Malicious Office Add-ins Guide: XLL, VSTO and Web Add-in Risks and Controls

A malicious Office add-in is an extension to Word, Excel, PowerPoint or Outlook that an attacker uses to run code, keep a foothold or read data, because Office loads add-ins automatically. In plain terms, instead of tricking a user into enabling a macro, the attacker installs a small program that Office itself starts every time the application opens. There are two very different kinds: native add-ins (XLL, COM and VSTO) that run as code on the device, and web add-ins that run in a sandbox but can be granted access to mailboxes, documents and, through OAuth, Microsoft 365 data. This guide explains each type, how abuse works and which Trust Center, Group Policy, Exchange and Microsoft 365 controls reduce the risk. It is for endpoint, Microsoft 365 and identity administrators and SOC analysts, and contains no code.

Key takeaways

• Native add-ins are programs. XLL, COM and VSTO add-ins run with the user's privileges inside the Office process, so the controls that matter are signing, trusted publishers and application control, not macro settings.
• Add-ins are a persistence technique. MITRE ATT&CK lists Office add-ins as Office Application Startup: Add-ins (T1137.006) because they can be set to execute code whenever an Office application starts.
• Require trusted publisher signatures. The Trust Center settings "Require Application Add-ins to be signed by Trusted Publisher" and "Disable notification for unsigned add-ins" stop unsigned native add-ins loading without asking the user.
• Take web add-in installation away from users. By default users can install Office Store add-ins and every user holds the Exchange roles to install Outlook add-ins; admin-managed deployment through Integrated apps is the safer model.
• Web add-ins are an OAuth risk. An add-in that signs users in to Microsoft Entra ID asks for consent to data, so user consent policy and OAuth app governance are part of add-in security.

What it is

Add-ins extend Office: pricing functions in Excel, a CRM button in Outlook. ATT&CK lists the forms that can be abused: Word and Excel add-in libraries (WLL and XLL), VBA add-ins, COM add-ins, automation add-ins, VBA Editor add-ins, Visual Studio Tools for Office (VSTO) add-ins and Outlook add-ins. For defenders they fall into four groups.

The ATT&CK mapping for the whole topic: delivery by Spearphishing Attachment (T1566.001), user execution of a Malicious File (T1204.002), persistence through Office Application Startup: Add-ins (T1137.006), and, for web add-ins that obtain tokens, Steal Application Access Token (T1528).

How it works

Native add-ins as a delivery route

When Microsoft blocked internet macros by default in 2022, attackers looked for other file types Office would run. An XLL is attractive because it is a full native library that Excel loads as an add-in, so opening one from an email or download can run code without any macro. Microsoft's common attachments filter now lists xll, along with ppam, among its default blocked types. Microsoft also documents that Excel and PowerPoint VBA add-ins (.xla, .xlam, .ppa, .ppam) that carry Mark of the Web load in a disabled state, and that trusting a digital signature does not override this for Excel add-ins. That Microsoft Learn page does not cover XLL files, and we could not confirm from Microsoft documentation how current Excel builds treat an XLL that arrives from the internet. Do not rely on any default: enforce the controls below explicitly and test the behaviour on your own Excel builds and channels. See the Macro Malware Guide and the Office Macro Blocking Guide for the macro side.

Native add-ins as persistence

Once an attacker can run code on a device, registering a COM or VSTO add-in, or dropping an add-in into a location Office loads at start, gives a foothold that restarts with every Outlook or Excel launch and lives inside a trusted, signed Office process. COM add-ins are registered per application under the Office Addins registry keys in HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE, so a new key there written by anything other than an installer is worth investigating. See also Component Object Model (T1559.001).

VSTO trust

Microsoft documents that VSTO application and deployment manifests must be signed with a certificate identifying the publisher. A solution signed with a certificate in the client's Trusted Publishers store installs without a prompt; otherwise ClickOnce asks the user, and if the user agrees an inclusion list entry storing the URL and public key means the solution never prompts again. Administrators can disable the prompt, or allow it only for Authenticode-signed solutions, separately for the MyComputer, LocalIntranet, Internet, TrustedSites and UntrustedSites zones.

Web add-ins

Web add-ins are much more constrained. Microsoft states that they run in a sandboxed iframe or a separate add-in runtime process, cannot use ActiveX or install DLL or EXE files, and are limited to the permissions declared in their manifest, which users see before installing. Outlook add-ins that request read/write mailbox permission need an administrator to install. The risks are different in kind:

• Data access within permissions: a read/write document or mailbox add-in can read and change everything it was granted.
• Changing back end: Microsoft notes that the web application behind an add-in can change at any time, even when the manifest and its permissions do not. An add-in approved last year may load different code today.
• OAuth consent: add-ins that use Microsoft Entra single sign-on are registered applications; on first use the user is asked to consent, and the add-in's server can use the on-behalf-of flow to call Microsoft Graph as the user. A malicious or compromised add-in publisher therefore becomes a consent phishing route. See the Consent Phishing and Illicit OAuth Grants Guide.

Why it matters

Add-ins load automatically and are rarely reviewed. Native add-ins give code execution and persistence that blends into Office; web add-ins give access to mail and documents that can outlive a password reset. See the Malware Guide for how such footholds fit the wider malware picture.

The controls, setting by setting

Office ASR rules add a behavioural layer for native add-ins as well as macros: "Block all Office applications from creating child processes" (d4f940ab-401b-4efc-aadc-ad5f3c50688a), "Block Office applications from creating executable content" (3b576869-a4ec-4529-8536-b80a7769e899) and "Block Office applications from injecting code into other processes" (75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84). Microsoft notes the first and third are enforced only when Office is installed under Program Files. See the Windows Endpoint Hardening Guide and the Application Allowlisting Guide.

Rolling it out

1. Inventory: collect native add-ins from endpoint management or EDR, and web add-ins from the Microsoft 365 admin center and Exchange.
2. Classify: mark each add-in sanctioned or unknown, with an owner.
3. Sign what you keep: sign internal native add-ins with a certificate you control and place only that certificate, plus validated vendor certificates, in Trusted Publishers. See the Code Signing Security Guide.
4. Pilot the Trust Center settings: enable the trusted publisher requirement with silent disabling for a pilot ring, collect breakage reports for two weeks, then widen.
5. Move web add-ins to admin deployment: deploy sanctioned add-ins through Integrated apps to groups rather than Everyone, then clear "Let users access the Office Store" and remove the three Exchange user roles.
6. Tighten consent: switch user consent to verified publishers with low-impact permissions and enable the admin consent workflow.
7. Roll back narrowly: if a business add-in fails, sign it or deploy it centrally for its group; do not re-enable user installs or unsigned add-ins for everyone. Unassigning an add-in in Integrated apps stops access without deleting it.

Small vs large organisations: a small organisation with few add-ins can block the Office Store, remove the Exchange roles and require signed native add-ins in a week. A large organisation needs an add-in register, a vendor certificate validation process, group-based central deployment and application control rules that allow approved XLLs by publisher.

Common misconceptions

• "Blocking macros covers add-ins": macro policy does not govern XLL, COM or VSTO add-ins, which are native code. The add-in Trust Center settings and application control are separate controls.
• "Signed means safe": a trusted publisher certificate makes every add-in it signs load. In the NVIDIA code-signing certificate theft, leaked, already expired certificates were used to sign malware within days.
• "Web add-ins are sandboxed, so they are harmless": the sandbox protects the device, not the data. A mailbox add-in with read/write permission, or an add-in holding a Graph token through consent, can read and change mail as the user.
• "Tightening consent removes risky grants": Microsoft notes consent setting changes affect only future consents. Existing grants to add-in applications remain until reviewed and revoked. See the SaaS and OAuth App Governance Guide.

Related concepts

Detection and measurement

• Add-in registry changes: alert on new keys under the Office Addins registry paths written by processes other than installers or software deployment tools. See the Endpoint Telemetry Guide.
• Native add-in loads: hunt for Excel loading an .xll, or Office loading a DLL, from user-writable paths such as Downloads, Temp or AppData, and for Office processes spawning shells or script hosts (Office ASR ActionTypes AsrOfficeChildProcessBlocked and AsrExecutableOfficeContentBlocked).
• Web add-ins and consent: review Integrated apps and Exchange add-in inventory monthly, and alert on new consent grants to applications with mail or file permissions. See the Entra ID Applications and Consent Guide.

Metrics that show it is working: percentage of devices with the trusted publisher requirement enforced (target 100); number of certificates in Trusted Publishers, each with an owner; percentage of web add-ins deployed centrally rather than user-installed; users still holding the three Exchange add-in roles (target zero outside exceptions); unsigned or unknown native add-ins found per month; consent grants to add-in applications reviewed within 30 days.

Framework mapping

Where identity fits

Two identity objects sit behind add-ins. Trusted publisher certificates are machine credentials: whoever holds the private key decides which code Office runs, so keep signing keys in an HSM or managed signing service and review the Trusted Publishers store like a privileged group. Web add-ins that use single sign-on are Entra applications with client secrets and delegated permissions, so they belong in the same inventory, owner review and credential rotation as any other non-human identity. See also the Malicious LNK Files Guide and HTML Smuggling Guide.

Practitioner checklist

• Enable "Require Application Add-ins to be signed by Trusted Publisher" and "Disable notification for unsigned add-ins" for every Office application by policy.
• Keep Trusted Publishers to certificates you control or have validated, each with an owner and review date.
• Disable the VSTO ClickOnce trust prompt for the Internet and UntrustedSites zones.
• Block .xll, .xlam and .ppam attachments from external senders at the email gateway.
• Clear "Let users access the Office Store" and set the Block the Office Store policy; deploy sanctioned web add-ins through Integrated apps to groups.
• Remove My Marketplace Apps, My Custom Apps and My ReadWriteMailbox Apps from the Default Role Assignment Policy.
• Restrict user consent to verified publishers with low-impact permissions, enable the admin consent workflow and review existing add-in grants.
• Deploy the Office ASR rules in Audit, then Block, and use application control to allow approved XLLs by publisher.

Standards and references

• MITRE ATT&CK: Office Application Startup: Add-ins (T1137.006)
• Microsoft Learn: Privacy and security for Office Add-ins
• Microsoft Learn: Grant trust to Office solutions
• Microsoft Support: View, manage, and install add-ins in Office programs
• Microsoft Learn: Manage add-ins in the Microsoft 365 admin center
• Microsoft Learn: Specify who can install and manage add-ins for Outlook in Exchange Online
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Macros from the internet are blocked by default in Office

Related NHI Mgmt Group resources: Malware Guide · Macro Malware Guide · Consent Phishing and Illicit OAuth Grants Guide · SaaS and OAuth App Governance Guide · Microsoft 365 Security Guide