Risky Sign-in with new MFA method

Hunt Hypothesis

An adversary may be attempting to compromise an account by first gaining access through a risky sign-in session and then adding a new MFA method to maintain persistent access. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential account takeover attempts and mitigate lateral movement risks.

KQL Query

let mfaMethodAdded=CloudAppEvents
| where ActionType =~ "Update user." 
| where RawEventData has "StrongAuthenticationPhoneAppDetail"
| where isnotempty(RawEventData.ObjectId) and isnotempty(RawEventData.Target[1].ID)
| extend AccountUpn = tostring(RawEventData.ObjectId)
| extend AccountObjectId = tostring(RawEventData.Target[1].ID)
| project MfaAddedTimestamp=Timestamp,AccountUpn,AccountObjectId;
let usersWithNewMFAMethod=mfaMethodAdded
| distinct AccountObjectId;
let hasusersWithNewMFAMethod = isnotempty(toscalar(usersWithNewMFAMethod));
let riskySignins=EntraIdSignInEvents
| where hasusersWithNewMFAMethod
| where AccountObjectId in (usersWithNewMFAMethod)
| where RiskLevelDuringSignIn in ("50","100") //Medium and High sign-in risk level.
| where Application in ("Office 365 Exchange Online", "OfficeHome")
| where isnotempty(SessionId)
| project SignInTimestamp=Timestamp, Application, SessionId, AccountObjectId, IPAddress,RiskLevelDuringSignIn
| summarize SignInTimestamp=argmin(SignInTimestamp,*) by Application,SessionId, AccountObjectId, IPAddress,RiskLevelDuringSignIn;
mfaMethodAdded
| join riskySignins on AccountObjectId
| where MfaAddedTimestamp - SignInTimestamp < 6h //Time delta between risky sign-in and device registration less than 6h
| project-away AccountObjectId1

Analytic Rule Definition

id: 0f57238b-e764-4246-b101-f78bf8c942a7
name: Risky Sign-in with new MFA method
description: |
  Looks for a new MFA method added to an account that was preceded by medium or high risk sign-in session for the same user within maximum 6h timeframe 
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - CloudAppEvents
  - EntraIdSignInEvents
tactics:
- Persistence
query: |
  let mfaMethodAdded=CloudAppEvents
  | where ActionType =~ "Update user." 
  | where RawEventData has "StrongAuthenticationPhoneAppDetail"
  | where isnotempty(RawEventData.ObjectId) and isnotempty(RawEventData.Target[1].ID)
  | extend AccountUpn = tostring(RawEventData.ObjectId)
  | extend AccountObjectId = tostring(RawEventData.Target[1].ID)
  | project MfaAddedTimestamp=Timestamp,AccountUpn,AccountObjectId;
  let usersWithNewMFAMethod=mfaMethodAdded
  | distinct AccountObjectId;
  let hasusersWithNewMFAMethod = isnotempty(toscalar(usersWithNewMFAMethod));
  let riskySignins=EntraIdSignInEvents
  | where hasusersWithNewMFAMethod
  | where AccountObjectId in (usersWithNewMFAMethod)
  | where RiskLevelDuringSignIn in ("50","100") //Medium and High sign-in risk level.
  | where Application in ("Office 365 Exchange Online", "OfficeHome")
  | where isnotempty(SessionId)
  | project SignInTimestamp=Timestamp, Application, SessionId, AccountObjectId, IPAddress,RiskLevelDuringSignIn
  | summarize SignInTimestamp=argmin(SignInTimestamp,*) by Application,SessionId, AccountObjectId, IPAddress,RiskLevelDuringSignIn;
  mfaMethodAdded
  | join riskySignins on AccountObjectId
  | where MfaAddedTimestamp - SignInTimestamp < 6h //Time delta between risky sign-in and device registration less than 6h
  | project-away AccountObjectId1

Required Data Sources

MITRE ATT&CK Context

• Tactic: Persistence

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Persistence/riskySignInToNewMFAMethod.yaml)

False Positive Guidance

• Scenario: A system administrator adds a new MFA method (e.g., Google Authenticator) to their account after logging in via a high-risk session due to IP geolocation mismatch.
  Filter/Exclusion: Exclude sign-ins where the user is a known admin and the MFA method addition is logged in the same session or within 5 minutes of the sign-in.

• Scenario: A scheduled job (e.g., cron job or Azure DevOps pipeline) triggers a sign-in to a service account that then adds a new MFA method as part of an automated configuration update.
  Filter/Exclusion: Exclude sign-ins associated with service accounts or automated processes using the user_principal_name or client_id fields.

• Scenario: A user signs in from a new location (e.g., using a travel app or a hotel Wi-Fi) and then immediately adds a new MFA method as part of a security update.
  Filter/Exclusion: Exclude sign-ins where the user has a recent travel history or is using a known travel IP range, or where the MFA method is added within 1 minute of the sign-in.

• Scenario: An IT support technician uses a privileged account to sign in and then adds a new MFA method during a routine account management task.
  Filter/Exclusion: Exclude sign-ins where the user is marked as an IT admin or has a role that includes account management tasks (e.g., ITSupport or Admin in Azure AD).

• Scenario: A user signs in using a high-risk session (e.g., from a public computer) and then adds a new MFA method as part of a security policy change.
  Filter/Exclusion: Exclude sign-ins where the user has a “high-risk” session but the MFA method addition is part of a known policy update or occurs within 2 minutes of the sign-in