WSH Injection is a technique that abuses Windows Script Host to run malicious script code through trusted scripting features. It commonly relies on script files, scriptlets, or moniker-based execution to launch payloads, often evading basic application controls that focus only on obvious executables.
How WSH Injection Works
WSH Injection abuses Windows Script Host as a trusted execution path for script code. The technique matters because the host is designed to run legitimate administrative and automation scripts, so malicious content can blend into normal script-based activity instead of appearing as an obvious standalone executable.
Attackers may deliver payloads through script files, scriptlets, or moniker-based execution. That flexibility gives defenders fewer fixed patterns to block, especially where policy and user awareness focus more on binaries than on interpreted script launch chains.
Why WSH Injection Is Effective
The technique is effective because it inherits trust from a built-in Windows component. If defenders allow script hosting broadly, the abuse can bypass weak application controls, blend with admin tooling, and reach execution without needing a traditional dropper that security tools would normally flag first.
It is also useful to attackers because script-based execution can be chained with living-off-the-land behaviour, letting a payload stage, download, decode, or launch a second-stage component with fewer obvious indicators than a direct executable launch would create.
Common Delivery and Abuse Patterns
WSH Injection is usually seen as a launch mechanism rather than a standalone payload. Script files can be opened directly, scriptlets can be invoked through COM-style execution paths, and moniker-based techniques can trigger script execution through a trusted handler route that many environments do not monitor as closely as process launches.
Because the script host supports multiple scripting languages and formats, defenders need to watch for the broader execution chain, not just file extension or binary reputation. The suspicious behavior is often the context of the launch, the parent-child process chain, and the post-launch actions the script performs.
For broad script abuse tradecraft, the attack logic is similar to the patterns tracked in the MITRE ATT&CK Enterprise Matrix, where execution, persistence, and defense evasion are often separated across multiple steps.
Defensive Controls and Detection Focus
Defence is strongest when organisations treat script hosting as an execution surface in its own right. OWASP Top 10 is a general application-security reference, but the practical lesson here is narrower: trusted execution features become risky when they can be abused to run untrusted code.
Detection should focus on suspicious script host usage, unusual parent-child process relationships, encoded or obfuscated script content, and script execution from user-writable or internet-sourced locations. Logging and command-line visibility matter because the initial launch mechanism is often less important than what the script does next.
Endpoint policy should also distinguish legitimate administration from opportunistic abuse. If scripting is necessary, constrain where scripts may run from, what interpreters may be launched, and which users or automation contexts are allowed to invoke them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | WSH Injection is a script-based execution technique within command and scripting abuse. |
| Recommendation — Map suspicious WSH launches to T1059 and hunt for interpreted command execution in your telemetry. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | WSH Injection needs monitoring of script execution, process chains, and abnormal host behavior. |
| AC-6 — Least Privilege | Limiting who can run script hosts reduces the blast radius of trusted scripting abuse. | |
| Recommendation — Monitor script host activity and alert on anomalous script execution chains. Restrict script execution rights to the minimum users and contexts that genuinely need them. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Script-host abuse is best surfaced through process and command-line logging. |
| Recommendation — Centralize and review logs that capture script host launches and command-line details. | ||
| NIST CSF 2.0 | DE.CM-08 — Monitor for Unauthorised and Unintended Connections | WSH Injection often appears as unusual host activity and execution paths that monitoring should expose. |
| Recommendation — Use monitoring to spot abnormal script-host activity and unexpected execution patterns. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org