DET0398: Detect Office Startup-Based Persistence via Macros, Forms, and Registry Hooks
DET0398 is a MITRE detection strategy for finding Office startup-based persistence associated with ATT&CK technique T1137, Office Application Startup. The...
Analyst context for executives and security teams
DET0398 is a MITRE detection strategy for finding Office startup-based persistence associated with ATT&CK technique T1137, Office Application Startup. The business significance is that Microsoft Office is common in Windows enterprise environments, so persistence tied to Office startup can let unwanted code reappear when users launch Office applications rather than through more obvious system startup paths. For leaders, the key question is whether SOC, endpoint, and incident response teams can prove they monitor Office persistence locations and changes—not merely whether they collect generic endpoint logs.
Executive priority
Prioritize this as a persistence-resilience and audit-evidence issue for Windows environments using Microsoft Office. It matters because persistence mechanisms can complicate containment, extend dwell time, and create gaps between endpoint hardening, user productivity tooling, and SOC visibility. Security leaders should ask whether controls and monitoring cover Office startup mechanisms, including templates, macros, add-ins, forms, and related registry hooks, and whether incident responders have a repeatable way to validate and remove these artifacts during containment.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T1137, Office Application Startup, under the persistence tactic for Windows and Office Suite. Because the official detection text is not provided, teams should treat DET0398 as a validation prompt: confirm visibility into Office-related startup artifacts, suspicious macro/template/add-in/form changes, and relevant registry modifications that influence Office application startup. Detection engineering should correlate Office application launches with recent changes to Office startup locations or configuration, while IR teams should include these locations in persistence triage and eradication checklists.
Likely telemetry
- Endpoint file creation, modification, and deletion events for Office-related startup, template, macro, add-in, and form locations
- Windows registry change telemetry for Office-related startup or add-in configuration paths
- Process execution telemetry for Microsoft Office applications and child processes
- Endpoint security alerts involving Office macros, add-ins, or startup artifacts
- Asset and software inventory identifying Windows systems with Microsoft Office installed
Detection direction
- Validate that telemetry includes both file-system and registry evidence for Office startup persistence, not just process execution events.
- Tune detections around changes to Office startup artifacts followed by Office application launch activity, while accounting for legitimate administrative software deployment and approved Office customization.
- Review whether monitoring covers user-profile locations as well as system-wide Office configuration, since persistence may be scoped to individual users.
- Use the relationship to T1137 as context for persistence hunting and incident scoping; do not assume impact or attribution from this detection strategy alone.
- Document blind spots where Office telemetry is not collected, macro activity is not logged, or registry monitoring is limited.
Mitigation priorities
- Inventory where Microsoft Office is deployed on Windows systems and confirm which users or tools are authorized to modify Office startup-related artifacts.
- Harden Office macro, add-in, and customization policies according to organizational risk and business requirements.
- Restrict write access to Office startup and configuration locations where feasible, especially for high-risk users and shared systems.
- Ensure endpoint monitoring captures relevant file, registry, and Office process activity needed for persistence detection and response.
- Add Office startup persistence checks to IR containment and eradication procedures so artifacts are removed and not reintroduced after reboot or application launch.
Analyst notes and limits
The ATT&CK object itself has no official description, platforms, tactics, or detection text, so this take relies on the object name and its supplied relationship to T1137. The related technique provides the supported context: Office Application Startup persistence on Windows and Office Suite. Local environment validation is required to determine actual exposure, logging coverage, and control effectiveness.
No official DET0398 detection logic, data source list, analytics, or mitigations were supplied. The relationship description for T1137 is partial. This summary does not claim active exploitation, attribution, or guaranteed detection coverage.
Detect Office Startup-Based Persistence via Macros, Forms, and Registry Hooks
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 detects Office Application Startup. |
All related ATT&CK context
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.0 | Current bundle | dbcfe5711413… |
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]
mitre-attack DET0398Open 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.