MITRE ATT&CK T1137 Office Application Startup: Detecting and Removing Persistence

Office and Outlook load templates, registry hooks, rules, forms and folder views every time they start, and each of those can be turned into a persistence point that survives reboots, password resets and even a new laptop. MITRE ATT&CK records this as T1137 Office Application Startup in the Persistence tactic (ATT&CK v20, platforms Windows and Office Suite), with six sub-techniques. Add-ins (T1137.006) already have their own page, the Malicious Office Add-ins Guide, so this guide concentrates on the other five: template macros, the Office Test registry key, Outlook forms, Outlook Home Page and Outlook rules. It covers how each one persists, where it lives, the v20 detection analytics, the settings that close it and how to remove it cleanly. It is for endpoint engineers, Microsoft 365 administrators and incident responders, and contains no attack procedures.

Key takeaways

• Mailbox persistence follows the user, not the device. Microsoft notes that reinstalling Outlook or replacing the computer does not remove malicious rules or forms, because they sync back from the mailbox.
• Macro blocking does not cover the Outlook methods. ATT&CK states the Visual Basic engine behind Outlook rules, forms and Home Page is separate from the macro engine, so patches and client settings are the control.
• Office Test is a registry-only DLL hook. The key is not created by default, so any value under Office test\Special\Perf deserves investigation.
• Two child-process ASR rules cover most of the payoff. Blocking Office and Outlook from creating child processes stops the most common follow-on step for every sub-technique.
• Clean-up is a mailbox and endpoint job together. Remove the artefact, reset credentials, revoke sessions and confirm on every device the user signs in from.

The six sub-techniques at a glance

ATT&CK v20 links Gamaredon Group and APT32 to the parent technique, MuddyWater to template macros, APT28 to Office Test and OilRig to Outlook Home Page. See the Gamaredon Group Threat Actor Profile Guide. The Outlook methods usually start with stolen credentials: the adversary signs in to the mailbox, plants the rule, form or Home Page, and then needs only to send an email to regain execution.

Template macros and the Office Test key

Template macros (T1137.001)

ATT&CK describes VBA macros inserted into the base template that loads each time Word or Excel starts. Word creates Normal.dotm in %APPDATA%\Microsoft\Templates by default; Excel has no default template, but a PERSONAL.XLSB placed in the XLSTART folder loads automatically. Adversaries may also redirect the template through the GlobalDotName registry value or search order hijacking, and may need the template to sit in a trusted location before its macros run without a prompt.

• Macro policy: Microsoft's "VBA Macro Notification Settings" policy (named "Macro Notification Settings" for Excel) with "Disable all except digitally signed macros" and "Require macros to be signed by a trusted publisher" is the Microsoft 365 Apps security baseline recommendation where macros cannot be disabled outright. A template written locally on the device does not normally carry Mark of the Web, so internet macro blocking alone is not enough for this sub-technique.
• Trusted locations: Microsoft advises against network trusted locations and warns that anyone who can write to a trusted location can add macros. Keep trusted locations few, local and writable only by administrators. See the Office Macro Blocking Guide.
• Trusted publishers: deploy signing certificates centrally and stop users adding publishers themselves; Microsoft notes trusted publishers apply across Windows.

Office Test (T1137.002)

The Office Test key lets a DLL load whenever an Office application starts. ATT&CK notes the key is not created during installation and maps M1054 Software Configuration: create the key yourself and set its permissions to Read Control so it cannot be changed without administrator rights. Because the DLL loads without any macro prompt, DET0315 flags this as a route that sidesteps macro defences.

Outlook rules, forms and Home Page

All three Outlook methods store their payload in the mailbox and execute through Outlook's own scripting, which is why ATT&CK says blocking macros may be ineffective. Microsoft states that current Outlook clients block both the rules and forms mechanisms by default.

Attackers who can run code on the client can set EnableUnsafeClientMailRules back to 1, so Microsoft recommends using Group Policy to monitor and enforce the value. For on-premises Exchange, Microsoft suggests blocking unpatched Outlook versions with Outlook client blocking. Rules that forward or hide mail rather than execute code are a different technique; see the MITRE ATT&CK T1564.008 Hide Artifacts and the T1114 Email Collection Defensive Guide.

Prevention controls, setting by setting

Microsoft notes that the child-process ASR rules are enforced only when Office is installed in %ProgramFiles% or %ProgramFiles(x86)%, so check installation paths before relying on them.

Choosing controls by organisation size

• Small organisations on Microsoft 365: keep Outlook on a supported update channel, turn on the two child-process ASR rules in audit mode and then block, and review inbox rules monthly with the read-only investigation script Microsoft provides.
• Large or regulated estates: add Office Test key lockdown, template integrity monitoring for Normal.dotm and XLSTART, Group Policy enforcement of the Outlook security values, and SIEM detections on both endpoint and mailbox audit data.
• Estates with legacy macros: sign the business-critical macros, deploy the certificate as a trusted publisher and move to "Disable all except digitally signed macros" rather than leaving notification prompts that users click through.

Detection

High-value detection logic

• Outlook or Word spawning interpreters: outlook.exe, winword.exe or excel.exe as parent of powershell.exe, mshta.exe, wscript.exe or rundll32.exe. ASR audit telemetry gives the same signal through advanced hunting action types such as AsrOfficeCommAppChildProcessAudited and AsrOfficeChildProcessAudited.
• Any write to the Office Test key: the key does not exist by default, so any creation is high fidelity.
• Template modification outside Office: Normal.dotm or files in XLSTART written by a process other than the Office application, or a change to GlobalDotName.
• Rule changes after a risky sign-in: Microsoft Purview mailbox auditing records rule additions, removals and changes as UpdateInboxRules for owner, delegate and admin sign-ins by default. Correlate with sign-ins from new locations. See the Microsoft 365 Unified Audit Log Guide for Detection.
• Audit still on: confirm Get-OrganizationConfig shows AuditDisabled as False; adversaries and well-meaning admins can both turn it off.

Metrics

• Percentage of Windows endpoints with both child-process ASR rules in block mode.
• Number of Outlook builds in use below the patched versions, target zero.
• Endpoints where EnableUnsafeClientMailRules is 1, target zero.
• Number of custom forms and rules with application actions found per tenant sweep, and time to remove them.
• Percentage of endpoints where the Office Test key is pre-created and locked.

Rolling out the controls

1. Baseline: run Microsoft's read-only Get-AllTenantRulesAndForms.ps1 (after updating its connection method, as Microsoft notes) to list rules with ActionType ID_ACTION_CUSTOM and every custom form. Inventory Outlook builds and the registry values above.
2. Audit mode: deploy the four Office ASR rules in audit for two to four weeks and review audited events by application and user.
3. Exclude narrowly: add per-rule exclusions for named, signed binaries only; avoid folder-wide exclusions.
4. Block in rings: move IT first, then general staff, then specialist groups that rely on automation, checking help desk volume at each ring.
5. Lock registry values: enforce the Office Test key permissions and the Outlook security value through Group Policy or Intune, with monitoring for drift.
6. Roll back: each ASR rule can be returned to audit individually; keep the change record so a single rule can be relaxed without disabling the rest.

Removal and response

1. Scope the mailbox: list rules with Get-InboxRule, inspect suspects with Format-List, and disable with Disable-InboxRule while you investigate; remove with Remove-InboxRule. Inspect custom forms in the Inbox and Personal Forms Library.
2. Clean every device: Microsoft advises identifying every device where the user ran Outlook and keeping the user signed out until each is clean, and reimaging where malware is possible.
3. Clean the endpoint artefacts: restore a known-good Normal.dotm, remove unexpected XLSTART files, delete the Office Test value and quarantine the DLL it pointed to.
4. Reset the identity: reset the password, revoke sessions, review MFA methods and remove offline mailbox copies, as Microsoft recommends. See the Microsoft 365 Tenant Compromise Playbook.
5. Hunt wider: search all mailboxes for the same rule name, trigger subject or form class and all endpoints for the same DLL hash.

Where identity fits

The Outlook sub-techniques are identity persistence as much as endpoint persistence: they need only a mailbox sign-in to plant and survive device rebuilds. Shared and service mailboxes that nobody reads are attractive targets, because rule changes go unnoticed. Give every shared mailbox an owner, block interactive sign-in where it is not needed, and include rule and form review in access reviews.

Framework mapping

Common failure patterns

• Rebuilding the laptop and stopping there: rules and forms return from the mailbox on the next sign-in.
• Assuming macro blocking covers Outlook: the Outlook methods use a separate engine and need their own updates and settings.
• ASR rules left in audit: the pilot never moves to block, so detections fire but nothing is stopped.
• Office installed outside Program Files: the child-process ASR rules are not enforced for those installations.
• Writable trusted locations: a network share marked trusted lets any writer add template macros that run without a prompt.

Practitioner checklist

• Inventory Outlook builds and bring every client to a version that blocks the rules, forms and Home Page methods.
• Enforce EnableUnsafeClientMailRules absent or 0 and alert on change.
• Pre-create the Office Test key with Read Control permissions and monitor it.
• Deploy the Office and Outlook child-process ASR rules, then block after audit.
• Set macro policy to signed-only or disabled and keep trusted locations local and admin-writable.
• Monitor Normal.dotm, XLSTART and GlobalDotName for changes.
• Sweep the tenant for custom forms and rules with application actions on a schedule.
• Include mailbox artefact removal and every-device clean-up in the account compromise runbook.

Standards and references

• MITRE ATT&CK: Office Application Startup (T1137)
• Microsoft Learn: Detect and remediate Outlook rules and custom forms injections attacks
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Macros from the internet are blocked by default in Office
• Microsoft Learn: Manage mailbox auditing
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Malicious Office Add-ins Guide · Office Macro Blocking Guide · Persistence Techniques Guide · MITRE ATT&CK T1564.008 Hide Artifacts · Microsoft 365 Tenant Compromise Playbook