Windows Scripting Host

Windows Scripting Host (WSH) is Windows’ built-in script execution environment: two interpreters — cscript.exe (console) and wscript.exe (GUI/dialog) — running VBScript and JScript with full access to COM automation. The interpreter doesn’t care about file extension; a .txt file containing VBScript executes fine. In MITRE terms this is T1059.005 (Command and Scripting Interpreter: Visual Basic) — VBScript is a default scripting language on Windows hosts and has been a malware workhorse for decades precisely because the interpreter is always there.

Key security property: WSH runs with the invoking user’s privileges — there is no elevation. A script fired from a phishing document gets whatever that user has, no more. (Which is why WSH malware pairs with privilege-escalation or persistence techniques rather than trying to be admin.)

The shape of a WSH script

Hello-world VBScript:

Dim message
message = "Welcome to THM"
MsgBox message

Launching a program goes through the Wscript.Shell COM object:

Set shell = WScript.CreateObject("Wscript.Shell")
 
' Note the trailing space after calc.exe — required by quirky
' interaction between wscript/cscript and the VB runtime.
' Triple double-quotes are the alternative.
shell.Run("C:\Windows\System32\calc.exe " & WScript.ScriptFullName),0,True
shell.Run("""C:\Windows\System32\calc.exe""" & WScript.ScriptFullName),0,True

shell.Run(command, windowStyle, waitOnReturn) — the 0 hides the window, which combined with the extension-agnosticism is most of the offensive recipe.

Modern posture: deprecated and restricted

WSH’s era is ending. Microsoft has deprecated VBScript (being removed from future Windows releases after a feature-on-demand phase), and recent Windows builds increasingly restrict what the Wscript.Shell object can launch — empirical testing shows calc.exe runs but most other binaries are blocked. Between that, Attack Surface Reduction rules (M1040: block VBScript/JS from executing downloaded content), and Office macro hardening, WSH is a shrinking attack surface — but it still appears in the wild (Koadic runs most of its operation through WSH VBScript; Operation CuckooBees executed encoded VBScript via wscript), and on legacy estates it remains fully functional.

Detection

• Process lineage is the highest-signal analytic: Office applications or mshta.exe spawning wscript.exe/cscript.exe is MITRE’s DET0076 pattern and almost never legitimate
• Command lines referencing scripts in temp/user-profile paths, or non-.vbs/.js extensions (extension-agnosticism cuts both ways)
• Script Block-equivalent telemetry is weak here (WSH has no PowerShell-style 4104 logging) — rely on process + file-create events, and on AMSI, which does scan VBScript/JScript content
• When PowerShell is locked down via AppLocker/WDAC, expect attackers to probe WSH as the alternate interpreter — correlate CLM enforcement with WSH process launches

Related

• windows-file-association-hijacking — wscript.exe is a classic hijack handler; both are “trigger on user double-click” techniques
• powershell-constrained-language-mode — the PowerShell lockdown that pushes attackers toward WSH
• powershell-execution-policy-bypass — contrast: PowerShell’s non-boundary vs. WSH’s different (privilege-scoped) limits
• backdoor-vbscripts — weaponizing .vbs files on shares, the WSH payload case
• classic-microsoft-excel-command-injection-exploit — the DDE alternative that bypasses WSH entirely

Sources

• Command and Scripting Interpreter: Visual Basic
• cscript