Azure and Entra ID Detection — Sign-in Logs, Activity Logs, and Defender

Azure’s identity system (Entra ID, formerly Azure Active Directory) is the most common enterprise cloud identity platform — making it the primary attack surface and the primary detection surface.

Every authentication event in Entra ID generates a sign-in log entry:

{
  "createdDateTime": "2026-05-18T02:14:23Z",
  "userPrincipalName": "alice@corp.onmicrosoft.com",
  "appDisplayName": "Microsoft Graph",
  "ipAddress": "203.0.113.42",
  "location": {
    "city": "Moscow",
    "countryOrRegion": "RU"
  },
  "status": {
    "errorCode": 0,
    "failureReason": null
  },
  "authenticationRequirement": "singleFactorAuthentication",
  "conditionalAccessStatus": "success",
  "riskLevelAggregated": "high",
  "riskDetail": "unfamiliarFeatures",
  "clientAppUsed": "Other clients; IMAP"
}

Key detection fields: ipAddress, location, status.errorCode, authenticationRequirement, clientAppUsed, riskLevelAggregated.

Detection Pattern 1: Password Spray

Password spray is the dominant initial access technique against M365/Azure environments:

title: Azure Password Spray Attack
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    ResultType: "50126"   # Invalid username or password
  timeframe: 5m
  condition: selection | count(UserPrincipalName) by SourceIP > 10
falsepositives:
  - Misconfigured service accounts with wrong stored credentials
  - Bulk password reset events (coordinate with IT before filtering)
level: high

Additional signals: Check UserAgent — spray tools have distinctive user agents. Real users use modern browsers; spray tools often report python-requests/2.x or curl/7.x.

Detection Pattern 2: Legacy Authentication Protocol Use

Legacy protocols bypass MFA — they remain the most common attack path against organizations that haven’t disabled them:

title: Azure Sign-in via Legacy Authentication Protocol
logsource:
  product: azure
  service: signinlogs
detection:
  selection_legacy_proto:
    ClientAppUsed:
      - "IMAP4"
      - "POP3"
      - "SMTP AUTH"
      - "Exchange ActiveSync"
      - "Exchange Online PowerShell"
      - "Other clients"
  selection_success:
    ResultType: "0"   # Successful authentication
  condition: selection_legacy_proto and selection_success
falsepositives:
  - Legacy MFP (multifunction printer) using SMTP AUTH for email scanning
  - Old on-prem mail servers relaying through Exchange Online
level: medium

Detection Pattern 3: Impossible Travel

title: Impossible Travel — Same User, Two Countries Within 1 Hour
logsource:
  product: azure
  service: signinlogs
detection:
  selection_success:
    ResultType: "0"
  # Implemented via correlation: same UserPrincipalName, different country, < 1 hour
  correlation:
    type: temporal_proximity
    field: UserPrincipalName
    group_by: CountryOrRegion
    timeframe: 1h
    threshold: 2   # 2 different countries = impossible travel
level: high

SIEM implementation: Most SIEMs implement this as a lookup join rather than native Sigma — correlate sign-in events for the same UPN, compute distance/time between location pairs, flag where implied travel speed > 800 km/hr.

Detection Pattern 4: MFA Fatigue (Prompt Bombing)

An attacker who has a valid password sends repeated MFA push notifications, hoping the user approves out of fatigue:

title: Excessive MFA Push Requests — Possible MFA Fatigue Attack
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    ResultType: "500121"   # Auth blocked by strong auth requirement (MFA pending)
  timeframe: 10m
  condition: selection | count() by UserPrincipalName > 5
falsepositives:
  - User locked out with misconfigured authenticator app
level: high

Follow-up: After detecting MFA fatigue, check if the same UPN eventually authenticates successfully — an approval after 10+ rejected prompts is a high-confidence MFA fatigue success.

Azure Activity Log: Control Plane Detection

Azure Activity Log covers resource management — the equivalent of AWS CloudTrail management events:

title: Azure Network Security Group Rule Modification
logsource:
  product: azure
  service: activitylog
detection:
  selection:
    operationName|startswith: "Microsoft.Network/networkSecurityGroups"
    operationName|endswith:
      - "/securityRules/write"
      - "/securityRules/delete"
  filter_known_automation:
    caller|contains: "terraform"
  condition: selection and not filter_known_automation
falsepositives:
  - Authorized network engineering changes
level: medium

High-priority Activity Log events:

Event	Why it matters
`Microsoft.Authorization/roleAssignments/write`	New role assignment — possible privilege escalation
`Microsoft.KeyVault/vaults/secrets/read`	Secrets accessed — possible credential theft
`Microsoft.Compute/virtualMachines/runCommand/action`	Remote command execution on VM
`Microsoft.Storage/storageAccounts/blobServices/containers/write`	Storage container created (possible exfil staging)
`Microsoft.Insights/diagnosticSettings/write`	Logging configuration changed (attacker may disable)

Microsoft Defender for Identity: Lateral Movement Detection

Defender for Identity (formerly Azure ATP) monitors on-prem Active Directory activity forwarded to the cloud:

Alert	ATT&CK technique	Signal
Suspected DCSync attack	T1003.006	Non-DC requesting replication rights
Suspected Pass-the-Hash	T1550.002	NTLM auth from unusual source
Suspicious LDAP queries	T1087.002	Bulk AD enumeration from non-admin
Kerberoasting	T1558.003	RC4 TGS requests for high-SPN services
Suspected golden ticket usage	T1558.001	Kerberos ticket with anomalous PAC

Azure AD Sign-in Logs— Microsoft Brute Force: Password Spraying (T1110.003)— MITRE

Retrieval Practice

You observe in Entra ID Sign-in Logs: user alice@corp.com successfully authenticates with MFA from London (UK) at 09:00. At 09:47, the same account authenticates successfully from Tokyo (JP). What is the attack, how would you confirm it, and what is the immediate response?

Reveal answer

Attack: Token theft (AiTM phishing) or session cookie theft — impossible travel (London to Tokyo in 47 minutes is ~800km/hr minimum, actual distance is ~9,500km requiring ~13 hours). MFA was completed once (legitimate login in London), then the token was stolen and replayed from Japan. Confirm: (1) Check sign-in from Tokyo's AuthenticationRequirement — if it shows 'previouslySatisfied' or no MFA prompt (token replay), confirms token theft rather than password compromise. (2) Check ClientAppUsed and UserAgent for the Tokyo session — token replay often shows different user agent than the originating session. (3) Review activity in the Tokyo session — what resources were accessed? Immediate response: (1) Revoke all active sessions for alice (Entra ID → Users → alice → Revoke sessions). (2) Reset alice's password and disable the compromised access token. (3) Investigate what alice's session accessed in the 47-minute window between login and detection.

Retrieval Practice

A SOC analyst reports: 'We got a Defender for Identity alert for Suspected Kerberoasting against svc-sharepoint. The security team says svc-sharepoint is just the SharePoint service account and this is probably a false positive.' How do you evaluate this?

Reveal answer

Evaluating a 'probable FP' Kerberoasting alert: (1) Pull the raw Kerberos Event 4769 from the domain controller — what are TargetUserName (svc-sharepoint), ServiceName (HTTP/sharepoint.corp.com), TicketEncryptionType (should be 0x17/RC4 for Kerberoasting), and ClientAddress (which host sent the request)? (2) Verify the ClientAddress: is this request coming from the SharePoint application server itself, or from a user workstation? Legitimate SharePoint Kerberos requests come from app servers, not workstations. (3) Check the timing: during business hours from the SharePoint server = likely legitimate. At 2am from a developer workstation = Kerberoasting. (4) Check the TicketEncryptionType: RC4 (0x17) is the Kerberoasting signal because it produces a crackable hash. AES (0x12/0x11) is modern, harder to crack — legitimate apps often use AES if configured. If the request is RC4 from a non-application host at an off-hours time, it's not an FP — escalate to IR regardless of the 'it's just the service account' explanation.

Entra ID Sign-in Log Structure

Detection Pattern 1: Password Spray

Detection Pattern 2: Legacy Authentication Protocol Use

Detection Pattern 3: Impossible Travel

Detection Pattern 4: MFA Fatigue (Prompt Bombing)

Azure Activity Log: Control Plane Detection

Microsoft Defender for Identity: Lateral Movement Detection