Office Application Startup is the automatic launch of code when a Microsoft Office application opens, often through templates, add-ins or macro-enabled documents. Attackers use it for execution and persistence through malicious documents or add-ins. Defenders should restrict macros, inspect startup locations and monitor unusual Office child processes.
What Office Application Startup Means
Office Application Startup is the automatic launch of code when a Microsoft Office application opens, often through templates, add-ins or macro-enabled documents. It is a startup execution path, not just a document feature, and it matters because code can begin running before users fully realise a file has introduced new behaviour.
Because the launch point is tied to normal Office workflows, attackers value it for persistence and for opening a route to execution through trusted productivity software. The security question is not whether Office can run extensions, but which startup paths are allowed, which sources are trusted, and how much code can run without user scrutiny.
Where Office Startup Code Runs
Startup code can be introduced through document templates, add-ins, automation hooks, and other locations that Office loads automatically at application start. Those locations are attractive because they often blend into ordinary desktop behaviour, especially where users expect Office to open documents, load personal templates, or initialise extensions.
The risk is not limited to macros alone. Any mechanism that causes Office to load code at startup can become a foothold, including file-based template abuse, add-in abuse, and malicious content placed in trusted locations that Office checks every time it opens.
Why Attackers Abuse It
Attackers prefer Office Application Startup because it combines execution with persistence. Once malicious code is loaded automatically, the payload can survive reboots and repeated application launches without needing the user to click again.
The technique is especially useful when paired with phishing or document delivery. A malicious file may only need to be opened once, after which the startup path continues the compromise. That makes it a durable execution method for adversaries who want repeated access, staging, or follow-on payload delivery.
For a broader map of persistence methods, Persistence Techniques Guide is useful because Office startup abuse sits alongside other autostart and logon mechanisms.
Security Implications for Defenders
Defenders should treat Office startup paths as part of the endpoint attack surface. The most important control problem is separating legitimate automation from untrusted code that loads silently when Office opens. That usually means limiting macro execution, reducing add-in sprawl, and knowing exactly which startup locations are expected in the environment.
Monitoring is just as important as prevention. Unexpected Office child processes, unusual template loads, and new or modified startup artefacts can indicate abuse. Reviewing those signals alongside document provenance and user behaviour helps distinguish normal productivity activity from an execution chain that began inside Office.
For attacker tradecraft context, the MITRE ATT&CK Enterprise Matrix helps place Office startup execution within persistence and execution techniques.
Risk and Threat Considerations
Office startup abuse is risky because it lets malicious code inherit trust from common business software. A compromised template, add-in, or macro-enabled document can create durable execution with very little visible friction, especially where users have broad trust in Office files and the startup path is rarely inspected.
Failure mechanism: An attacker places or modifies a startup artefact that Office loads automatically, then uses that autoload path to execute code and keep it running across future launches.
Impact: The result can be persistence, repeated payload execution, credential theft, lateral movement, and a harder-to-detect compromise because the malicious code starts from a normal application launch path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.012 — Boot or Logon Autostart Execution: Office Template Macros | Office startup code is a persistence/autostart technique. |
| Recommendation — Map Office autostart artefacts to T1547.012 and hunt for unexpected template-loading activity. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Office startup abuse often rides through add-ins and template-based software components. |
| CIS-8 — Audit Log Management | Detection depends on reviewing process creation and Office startup behaviour. | |
| Recommendation — Inventory Office add-ins and startup locations, then remove unapproved software components. Log and review Office child processes and startup-related events for unusual execution patterns. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Malicious startup code alters trusted Office execution paths and should be checked for integrity. |
| Recommendation — Validate Office startup artefacts and block unauthorized code from trusted loading paths. | ||
| OWASP ASVS | V13 — Configuration | Startup hooks, add-ins, and macro settings are configuration decisions that affect execution trust. |
| Recommendation — Harden Office configuration to restrict auto-loaded code and untrusted extensions. | ||
Practitioner Guidance
Why practitioners should care: This term is operationally important because startup execution happens early, often before users notice unusual behaviour. Security teams should know which Office loading points are approved and which are not, because undocumented startup paths are a common place for abuse to hide.
What to watch for: Focus on unexpected add-ins, template changes, macro-enabled documents from untrusted sources, and Office processes that spawn unusual child activity. Those signals often matter more than the document itself, because the real risk is the code that gets loaded automatically after open.
When a startup path is not essential, remove it rather than simply warning users about it. Where startup automation is needed, keep it narrowly scoped and reviewed so that convenience does not become a standing execution channel.