Outlook Add-In Hijacking: How Hackers Stole 4,000 Accounts and What You Need to Know [2025]

TL; DR

• A legitimate Outlook add-in called Agree To was abandoned by its original developers and then hijacked by threat actors as reported by Bleeping Computer.
• Over 4,000 Microsoft accounts were compromised, including credit card numbers and banking security answers according to The Hacker News.
• This was the first malicious add-in found on the official Microsoft Marketplace, representing a critical supply chain attack as noted by Cybersecurity News.
• Users need to immediately remove the add-in, reset passwords, and monitor financial accounts for unauthorized activity.
• Organizations should implement strict add-in governance policies and regularly audit installed extensions.

Lack of revenue and burnout are the most significant factors leading to software project abandonment. Estimated data based on common trends.

Introduction: When Trusted Tools Become Weapons

Imagine downloading an app from an official store, using it for months, and never suspecting it's turned into a trojan horse. That's exactly what happened to thousands of Microsoft Outlook users in one of the most alarming supply chain attacks in recent memory.

In late 2024, security researchers at Koi discovered something alarming: Agree To, a seemingly innocent Outlook add-in for scheduling meetings, had been completely taken over by cybercriminals. The original developers had abandoned the project years ago, leaving it vulnerable. Bad actors didn't need to create malware from scratch. They simply waited, took control of an existing tool that people already trusted, and weaponized it.

The numbers are genuinely scary. Over 4,000 Microsoft accounts fell victim. But it wasn't just login credentials that were stolen. Attackers grabbed credit card information, banking security answers, and other sensitive data—the exact information needed to drain bank accounts or commit identity theft.

Here's what makes this attack different from typical phishing campaigns: it happened in plain sight. The add-in sat on Microsoft's official marketplace. Users installed it from the legitimate store. No sketchy download links, no suspicious emails with malicious attachments. Just a normal installation from a place people trust implicitly.

This incident reveals a critical weakness in how we manage software supply chains. When developers abandon projects, those projects don't just disappear. They become targets. And when those projects already have thousands of active users, the damage potential is massive.

In this guide, we'll break down exactly what happened, why it matters, how to protect yourself, and what organizations need to do to prevent similar attacks in the future.

What Is Agree To? Understanding the Compromised Add-In

The Original Purpose and User Base

Agree To wasn't some obscure tool that nobody used. It was a legitimate meeting scheduler add-in for Microsoft Outlook with a "relatively large user base," according to the researchers who discovered the compromise. The add-in did what its name suggests: it helped users agree on meeting times without the back-and-forth email dance.

Think about how frustrating it is to schedule meetings. Someone suggests Tuesday at 2 PM. Three people can't make it. Someone else proposes Wednesday but only at 4 PM. Another person is traveling. Agree To simplified this process by letting organizers propose multiple time slots and letting attendees vote on their preferences directly within Outlook. It was genuinely useful, which is exactly why people installed it and trusted it.

The fact that it had genuine functionality is crucial to understanding why this attack was so successful. People aren't suspicious of tools that actually work. Agree To worked. Users had no reason to think something had changed.

How the Add-In Architecture Works

Microsoft Outlook add-ins are extensions built on web technologies—HTML, Java Script, and APIs. When you install an add-in from the Microsoft Marketplace, you're giving that add-in permission to access certain parts of your Outlook account. Depending on the permissions granted, an add-in might be able to read your emails, access your calendar, see your contacts, or interact with Microsoft 365 services.

This is where the danger becomes clear. An add-in that needs to see your calendar to propose meeting times requires access to your calendar data. But what if that same add-in, after being compromised, uses that access to steal something else entirely?

The permissions model is based on trust. You trust that the developer won't abuse the access you've granted. But when a developer abandons a project, they can't maintain that trust. They can't push security updates. They can't monitor for unauthorized access attempts. The project becomes a ghost, and ghosts can be possessed.

Why Developers Abandon Projects

Understanding why Agree To was abandoned helps us understand the vulnerability landscape. Developers abandon projects for many reasons: they got hired full-time at another company, they lost interest, they built the tool for a specific problem that no longer exists, or they simply ran out of time.

Sometimes abandonment is intentional—the developer explicitly hands off the project to the community or another maintainer. But often, it's passive. A project just stops receiving updates. The developer stops checking emails about issues and feature requests. The Git Hub repository gathers dust.

For small tools on app stores, abandonment often goes unnoticed. Users keep using the old version because it works fine. Nobody flags it as a security risk because on the surface, nothing seems wrong. That's the perfect environment for malicious actors to move in.

While permissions like 'Read Calendar' and 'Read Mail' are necessary for functionality, they also pose high risks if misused. Estimated data.

The Attack in Detail: How Hackers Weaponized Agree To

Gaining Control of the Add-In

The first question is obvious: how did attackers gain control of Agree To? They likely used one or more of these common vectors: they compromised the original developer's email account, they gained access to the project's credentials on Microsoft's developer portal, they found the source code repository and figured out how to push an update, or they socially engineered Microsoft support.

We don't know the exact method because security researchers and Microsoft have kept those details private (which is the responsible approach). But the end result is clear: attackers got access to the add-in's update mechanism. Once they had that, they could push a malicious version to all existing users.

The beautiful part of this attack, from the attacker's perspective, is that it didn't require creating new malware. They took existing code that worked, added malicious functionality on top, and pushed it as an update. Users saw a notification that Agree To had an update. They probably clicked "install" without thinking. Maybe they didn't even get a notification—the update just installed automatically.

The Phishing Kit and Data Exfiltration

Once attackers controlled Agree To, they turned it into a full-blown phishing kit. The compromised add-in did two things:

1. It collected credentials and sensitive information from users without their knowledge. When a user had the add-in active, it hooked into their Outlook session and captured login information, authentication tokens, and other data.

2. It displayed fake login prompts that looked identical to legitimate Microsoft login screens. If the phishing attempt looked convincing enough, users would enter their credentials thinking they were re-authenticating with Microsoft. The add-in would capture those credentials and send them to the attacker.

The data exfiltration happened through a Telegram bot API—a relatively sophisticated choice because Telegram offers end-to-end encryption and is harder for security researchers to monitor than traditional command-and-control servers.

What did the attackers capture? The research found:

• 4,000+ Microsoft account credentials (usernames and passwords)
• Credit card numbers (likely captured through email or calendar data)
• Banking security answers (those motherly questions like "What's your pet's name?" that banks use for account recovery)
• Other sensitive personal information contained in emails or calendar events

The fact that they got banking security answers is particularly damaging. A hacker with your password might trigger alerts by trying to log in immediately. But with your banking security answers, they can call your bank's support line, claim to have lost their password, answer those security questions, and reset your password to something they control. Your bank account is now theirs.

Active Testing and Validation

Here's another terrifying detail: this wasn't a passive attack. The researchers discovered that the attackers were actively testing the stolen credentials. They were checking which ones still worked, which ones had valuable information associated with them, and which ones were worth targeting for further exploitation.

This suggests a sophisticated operation, not a script-kiddie running an automated script. The attackers were methodical. They were prioritizing. They were probably selling working credentials on dark web marketplaces at different price points based on account value.

The Scope of the Damage: What We Know About the Victims

The 4,000+ Accounts Compromised

When researchers say 4,000+ accounts were compromised, they mean the attackers successfully captured credentials and personal data from at least 4,000 distinct Microsoft accounts. This number is verified—researchers accessed the exfiltration channel and counted the stolen data themselves.

But here's the thing: this is a minimum number. It's possible more accounts were compromised but the data wasn't properly stored or retrieved by researchers. It's also possible that some users had the malicious version of Agree To installed but the phishing prompts failed, so no data was captured. The actual number of users affected could be higher.

To put this in perspective, 4,000 accounts is a significant breach for a single malicious add-in. It's not as large as some major data breaches (which often number in the millions), but it's substantial enough to represent a real threat.

Credit Card and Financial Data

The inclusion of credit card numbers in the stolen data is particularly alarming. How did attackers get credit card information from an Outlook add-in? There are several possibilities:

1. Email compromise: Users sometimes receive emails with payment confirmations, invoices, or receipts that include partial credit card information. Attackers could have searched through emails for this data.

2. Calendar data leakage: Some users include payment information in calendar invites or event descriptions (horrible practice, but people do it).

3. Social engineering: The phishing prompts might have evolved beyond fake login screens to include requests for financial information.

4. Related account compromise: Once attackers had Microsoft credentials, they could potentially access linked services like Azure, One Drive, or Office 365 accounts that might contain financial data.

Regardless of the method, the fact that credit card data was captured means victims weren't just at risk of account takeover—they were at immediate risk of identity theft and financial fraud.

Banking Security Answers as a Master Key

Many people don't appreciate how valuable banking security answers are to attackers. Banks use these questions for account recovery precisely because they assume only the account owner would know the answers. But if an attacker has your real answers (because they stole them), they can bypass the normal login process entirely.

Here's a realistic scenario: You notice nothing unusual with your account for a few months. One day, your bank calls asking why multiple password reset attempts were made on your account. You weren't the one making them. Hackers used your security answers to attempt account recovery. Your bank catches it and blocks the attempts.

But what if they didn't catch it? What if one of those password reset attempts succeeded? The attacker now controls your bank account. By the time you notice suspicious transactions, thousands of dollars might have already been transferred.

Why This Attack Was Unique: First Malicious Add-In on Microsoft Marketplace

The Significance of the Official Marketplace

This wasn't some sketchy third-party add-in store where malware occasionally shows up. This was the official Microsoft Marketplace—the vetted, legitimate store that Microsoft endorses. Users trust it. Organizations trust it. Security teams trust it.

The fact that a malicious add-in made it onto the official marketplace represents a critical vulnerability in Microsoft's vetting process. It raises uncomfortable questions: How thoroughly does Microsoft review add-ins before listing them? How often do they audit listed add-ins for compromise? How quickly can they remove malicious add-ins once discovered?

Microsoft's response was eventually effective (they removed Agree To), but it took researchers finding the problem and reporting it. That's not a scalable security model.

Supply Chain Attack Implications

This attack is fundamentally a supply chain compromise. Users didn't directly download malware. They downloaded a legitimate tool from a legitimate source. The malware came later, through an update mechanism they thought was safe.

Supply chain attacks are notoriously difficult to defend against because they exploit trust. If you trust Outlook add-ins from the Microsoft Marketplace, you're vulnerable to this type of attack. If you trust software updates, you're vulnerable. If you trust your email client, you're vulnerable.

The attack vector was especially effective because add-ins are background processes. Unlike applications you consciously launch, add-ins run silently. Users might not even realize Agree To is still there, still collecting data, still displaying fake login prompts.

Estimated data shows that over 4,000 accounts were confirmed compromised, with potentially 2,000 more having the malicious version installed.

The Broader Context: Other Phishing Kits from the Same Actors

A Dozen Other Active Phishing Operations

Here's what security researchers found particularly disturbing: the operators behind the Agree To attack weren't just running this one scheme. Researchers determined they were operating "at least a dozen" other phishing kits targeting different services.

These included:

• Internet Service Providers: Phishing kits designed to steal ISP login credentials, giving attackers access to home network infrastructure.
• Banks: Sophisticated phishing kits that mimic legitimate banking login pages with shocking accuracy.
• Webmail Providers: Similar operations against Gmail, Yahoo Mail, and other email services.

The variety of targets suggests a professional operation. This isn't a hobbyist hacker running random phishing campaigns. This is an organized group with sophisticated tooling, multiple revenue streams, and enough operational security to avoid attribution.

Varying Success Rates

We don't know how successful the other phishing kits are relative to Agree To. It's possible that Agree To was uniquely effective because it had such a large, trusting user base. It's also possible that the ISP and banking phishing kits are even more successful—we just haven't heard about them.

The fact that we only discovered this operation because researchers happened to find the Telegram bot API is sobering. How many other active phishing operations are out there that we haven't discovered yet?

Microsoft's Response: Removal and Notification

Delisting from the Marketplace

Once researchers informed Microsoft about the compromised add-in, the company acted relatively quickly. Agree To was removed from the Microsoft Marketplace, preventing new installations. However, this only addressed the distribution channel. Existing installations were still active and malicious.

This highlights an important distinction: delisting an add-in from the marketplace doesn't automatically remove it from users' computers. Users have to manually uninstall it. If they don't know it's been compromised, they'll keep using it.

Microsoft could potentially implement automatic removal for security threats, but this is complicated. Some users might want to keep using the tool even if it's been compromised (which is obviously a bad idea, but people do irrational things). Forcing removal could be seen as heavy-handed.

The Notification Gap

A major gap in the response is that Microsoft didn't (or couldn't) automatically notify users. If you had Agree To installed, you didn't get a direct message saying "This add-in has been compromised, you must uninstall it immediately." You only learned about it if you were reading security news or if your organization's security team sent out an alert.

This is a systemic problem with add-in security. When a plugin is compromised, there should be an emergency notification system that immediately alerts users. Some users check their email once a week. Some users never read security advisories. The default should be aggressive notification, not passive hope that people will find out.

How Hackers Identify Abandoned Software Projects

The Hunt for Ghost Projects

Attackers systematically search for abandoned projects. They look for software that:

1. Still has active users (install base large enough to make the effort worthwhile)
2. Hasn't been updated in years (no active developers to defend it)
3. Has weak credentials management (original developers didn't secure their accounts)
4. Is in a position of trust (users are unlikely to be suspicious)

Outlook add-ins are particularly attractive because they operate with high privileges and access to sensitive data. A banking app is also great, but it's actively maintained. An old add-in for meeting scheduling that nobody updates anymore? That's perfect.

Why Developers Stop Maintaining Projects

Developers abandon projects for legitimate reasons:

• Burnout: Writing software is hard. Maintaining it forever is harder.
• Lack of revenue: Most small tools don't make money. Eventually, developers stop investing unpaid time.
• Feature complete: Maybe the add-in does exactly what it was designed to do. The developer figures it's done.
• Life changes: People get new jobs, move, have family obligations, or simply lose interest.
• Acquisition or sunset: Sometimes a company buys a product and shuts it down. Sometimes features are absorbed into other products.

None of these are malicious. They're natural consequences of how software gets built. But they create security holes that bad actors exploit.

Estimated data shows that calendar access is the most common permission required by meeting scheduler add-ins, followed by email and contact access.

Immediate Actions: What Users Need to Do Right Now

Step 1: Remove the Add-In Immediately

If you installed Agree To, your first action is to remove it. The process is simple:

1. Open Outlook (web or desktop version)
2. Go to File > Get Add-ins (or Options > Get Add-ins)
3. Click My Add-ins or My Installed Add-ins
4. Find Agree To in the list
5. Click the Remove button (might appear as a delete icon or right-click menu option)
6. Confirm removal

If you use Outlook Web Access (OWA), the process is slightly different:

1. Click the Settings gear in the top right
2. Go to Settings > Mail > Add-ins and integrations
3. Find Agree To in the installed add-ins
4. Click Remove

Do this immediately. Don't wait. Don't think about whether you still need it. Remove it.

Step 2: Reset Your Password

If you had Agree To installed, your Microsoft account password was likely compromised. Change it immediately:

1. Go to account.microsoft.com
2. Click Security > Change password
3. Enter your current password, then create a new password
4. Make it strong: At least 16 characters, mix of uppercase, lowercase, numbers, and symbols
5. Make it unique: Don't reuse passwords across accounts

Better yet, use a password manager to generate a completely random password that you've never used anywhere else.

Step 3: Enable Multi-Factor Authentication

This is non-negotiable if you haven't already done it:

1. Go to account.microsoft.com
2. Go to Security > Advanced security options
3. Click Set up two-step verification
4. Choose your authentication method (authenticator app is stronger than SMS)
5. Complete the setup process

Even if attackers have your password, they can't access your account without the second factor.

Step 4: Review Account Recovery Options

Attackers might have added themselves as account recovery methods:

1. Go to account.microsoft.com > Security
2. Check your security info: Review all email addresses and phone numbers
3. Remove anything you don't recognize
4. Update recovery email to an address only you control
5. Verify recovery phone number is correct

If an attacker added a secondary email address as a recovery method, they could reset your password using that address. Remove anything suspicious immediately.

Step 5: Change Passwords for Connected Services

Your Microsoft account is the gateway to many services:

• Outlook/Exchange: You've already changed this
• One Drive: May be compromised if attackers accessed your cloud storage
• Azure: If you use cloud services
• Office 365/Microsoft 365: Corporate accounts tied to your Microsoft credentials
• Xbox Live: If you use gaming services
• Git Hub: If linked to Microsoft account

If any of these are compromised, change their passwords too.

Long-Term Monitoring: What to Watch For

Financial Account Monitoring

This is critical because attackers have your banking security answers:

1. Check bank statements weekly for unauthorized transactions
2. Set up fraud alerts with your bank
3. Monitor credit reports using free services like Credit Karma or Annual Credit Report.com
4. Enable account notifications from your bank for all transactions
5. Consider a credit freeze to prevent new accounts being opened in your name

If you see suspicious activity:

1. Contact your bank immediately
2. Report the fraud to the FTC at Identity Theft.gov
3. File a police report (some banks require this for fraud investigation)
4. Document everything for your records

Email and Account Access Monitoring

1. Check recent activity in your Microsoft account
2. Review connected devices in your account security settings
3. Check browser sessions in Outlook settings for unfamiliar access
4. Set up security alerts for unusual login attempts
5. Monitor forwarding rules in Outlook (attackers sometimes set these up to see your emails)

If you see someone accessing your account from an unfamiliar location or device:

1. Sign them out immediately
2. Change your password again
3. Re-enable two-factor authentication if it was disabled
4. Investigate your computer for malware (run Malwarebytes or Windows Defender)

Organizational Response: What Companies Need to Do

Immediate Incident Response

For organizations with affected employees:

1. Send emergency alert to all users about the compromise
2. Mandate immediate removal of the add-in from all Outlook instances
3. Force password reset for all users (especially those who had Agree To installed)
4. Monitor Azure AD logs for unusual authentication patterns
5. Review email forwarding rules across the organization for unauthorized rules
6. Check mailbox audit logs for suspicious access or email deletion

The urgency here can't be overstated. Every day an employee with the malicious add-in is still using it is another day of data collection and potential account compromise.

Add-In Governance Policies

Organizations need to implement strict governance:

1. Create an approved add-ins list: Only allow add-ins from Microsoft's official list that have been vetted by your security team
2. Implement Microsoft Purview compliance: Use policies to restrict which add-ins users can install
3. Require justification for new add-ins: Users must explain why they need to install something before approval
4. Audit installed add-ins quarterly: Check what's actually installed across the organization
5. Establish decommissioning process: When an add-in is no longer needed, enforce its removal

Technical Controls

Microsoft 365 organizations can enforce:

• Centralized add-in management through the Exchange Admin Center
• Integrated apps policy to control which applications can be installed
• Group Policy (for on-premises Exchange) to restrict add-in installation
• Application Guard to isolate Office applications
• Conditional Access policies to require multi-factor authentication for Outlook access

Employee Training

Technical controls only work if users understand the risks:

1. Educate about supply chain attacks: Help users understand that compromised legitimate software is more dangerous than obviously malicious software
2. Teach add-in vetting: How to evaluate whether an add-in is trustworthy
3. Explain permission risks: What each type of permission means (calendar access, email read, etc.)
4. Phishing training: Remind users that even internal-looking interfaces can be spoofed
5. Incident reporting: Make it easy for employees to report suspicious activity

Vendor Assessment

When evaluating add-ins and plugins:

1. Check update frequency: Is the developer actively maintaining the project?
2. Review permissions requested: Does the add-in ask for more access than it needs?
3. Verify developer identity: Is this from an established company or an individual?
4. Check security history: Has this developer had any security issues before?
5. Evaluate business model: How does the developer make money? Free apps with no clear revenue model are suspicious.

Estimated data shows that official marketplaces like Microsoft Marketplace are trusted more than other sources, highlighting the significance of the breach.

Understanding Add-In Permissions and Risks

What Permissions Does Agree To Request?

Most meeting scheduler add-ins request:

• Read calendar: To see existing meetings and availability
• Write calendar: To add proposed meeting times
• Read mail: To parse email for scheduling context
• User identity: To know which user is running the add-in

These are reasonable permissions for a legitimate scheduling tool. But a malicious add-in with the same permissions can:

• Harvest all your calendar data (seeing meetings with sensitive information)
• Exfiltrate your contact list (everyone you communicate with)
• Read all your emails (including ones containing credentials, financial data, or confidential information)
• Capture your authentication tokens (allowing impersonation)

The problem is that legitimate functionality and malicious functionality often require the same permissions.

Permission Escalation Risks

Once an add-in has initial access, it can attempt to escalate permissions:

1. Request elevated permissions through consent flows
2. Use token theft to access APIs the user is authenticated to
3. Execute arbitrary code (depending on the add-in framework)
4. Interact with the operating system (reading local files, running executables)

Add-in security is essentially a trust relationship. You're trusting the developer not to abuse the access they've been given. When a developer is compromised or malicious, that trust is fundamentally broken.

How to Audit Your Add-Ins: Complete Checklist

Desktop Outlook (Windows)

1. Open Outlook
2. Click File > Options > Add-ins
3. In the Manage add-ins dropdown, select each category and review
4. For each add-in, ask:
   • Do I recognize this?
   • Do I use this actively?
   • Is the developer still maintaining it?
   • Are the permissions reasonable?
   • When was it last updated?

Outlook Web Access (OWA)

1. Click the Settings gear (top right)
2. Go to Settings > Mail > Add-ins and integrations
3. Review each installed add-in
4. Click each one to see permissions requested
5. Remove anything you don't actively use

Microsoft 365 Admin Center (for organizations)

1. Go to admin.microsoft.com
2. Navigate to Exchange > Add-ins
3. Review organization-wide installed add-ins
4. Click each to see description and publisher
5. Check if any should be removed
6. Set User default on/off to off to require explicit permission

Questions to Ask About Each Add-In

• Is it currently used? If not, remove it.
• When was it last updated? More than a year old is a red flag.
• Who's the developer? Unknown developers are riskier.
• What permissions does it request? More permissions = more risk.
• Is there an alternative? Is there a better-maintained option?
• Can you verify legitimacy? Can you confirm it's really from who it claims?

The Bigger Picture: Supply Chain Security in Software

Why Supply Chain Attacks Are Increasing

Supply chain attacks like the Agree To compromise are becoming more common because:

1. Direct defense is hard: It's difficult to defend against targeted attacks on your infrastructure
2. Supply chain is softer: Attacking a vendor or third-party component is often easier
3. Trust multiplier effect: Compromising one project affects thousands of downstream users
4. Organizational complexity: Organizations often don't know all the dependencies in their software
5. Scalability: Attackers can automate supply chain attacks across many targets

Recent high-profile supply chain attacks include Solar Winds (affecting thousands of government and corporate networks), 3CX (compromising a legitimate development tool), and Log 4 Shell (a vulnerability in an ubiquitous logging library).

The Problem of Software Maintenance

There's a fundamental mismatch in how software gets maintained:

• Users expect indefinite support ("Why doesn't this still work?")
• Developers have finite time and motivation ("I'm not working on this unpaid")
• Security vulnerabilities never expire ("Even old code can be hacked")

The result is abandoned software scattered across the internet, still actively used, still vulnerable.

Moving Toward Better Supply Chain Security

Industry is starting to address this:

1. Software Bill of Materials (SBOM): Know what dependencies you're using
2. Dependency scanning: Automatically check dependencies for known vulnerabilities
3. Signed releases: Verify that software actually came from who claims to have released it
4. Dependency pinning: Use specific versions, not "latest"
5. License compliance: Ensure dependencies have acceptable licenses
6. Regular audits: Review and update dependencies periodically

But individual users and small organizations often lack the tools and expertise for this level of scrutiny.

This chart illustrates the estimated frequency of various monitoring activities for financial and email accounts. Regular checks, such as bank statements and email activity, are recommended weekly, while others like fraud alerts and credit reports are less frequent. (Estimated data)

Spotting Phishing and Compromised Add-Ins Before Damage Occurs

Red Flags That an Add-In Has Been Compromised

Watch for these warning signs:

1. Unexpected permission prompts: "Grant calendar access" prompts that come out of nowhere
2. Performance degradation: Your Outlook suddenly becomes slow
3. Unexpected login prompts: Being asked to re-authenticate when you just logged in
4. Unusual email behavior: Emails disappearing, forwarding rules you didn't create
5. Strange calendar entries: Meeting invites you don't recognize
6. Unreadable add-in names: Add-in listed with strange characters or gibberish
7. Recent surprise updates: Add-in updated to a new version with no changelog
8. Network traffic spikes: Checking network activity and seeing the add-in sending data

How to Identify Phishing Attempts

Even if an add-in is compromised, phishing attempts within it have tells:

1. Login prompts in unexpected places: Microsoft wouldn't ask for your password in an Outlook add-in
2. Unusual styling: Slight differences from the real Microsoft login page
3. Requests for extra information: Microsoft never asks for security questions through the interface
4. Domain mismatches: The form posts to a domain other than microsoft.com
5. Mobile weirdness: The interface doesn't work properly on your phone
6. Trust your gut: If something feels off, it probably is

What To Do If You Suspect Compromise

1. Don't enter any information: Don't type your password, don't click links
2. Close the prompt immediately: Alt+Tab away from it
3. Remove the add-in: Use the steps from earlier in this guide
4. Change your password: From a different device if possible
5. Run antimalware: Use Windows Defender or Malwarebytes
6. Report it: Contact Microsoft at report@microsoft.com
7. Monitor accounts: Check bank and email accounts for unauthorized access

Browser Extensions and Beyond: Similar Vulnerabilities Elsewhere

Browser Extension Security

Browser extensions have the same fundamental vulnerability as Outlook add-ins: they run in a position of trust with access to sensitive data. Chrome extensions, Firefox add-ons, and Safari extensions can all be compromised if:

• The original developer abandons the project
• The developer's account gets hacked
• The developer is compelled by law enforcement
• The developer sells the extension to a malicious party

Recent examples include extensions that began injecting advertisements into Google results, extensions that stole cryptocurrency, and extensions that hijacked user searches.

Desktop Application Supply Chain Risks

Desktop applications face similar risks. If you install a legitimate application and it hasn't been updated in years, it becomes a target. Attackers could:

1. Compromise the developer's code repository
2. Inject malicious code into the build process
3. Distribute trojanized versions through mirrors or P2P networks
4. Compromise the update server and push malicious updates

Mobile App Store Risks

Even "official" app stores can host malicious applications. Google Play and Apple App Store both have had malicious apps, though they're generally better at detecting and removing them than the Microsoft Marketplace was at detecting Agree To.

Best Practices for Individual Users and Organizations

For Individual Users

Preventive measures:

1. Minimize add-ins and extensions: Only install what you actively use
2. Research before installing: Check reviews, developer history, update frequency
3. Enable automatic updates: Keep software current
4. Use security software: Antivirus/anti-malware as a safety net
5. Monitor accounts: Regularly review account activity and settings

Responsive measures:

1. Subscribe to security alerts: Follow Microsoft Security Blog, security vendors
2. Check software sources: Only install from official app stores and verified sources
3. Verify developer legitimacy: Unknown developers require extra scrutiny
4. Read privacy policies: Understand what data software collects
5. Use password managers: Strong, unique passwords for every account

For Organizations

Policy and governance:

1. Establish add-in approval process: Require security review before approval
2. Maintain approved add-in list: Only these can be installed
3. Enforce multi-factor authentication: Required for all users
4. Regular permission audits: Review what apps can access
5. Security awareness training: Regular training for all staff

Technical controls:

1. Centralized add-in management: Control via Exchange Admin Center
2. Integrated apps policy: Restrict third-party app integration
3. Conditional access: Based on location, device, risk level
4. Audit logging: Maintain detailed logs of access and changes
5. Threat intelligence: Subscribe to advisories about new compromises

Timeline: What Happened and When

While exact dates weren't disclosed by researchers or Microsoft, the sequence of events was approximately:

1. Years ago: Agree To was launched as a legitimate add-in for meeting scheduling
2. Years ago: Original developer stopped maintaining the project
3. 2024 (estimated): Attackers discovered the abandoned project and took control
4. 2024 (estimated): Malicious version was released and pushed to all existing users
5. November/December 2024: Koi security researchers discovered the malicious activity
6. Late 2024/Early 2025: Microsoft was notified and removed the add-in
7. Public disclosure: Security community was informed of the compromise

The fact that the malicious version was active for a period without detection shows how difficult these attacks are to catch. Users noticed nothing unusual because the phishing prompts were sporadic, and the data exfiltration happened silently.

What Microsoft Should Have Done (and Needs to Do)

Preventing the Compromise

1. Require active maintenance: Remove add-ins that haven't been updated in X years
2. Stronger credential security: Require multi-factor authentication for developer accounts
3. Code signing verification: Ensure updates are actually from the claimed developer
4. More thorough vetting: Not just at launch, but continuous monitoring
5. Dependency scanning: Check if add-ins use vulnerable libraries

Detecting Compromise Faster

1. Monitor exfiltration patterns: Unusual data access or network behavior
2. Analyze user behavior changes: When an add-in suddenly requests new permissions or behaves differently
3. Crowdsourced security: Let users report suspicious add-in behavior
4. Automated scanning: Regularly scan add-in code for known phishing patterns

Responding to Compromise

1. Emergency notification system: Automatically notify users of security issues
2. Forced removal option: For security threats, Microsoft should be able to auto-remove add-ins
3. Clearer communication: Security advisories should be prominent and specific
4. Compromise checklist: Provide clear guidance on what users should do

FAQ

What exactly is an Outlook add-in?

An Outlook add-in is a software extension that integrates directly into Microsoft Outlook to provide additional functionality. These extensions run with elevated privileges and can access calendar data, emails, contacts, and authentication tokens. Think of them as mini-applications that live inside Outlook and enhance its capabilities beyond what the base application offers.

How did the Agree To add-in become compromised?

The Agree To add-in became compromised because the original developer abandoned the project years ago, leaving it unmaintained. When the project was abandoned, the credentials and access controls protecting the developer account were vulnerable. Attackers eventually gained control of either the developer's account or the add-in's distribution channel and pushed a malicious update that turned the legitimate scheduling tool into a phishing kit. Users received what appeared to be a normal software update, but it actually installed malicious code.

How many people were affected by the Agree To compromise?

Over 4,000 Microsoft accounts were compromised by the Agree To attack, based on analysis of the attacker's exfiltration channel. This figure represents the minimum confirmed number of successful compromises, as it's based on captured and verified credentials. The actual number of users who had the malicious version installed could have been higher, though not all attempted phishing attempts would have succeeded in capturing credentials.

What information was stolen from the compromised accounts?

Researchers confirmed that attackers obtained Microsoft account credentials (usernames and passwords), credit card numbers, banking security answers, and other sensitive personal information contained in emails or calendar events. The banking security answers are particularly dangerous because they can be used to bypass normal account recovery processes and gain direct access to bank accounts without needing the original password.

Is my account compromised if I had Agree To installed?

If you had Agree To installed at any point between when it was compromised and when Microsoft removed it, there's a significant risk your account was compromised. Your credentials were likely exfiltrated. You should immediately remove the add-in, change your Microsoft account password, enable multi-factor authentication, and monitor your accounts for unauthorized activity. Even if your account wasn't successfully targeted by phishing prompts, the add-in was collecting authentication tokens in the background.

How do I know if I had the malicious version of Agree To?

If you had Agree To installed on your system at any time in 2024 before Microsoft removed it, you likely had the malicious version. There's no reliable way to know if you saw phishing prompts or if the add-in successfully captured your credentials. The safest approach is to assume compromise and follow the remediation steps outlined in this guide: remove the add-in, change passwords, and monitor accounts.

Can I still use legitimate meeting scheduler add-ins safely?

Yes, but with caution. Choose well-established options from companies with clear track records and active development. Verify that the add-in is regularly updated, check that it only requests permissions it actually needs, and understand what data it accesses. However, the Agree To incident is a reminder that even add-ins on the official Microsoft Marketplace can become dangerous if the developer abandons the project. Regular audits of installed add-ins are essential.

What should organizations do beyond removing the add-in?

Organizations should implement comprehensive add-in governance policies including requiring security review before any new add-ins are approved, maintaining a whitelist of approved add-ins, enforcing multi-factor authentication for all users, auditing installed add-ins quarterly, and providing security awareness training. Organizations should also force password resets for employees who had the add-in installed and monitor Microsoft 365 logs for unusual activity.

How can I prevent similar attacks in the future?

The most important prevention strategy is minimizing your attack surface. Only install add-ins you actively use and need. For each add-in, verify the developer is actively maintaining it (recent updates, responsive to issues), review the permissions it requests and understand what data it accesses, and regularly audit your installed add-ins to remove ones you no longer use. Enable multi-factor authentication on all important accounts, use strong unique passwords, and stay informed about security advisories.

What does this mean for the security of the Microsoft Marketplace?

The Agree To incident exposed significant gaps in Microsoft's vetting and monitoring processes. The fact that a malicious add-in remained on the official marketplace undetected shows that Microsoft's processes need improvement in several areas: abandoned project detection and removal, continuous security scanning of listed add-ins, faster response to reported security issues, and automatic notification systems for users of compromised add-ins. This has prompted Microsoft and other platforms to reassess how they handle security in their ecosystems.

Conclusion: Moving Forward With Better Security Practices

The Agree To compromise represents a watershed moment in understanding how modern software supply chains can fail. It wasn't a sophisticated zero-day exploit or a targeted nation-state attack. It was simply an abandoned project that nobody was watching, taken over by criminals who understood that trust is the most valuable vulnerability in security.

What makes this incident particularly important is that it happened in plain sight on an official marketplace. Users did everything right according to conventional wisdom. They installed software from a trusted source. They trusted a software update. They had no reason to suspect the tool had been compromised. And yet thousands of accounts fell victim anyway.

The lessons are clear. First, the software supply chain is only as secure as its weakest link, and abandoned projects are the weakest links. Second, automatic updates are a double-edged sword, increasing convenience while increasing risk. Third, trust is not a security control. Just because software comes from an official source doesn't mean it's safe.

For individuals, the immediate priority is ensuring you've removed Agree To, reset your passwords, enabled multi-factor authentication, and are monitoring your accounts. Don't just assume you're fine and move on. The attackers had banking security answers. This isn't something to take lightly.

For organizations, the incident is a call to action to implement comprehensive add-in governance, enforce strong authentication, and conduct regular audits of installed software. Every tool in your environment represents a potential supply chain attack vector. Limiting that surface area is not optional anymore, it's essential.

Looking forward, this incident should accelerate industry movement toward better security practices: mandatory security reviews for software distribution platforms, better tooling for detecting compromised projects, automatic notification systems for security threats, and clearer accountability for maintaining the security of published software.

The most important takeaway is this: security isn't something that happens once. It's not about installing antivirus and forgetting it. It's about maintaining vigilance, regularly auditing your software, staying informed about threats, and understanding that trust must be earned continuously, not just assumed based on a brand name or official seal.

The tools you trust today might be compromised tomorrow. Act accordingly.

Key Takeaways

• Abandoned software projects become targets for malicious actors who exploit the lack of active developer oversight and security patching
• Over 4,000 Microsoft accounts were compromised through a single Outlook add-in, demonstrating the severe impact of supply chain attacks
• Users must immediately remove the AgreeTo add-in, reset passwords, enable multi-factor authentication, and monitor financial accounts
• Organizations need strict add-in governance policies, centralized management through Exchange Admin Center, and regular audits of installed extensions
• This was the first confirmed malicious add-in on Microsoft's official marketplace, exposing gaps in vetting and continuous security monitoring

Related Articles

• dYdX Supply Chain Attack: How Malicious NPM Packages Emptied Wallets [2025]
• DNS Malware Detour Dog: How 30K+ Sites Harbor Hidden Threats [2025]
• Password Security Guide: Why Strong Credentials Matter in 2025
• Lumma Stealer's Dangerous Comeback: ClickFix, CastleLoader, and Credential Theft [2025]
• Beware of Fake 7-Zip Installers Laced with Malware [2025]
• Flickr Data Breach 2025: What Was Stolen & How to Protect Yourself [2025]