VBS File Documentation

---

Technical details

Feature	Value
Full name	VBScript file (Visual Basic Scripting Edition)
File extension	.vbs
MIME type	text/vbscript
Format type	Plain-text script source code
Developer	Microsoft
Introduced	1996 (VBScript 1.0, with Internet Explorer 3)
Runtime	Windows Script Host: wscript.exe (windowed), cscript.exe (console)
WSH shipped from	1998 (Windows 98)
Based on	Visual Basic
Open standard	No
Magic number	None — plain text; no fixed signature
Encoding	ANSI or Unicode text
Executes on double-click	Yes (runs with the user’s privileges)
Security risk	High — classic malware/worm delivery format
Status	Deprecated; optional feature in Windows 11 24H2, removal planned ~2027
Encoded variant	.vbe (obfuscated by the Script Encoder)
Successor	PowerShell (automation), JavaScript (web)
Related extensions	.vbe, .js, .wsf, .bat, .ps1, .hta
Specification	Microsoft VBScript documentation (archived)

What is a VBS file?

A .vbs file is source code written in VBScript (Visual Basic Scripting Edition), a lightweight scripting language Microsoft introduced in 1996 alongside Internet Explorer 3. The file is plain text: a human-readable program. On Windows it is executed by the Windows Script Host (WSH), which shipped with the operating system from Windows 98 onward, through one of two engines: wscript.exe for windowed scripts that show dialog boxes, or cscript.exe for console output. VBScript was used for three main jobs over its lifetime: Windows administration and logon scripts, client-side scripting inside old Internet Explorer pages, and server-side classic ASP.

The one behaviour that matters most, and the reason this page leads with a warning, is that a .vbs is executable. Double-clicking it does not display the code; it runs the script immediately with your user privileges. To read what a script does you have to open it as text. The sections below explain how WSH resolves and runs a script, the language elements you will see in the source, exactly why the format became a notorious malware carrier, and the deprecation timeline that means VBScript is now on its way out of Windows entirely.

Windows Script Host and the run-on-double-click behaviour

When you double-click a .vbs, Windows looks up the file association for the extension, which points at wscript.exe, and hands the file to it. WSH loads the VBScript engine, parses the text and executes it top to bottom in the security context of the logged-in user. There is no compilation step and no separate “open” action: the default verb for the file type is run, not edit. That single design decision, that the obvious click executes rather than displays, is the root of the format’s danger, because a file named to look like a document runs as a program the instant it is opened.

The console engine, cscript.exe, is invoked explicitly from a command prompt (cscript script.vbs) and sends WScript.Echo output to the terminal instead of a dialog. Both engines expose the same object model. On current Windows the runtime may not even be present by default: on Windows 11 version 24H2 VBScript became an optional “Feature on Demand”, so a script that used to run may now fail with a missing-engine error until the feature is enabled.

The language elements you will see in the source

Reading a .vbs as text, a handful of constructs make up most scripts. Comments are lines beginning with an apostrophe (') and are ignored at run time. Option Explicit forces variables to be declared, and Dim declares them. Sub and Function define procedures. Output is WScript.Echo (to console or dialog) or MsgBox.

' map a network drive, then report
Option Explicit
Dim shell, net
Set shell = CreateObject("WScript.Shell")
Set net   = CreateObject("WScript.Network")
net.MapNetworkDrive "Z:", "\\server\share"
WScript.Echo "Drive Z: mapped for " & net.UserName

The pivotal line in almost any real script is CreateObject. VBScript itself is small; its power comes from instantiating COM objects and driving them. Scripting.FileSystemObject reads, writes, moves and deletes files. WScript.Shell runs programs, reads and writes the registry, and sets environment variables. winmgmts: reaches WMI to query and change system state. When you audit a suspicious .vbs, the CreateObject calls tell you what it can touch: a script that creates a FileSystemObject and a WScript.Shell and then loops over files is doing exactly the kind of thing a wiper or a worm does.

Why .vbs is a classic malware vector

The technical facts above combine into a well-known attack pattern, so it is worth being specific about the mechanics rather than issuing a vague caution. A malicious .vbs needs no exploit and no vulnerability. It relies entirely on the user double-clicking it and on WSH then running it with the user’s full privileges. From there the script uses the same COM objects a legitimate admin script uses, only turned to harm: FileSystemObject to overwrite or delete files, WScript.Shell’s RegWrite to add a Run key so the code survives reboot, and an HTTP object or shell command to download a heavier payload.

The canonical example is the ILOVEYOU worm of May 2000. It arrived as an email attachment named LOVE-LETTER-FOR-YOU.TXT.vbs. The double extension is the trick: with Windows hiding known extensions, the file appeared to be LOVE-LETTER-FOR-YOU.TXT, a harmless text file, while the real .vbs extension meant a double-click ran it. Once run, it overwrote users’ files, wrote itself into the registry to persist, and used the Outlook object model to mail copies to every contact, which is how it spread worldwide in hours. Every step used ordinary, documented VBScript and COM calls. The practical rules follow directly: never run a .vbs that arrived by email, chat or download unless you wrote it; always inspect one by right-clicking and choosing Edit so it opens as text instead of executing; and be suspicious of any file whose name ends in a double extension such as invoice.pdf.vbs. If a .vbs arrives unexpectedly, the safe assumption is that it is hostile.

The .vbe encoded variant and obfuscation

A related file you may meet is .vbe, an encoded VBScript produced by Microsoft’s old Script Encoder (screnc.exe). It is important to understand that .vbe is obfuscated, not encrypted: the encoding scrambles the source so it is not casually readable, but it uses a fixed, publicly known transformation and is trivially reversible with free decoders. It was originally meant to hide script internals from casual viewing, but because it also hides intent from a quick human glance, malware adopted it to slip past shallow inspection. If you find a .vbe, treat it exactly as you would a .vbs: decode it to read what it actually does before considering whether to trust it, and never run it on faith.

Deprecation: VBScript is being removed from Windows

VBScript is end-of-life. Internet Explorer, which hosted VBScript in the browser, was retired in June 2022, so browser VBScript is already dead and no modern browser runs it. For the operating system, Microsoft has published a phased removal. In Windows 11 version 24H2 and Windows Server 2025, VBScript became a “Feature on Demand”, still enabled by default for now but no longer a permanent part of the OS. Microsoft’s stated plan is to stop enabling it by default around 2027, and then to remove it from Windows entirely in a later release.

For anyone maintaining legacy scripts, the migration path Microsoft points to is PowerShell, which covers everything VBScript did (file and registry operations, WMI, process control) and a great deal more. There is no one-click converter: moving a .vbs to a .ps1 is a manual rewrite, because the two are different languages, though the mapping is direct since both ultimately drive the same Windows objects. A batch (.bat) rewrite is possible for simple file-and-loop scripts but a poor fit for anything using COM, so PowerShell is the sensible target. Given both the deprecation and the security history, many managed environments now block .vbs execution outright, which is why an old utility script that once ran may simply do nothing on a current, locked-down machine.

References

• Microsoft — Windows Script Host overview
• Microsoft — VBScript deprecation: timelines and next steps
• PowerShell — the recommended replacement

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.