In February 2026, cybersecurity researchers publicly disclosed one of the most concerning supply-chain attacks to date affecting Microsoft 365 users: AgreeToSteal — the first known malicious Microsoft Outlook add-in found in the wild. This incident not only led to the theft of over 4,000 Microsoft account credentials and associated sensitive data, but also highlighted a critical architectural weakness in the Outlook add-in ecosystem and the broader Office extensions supply chain.
How Outlook Add-Ins Work — and Why That Matters
Microsoft Outlook add-ins are not traditional installed binaries — they are remote web applications. When a developer publishes an add-in, Microsoft reviewers inspect only the manifest (an XML descriptor). The manifest tells Outlook, “load this external URL inside the Outlook UI.” Once approved, Outlook embeds that URL in a trusted iframe with whatever permissions the manifest requested.
This architecture is inherently dynamic:
- Outlook does not bundle or hash the add-in’s code at approval time.
- Content served from the URL can change without further review.
- Outlook continues loading whatever is served from that URL indefinitely.
This model enables powerful integrations, but it also means that security assurances expire once the manifest is approved — even if the hosting or domain ownership changes later.
From Legitimate Tool to Malicious Infrastructure
The add-in at the center of this case was originally named AgreeTo, a legitimate meeting-scheduling tool built by an independent developer and published to the Microsoft Office Add-in Store in December 2022. It had real functionality, integrations with Microsoft Graph API, and a Chrome extension companion — all open source.
However, the developer eventually abandoned the project. The associated domain (e.g., agreeto.app) expired, and the project’s hosting on Vercel lapsed. Microsoft’s store listing remained active, still pointing to a now-orphaned URL: outlook-one.vercel.app.
An attacker claimed that subdomain and deployed a simple phishing kit. They never needed to push anything through Microsoft’s marketplace review — Outlook continued to load the malicious content as if it were legitimate.
The Attack Workflow
Once a victim opened the compromised add-in in Outlook’s sidebar:
- Malicious HTML/JavaScript was served in the trusted iframe.
- The user was prompted with a fake Microsoft login page mimicking Microsoft’s authentic UX.
- When the victim entered credentials, a short JavaScript function captured the email, password, device IP, and other data.
- This data was exfiltrated using a simple
fetch()call directly to a Telegram Bot API endpoint owned by the attacker — no command-and-control infrastructure necessary. - After a simulated delay, the victim was redirected to the real Microsoft login page, leaving them unaware their credentials had been stolen.
The simplicity of this phishing element underscores a key point: the delivery vector — not the sophistication of the phishing payload — made the attack effective. Most security scanners inspect email attachments, web URLs, or endpoint binaries; none of those trigger for a trusted Office add-in loading a phishing page from a cloud provider.
Scale and Impact
Because Microsoft does not publicly display Office add-in installation counts, the number of affected users couldn’t be estimated from the store listing alone. However, due to operational security errors by the attacker, Koi researchers were able to access the attacker’s exfiltration storage, confirming:
- Over 4,000 victims’ credentials were collected.
- The dataset also contained credit card numbers, CVVs, banking security answers, and identity verification data.
Moreover, the same threat actor managed at least 12 distinct phishing kits impersonating various brands, indicating a professionalized multi-vector phishing infrastructure, with the Outlook add-in being only one distribution channel.
IOCs
outlook-one.vercel[.]app– Phishing domain (LIVE)WA200004949– Office Add-in ID
Why This Should Concern Security Teams
This incident exposes a fundamental architectural blind spot:
- Microsoft approves the manifest once, but does not periodically validate the hosted content.
- The add-in infrastructure allows untrusted code to run with permissions like ReadWriteItem, meaning an attacker could programmatically read contacts, modify emails, or send messages on behalf of the victim.
- Traditional email or network security tools don’t flag a phishing page that never traverses email systems, endpoints, or suspicious URLs — especially when loaded within trusted Microsoft infrastructure.
Security analytics products rarely, if ever, inspect Office add-ins at runtime — meaning this attack would be largely invisible to conventional defenses.
Lessons Learned and Mitigation Considerations
Supply-chain risk extends beyond packaged binaries. The AgreeToSteal case demonstrates how:
- A project’s lifecycle, hosting dependencies, and registration metadata can become threat vectors.
- Marketplace trust should not be equated with ongoing service integrity.
- Platforms must consider continuous monitoring for hosted content changes post-approval.
From a defense perspective:
- Enterprise security teams should treat Office add-in installations with the same scrutiny as browser extensions or external APIs.
- Zero-trust policies and OAuth token monitoring can help detect anomalous token usage.
- Conditional Access and multi-factor authentication mitigate credential misuse even after theft.
Conclusion
The AgreeToSteal campaign represents a watershed in Outlook add-in security, illustrating how even trusted ecosystems can be weaponized when governance assumptions fail and dynamic dependencies are not continuously evaluated. As Microsoft and platform providers update their security models, this incident will likely serve as a key case study in modern supply-chain risk and trusted third-party integration risk vectors.
