Quick Links

Investigating “Azure Identity Protection Risky Sign-in” findings

Overview

This guide provides steps for investigating “Azure Identity Protection Risky Sign-in” findings using Report Builder to track specifics of sign-in attempts, including whether the sign-in attempts were successful. Microsoft Identity Protection evaluates risky sign-ins based on user behavior and patterns. We recommend starting investigations by reviewing reports on sign-in attempts for specific users, with additional filtering for times of sign-ins. If your account is compromised, follow the steps to secure your account (included below).

Events that can trigger “Azure Identity Protection Risky Sign-in” findings

There are several scenarios that would match detection logic for risky sign-ins. Below are some common cases.

Scenario Considerations
Malicious IPs  Sign-ins are coming from known malicious IPs.
User traveling The user may be traveling abroad and logging into their account from a new location. Confirm with the user if they are traveling and if they are actively logging in.
Numerous attempts  There have been successive failed or successful authentication attempts.
Multiple risks  Multiple risks have been detected on the account (e.g. leaked credentials).

Using Report Builder to investigate 

Reference: See Using the Report Builder for more information about building reports.

You can use Report Builder to investigate risky sign-in findings in several ways including the following:

Reviewing reports to scope sign-in events for each user

To review risky sign-ins by user, do the following:

  1. Navigate to Reporting > Report Builder.
  2. Click View All Saved Reports.
  3. Search and click any report titled “Azure/Entra - Risky Sign-In Events - 7 Days.”
  4. Click Add Filter, then add a filter to the two existing report filters to narrow the activity down to the user you need to review.
    Example: userEqualusername
  5. Click Submit to run the report.

Note: the results will reveal every sign-in action that has been completed for this user over the past 24 hours.

While reviewing the report, determine the source of sign-in action by verifying the following:

  • Which app attempted the authentication, in the app_name field
  • Which client attempted the authentication, in the client_name field
  • The name of the host that observed the authentication request, in the agent field
  • The result of the authentication, in the action_details field
  • Whether MFA or single factor authentication was attempted, in the auth_factor_type field
  • Which method was used for the authentication, in the auth_method field
  • Where the sign-in occurred from, in the client_ip field
  • Why the authentication may have failed, in the failure_reason field
  • The error code value that can confirm why authentication failed, in the error_code field
    Reference: See more details about AADSTS error codes here
  • Whether the authentication succeeded or failed (result field) based on the description in the action_details field

Filtering reports for time range to determine start of unknown behavior

To see all the events where a user had login activity, do the following:

  1. Use the report created above as a starting point, and delete the filter state is not eq null.
  2. Edit Time Range to +- 1 hour from the atRisk event seen in the finding. You can expand this time range further as you investigate more to see when the unknown behavior started for this user account.
  3. Click Submit.

Tip: Ensure you review the subtype field as this will reveal each login for the user account that was Interactive and NonInteractive.

Steps to take if account is compromised

After you investigate and determine the account is compromised, do the following:

  1. Revoke all sign on and session cookies for the impacted user account.
  2. Reset the user account password.
  3. If a successful sign in took place, review other Azure, Entra ID, and Microsoft 365 logs for the user account to see if any other actions were taken.
  4. Validate user account for any MFA device changes or App Passwords that were created or edited.
  5. Review or implement Conditional Access policies within your Entra tenant to harden your authentication approvals.

Additional detection rules for risky behavior

Blumira has a variety of detections that help spot events that could be linked to risky behavior. If the findings below appear in addition to risky sign-in events, investigate them immediately. 

Additional detection rules that are available in Settings > Detection Rules include the following:

  • Azure Identity Protection Risky Sign-in All vs High: We have two versions of this detection that can look for only high-risk events, or all risk events. The "All" detection can have a higher fidelity depending on your user base and their baseline behaviors.
  • Azure: Trusted Location Added or Modified: A trusted location has been added or modified within your Entra instance. Trusted locations are used in conjunction with Conditional Access to help streamline authentication processes.
  • Azure AD Privileged Role Assignment
  • Azure: Failed Single Factor PowerShell Authentication Attempt
  • Disabling of Multi-Factor Authentication on Azure AD User
  • Azure AD - Pass-through Authentication registered: A new pass-through authentication proxy has been detected in your Azure AD. Pass-through authentication proxies can be established for normal administrative activity, but can also be used to capture plaintext active directory credentials.
  • Azure: Entra ID Anomalous Agent Sign-In Activity: An unusual sign-in attempt to your Azure Active Directory using a non-standard agent.
  • Indicator: Azure AD - Conditional Access Policy Added/Modified/Deleted
  • Microsoft 365: Impossible Travel AAD Login: Requires the Microsoft 365 Cloud Connector integration
  • Microsoft 365: Login Blocked due to Conditional Access Policy: Requires the Microsoft 365 Cloud Connector integration
  • Microsoft 365: New MFA Device Added: Requires the Microsoft 365 Cloud Connector integration