Command and Scripting Interpreter
Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries. These interfaces and languages provide ways of interacting with computer systems and are a common feature across many different platforms. Most systems come with some built-in command-line interface and scripting capabilities, for example, macOS and Linux distributions include some flavor of Unix Shell while Windows installations include the Windows Command Shell and PowerShell. There are also cross-platform interpreters such as Python, as well as those commonly associated with client applications such as JavaScript and Visual Basic. Adversaries may abuse these technologies in various ways as a means of executing arbitrary commands.
What is T1059 Command and Scripting Interpreter?
Command and Scripting Interpreter (T1059) maps to the Execution tactic — the adversary is trying to run malicious code in MITRE ATT&CK.
This page provides production-ready detection logic for Command and Scripting Interpreter, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Execution
- Technique
- T1059 Command and Scripting Interpreter
- Canonical reference
- https://attack.mitre.org/techniques/T1059/
let ScriptEngines = dynamic(["powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "python.exe", "python3.exe", "perl.exe", "ruby.exe", "lua.exe", "node.exe", "osascript", "bash", "sh", "zsh", "AutoHotkey.exe", "AutoIt3.exe"]);
let SuspiciousParents = dynamic(["winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe", "msaccess.exe", "mspub.exe", "visio.exe", "onenote.exe", "explorer.exe", "wmiprvse.exe", "svchost.exe"]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any (ScriptEngines)
| where InitiatingProcessFileName has_any (SuspiciousParents)
| extend IsOfficeParent = InitiatingProcessFileName has_any ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| extend IsWMI = InitiatingProcessFileName =~ "wmiprvse.exe"
| extend IsSvchost = InitiatingProcessFileName =~ "svchost.exe"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, IsOfficeParent, IsWMI, IsSvchost
| sort by Timestamp desc Detects suspicious execution of scripting interpreters spawned by unusual parent processes using Microsoft Defender for Endpoint. Focuses on script engines (PowerShell, cmd, wscript, cscript, mshta, python, node, etc.) being launched from Office applications, WMI, or service host processes, which are common indicators of malicious macro execution, lateral movement, or exploitation.
Data Sources
Required Tables
False Positives
- Legitimate Office macros that invoke scripting engines for approved business automation
- WMI-based management tools (SCCM, Intune) that spawn script interpreters for system configuration
- Svchost launching script interpreters as part of scheduled tasks or Windows Update processes
Sigma rule & cross-platform mapping
The detection logic for Command and Scripting Interpreter (T1059) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1059
References (5)
- https://attack.mitre.org/techniques/T1059/
- https://docs.splunk.com/Documentation/SplunkCloud/latest/SearchReference/CommonStatsFunctions
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1059/T1059.md
- https://github.com/SigmaHQ/sigma/tree/master/rules/windows/process_creation
- https://lolbas-project.github.io/
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Office Macro Simulation — Word spawns PowerShell
Expected signal: Sysmon Event ID 1: Process Create for cmd.exe spawning powershell.exe. Security Event ID 4688 with command line details showing the full chain.
- Test 2WScript Execution of VBScript File
Expected signal: Sysmon Event ID 1: Process Create with Image=wscript.exe and CommandLine containing the .vbs file path. Sysmon Event ID 11: File Create for the .vbs file in the temp directory.
- Test 3MSHTA Executing Inline VBScript
Expected signal: Sysmon Event ID 1: Process Create with Image=mshta.exe and CommandLine containing 'vbscript:Execute'. Child process creation event for calc.exe spawned by mshta.exe.
Response Playbook
Triage
- Identify the parent-child process relationship — which parent spawned the scripting interpreter and is this expected in your environment?
- Examine the full command line of the scripting interpreter — is it executing inline code, downloading content, or referencing suspicious file paths?
- Check the user context — is this a standard user, service account, or privileged account? Does this user normally execute scripts?
- Determine if the scripting engine was invoked by an Office application — this is a strong indicator of macro-based initial access
- Look for subsequent child processes spawned by the scripting interpreter — chained execution (Office -> script -> LOLBin) is a hallmark of multi-stage attacks
- Check for network connections initiated by the scripting process — outbound connections suggest C2 or payload download
Containment
- If malicious macro detected: isolate the endpoint and block the document hash across the organization
- If C2 communication observed: isolate the endpoint from the network and block the C2 domain/IP at perimeter
- If lateral movement detected via WMI or remote script execution: disable the compromised account and isolate affected systems
- If multiple endpoints affected: consider enterprise-wide script execution policy changes as temporary mitigation
Evidence Collection
- Process Creation Events — Sysmon Event ID 1 or Security Event ID 4688 with full command line details
- Script content — PowerShell ScriptBlock Logging (4104), VBScript/JScript via AMSI events
- Network Connections — Sysmon Event ID 3 for outbound connections from script engines
- File Creation Events — Sysmon Event ID 11 for files dropped by script interpreters
- Loaded DLLs — Sysmon Event ID 7 for suspicious DLLs loaded into script engine processes
- Registry Modifications — Sysmon Event ID 13 for persistence mechanisms set by scripts
Escalation Criteria
- ! Office application spawning a scripting interpreter that then makes outbound network connections
- ! Multiple different scripting interpreters executed in rapid succession on the same endpoint
- ! Script execution followed by credential access tools (Mimikatz, LSASS dumping)
- ! Same suspicious script execution pattern observed across multiple endpoints simultaneously
- ! Script interpreter running as SYSTEM or domain admin without a corresponding change ticket
Investigation Guide
Forensic Artifacts
- >
File System: Recent .ps1, .vbs, .js, .bat, .cmd, .py, .ahk, .au3 files in temp directories or user profile - >
Registry: HKCU\Software\Microsoft\Office\<version>\<app>\Security — macro security settings - >
Event Log: Microsoft-Windows-PowerShell/Operational (4103, 4104) for PowerShell activity - >
Event Log: Microsoft-Windows-WMI-Activity/Operational for WMI-based script execution - >
File System: Prefetch files for script interpreters (POWERSHELL.EXE-*.pf, WSCRIPT.EXE-*.pf, CSCRIPT.EXE-*.pf) - >
File System: Browser download history for recently downloaded script files
Tuning Guidance
This is the parent technique covering all scripting interpreters. Start by deploying sub-technique-specific detections (T1059.001 through T1059.013) for targeted coverage. Use this parent detection as a catch-all for unusual parent-child process relationships involving any script engine. Baseline your environment's normal script interpreter usage by department and role. Build allowlists for known-good parent-child combinations (e.g., SCCM -> PowerShell, Task Scheduler -> cmd.exe). Focus tuning on reducing noise from IT automation tools while maintaining visibility on Office-to-script chains and WMI-spawned interpreters.
Hunting Queries
Hunt for accounts using an unusually high variety of scripting interpreters. Accounts using more than 3 different script engines may indicate an attacker leveraging multiple execution vectors or an automated post-exploitation framework.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "python.exe", "node.exe")
| summarize ScriptTypes=dcount(FileName), ExecutionCount=count(), Devices=dcount(DeviceName) by AccountName
| where ScriptTypes > 3 or ExecutionCount > 50
| sort by ScriptTypes desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 (Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\cmd.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\python.exe" OR Image="*\\node.exe")
| stats dc(Image) as ScriptTypes, count as ExecutionCount, dc(host) as Devices by User
| where ScriptTypes > 3 OR ExecutionCount > 50
| sort - ScriptTypes Hunt for Office applications spawning script interpreters. This is a classic indicator of macro-based initial access. Any Office-to-script-engine parent-child relationship warrants investigation.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 (ParentImage="*\\winword.exe" OR ParentImage="*\\excel.exe" OR ParentImage="*\\powerpnt.exe" OR ParentImage="*\\outlook.exe") (Image="*\\powershell.exe" OR Image="*\\cmd.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time Hunt for Windows Script Host engines executing scripts from URLs or referencing suspicious script file extensions. Remote script execution via wscript/cscript/mshta is a common initial access and execution technique.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("wscript.exe", "cscript.exe", "mshta.exe")
| where ProcessCommandLine has_any ("http://", "https://", "ftp://", ".js", ".vbs", ".hta", ".wsf")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 (Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe") (CommandLine="*http://*" OR CommandLine="*https://*" OR CommandLine="*.js*" OR CommandLine="*.vbs*" OR CommandLine="*.hta*" OR CommandLine="*.wsf*")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time Atomic Red Team Tests
Simulates a malicious Office macro by launching PowerShell from a command that mimics the Office-to-script execution chain. In real attacks, this chain begins with a macro in a Word document that invokes PowerShell to download and execute a payload.
Command
cmd.exe /c "powershell.exe -NoProfile -Command Write-Output 'df00tech-test-T1059'" Expected Telemetry
Sysmon Event ID 1: Process Create for cmd.exe spawning powershell.exe. Security Event ID 4688 with command line details showing the full chain.
Expected Detection
Alert fires when cmd.exe spawns powershell.exe. In production environments, the parent would be winword.exe — adjust test to launch from an Office process for full chain validation.
Executes a benign VBScript file using the Windows Script Host (wscript.exe). This simulates adversary use of VBS for execution, which is common in phishing attacks and dropper chains.
Command
echo MsgBox "df00tech-test" > %TEMP%\df00tech-test.vbs && wscript.exe %TEMP%\df00tech-test.vbs Cleanup
del %TEMP%\df00tech-test.vbs Expected Telemetry
Sysmon Event ID 1: Process Create with Image=wscript.exe and CommandLine containing the .vbs file path. Sysmon Event ID 11: File Create for the .vbs file in the temp directory.
Expected Detection
Alert fires on wscript.exe execution. SPL and KQL queries match on the script engine filename.
Uses mshta.exe to execute inline VBScript via the vbscript: protocol handler. This technique is frequently used by adversaries to bypass application whitelisting and execute arbitrary code without dropping a file to disk.
Command
mshta.exe "vbscript:Execute(""CreateObject(""""Wscript.Shell"""").Run """"calc.exe"""", 0:close"")" Cleanup
taskkill /f /im calc.exe 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=mshta.exe and CommandLine containing 'vbscript:Execute'. Child process creation event for calc.exe spawned by mshta.exe.
Expected Detection
Alert fires on mshta.exe execution with inline vbscript protocol handler. Both KQL and SPL queries detect mshta.exe as a suspicious script engine.