.vbs
VBScript file
Text run by the Windows Script Host. A small language whose reach comes entirely from the COM objects it can create by name.
at a glance
- container
- PLAIN-TEXT
- executes
- needs an interpreter
- elevation
- sometimes
- install scope
- either
- inventory
- not enumerated
Knowing it is really that
Plain text run by the Windows Script Host. Like batch files it has no header; unlike batch files it can carry a signature block, though almost nothing does in practice.
What is actually inside
Text executed by the scripting host, with access to COM. That access is the point: the language itself is small, but through COM it reaches the filesystem, the registry, WMI, and any registered automation object on the machine.
What reading it tells you
- the source as written, including every COM object it creates by name
- the automation surfaces it intends to use, which are named as strings
- character-level encoding tricks, which remain visible as text even when unreadable
What it does not tell you
The useful half, and the half a file-type reference usually leaves out.
- what a COM object will do. The script names an object and calls a method; the implementation belongs to whatever is registered under that name on the machine, which the file cannot describe
- whether the registered object is the expected one. Resolution happens at runtime against the local registry, so the same script can reach different code on different machines
- what a dynamically constructed string will evaluate to before it is evaluated
- whether the host will run it here at all. Script host availability is a machine policy setting, so the same file is inert on one system and consequential on the next without either copy differing
Why it turns up on an endpoint
Login scripts, legacy automation, and installer glue. It is deprecated rather than absent, which is the worst combination: still executable on the platform, no longer something anybody is actively maintaining or watching.