impossible travel identity protection

Impossible Travel 101: What You Need to Know

"Impossible travel" is a threat detection technique or risk-predicting algorithm that calculates whether sequential login attempts from different locations are realistically too far apart to travel within the defined time period. It evaluates whether the travel time between the current attempt and a previous successful attempt is logically possible.

For example, if you have a detection solution that includes impossible travel and one of your employees signs in to their account from New York and then the same account is accessed from San Francisco 15 minutes later, the session is scored as high-risk and mitigation begins.

In this blog, we'll delve into the mechanics of impossible travel, also known as geo-velocity anomalies, and discuss how Ping's threat protection tools can help businesses keep their identities secure.

A note on false positives

Before we get into the nitty-gritty of impossible travel, it’s important to talk about a fundamental concept of risk scoring - false positives. By nature, no single risk detection technique is immune to false positives. That is to say, there is always a margin of error, and one risk predictor alone is not enough to score a session high-risk with absolute certainty. You need more evidence, data, and risk anomalies to detect threats accurately. 

Think about risk scoring like your senses: touch, smell, taste, sight, and sound. Through experiencing all those senses together, you know with great certainty where you are and what is happening around you. If you were only to rely on one sense, you could easily be misled. Risk scoring and the associated risk predictors are like each of your senses. Each one evaluates specific data sets – alone, they don’t give you much certainty, but when combined, they work together to tell the full story. Each predictor gathers evidence, and you need a lot of evidence to minimize doubt and false positives and to make the case strong enough to convict.

How does impossible travel detection work?

It is easy to explain the concept of impossible travel: you can’t be in two different places simultaneously. But, the work that risk algorithms do in the background to identify this anomaly is more complex. Impossible travel detection and protection is not merely about evaluating login activity. It also includes:

Data aggregation & calculation: Different risk signals, like IP, geolocation, session tokens, device IDs, and behavioral biometrics, are combined to establish baseline “normal” activity. Travel velocity inputs are also used to calculate realistic travel distances based on different timeframes.

Login history evaluation: Machine learning algorithms take real-time aggregated data the minute it’s received and compares recent activity against login timestamps and historical behavior to identify anomalies and impossibilities.

Scoring for mitigation: All risk signals, including the impossible travel predictor, are combined to output an aggregated risk score. That risk score is used to automate mitigation, including:

• Invoking multi-factor authentication or identity verification
• Flagging the login attempt and alerting the account owner
• Alerting the administration

The risks of ignoring threat detection

Not leveraging a threat detection solution with impossible travel is akin to not buying a smoke alarm: the consequences could be severe. Here's what could happen if your identity systems are compromised:

Personal data & identity theft

If an unauthorized party gains access to a user's account, they obtain all personal information stored there, including contact lists and messages. If the compromised account contains information that could be used for identity theft, the potential for harm is more severe. With enough data, cybercriminals can impersonate users to open new accounts, secure loans, or conduct illegal activities.

Financial loss

Unauthorized users can conduct transactions, make online purchases, and even steal credit card or banking information. Cybercriminals who go unnoticed can gain complete access to your company’s financial information by hacking into your accounting department’s data, for example.

Loss of business reputation & legal consequences

If a fraud incident is made public, you lose customer trust, harm your reputation, and face significant financial and legal repercussions. By taking real-time threat detection seriously and automating mitigation, you not only protect yourself but also contribute to broader cybersecurity efforts. In the digital world, your first line of defense is being proactive about threat detection.

Additional insight: quick Q&A on impossible travel

Sophisticated systems use machine learning to adapt to user behavior over time, reducing the rate of false positives. Remember, though, impossible travel anomalies are not reliable enough as a stand-alone evaluation technique. The best threat protection includes multiple risk predictors across a wide array of signals.

Any organization concerned about cybersecurity should consider implementing threat detection that includes impossible travel, especially organizations dealing with sensitive data, such as financial institutions, healthcare providers, and government agencies.

The setup complexity depends on the system you are integrating with. Tools like PingOne Protect are designed to integrate easily with most existing identity systems.

While highly effective, impossible travel detection is not foolproof. False positives can occur, especially if a user is employing VPN services or if there are inaccuracies in geolocation databases. This is why it's usually used as a part of a broader, layered threat detection solution with multiple risk predictors that work together to provide accurate risk scores.

Yes, many systems that use impossible travel detection can trigger immediate actions, such as multi-factor authentication, thereby preventing potential breaches in real-time.

Protect your business with PingOne Protect

It's imperative to arm yourself with advanced threat protection solutions that include impossible travel detection. PingOne Protect is like a vigilant, 24/7 security officer, continuously analyzing digital behavioral metrics, login origins, and other risk indicators. It flags any suspicious elements for immediate scrutiny, which is vital in the rapidly evolving cyber threat landscape. Being proactive rather than reactive is not optional – it's imperative for staying ahead of cybercriminals.

Don't let impossible travel compromise your security

Safeguard your digital assets with fraud detection and prevention solutions.

We’re here to help! Reach out to us today.

Start Today

Contact Sales

[email protected]

+1 877-898-2905

See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.

Request a FREE Demo

• Artificial Intelligence
• Generative AI
• Business Operations
• IT Leadership
• Application Security
• Business Continuity
• Cloud Security
• Critical Infrastructure
• Identity and Access Management
• Network Security
• Physical Security
• Risk Management
• Security Infrastructure
• Vulnerabilities
• Software Development
• Enterprise Buyer’s Guides
• United States
• United Kingdom
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Member Preferences
• About AdChoices
• E-commerce Links
• Your California Privacy Rights

Our Network

• Computerworld
• Network World

How to set up Microsoft Azure AD Identity Protection to spot risky users

Whichever license of azure active directory you own, you have options to set up alerts and automate actions to risky user behavior..

Do your users perform actions that put your organization at risk? If you have an Azure Active Directory (AD) Premium 2 (P2) license, you can set up risk alert rules that tell you when their actions are putting your firm at risk. You can also instruct it to take additional actions based on the activities seen by Azure AD Identity Protection at the sign-in process.  

If you have a Premium 1 (P1) license, you will receive a “Sign-in with additional risk detected” notice. The risk level and risk detail fields are hidden, but this might be enough to alert you to actions that put your firm at risk. There are different features included in Azure AD P1 versus Azure AD P2 , and how each reports on risky user activities is just one of them.

Azure monitors how a user logs in and takes action if it sees unusual activity based on policies you set up. This setting is similar to the Microsoft 365 user login monitoring but focuses on the user login for Azure AD. You can purchase a single P2 license to add this level of protection for your global administrator accounts and leave the rest of your users with a P1 license or even at the basic Azure AD level. You may find conflicting information on the web, but you can mix and match Azure licenses to put together the best protection for your accounts. This is just one of many best practices that you can do for Azure AD as noted on this best practices checklist .

The risk event types Azure AD detects include:

• Users with leaked credentials: This is done by comparing the credentials, monitoring public and dark web websites, and working with researchers, law enforcement, and security teams at Microsoft and other trusted sources.
• Sign-ins from anonymous IP addresses: The service checks sign-ins in real time from an anonymous IP address (for example, Tor browser , anonymizer VPNs). These IP addresses are typically used by attackers who want to hide their login telemetry (IP address, location, device, etc.) for potentially malicious intent.
• Impossible travel to atypical locations: This is done with a service that identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. The service actually calculates the time it takes to travel between the two locations and how it would be impossible to be in those two locations. The service ignores obvious “false positives” contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. It takes two weeks for the system to learn the user’s behavior.
• Sign-ins from unfamiliar locations and from IP addresses with suspicious activity: This is done in real time and is best when used with modern authentication and where basic authentication is disabled.
• Sign-ins from infected devices: These are monitored and blocked.

Setting up Azure AD Identity Protection

To get started with Azure AD Identity Protection, you’ll need to add Azure AD Identity Protection through the Azure Marketplace under Security + Identity.

Look in the Azure AD Identity marketplace

Then log into the dashboard and review if you have users already at risk. In my sample account, it’s already flagged my user account as not having multi-factor authentication (MFA).

Azure AD Identity Protection page

Go to the Azure AD Identity Protection page and set up the sign-in risk policy. To set up the policy, click on “Azure AD Identity Protection – Sign-in risk policy”. Set the policy to either all users or selected users. Choose sign-in risk as high and click “Done”. Now it’s time to assign a control. Choose “Select a control” such as blocking the user or demanding that the user change their password. Save the policy.

You might think that choosing low risk will give you the best experience when setting up a new policy. However, it’s exactly opposite. The “high” value refers to how likely the event indicates a compromised identity and not the high risk of activities. It’s about high confidence that a high severity risk event indicates that any user accounts impacted should be remediated immediately.

If you choose low risk, it means more chance of a false positive. That is a low confidence and low severity risk event. This event may not require an immediate action, but when combined with other risk events, might provide a strong indication that the identity is compromised.

Azure AD risk reporting levels vary

Depending on the license of Azure AD you have, you may have different reporting levels. For example, if you have the Azure AD Free and Basic editions, you get a list of users flagged for risk. If you have Azure AD P1 edition you can dig deeper into the underlying risk events that have been flagged in the risk report. Finally if you have the Azure AD P2 version, you get the most detailed level of information. You can even set up security policies that respond to the triggered risks events flagged. You can mix and match different licenses and assign a P2 license just for your more risky users such as global admins.

Microsoft is in the process of expanding the risky user report with a more expanded version at the updated risky user report . While you review the risk report, take the time to review the identity secure score report.

Don’t forget to sign up for the IDG Tech Talk channel where you can see more videos of my Windows security tips.

Related content

How the toddycat threat group sets up backup traffic tunnels into victim networks, new ot security service can help secure against critical systems attacks, what is biometrics 10 physical and behavioral identifiers that can be used for authentication, the rise in ciso job dissatisfaction – what’s wrong and how can it be fixed, from our editors straight to your inbox.

Susan Bradley has been patching since before the Code Red/Nimda days and remembers exactly where she was when SQL slammer hit (trying to buy something on eBay and wondering why the Internet was so slow). She writes the Patch Watch column for Askwoody.com, is a moderator on the PatchManagement.org listserve, and writes a column of Windows security tips for CSOonline.com. In real life, she’s the IT wrangler at her firm, Tamiyasu, Smith, Horn and Braun, where she manages a fleet of Windows servers, Microsoft 365 deployments, Azure instances, desktops, a few Macs, several iPads, a few Surface devices, several iPhones and tries to keep patches up to date on all of them. In addition, she provides forensic computer investigations for the litigation consulting arm of the firm. She blogs at https://www.askwoody.com/tag/patch-lady-posts/ and is on twitter at @sbsdiva. She lurks on Twitter and Facebook, so if you are on Facebook with her, she really did read what you posted. She has a SANS/GSEC certification in security and prefers Heavy Duty Reynolds wrap for her tinfoil hat.

More from this author

Us federal agencies get first crack at expanded microsoft 365 logging capabilities, teams, slack, and github, oh my – how collaborative tools can create a security nightmare, thinking beyond bitlocker: managing encryption across microsoft services, how to proactively prevent password-spray attacks on legacy email accounts, most popular authors.

Show me more

The assumed breach conundrum.

Authentication failure blamed for Change Healthcare ransomware attack

Russian state-sponsored hacker used GooseEgg malware to steal Windows credentials

CSO Executive Sessions: Geopolitical tensions in the South China Sea - why the private sector should care

CSO Executive Sessions: 2024 International Women's Day special

CSO Executive Sessions: Former convicted hacker Hieu Minh Ngo on blindspots in data protection

LockBit feud with law enforcement feels like a TV drama

Sponsored Links

• Tomorrow’s cybersecurity success starts with next-level innovation today. Join the discussion now to sharpen your focus on risk and resilience.

• Privacy Policy

Select Page

Step-by-Step guide to manage Impossible travel activity alert using Azure cloud app security

Posted by Dishan M. Francis | Sep 23, 2018 | Azure , Azure Active Directory | 2 |

Last Updated on September 26, 2018 by Dishan M. Francis

Let’s assume one of user in your sales team log in to https://myapps.microsoft.com and launch salesforce app successfully from his office in UK. Few minutes later the same user made successful login from Canada. Unless user is using remote connection, it is not impossible. Still someone can’t travel that fast ?. Azure Active Directory capable of detect this type of impossible sign-in activities. However, detection type for this kind of activities is “ offline ”. Which means reporting latency for these alerts are between 2 to 4 hours . 

Azure cloud app security also capable of detecting these types of activities but it is real-time as it detects activities based on sessions. It helps administrators to react faster and protect infrastructure from potential breach. In this demo, I am going to demonstrate how to fine tune built in azure cloud app security policy for Impossible travel activity and prevent breach. 

Before we start, first we need to integrate SaaS app with cloud app security. In my previous post I demonstrate how to do that. So please go ahead and read it on https://www.rebeladmin.com/2018/09/step-step-guide-block-data-download-using-azure-cloud-app-security/

In my demo I am using salesforce app. 

1. Once integration is done, log in to https://portal.cloudappsecurity.com as global administrator.

2. Then go to Settings | Conditional access app control

3. There you should be able to see your app under Conditional access app control tab. It should be in healthy connected status. 

4. Then click on Control | Policies

5. Under policies, click on impossible travel policy 

6. This is a built-in policy. as you can see it doesn’t have any actions attached to it. if CAS detect such activity, it will still be reported under CAS dashboards. 

7. In my environment, I like to get an alert if its detect such activity. To do that, click on Send alert as email option under Alerts . Then define email address in text box. 

8. I also like to suspend the user account, so it gives my team enough time to review the alert and do the necessary adjustments. To do that, click on All apps under Governance and click on Suspend user check box. 

9. To complete the action, click on Update .

10. Policy is updated now. For testing I am login from two VMs located on two different locations.

11. Once the login is done, I came back to https://portal.cloudappsecurity.com . Then click on Salesforce app.

12. Under the alerts I can see it detected impossible travel activity. Click on it to view more details.

13. In there we can see in-details error description & activity log. 

14. According to policy, I also should get email alert. When I log in to email I can see email alert for the activity as expected. 

15. According to policy it also should suspend the user account. When I try to login again as the same user I got following account lock out error. 

Cool ha? As expected policy detects the activities in real-time and take necessary actions as defined. 

This marks the end of this blog post. If you have any further questions feel free to contact me on [email protected] also follow me on twitter @rebeladm to get updates about new blog posts.

Related Posts

Step-by-step guide: how to apply security baselines to windows 10 devices using microsoft intune.

August 25, 2019

Step-by-Step Guide: How to transfer data to or from storage account using AzCopy

December 3, 2019

Step-by-Step Guide to manage Azure Active Directory Domain Service (AAD-DS) managed domain using Virtual Server

May 15, 2016

How Azure RMS Works?

May 13, 2019

I am currently using the impossible travel alert for Office 365 logins. However, the alert goes off even if the login from an impossible travel location was unsuccessful.

This has made this alert useless because these unsuccessful logins are happening all the time as bots and bad actors are constantly trying to log in to my users accounts.

Is there a way to set the alert to only kick off if the login was successful?

This is also detecting account login via VPN in different location. How can we exclude that ? also, failed logins are also coming as alert. can we exclude them to reduce number of false positive.

Trackbacks/Pingbacks

• travel cloud login - Login Portal - […] 8. Step-by-Step guide to manage Impossible travel activity … […]

Leave a reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

I am Dishan Francis. I’m a Cyber Security Consultant at Microsoft. I’m a dedicated and enthusiastic information technology expert who enjoys professional recognition and accreditation from several respected institutions. I am maintaining this blog for last 11 years. This includes more than 400 articles already. These are mainly about Microsoft Active Directory Service and Azure Active Directory Service. I also blog about different Azure services. If you need further help on subject matters, feel free to contact me on [email protected]. Also to get latest updates, follow me on twitter @rebeladm

Mastering Active Directory, Third Edition

I am glad to announce the release of my new book “ Mastering Active Directory – 3rd Edition ”. It is available for purchase worldwide now For more info….

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The difference between "Atypical travel" and "Impossible travel" #86742

ShawnHag commented Jan 21, 2022

SaurabhSharma-MSFT commented Jan 21, 2022

Sorry, something went wrong.

shashishailaj commented Jan 23, 2022

A signin event is related specifically to signing in . However an activity essentially is a term used in Microosft Defender for cloud apps meaning either signing in to the application or any other other activity within the application . For example a user could logon to their onedrive account from two locations within minutes of time difference between both attempts however they could have a valid session and be trying to upload a new file from both locations at the same time or with very low difference from two long distant geographic location . Thus an activity could be signin or any other request within the application like editing a site in sharepoint online etc.

Atypical travel essentially means a location which may not be too far from user's usual logon location but they seldom logon form that for example two different locations within the same city . As mentioned in the above table in the article "the algorithm ignores obvious "false positives" contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. "

However Impossible travel is when a user logs in from New York now and the next minute a signin attempt of the user from London which is a geographically distant city from New York and impossible for the user to travel from NY to London within a minute .

Hope this clarifies the query .

ShawnHag commented Jan 24, 2022

No branches or pull requests

Azure Scene

Microsoft Azure & Microsoft 365

How to enable Azure AD Identity Protection

• Azure Active Directory
• Identity Protection
• Microsoft 365

Azure AD Identity Protection requires Azure AD P2 licenses. Azure AD Identity Protection is not included with Azure AD P1 or Microsoft 365 Business.

Azure AD Identity protection is a premium tool that analyses 6.5 trillion signals per day to identify and protect customers from threats. Identity protection has two types of risk where some are calculated offline and some in realtime.

This blog post is part of my Azure AD Best Practices post.

User risks are calculated offline by Microsoft’s internal and external threat intelligence sources. These sources include security researchers, law enforcement professionals, security teams at Microsoft and more. A user risk represents the probability that a user is compromised. User risk is always calculated offline.

Leaked credentials

The Microsoft leaked credentials service acquires credentials on the dark web, paste sites, password dumps and more. All these passwords are checked against the users’ current credentials to find a match.

Azure AD threat intelligence

The activity of the user is compared with the normal activity for the given user. Unusual activy or activity that is consistent with known attach patterns will be flagged.

Sign-in risk

A Sign-in risk is calculated offline or in realtime and represents the probablity that an authentication request isn’t legit. Unlike User risk, there are more detection types in place.

Do you see ‘ additional risk detected ‘ in your portal? This means that one of the risks below is detected. Additional risk detected is shown to customers without Azure AD P2 licenses.

Admin confirmed user compromised

When an admin has selected confirm user compromised in the risky user portal (or by using Microsoft Graph).

Atypical travel

Atypical travel is an offline detection type that identifies sign-ins originating from geographically distant locations. A machine learning algorithm takes the past behavior of the user into account to identify the risk. Impossible travel time will indicate that a different user is using the credentials to log on.

Atypical travel has a learning period of 14 days or 10 logins (whatever comes first) in which in learns the sign-in behavior of a new user. Because of this, false positives are being ignored (regulary locations in the organization, VPN’s, ..)

Anonymous IP Address

Anonymous is a realtime detection type that identifies sign-ins from IP addresses that are used by VPN services or anonymous browsers like Tor. These services are typically used by people with malicious intent.

Unfamiliar sign-in properties

Unfamiliar sign-in properties is a realtime detection type that compares sign-ins with the sign-in history of a user. The risk score is computed in real-time while logging on and looks at IP address, location, known/past IP addresses, IP carriers and browser sessions.

Unfamiliar sign-in properties has a dynamic learning period . A user will be in learning mode for a minimum duration of five days untill the algorith has enough information about the users behavior.

Malware linked IP address

Malware linked IP address is an offline detection type that will trigger when a sign-in from an IP address that is known to actively communicate with a bot server.

Malicious IP address

Malicious IP address is an offline detection type that indicates sign-in from an IP address that has a high logon failure rate because of invalid credentials.

Configure Azure AD Identity Protection

3 policies should be enabled to fully use the capabilities of Identity Protection. Keep in mind that there will be user impact.

MFA registration policy

The MFA registration policy will manage the roll-out of Azure Multi-Factor Authentication registration by configuring a Conditional Access policy to require MFA. Even if MFA is not enabled, MFA registration is required. Be sure to configure this policy when using Identity Protection because it will have impact on the policies below.

Enabling this policy will have impact on the users that are scoped in this policy . After enabling the policy users will be prompted to register for multi-factor authentication. Users will have 14 days to complete registration and are able to skip to prompts in this period. After 14 days they are forced to complete registration before they can sign in. If users already have registered for MFA they won’t see this prompt.

• Sign-in to your Azure Portal as global administrator .
• Seach for Azure AD Identity Protection

• Click on the MFA registration policy to start configuring.

• Assign the policy to All Users . It possible to exclude users or groups if needed but I advise you don’t do this.
• Be sure to select Require Azure MFA registration under Controls .
• Enforce the policy and click Save .

User risk policy

Enabling this policy will have impact on the users that are flaged as risky . Use the Overview page to investigate the current situation.

When this policy is triggered the user will be required to use muti-factor authentication and change their password. Users who aren’t registered for MFA will be blocked from accessing the account. If a user is blocked, and admin is required to unblock the account.

• Click on the User risk policy to start configuring.

• Assign the policy to All Users .
• Click Conditions and select the approporiate user risk level . Microsoft’s recommendation is to set the user risk policy threshold to High . Depending on your environment i should try Medium and above (after investigating user impact).
• Click Controls and be sure to check Allow Access, Require password change.

• Optional: Review the impact on your environment. You should do this before configurin the policy by using the Overview page.

Sign-in risk policy

When this policy is triggered the user will be required to use muti-factor authentication before accessing the account. Users who aren’t registered for MFA will be blocked. If a user is blocked, and admin is required to unblock the account.

• Click on the Sign-in risk policy to start configuring.

• Click Conditions and select the approporiate user risk level . Microsoft’s recommendation is to set the sign-in risk policy threshold to Medium and above .
• Click Controls and select Require multi-factor authentication .

Notifications

it’s advisable to review your risky users and sign-ins every week . Depending on your policy low or medium risky users aren’t required to act, but there could be something going on. Be sure to enable notifications/email alerting on an approporiate risk level.

• Click on Users at risk detected alerts .
• Select the approporiate risk level (Medium is a perfect choice).
• Select your recipients and click save.

Weekly email digests can help you to review the risk every week so be sure to enable this as well!

Guest Users

Configuring the policies above will have impact on all Guest users in your tenant. Have a look at my blog post explaining this.

That’s it! You’re done configuring Azure AD Identity Protection and you tenant is more secure than before. Don’t forget to review the risky users and sign-ins weekly. Got questions or tips? Just leave a comment!

Hi, What are the best approaches to tune unfamiliar sign-in and atypical travel as these are very noisy at the moment. Our environment is in the education sector and currently doesn’t seen to cope very well AAD identity protection.

Hello! I’m afraid that’s not possible. This is a feature, completely controlled by Microsoft.

True, but I think you can add IPs to Named Locations CAPs, and this will lower the risky sign-in detection and false positives.

You can label trusted IP address ranges in your organization with named locations. Azure AD uses named locations to: -Detect false positives in risk detections. Signing in from a trusted location lowers a user’s sign-in risk. https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/quickstart-configure-named-locations

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

• Conditional Access
• Managed Service Provider
• Microsoft Azure
• Microsoft Teams
• Traffic Manager
• Universal Print

A small donation will keep this blog online.

‘Impossible Travel’ Tests Limits of Anomalous Detection

Systems that identify anomalies in employee email and collaboration can reduce cyber risk but increase security team workloads. AI is bringing relief.

• ‘Impossible travel,’ when a user logs in from different locations faster than humanly possible, proves easier for systems to spot than to resolve.
• Security professionals are often overwhelmed by false positives and lack time to investigate all the alerts.
• Here’s how social graphs can help security teams figure out what’s worth investigating. 

“Impossible travel” enjoys a droll reputation as one of the more apparent indicators of a cyber anomaly. Knowing that a person can’t be in two places at once, today’s cybersecurity software can detect anomalous behavior and take actions such as raising alerts or isolating messages as needed. 

When a user logs into the cloud, the system records a timestamp and a user’s GPS and IP addresses. The next time the user logs in, the system automatically checks the last login data and calculates the difference between the locations. By Microsoft’s definition, impossible travel occurs “if the same user connects from two different countries and the time between those connections can’t be made through conventional air travel.” [1]

Sounds straightforward, except that many of these alerts result in false positives. Hybrid work has exacerbated the issue. Many knowledge workers log into servers from around the globe, using VPNs that complicate location verification. Cybersecurity software may monitor logs showing that a trusted user last checked in from Paris, France, but is logging in 75 minutes later via Paris, Texas.

Improperly managed, impossible travel adds to a security team’s daily noise. The average security team fields over 11,000 alerts per day, mainly manually, according to Forrester’s State of SecOps in 2021 report. Nearly a third of those alerts are false positives. [2]

Can Artificial Intelligence Meet This Challenge?     

Intriguing or not, impossible travel is another of the challenges faced daily by security teams — an indicator that could signify malicious activity such as phishing or ransomware.

In other words, impossible travel represents the sort of email threat that machine learning and artificial intelligence (AI) can detect and manage. And that’s important because the risk is undiminished. In Mimecast’s  State of Email Security 2022 (SOES) report, 72% of respondents said the number of email-based threats had increased in the past 12 months, with 26% describing the threat level as significant. Yet, the SOES study also indicates that fewer than half of respondents’ companies have a system for monitoring email attacks. 

Still, security pros believe AI can improve their effectiveness. In the SOES study, 56% of respondents confirmed that AI had increased threat detection accuracy. However, for many security teams, the constant challenge is weeding out false positives. One approach entails looking at each case manually. One security maven on Reddit (r/cybersecurity) noted that to prove an alert is a false positive, you “need to provide a plausible benign scenario that explains the anomalous activity.” If not, he would prohibit the activity. [3]

Yet, amid continued staffing shortages, the more significant problems concern a lack of time and resources to intervene manually. Rather than try to resolve each alert on a one-off basis, many organizations apply AI, automation, and integration to prevent breaches.  Mimecast’s email security approach blocks email threats with AI-powered detection, including identity and social graphing for anomaly and phishing detection. 

These capabilities detect and block targeted email threats such as:

• Anomalous behaviors associated with malicious email.
• Misaddressed emails, to prevent data loss by mistakenly emailing the wrong people.
• Highly targeted spearfishing attacks.
• Trackers embedded in emails.

Recognizing the New Normal

Social graphing is technology that uses machine learning to recognize what’s normal and what’s not about email and communications. Mimecast CyberGraph deploys this technology to map an organization’s communications patterns, tracking connections between senders and recipients, including the strength or proximity of those relationships. 

The resulting data enables security teams to spot anomalous behaviors and block targeted and malicious email attacks that rely on tactics like social engineering and fileless malware. And CyberGraph continually finetunes results using a feedback loop to reduce false positive rates. Mimecast’s software can also heighten employee awareness of risks and threats by inserting contextual, real-time warnings in email, calling out when an email comes from an unknown source. 

Social graphing data can also recognize patterns and help security teams craft relevant policy exceptions. For instance, the  Mimecast X1 platform’s global policy engine may recognize that a particular employee is likely to log in or collaborate from anywhere. This knowledge reduces manual efforts, supports compliance, and lessens risk. Creating an exception also reduces stress for a roaming employee who may otherwise get temporarily locked out from email or collaboration. 

In an  Enterprise Strategy Group paper called “When the Adversary Knows All About You … Personally,” the author contends that “modern attacks are becoming highly personalized.” The upshot is that attackers tap a range of public information sources and socially engineered communications, among other tricks, to “carry out criminal actions.” Yet, while attackers are getting smarter, technologies such as identity graphs are “helping organizations combat more sophisticated attacks.”

The Bottom Line

Mimecast CyberGraph protects systems from some of the most evasive and hard-to-detect email threats, limiting attacker reconnaissance and mitigating human error. Impossible travel is one of the trickier signs of an attack. Mimecast CyberGraph provides security teams with an approach that integrates into enterprise security environments and applies AI, social graphs, and smart anomaly detection to elevate their ability to detect and mitigate anomalous threats.  Delve deeper into CyberGraph’s capabilities.

[1] “ Detecting and Remediating Impossible Travel ,” Microsoft

[2]  “ State of SecOps in 2021 ,” Forrester

[3]  “ How do you ‘prove’ that an alert is a false positive? ”, Reddit

Related Articles

Subscribe to cyber resilience insights for more articles like these.

Get all the latest news and cybersecurity industry analysis delivered right to your inbox

Sign up successful

Thank you for signing up to receive updates from our blog

We will be in touch!

Azure AD Identity Protection deep dive

One of the advantages of Microsoft having many customers using its services is that Microsoft can leverage data from those customers and apply some real fancy Machine Learning on that data, coming from Azure AD, Microsoft Accounts and even Xbox services.

Based on all that data the Machine Learning capabilities are able to identify identity risks. Based on the risk, automatic investigation, remediation and sharing of that data with other solutions able to leverage it is possible. The outcome of risk is expressed as either High, Medium, Low or No Risk. This outcome can later be used to define policies.

By leveraging Azure AD Identity Protection you are able to use the signals provided by Microsoft and trigger “actions” – the signals can also be leveraged in your conditional access policies.

This article covers the following topics:

Examples of using Identity Protection

How is risk determined.

• Portal Walkthrough

Policy behavior

Disclaimer:  This post reflects the status of Azure AD Identity Protection as of April 7th 2020. Functionality may change, even right after this post has been published.

If for a user, it’s determined that he/she has a high-risk level (as provided by the ML capabilities coming from Microsoft), we can either block access, allow access or allow access but require a password change.

If for a user, it’s determined that his/her sign-in risk level is high, we can either block access, allow access, or allow access but require a MFA.

Within Azure AD Conditional Access, we can provide the sign-in risk level as a condition in our Conditional Access policy. We can then for example, deny access to our finance application if the sign-in risk is Medium or High. See my series of blogposts about Conditional Access for more information on how to create Conditional Access policies.

Based on your Azure AD licensing you can leverage the functionality of Azure AD Identity protection. If you want to use all the functionality though, an Azure AD Premium P2 license is necessary. And since your users benefit from the functionality, you can assume you must license all of your users or define a set of users whom you want to protect using this functionality. See License Requirements for more information.

Note: Licensing is always a challenge and can lead to some strange outcome, read my article titled: “ License requirements for administering Microsoft 365 services ” to get an idea.

Risk is determined based on identified suspicious actions related to user accounts in your Azure AD. Within risk, we either have “User Risk” or “Sign-In risk” where some detections are real-time and others are non-real-time, which Microsoft calls Offline.

A user risk is based on the probability that the identity is compromised. This is either determined by Microsoft finding leaked credentials, or by using Azure AD threat intelligence which can compare user activity with known attack patterns.

Sign-in Risk

A sign-in risk is based on the probability that the authentication request itself is compromised. Detections are based on Anonymous IP address, Atypical travel, Malware linked IP addresses, Malicious IP addresses, Unfamiliar sign-in properties, Suspicious inbox manipulation rules, Impossible travel or by an Admin who confirms a user being compromised manually from the portal.

Both Suspicious inbox manipulation rules and impossible travel signals are provided by Microsoft Cloud App Security (MCAS), another great example of products sharing data with each other for the better.

If you are not licensed for Azure AD Premium P2, you might see the “Additional risk detected” which is either one of the risk detections mentioned but cannot be seen due to the license in place.

If you want to know more about the risk detection, I suggest to read the following article on Microsoft Docs: What is risk?

Portal walkthrough

Azure AD identity protection is available either by searching for Identity Protection in the Azure Portal or by browsing to Manage | Security | Identity Protection from the Azure AD management portal. Once opened the portal will look similar to the picture below, keep in mind that we do not have much users in my tenant, so in a bigger tenant more data will probably be available.

With the portal there are 4 sections, Protect, Report, Notify and Troubleshooting + Support, let’s go into some more detail for each of them.

Under protect we can create User risk, Sign-in risk and MFA registration policies. While these policies are similar to Conditional Access policies, they aren’t the same. This sometimes can cause some confusion, because the most obvious place to look for policies like this would be under Conditional Access and not under Identity Protection. 

User risk policy

The user risk policy allows you to either block access, allow access or allow access but force a password change for users with a certain user risk defined.

Sign-in risk policy

The sign-in risk policy allows you to either block access, allow access or allow access but force a MFA challenge for sign-ins considered with a certain risk.

The MFA registration policy allows you to force users to do a MFA registration before continuing their login via Azure AD.

Under reports we can find reports on risky users, risky sign-ins and risk detections.

For each risky user, you have the option to view data like: User’s sign-ins, User’s risky sign-ins and User’s risk detections. Besides that you have the option to: Reset the password, Confirm user compromised, Dismiss user risk, block user and Investigate the user with Azure ATP (opening a new window)

Risky sign-in

For each risky sign-in, which can be more than one for a specific user, you see more detailed information about the Location, IP address, Operating System and Device Browser used when the risky sign-in took place. Once a risky sign-in is selected you have the same options available for the user as described at risky user.

Risk detections

Risk detections shows the type of Risk detected, the IP address and the location, also here, once an event is selected you have the same options available as described at risky user.

Users at risk detected alerts

Under notify you can configure who needs to be notified by email is a certain risk level is detected. You can alert on Low and above, Medium and above and High. Emails are sent to the following users. New global admins, security admins and security readers will be added to this list by default and can also only be selected. You also have the option to include additional email addresses which receive a notification as well.

Weekly digest

You can also enable the option to send out a weekly digest, new global admins, security admins and security readers will be added to this list by default and can only be selected. If you need to add users who are eligible for any of these roles make sure that they are activated if you want to add them to the list.

Troubleshooting and Support

Under troubleshooting you can find some common problems, at time of writing there are not common problems described, but this can change in the future. Here you also have the option to create a new support request.

Below is two galleries with displaying the behavior from an end-user point of view if the MFA registration policy and User risk policy have been enabled.

MFA registration policy behavior

User risk policy behavior

We can test whether user risk is working by using the Tor browser , by using the Tor browser we can mimic unusual behavior for the user, which then receives a high risk rating.

Azure Active Directory Identity Protection provides some really useful features which can help to automate and mitigate security related incidents.

Big disadvantage is the way that it’s currently licensed, making the functionality only available for user licensed with Azure AD Premium P2 or E5 licenses.

If you have the necessary licenses available, then implementing Azure AD Identity Protection is a must-have solution in my opinion. I hope this article helped you to get an idea of what it can do, and how to implement it in your organization.

What is Azure Active Directory Identity Protection?

Eight essentials for hybrid identity #3: Securing your identity infrastructure

What is risk?

Conditional Access: Risk-based Conditional Access

3 thoughts on “ Azure AD Identity Protection deep dive ”

• Pingback: Conditional Access demystified: My recommended default set of policies | Modern Workplace Blog

Hi, you are one of the only ones that has an overview of the Sign-in activity and matching Risk level. I was searching but could not find an (up-to-date Microsoft) page that has all of them. Do you know where to find that by any chance?

I don’t have a clue anymore where I got that information at that time, it was probably documented in the MS documentation, but I see now that it has been removed. That might also mean that the information in this blogarticle is not relevant anymore when it comes to sign-in activity and matching risk level.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Privacy Overview

• Secure Score Series
• Power Platform
• [email protected]

Close the gap. Azure AD Identity Protection & Conditional Access.

• July 14, 2020 February 15, 2021
• Entra , Security

This blog is about Azure AD Identity Protection and Conditional Access, and how these two features are working together. This is not my first article on this subject. (neither my last) In previous blogs, I covered the sign-in risk and user risk policies as part of the Secure Score Series, and in my blog, about Azure Multifactor Authentication I talked about Azure AD Identity Protection, and how it can be used to roll out MFA in your organization.

Microsoft released the user risk integration with Conditional Access last week, so for me, it seemed the perfect occasion to write a blog about this. To understand why this integration is such a big deal, let’s first take a look at those two features individually.

What is Conditional Access?

Conditional Access is a feature in Azure Active Directory and requires a Premium P1 license. It can be used to protect your Office 365 and Azure AD resources. I often call it: ” the firewall of the cloud”. You can deploy if-this-than-that statements to determine who has access to resources and under what conditions.

There are a lot of signals and conditions that can be used. Also, Conditional Access integrates with many other security features such as Microsoft Defender ATP, Intune (App Protection), and Cloud App Security. You can build policies like:

• To access Exchange Online from an unmanaged device, all users have to perform MFA.
• Users in the sales team can not access the CRM application unless they are using a managed device.
• When users access SharePoint Online from an untrusted device, they cannot download or upload documents.
• Users who access Onedrive for Business on their iOS or Android device must use the (protected) Onedrive app.

What is Azure AD Identity Protection?

Azure AD Identity Protection is also a premium feature in Azure Active Directory but requires a Premium P2 license. The feature is all about risk detection and remediation. Identity protection uses Azure AD threat intelligence to determine whether the sign-ins are risky . In case of a risky sign-in, the user can self-remediate by approving the MFA request.

All the sign-ins are aggregated so that the user risk is calculated. This happens both in real-time and offline. You can investigate the risks from the Azure portal, or export the risk data to analyze it elsewhere.

Multiple risks can be detected. The most important one is the ability to detect leaked credentials . To take advantage of that feature, you’ll have to turn on password hash synchronization. You can read all about that part in one of my previous blogs. There are a couple of other risks that can be identified:

• Atypical travel
• Anonymous IP address
• Unfamiliar sign-in properties
• Malware linked IP address
• Known attack patterns

Malicious IP addresses are detected when attackers use dictionary attacks, brute force, password spray, or list cleaning methods.

When you are licensed for Cloud App Security , Identity Protection can also detect additional risks such as suspicious inbox manipulation rules and impossible travel.

Risk and remediation

So, Azure AD Identity Protection gives you two parameters that you can work with:

• User risk (represents the probability that a given identity or account is compromised.)
• Sign-in risk (represents the probability that a given authentication request isn’t authorized by the identity owner.)

Take a look at this overview to understand the flow of Azure AD Identity Protection.

For both risk types, you can set up policies to let users remediate the risk. Users with a risky sign-in can self-remediate by satisfying the MFA challenge. Users that trigger the user risk policy, can be blocked or forced to reset their password.

That brings us to the core of this blog post. As these policies apply for all of the Azure resources and applications, some organizations want to configure some granularity on top, or instead of these policies.

Conditional Access goodness

As of today, both user and sign-in risk can be used as conditions in Conditional Access. The ‘sign-in risk’ condition is out of preview already, and Microsoft recently added the ‘user risk’ condition. Take note this feature is still in preview at the time of writing.

Next, you can configure the action. You can block access, or force a password reset. When you pick “Require Password change (Preview)”, take note of these three things:

• “Require multi-factor authentication” is also checked
• This will only work when you select “All cloud apps”
• You can only select the User risk (Preview) condition in combination with password reset. All other conditions are greyed out.

User risk support in Azure AD Conditional Access policy allows you to create multiple user risk-based policies. Different minimum user risk levels can be required for different users and apps. Based on user risk, you can create policies to block access, require multi-factor authentication, secure password change, or redirect to Microsoft Cloud App Security to enforce session policy, such as additional auditing. Also, you could make use of the report-only setting to measure user impact first.

Sign-in experience

For this demo, I created a policy that will force a password reset once the user’s risk level is medium or high . Once the user has reached that point, the user will be prompted for MFA first. After successful authentication, the user can change the password.

Good to know

When you have configured either “Require multi-factor authentication” or “Require password change (Preview)” and the user has not registered for MFA, the session will be blocked.

So, why is this better?

As I mentioned earlier, organizations can now deploy more fine-grained and specific policies, based on user risk. You can now use multiple conditions and make full use of the exclusions. You could build a policy to block access for high-risk administrator accounts, and have another one for your regular users with different conditions and controls.

Azure AD Identity Protection is a must-have if you ask me. At least for your administrators and users that have access to intellectual property or high confidential data. When those users get breached, it will most likely damage your companies reputation and cost a lot of money and effort to restore the damage. That’s an easy business case right? You can try Azure Premium for free. This will give you instant insight into your risky users.

I suggest you take a look at this video: Ignite 2019 session about Azure Active Directory Identity Protection

This will give you some in depth information about how risk is detected and how you can integrate this product with other systems.

Also check out the Microsoft documentation to learn more about the premium features:

Azure AD Conditional Access documentation

Azure AD Identity Protection documentation

Also, check out these base protection policies to get you started.

Update 02-2021: Sometimes I get the question if you can send out alerts to end-users so that they can respond to sign-ins in order to train the system. However, check out this note that I found in the FAQ :

Today, selecting confirm safe on a sign-in does not by itself prevent future sign-ins with the same properties from being flagged as risky. The best way to train the system to learn a user’s properties is to use the risky sign-in policy with MFA. When a risky sign-ins is prompted for MFA and the user successfully responds to the request, the sign-in can succeed and help to train the system on the legitimate user’s behavior.

If you believe the user is not compromised, use  Dismiss user risk  on the user level instead of using  Confirmed safe  on the sign-in level. A  Dismiss user risk  on the user level closes the user risk and all past risky sign-ins and risk detections.

6 thoughts on “Close the gap. Azure AD Identity Protection & Conditional Access.”

Pingback:  Close the gap. Azure AD Identity Protection & Conditional Access. – JanBakker.tech – 365 admin service

Pingback:  Control access from unmanaged devices with Cloud App Security - JanBakker.tech

Hi. Is there a way to trigger an alert for changes to a Conditional Access rule? I don’t find it in the list of items I can alert on in the Security Admin module.

Good question. The only way that I can think off, is to use Azure monitor to query against Log Analytics with KQL. https://www.chorus.co/resources/news/setting-up-conditional-access-alerts

Pingback:  10 tips to secure your identities in Microsoft 365 - JanBakker.tech

Hi, if you enable the CA policy to reset password for high user risk and it triggers, does it automatically remove and dismiss the risk from AD Identity protection?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Related Posts

Get started with passkeys in Microsoft 365

• April 13, 2024 April 24, 2024
• 13 min read

It’s here! A long-awaited feature in Microsoft 365 is finally there. Now, in public preview, organizations can add another phishing-resistant credential to their arsenal: device-bound… 

How to simulate risk in Microsoft Entra ID Protection

• March 19, 2024 April 11, 2024

Entra ID protection is an excellent feature amongst the other services in the Entra Premium P2 license SKU. Microsoft Entra ID Protection detects identity-based risks… 

Microsoft 365 end-user notifications for changes in authentication methods

• February 21, 2024 February 23, 2024
• Entra , Logic Apps , Security
• 12 min read

When moving away from traditional and weak authentication methods like passwords to stronger ones like Authenticator App and passkeys, it’s essential to keep informed when… 

• Threat intelligence
• Attacker techniques, tools, and infrastructure

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud

• By Microsoft Threat Intelligence
• Social engineering / phishing
• Adversary-in-the-middle (AiTM)
• Credential theft

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

A large-scale phishing campaign that used adversary-in-the-middle (AiTM) phishing sites stole passwords, hijacked a user’s sign-in session, and skipped the authentication process even if the user had enabled multifactor authentication (MFA). The attackers then used the stolen credentials and session cookies to access affected users’ mailboxes and perform follow-on business email compromise (BEC) campaigns against other targets. Based on our threat data, the AiTM phishing campaign attempted to target more than 10,000 organizations since September 2021.

Phishing remains to be one of the most common techniques attackers use in their attempts to gain initial access to organizations. According to the 2021 Microsoft Digital Defense Report , reports of phishing attacks doubled in 2020, and phishing is the most common type of malicious email observed in our threat signals. MFA provides an added security layer against credential theft, and it is expected that more organizations will adopt it, especially in countries and regions where even governments are mandating it. Unfortunately, attackers are also finding new ways to circumvent this security measure. 

In AiTM phishing, attackers deploy a proxy server between a target user and the website the user wishes to visit (that is, the site the attacker wishes to impersonate). Such a setup allows the attacker to steal and intercept the target’s password and the session cookie that proves their ongoing and authenticated session with the website. Note that this is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user’s behalf, regardless of the sign-in method the latter uses.

Microsoft 365 Defender detects suspicious activities related to AiTM phishing attacks and their follow-on activities, such as session cookie theft and attempts to use the stolen cookie to sign into Exchange Online. However, to further protect themselves from similar attacks, organizations should also consider complementing MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals like user or group membership, IP location information, and device status, among others. 

While AiTM phishing isn’t new, our investigation allowed us to observe and analyze the follow-on activities stemming from the campaign—including cloud-based attack attempts—through cross-domain threat data from Microsoft 365 Defender. These observations also let us improve and enrich our solutions’ protection capabilities. This campaign thus also highlights the importance of building a comprehensive defense strategy. As the threat landscape evolves, organizations need to assume breach and understand their network and threat data to gain complete visibility and insight into complex end-to-end attack chains.

In this blog, we’ll share our technical analysis of this phishing campaign and the succeeding payment fraud attempted by the attackers. We’ll also provide guidance for defenders on protecting organizations from this threat and how Microsoft security technologies detect it.

How AiTM phishing works

Every modern web service implements a session with a user after successful authentication so that the user doesn’t have to be authenticated at every new page they visit. This session functionality is implemented through a session cookie provided by an authentication service after initial authentication. The session cookie is proof for the web server that the user has been authenticated and has an ongoing session on the website. In AiTM phishing, an attacker attempts to obtain a target user’s session cookie so they can skip the whole authentication process and act on the latter’s behalf.  

To do this, the attacker deploys a webserver that proxies HTTP packets from the user that visits the phishing site to the target server the attacker wishes to impersonate and the other way around. This way, the phishing site is visually identical to the original website (as every HTTP is proxied to and from the original website). The attacker also doesn’t need to craft their own phishing site like how it’s done in conventional phishing campaigns. The URL is the only visible difference between the phishing site and the actual one. 

Figure 2 below illustrates the AiTM phishing process:

The phishing page has two different Transport Layer Security (TLS) sessions—one with the target and another with the actual website the target wants to access. These sessions mean that the phishing page practically functions as an AiTM agent, intercepting the whole authentication process and extracting valuable data from the HTTP requests such as passwords and, more importantly, session cookies. Once the attacker obtains the session cookie, they can inject it into their browser to skip the authentication process, even if the target’s MFA is enabled. 

The AiTM phishing process can currently be automated using open-source phishing toolkits and other online resources. Among the widely-used kits include Evilginx2 ,  Modlishka , and  Muraena .  

Tracking an AiTM phishing campaign

Using Microsoft 365 Defender threat data, we detected multiple iterations of an AiTM phishing campaign that attempted to target more than 10,000 organizations since September 2021. These runs appear to be linked together and target Office 365 users by spoofing the Office online authentication page.

Based on our analysis, these campaign iterations use the Evilginx2 phishing kit as their AiTM infrastructure. We also uncovered similarities in their post-breach activities, including sensitive data enumeration in the target’s mailbox and payment frauds.

Initial access

In one of the runs we’ve observed, the attacker sent emails with an HTML file attachment to multiple recipients in different organizations. The email message informed the target recipients that they had a voice message.

When a recipient opened the attached HTML file, it was loaded in the user’s browser and displayed a page informing the user that the voice message was being downloaded. Note, however, that the download progress bar was hardcoded in the HTML file, so no MP3 file was being fetched.

Instead, the page redirected the user to a redirector site:

This redirector acted as a gatekeeper to ensure the target user was coming from the original HTML attachment. To do this, it first validated if the expected fragment value in the URL—in this case, the user’s email address encoded in Base64—exists. If the said value existed, this page concatenated the value on the phishing site’s landing page, which was also encoded in Base64 and saved in the “link” variable (see Figure 7 below).

By combining the two values, the succeeding phishing landing page automatically filled out the sign-in page with the user’s email address, thus enhancing its social engineering lure. This technique was also the campaign’s attempt to prevent conventional anti-phishing solutions from directly accessing phishing URLs.

Note that on other instances, we observed that the redirector page used the following URL format:

In this format, the target’s username was used as part of an infinite subdomains technique, which we have previously discussed in other phishing campaigns .

After the redirection, the user finally landed on an Evilginx2 phishing site with their username as a fragment value. For example:

The phishing site proxied the organization’s Azure Active Directory (Azure AD) sign-in page, which is typically login.microsoftonline.com . If the organization had configured their Azure AD to include their branding, the phishing site’s landing page also contained the same branding elements.

Once the target entered their credentials and got authenticated, they were redirected to the legitimate office.com page. However, in the background, the attacker intercepted the said credentials and got authenticated on the user’s behalf. This allowed the attacker to perform follow-on activities—in this case, payment fraud—from within the organization.

Post-breach BEC

Payment fraud is a scheme wherein an attacker tricks a fraud target into transferring payments to attacker-owned accounts. It can be achieved by hijacking and replying to ongoing finance-related email threads in the compromised account’s mailbox and luring the fraud target to send money through fake invoices, among others.

Based on our analysis of Microsoft 365 Defender threat data and our investigation of related threat alerts from our customers, we discovered that it took as little time as five minutes after credential and session theft for an attacker to launch their follow-on payment fraud. From our observation, after a compromised account signed into the phishing site for the first time, the attacker used the stolen session cookie to authenticate to Outlook online (outlook.office.com). In multiple cases, the cookies had an MFA claim, which means that even if the organization had an MFA policy, the attacker used the session cookie to gain access on behalf of the compromised account.

Finding a target

The following days after the cookie theft, the attacker accessed finance-related emails and file attachments files every few hours. They also searched for ongoing email threads where payment fraud would be feasible. In addition, the attacker deleted from the compromised account’s Inbox folder the original phishing email they sent to hide traces of their initial access.

These activities suggest the attacker attempted to commit payment fraud manually. They also did this in the cloud—they used Outlook Web Access (OWA) on a Chrome browser and performed the abovementioned activities while using the compromised account’s stolen session cookie.

Once the attacker found a relevant email thread, they proceeded with their evasion techniques. Because they didn’t want the compromised account’s user to notice any suspicious mailbox activities, the attacker created an Inbox rule with the following logic to hide any future replies from the fraud target:

“For every incoming email where sender address contains [domain name of the fraud target], move the mail to “Archive” folder and mark it as read.”

Conducting payment fraud

Right after the rule was set, the attacker proceeded to reply to ongoing email threads related to payments and invoices between the target and employees from other organizations, as indicated in the created Inbox rule. The attacker then deleted their replies from the compromised account’s Sent Items and Deleted Items folders.

Several hours after the initial fraud attempt was performed, the attacker signed in once every few hours to check if the fraud target replied to their email. In multiple instances, the attacker communicated with the target through emails for a few days. After sending back responses, they deleted the target’s replies from the Archive folder. They also deleted their emails from the Sent Items folder.

On one occasion, the attacker conducted multiple fraud attempts simultaneously from the same compromised mailbox. Every time the attacker found a new fraud target, they updated the Inbox rule they created to include these new targets’ organization domains.

Below is a summary of the campaign’s end-to-end attack chain based on threat data from Microsoft 365 Defender:

Defending against AiTM phishing and BEC

This AiTM phishing campaign is another example of how threats continue to evolve in response to the security measures and policies organizations put in place to defend themselves against potential attacks. And since credential phishing was leveraged in many of the most damaging attacks last year, we expect similar attempts to grow in scale and sophistication.

While AiTM phishing attempts to circumvent MFA, it’s important to underscore that MFA implementation remains an essential pillar in identity security. MFA is still very effective at stopping a wide variety of threats; its effectiveness is why AiTM phishing emerged in the first place. Organizations can thus make their MFA implementation “phish-resistant” by using solutions that support Fast ID Online (FIDO) v2.0 and certificate-based authentication.

Defenders can also complement MFA with the following solutions and best practices to further protect their organizations from such types of attacks:

• Enable conditional access policies. Conditional access policies are evaluated and enforced every time an attacker attempts to use a stolen session cookie. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Invest in advanced anti-phishing solutions thatmonitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers that can automatically identify and block malicious websites , including those used in this phishing campaign.
• Hunt for sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, use of anonymizer services).
• Hunt for unusual mailbox activities such as the creation of Inbox rules with suspicious purposes or unusual amounts of mail item access events by untrusted IP addresses or devices.

Coordinated threat defense with Microsoft 365 Defender

Microsoft 365 Defender provides comprehensive protection against this AiTM phishing campaign by correlating threat data from various domains. It also coordinates threat defense against the end-to-end attack chain using multiple solutions and has advanced hunting capabilities that allow analysts to inspect their environments further and surface this threat.

Leveraging its cross-signal capabilities, Microsoft 365 Defender alerts customers using Microsoft Edge when a session cookie gets stolen through AiTM phishing and when an attacker attempts to replay the stolen session cookie to access Exchange Online:

Microsoft 365 Defender’s unique incident correlation technology also lets defenders see all the relevant alerts related to an AiTM phishing attack pieced together into a single comprehensive view, thus allowing them to respond to such incidents more efficiently:

Microsoft 365 Defender is backed by threat experts who continuously monitor the computing landscape for new attacker tools and techniques. Their expert monitoring not only helps alert customers of a possible incident (such as a potential cookie theft during an authentication session), their research on the constantly evolving phishing techniques also enriches the threat intelligence that feeds into the abovementioned protection technologies.

Microsoft Defender for Office 365 detects threat activity associated with this phishing campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

• Email messages containing malicious file removed after delivery​. This alert is generated when any messages containing a malicious file are delivered to mailboxes in an organization. Microsoft removes the infected messages from Exchange Online mailboxes using zero-hour auto purge (ZAP) if this event occurs.
• Email messages from a campaign removed after delivery​. This alert is generated when any messages associated with a campaign are delivered to mailboxes in an organization. Microsoft removes the infected messages from Exchange Online mailboxes using ZAP if this event occurs.

Microsoft Defender for Cloud Apps detects this AiTM phishing and BEC campaigns through the following alerts:

• Suspicious inbox manipulation rule. The attackers set an Inbox rule to hide their malicious activities. Defender for Cloud Apps identifies such suspicious rules and alerts users when detected.
• Impossible travel activity. The attackers used multiple proxies or virtual private networks (VPNs) from various countries or regions. Sometimes, their attack attempts happen at the same time the actual user is signed in, thus raising impossible travel alerts.
• Activity from infrequent country. Because the attackers used multiple proxies or VPNs, on certain occasions, the egress endpoints of these VPN and proxy servers are uncommon for the user, thus raising this alert.

Azure AD Identity Protection automatically detects and remediates identity-based risks. It detects suspicious sign-in attempts and raises any of the following alerts:

• Anomalous Token. This alert flags a token’s unusual characteristics, such as its token lifetime or played from an unfamiliar location.
• Unfamiliar sign-in properties. In this phishing campaign, the attackers used multiple proxies or VPNs originating from various countries or regions unfamiliar to the target user.
• U nfamiliar sign-in properties for session cookies. This alert flags anomalies in the token claims, token age, and other authentication attributes.
• Anonymous IP address. This alert flags sign-in attempts from anonymous IP addresses (for example, Tor browser or anonymous VPN).

In addition, Continuous Access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Learn how you can stop attacks through automated, cross-domain security with Microsoft 365 Defender.

Microsoft 365 Defender Research Team

Microsoft Threat Intelligence Center (MSTIC)

Indicators of compromise (IOCs)

Redirector domains.

• 32sssaawervvvv[.]biz
• adminmmi[.]biz
• auth2022[.]live
• cleanifl[.]com
• docpmsi[.]us
• vrtlsrvmapp[.]biz
• vrtofcvm[.]live

Phishing site domains  

• login[.]actionspsort[.]cam
• login[.]akasmisoft[.]xyz
• login[.]aueuth11[.]live
• login[.]auth009[.]xyz
• login[.]auth2022[.]live
• login[.]auth83kl[.]live
• login[.]bittermann-hh[.]co
• login[.]cbhbanlc[.]com
• login[.]cleanifl[.]com
• login[.]clfonl365[.]xyz
• login[.]gddss36[.]live
• login[.]grodno-pl[.]com
• login[.]hfs923[.]shop
• login[.]karlandpearson[.]com
• login[.]klm2136[.]click
• login[.]login-micro[.]mcrsfts-passwdupdate[.]com
• login[.]mcrosfts-updata[.]live
• login[.]mcrosfts-update[.]cloud
• login[.]mcrosfts-update[.]digital
• login[.]mcrosftts-update[.]cloud
• login[.]mcrsft-audio[.]xyz
• login[.]mcrsfts-cloud[.]live
• login[.]mcrsfts-passwd[.]cloud
• login[.]mcrsfts-passwd[.]digital
• login[.]mcrsfts-passwdupdate[.]com
• login[.]mcrsfts-update[.]cloud
• login[.]mcrsfts-update[.]digital
• login[.]mcrsfts-virtualofficevm[.]com
• login[.]mcrsftsvm-app[.]digital
• login[.]mcrsftsvm-app[.]live
• login[.]mcrsfts-voiceapp[.]digital
• login[.]mcrsftsvoice-mail[.]cloud
• login[.]microsecurity[.]us
• login[.]microstoff[.]xyz
• login[.]mljs365[.]xyz
• login[.]mwhhncndn[.]xyz
• login[.]mycrsfts-passwd[.]live
• login[.]qwwxthn[.]xyz
• login[.]seafoodsconnection[.]com
• login[.]sunmarks[.]co[.]uk
• login[.]tfosorcimonline[.]xyz
• login[.]whitmanlab[.]uk
• login[.]yi087011[.]xyz

Advanced hunting queries  

When an attacker uses a stolen session cookie, the “SessionId” attribute in the AADSignInEventBeta table will be identical to the SessionId value used in the authentication process against the phishing site. Use this query to search for cookies that were first seen after OfficeHome application authentication (as seen when the user authenticated to the AiTM phishing site) and then seen being used in other applications in other countries:

Use this query to summarize for each user the countries that authenticated to the OfficeHome application and find uncommon or untrusted ones:  

Use this query to find new email Inbox rules created during a suspicious sign-in session:

Related Posts

• Microsoft Defender

Threat actors misuse OAuth applications to automate financially driven attacks  

Microsoft Threat Intelligence presents cases of threat actors misusing OAuth applications as automation tools in financially motivated attacks.

• Threat actors

Star Blizzard increases sophistication and evasion in ongoing attacks  

Microsoft Threat Intelligence continues to track and disrupt malicious activity attributed to a Russian state-sponsored actor we track as Star Blizzard, who has improved their detection evasion capabilities since 2022 while remaining focused on email credential theft against targets.

• Mobile threats

Social engineering attacks lure Indian users to install Android banking trojans  

Microsoft has observed ongoing activity from mobile banking trojan campaigns targeting users in India with social media messages and malicious applications designed to impersonate legitimate organizations and steal users’ information for financial fraud scams.

• Microsoft Incident Response

Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction  

Microsoft has been tracking activity related to the financially motivated threat actor Octo Tempest, whose evolving campaigns represent a growing concern for many organizations across multiple industries.

Microsoft Sentinel 101

Learning microsoft sentinel, one kql error at a time, cloud app security azure ad identity protection help.

If you are an Azure AD P2 tenant, or have E5 licensing there is a chance you have had a look at these products, the way they integrate (or don’t integrate) with each other and Azure Sentinel is sometimes a little unclear and known to change. They are meant to take the noise from your data sources like Azure AD sign in logs, or Office activity logs and make some sense of it all and direct the alerts to you, which is great. However sometimes even the alerts left over can be noisy. In Cloud App Security you can definitely tune this alerts which is helpful – for instance, you can change ‘impossible travel’ alerts to only fire on successful logons, not successful and failed. but I personally like getting as much data as I can into Sentinel and work with it in there.

The downside is that sending everything to Sentinel may mean a lot of alerts, even after Cloud App Security and Identity Protection have done their thing. Depending on the size your environment, it still may be overwhelming, say in a month you get 1430 alerts (using the below test data) for various identity issues.

You could just take the stance that for any of these you just sign the person out or force a password reset, that could result in a heap of false positives and frustrating users, and not treating more serious cases with more urgency.

When you connect Azure AD Identity Protection & Cloud App Security to Azure Sentinel, the alerts will show up in the SecurityAlert table with the ProviderNames of IPC and MCAS respectively. MCAS also alerts on a lot of other things, but we will focus on identity issues for now. When we look at the description for these alerts from Identity Protection, they are all kind of the same, something similar to “This risk event type considers past sign-in properties (e.g. device, location, network) to determine sign-ins with unfamiliar properties. The system stores properties of previous locations used by a user, and considers these “familiar”. The risk event is triggered when the sign-in occurs with properties not already in the list of familiar properties. The system has an initial learning period of 30 days, during which it does not flag any new detections…”, MCAS will give you a little more info but we need to really hunt ourselves.

To help us make sense of all these alerts, I thought we could get the details (IPv4 addresses and UserPrincipalName for this example) from our SecurityAlert, then replay that data through the Azure AD SigninLogs table and see if we can find some key alerts

We get our SecurityAlerts over whatever period you want to look through, parse the IPs and UserPrincipalName data out, then we use the mv-expand operator to make a new row for each IP/UPN combination then look up that data to our SigninLogs table. Then to add some more intelligence, we exclude known trusted IP addresses (1.1.1.0/24 in the above example, you can whitelist these in MCAS too of course) and also only filter on successful (ResultType == 0) or successful and then sent to a third party security challenge, such as third party MFA (ResultType == 50158) events. We join on UserPrincipalName where we have a match on one of the IPs taken from the SecurityAlert event. Lastly we count the UserAgents used by each user and tell us when it is new, count == 1.

So get the alerts, grab the IP addresses and user, use that data to look for successful sign ins from non trusted networks on a user agent that is new to that user over the last 3 days. In my test environment full of fake data we go from 1430 alerts, to 11

I am not suggesting you just ignore the other 1119 alerts of course, but maybe these ones you prioritize higher or have a different response to.

Share this:

Leave a comment cancel reply.

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar