How to detect macro and Office document attacks

Threat snapshot

Malicious Office documents remain one of the most effective and widely used initial access delivery mechanisms. They reach victims through phishing emails, arrive as convincing invoice attachments, shipping notifications, or contract documents, and exploit a level of user trust that no technical control has fully neutralized. A user who would never run an unsigned executable will routinely open an Excel spreadsheet or Word document attached to a business email.

The attack vector has evolved substantially over the years. Traditional VBA macro attacks relied on users enabling macros manually. Microsoft's decision to block macros in documents downloaded from the internet (Mark-of-the-Web enforcement) prompted a shift to other techniques: malicious document formats that execute without macros (Excel 4.0 XLM macros, XLL add-ins), template injection that loads a macro-enabled template from a remote URL, and techniques that abuse Office features like DDE (Dynamic Data Exchange) and MSDT (Microsoft Support Diagnostic Tool, the Follina vulnerability). The detection requirement has expanded beyond macro detection alone.

Log360 maps 27 detection rules to macro and Office document attack patterns. The primary detection signal across all these techniques is the same: an Office application spawning a child process that it has no legitimate reason to create. Excel spawning cmd.exe, Word spawning PowerShell, Outlook spawning mshta.exe. These parent-child process relationships are the reliable behavioral signature that remains consistent across macro techniques, exploit-based delivery, and document-based LOLBin abuse.

Macro and Office document attacks, at a glance

How Office document attacks work

VBA macro execution

VBA macros are the original Office attack vector and remain common despite macro blocking improvements. In environments where macros are allowed, or where users are socially engineered into enabling them via fake security prompts in the document content, VBA code runs in the Office application's process context. The macro can execute shell commands through WScript.Shell, PowerShell, or direct Windows API calls, all of which result in a child process being spawned by the Office application. This child process spawning is the primary detection signal.

Security control disabling before macro execution

Before executing their payload, macro attacks often disable Office security controls to prevent subsequent document-triggered detections. The Office Macros Warning Disabled rule detects registry changes that suppress the macro warning prompt. The Microsoft Office Protected View Disabled rule detects Protected View being turned off, which normally sandboxes document content from the local file system. The Microsoft Office Trusted Location Updated rule detects additions to the trusted locations list, which causes Office to run macros in documents from those locations without warning.

Office application spawning MSHTA

One of the highest-confidence Office macro attack signals is an Office application spawning mshta.exe. Legitimate Office applications have no reason to launch the Windows HTML Application Host. When this parent-child relationship appears, it means a macro, exploit, or malicious document feature executed an HTA payload, which is a full scripting environment with Windows API access. Office Product Spawning MSHTA is rated Critical because this combination has essentially no benign explanation.

DLL sideloading via Office

Office applications can be made to load attacker-controlled DLLs through DLL sideloading, placing a malicious DLL with the same name as a legitimate Office dependency in a directory that the Office application searches before the system32 directory. The Microsoft Office DLL Sideload rule detects DLL loading patterns from unexpected paths in the context of Office application processes.

Outlook macro persistence

Beyond document-based macro delivery, Outlook supports macro-based persistence through the ThisOutlookSession module, which runs on Outlook startup. Attackers who have achieved code execution on a host may create an Outlook macro that runs every time the user opens Outlook, providing persistent code execution without any scheduled task or registry run key. The New Outlook Macro Created, Suspicious Outlook Macro Created, and Outlook Macro Execution Without Warning Setting Enabled rules target this persistence vector.

Real-world campaigns

Emotet: Office macro delivery for botnet enrollment

Emotet was one of the most prolific users of malicious Office document delivery, distributing macro-enabled Word documents through hijacked email threads to increase their perceived legitimacy. When the macro ran, it spawned PowerShell or cmd.exe to download and execute the Emotet loader. The Office-spawning-PowerShell parent-child relationship was a consistent detection signal across all Emotet macro delivery variants.

APT28/Fancy Bear: macro-based initial access against government targets

APT28 has used macro-enabled Office documents as an initial access vector in targeted campaigns against government and defense targets, delivering custom implants through VBA macros that spawned PowerShell download cradles. Their documents used social engineering to encourage macro enablement and used mshta.exe as an execution intermediary to reduce direct PowerShell process creation visibility.

Qakbot: macro delivery transitioning to XLL and OneNote

Qakbot evolved its delivery mechanism through multiple transitions as Microsoft tightened macro controls: from password-protected macro documents, to XLL Excel add-ins that execute without a macro warning, to malicious OneNote files with embedded executables. Each transition maintained the same fundamental pattern of an Office application spawning unexpected child processes, keeping the behavioral detection signal consistent even as the specific file format changed.

Business impact

• Office document attacks exploit user trust rather than technical vulnerabilities: Even technically aware users can be deceived by well-crafted spearphishing documents that appear to come from trusted colleagues or business partners. No technical email filtering control eliminates this risk entirely because some malicious documents will always appear legitimate enough to open.
• The initial access vector often determines the attacker's capability within the environment: A macro that runs in the context of a standard user account delivers different post-exploitation capability than one running in an admin context. Early detection at the macro execution stage, before privilege escalation, limits the attacker to the user's existing permissions.
• Macro-based attacks are the primary delivery mechanism for banking trojans, information stealers, and ransomware loaders: Emotet, Qakbot, Trickbot, and their successor families all use Office document delivery as their primary initial access vector. Detecting the document execution stage catches these families before they have established persistence or moved laterally.

Detecting macro and Office document attacks with Log360

Office document attack detection relies on Windows Security Event 4688 with command-line capture or Sysmon Event 1. The parent-child process relationship (Office application spawning cmd.exe, PowerShell, etc.) is only visible if the parent process name is captured in process creation events. Registry events must also be collected to detect the security control disabling rules.

Attack chain visibility

Investigation playbook

Step 1: Identify the document and the delivered payload

• From the process creation event showing the Office application as parent, work backward to identify the document that was open at the time. Email metadata in Outlook logs or the file path of the opened document provides the document name and origin. Quarantine and analyze the document to understand the full attack chain.
• Capture the full command line of the child process spawned by the Office application. This command line is the macro payload and may be a download cradle, a LOLBin invocation, or a direct process injection command. The command line determines the response priority and the subsequent investigation path.
• Query all other endpoints in the environment for similar parent-child process patterns (same Office parent spawning the same child process type) in the same time window. Phishing campaigns deliver the same document to multiple recipients. Identifying all affected hosts requires searching beyond the initial alert host.

Step 2: Determine scope and persistence

• Check whether the macro execution resulted in persistence creation (scheduled task, registry run key, service installation). If persistence was established, the attacker's foothold survives a reboot and must be removed explicitly.
• Check Outlook macro rules (New Outlook Macro Created, Suspicious Outlook Macro Created alerts) on the affected host for the same time window. If an Outlook persistence macro was created, it runs every time Outlook opens regardless of whether the original document is deleted.

Response and remediation

Immediate actions

• Block the document hash at the email gateway and endpoint security layers immediately: Phishing campaigns deliver the same document to multiple recipients. Blocking the document hash prevents additional users from opening it. Report the document hash to your email security vendor's threat intelligence feed.
• Enforce Mark-of-the-Web macro blocking via Group Policy if not already active: Microsoft's MOTW macro blocking prevents VBA macros from running in documents that were downloaded from the internet. This is the single most impactful configuration change for reducing macro-based initial access, and it has been available in current Office versions since 2022.
• Audit Office trusted locations and remove any entries that were not explicitly authorized: Microsoft Office Trusted Location Updated alerts indicate an attacker may have added a path to make future macro delivery to that path silent. Remove unauthorized trusted locations and review who has the permissions to modify this setting.