T1059

Command and Scripting Interpreter

Execution Last updated:

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/
Microsoft Sentinel / Defender
kusto
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.

high severity medium confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

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:


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.

  1. 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.

  2. 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.

  3. 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

  1. Identify the parent-child process relationship — which parent spawned the scripting interpreter and is this expected in your environment?
  2. Examine the full command line of the scripting interpreter — is it executing inline code, downloading content, or referencing suspicious file paths?
  3. Check the user context — is this a standard user, service account, or privileged account? Does this user normally execute scripts?
  4. Determine if the scripting engine was invoked by an Office application — this is a strong indicator of macro-based initial access
  5. Look for subsequent child processes spawned by the scripting interpreter — chained execution (Office -> script -> LOLBin) is a hallmark of multi-stage attacks
  6. Check for network connections initiated by the scripting process — outbound connections suggest C2 or payload download

Containment

  1. If malicious macro detected: isolate the endpoint and block the document hash across the organization
  2. If C2 communication observed: isolate the endpoint from the network and block the C2 domain/IP at perimeter
  3. If lateral movement detected via WMI or remote script execution: disable the compromised account and isolate affected systems
  4. If multiple endpoints affected: consider enterprise-wide script execution policy changes as temporary mitigation

Evidence Collection

  1. Process Creation Events — Sysmon Event ID 1 or Security Event ID 4688 with full command line details
  2. Script content — PowerShell ScriptBlock Logging (4104), VBScript/JScript via AMSI events
  3. Network Connections — Sysmon Event ID 3 for outbound connections from script engines
  4. File Creation Events — Sysmon Event ID 11 for files dropped by script interpreters
  5. Loaded DLLs — Sysmon Event ID 7 for suspicious DLLs loaded into script engine processes
  6. 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.

Hunting — KQL
kql
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
Hunting — SPL
spl
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.

Hunting — KQL
kql
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
Hunting — SPL
spl
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.

Hunting — KQL
kql
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
Hunting — SPL
spl
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

Test 1 Office Macro Simulation — Word spawns PowerShell
windows

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

powershell
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.

Test 2 WScript Execution of VBScript File
windows

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

powershell
echo MsgBox "df00tech-test" > %TEMP%\df00tech-test.vbs && wscript.exe %TEMP%\df00tech-test.vbs

Cleanup

powershell
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.

Test 3 MSHTA Executing Inline VBScript
windows

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

powershell
mshta.exe "vbscript:Execute(""CreateObject(""""Wscript.Shell"""").Run """"calc.exe"""", 0:close"")"

Cleanup

powershell
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.

Related Detections

Tactic Hub