T1137.003: Outlook Forms
Adversaries may abuse Microsoft Outlook forms to obtain persistence on a compromised system. Outlook forms are used as templates for presentation and functionality in Outlook messages. Custom Outlook forms can be created that will execute code when a specifically crafted email is sent by an adversary utilizing the same custom Outlook form.[1]
Once malicious forms have been added to the user’s mailbox, they will be loaded when Outlook is started. Malicious forms will execute when an adversary sends a specifically crafted email to the user.[1]
Analyst context for executives and security teams
Outlook Forms persistence matters because it hides inside a normal business application and mailbox workflow rather than a traditional startup folder or service. If an attacker has already compromised a user environment, a malicious custom Outlook form can be loaded when Outlook starts and triggered by a specially crafted email, making email and endpoint evidence both important for investigation and recovery.
Executive priority
Treat this as an Office and identity-adjacent persistence risk for Windows and Outlook-heavy environments. Leaders should ask whether the organization can find unauthorized custom Outlook forms, preserve mailbox and endpoint evidence during an incident, and prove to auditors that Office persistence mechanisms are monitored and remediated. The priority is not only malware prevention; it is validating that SOC, messaging, endpoint, and incident response teams can coordinate on persistence that lives in user mailbox/application configuration.
Technical view
This is ATT&CK T1137.003, a persistence sub-technique under Office Application Startup for Windows and Office Suite. MITRE does not provide official detection text for this object, but the relationship context identifies DET0029, “Detect Persistence via Outlook Custom Forms Triggered by Malicious Email,” and references Microsoft guidance for detecting and remediating Outlook rules/forms attacks plus SensePost NotRuler. SOC teams should validate visibility into Outlook custom forms, mailbox changes, Outlook startup behavior, and suspicious endpoint behavior associated with Outlook-launched code. IR teams should include Outlook forms in persistence checks when investigating compromised mailboxes or Windows endpoints running Outlook.
Likely telemetry
- Mailbox and Exchange/Office 365 configuration evidence related to custom Outlook forms
- Administrative or audit records for Outlook forms, rules, and mailbox modifications where available
- Endpoint process and file activity associated with Outlook starting and loading user mailbox content
- Security tool behavioral alerts for suspicious Outlook child-process or code-execution patterns
- Email evidence for crafted messages that may trigger a malicious custom form
Detection direction
- Confirm whether detections cover Outlook custom forms specifically, not only inbox rules, macros, add-ins, or generic Office execution.
- Use the DET0029 relationship as the ATT&CK-aligned detection strategy to validate: malicious custom form presence, Outlook startup loading behavior, and triggering by email.
- Review Microsoft’s referenced detection and remediation guidance and SensePost NotRuler as source context for blue-team validation, without assuming those tools are deployed or sufficient.
- Tune investigations to correlate mailbox configuration changes with endpoint Outlook behavior; either signal alone may be incomplete.
- Account for false positives from legitimate custom Outlook forms in organizations that use them for business workflows; baseline known forms and owners where possible.
Mitigation priorities
- Prioritize endpoint behavior prevention controls capable of identifying and blocking suspicious process behavior involving Outlook, consistent with mitigation M1040.
- Keep Windows and Office software updated, consistent with mitigation M1051, to reduce exposure to known weaknesses in supported platforms.
- Establish an administrative review and remediation process for unauthorized Outlook custom forms in user mailboxes.
- Include Outlook Forms checks in incident response playbooks for compromised mailbox or Windows endpoint cases.
- Document approved custom Outlook form usage so security teams can distinguish expected business configuration from suspicious persistence.
Analyst notes and limits
The key defensive value is cross-domain validation: this persistence mechanism touches Outlook, mailbox configuration, email delivery, and Windows endpoint behavior. Glexia would use this object to drive readiness questions for managed detection, incident response scoping, Office security hardening, and compliance evidence around persistence monitoring.
The ATT&CK object provides no official detection text and does not supply impact, prevalence, or active exploitation claims. Detection quality depends on local Outlook/Exchange/Office 365 configuration, audit logging, endpoint telemetry, and whether legitimate custom Outlook forms are used in the environment.
Outlook Forms
Adversaries may abuse Microsoft Outlook forms to obtain persistence on a compromised system. Outlook forms are used as templates for presentation and functionality in Outlook messages. Custom Outlook forms can be created that will execute code when a specifically crafted email is sent by an adversary utilizing the same custom Outlook form.[1]
Once malicious forms have been added to the user’s mailbox, they will be loaded when Outlook is started. Malicious forms will execute when an adversary sends a specifically crafted email to the user.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1137 | Office Application Startup | This object subtechnique of Office Application Startup. |
Groups, software, and campaigns
S0358: Ruler
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | 4c8264b6475b… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
SensePost Outlook Forms
Stalmans, E. (2017, April 28). Outlook Forms and Shells. Retrieved February 4, 2019.
Open source URL -
[2]
Microsoft Detect Outlook Forms
Fox, C., Vangel, D. (2018, April 22). Detect and Remediate Outlook Rules and Custom Forms Injections Attacks in Office 365. Retrieved February 4, 2019.
Open source URL -
[3]
SensePost NotRuler
SensePost. (2017, September 21). NotRuler - The opposite of Ruler, provides blue teams with the ability to detect Ruler usage against Exchange. Retrieved February 4, 2019.
Open source URL -
[4]
mitre-attack T1137.003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.