T1059 Google Chronicle · YARA-L

Detect Command and Scripting Interpreter in Google Chronicle

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.

MITRE ATT&CK

Tactic
Execution
Technique
T1059 Command and Scripting Interpreter
Canonical reference
https://attack.mitre.org/techniques/T1059/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1059_scripting_interpreter_suspicious_parent {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects command and scripting interpreters spawned by suspicious parent processes including Office apps, WMI, and svchost (MITRE ATT&CK T1059)"
    mitre_attack_tactic = "Execution"
    mitre_attack_technique = "T1059"
    severity = "HIGH"
    confidence = "HIGH"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    $e.principal.process.file.full_path = /(?i)(powershell\.exe|pwsh\.exe|cmd\.exe|wscript\.exe|cscript\.exe|mshta\.exe|python\.exe|python3\.exe|perl\.exe|ruby\.exe|lua\.exe|node\.exe|AutoHotkey\.exe|AutoIt3\.exe)$/
    $e.principal.process.parent_process.file.full_path = /(?i)(winword\.exe|excel\.exe|powerpnt\.exe|outlook\.exe|msaccess\.exe|mspub\.exe|visio\.exe|onenote\.exe|explorer\.exe|wmiprvse\.exe|svchost\.exe)$/

  condition:
    $e
}
high severity high confidence

Chronicle YARA-L 2.0 rule detecting scripting interpreter binaries (PowerShell, cmd, WScript, Python, Node.js, etc.) launched by suspicious parent processes including Microsoft Office applications, WMI provider host (wmiprvse.exe), and svchost.exe. Triggers on UDM PROCESS_LAUNCH events matching the parent-child process relationship indicative of macro execution, WMI abuse, or service-spawned interpreter activity.

Data Sources

Google Chronicle UDM via Windows SensorChronicle Forwarder (Sysmon or Windows Event Logs)CrowdStrike Falcon or Carbon Black EDR Chronicle integration

Required Tables

UDM Events (PROCESS_LAUNCH)

False Positives & Tuning

  • Legitimate scheduled tasks registered under svchost service groups that invoke PowerShell or cmd.exe for maintenance operations such as disk cleanup or log rotation
  • Office-integrated business intelligence tools (Power Query, Excel macros for data refresh) that launch Python or PowerShell as part of sanctioned data pipeline workflows
  • WMI-based monitoring solutions (e.g., SCCM hardware inventory, Dell OpenManage) that use wmiprvse.exe to spawn scripting engines for asset discovery

Other platforms for T1059


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 1 Office 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 2 WScript 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 3 MSHTA 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

Related Techniques

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