The main warning signs are an Office customisation prompt, a request to install an add-in, and network retrieval of VSTO manifests or assembly files from a remote location. If the document loads without a prompt because the publisher is trusted, that can be a sign the control boundary has shifted from user approval to policy trust.
How VSTO Execution Becomes Visible Before Office Hands Off Control
VSTO payloads become easier to spot when Office transitions from simple document rendering into add-in loading. The most useful signals are not the code itself, but the handoff points: a customisation dialog, a prompt to install or enable an add-in, and outbound retrieval of a manifest or assembly from a remote path. That matters because the user is no longer only opening a file. Office is being directed to trust and load executable content.
One practical indicator is whether the document is trying to establish an add-in relationship instead of remaining a passive file. If the process begins resolving remote XML manifests, assembly references, or trust-related prompts, the execution path is already underway even if the code has not yet run. For defenders, this is a boundary question as much as a malware question. In practice, many security teams first notice VSTO execution only after Office has already shifted from document handling into add-in loading, rather than during the earlier trust decision.
For control context, NIST SP 800-53 Rev. 5 is useful because it frames how organisations should govern software execution, trusted content, and boundary conditions around code loading. NIST SP 800-53 Rev 5 Security and Privacy Controls
What Happens During the Office-to-VSTO Handoff
VSTO is not a normal macro chain. It relies on Office recognising a document or template as associated with a managed add-in or solution, then resolving the supporting manifest and assembly needed to load that solution. The important practical distinction is that execution often depends on trust decisions made before code starts. Those decisions may involve publisher trust, policy-based trust, or a user-facing installation prompt, and each one changes what the operator should expect to see.
From an analyst perspective, the visible path usually includes one or more of these events:
- Office displays a customisation prompt or installation request.
- The application attempts to retrieve a deployment manifest from a remote location.
- Office resolves .dll or related assembly content that is not embedded in the document itself.
- The process proceeds without a user prompt because a trust decision has already been satisfied by policy or certificate.
The most reliable observation point is not the document contents alone but the combination of UI behaviour, file access, and network activity. A benign document may still reference external resources, but a VSTO payload that is about to run tends to show a clear sequence: trust decision, manifest resolution, then assembly loading. If telemetry is available, that sequence is usually more informative than any single alert. It also helps distinguish VSTO from other Office-based techniques that rely on macros, embedded objects, or plain link following. Where visibility breaks down is when trusted publisher policy suppresses prompts and the add-in loads quietly, because the most obvious user-facing warning never appears.
When the Same Warning Means Different Things
Tighter trust enforcement often improves visibility, but it also creates more prompts and more chances for users to accept content they do not understand, so teams have to balance friction against assurance. A prompt is not always malicious, and the absence of a prompt is not always safe.
One edge case is signed content from a trusted publisher. In that situation, the usual warning signs may be reduced or absent, because the execution boundary has moved from user judgement to policy and certificate trust. That is helpful for legitimate enterprise add-ins, but it also means defenders need to monitor trust decisions and provenance, not just prompts. Another variation is remote manifest hosting. Sometimes the manifest path is part of a legitimate deployment model, which means the deciding factor is not “remote equals bad” but whether the source, signing chain, and expected deployment pattern are consistent with the organisation’s policy.
Another common point of confusion is that VSTO execution can look like ordinary add-in behaviour from the user’s perspective. The difference is that a payload may be engineered to trigger loading at document open or first interaction, so the user sees a normal Office workflow while the process is already preparing code execution. This is why validation should include both trust state and network destination reputation. For defensive purposes, the sign that matters most is a change in control boundary, not just the presence of an Office prompt.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management | Trust and add-in loading depend on authorised execution paths. |
| PR.PT-5 — Resilience of Operating Environment | Office add-ins alter the execution boundary and loading behaviour. | |
| Recommendation — Enforce authorised trust paths for Office add-ins before allowing execution. Monitor Office execution boundaries for unexpected add-in activation. | ||
| CIS Controls v8 | 6.3 — User Application Hardening | Office is the application surface where VSTO loading is initiated. |
| Recommendation — Harden Office application settings to limit unapproved add-in execution. | ||
| MITRE ATT&CK | T1137 — Office Application Startup | VSTO payloads leverage Office startup and add-in loading behaviour. |
| T1027 — Obfuscated Files or Information | Remote manifests and assemblies may be used to stage payload execution. | |
| Recommendation — Hunt for Office startup and add-in-loading activity that precedes code execution. Inspect staged manifests and assemblies for unusual retrieval and packing patterns. | ||
Practitioner Guidance
What to prioritise: Treat the trust decision and the manifest fetch as the key checkpoints, not the final code load. If telemetry only records process start and file open, it will miss the moment when Office crosses into add-in execution.
What to verify: Confirm whether the add-in source, signing chain, and retrieval path match an approved deployment pattern. If the payload depends on a remote manifest, the hosting location and certificate trust path should be explicitly expected, not merely tolerated.
Decision rule: If the document opens with a prompt, investigate the trust basis; if it opens without a prompt, verify whether policy or publisher trust explains the silent load. Silent execution is often the harder condition to detect and the more important one to instrument.
Practitioner takeaway: The most important judgement is that VSTO “about to execute” usually shows up as a trust transition plus external loading behaviour, so teams should measure the handoff, not just the eventual payload.
