Account Compromise Arms Race: How Threat Actors Evade Phish-Resistant Security Tools

Phishing remains one of the most effective cyber threats, constantly evolving to outmaneuver security measures designed to prevent account compromise. Today, multi-factor authentication (MFA) and passkeys offer robust layers of protection, but threat actors are developing new methods to circumvent these defenses.

In this second edition of the Account Compromise Arms Race blog series, we explore how cybercriminals exploit session hijacking, info-stealer malware, and consent phishing to bypass security controls and gain unauthorized access to accounts.

So, you’ve implemented MFA and while that’s essential in preventing account compromise through plain old credential theft, it does nothing to address session cookie theft, which leaves threat actors with a variety of responses to choose from.

Response 1: Session Hijacking

Credential phishing via session hijacking is probably the most prolific account compromise method in today’s email-centric world. The example below illustrates an attack on Microsoft 365, but the same tactic can be applied to many other mainstream SaaS services.

This method leverages a proxy in the middle (usually based on the Evilginx proxy framework) and follows some quite simple steps:

1. A threat actor sends a phishing email to multiple targets. Phishing-as-a-Service (PhaaS) makes this easy, as it typically provides an SMTP mail-out tool or WebUI, and includes target-tracking scripts in the email or a 1x1 pixel image to register who’s opening the malicious email.
2. When the target clicks the link or opens the HTML attachment, they see a Microsoft login panel that looks authentic but actually proxies credentials—including the MFA token—directly to Microsoft. PhaaS platforms generate dynamic URLs unique to each target, rendering even the best threat intelligence ineffective since each link is brand new. Worse, these dynamic links are often paired with recently compromised domains, meaning a domain reputation-based security solution will not see a problem.
3. Login credentials—including the MFA token or authenticator app response—are relayed through the threat actor-controlled proxy to Microsoft, allowing the target to authenticate as usual.
4. Microsoft issues a session cookie, which the target's browser stores.
5. The session cookie is essentially a key that grants the holder access to the Microsoft account they’ve just authenticated, which includes not only email but other Microsoft services as well, including Teams, OneDrive, and Sharepoint, to name a few.
6. The attacker's proxy, having captured and relayed the entire login process to Microsoft, steals the session cookie and notifies the attacker through various channels, such as a Telegram bot, Slack or Discord webhook, email, or an HTTP POST to the PhaaS service.

7. Once in possession of the session cookie, the threat actor simply plugs the cookie into their browser using Chrome developer tools or a dedicated Chrome extension.

8. Hey presto! The threat actor now has the same access as the target. Email, Teams, OneDrive, SharePoint, and many more platforms are now at the mercy of the threat actor. And the target is blissfully unaware as they remain logged in too!

Disappointingly, at the time of stolen cookie re-use, Microsoft simply allows the new sign-in, stating “MFA requirement satisfied by claim in the token”.

On the plus side, however, Microsoft’s Conditional Access Policy (CAP) is assessed at the time of stolen session cookie re-use, so a CAP can be applied that checks other conditions, e.g. is the login location (aka “Network”) matching a list of expected countries, or does the login device match a sanctioned list of manufacturers, models, operating systems, etc.

Of course, this method isn’t much use if your users and attackers are both in the same country or if the attacker is using a VPN to appear as though they’re in the same country as your users.

Response 2: Info-Stealer Malware

This method is a client-side attack and requires no proxy or “Attacker in the Middle” (AitM)—as per the session-hijacking attack covered previously. The threat actor gains access in a few simple steps:

1. The target clicks a link or opens a website with malware (even website ads are being compromised to carry malware), or they download and run some script or executable that installs info-stealer malware.
2. The target logs in as normal, with no indication of foul play.
3. A session cookie is issued to the browser as normal.
4. The target gains access to their M365 account, which likely includes more than just email.

5. The target's device, running info-stealer malware, detects that a session cookie is available and simply delivers it to the threat actor.

6. The threat actor now has the same access to the M365 service as the target and, just like before, the target is blissfully unaware as they remain logged in too.

Info-stealer malware is constantly evolving, as described in several Bleeping Computer articles from late 2024, such as this one and this one. Down under, the Australian Cyber Security Centre (ACSC) published an advisory on the topic in September 2024 due to its sudden rise in prevalence across multiple organisations worldwide: The silent heist: cybercriminals use information stealer malware to compromise corporate networks

Response 3: Consent Phishing

In addition to session hijacking or info-stealer malware, threat actors can also gain access through consent phishing. This involves:

1. Creating an App (or taking over the code repository of an existing one) that will make an OAuth connection to M365 or other SaaS being targeted.

2. Tricking the target into clicking a link and giving consent to connect the OAuth app to their primary email service (usually M365). The target may already be familiar with this process, having previously connected SaaS apps like Salesforce, Workday, and others to their Microsoft account—so is likely to just click away!

3. Leveraging these new permissions granted by the target, allowing them to read and write emails, files, and calendar entries, for example, using the target's M365 account.

While MFA will prevent the re-use of stolen credentials and is therefore somewhat phish-resistant, where do passkeys fit in? Will they be the end of phishing?

Firstly, what exactly is a passkey? Well, it’s simply a private key (that you keep to yourself) and a public key (that the site you’re logging into has) and they’re linked cryptographically.

The service you’re logging into will use your public key to validate that you can correctly sign something with your private key. Only your use of the correct private key to sign the request will return the correct signing result. And the nice part? Your private key is never transmitted beyond your local browser, password manager, or hardware key. This means that if a threat actor steals all the passkeys (public keys actually) from excellent.website[.]com, they can’t use those to access your account on excellent.website[.]com, or anywhere else for that matter.

The private key portion of the passkey can be either:

• Device bound e.g. stored on a YubiKey. There is no backup or sync to other devices like your phone with this method, but it does provide the most secure way to store your private key. Note that the YubiKey-5 can only store up to 25 passkeys, so it may not be suitable for ubiquitous login to all of your SaaS services—maybe just the most critical.

• Synced, meaning the private key is stored in software via a browser or password manager and synced across devices. This method is highly convenient: add a passkey in Chrome on your desktop and—hey presto!—it’s instantly available on your phone (as long as you're logged into Chrome with sync enabled). Of course, this convenience comes at a security cost, as the private key is now spread across multiple devices with varying security levels.

Each passkey you create is tied to the specific SaaS or website you’ve just enrolled your passkey in. So, if you decide to use Chrome, Apple Passwords, and a YubiKey for storage of your passkeys and enroll a passkey for M365, GWS, and AWS, then you’ll have at least nine passkeys, with additional passkeys synced to your other Apple or Chrome devices.

Do Passkeys Make You Phish Resistant?

Yes, passkeys will certainly make your accounts more resistant to session hijacking (as per the example in Figure 11 below). However, just like with MFA, there’s still one small—actually large—problem: the session cookie. On the plus side, each passkey (the private key specifically) is directly associated with the site URL you’re logging into, meaning those pesky phishing URLs that attempt to send you to a proxy site (see session hijacking above) will not work with a passkey.

So, to break down how this works:

1. The treat actor uses PhaaS to generate a malicious proxy URL and phishing email that claims an M365 login is required.

2. The target clicks and is presented with a Microsoft login panel that is a proxied login to M365. The target selects a passkey as their login method. Ideally, they shouldn’t be given the choice to use a traditional username/password as this can be exploited (see response 2 below).

3. The session is proxied through some other URL, e.g. mrsft-online[.]com—a clever look-alike domain in this example.

4. M365 Entra then looks up the passkey belonging to the target and uses the associated public key to challenge with a signing request.

5. The target's browser performs an “origin-check”—essentially checking whether the signing request come from the same URL that was originally stored with the passkey for the site that the user is trying to log into.

So, in this case, “mrsft-online[.]com," from the proxy in the middle, doesn’t match login.live[.]com from the website.

Let’s look at how threat actors are responding to passkeys.

Response 1: Session Cookie Theft

In Figure 12 below we see a login to office[.]com which requires authentication via microsoftonline[.]com. I’ve chosen to use a passkey, but as you can see in the Chrome developer tools on the right of the graphic, I still get the same old session cookies (prefixed with ESTSAUTH*), as I would if I logged in with a password.

Figure 12: Sign-in with a passkey still delivers session cookies which are vulnerable to theft

How are these cookies now stolen? Quite simply, via info-stealer malware as described above or a malicious browser extension. Cross-site scripting is another available method, according to OWASP.

Response 2: Remove the Passkey Option

Then there’s the good old fall-back to username/password. In an excellent blog from eSentire in June 2024, they proved that the standard Github phishlet, which can be found in various user repositories on Github itself, could be proxied through EvilProxy and, with a slight change to the standard phishlet configuration, they were able to force removal of the “Sign in with a passkey” text:

The target will then simply dig out their normal username and password, and the traditional session-hijacking technique will then succeed.

Response 3: Move the Attack to a Phone

Threat actors will also use the humble QR code to move the attack to a phone, which is typically unmanaged and may not have the required passkey available.

So, clearly you must also go passwordless if you want to avoid your users having the option to fall back from passkeys to passwords.

As organizations adopt phish-resistant authentication methods, cybercriminals continue to refine their tactics. While MFA and passkeys enhance security, they are not foolproof. Defenders must stay vigilant by implementing additional security layers, such as continuous session monitoring, browser integrity checks, and rigorous endpoint protection.

This blog series will continue to explore emerging phishing tactics and best practices for defending against them. Stay tuned for our next installment, where we explore how behavioural AI can be used to detect phishing attempts and account compromises proactively.

Interested in learning how Abnormal can help protect your organization from advanced phishing threats? Schedule a demo today.