Wscript/Cscript Execution

wscript.exe and cscript.exe are the signed Windows Script Host (WSH) engines that execute .vbs, .js, .vbe, .jse, and .wsf scripts. wscript runs them in a windowed context, cscript at the console; both interpret VBScript and JScript with the full privileges of the calling user. They are first-class Living-off-the-Land binaries because script files arrive easily by email and run directly on double-click through these trusted hosts.

These engines are a classic first stage in phishing chains: a ZIP or ISO attachment contains a heavily obfuscated .js/.vbs loader, the user opens it, and wscript.exe executes it. The script then bootstraps the next stage — most often by spawning powershell.exe, downloading a payload with an HTTP request, or registering persistence. An analyst encounters the script hosts as the visible actor while the real logic sits in the script body.

How it works

The host is simply pointed at a script file, frequently dropped into a user-writable directory:

wscript.exe C:\Users\Public\invoice.js

wscript loads the script and runs it through the JScript or VBScript engine. A typical loader calls WScript.Shell to spawn a shell, or MSXML2.XMLHTTP/WinHttp to fetch a second stage, often after layers of string concatenation, Chr() arithmetic, and eval/Execute to defeat static review. Analysts should treat any wscript/cscript running a script from %TEMP%, %APPDATA%, a download/ISO mount, or with a //e: engine override, as worth triage — and pay special attention when the parent is a mail or archive application.

Detection & analysis

Static analysis:

• The script is plain text — open it. Look for CreateObject("WScript.Shell"), .Run/.Exec, MSXML2.XMLHTTP/WinHttp requests, ADODB.Stream file writes, eval/Execute, base64 blobs, and downstream powershell/cmd references. Deobfuscate Chr()-built and concatenated strings to reveal URLs and commands.
• Triage the command line with regex/YARA: a script path in a user-writable directory, the //e:vbscript///e:jscript engine flag, //b (batch/silent) mode, or a .jse/.vbe encoded extension all flag likely abuse.

Dynamic analysis:

• In a sandbox, observe whether the host makes outbound network connections (to pull the next stage) and what it writes to disk — legitimate admin scripts rarely both fetch from the internet and drop executables.
• Examine the process tree. wscript.exe/cscript.exe spawned by outlook.exe, winrar.exe, 7zFM.exe, explorer.exe (from a download), or spawning powershell.exe/cmd.exe/mshta.exe, is a high-confidence loader chain.

Detection rule hint:

Alert on Sysmon Event ID 1 where Image ends with \wscript.exe or \cscript.exe AND (the script path is in %TEMP%/%APPDATA%/a removable or mounted volume, OR the command line carries //e:///b, OR the parent is a mail or archive application). Correlate strongly with child powershell.exe/cmd.exe/mshta.exe and Event ID 3 (network) from the same PID to catch the staging behaviour.