Azure Incident Response Runbook: Sentinel, Entra ID, and Defender for Cloud

Cybersecurity

A practitioner playbook for Azure incidents covering Sentinel KQL hunts, sign-in and audit log scoping, Entra ID compromised user containment, conditional access bypass triage, and Defender for Cloud findings.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 3, 2024 · 9 min read

Azure incidents hide in three logs: SigninLogs, AuditLogs, and the OfficeActivity table if you have M365 wired in. Microsoft Sentinel is the place to join them. This runbook assumes Sentinel is deployed, Defender for Cloud is on, and Entra ID Premium P2 licensing covers your responder accounts.

1. The first KQL pull

When an Entra ID account is suspected compromised, the opening query is short. Pull every sign-in for the user over the last 14 days, then every audit operation they performed. Sentinel correlates faster than the Entra portal UI.

SigninLogs | where UserPrincipalName == 'alex@contoso.com' | where TimeGenerated > ago(14d) | project TimeGenerated, IPAddress, Location, AppDisplayName, ResultType, ConditionalAccessStatus, DeviceDetail, RiskLevelDuringSignIn

Look for ResultType 50053 (account locked), 50158 (external challenge failed), and 0 from unexpected ASNs. Cross reference RiskLevelDuringSignIn with Identity Protection alerts. A 'sign-in risk: high' that completed successfully is your incident start time.

2. Audit log scoping

Once you have the sign-in timeline, query AuditLogs for the same principal. The operations that matter are 'Add member to role', 'Update application', 'Add service principal credentials', 'Update conditional access policy', 'Consent to application', and 'Update user'.

• Add service principal credentials means the attacker is establishing persistence through an app registration.
• Update conditional access policy on a CA admin account is a kill-chain step and rare in benign workflows.
• Consent to application from a non-admin user is the OAuth phishing signal.

3. Containment in Entra ID

Sentinel can trigger playbooks. For a manual response, the sequence is: block sign-in, revoke refresh tokens, then disable any MFA methods the attacker may have added. Order matters. If you revoke tokens first, an active session can sometimes complete one more action before the block applies.

Connect-MgGraph -Scopes 'User.ReadWrite.All','AuditLog.Read.All' && Update-MgUser -UserId alex@contoso.com -AccountEnabled:$false && Revoke-MgUserSignInSession -UserId alex@contoso.com

Then list the user's authentication methods and remove anything you did not provision. Attackers love adding a phone method or an authenticator app on their own device.

4. Conditional access bypass investigation

If MFA was supposedly enforced but the attacker still got in, three things to check. First, was the sign-in marked as 'compliant device' from a device that is not actually compliant. Second, did the user have a legacy authentication grant that bypassed the CA policy. Third, did the attacker complete a device code phishing flow.

The Sentinel hunt for device code phishing is straightforward and surprisingly underused.

SigninLogs | where AuthenticationProtocol == 'deviceCode' | where TimeGenerated > ago(30d) | summarize SignIns=count(), UniqueIPs=dcount(IPAddress) by UserPrincipalName | where SignIns > 0 | order by UniqueIPs desc

5. Defender for Cloud and resource compromise

When the incident moves from identity to a subscription resource, Defender for Cloud's security alerts table is the pivot. Filter to alerts where IntentDescription contains 'Execution', 'Persistence', or 'CredentialAccess'. For VM compromise, take a managed disk snapshot before the VM is stopped: a stopped VM with a deleted disk is a forensics dead end.

• az snapshot create --resource-group rg-prod --name vm-snap-IR2024 --source <managedDiskId>
• Copy the snapshot to a forensics storage account in a separate subscription with its own RBAC.
• Apply a resource lock on the snapshot to prevent accidental deletion during the investigation.

6. Recovery and policy hardening

Recovery is more than re-enabling the user. Rotate any client secrets on app registrations the user could edit. Audit conditional access policy changes in the incident window. Re-baseline named locations if the attacker added one. Finally, run the IdentityInfo table against your privileged role assignments and confirm that nothing new sits in 'Global Administrator', 'Application Administrator', or 'Privileged Authentication Administrator'.

Azure gives you the telemetry. Sentinel turns it into a timeline. The runbook turns the timeline into a contained tenant. Practice the sequence on a tabletop before you need it for real.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.