Tips for preventing against new modern identity attacks (AiTM, MFA Fatigue, PRT, OAuth)
Identity attacks are currently changing and focussing on new techniques. In the past years, many organizations protected accounts with MFA/ FIDO2 and configured additional controls like Conditional Access and disablement of legacy authentication. After some years Microsoft starts finally with the depreciation of basic/ legacy authentication. With the more strict protection attackers need to find new ways for bypassing the security layer (MFA, 2FA, Legacy Authentication). Still no MFA, Conditional Access, or Legacy Authentication? Don’t wait and take action.
Note: Blog is written based on my own opinion.
Since the recently published Twitter story – there were many followers asking for a summary article. Most of the techniques are explained earlier more in-depth on my blog – see this blog as an overview for new attacks.
|Blog information: |
Blog published: August 31, 2022
Blog latest updated: August 31, 2022
What is the risk with MFA/2FA enabled?
In the last couple of months, there is an increase in modern/ future phishing attacks using new techniques where MFA gives no protection. The following techniques are more detected and require additional protection/ attention and adoption:
- Adversary-in-the-middle (AiTM) phishing
- MFA Fatigue/ MFA Spamming
- OAuth Consent Phishing attempts
- Primary Refresh Token (PRT) abuse
- Device Token theft (not added yet part of this blog)
- Azure AD Workloads/ Service Principals.
MFA is no protection and guarantee against attacks. MFA prevents most of the attacks; with MFA there is still some room for attackers using new techniques like AiTM phishing, importing stolen tokens, and more. Attackers are finding always new ways to bypass security protections.
Phishing remains to be one of the common techniques used by attackers in their attempts to gain initial access.
Following Microsoft; 98% protection is possible by utilizing antimalware, applying least privilege access, enabling multifactor authentication (NOT ALL MFA), keeping versions up to date, and protecting data. Following Microsoft 2% of the remaining attacks include outlier attacks. Recommended read: Microsoft Digital Defense report
Image source: Microsoft
Adversary-in-the-middle (AiTM) phishing
Adversary-in-the-middle (AiTM) phishing is not new; and available for some years. Phishing is still the most common type of attack. MFA provides an added security layer against credential theft. Unfortunately, attackers are also finding new ways to bypass the additional security layer (MFA, 2FA).
Microsoft Threat Intelligence Center (MSTIC) shared some time ago an interesting blog focussing on AiTM attacks with the following information.
Based on our threat data, the AiTM phishing campaign attempted to target more than 10,000 organizations since September 2021.@Microsoft MSTIC
Traditional credential phishing sites collect the user’s credentials and never complete the authentication process. When MFA is enabled for the user it prevents the attacker from logging into the account with the stolen credentials.
Adversary-in-the-middle (AiTM) phishing attacks are used for bypassing multi-factor. AiTM attacks complete the authentication process and captured the token. Currently, there are three main open-source AiTM phishing kits available that are widely known:
The below image explains the AiTM phishing process (credits: Microsoft)
Capture tokens using Evilginx2
Evilginx2 is one of the most popular AiTM phishing kits. Evilginx2 does not serve its own HTML look-alike pages like in traditional phishing attacks. Evilginx2 is a man-in-the-middle attack framework used for phishing login credentials and session cookies.
After phishing the tokens are captured and visible in phishing kits like Evilginx2.
More Evilginx2 information can be founded in the following blog post including interesting videos: Protect against AiTM/ MFA phishing attacks using Microsoft technology
Where the detection is not easy ( working on a blog post) – some preventions can be configured to restrict the abuse of Evilginx2.
The first prevention is to use phish-resistant sign-in methods:
|Method||Protected against AiTM|
|FIDO2 security keys||✅|
|Windows Hello for Business||✅|
|Passwordless phone sign-in||❌|
|Phone number and SMS||❌|
|Username and password||❌|
Another prevention is possible with the use of Conditional Access and additional controls. When using MFA and configured with additional controls it is possible to prevent AiTM.
|Method||Protected against AiTM|
|Require device to be marked as compliant||✅|
|Require device to be marked as Hybrid Azure AD joined device||✅|
|Conditional Access Session Controls||❌ ( limit time window)|
|Conditional Access Trusted Locations||✅|
|Continuous Access evaluation CAE||❌ ( only revokes access in real-time when changes in user conditions|
Protection with Microsoft technology
Additional security toolings are not preventing AiTM. The following is advised:
- Configure Azure AD Identity Protection and take automated actions when the user/ sign-in risk is medium or high.
- Use sign-in frequency/ persistence of browser sessions “More info“
- Track sign-ins from different locations using MFA
- Configure the basics
- Continuous Access Evaluation/ CAE
- Block legacy authentication
- Use Conditional Access based on risky signals
The following alerts are important in detecting AiTM phishing:
- Microsoft 365 Defender
- Stolen session cookie was used
- Defender for Cloud Apps
- Suspicious inbox manipulation rule
- Impossible travel activity
- Activity from infrequent country
- Azure AD Identity Protection
- Anomalous Token
- Unfamiliar sign-in properties
- Unfamiliar sign-in properties for session cookies
- Anonymous IP address
- Defender for Office 365
- Email messages containing malicious file removed after delivery
- Email messages from a campaign removed after delivery
- Creation of forwarding/redirect rule
- Defender for Endpoint
- Potential phishing website
View detailed prevention information including an example video in the following blog post: MFA phishing attacks using Microsoft technology
MFA Fatigue/ MFA Spamming
MFA fatigue / MFA Spamming is not new and used for quite some time. Since LAPSUS$ the attack is more in the news.
The most common question when discussing MFA prompt spamming; MFA is secure right? Yes – it depends on the type of MFA. Of course, it’s better than no MFA configured. SMS is always better in comparison without any second factor enabled.
When the username/password is available, you can just generate an MFA prompt (via push, call, etc). MFA prompt spamming is a well-known attack where the victim is generating MFA prompts and hopes the user/target accepts the MFA request. They keep spamming until they accept the MFA prompt that allows them to get initial access.
Lapsus$ highlighted the weaknesses of certain MFA options. Specifically push approvals. Once they had the victim’s credentials, they would simply spam users with MFA prompts until they got approved.
A member of Lapsus$ wrote on the group’s official Telegram chat channel.
“Call the employee 100 times at 1 am while he is trying to sleep, and he will more than likely accept it. Once the employee accepts the initial call, you can access the MFA enrollment portal and enroll another device.”LAPSUS$ Telegram
Protection with Microsoft technology
Protection/ prevention against MFA Fatigue / MFA spamming is possible using Microsoft technologies and built-in features. Most important is awareness and reporting real attempts. Explain to users; MFA can be abused and is not always safe and correct. Sometimes MFA is known as; always safe and good. Adoption / Awareness is also with MFA enabled important.
The following is recommended:
- Use AzureAD Identity Protection sign-in / user-risk policies
- Enable Azure MFA number matching/ MFA codes
- Implement advanced authentication features using geography
- Create sign-in risk-based policies that block high-impact actions like device enrollment and MFA registration
The following AzureAD features are currently in preview:
- Azure MFA number matching
- Show additional context in notifications
Number matching is currently in public preview. Microsoft gives the following explanations and marks the feature as a key security upgrade to traditional second-factor notifications in the Microsoft Authentication app.
Number matching is a key security upgrade to traditional second-factor notifications in the Microsoft Authenticator app that will be enabled by default for all tenants a few months after general availability (GA). We highly recommend enabling number matching in the near-term for improved sign-in security.Microsoft
Number matching gives improvements against MFA Prompt spamming and will increase the security posture of MFA Authentication prompts. When a user responds to an MFA push notification using Microsoft Authentication App, they will be presented with a number. The user needs to type that number into the app to complete the approval. Attackers don’t have access to the device/app where the code needs to be filled-in. For the attacker the code is visible; only the code needs to be added manual in the app itself for completing the MFA request.
Number matching + additional context enabled:
More information and explanation including the configuration and hunting are explained here: MFA prompt spamming/ MFA fatigue – What can you do to prevent/ detect attacks?
OAuth Consent Phishing attempts
In the last couple of months, there is a large increase visible in consent phishing emails (illicit consent attacks). Microsoft threat analysts are tracking a continued increase in consent phishing attempts/mails. Consent phishing is not new and used for quite some time.
Consent phishing attacks (Illicit consent attacks) abuse legitimate cloud service providers, including Microsoft, Meta, Google, and others that use OAuth 2.0 authorization. OAuth 2.0 is a widely used protocol that allows third-party apps to access account details and perform an action on their behalf.
The main goal of a consent phishing attack is to let users grant permissions (content) to apps that are owned by the malicious attacker. The attacker then tricks an end-user into granting that application consent to access their data
Below is a simple overview of a phishing attack and all the steps:
- Attacker registers malicious app with OAuth 2.0 provider with the name “Upgrade”
- Attacker sends Email-based phishing including OAuth 2.0 URL
- User open e-mail phish
- User click on OAuth 2.0 link
- Consent message visible
- User grants access to malicious app ( including permissions)
- Authorization code sent to attackers (App registration Identity Provider)
- Access to user data based on API/ OAuth2.0 grant
Below consent ask the user for the following permissions:
- Read and write your files
- Read your calendar
- Sign you in and read your profile
If a user accepts the request, the attacker (malicious app) has permission to the target Office 365 account. Quite hard to discover right?
Protection with Microsoft technology
Protection/ prevention against MFA Fatigue / MFA spamming is possible using Microsoft technologies and built-in features. The following is important:
- Enable Azure AD Admin CONsent Workflow or disable registration of apps completely
- Review existing apps in AzureAD/ Defender for Cloud Apps and remove permissions
- Enable Defender for Cloud Apps
- Enable the following Defender for Cloud Apps alerts
- Malicious OAuth app consent
- Suspicious OAuth app file download activities
- Unusual addition of credentials to an OAuth app
- Unusual ISP for an OAuth App
- Misleading OAuth app name
- Misleading publisher name for OAuth app
- Enable AzureAD Identity protection and review Workload identities
Defender for Cloud Apps policies
More information and explanation including the configuration and hunting options are explained here: Protect against AzureAD OAuth Consent phishing attempts (Illicit consent attack)
Primary Refresh Token
Use toolings like Defender for Office / Defender for Endpoint. More and more collaboration is available in products. Good collaboration example is in case of Primary Refresh Tokens:
Primary Refresh Token (PRT) is a special high privileged refresh token. Compared to Active Directory it is equivalent to the Ticket Granting Ticket (TGT). PRT is a token stored on the device. (Cryptographic keys stored in TPM).
Primary Refresh Tokens are used for Azure AD Registered devices, Azure AD Joined devices and Hybrid AzureAD joined devices. PRT tokens can be used to authenticate against any application and can be updated with an MFA claim.
The combination of products is interesting where Azure AD Identity Protections sharing holistic compromised identity signals and shares events.
When a possible attempt to access Primary Refresh Token (PRT) is detected by Defender for Endpoint it will generate a premium alert in Azure AD Identity Protection. Using response actions in Azure AD Identity Protection it is possible to block automatically users based on the risk level.
When Azure AD Identity Protection and Defender for Endpoint is available and onboarded the risk signals will be shared automatically.
General Identity tips
Above the preventions against some of the “new” attacks are explained. For protecting identities more preventions can be configured. The following is based on my opinion important:
- Use Privileged Identity Management PIM and go for least privilege access and always verify roles. Privileged Identity Management is not protecting against AITM and stolen cookies. For any Identity attack and special Oauth Consent / Device Token it is recommended to strict the available roles and request MFA + approval.
- Enable MFA for all users and admins ( except some break-glass accounts)
- Block legacy authentication ( DON’T WAIT FOR MICROSOFT)
- When MFA is not possible; restrict service accounts based on trusted locations
- Collect AzureAD Logs in Sentinel / Log Analytics and start additional hunting
- Enable Password hash synchronization
Own attack-related blogs
Each attack is more explained in-depth on the below pages:
Recommended community resources:
Cloudborhters.info: Continuous access evaluation