Microsoft 365 Phishing Token Theft Attack

Identity Provider (IdP) token theft is a growing tactic in todays phishing attacks. Token theft can happen in many ways but a common real world method is token theft through a phishing email/site. Here I will map out the attack chain that I've seen and become familiar with.
IdP Token Authentication
We will start with a brief overview of how token authentication works. When a user first tries to access a services that uses Entra IdP, it verifies their identity through many different methods such as passwords, biometrics, or multifactor authentication. Then, Entra issues an identity token (Access and Refresh tokens). The token is a secure credential that can then be used on various applications that use Entra IdP without having the user login again. This also maintains the user's session for certain amount of time, depending on your organization's settings.

Token Compromise Attack
Attackers are using a Man-in-the-Middle methodology to capture the session token, issued in step 4 of the Entra ID token flow, then replaying that session token to compromise the user account.
MITRE ATT&CK has a specific framework for Office Suite and Identity Provider. For this I was able to use the Office Suite framework to map out the kill chain.


Initial Access
In this specific kill chain, it usually begins with a phishing tactic (T1566.002) to get the user to click on a link to a compromised webserver that is hosting a fake Microsoft login screen. The phishing tactic can be a email, text message or even vishing. But in this particular instance it was a fake secure file sharing email.

Clicking on the link in the email will send you to a compromised webserver containing a fake Microsoft login. The URL, most of the time, will be an obvious sign that it is fake. In more targeted attacks, I've seen an attacker compromise a trusted company's website to host a malicious webpage like this. But the fact that it is not using any Microsoft domains, tells us that this is a fake login website.

Once the user enters their credentials on the malicious webserver that is impersonating Microsoft, it will then prompt for MFA. After that is completed the attacker will then have the session token to be able to compromise the user account.

Defense Evasion
Once the token is compromised, the first tactic the attacker begins with is defense evasion by creating email inbox rules (T1564.008). This is usually to delete or move emails to unused Outlook default folders like RSS Feeds or Archive. These are usually to hide any email security alerts, responses to internal spear phishing emails sent to the compromised account, or any emails keywords from known retailers if the attacker wants to do some shopping.
There are many ways that the attacker can set up defense evasion techniques. One example is clearing the entire mailbox, this is less subtle than before but it does happen. Make sure to have backups!
Maintaining Persistence
After setting up defense evasion tactics, the attacker attempts to maintain persistence by adding an additional MFA method to access the account (T1556.006). With the rules in place on the inbox, depending on your organization's IdP notification settings, it is likely the user will never find out another MFA method has been enrolled.
Once persistence is established, there is usually a delay in 12-48 hours and then ingress from a different IP (Most likely a VPN server) on the compromised account. This is suspected that the account access is being sold on the dark web by initial access brokers. Another interesting note is that most attackers that access these accounts, do so from VPN servers based in the US, as to not trigger any out of country authentication/impossible travel alerts.
Collection/Exfiltration
Once persistent access has been established, by either the initial attacker or by the attacker that purchased the initial access, then you start seeing signs of collection and data exfiltration.
The first is usually email collection (T1114.002). There are many different automated tools out there for scanning email mailboxes for sensitive information like credit cards and bank account information. If it is a more targeted attack, there are usually logs showing them searching for company intellectual property.
After that, the attacker usually looks through the collection of files from data repositories accessible to them, like SharePoint and OneDrive. Once the targeted data is found, it is exfiltrated through either email forwarding rules(T1114.003) or over the web(T1567).
Lateral Movement
After exfiltration, the account is then used for lateral movement to other accounts. The most prominent way this happens is through internal spear phishing(T1534). The tools that attacker usually have are automated tools that pulls the entire recipients address book and sends out a malicious email and/or teams message to the recipients.
Depending on the organization, this can be very effective as some email gateways don't scan internal traffic and the email looks very legit as it is a coworker sending it to the intended target. User awareness training is important!
Ways to Protect from Token Compromise Attacks
As the need for token theft protection grows, here are some ways to protect your organization from these attacks.
Conditional Access Token Protection
This feature of Microsoft Entra cryptographically ties the token to client secrets. This prevents any kind of token replay attacks from occurring from a different device.
This seems like an effective way to protect tokens. But here's the kicker, Microsoft is making it a Entra ID P2 feature... which is apart of E5. So if your organization is on E3, you will need to buy the P2 upgrade.

Conditional Access Policies
Using general conditional access policies, you can enforce certain checks to take place before a user can authenticate. Such as, requiring a compliant organization device, only able to authenticate from certain locations or IPs, or implementing an improved client list.
For some organizations, these controls may be too restrictive or too cumbersome to maintain but they are very useful in creating a secure access control program for your IdP.

Conditional Access Evaluation (CAE)
This is a feature apart of Entra conditional access policies under the session section. It allows access tokens to be revoked based on certain events or policy evaluations, rather than just the token expiry based lifetime. Some of the events that are evaluated are:
- User Account is deleted or disabled
- Password for a user is changed or reset
- MFA is enabled for the user
- Administrator explicitly revokes all refresh tokens for a user
- High user risk detected by Microsoft Entra ID Protection
Whenever these are evaluated, the token session will be revoked and the user will be forced to reauthenticate and receive a new token.

Short Token Lifetimes
Utilizing a short lifetime for tokens can limit the time that the attacker can utilize the stolen token.
According to NIST 800-63B, for a moderate baseline (AAL2), the recommended session life time is 12 hours for reauthentication. For the low baseline (AAL1), it is 30 days. This is a balance you have to find within your organization, but having a longer time frame enables the attacker to different routes or even selling your access on the dark web.
References


