Token Theft Attacks & MFA Defeat: 2025 State of Infosec Incident Stories

Welcome to the second post in our series of incident response stories following our recent engagements.

Over the past two years, our team has managed 135 incident response cases, addressing incidents that have affected small, medium-sized, and enterprise-level entities alike.

Through our analysis of these incident response cases, we’ve discovered and documented the tactics, techniques, and protocols attackers use to compromise and damage organizations.

The goal of this series is to offer you a peek behind the curtain and expose the realities of attacker operations while also providing actionable insights to lower your risk and minimize the impact if (or when) you become a target.

The FRSecure Incident Response team responded to 65 business email compromise incidents in 2024-2025, which was 48.15% of all investigations in the dataset.

Of the 65 business email compromise incidents our team responded to, 79% of the victims had correctly implemented multifactor authentication (MFA). When we originally drafted our InfoSec Report in 2023, only 27% of victims had MFA properly deployed. Kudos to the security technical professionals who have made significant progress since last year.

However, as expected, the paradigm has shifted.

Last year, we warned that MFA is a critical safeguard—but it is not a silver bullet. We also highlighted multiple MFA defeat techniques. This year, our observations indicate that these techniques are still in use in the wild. Only this time, a new player was introduced: token theft attacks!

Token Theft Attacks Introduction

As we observed the improved adoption of MFA, attackers quickly designed new attacks to circumvent these protections.

In the majority of business email compromise incidents, with proper multi-factor authentication (MFA) implementation, token theft attacks delivered through phishing campaigns were used as the initial point of entry.

You’ve likely heard of these attacks referred to as EvilProxy or EvilGinx. Both, along with others, follow the same attack kill chain.

On the surface, token theft attacks resemble many phishing campaigns of the past.

Token Theft Attack Steps

Here’s how it looks:

1. Unsuspecting users receive an email that directs them to download a file or click a link.
2. When a user clicks the link, they will be directed to a well-designed yet fake login page.
   1. This page acts as a proxy between the user and the intended landing page being impersonated.
3. When a victim enters credentials into the web page, they are passed through the proxy for interception and then onto the legitimate server.
4. The use of valid credentials initiates the MFA response requirement, which is also presented and proxied through the attacker’s login page.
5. When the victim enters their MFA response, the attacker’s proxy system authenticates with the destination application.

Attackers now steal the session cookie, retaining persistent access to the target environment.

Token Theft Attack Persistence

Once the attacker has gained access to the victim’s mailbox or M365 environment, they typically deploy multiple persistence techniques to maintain their access.

Communication Interception

The first persistence type involves creating inbox rules for users to forward all emails to an attacker-owned mailbox. These rules ensure that even if access to the mailbox is lost, the attacker will still have visibility to all communications.

With visibility and knowledge of ongoing communications, the attacker can infiltrate existing conversations and attempt other fraudulent activities, such as continued phishing or fraudulent ACH fund transfers.

If the attacker still has access to the environment, they will attempt to hijack active communications to deliver the payload.

Suppose access has been severed, and the attackers are still successfully offloading email communications. In that case, the attacker will copy the ongoing conversations and emails into a spoofed email in an attempt to execute ACH fraud or successfully compromise another target.

Auto-Hide Financial Communications

Another technique observed is the creation of mailbox rules to autohide or delete emails related to financial transactions.

As the goal for many attackers is to execute financial transactions, hiding these communications from the compromised user allows the attacker to retain access, evade detection, and successfully execute ACH fraud.

Third-Party Applications

One final technique discovered this year is the utilization of third-party applications as part of the kill chain.

Once attackers gained access to a compromised account, our team observed them using this authorization to register third-party applications and then granting all available permissions to these applications.

The application most observed in our casework is “PerfectData Software.”

PerfectData is a legitimate application that offers numerous functions, but it also enables quick backup of the M365 environment. Similar to the aforementioned inbox rule, this is a highly effective persistence technique that allows the attacker to maintain visibility into the account and all data and communications, even if the initial malicious login is discovered and remediated.

Now onto the most essential part: what can we do to STOP these attacks?!? Conditional Access is the new MFA!

Token Theft Attack Logic

Let’s first consider the logic behind this attack.

Attackers can defeat MFA through a relatively simple, old-school technique: the Man-in-the-Middle attack.

This attack type isn’t anything new, and our defense against these attacks might be simpler than you think.

1. As always, the number one defense against these types of attacks is education.
2. Second to that is validation of all devices and applications that have the authority to access your environments.

Every device has a unique fingerprint, and your cloud environments log that fingerprint. Every application, browser, location, and so on has a unique fingerprint, and your cloud services are (hopefully) logging them as well.

You should only allow access to validated systems and applications. Validation of these systems can and should only be achieved by going through the conditional access policy processes.

Conditional Access

In its simplest form, conditional access means that a user must meet a specified condition to gain access to a resource.

MFA is an excellent example of this. Many MFA policies are configured using conditional access rules. However, we cannot limit our conditional access to just requiring an MFA code anymore.

You can also utilize conditional access for device and application authorization.

M365 offers configurations that will alert your administrator when a new device attempts to access your tenant. You can set requirements that the device be compliant and managed by your organization. If the device does not meet this criterion, it will not be allowed to access your environment.

You can also configure these policies to require administrator approval of all devices attempting to connect to your tenant. Conditional access policies can be applied to all systems and mobile devices.

Conditional access also allows you the ability to limit third-party applications from accessing your environment without prior authorization. Any new application attempting to connect to your organization will be blocked until the administrator has reviewed and approved it.

How does this prevent man-in-the-middle attacks?

To bring this back to the kill chain—even if an attacker successfully proxies a user’s connection and harvests their credentials and MFA code —when a new device attempts to connect to the environment, it will be denied.

An administrator will be notified when a new system requests access. This will enable you to identify when a user has been compromised quickly, prevent the attacker from gaining access to your environment, and facilitate rapid remediation with minimal impact on your organization.

The same logic should be applied to all third-party applications that attempt to access your environment.

This is only the tip of the iceberg for conditional access policies. They can also be utilized to restrict access based on location, identify and block risky users, etc.

Other Recommendations

Audit your environment! Ensure that all currently authorized devices have been reviewed and approved. Execute the same review for all applications that currently have access to your environment.

Token theft attacks and similar attack vectors highlight the continued importance of having a comprehensive vulnerability management program.

1. Your program must include keeping an up-to-date system, data, and application inventory.
2. Any system or application that has been approved for use on your network should be documented.
3. By default, any system or application that is not on this list should be denied access to the tenant.
4. New authorization attempts from anything not previously authorized should initiate a response or review process.

Based on the risk assessments we conducted last year, here’s a snapshot of how organizations are doing in the most critical areas of vulnerability management.

• 59% of organizations observed scan for external vulnerabilities at least quarterly
• 85% of organizations observed restrict public access to insecure TCP ports 23, 135, 137, 138, 139, 161, 445, 901, 902, 903, 1025, 1433, 1434, and 3389
• 54% of organizations observed define specific timelines and thresholds for vulnerability management
• 64% of organizations observed validate vulnerability management practices periodically
• 61% of organizations observed regularly audit the ports that are open to the internet

In addition to these findings, we also observed the following about organizations’ asset management practices within their vulnerability management program:

• 88% of organizations observed maintain a complete inventory of assets for technical vulnerability management
• 53% of organizations observed have identified critical business assets and their dependencies
• 51% of organizations observed maintain a complete, up-to-date, and detailed inventory of all cloud services.

These metrics can and should serve as benchmarks for your business, providing a target to work toward and helping prevent token theft attacks.

One final thought to leave you with: Are you properly utilizing application allowlisting? Application allowlisting technology should be utilized on all systems that support it. The allowlisting should be derived from the organization’s approved software list.

---

If you find yourself needing assistance with any of the topics covered here or with the improvements you can make to your program to mitigate token theft attack risks, we’re happy to help!