How attackers can bypass phishing-resistant MFA

In previous articles, I’ve talked about how Passkeys are one of the strongest forms of MFA that you could roll out in an organization given that they are considered phishing resistant and can protect us against threats like a man in the middle attack. It’s unlikely that many of us have reached a maturity level where we can look at rolling out passkeys to our customers, but I wanted to write this article to show how users can still be breached in Microsoft 365 even with this form of MFA in place. The example I am going to show of the breach is something I have seen in real life from an organization that I have consulted with in the past. In their case, they transferred 530k to a fraudulent bank account after having multiple users compromised within the organization. I will also share my thoughts on how you can protect yourself from this attack leveraging various security protections native in Microsoft 365.

Quick background on the attack method

The initial attack comes from something known as pass-the-cookie attack. You may have heard this by other names like cookie hijacking. Most websites store session cookies when a user signs in to their service, Microsoft is no different. The lifetime of these sessions by default in Microsoft is 1 hour but through continuous access evaluation, they can re-evaluate the session and determine that it can continue given certain conditions. While Microsoft’s lifetime is 1 hour, cookies from every website will vary. Cookie hijacking has been going on for years, but I wanted to show you how this can happen with a Microsoft account specifically.

Initial User Compromise

In my scenario, we will assume the organization has taken extra security measures to ensure their users are set up with Phishing resistant MFA. In this case, the user we will look at has set up a Yubikey to login with Microsoft.
The user can still access their Microsoft account on their personal device. This device is not managed by the MSP and is prone to weaknesses such as:
1. Hardware out of date
2. The device isn’t patched
3. The device doesn’t have basic security protections like AV (or even substandard AV software)

*Just to call out that while we see the personal device example, it does not mean that this cannot happen on a managed machine. The propensity for breach is just higher on personal devices*

3. When the user signs in they authenticate with their Yubikey and their session cookie is stored in the browser

4. The method the attacker users to get initial access can certainly vary but one of the most popular forms at the time of writing is sending malicious link in email. In this example, we are saying that the company uses workday as their hr platform and the attacker sends out an email disguised at that platform sending an automated message with a link to click on. (ex. “We need you to approve Jane’s time off request, click on this link”)

a. The user can also get exposed via the other methods shown as examples

b. After the user clicks on the malicious link, malware is deployed to the device

5. After the malware is running, the attacker can remotely run programs or scripts to extract the cookies from a browser like Chrome. Leveraging the cookie for the Microsoft session, the attacker can manually insert the cookie into a browser on their local device and refresh the page to automatically sign into Microsoft as that user. The user is now compromised.

Persistence

Depending on the attackers goals and user they compromised, there is a variety of things they might do next but one of the first action items would be taking steps to achieve persistence in the account.

6. Recall, the session token is only good for 1 hour in Microsoft and through CAE, their session token is likely to be terminated when checked again and seeing a new IP address. The attacker will likely know this as well and look for ways to maintain their access.

7. Common methods the attacker will look to do is to:

a. Join a device to the tenant to make it look like it is a trusted device on the network

b. Join a secondary MFA Method to ensure they can re-authenticate to keep the session alive

8. The actions the attacker takes next depending on their goals. In this case their intention is to get the organization to move money to a fraudulent bank account. To do this, they may need to compromise other users or spend some time doing reconnaissance in the account to identify the users responsible for payments (as an example).

Movement of Funds

9. Once the attacker has a plan, they will usually clean up the inbox to hide their initial attack and will also create inbox rules to avoid being detected by the legitimate user. Often these rules correlate with the additional users inside or outside the org that they want to compromise. The actions taken for the inbox rule often automatically move messages to archives and/or mark as read. They want to conduct campaigns against these users without being noticed

10. The attacker might target 1 to many users but is leveraging the initially compromised user to get to their goal. In this case the attacker reaches out to multiple users saying that one of their suppliers updated their bank account information for ACH of their regular payments. The attacker will either collect the information manually in email or generate another fake webpage to “update” the information.

11. From there, the money is transferred to their fraudulent account.

Preventing this Attack

Now lets walk through this attack again and see how we can prevent it via various security protections in Microsoft. Keep in mind that most of these recommendations are not turned on by default.

As mentioned, Passkeys are one of the strongest forms of MFA so we are very locked down in the sense of our MFA method.
Users should be prevented from accessing corporate data on personal devices. If this cannot be supported in an organization, you should make them required to be enrolled in Intune and have baseline requirements for these devices to access data (such as minimum OS, AV installed, etc.). This will significantly reduce the likelihood of malware being installed on the device. Requiring device compliance via conditional access is another way to provide further protections. If an attacker captured the session token and tried to use it on their device, they would be blocked

3. You could technically enforce Conditional Access Policies to enforce non-persistent browser sessions but I have another CAP that I think is better which isn’t so disruptive to the end-user. They will quickly get frustrated with you if you are booting them from their session every hour

4. Defender for Office 365 has native phishing and link protections that could help discover these malicious emails or attachments coming in. Real-time click protection is available and can help prevent malicious links from being accessed if a user does click on them.

Windows Defender can also assist here in blocking a malicious exe onto the device if the link was still access by the user. Devices can be enrolled in Microsoft Defender and AV policies can be configured in Intune. This comes part of your licensing if you are on Business Premium.

5. The most restrictive way to prevent the pass-the-cookie attack if a device is compromised is to enforce strict CAE in a conditional access policy. This requires that you configure trusted locations in Entra where users can access data. This basically takes CAE a step further to say if the user if not at one of my trusted IPs, then the session should be terminated. If an attacker was to retrieve the session token, they would not be able to compromise the user given their IP address would be different on the device they were using to try and login with.

Microsoft also has another setting right now in preview called “Require token protection for sign-in sessions” which currently does not support web cookies today, but I am hoping will be in the near future. This would also help prevent this attack without needing to have trusted locations configured which is hard to do in most organizations.

6. Outside of the session, its possible that the native Identity protection capabilities in Entra would detect the updated session as suspicious given the IP address it was coming from. If you have Entra ID P2, this also should be able to detect and automatically block the user through Identity protection policies. This is also detected as part of the native protection of CAE.

Current CAE near real-time detections:

7. To combat device join, you can add a Conditional access policy that requires MFA to register a device in Entra. Since this user leverages passkeys, the attacker would not be able to re-fulfill another MFA prompt to join the device to the network. To prevent the attacker from adding another MFA method, you can use the same “User Actions” setting in a conditional access policy to say they need to be on a trusted IP, trusted device, and/or fulfill with another MFA request.

Additionally, you can configure your authentication methods policy to prevent other forms of MFA from being added. In our example, if we said that only FIDO2 keys were allowed, the attacker wouldn’t be able to add something like Authenticator, OTP, or SMS/Email as a second factor. If you think about it with passkeys, they also would not have harvested the UN/PW given they did not collect that via the session token. A man in the middle attack would allow them to do that.

9. For many of us, we have set up a transport rule in Exchange Online to prevent automatic forwarding of email to external domains. That is a hardening policy recommended for many years now. This policy doesn’t cover the evasion tactics from an attacker leveraging rules to mark emails as read, moving them to archive, etc. Defender for Office 365 in Microsoft has some native alerting capabilities that could detect us on suspicious inbox rules being created. This natively will go to the admin users in the tenant but many of us have not set this up to go to our ticketing system. You want to triage these alerts in your ticketing system for further investigation to detect this potential malicious activity.

Additionally, Defender for Cloud Apps has native protections for detecting suspicious inbox rules. This is something you can configure with a Business Premium License.

10. Since this campaign may be coming from an internal user its possible that the native email protections in Microsoft will not catch if an attacker starts emailing other users in the organization. This is where security awareness training should play a big part in users being able to detect malicious activity. Anything regarding financial information should always be viewed as alarming to the user and we can reinforce that through automated and manual training.

Conclusion

I hope this article provided you some targeted guidance on common attack methods and subsequent protections in Microsoft 365. Business Premium is still a very powerful solution to help prevent these attacks. Email me if you have any questions or would like to have any consulting done in these areas!

msp4msps@tminus365.com

Stay vigilant!

Share with the Community

How attackers can bypass phishing-resistant MFA | Use these protections!

Bymsp4msps

Quick background on the attack method

Initial User Compromise

Persistence

Movement of Funds

Preventing this Attack

Conclusion

By msp4msps

Related Post

My top policies for securing device registration in Microsoft 365

Require managed devices in Microsoft 365

Customer needs personal device access for Microsoft 365 | Secure Options