Full Report
Cybersecurity researchers have discovered what they said is the first known malicious Microsoft Outlook add-in detected in the wild. In this unusual supply chain attack detailed by Koi Security, an unknown attacker claimed the domain associated with a now-abandoned legitimate add-in to serve a fake Microsoft login page, stealing over 4,000 credentials in the process. The activity has been
Analysis Summary
# Incident Report: Supply Chain Compromise via Abandoned Outlook Add-In (AgreeToSteal)
## Executive Summary
Researchers discovered the first known malicious Microsoft Outlook add-in, dubbed "AgreeToSteal," leveraging a supply chain technique against an abandoned legitimate add-in (AgreeTo). The attacker claimed the dormant add-in's domain infrastructure to host a fake Microsoft login page, resulting in the compromise of over 4,000 user credentials. This incident highlights a critical blind spot in third-party application marketplace security: the lack of continuous monitoring of externally hosted manifest content.
## Incident Details
- **Discovery Date:** February 11, 2026 (Date of reporting)
- **Incident Date:** Occurred sometime after the original developer abandoned the project (around 2023).
- **Affected Organization:** Undisclosed end-users leveraging the malicious add-in.
- **Sector:** Technology / General Business (Users running Microsoft Outlook).
- **Geography:** Not specified, affecting global users who installed the add-in.
## Timeline of Events
### Initial Access
- **Date/Time:** Post-developer abandonment (circa 2023 onward).
- **Vector:** Supply Chain Attack via Abandoned Software Component (Microsoft Office Add-in).
- **Details:** The original developer abandoned the "AgreeTo" Outlook add-in. The attacker claimed the associated abandoned domain/infrastructure hosting the dynamically loaded add-in manifest content (specifically, a Vercel deployment URL: `outlook-one.vercel[.]app`).
### Lateral Movement
The provided summary primarily focuses on credential harvesting via the add-in interface and potential mailbox access; details on traditional network lateral movement were not specified.
### Data Exfiltration/Impact
- **Details:** The compromised add-in displayed a fake Microsoft sign-in page within Outlook to captured credentials. Exfiltration of these stolen passwords occurred via the Telegram Bot API.
- **Potential Impact:** The add-in had `ReadWriteItem` permissions, allowing the attacker to potentially siphon entire mailboxes using covert JavaScript injection.
### Detection & Response
- **How it was discovered:** Discovered and detailed by cybersecurity researchers at Koi Security.
- **Response actions taken:** Koi Security published analysis detailing the attack vector and impact, alerting the community to the new threat class. (Specific organization-level containment/eradication details are not provided, as this is a research finding).
## Attack Methodology
- **Initial Access:** Domain squatting/hijacking of infrastructure associated with an abandoned, legitimate add-in, redirecting dynamic manifest loading pointers.
- **Persistence:** Access was maintained through the legitimate installation platform (Microsoft Marketplace) via the add-in's dynamic content loading mechanism.
- **Privilege Escalation:** Not explicitly detailed, but the add-in already possessed significant permissions granted by the user during installation (`ReadWriteItem`).
- **Defense Evasion:** Relied on the implicit trust placed in Microsoft Marketplace-approved content and the fact that the add-in fetched dynamic content from an external server, bypassing static code inspection during approval.
- **Credential Access:** Phishing the user directly within the Outlook iframe environment by presenting a fake Microsoft login page.
- **Discovery:** Not explicitly stated, but implied reconnaissance was used to identify the abandoned domain/deployment.
- **Lateral Movement:** Not explicitly detailed.
- **Collection:** Harvesting credentials entered into the fake login page. Potential collection of mailbox contents due to existing high permissions.
- **Exfiltration:** Exfiltrating captured credentials via the Telegram Bot API.
- **Impact:** Theft of user credentials.
## Impact Assessment
- **Financial:** Not quantified.
- **Data Breach:** Over 4,000 Microsoft user credentials stolen. High potential for secondary mailbox compromise due to add-in permissions.
- **Operational:** Potential exposure of sensitive communications and data if the `ReadWriteItem` permissions were abused for mass siphoning.
- **Reputational:** Damage to user trust in third-party add-ins and the security vetting process of the Microsoft Marketplace.
## Indicators of Compromise
*Note: Specific IOCs for URLs and IPs are defanged as per instructions.*
- **Network Indicators:** Communication channels utilized Telegram Bot API for exfiltration.
- **File Indicators:** Malicious content was likely loaded dynamically via the URL specified in the add-in manifest (`outlook-one.vercel[.]app`).
- **Behavioral Indicators:** User interaction with a seemingly legitimate add-in surface that prompts for Microsoft credentials unexpectedly.
## Response Actions
*(Based on the research publication nature of the disclosure, these are generalized actions expected following such a report):*
- **Containment measures:** Removal/disabling of the malicious add-in from user installations.
- **Eradication steps:** Forced password resets for all compromised accounts (4,000+). Reviewing and likely revoking permissions granted to the application.
- **Recovery actions:** Auditing mailboxes for signs of data siphoning, given the potential permissions.
## Lessons Learned
- **Supply Chain Risk in Dynamic Content:** Traditional software vetting is insufficient when applications dynamically load content from external servers whose ownership (domains/hosting) can change post-approval.
- **Abandoned Software Vulnerability:** Abandoned, but still functional, applications hosted on marketplaces create opportunities for domain reclamation and malicious repurposing.
- **Add-in Trust Model Flaw:** The implicit trust granted to marketplace add-ins is exploited, especially when they run inside sensitive environments like Outlook with high permissions.
## Recommendations
- **Continuous Manifest Monitoring:** Marketplaces (like Microsoft's) must implement mandatory, periodic rescans of the content referenced by add-in manifests, not just relying on the initial submission review.
- **Infrastructure Ownership Verification:** Implement checks to ensure that domain names referenced in manifests remain under the control of the original, verified developer or have been properly transferred.
- **Permission Minimization:** Users must be strongly educated to scrutinize required permissions (`ReadWriteItem` is highly sensitive) and only install add-ins from actively maintained developers.