[Updated 7/11/2019 – Azure AD now supports FIDO2 tokens for MFA, which also protect against EvilGinx2]

This is my second blog post in this series. In the first blog post (here) Aidan Holland (@thehappydinoa) demonstrated how EvilGinx2 can bypass Microsoft’s 2FA that is built into Office 365 (SMS Text or Mobile Authenticator), sometimes called “Always-On MFA.”

Kuba Gretzky (@mrgretzky) stated that it can defeat any form of 2FA!

“Be aware that: Every sign-in page, requiring the user to provide their password, with any form of 2FA implemented, can be phished using this technique!” https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens

That’s a bold claim! Matt Soseman from Microsoft says, “always combine MFA with Conditional Access.” Matt is one of Microsoft’s top Cybersecurity experts, as he spoke on behalf of Microsoft at the RSA Security Conference in March 2019 (PDF HERE).

In this blog post, we are going to put both claims to the test. How does Microsoft’s Conditional Access compare against Evilginx2? We tested 13 of Microsoft’s defense capabilities and found 7 ways to defeat EvilGinx2. We also provide 4 recommendations for Microsoft to further improve security, and 5 recommendations for customers.

First, let’s define terms.

• 2FA, or ‘two-factor authentication’ is most commonly something you know like a password, and then some other factor like an SMS text code or a token-based Authenticator mobile app.
• MFA, or ‘multi-factor authentication’ can be multiple factors, not just two. For example, Microsoft’s conditional access allows you to go beyond user-authentication to perform machine authentication. You can check to see whether a computer is joined to the on-premises Active Directory domain, or whether it has a certificate issued from Active Directory Certificate Services (using Microsoft Cloud App Security Conditional Access App Control), or is originating from a range of IP addresses (aka IP-fencing). You can also check for the risk level of a user identity (using Azure Identity Protection) or the risk level of a machine (with Microsoft Defender ATP).

In our testing, we found that while EvilGinx2 is successful in bypassing the user-authentication forms of 2FA (yes, even the Microsoft Authenticator App!), and Azure Identity Protection.

EvilGinx2 was unsuccessful in bypassing the full MFA capabilities that Microsoft offers in Azure Conditional Access. This is available for customers who own the Azure AD Premium P1 license, which is also bundled in Enterprise Mobility Suite E3, and/or M365 E3.

Anyone who owns Azure AD Conditional Access can protect themselves from EvilGinx2 MFA bypass. Anyone who does not own Conditional Access can partially defend themselves against EvilGinx. The client access rule only protects Exchange Online, not SharePoint Online, OneDrive, Dynamics, or any of the other Office 365 or Azure services.

How does EvilGinx2 Work?

In order to understand how Azure Conditional Access can block EvilGinx2, its important to understand how EvilGinx2 works. First, the attacker must purchase a domain name, like “office-mfa.com” and convince an end-user to click on that link. The attacker’s machine passes all traffic on to the actual Microsoft Office 365 sign-on page. Since all traffic is passed directly through, the end-user sees the *actual* Office 365 sign-in page. This means the attacker does not have to waste valuable time trying to make the page look identical. The authentication token is captured after the user performs user-based authentication (SMS or Authenticator App). The attacker can then import the cookie into their own browser to access Office 365. In our testing, the link was not blocked by MSFT EOP, Office ATP, Microsoft Defender ATP, or Windows Defender SmartScreen. However, we did find at least three methods that blocked EvilGinx2.

Figure 1 image credit – breakdev.org

The attacker’s EvilGinx2 server terminates the SSL session and it then re-transmits a new SSL session against login.microsoftonline.com. This avoids all SSL errors in the browser, since there is a valid ssl handshake to the attacker’s machine. This is an advantage for the hacker, but it turns out to be the Achilles heel because Azure Conditional Access can perform additional checks that will all block EvilGinx such as: IP address, Domain Join Membership, Compliance (via Intune UEM), or Certificate (via CASB).

Here is a screen shot showing Azure Conditional Access blocking EvilGinx2 because the attacker’s IP address does not match the policy.

Here is a screen shot showing that Azure Conditional Access blocks EvilGinx2 because the attacker’s proxy machine is not a domain-joined device

Here is a screen shot showing that Azure Conditional Access blocks EvilGinx2 because the attacker’s proxy machine is not meeting Intune compliance policy.

Here is a screen shot showing Microsoft Cloud App Security Conditional Access App Control successfully blocked the attacker from getting into Exchange Online because the attacker could not present a valid certificate.

Here is a screen shot showing new-clientaccessrule blocking EvilGinx2 from accessing the mailbox in Office 365

Another method that blocks EvilGinx is U2F (Universal 2nd Factor Authentication). The author of EvilGinx2 states (here) that U2F “leaves no room for error and is totally unphishable using Evilginx method…” and that “make your life easier and get a U2F device! This will greatly improve your accounts’ security.” [Update: On July 10th, Microsoft formally announced that Azure AD now supports FIDO2 in public preview (read announcement here).]

So here is a summary of all known/possible defenses in Microsoft’s security arsenal and how they measure up against EvilGinx2.

Recommendations for Office 365 Customers

1. If you are an Office 365 E3 subscriber, upgrade to Enterprise Mobility Suite and configure Azure AD Conditional Access for either (machine-authentication (domain-join checking, certificate checking) or IP address fencing) or (compliant device checking with Intune for Mobile Devices or Intune UEM for Windows 10). If you need assistance, find a qualified Microsoft Partner (here) and scroll down to the bottom.
   
2. Consider implementing client access rules to protect Exchange Online. For an excellent overview of how client access rules work, watch this MSFT Ignite Video (here), fast-forward to 7:35 and watch until 15:55. Here is an example client access rule targeting a test account.
   new-ClientAccessRule -name “Allow InternalIP Only” -Action DenyAccess -ExceptAnyOfClientIPAddressesOrRanges [enter your public IP addresses here] -UsernameMatchesAnyOfPatterns *TestUserName
   
3. Plan a U2F deployment, for example with Yubico. [This is now supported with Azure AD as of 7/10/2019].

   “With the YubiKey, user login is bound to the origin, meaning that only the real site can authenticate with the key. The authentication will fail on the fake site even if the user was fooled into thinking it was real. This greatly mitigates against the increasing volume and sophistication of phishing attacks and stops account takeovers.” Reference https://www.yubico.com/solutions/fido-u2f/
   

4. Perform regular Security Awareness training to help users recognize suspicious URLs.
   Note: Microsoft’s Office 365 ATP has an exclusive feature called ‘Native Link Rendering’
   to show users the original hyperlink when they hover over it. No other advanced hyperlink scanning solution has this capability (I asked all the top vendors this question including ProofPoint, Mimecast, FireEye, Symantec and others). Native Link Rendering requires the Office 365 C2R (click-to-run) version, and not the volume-licensed MSI installer version of Office. Monthly Channel 1808 release (September 2018) or Semi-Annual Channel 1901 (which has not rolled out yet except to the Semi-Annual Targeted channel). See release notes (here).
5. Harden the Office 365 tenant. A good place to start is my blog post ’20 Things to do before and after a phishing event in Office 365′. And we also offer a monthly service to continuously audit and harden Office 365, for more on that service click here.
   If you are investigating an incident and you believe a user’s token has been captured, you can invalidate a token with this AAD PowerShell cmdlet
   $date =get-date; Set-Msoluser -UserPrincipalName (UPN) -StsRefreshTokensValidFrom $date
   

Feedback for Microsoft:

• Microsoft should consider improving Office ATP Safe Links and/or SmartScreen to take into consideration the age of a newly registered domain name. Some of Microsoft’s competitors can check the age of a domain name when determining hyperlink reputation.
• Microsoft should consider developing features similar to new-clientaccessrule for the other services in Office 365 like SharePoint Online, OneDrive for Business, Teams, Dynamics
• Azure Identity Protection could be improved to check every attempt, similar to new-clientaccesrule. We assume the fact that we had imported a captured token is why we did not get triggered by the User Risk policy or Sign-in risk policies (which were both set to ‘low and above’ with the block control).
• Don’t give away which factor of authentication was the reason why the attacker could not sign-in. For example, in our testing the attacker is able to learn whether it was a domain join check or a compliance check that they failed. This is precisely what the PCI DSS takes issue with in their MFA guidance (here)

  

  Therefore we recommend that Microsoft change from Multi-Step to true Multi-Factor authentication. Today, any world-wide user can attempt to guess a username and password, only to then be blocked by a subsequent policy. This arms the attacker with too much information on which challenge failed.

  

-Joe Stocker, CEO

Patriot Consulting Technology Group, LLC

Our Mission “to empower our clients to manage cyber security risk by securely deploying Microsoft Cloud technology”