How to protect against modern phishing attacks like Evilginx
Modern phishing attacks are on the rise, and methods to defend against them are scarce and few. While I've shared numerous posts on how Evilginx works, I wanted to dedicate some time to investigating and understanding how to prevent Evilginx and other Man-In-The-Middle (MITM) style attacks based on personal experience. This guide is designed not only to prevent these attacks but also to cover other mitigation techniques commonly employed in Business Email Compromises (BEC).
To underscore the severity of the phishing threat, consider the following staggering statistics:
3 Billion Phishing emails are sent every day! - Valimail
36% of data breaches originate from phishing email - Verizon
The screenshot below highlights the percentage of businesses that have identified the following types of breaches or attacks in the last 12 months - Charities are heavily targeted too!
cyber-security-breaches-survey-2022
It's evident that phishing poses a widespread challenge affecting us all. The statistics mentioned earlier primarily address generic, low-effort phishing attacks, which are proving effective against both businesses and individuals. Modern style attacks are less common and even more effective!
What is the difference between standard phishing attacks and modern phishing attacks?
Modern phishing attacks
Typically revolves around some form of Man-In-The-Middle attack. There are multiple tools that are used but the most common is Evilginx. Modern phishing attacks aim to circumvent standard security practices, including Multi-Factor Authentication, often by employing token theft techniques.
Standard phishing attacks
Standard phishing attacks typically originate in a badly formed email. This email often contains a link to an attacker’s controlled website and often requests an email address and password. With Multi-Factor Authentication enabled, it should prevent most of these from succeeding. Password reuse is still an issue but it’s less likely to result in a Business Email Compromise (BEC)
Workflow of a Man-In-The-Middle attack
While Multi-Factor Authentication (MFA) is indispensable and effectively thwarts malicious actors attempting to gain unauthorised access, it's crucial to recognise and comprehend its limitations. MFA itself is not inherently flawed; rather, the challenge lies in the typical prioritization of usability over security. Cookies are a good example of this! When you log in to a website, a cookie is stored in your browser, serving as proof of authentication. This way, if you navigate to another page on the same website, the cookie acts as your authentication, sparing you from having to log in repeatedly however, if this cookie / token was stolen, it could negate the requirement for a username, password and MFA method to be submitted.
The graph below simplifies the delecate balance between usability & security.
As usability increases, security decreases and vice-versa.
How to prevent modern phishing attacks?
There are multiple layers of defence against a phishing attack so let’s start with a general overview and jump into more detail further below. It's crucial to emphasise that effective security should adopt a layered approach, recognising that there's no one-size-fits-all solution. To enhance your defenses against phishing and bolster your overall security posture, it's advisable to implement as many of the strategies outlined below as possible
Training and awareness
Understand suspicious characteristics, how to identify them, and the associated risks
Mail protection
Preventional measure but a great tactic and will do a good job at preventing most (not all) phishing emails
Web protection
Prevention again - If the website has suspicious characteristics, or it’s a newly created domain or a typo’d domain it can be blocked before any further action can be taken
Multi-Factor Authentication
A vital defense against many phishing attacks.
Hardware keys MFA (U2F)
Not all MFA methods are equal; U2F tokens, such as Yubikeys, are resistant to phishing due to their authentication process. More on that later!
Conditional Access Policies
A licensed feature within Microsoft 365; configures policies to significantly reduce the attack surface and implement preventative measues- Setup can be found further down
Compliant devices only
Continous Access Evaluation
Trusted locations only
Token Protection
Sign-in Risk Policy
This is currently being moved to Conditional Access Policies section, sign-in risk may not prevent the initial login but if suspicious factors are found, can automatically reset the password of the account which will refresh the authentication token and thus, invalidate the session. - Setup can be found further down
3rd Party Applications
These are commonly used by malicious attackers for multiple reasons but primilary the use of maintaining access to an account after password resets and/or social engineering an individual to consent to access - Setup can be found further down
Alerts
Always setup suspicious sign-ins, impossible travel, oAuth apps, 3rd party applications consent alerts, token theft (license dependant)
Conditional Access Policies
There are several conditional access policies that can help prevent and/or limit modern proxy-based phishing techniques like Evilginx. It's important to note that conditional access policies only come into effect during the initial login—specifically when the initial authentication process communicates with Entra ID. After the login and the establishment of a successful session, conditional access is not rechecked. This means that if a cookie is stolen, it can be used to login, even if the device hasn’t met the original policy criteria. - we can use Continous Access Evaluation (CAE) to fix this but more on that later.
Conditional Access Policy: Compliant Devices
Users: ALL (Exclude ‘break-the-glass’ account)
Target Resources: All Cloud Apps:
Condition: 0 Conditionals ( Optional but not needed )
Grant: Require Device to be marked as compliant
This policies requires all devices to be marked as compliant, otherwise the sign-in will fail. The screenshot below shows a sign-in from a device that is non-compliant:
The attacker will see the following:
Note, you can see the attacker can still acquire the username and password, but the token field remains empty. This token field would typically display the session token if captured successfully. However, in this case, the authentication flow is interrupted because the login request technically originates from Evilginx's server, which is identified as a non-compliant device. Consequently, Evilginx is unable to capture the session token.
It's crucial to emphasise that, despite the prevention of session token capture, the attacker can still gain access to the password.
In-Token Protection
When an attacker is able to steal a token by hijacking or token replay, they can impersonate their victim until the token expires or is revoked.
Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device.
Conditional Access Policy: In-Token Protection
Users: ALL (Exclude ‘break-the-glass’ account)
Target Resources: Exchange Online, SharePoint Online
Condition: No conditions
Grant: Grant Access
Session: Require Token Protection for sign-in sessions (Preview)
Requirements:
Windows 10 or newer devices that are Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered.
OneDrive sync client version 22.217 or later
Teams native client version 1.6.00.1331 or later
Power BI desktop version 2.117.841.0 (May 2023) or later
Visual Studio 2022 or later when using the 'Windows authentication broker' Sign-in option
Office Perpetual clients aren't supported
Token Protection is currently in preview, and still a work in progress, but it effectively safeguards accounts from token theft attacks. It’s functionality currently is limited to a few Microsoft applications, mainly Exchange Online and SharePoint Online.
Scenario:
In-Token Protection is enabled
Malicious Actor has stolen a session token
Upon logging in, the malicious actor will have access to the office.com screen. However, if they were to browse to Outlook or SharePoint Online, they will receive the following:
Token Protection is highly effective, with the primary limitation being that the device must be Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered.
As mentioned earlier, Conditional Access Policies only come into effect during the initial login, specifically when the initial authentication process communicates with Entra ID. Once the login is successful, and a session is established, Conditional Access is not rechecked. Consequently, if a cookie is stolen, it can be used for login even if the device isn't compliant. To address this issue, Continuous Access Evaluation (CAE) is necessary.
Continuous Access Evaluation (CAE) allows for policy reevaluation on any session, and it can do so in near-real-time.
Conditional Access Policy: Continous Access Evaluation (CAE)
Users: ALL (Exclude ‘break-the-glass’ account)
Target Resources: All Cloud Apps:
Condition: Any Location - Exclude Office Locations
Block: Cutomise continous access evaluation: ‘Strictly Enforce Location Policies’
Below is the user condition change flow of how CAE works when used with a network location policy.
So, say if you have an MFA policy that whitelists MFA when signing in from an office location (bad practice but that’s a topic for another time) The validity of this cookie is until it expires or a new sign-in occurs. In the unfortunate event that this cookie is stolen by an attacker, they can log into the account successfully from any location. As conditional access policies only take effect upon login and are not reapplied, the conditional access MFA will never come into play in this situation.
With Continuous Access Evaluation (CAE), it will perform a near-real-time policy reevaluation. This reevaluation will detect the change in network location and trigger the MFA conditional access policy, now requiring it to be met.
To setup CAE, we need to use session controls within Conditional Access Policies.
Continuous Access Evaluation (CAE) allows access tokens to be revoked based on critical events and policy evaluation in near-real time rather than relying on token expiration based on lifetime.
"Disable" works correctly when "All cloud apps" is selected, and no condition has been chosen. This setting does not work with report-only mode, but there are pre-published workbooks with data insights.
Strictly Enforce Location Policies:
Use this option to deny access when the client's IP address is not in the allowed location policy range. Configure location in the "Conditions" tab.
Now, suppose we have a policy that blocks any location except for our trusted IPs. Since the session cookie has been stolen, the trusted locations have technically already been met. This means the session cookie can bypass the initial authentication process with Entra ID. In a normal scenario, this would render the location policy ineffective, as our session token has already satisfied the criteria.
However, as we’re using Continuous Access Evaluation (CAE), it will in near-real-time reveluate the policy. This will detect any locational-based changes.
I am using a VPN to change my IP to imitate an attacker who has stolen the token. I am now going to use the stolen cookie.
It reevaluated the policy and identified that my current location is not within the scope of my trusted IPs. This triggered the enforcement of the Conditional Access Policy.
Continuous Access Evaluation (CAE) is designed for Critical event evaluations. Critical events are classed as as the following:
User Account is deleted or disabled
Password for a user is changed or reset
Multifactor authentication is enabled for the user
Administrator explicitly revokes all refresh tokens for a user
High user risk detected by Microsoft Entra ID Protection
This means if one of the above isn’t met, Continuous Access Evaluation (CAE) will not take effect and you will be at the mercy of the token lifetime or until a critical even is generated.
If your workforce consists solely of office workers, you can implement a policy to block all external sign-ins except from trusted location IPs. This approach would also introduce a disruption in the authentication flow, as the initial login would originate from the Evilginx server, which is not a trusted IP.
Conditional Access Policy: Only allow Office locations
Users: ALL (Exclude ‘break-the-glass’ account)
Target Resources: All Cloud Apps:
Condition: Location: Any location and all trusted locations excluded
Grant: Require MFA / Block
The token cannot be captured because the MFA is not 'catchable'—Conditional Access blocks it before it can take effect.
Sign-In Risk Policy
Sign-In Risk Policy can be configured in two places currently:
Entra ID > Protection > Identity Protection > Sign-in risk policy
Entra ID > Protection > Conditional Access > Policies
The first method is slowly being phased out and sign-in risk will be moved to conditional access policies. Microsoft has began sending out notifications regarding migrating policies over.
Sign-in Risky & User Risk Policy are great for a quick, easy policy that can help prevent multiple different attacks. It’s not flawless but it’s definitley better than nothing especially for IT who are not 24/7. This can often give an edge in preventing / delaying an attack. The risk can vary greatly which is the one drawback. If an attacker is cautious, they could potentially generate less noise / perform less suspicious actions and prevent the policy from trigering - this is why a layered approach is very important. Relying on anyone conditional will open up the attack surface.
Both of these policies should be trialed within an organisation until an acceptable tolerance is found. False positives can happen so if you force a password reset on each occasion it generates a medium confidence risk, you will run into issues. From personal experience, I have found High Risk to be very accurate. It’s rare for this alert to be a false positives and in those rare occasions, I’d rather it block access rather than potentially giving an attacker free reign.
I would recommend biting the bullet and setting up the policies in Conditional Access Policies rather than using the traditional Sign-in risk policy as it gives you greater control over the policies, actions and the targted resources.
My recommendation would be:
Conditional Access Policy: Sign-In Risk
Users: ALL (Exclude ‘break-the-glass’ account)
Target Resources: All Cloud Apps:
Condition: High Risk (Change to medium risk once false positives are analsyed)
Grant: Require Multi-Factor Authentication or Block Access or compliant device / Entra joined
This would impact the authentication flow.
3rd Party Applications:
3rd party applications (Enterprise Applications) are often used by malicious actor(s). Typically they either use the compromsied credentials to consent to an overly permissive application or they trick the user into consenting to the application. By doing this, they maintain access to the account through password resets & changes to Multi-Factor Authentication. It's worth noting that many IT professionals and users might assume that resetting the user's password secures the account. However, this belief is far from the truth, and a thorough investigation should be conducted.
When consenting to an application, the following screen will appear:
I cannot stress how frequently I have observed 3rd party applications being used in Business Email Compromises (BEC).
To prevent the consent of 3rd party applications by end-users, I recommend the following settings:
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/ConsentPoliciesMenuBlade/~/UserSettings?Microsoft_AAD_IAM_legacyAADRedirect=true
Note that an administrator can still consent to any REQUIRED applications, so this should have minimal impact. Any previously consented apps will remain. I recommend reviewing these applications and checking their permissions to ensure they are not overly permissive
Alerts
Alerts are key to any organisation however, it’s important to tune the noise (false positives) out. There is a delicate balance here. You will likely need to tweak alerts as the organisation changes and as more features / signals become avaliable.
Licensing can play a massive part and there are many useful features behind a paywall! If you have a Security Information and Event Management (SIEM) system, you can likely leverage the capabilities and identify these style of attacks easier as they often follow similar patterns. A SIEM is not neccessary.
Microsoft Entra ID Protection is great for extra insight - this is included in P2 so if you have Conditional Access, there’s a good chance you may have this!
Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) is really the main defense against account breaches however, some methods are far, far, far………. better than others!
Any method which isn’t phishing-resistant is kinda where we need to draw the line. Text codes, app approvals etc are all products of their time - preventative at the time… even now mostly but they do not hold up against modern phishing attacks. They’re still better than nothing - and they’re arguably more covenient than phishing-resistant MFA methods which usually results in carrying around a USB hardware token.
How are FIDO2 keys phishing resistant?
There are multiple reasons why FIDO2 are phishing resistant.
Public Key Cryptography: FIDO2 relies on public key cryptography, specifically Elliptic Curve Cryptography (ECC). During registration, the device (security key) generates a pair of public and private keys. The private key is stored securely on the device and never leaves it. The public key is shared with the relying party (e.g., a website like microsoft.com).
Phishing-resistant User Verification: FIDO2 keys use user verification methods such as biometrics (like fingerprints or facial recognition) or a secure PIN. This ensures that even if an attacker gains access to the physical key, they would still need additional authentication factors
Device-based Authentication: FIDO2 keys are physical devices (e.g., USB security keys or devices with Bluetooth or NFC capabilities). The authentication process involves communication between the device and the relying party, and the private key never leaves the device. This makes it difficult for attackers to clone or replicate the key.
Credential Phishing Protection: FIDO2 keys are resistant to traditional credential phishing attacks where attackers trick users into entering their credentials on a fake website. Since FIDO2 keys use public key cryptography and rely on device-based authentication, phishing attacks that aim to steal username and password combinations are less effective.
Token Binding: FIDO2 supports token binding, which helps prevent token theft and replay attacks. Token binding ensures that the authentication token is bound to the specific TLS connection, making it difficult for attackers to reuse captured tokens in a different context.
User Presence and Consent: FIDO2 requires user interaction during the authentication process. The user must physically connect or interact with the FIDO2 key, confirming their presence and consent. This adds an additional layer of security against automated attacks
A very simplified flow:
Key generation:
1. Key pair (public / private) is generated during the registration process.
2. The public key is associated to the user’s account on the relaying party’s server
3. Private key is stored on the FIDO2 token
Authentication
4. User attempts to login, relying party sends challenge to FIDO2 key
5. FIDO2 key responds signing the challenege with it’s private key (private key never leaves the FIDO key, only the signature)
6. Relying party verifies signature using the stored public key associated with the account
User verification:
7. FIDO2 typically requires user input, this is often done via fingerprint, facial recognition or a secure pin.
Remember, if a user browses to a phishing site and enters a username & password, the next step would be to complete a MFA prompt. MFA is not possible as the domain is different which means the relying party is different. Due to this, the public key associated with the FIDO2 token on the phishing site would not exist! The FIDO2 would also not recognise the phishing site - I made a meme from the FIDO2 point of view… enjoy.
There are multiple ways to enforce Multi-Factor Authentication, the easiest is via Conditional Acess Policy.
Conditional Access Policy: Sign-In Risk
Users: ALL (Exclude ‘break-the-glass’ account)
Target Resources: All Cloud Apps:
Condition: None (Can exclude location if applicable but nerver recommended)
Grant: Require authentication strength: Phishing Resistant MFA
Note “For security info registration, the authentication strength evaluation is treated differently – authentication strengths that target the user action of Registering security info are preferred over other authentication strength policies that target All cloud apps. All other grant controls (such as Require device to be marked as compliant) from other Conditional Access policies in scope for the sign-in will apply as usual.”
It’s worth checking to see if the authentication methods are turned on. To do this, go to Azure AD > Security > Policies. You will be able to see the scope and if the method is enabled.
You can also configure what keys are allowed, enforce key restrictions, allow self-service setup etc if neccessary.
Because security key registration is based on self-service, the user would need to either have an MFA method already setup or have a Temporary Access Pass. This can be seen in the picture above - Note, Temporary Access Pass is not phishing resistant. Once enabed and scoped, you can browse to the user in Entra ID > Authentication methods > Add Authentication Method > Temporary Access Pass. I am not recommending this but can be useful in certain situations! It’s also better than having no MFA on a newly created account and relying on an end user to add a hardware token.
Once logged in, go to My Account > Security > Security Info > Add sign-in method > Security key.
From here the one screen instructions will guide the user/you when to plug in the hardware token, when to press it and creating a pin.
Conclusion:
Phishing attacks have been a massive issue for a long time and they’re only ever increasing in complexity and volume. Standard Multi-Factor Authenticaiton (MFA) methods like App Approvals, Text codes / OTP have prevented many attacks and are still doing a great job but modern phishing attacks have become more common and can bypass weak MFA methods with a low amount of effort.
It’s important not to skip preventative measures like training, protection for web and mail as these can negate many attacks at the first oppotunity. Conditional Access is a massive contender to prevent modern attacks - there are a decent amount of variety of policies and rules that can be tweaked to best suit your organisation. If you’re an organisation with predominantly Intune or Entra joined devices, preventing modern attacks should be realitively low effort. Microsoft are doing a good job with the in-preview features such as Continous Access Evaluation (CAE) & In-Token Protection - these are great and hopefully will only get better!
3rd party applications are an issue for most organisations and will continue to be abused so blocking user consent is the only logical option here really.
Phish-resistant MFA is the real MVP but I think considering how long it has taken to get organisations to use standard MFA, hardware tokens will be a slow burn - hopefully Windows Hello can fill the gap!
References:
https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2022/cyber-security-breaches-survey-2022
https://www.verizon.com/business/resources/reports/dbir/
https://www.valimail.com/newsroom/valimail-report-reveals-3-billion-spoofed-emails-are-sent-every-day/
https://twitter.com/meril
https://breakdev.org/
https://webauthn.wtf/how-it-works/authenticators