Securing Your Outlook Add-ins: Lessons from the AgreeTo Hijack

A popular Outlook add-in called AgreeTo was abandoned by its developer and stayed listed in the Microsoft Marketplace. An attacker took over the unowned hosting subdomain, swapped the live content for a phishing kit that copied Microsoft sign-in pages, and harvested credentials from roughly 4,000 accounts. Security researchers described the compromise and the scale of the theft in public write-ups, and advised removing the add-in and resetting passwords after discovery Computerworld and BleepingComputer. The incident shows the gaps in Outlook add-ins security and in the Microsoft Marketplace model for live content.

How the attack worked and which gaps it exposed

The attack depended on three simple conditions. The add-in manifest in Microsoft’s listing pointed to external content hosted on a third-party domain. The domain or subdomain had been left abandoned, so an outsider could claim it. The marketplace review process checked the manifest, not the live content loaded at run time. The attacker changed the content at the hosted URL. The add-in kept loading the new content without any extra checks. Users never authorised that change in behaviour.

That chain points to three recurring problems with add-ins. Manifest-only review leaves a blind spot. A signed manifest vouches for pointer attributes, not the content behind them. External hosting without ownership checks or monitoring opens the door to subdomain takeover. Plenty of hosts, including serverless platforms, leave stale DNS or platform records that can be reclaimed. Broad run-time permissions raise the risk again. If an add-in asks for wide scopes, a changed web payload can reach sensitive resources, session tokens, or start OAuth flows that look legitimate.

The attacker kept the setup simple. The phishing pages copied Microsoft sign-in UX and captured credentials. Exfiltration used basic automation rather than a custom C2 stack. That makes the pattern easy to repeat. Users and administrators should treat any add-in that loads remote content silently as a risk. Developers and publishers need to treat domain ownership and subdomain lifecycle as part of add-in security, not an afterthought.

Hardening steps for Outlook add-ins and your environment

Inventory and remove unused add-ins. Open Outlook, go to Manage add-ins, and list everything installed. Remove any add-in that is abandoned, unrecognised, or no longer maintained. Reset affected account credentials if you saw suspicious activity after installing a compromised add-in. Revoke stale OAuth consent grants from account security settings. That cuts off tokens abused by third-party code.

For administrators and power users, keep the scope tight. Limit the permissions granted to add-ins. Do not approve add-ins that ask for more than they need. Audit third-party permissions centrally and revoke the ones that are not required. Apply conditional access policies where available so unusual sign-in flows are challenged or blocked.

For add-in developers and publishers, keep control of hosting and DNS. Host add-in resources on domains you own and monitor. Use DNS records and hosting accounts with account recovery and registrations locked down. Make sure subdomains are not left orphaned in DNS or platform consoles. Use certificate pinning for critical endpoints where possible and set strict Content Security Policy headers to limit which domains can be framed or fetch resources.

For Marketplace and platform operators, require live-content validation and domain proofing. Ask developers to prove control of hosting domains or to use platform-hosted assets for payloads that run inside the add-in context. Revalidate hosted content when domains change hands or when an app goes unmaintained for a defined period. Time-box approvals for add-ins with external content and run automated rechecks.

Monitoring matters as well. For users, enable multi-factor authentication on accounts and keep recovery contact details current. For administrators, log add-in installation and permission grant events. Alert on sudden spikes in authentication failures, new redirect URIs, or high-volume OAuth consent activity tied to third-party apps. Use indicators from security researchers and add them to block lists at the perimeter.

After remediation, check the state of the account. Remove the compromised add-in, reset passwords, and revoke tokens. Then confirm that no suspicious forwarding rules, connectors, or mailbox delegations were added. Check connected apps and authorised services in account security dashboards. Run a test sign-in with MFA to verify that account recovery paths still work.

Practical checks to run now:

• List installed add-ins and remove unfamiliar entries.
• Revoke third-party app consents from account security pages.
• Turn on multi-factor authentication and require it for administrative accounts.
• Monitor DNS and hosting registrations for domains tied to published add-ins.

This incident shows the main risks in Outlook add-ins security: manifest pointers to live content, stale or unowned hosting, and overly broad permissions. Treat add-ins like any other third-party integration. Keep ownership tight, reduce privilege, monitor actively, and audit regularly.