AN0138: Analytic 0138
Malicious Office add-ins loaded via VSTO, COM, or VBA auto-load paths. Upon launch of Word/Excel/Outlook, the add-in executes code without user action. Add-in resides in trusted directory or registered via Office COM/VBE subsystem. Behavior includes unsigned add-in execution, anomalous load context, or add-in spawning interpreter process.
Analyst context for executives and security teams
This analytic matters because Office add-ins can turn routine Word, Excel, or Outlook launches into automatic code execution without an additional user click. For leaders, the risk is not just “malicious macros”; it is persistence and execution through trusted Office extension paths that may blend into normal productivity tooling.
Executive priority
Prioritize this as an Office endpoint and identity-adjacent resilience issue: if malicious or unsigned add-ins are allowed to load from trusted locations or COM/VBE registration paths, users can repeatedly trigger attacker-controlled code during normal business activity. Executives should ask whether the organization can inventory Office add-ins, distinguish approved business add-ins from untrusted ones, and produce audit evidence for add-in governance and monitoring.
Technical view
SOC and detection teams should validate visibility into Office add-in loading across Word, Excel, and Outlook on Office Suite platforms. Focus on VSTO, COM, and VBA auto-load paths; unsigned add-in execution; anomalous load context; and Office applications spawning interpreter processes. Because the official detection field is not provided, detection engineering should treat this as a validation target rather than a ready-made rule.
Likely telemetry
- Office application process execution for Word, Excel, and Outlook
- Loaded Office add-in metadata, including VSTO, COM, and VBA/VBE-related add-ins where available
- File path and signing information for add-ins loaded from trusted or auto-load directories
- Registry or configuration evidence for Office COM/VBE add-in registration
- Process child relationships where Office applications spawn interpreter processes
Detection direction
- Baseline approved Office add-ins by application, publisher/signature status, path, and business owner.
- Alert or hunt for unsigned add-ins, newly introduced add-ins, or add-ins loading from unusual contexts relative to the local baseline.
- Correlate Office add-in load events with child process creation, especially interpreter processes spawned by Word, Excel, or Outlook.
- Tune for legitimate enterprise add-ins to reduce false positives; many organizations use business-critical COM or VSTO add-ins.
- Check for blind spots where add-in inventory, registry monitoring, code-signing metadata, or Office child-process telemetry is incomplete.
Mitigation priorities
- Establish and maintain an approved Office add-in inventory with ownership and business justification.
- Restrict Office add-in loading to trusted, approved sources and review trusted directory usage.
- Prefer signed and managed add-ins where feasible, and investigate unsigned add-ins that are not explicitly approved.
- Use endpoint/application control policy to reduce unauthorized Office extension execution where operationally practical.
- Include Office add-in checks in incident response triage when Office applications launch unexpected child processes.
Analyst notes and limits
This object is a detection analytic, not a technique description, and it has no supplied relationships or official detection logic. The value for defenders is in translating the described behavior into telemetry validation: add-in load visibility, signing/path context, registration evidence, and Office child-process monitoring.
No tactic, relationship context, detailed detection procedure, mitigation text, or affected non-Office platforms were supplied. Local add-in baselines and business-approved software lists are required before determining suspiciousness or coverage.
Analytic 0138
Malicious Office add-ins loaded via VSTO, COM, or VBA auto-load paths. Upon launch of Word/Excel/Outlook, the add-in executes code without user action. Add-in resides in trusted directory or registered via Office COM/VBE subsystem. Behavior includes unsigned add-in execution, anomalous load context, or add-in spawning interpreter process.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 3d461ddfd8fd… |
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 AN0138Open 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.