Microsoft Entra CBA enhancements
Over the last year, we’ve seen many federal and regulated industry customers migrate from Active Directory Federation Services (AD FS) to Microsoft Entra ID seamlessly providing end users a familiar sign-in experience with Microsoft Entra certificate-based authentication (CBA). In fact, in the last 12 months, we’ve seen an over 1500% increase in phishing-resistant authentication for United States government customers. As we continue our investments in the Microsoft Entra CBA, today I am excited to share the public preview of our latest enhancements: Certificate Revocation List (CRL) validation fail safe: Admins can strengthen the security by failing CBA authentication if the issuing certificate authority (CA) has no Certificate Revocation List (CRL). Enhanced PKI based certificate authority (CA) store: This enhancement removes any current size limitation and supports issuer hints at each CA level. Let’s dig deeper! Certificate Revocation List (CRL) validation fail safe Certificate Revocation List (CRL) validation feature allows enterprises to fail CBA authentication when the issuing CA does not have a CRL configured. This helps a tenant admin to strengthen security and avoid misconfigurations by requiring CBA authentication to fail if no CRL is configured for a CA that issues an end user certificate. A CA can be uploaded to the Microsoft Entra CA store without a CRL endpoint, and by default, Entra ID treats a CA without a CRL Distribution Point (CDP) as an administrator intentionally disabling CRL checking for that CA. The CRL validation feature allows a tenant admin to toggle the default behavior to fail CBA authentication if a CA is configured without CDP. To enable CRL validation, click Require CRL validation (recommended) and any CBA authentication will fail if the end user certificate was issued by a CA with no CRL configured. Administrators can also exempt specific CAs that do not need CRL validation. The CAs in the exempted list are not required to have CRL configured and the end-user certificates that they issue do not fail authentication. More info on CRL validation. Enhanced PKI-based certificate authority (CA) store Microsoft Entra has a new Public Key Infrastructure (PKI)-based CA store with higher limits for the number of CAs and the size of each CA file. The PKI-based CA store allows CAs within each different PKI to be in its own container object so admins can move away from one flat list of CAs to PKI-container-based CAs. PKI-based CA store supports up to 250CAs, 8KB size for each CA and supports issuers hints at CA level. An admin can also upload the entire PKI and all the CAs using the upload PKI feature or create a PKI container and upload CAs individually. The tenant admin can also enable issuer hints for specific CAs by enabling the Issuer Hint attribute isIssuerHintEnabled flag. Microsoft Entra CBA will support both the old and new store for authentication, but it is recommended to configure PKI-based CA store for Entra CBA. You can learn more about Microsoft Entra CBA here and Microsoft’s commitment to Executive Order 14028. We’re eager to hear your feedback as we work towards the general availability of these new enhancements. What’s next Keep your feedback coming at Microsoft Entra Community! We’re working diligently to bring more enhancements like the removal of limits on CRL, CBA support on the resource tenant for B2B external guest users, and iOS UX enhancements, to name some. Thank you, Nitika Gupta Read more on this topic Check out CBA documentation Learn more about Microsoft Entra Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds. Microsoft Entra News and Insights | Microsoft Security Blog Microsoft Entra blog | Tech Community Microsoft Entra documentation | Microsoft Learn Microsoft Entra discussions | Microsoft Community
Defeating Adversary-in-the-Middle phishing attacks
Welcome to the second in our series of articles on dealing with advanced identity-related attacks. As we’ve crossed the threshold of more than 40% of users employing multifactor authentication (MFA), we see two trends emerging. The first is that adversaries are successfully compromising a higher percentage of accounts not protected by MFA. With more lions pursuing fewer available gazelles, the gazelles face a lot more risk. In the past year, we blocked 7,000 password attacks per second, an increase of 75% YoY. The second trend is that more widespread use of MFA is forcing adversaries to find other ways to compromise MFA-protected accounts. Thus, advanced attacks like token theft (the subject of our previous blog) and Adversary-in-the-Middle (AiTM) phishing attacks (the subject of this blog) are on the rise—and are the focus of this blog series. Most attacks still involve passwords, so before you do anything else, turn on MFA, which can stop more than 99% of password-related attacks. Good MFA strategy and execution are the most important parts of any identity security plan. In the first blog, How to break the token theft cyber-attack chain, we gave you eight practical countermeasures against attacks involving token theft. Unlike token theft, an AiTM phishing attack does not steal a token already issued to a valid user. Instead, it involves tricking a user into going to a legitimate-looking copy of a website, entering their credentials, and performing MFA to authenticate on behalf of the adversary, who’s using the victim’s information to sign into the real website—resulting in a token issued directly to the adversary’s device. In this blog, we’ll explain how AiTM phishing attacks work and what you can do to protect your users against them. How classic phishing attacks work: The animated GIF above, reproduced from the first blog in this series, illustrates the normal flow of a token among the user agent (which may be a device or application), the identity provider (IdP), and the relying party. When the user agent requests access, the IdP responds by requesting proof of identity. Once the user agent provides their credentials, the IdP returns a token that the user agent presents to the relying party to gain access. The user agent is like a fairgoer purchasing a ticket to go on a ride at a county fair, the IdP is like a ticket office selling tickets to the fair rides, and the relying party is like the ride operator who examines and accepts the ticket from the fairgoer so they can go on the ride. Before MFA, phishing attacks were simple to execute, as the image below illustrates. An adversary (depicted on the right) would send a compelling, deceptive email or instant message containing a malicious link to a victim (depicted on the left). For example, the message may tell the victim they need to do account maintenance or take urgent action to prevent losing access. Selecting the link would lead to a fake site that asked the victim to enter their username and password. Once the victim complied, the fake site would scrape their credentials and then display an error message or a malicious page. Note that during the phishing attack, the adversary never needed to interact with the legitimate site or its IdP. After stealing the password, however, the adversary could go to the legitimate site and use the captured password to sign in whenever they wanted. Then along came MFA. Phishing after MFA A traditional MFA challenge requires the user to enter, within a few minutes, a validation code that the IdP sends—via a text, call, or push notification to an authentication app—directly to the user’s device or application. In other words, the MFA challenge bypasses the attacker trying to steal a user’s credentials via a phishing site. Even if the MFA challenge doesn’t require sign-in screen interaction, the victim could be out golfing when they receive a text or call they never requested. This defeats any adversary trying the usual tactic of signing in with a stolen password “whenever they want.” Without the user’s response, the attack fails. To get around MFA, the adversary has to change their attack flow. They must keep their victims engaged all the way through a potential MFA challenge. To do so, they must insert themselves into the authentication circuit between the victim and the IdP, interacting directly with the victim on one side of the circuit and with the IdP on the other, until they can manipulate the victim into providing their username, password, and validation code. Then they can complete the authentication circuit and gain access to the victim’s account. During this two-sided interaction, the adversary must impersonate the sign-in UX to the victim and impersonate the victim to the IdP. They scrape and replay the legitimate IdP’s UI to the victim, and they capture and replay the victim’s responses to the IdP. Lured by a phishing link, the victim interacts with the fake sign-in UX. The adversary captures the interaction and passes it on to the legitimate IdP. When the legitimate IdP issues an MFA challenge to the victim, the victim responds by interacting with the fake challenge UX displayed on the fake site. The adversary captures the victim’s response and echoes it back to the legitimate IdP, thus completing the authentication circuit. The IdP responds by issuing a valid token to the attacker, who has now successfully breached the victim’s account. In the last blog, we compared token theft to getting pickpocketed after purchasing your ticket from a county fair’s ticket office. AiTM phishing is like getting tricked into going to the wrong ticket office. Attracted by a flyer that offers 10% off admission, you (the user agent) approach a legitimate-looking ticket booth and ask to buy a season pass (the token). The fake attendant (the adversary) asks for your ID and credit card. When you hand them over, the attendant slips your items to an accomplice, who runs to the legitimate ticket office (the IdP) and attempts to purchase a pass using your items. Before approving the transaction, your bank asks the legitimate ticket office for a PIN code that they’ve texted to you. When the ticket office asks for the code, the accomplice runs back to the fake ticket booth to get the PIN code from you, then runs back to the legitimate office, completes the purchase, and pockets the season pass. While all this running around may make you feel winded, remember that in a digital interaction, everything is effortless, instant, and undetectable to the legitimate user. When the accomplice returns with your ID and credit card, the fake attendant hands them back to you and says they were unable to process your transaction. You’re out of luck, while someone else presents the pass you paid for to the ride operator (the relying party) and has fun on the ride. Although enforcing MFA with the right policies makes it nearly impossible for an attacker to complete authentication with stolen credentials over and over whenever they want, they can use this AiTM phishing technique to get a token and do harm until that token expires. To learn more about attacks that bypass MFA, see the blog post All your creds are belong to us! Now let’s explore how Microsoft can help you defeat these attacks. We’ll start with the most foolproof measure, passkeys, and then talk about other defense-in-depth options. Passkeys are the best solution to AiTM phishing attacks Just as token protection provides a definitive way to block token theft attacks, a new class of credentials makes it next to impossible to fall prey to an AiTM phishing attack. Phishing-resistant credentials are more secure because they use cryptographic methods that don’t expose sensitive information, making it impossible for attackers to intercept or replicate the authentication process. Among the authentication methods that Microsoft Entra supports, passkeys, certificate-based authentication (CBA), and Windows Hello for Business are phishing-resistant. By offering the strongest protection, they meet requirements for regulations such as the U.S. Executive Order on Improving the Nation’s Cybersecurity. Passkeys, which represent the newest industry standard, are already gaining broad adoption. To provide high security assurance, passkeys apply public-private key cryptography and require direct interaction with the user. Three critical characteristics make them almost impossible to phish: URL-specific. When the user agent creates a passkey, the provisioning process records the relying party’s URL, so the passkey will only work for the site with that same URL. It won’t work on a fake copycat site. Device-specific. Unless the passkey is synched, stored, or connected to the device from which the user is requesting access, the relying party won’t grant access. User-specific. To complete authentication, the user must prove they are physically present, usually by performing a gesture on their device, usually with their face, fingerprint, or device-specific PIN. A passkey is like a special ID card written in invisible ink that can only be revealed at the location it was intended for, and when presented in person. In this case, the special ID card will only work at the legitimate ticket office at the county fair and when unlocked with your biometric or PIN. To learn more about phishing-resistant authentication methods in Microsoft Entra ID, check out our video series. Defense-in-depth measures against Adversary-in-the-Middle attacks AiTM attacks simply don’t work against users who sign in with phishing-resistant credentials, but rolling out phishing-resistant credentials to all your users can take time. Even if you’re still using MFA with OAuth tokens or simple approvals, you can set up guardrails that make AiTM attacks much harder for adversaries to execute. Go passwordless Use the Microsoft Authenticator app for MFA and passwordless authentication. The Authenticator App gives users additional context to help them determine whether an MFA challenge is legitimate or a potential security threat. Application name: Displaying the name of the application requesting authentication helps users recognize whether the MFA challenge comes from the resource they’re trying to access. Geographic location: Displaying the location of the sign-in attempt, based on its IP address, helps users identify any sign-in attempts coming from unexpected or suspicious locations. Number Matching: Presenting a number on the sign-in screen that users must enter into the Authenticator app ensures that they’re physically present and aware of the sign-in attempt. The user selecting the “No, it’s not me” option feeds into Entra ID Protection as a risk signal and will trigger an immediate prompt to the user. As an added bonus, if our identity security algorithms detect an anomalous sign-in attempt, for example, from an unusual IP address or a known bad one, we suppress the MFA notification altogether. Find step-by-step instructions for setting up passwordless authentication using Microsoft Authenticator in our documentation. Set access policies that restrict threat actor activity. Given that AiTM attacks depend on tricking the user into going to a bad website, you want to set up as many roadblocks as possible. For example, policy restrictions can force attackers to operate within your environment, which massively restricts their ability to maneuver and makes it easier for you to identify and block their activity. Require managed and compliant devices. If your policy says that Entra ID will only issue tokens to users requesting them from managed and compliant devices, then the only way the attacker can request a token on the user’s behalf is to set up a phishing site on a compliant device that you manage, keep the device turned on all the time, evade endpoint protection, use the issued token within refresh windows dictated by policy, and not trigger risk thresholds that would result in automatic revocation of the token. These are pretty significant hurdles. To help prevent accidental infection with malware that actors can use to launch AiTM phishing attacks, configure your policy to require that all devices are compliant and running up to date endpoint protection, and that all Windows users run as standard users rather than with device admin rights. Find step-by-step instructions for configuring policies to require managed devices in our documentation. Restrict sessions for use within network boundaries. You can use Conditional Access to define a network compliance boundary using IP address ranges. Establishing network boundaries forces attackers to operate within those boundaries, because it prevents the issuing or re-issuing of tokens to devices outside the network boundaries. So, not only would they need to execute their mirrored commands on a managed and compliant device, but that device would also have to be operating within your network boundary. Entra Internet Access and Entra Private access install agents on endpoints that enforce a real-time compliant network check that verifies whether a user requesting access is coming from a trusted network. If they aren’t, Conditional Access denies their request immediately. Find step-by-step instructions for defining a network compliance boundary with Conditional Access in our documentation. Find step-by-step instructions for enabling compliant network check with Conditional Access in our documentation. Restrict which URLs your users can visit. If a user clicks on a phishing link, Microsoft Defender SmartScreen, a security feature integrated into Windows and Microsoft Edge, checks the URL against a dynamic list of user- and industry-reported phishing and malware sites. If it finds a match, it warns the user that the site has been reported as unsafe, and they must take an extra step to continue to the site. SmartScreen also scans downloaded files and applications, blocking those known to be malicious or potentially unwanted. Network protection in Microsoft Defender for Endpoint expands the scope of SmartScreen to block—at the operating system level—all outbound HTTP(S) traffic that attempts to connect to low-reputation sources. You can use Intune, PowerShell, Group Policy, or Microsoft Configuration Manager to enable network protection. You can also configure the Tenant Allow/Block List in the Microsoft Defender for Office 365 portal to restrict which sites users can visit. Find step-by-step instructions on how to block URLS using Microsoft Defender in our documentation. Find step-by-step instructions on how to turn on Microsoft Defender for Endpoint network protection in our documentation. Be prepared to detect and respond to anomalies that may indicate a phishing attack In the unlikely event that all the above measures fail, anomaly detection can help you block and remediate attacks. Use Entra ID Protection and Microsoft Defender to monitor for anomalous sessions. When a user initiates a session or attempts to access an application, Entra ID Protection will examine user and session risk factors for any anomalies. Here are some examples of anomalies that elevate risk levels: A request for a token from an unusual website. A threat actor signing in with a token obtained via phishing, thus triggering detections such as: Anomalous token Anomalous user activity Attacker in the Middle Unfamiliar sign-in properties A user reporting suspicious activity, such as an MFA request they didn’t initiate. You can configure Conditional Access policies to be risk-based, meaning you can define remediation steps that happen automatically when user or session risk levels rise. Learn more about risk detections in our documentation. Create a risk-based Conditional Access policy. You can configure a Conditional Access policy that, for example, requires reauthentication with MFA in response to elevated risk. This thwarts an AiTM phishing attack because the legitimate user likely isn’t present to interact with the adversary to “help” them reauthenticate. Conditional Access usually checks risk level during token refresh, so if an adversary manages to get a hold of a legitimate token, your exposure is limited to the lifetime of that token. Continuous Access Evaluation (CAE)—supported natively in applications and services such as Teams, Exchange Online, and SharePoint Online—can trigger policies that invalidate access tokens for these apps in near real time, ending your exposure immediately when a change in conditions elevates the risk level for a user or service principal. This includes a change in the user’s network location. Find step-by-step instructions for creating risk-based Conditional Access policies in our documentation. Find step-by-step instructions for enforcing strict location policies using CAE in our documentation. Use Microsoft Defender XDR to investigate and mitigate AiTM phishing attacks. If adversaries do successfully intercept credentials and session cookies, they can use them to initiate other attacks such as Business Email Compromise (BEC) and credential harvesting. Based on multiple, correlated Microsoft 365 Defender signals that indicate an AiTM phishing attack, Defender XDR automatically disables compromised user accounts in Entra and in on-premises Active Directory, and revokes session cookies. It also monitors session traffic and enforces policies that prevent adversaries from exporting sensitive data outside your network. Find step-by-step instructions for using Defender XDR to disrupt AiTM phishing attacks in the blog post, Automatically disrupt adversary-in-the-middle attacks with XDR. Investigate potential AiTM phishing attacks via a Security Information and Event Management (SIEM) tool, such as Microsoft Sentinel. If you receive an alert for an event that may indicate an AiTM phishing attack, you can investigate it in the Microsoft Sentinel portal or in another SIEM. Microsoft Sentinel gives you important details about a specific incident, such as its severity, when it occurred, how many entities were involved and which events triggered it. You can then view the investigation map to understand the scope and root cause of the potential security threat. Find step-by-step instructions for detecting and investigating incidents using Sentinel in our documentation. Go passwordless, ideally using passkeys Set access policies that restrict threat actor activity Be prepared to detect and respond to anomalies that may indicate a phishing attack Use the Microsoft Authenticator app for MFA and passwordless authentication. Require managed and compliant devices. Use Entra ID Protection and Microsoft Defender to monitor for anomalous sessions. Restrict sessions for use within network boundaries. Create a risk-based Conditional Access policy. Restrict which URLs your users can visit. Use Microsoft Defender XDR to investigate and mitigate AiTM attacks. Investigate potential AiTM phishing attacks via a SIEM such as Microsoft Sentinel. According to our detection data, AiTM phishing attacks have grown 146% over the past year. Passkeys provide the most effective solution available against these attacks, so we strongly recommend that you start planning and executing your passkey rollouts now. In the meantime, you can also employ the other defense-in-depth recommendations we make in this blog to keep your users as safe as possible. Stay safe out there, Alex Weinert Learn more about Microsoft Entra Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds. Microsoft Entra News and Insights | Microsoft Security Blog Microsoft Entra blog | Tech Community Microsoft Entra documentation | Microsoft Learn Microsoft Entra discussions | Microsoft Community
