Microsoft Office is on most Windows desktops in a company. That makes it a good place to hide something that needs to run again after a reboot. T1137, Office Application Startup, covers the ways an adversary can use Office-based applications for persistence between startups.
MITRE lists persistence as the tactic and Windows and Office Suite as the platforms. Six sub-techniques cover the specific mechanisms, and this post gives the overview.
How attackers use it
MITRE describes multiple mechanisms that run when an Office application starts, including Office template macros and add-ins. A variety of Outlook features can also be abused, namely rules, forms and the Home Page. These work inside Outlook or through Office 365.
The six sub-techniques:
- Office Template Macros (T1137.001). A macro placed in a base template, such as Word's
Normal.dotm, runs each time the application starts. - Office Test (T1137.002). A registry key lets a DLL load whenever an Office application starts.
- Outlook Forms (T1137.003). Custom forms in the mailbox run code when a specially crafted email arrives.
- Outlook Home Page (T1137.004). A legacy feature loads a URL for a folder, and a crafted page can run code.
- Outlook Rules (T1137.005). A rule runs code when a crafted email arrives.
- Add-ins (T1137.006). Add-in types can run code at application start.
What they share is a trigger tied to normal use. Opening Word or Outlook is enough, and some Outlook methods fire when an attacker sends a crafted message. The pages list APT32 and Gamaredon Group as users of the family.
How to detect it
MITRE gives two detection angles. One looks for persistence through Office template macros, Outlook forms, rules or the home page, or through registry-persistent scripts. In that picture the adversary modifies registry keys or Office application directories so that scripts load at startup. The other covers startup mechanisms like template macros and home page redirects that are configured through internal automation or client-side settings, so unusual changes stand out against what your own tooling sets.
In practice:
- Registry. Watch for changes under Office registry paths, including the Office test key and template settings (Sysmon event IDs 12 and 13 cover registry creation and value sets).
- Files. Watch for writes to Office template and add-in locations (Sysmon event ID 11).
- Processes. Office applications that spawn scripting engines, shells or unusual children. For Outlook this is the strongest signal for rules, forms and home page abuse.
How to reduce the risk
MITRE lists several mitigations:
- Disable what you do not need. Follow Office macro security best practices, disable VBA macros from executing, and disable Office add-ins. If add-ins are required, require them to be signed and turn off user notification for allowing add-ins. MITRE adds that for some add-in types (WLL and VBA) more mitigation is likely needed.
- Block child processes. On Windows 10, turn on Attack Surface Reduction rules that stop Office applications from creating child processes and from writing potentially malicious executable content to disk.
- Patch for the Outlook methods. Blocking macros may not help, because the Visual Basic engine behind these Outlook features is separate from the macro scripting engine. MITRE points to Microsoft patches addressing each issue, including KB3191938, which blocks Outlook Visual Basic and shows a malicious code warning.
- Protect the Office Test key. MITRE advises creating the registry key used by that method and setting its permissions to Read Control, so it cannot easily be modified without administrator rights.
Check your own environment
Confirm the ASR rule for Office child processes is on, using PowerShell on Windows:
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
The rule "Block all Office applications from creating child processes" has the ID D4F940AB-401B-4EFC-AADC-AD5F3C50688A. An action value of 1 means block.
Check whether the Office Test key exists. By default it should not:
reg query "HKCU\Software\Microsoft\Office test\Special\Perf"
reg query "HKLM\Software\Microsoft\Office test\Special\Perf"
For Exchange Online mailboxes, list Outlook rules for an account you want to review:
Get-InboxRule -Mailbox someone@yourcompany.com | Format-List Name, Enabled, Description
Then ask: do you know which Office add-ins are approved? Is macro policy set centrally? Does your endpoint product alert when Outlook starts a shell?
Quick check
Why might blocking macros not stop the Outlook methods?
The Visual Basic engine used by Outlook rules, forms and home page is separate from the macro scripting engine, so macro blocking does not cover it.
Which behavior is the strongest generic signal across these methods?
An Office application launching an unusual child process, such as a script interpreter or shell.
Sources
- MITRE ATT&CK, T1137 Office Application Startup
