{"id":135,"date":"2026-05-24T23:17:17","date_gmt":"2026-05-25T03:17:17","guid":{"rendered":"https:\/\/securebydefault.io\/blog\/?p=135"},"modified":"2026-05-24T23:27:10","modified_gmt":"2026-05-25T03:27:10","slug":"soc146-phishing-excel-40-macro-walkthrough","status":"publish","type":"post","link":"https:\/\/securebydefault.io\/blog\/soc146-phishing-excel-40-macro-walkthrough\/","title":{"rendered":"SOC146 LetsDefend Walkthrough: Phishing Mail Detected \u2014 Excel 4.0 Macros"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Excel 4.0 macros are older than most SOC analysts. They date to 1992, were designed for legitimate spreadsheet automation, and were effectively obsolete by the time VBA arrived in Office 97. Microsoft never removed them. Attackers noticed.<\/p>\n\n\n\n

The reason Excel 4.0 macros\u200a\u2014\u200aalso called XLM macros\u200a\u2014\u200akeep showing up in phishing campaigns is simple: most organizations block VBA macros. Endpoint protection tools are tuned to catch VBA. Security awareness training warns employees about VBA. But XLM? The old format gets far less scrutiny, it runs without triggering the same warnings, and it can call the same dangerous Windows utilities as its modern equivalent. Defenders got good at blocking the new thing and forgot about the old one.<\/p>\n\n\n\n

SOC146 is a textbook example of this technique in practice. Here\u2019s how the investigation went\u200a\u2014\u200aand more importantly, why each step matters.<\/p>\n\n\n\n

The Alert<\/h3>\n\n\n\n

EventID: 93\u200a\u2014\u200aSOC146\u200a\u2014\u200aPhishing Mail Detected\u200a\u2014\u200aExcel 4.0 Macros<\/p>\n\n\n\n

First action: take ownership of the alert and open a case. This matters not just administratively\u200a\u2014\u200astarting a case creates a timestamp, establishes a chain of custody for your findings, and ensures nothing is lost if the investigation runs long or is handed off to another analyst. In a real SOC environment, owning it means you\u2019re accountable for it. That accountability is what keeps investigations from falling through the cracks.<\/p>\n\n\n\n

Then: start the playbook. A playbook is a structured decision tree for a specific incident type. It sounds bureaucratic, but it serves a real purpose\u200a\u2014\u200aunder pressure, during a live incident, a playbook keeps you from skipping steps. The questions it asks are the questions you\u2019d eventually ask anyway. It just makes sure you ask them in the right order before you start taking action.<\/p>\n\n\n\n

\"\"
SOC146 alert details\u200a\u2014\u200aEventID 93, severity High, flagged as a phishing mail with Excel 4.0 macro attachment.<\/sup><\/figcaption><\/figure>\n\n\n\n

Step 1\u200a\u2014\u200aExamine the Email<\/h3>\n\n\n\n

The first job is understanding what we\u2019re dealing with. Navigate to the Email Security tab and use the SMTP address from the alert to pull the email logs. What we find:<\/p>\n\n\n\n

Sent: June 13, 2021, 2:11 PM<\/p>\n\n\n\n

SMTP (sending server): 24.213.228.54<\/p>\n\n\n\n

Sender address: trenton@tritowncomputers.com<\/p>\n\n\n\n

Recipient: lars@letsdefend.io<\/p>\n\n\n\n

Attachment: 11f44531fb088d31307d87b01e8eabff.zip<\/p>\n\n\n\n

\"\"
Email log pulled from the SMTP address\u200a\u2014\u200asender domain, recipient, and attachment name (an MD5 hash used as a filename, a pattern associated with automated malware distribution).<\/sup><\/figcaption><\/figure>\n\n\n\n

The sender domain\u200a\u2014\u200atritowncomputers.com\u200a\u2014\u200ais worth noting. It looks like a plausible small business. That\u2019s deliberate. This isn\u2019t a Nigerian prince email with obvious tells. The sender has a real-looking domain and a real-looking name. The email content was flagged as suspicious, but subtle. This is what modern phishing looks like: just credible enough to make someone hesitate before deleting it.<\/p>\n\n\n\n

The attachment name is also worth flagging immediately. 11f44531fb088d31307d87b01e8eabff is an MD5 hash\u200a\u2014\u200asomeone took the file’s hash and used it as the filename, a pattern associated with automated malware distribution. The zip extension tells us we need to look inside before we know what we\u2019re actually dealing with.<\/p>\n\n\n\n

At this point in the playbook, is the email suspicious? Yes. Continue with the investigation.<\/p>\n\n\n\n

Step 2\u200a\u2014\u200aAnalyze the Attachment<\/h3>\n\n\n\n

Never open a suspicious attachment on a production machine. This should be obvious, but it\u2019s worth saying clearly because the cost of getting it wrong is an active compromise on your own endpoint, which is a significantly worse day than the one you started with.<\/p>\n\n\n\n

Download the attachment and extract it in an isolated environment. REMnux is a solid choice for this\u200a\u2014\u200ait\u2019s a Linux distribution built specifically for malware analysis. I used the LetsDefend<\/a> built-in Linux sandbox, which works for the same reason: isolated, disposable, no path back to anything that matters.<\/p>\n\n\n\n

The zip contains three files:<\/p>\n\n\n\n

research-1646684671.xls\u200a\u2014\u200athe delivery mechanism<\/p>\n\n\n\n

iroto.dll\u200a\u2014\u200amalicious DLL, payload component<\/p>\n\n\n\n

iroto1.dll\u200a\u2014\u200asecond malicious DLL, payload component<\/p>\n\n\n\n

The XLS filename pattern (filename-timestamp.xls) is another automated distribution tell. This wasn\u2019t crafted manually for lars@letsdefend.io\u200a\u2014\u200ait was generated and sent at scale.<\/p>\n\n\n\n

The three-file structure immediately suggests the attack chain: the XLS executes first and uses the DLLs to do its real work. DLLs (Dynamic Link Libraries) are shared code libraries that Windows applications load at runtime. Attackers bundle malicious DLLs with their payloads because these DLLs can be loaded by legitimate Windows utilities, making them much harder to detect and block than standalone executables.<\/p>\n\n\n\n

Step 3\u200a\u2014\u200aVirusTotal Scan<\/h3>\n\n\n\n

Run all three files through VirusTotal. VirusTotal aggregates results from dozens of antivirus engines and gives you a quick picture of whether a file is known malicious and what family it belongs to.<\/p>\n\n\n\n

Results: all three files come back flagged as malicious. That confirms what the structure suggested\u200a\u2014\u200athis isn\u2019t an accidental zip or a false positive. But VirusTotal alone isn\u2019t the whole picture. It tells you a file is bad. It doesn\u2019t tell you what it does, which matters for understanding scope and writing a useful incident summary.<\/p>\n\n\n\n

That\u2019s what the sandbox is for.<\/p>\n\n\n\n

\"\"
VirusTotal flags all three extracted files as malicious. Detection count confirms known-bad status\u200a\u2014\u200abut VirusTotal alone doesn\u2019t tell you what the files do. That\u2019s what the sandbox is\u00a0for.<\/sup><\/figcaption><\/figure>\n\n\n\n
\n

Dynamic Link Libraries (DLL) are an essential Windows operating system component, providing reusable code and functionality that multiple programs can utilize.<\/p>\n<\/blockquote>\n\n\n\n

\n

By placing a malicious DLL in a location where an application searches for the required DLL, attackers can execute arbitrary code with the privileges of the hijacked application. This allows them to compromise the integrity and security of the system.<\/p>\n<\/blockquote>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Step 4\u200a\u2014\u200aSandbox Analysis (AnyRun)<\/h3>\n\n\n\n

AnyRun is an interactive malware sandbox\u200a\u2014\u200ayou submit a file, it executes in a controlled environment, and you watch what happens. Process tree, network connections, file system changes, registry modifications. The attack plays out in front of you.<\/p>\n\n\n\n

What AnyRun shows for research-1646684671.xls:<\/p>\n\n\n\n

The Excel file executes its XLM macros on open. Those macros call regsvr32.exe\u200a\u2014\u200athe Windows utility for registering DLLs\u200a\u2014\u200ato load iroto.dll and iroto1.dll. This is the core of the Excel 4.0 macro technique: use a built-in Windows tool (regsvr32) to execute the malicious payload. Regsvr32 is a legitimate, signed Microsoft binary. Many security tools and detection rules don\u2019t flag it by default. The malicious activity is occurring within the DLL being loaded, not in the utility loading it.<\/p>\n\n\n\n

\"\"
AnyRun process tree showing the full execution chain: Excel opens, XLM macros execute, regsvr32.exe loads iroto.dll and iroto1.dll. The malicious work happens inside the DLLs\u200a\u2014\u200anot in the signed Windows binary loading\u00a0them.<\/sup><\/figcaption><\/figure>\n\n\n\n

This technique maps to MITRE ATT&CK T1218.010 (Signed Binary Proxy Execution: Regsvr32). The XLM macros themselves map to T1137.001 (Office Application Startup: Office Template Macros), and the delivery via spearphishing attachment maps to T1566.001.<\/p>\n\n\n\n

After the DLLs load, the malware establishes outbound network connections to two C2 (command and control) domains:<\/p>\n\n\n\n

nws.visionconsulting.ro<\/p>\n\n\n\n

royalpalm.sparkblue.lk<\/p>\n\n\n\n

\"\"
AnyRun network connections confirming C2 beaconing to both domains. This is the moment the investigation changes classification\u200a\u2014\u200afrom \u201cdelivered phishing\u201d to \u201cactive compromise.\u201d<\/sup><\/figcaption><\/figure>\n\n\n\n

C2 infrastructure is where attackers maintain communication with a compromised host\u200a\u2014\u200asending commands, receiving exfiltrated data, and potentially downloading additional payloads. The presence of C2 beaconing in the sandbox analysis indicates that this isn\u2019t just a malware sample. This is a full compromise chain: delivery \u2192 execution \u2192 persistence attempt \u2192 calling home.<\/p>\n\n\n\n

Step 5\u200a\u2014\u200aWas It Delivered? Did They Open It?<\/h3>\n\n\n\n

Two questions that change everything about the response.<\/p>\n\n\n\n

Check the alert details for Device Action. The email was marked Allowed\u200a\u2014\u200ait was delivered to lars@letsdefend.io\u2019s inbox. The mail gateway didn\u2019t catch it. That moves this from \u2018attempted phishing\u2019 to \u2018delivered phishing,\u2019 and the response changes accordingly.<\/p>\n\n\n\n

Immediate action: delete the email from the recipient\u2019s mailbox. This prevents the user from opening it if they haven\u2019t already\u200a\u2014\u200aand more importantly, from forwarding it or accessing it on another device.<\/p>\n\n\n\n

Now the critical question: did lars open it?<\/p>\n\n\n\n

Take the C2 domains from AnyRun and search them in Log Management. What comes back: outbound GET requests from an internal IP to both nws.visionconsulting.ro and royalpalm.sparkblue.lk. The device action on those requests was allowed. The connection went through.<\/p>\n\n\n\n

This confirms it. The file was opened. The macros ran. The DLLs are loaded. The malware successfully called home. This is no longer a phishing attempt\u200a\u2014\u200ait\u2019s an active compromise.<\/p>\n\n\n\n

\"\"
Log management confirms what AnyRun predicted\u200a\u2014\u200aoutbound GET requests from an internal IP to both C2 domains, Device Action Allowed. The file was opened. The macros ran. The malware called\u00a0home.<\/sup><\/figcaption><\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Step 6\u200a\u2014\u200aIdentify and Contain the Endpoint<\/h3>\n\n\n\n

Use the source IP from the log management results to find the endpoint in Endpoint Security. The internal IP traces back to the device LarsPRD\u200a\u2014\u200aLars\u2019s workstation.<\/p>\n\n\n\n

Review the endpoint\u2019s command history before containment. The CMD history on LarsPRD confirms regsvr32 execution\u200a\u2014\u200amatching exactly what the AnyRun sandbox predicted would happen. Browser history and network connections show sustained communication with the malicious domains.<\/p>\n\n\n\n

\"\"
Endpoint security confirms regsvr32 execution on LarsPRD, matching exactly what AnyRun predicted. Endpoint contained\u200a\u2014\u200aisolated from the network, state preserved for forensics.<\/sup><\/figcaption><\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Contain the machine immediately. Containment in an endpoint management tool cuts the device off from the network while preserving its state for forensics. Don\u2019t wipe it. Don\u2019t reimage it yet. The device is evidence. Isolate it, document what you found, and preserve the artifacts for the post-incident investigation.<\/p>\n\n\n\n

Step 7\u200a\u2014\u200aArtifacts and Verdict<\/h3>\n\n\n\n

Document your artifacts. In incident response, an artifact is any piece of evidence generated during the incident\u200a\u2014\u200afile hashes, IP addresses, domains, process names, registry entries. These are logged for threat intelligence, for the post-incident report, and to ensure that other alerts referencing the same indicators are correctly correlated.<\/p>\n\n\n\n

Artifacts from this investigation:<\/p>\n\n\n\n

SMTP server: 24.213.228.54<\/p>\n\n\n\n

Sender: trenton@tritowncomputers.com<\/p>\n\n\n\n

Attachment hash (ZIP): 11f44531fb088d31307d87b01e8eabff<\/p>\n\n\n\n

Malicious XLS: research-1646684671.xls<\/p>\n\n\n\n

DLL payloads: iroto.dll, iroto1.dll<\/p>\n\n\n\n

C2 domain 1: nws.visionconsulting.ro<\/p>\n\n\n\n

C2 domain 2: royalpalm.sparkblue.lk<\/p>\n\n\n\n

Compromised device: LarsPRD<\/p>\n\n\n\n

Malicious process: regsvr32.exe loading iroto.dll \/ iroto1.dll<\/p>\n\n\n\n

Verdict: True Positive.<\/p>\n\n\n\n

The email was a phishing attempt carrying an Excel 4.0 macro payload. The file was delivered, opened, and executed. The XLM macros invoked regsvr32 to load two malicious DLLs, which established C2 communication with two external domains. Log evidence confirmed the outbound connections succeeded. The endpoint LarsPRD has been confirmed compromised and contained.<\/p>\n\n\n\n

Why Excel 4.0 Macros Specifically<\/h3>\n\n\n\n

The question worth asking after every incident is: why did this work? Not just technically\u200a\u2014\u200athat part we\u2019ve covered\u200a\u2014\u200abut why did it work when it should have been caught?<\/p>\n\n\n\n

Excel 4.0 macros persist in modern Office not because Microsoft forgot about them, but because removing them would break legitimate legacy workflows. That\u2019s a real operational constraint, and it\u2019s one that attackers actively exploit. VBA macro security controls\u200a\u2014\u200awhich Microsoft has strengthened significantly over the years, and which many organizations configure aggressively\u200a\u2014\u200adon\u2019t apply to XLM macros by default. An organization that locked down VBA macros and felt good about it may have left XLM completely open.<\/p>\n\n\n\n

The regsvr32 technique compounds this. By calling a signed, legitimate Windows binary to do the malicious work, the attack avoids the profile of \u2018malware executing directly.\u2019 The malicious code runs with the permissions of regsvr32, which is trusted by the operating system. Application whitelisting that doesn\u2019t account for signed binary proxy execution won\u2019t stop this.<\/p>\n\n\n\n

The practical takeaway isn\u2019t \u2018trust nothing\u2019\u200a\u2014\u200athat\u2019s not actionable. It\u2019s: know what your defenses actually cover and what they don\u2019t. If your organization restricts VBA macros, verify that XLM macros are also restricted. If you use application whitelisting, check whether it accounts for regsvr32 abuse. The gap between \u2018we have controls\u2019 and \u2018we know what our controls cover\u2019 is exactly where this kind of attack lives.<\/p>\n\n\n\n

MITRE ATT&CK Mapping<\/h3>\n\n\n\n

T1566.001\u200a\u2014\u200aPhishing: Spearphishing Attachment (initial delivery)<\/a><\/p>\n\n\n\n

T1137.001\u200a\u2014\u200aOffice Application Startup: Office Template Macros (XLM macro execution)<\/a><\/p>\n\n\n\n

T1218.010\u200a\u2014\u200aSystem Binary Proxy Execution: Regsvr32 (DLL loading via signed binary)<\/a><\/p>\n\n\n\n

T1055\u200a\u2014\u200aProcess Injection (malicious DLL loaded into legitimate process)<\/a><\/p>\n\n\n\n

T1071.001\u200a\u2014\u200aApplication Layer Protocol: Web Protocols (C2 over HTTP\/S)<\/a><\/p>\n\n\n\n

T1105\u200a\u2014\u200aIngress Tool Transfer (DLL payloads delivered with the initial attachment)<\/a><\/p>\n\n\n\n

Key Takeaways<\/h3>\n\n\n\n