Investigating “Microsoft 365: Impossible Travel AAD Login” findings

Overview

This guide contains helpful tips for investigating “Microsoft 365: Impossible Travel AAD Login” findings using Report Builder to review log data for suspicious activity. It includes common scenarios that can trigger impossible travel detections and how to create filters for safe sources, so you stop receiving findings for the same activity if you are certain it is safe.

Events that can trigger “Impossible Travel” findings

There are several event scenarios that can match the logic for impossible travel findings. Below are some common cases and tips for investigating.

Reviewing log data in Report Builder

Reference: For more information about viewing the logs stored in your account, see Using the Report Builder.

To identify user activity from the suspicious IP, we recommend reviewing all sign-ins for the user during and around the timeframe of the finding. As mentioned above, you can start with a global report and customize it to quickly narrow your investigation.

To review your logs in Report Builder, do the following:

1. Navigate to Reporting > Report Builder.
2. Click View all Saved Reports, then find and select Microsoft 365 - Azure AD: Login Report.
   Note: The report defaults to the past 7 days of logs.
3. In Time Range select the timeframe of the activity that you need to investigate.
4. In Data Sources, select all of your available Microsoft 365 data sources to expand the dataset.
   Tip: If you're interested in viewing activity across your entire environment, not just Microsoft, consider adding all available log types.
5. Click Add Filter and then create the following filters: 
   • Add a filter for the user in question.
     
   • Add a filter where client_ip equals the value of the suspicious IP address in question.
     
6. Under Selected Columns, add columns to your report, such as those below, if available, to see more information about the actions taken in Microsoft 365:
   • client_ip
   • client_ip_geoip.city
   • client_ip_geoip.subdivision1code
   • client_ip_geoip.countryname
   • timestamp
   • name
   • operation
   • properties
   • reason
   • smtp_address
   • subject
   • user
7. Click Submit to run the report.

While reviewing the report, look for the following information:

• Where the sign-ins occurred from (client_ip fields)
• Review emails that were sent (Subject field)
• Review the operations that were performed (Operations field)
• If mail rules were created and what they were configured to do (operation, smtp_address, name, and properties)

About delayed “Impossible Travel” findings

The "Indicator: Microsoft 365 - Impossible Travel Activity" detection rule is a real-time detection that generates findings immediately upon matching evidence in your logs. The similarly named but different “Microsoft 365: Impossible Travel AAD Login” group of detection rules is categorized as windowed detection rules. In windowed rules, our platform analyzes sign-in logs over a predefined time window to identify if an impossible travel event occurs.

The initial login and subsequent logins are necessary to determine windowed activity, which users sometimes interpret as delayed findings. This is, instead, the intentional timing of detection to analyze activity and avoid the unnecessary noise of false positives.

The timing for windowed impossible travel detections is as follows: 

• Microsoft 365: Impossible Travel AAD Login - 500 to 999 miles - Detects travel between 500 to 999 miles within a 2-hour window. This rule is disabled by default.
  
  
• Microsoft 365: Impossible Travel AAD Login - 2,001 miles and higher - Detects travel over 2,001 miles within a 6-hour window. This rule is enabled by default.
  
  
• Microsoft 365: Impossible Travel AAD Login - 1,000 to 2,000 miles - Detects travel between 1,000 to 2,000 miles within a 4-hour window. This rule is disabled by default.
  
  

Adding detection filters to allow safe sources

The src_country and client_ip fields always display the two countries and client IPs that were analyzed to determine the impossible travel, separated by a comma. As such, detection filters for “Microsoft 365: Impossible Travel AAD Login” detections will be slightly different than other detections that have one country and IP in these fields.

Filters that use the ”IN” operator will need to have both sequences of country names or IP addresses in the Value field because the country or IP value can be arranged in either order depending on which authentication occurs first.

Here are some example detection filters:

• Allowing impossible travel between United States and Canada for user@company.com

• Allowing impossible travel between the two IPs 1.1.1.1 and 2.2.2.2: