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 the depreciation of basic/ legacy authentication. With 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.
Since Oktober 1, 2022 Microsoft started permanently disable Basic Authentication for Exchange Online in all tenants (except SMTP Authentication). In 2023 more new features are scheduled for preventing new attacks by default (Number matching)
Most of the techniques are explained earlier and more in-depth on my blog – see this blog as an overview of new attacks and updated around the identity protection space.
| Blog information: Blog is written based on my own opinion. Blog published: August 31, 2022 Blog latest updated: February 4, 2023 |
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 as part of this blog)
- Azure AD Workloads/ Service Principals.
MFA is no protection and guarantees against attacks. MFA prevents most of the attacks; with MFA there is still some room for attackers to use 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.
Risk factor
Following Microsoft; 98% protection is possible by utilizing antimalware, applying for 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).
Must read from Microsoft DART: Token tactics: How to prevent, detect, and respond to cloud token theft
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
Protection
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 | ✅ |
| Certificate-based authentication | ✅ |
| 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 generally available. 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 Microsoft Authenticator. We will remove the admin controls and enforce the number match experience tenant-wide for all users starting May 8, 2023.
Microsoft
We highly recommend enabling number matching in the near term for improved sign-in security. Relevant services will begin deploying these changes after May 8, 2023 and users will start to see number match in approval requests.
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 manually in the app itself for completing the MFA request.
Update 2023: Number matching is the default. Microsoft starts May 8, 2023 with global enablement for all users. Push notification on Authenticator with Approve/Deny will be completely replaced with number matching. The change is for Azure AD only. More information: How to use number matching in multifactor authentication (MFA) notifications – Authentication methods policy
Normal MFA:
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/emails. 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
Attack flow
Below is a simple overview of a phishing attack and all the steps:
- The 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. A good collaboration example is in the case of Primary Refresh Tokens:
Primary Refresh Token (PRT) is a special high-privileged refresh token. Compared to the 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 Azure AD 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 share holistic compromised identity signals and share 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 privileged 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, and block it for all apps and protocols)
- 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
Sources
Microsoft: Holistic compromised identity signals from Microsoft
Microsoft: Token tactics: How to prevent, detect, and respond to cloud token theft
Own attack-related blogs
Each attack is more explained in-depth on the below pages:
Jeffreyappel.nl: MFA prompt spamming/ MFA fatigue – What can you do to prevent/ detect attacks?
Jeffreyappel.nl: Protect against AzureAD OAuth Consent phishing attempts (Illicit consent attack)
Jeffreyappel.nl: Protect against AiTM/ MFA phishing attacks using Microsoft technology
Community resources
Recommended community resources:
GitHub: Azure AD – Attack and Defense Playbook
Cloudborhters.info: Continuous access evaluation
2 Comments
Leave a Reply
You said FIDO2 security key would protect against AITM, what about WebAuthN?
I believe WebAuthN should also, protect against.
Great articel. But can you elaborate on why Azure AD Identity Protection will not prevent an attach?
Let’s say that you have set the Sign-in risk policy “Controls” to “Block access”. Will that have any effect?