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
- Filtering reports for time range to determine start of unknown behavior
Reviewing reports to scope sign-in events for each user
To review risky sign-ins by user, do the following:
- Navigate to Reporting > Report Builder.
- Click View All Saved Reports.
- Search and click any report titled “Azure/Entra - Risky Sign-In Events - 7 Days.”
- 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:user–Equal–username - 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_namefield - Which client attempted the authentication, in the
client_namefield - The name of the host that observed the authentication request, in the
agentfield - The result of the authentication, in the
action_detailsfield - Whether MFA or single factor authentication was attempted, in the
auth_factor_typefield - Which method was used for the authentication, in the
auth_methodfield - Where the sign-in occurred from, in the
client_ipfield - Why the authentication may have failed, in the
failure_reasonfield - The error code value that can confirm why authentication failed, in the
error_codefield
Reference: See more details about AADSTS error codes here - Whether the authentication succeeded or failed (
resultfield) based on the description in theaction_detailsfield
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:
- Use the report created above as a starting point, and delete the filter
state is not eq null. - 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.
- 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:
- Revoke all sign on and session cookies for the impacted user account.
- Reset the user account password.
- 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.
- Validate user account for any MFA device changes or App Passwords that were created or edited.
- 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