Token Protection by using Microsoft Entra ID.
As organizations move to the cloud and adopt SaaS applications, identities are becoming increasingly crucial for accessing resources. Cybercriminals exploit legitimate and authorized identities to steal data and access credentials through methods like phishing, malware, data breaches, brute-force/password spray attacks, and prior compromises. As in past years, password-based attacks on users constitute most identity-related attacks. As MFA blocks most password-based attacks, threat actors are shifting their focus, moving up the cyberattack chain in three ways: 1) attacking infrastructure, 2) bypassing authentication, and 3) exploiting applications. They are leaning more heavily into adversary-in-the-middle (AiTM) phishing attacks and token theft. Over the last year, as Microsoft Digital Defense Report (MDDR 2024) a 146% rise in AiTM phishing attacks. In AiTM attack , the attackers steal tokens instead of passwords. The Frameworks used by attackers go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token. By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. Now it is imperative that tokens must be protected from token theft. Let us understand more on tokens. An Entra identity token is a security token issued by Microsoft Entra ID for authentication and authorization. There are several types: Access Tokens: Grant access to resources on behalf of an authenticated user, containing user and resource information. ID Tokens: Authenticate users, issued in the OpenID Connect flow, containing user identity and authentication details. Refresh Tokens: Obtain new access tokens without re-authentication, usually issued with access tokens and have a longer lifespan. Ensuring Token Security By following best practices, you can significantly enhance the security of your tokens and protect your applications from unauthorized access. Use Secure Transmission: Always transmit tokens over secure channels such as HTTPS to prevent interception by unauthorized parties. Token Binding: Implement Token Protection (formerly known as token binding) to cryptographically tie tokens to client secrets. This prevents token replay attacks from different devices. Conditional Access Policies: Use Conditional Access policies to enforce compliant network checks. This ensures that tokens are only used from trusted networks and devices. Continuous Access Evaluation (CAE): Implement CAE to continuously evaluate the security state of the session. This helps in detecting and revoking tokens if there are changes in the user's security posture, such as network location changes. Short Token Lifetimes: Use short lifetimes for access tokens and refresh tokens to limit the window of opportunity for attackers. Secure Storage: Store tokens securely on the client side, using secure storage mechanisms provided by the operating system, such as Keychain on iOS or Keystore on Android. Regular Audits and Monitoring: Regularly audit token usage and monitor for any unusual activity. This helps in early detection of potential security breaches. Now we will discuss Entra ID new features for Token Protection. Token protection using conditional access : This feature will provide refresh token protection. Compliant network check with Conditional Access: This feature will provide both refresh token and Access token protection. Token protection using conditional access: 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. When an attacker is able to steal a token, by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is thought to be a relatively rare event, but the damage from it can be significant. Token protection creates a cryptographically secure tie between the token and the device (client secret) it's issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device. What this means: A policy can ensure that only bound sign-in session (or refresh) tokens, otherwise known as Primary Refresh Tokens (PRTs) are used by applications when requesting access to a resource. Token protection is currently in public preview Create a Conditional Access policy Users who perform specialized roles like those described in Privileged access security levels are possible targets for this functionality. We recommend piloting with a small subset to begin. The steps that follow help create a Conditional Access policy to require token protection for Exchange Online and SharePoint Online on Windows devices. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Protection > Conditional Access > Policies. Select New policy. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies. Under Assignments, select Users or workload identities. Under Include, select the users or groups who are testing this policy. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts. 6.Under Target resources > Resources (formerly cloud apps) > Include > Select resources Under Select, select the following applications supported by the preview: Office 365 Exchange Online Office 365 SharePoint Online Choose Select. 7. Under Conditions: Under Device platforms: Set Configure to Yes. Include > Select device platforms > Windows. Select Done. Under Client apps: Set Configure to Yes Under Modern authentication clients, only select Mobile apps and desktop clients. Leave other items unchecked. Select Done. 8. Under Access controls > Session, select Require token protection for sign-in sessions and select Select. 9. Confirm your settings and set Enable policy to Report-only. 10.Select Create to create to enable your policy. After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On. Capture logs and analyze Monitoring Conditional Access enforcement of token protection before and after enforcement. Sign-in logs Use Microsoft Entra sign-in log to verify the outcome of a token protection enforcement policy in report only mode or in enabled mode. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Identity > Monitoring & health > Sign-in logs. Select a specific request to determine if the policy is applied or not. Go to the Conditional Access or Report-Only pane depending on its state and select the name of your policy requiring token protection. Under Session Controls check to see if the policy requirements were satisfied or not. You can refer below link to know more about license requirements, prerequisites & limitations. Token protection in Microsoft Entra Conditional Access - Microsoft Entra ID | Microsoft Learn Enable compliant network check with Conditional Access Organizations who use Conditional Access along with the Global Secure Access, can prevent malicious access to Microsoft apps, third-party SaaS apps, and private line-of-business (LoB) apps using multiple conditions to provide defense-in-depth. These conditions might include device compliance, location, and more to provide protection against user identity or token theft. Global Secure Access introduces the concept of a compliant network within Microsoft Entra ID Conditional Access. This compliant network check ensures users connect from a verified network connectivity model for their specific tenant and are compliant with security policies enforced by administrators. The Global Secure Access Client installed on devices or users behind configured remote networks allows administrators to secure resources behind a compliant network with advanced Conditional Access controls. This compliant network feature makes it easier for administrators to manage access policies, without having to maintain a list of egress IP addresses. This removes the requirement to hairpin traffic through organization's VPN. Compliant network check enforcement Compliant network enforcement reduces the risk of token theft/replay attacks. Compliant network enforcement happens at the authentication plane (generally available) and at the data plane (preview). Authentication plane enforcement is performed by Microsoft Entra ID at the time of user authentication. If an adversary has stolen a session token and attempts to replay it from a device that is not connected to your organization’s compliant network (for example, requesting an access token with a stolen refresh token), Entra ID will immediately deny the request and further access will be blocked. Data plane enforcement works with services that support Continuous Access Evaluation (CAE) - currently, only SharePoint & Exchange Online. With apps that support CAE, stolen access tokens that are replayed outside your tenant’s compliant network will be rejected by the application in near-real time. Without CAE, a stolen access token will last up to its full lifetime (default 60-90 minutes). This compliant network check is specific to each tenant. Using this check, you can ensure that other organizations using Microsoft's Global Secure Access services can't access your resources. For example: Contoso can protect their services like Exchange Online and SharePoint Online behind their compliant network check to ensure only Contoso users can access these resources. If another organization like Fabrikam was using a compliant network check, they wouldn't pass Contoso's compliant network check. The compliant network is different than IPv4, IPv6, or geographic locations you might configure in Microsoft Entra. Administrators are not required to review and maintain compliant network IP addresses/ranges, strengthening the security posture and minimizing the ongoing administrative overhead. Enable Global Secure Access signaling for Conditional Access To enable the required setting to allow the compliant network check, an administrator must take the following steps. Sign in to the Microsoft Entra admin center as a Global Secure Access Administrator. Browse to Global Secure Access > Settings > Session management > Adaptive access. Select the toggle to Enable CA Signaling for Entra ID (covering all cloud apps). This will automatically enable CAE signaling for Office 365 (preview). Browse to Protection > Conditional Access > Named locations. a. Confirm you have a location called All Compliant Network locationswith location type Network Access. Organizations can optionally mark this location as trusted. You can refer below link to know more about license requirements, prerequisites & limitations Protect your resources behind the compliant network The compliant network Conditional Access policy can be used to protect your Microsoft and third-party applications. A typical policy will have a 'Block' grant for all network locations except Compliant Network. The following example demonstrates the steps to configure this type of policy: Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Protection > Conditional Access. Select Create new policy. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies. Under Assignments, select Users or workload identities. Under Include, select All users. Under Exclude, select Users and groupsand choose your organization's emergency access or break-glass accounts. 6. Under Target resources > Include and select All resources (formerly 'All cloud apps'). If your organization is enrolling devices into Microsoft Intune, it is recommended to exclude the applications Microsoft Intune Enrollmentand Microsoft Intune from your Conditional Access policy to avoid a circular dependency. 7. Under Network. Set Configureto Yes. Under Include, select Any location. Under Exclude, select the All Compliant Network locationslocation. 8. Under Access controls: Grant, select Block Access, and select Select. 9. Confirm your settings and set Enable policy to On. 10. Select the Create button to create to enable your policy. User exclusions Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies: Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and take steps to recover access. More information can be found in the article, Manage emergency access accounts in Microsoft Entra ID. Service accounts and Service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications but are also used to sign in to systems for administrative purposes. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals. If your organization has these accounts in use in scripts or code, consider replacing them with managed identities. Try your compliant network policy On an end-user device with the Global Secure Access client installed and running, browse to https://outlook.office.com/mail/ or https://yourcompanyname.sharepoint.com/, you have access to resources. Pause the Global Secure Access client by right-clicking the application in the Windows tray and selecting Pause. Browse to https://outlook.office.com/mail/ or https://yourcompanyname.sharepoint.com/, you're blocked from accessing resources with an error message that says You cannot access this right now. You can refer below link to know more about license requirements, prerequisites & limitations Enable compliant network check with Conditional Access - Global Secure Access | Microsoft Learn
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
