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

A popular Outlook add-in called AgreeTo was abandoned by its developer and remained listed in the Microsoft Marketplace. An attacker claimed the unowned hosting subdomain, replaced the live content with a phishing kit that mimicked Microsoft sign-in pages, and harvested credentials from roughly 4,000 accounts. Security researchers reported the compromise and the scale of the theft in public write-ups, and recommended removal of the add-in and password resets after discovery Computerworld and BleepingComputer. The incident exposes clear gaps in Outlook add-ins security and in the Microsoft Marketplace submission and live-content model.

How the attack worked and which gaps it exposed

The attack relied on three simple conditions. First, the add-in manifest in Microsoft’s listing pointed to external content hosted on a third-party domain. Second, the domain or subdomain had been abandoned, allowing an outsider to claim it. Third, the marketplace review process verified only the manifest and not the live content loaded at run time. The attacker changed the content at the hosted URL. The add-in continued to load the new content without additional checks. That produced a silent change in behaviour that users never authorised.

This chain highlights three recurring add-in vulnerabilities. One, manifest-only review leaves a blind spot. A signed manifest vouches for pointer attributes, not the content those pointers serve. Two, reliance on external hosting without ownership checks or monitoring allows subdomain takeover. Many hosts, including serverless platforms, leave stale DNS or platform records that can be reclaimed. Three, wide run-time permissions increase attack surface. If an add-in asks for broad scopes, a changed web payload can access sensitive resources, session tokens, or initiate OAuth flows that look legitimate.

The attacker kept complexity low. The phishing pages imitated Microsoft sign-in UX and captured credentials. Exfiltration used simple automation channels rather than bespoke C2 systems. The low technical bar makes the attack pattern repeatable. Users and administrators must treat any add-in with silently loaded remote content as a potential risk. Developers and publishers must treat domain ownership and subdomain lifecycle as part of their security posture for add-in deployment.

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 any suspicious activity occurred after installing a compromised add-in. Revoke stale OAuth consent grants from account security settings. That stops tokens abused by third-party code.

For administrators and power users, apply least privilege. Limit the scopes granted to add-ins. Do not approve add-ins that request more permissions than required for their task. Audit third-party permissions centrally and revoke those that are unnecessary. Apply conditional access policies where available so account sign-ins that come from unusual flows are challenged or blocked.

For add-in developers and publishers, retain control of hosting and DNS. Host add-in resources on domains owned and monitored by the publisher. Use DNS records and hosting accounts with account recovery and registrations locked. 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. Require developers to demonstrate control of hosting domains or to use platform-hosted assets for payloads that run inside the add-in context. Require revalidation of hosted content when domains change hands or when an app goes unmaintained for a defined period. Encourage time-boxed approvals for add-ins with external content and trigger automated rechecks.

Implement monitoring and detection. For users, enable multi-factor authentication on accounts and make sure recovery contact details are up to date. For administrators, log add-in installation and permission grant events. Alert on sudden spikes in authentication failures, novel redirect URIs, or high-volume OAuth consent activity tied to third-party apps. Use threat indicators from security researchers and add them to block lists at the perimeter.

Verify post-change state after remediation. Remove the compromised add-in, reset passwords, and revoke tokens. Then confirm 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 remain secure.

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 core threat vectors for Outlook add-ins security: manifest pointers to live content, unowned or stale hosting, and overly broad permissions. Treat add-ins like any other third-party integration. Keep ownership tight, reduce privilege, monitor actively, and audit regularly. Those steps reduce the chance of silent, large-scale phishing attacks through the Microsoft Marketplace and through add-in vulnerabilities.