The 100 SOC Playbook Pack: Mastering Identity-Driven Incident Response For Cloud-Native Threats + Video

Introduction

Modern Security Operations Centers (SOCs) are drowning in alerts but starving for actionable response logic. The shift from malware-centric to identity-focused attacks—such as MFA fatigue, adversary-in-the-middle (AiTM) phishing, and OAuth consent abuse—demands playbooks that prioritize session theft, SaaS permissions, and cloud control weaknesses over traditional file-based indicators.

Learning Objectives

Implement structured playbooks for identity-based threats including help-desk vishing, MFA reset abuse, and device code phishing.
Apply containment and recovery steps using native cloud tools, SIEM queries, and identity provider logs.
Differentiate between high-confidence alert indicators and noise using ATT&CK mapping and analyst investigation priorities.

You Should Know

1. Identity-Focused Playbook Structure and Investigation Workflow

The post highlights that each playbook in “The 100 SOC Playbook Pack” is organized around: use case, threat category, severity, primary logs, ATT&CK stage, analyst priorities, alert ideas, containment, and close criteria. This structure is critical because today’s incidents often begin without malware—through session hijacking or trusted device abuse.

Step‑by‑step guide to build an identity investigation playbook:

Define the use case – e.g., “Suspicious MFA reset followed by anomalous login”.
Identify primary logs – Azure AD sign-in logs, Okta system logs, AWS CloudTrail, or Duo authentication logs.
Map to ATT&CK – Tactics like Initial Access (T1078.004 – Cloud Accounts), Persistence (T1098 – Account Manipulation), or Credential Access (T1621 – Multi-Factor Authentication Interception).
Set severity criteria – Critical: successful MFA reset + login from new country/device within 5 minutes. High: failed reset attempts + help-desk ticket from unverified caller.
Create high-confidence alert – Query for MFA method removal (e.g., `”Remove MFA”` event) followed immediately by `”Success login”` with different user agent.

Linux/Windows commands for log extraction:

Linux (parsing Azure AD logs via CLI with jq):
`cat azure_signins.json | jq ‘.[] | select(.properties.status.errorCode == 500121) | {user: .properties.userPrincipalName, app: .properties.appDisplayName, ip: .properties.ipAddress}’`
– Windows (PowerShell – pull recent MFA changes from Graph API):
```
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime gt 2025-03-01 and activityDisplayName eq 'Reset MFA'" | Format-Table -AutoSize
```

Tutorial: Use Sysmon Event ID 4624 (Windows) or auditd (Linux) to correlate successful logins with MFA state changes. For cloud, schedule a Lambda/Azure Function to pull sign-in logs every 5 minutes and compare MFA method hashes.

Simulating an Adversary-in-the-Middle (AiTM) Phishing Attack for Playbook Testing

AiTM phishing uses a reverse proxy to steal session cookies, bypassing MFA. The post explicitly calls out “AiTM phishing with session token theft” as a top scenario. Testing your SOC against this requires controlled simulation.

Step‑by‑step guide to simulate and detect AiTM:

Set up a proxy tool like Evilginx2 or Modlishka on a isolated Linux VM.
Configure a phishing domain (e.g., office-auth[.]com) and obtain a TLS certificate via Let’s Encrypt.
Clone the target login page – e.g., Microsoft 365 or Google Workspace.
Launch the attack – Send a test link to a controlled user account. Capture the session token after they log in.
Replay the token – Use `curl` or a browser extension to inject the cookie and access the victim’s mailbox/OneDrive.

Detection commands and queries:

Splunk query for anomalous token use:
`index=o365 (operation=”UserLoggedIn”) | where ‘UserAgent’ != “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36” | stats count by User, ClientIP`
– Linux (check for proxy indicators in HTTP access logs):

`grep -E “X-Forwarded-For|X-Original-URI” /var/log/nginx/access.log`

Windows (PowerShell – detect unusual session replay from different IP):

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} | Where-Object {$<em>.Properties[bash].Value -like "session" -and $</em>.Properties[bash].Value -ne $env:COMPUTERNAME}

Mitigation: Enforce token binding (Primary Refresh Cookie with session binding to device) and configure Conditional Access policies to block logins from non-corporate IPs unless compliant.

OAuth Consent Abuse and Rogue App Enrollment: Containment Steps

The post mentions “OAuth consent phishing” and “guest account abuse”. Attackers trick users into granting permissions to malicious multi-tenant apps. Once consented, the app can read mail, modify files, or even reset passwords.

Step‑by‑step containment for OAuth abuse:

Identify the malicious app – Check Azure AD Enterprise Applications or Google Workspace OAuth tokens. Look for high-risk permissions (e.g., Mail.ReadWrite, Files.ReadWrite.All, User.EnableDisableAccount).

2. Revoke consent –

Azure AD (PowerShell): `Revoke-AzureADUserAllRefreshToken -ObjectId ` and remove the service principal: `Remove-AzureADServicePrincipal -ObjectId `
Google Cloud (gcloud): `gcloud auth revoke –user=
` then `gcloud oauth tokens revoke
`
3. Disable the app across tenant – Use Graph API: `PATCH https://graph.microsoft.com/v1.0/servicePrincipals/{id} -d ‘{“accountEnabled”: false}’`
4. Audit all OAuth grants – Run this Linux script to list all consented apps with risky scopes:
```
curl -X GET -H "Authorization: Bearer $ACCESS_TOKEN" "https://graph.microsoft.com/v1.0/users?`$select=id,userPrincipalName" | jq '.value[] | .id' | xargs -I{} curl -X GET -H "Authorization: Bearer $ACCESS_TOKEN" "https://graph.microsoft.com/v1.0/users/{}/oauth2PermissionGrants"
```

Prevention: Configure app consent policies to require admin approval for high-risk permissions. Use Microsoft Defender for Cloud Apps to detect anomalous OAuth grants.

MFA Fatigue and SIM Swap: Hardening Identity Workflows

MFA fatigue (spamming push notifications until user approves) and SIM swap (porting victim’s phone number) are explicitly listed. These bypass traditional MFA by exploiting human or telco weaknesses.

Step‑by‑step hardening:

Replace push notifications with number matching – In Azure AD, enable “Number matching” for MFA. In Duo, enable “Duo Push with number matching”.
Configure location‑based MFA – Only allow MFA approvals from geographies matching the user’s recent travel patterns.
Implement SIM swap detection – Monitor for sudden carrier port-out requests via email alerts from mobile carriers. Use Twilio’s Lookup API to check last SIM change date:
```
curl -X GET "https://lookups.twilio.com/v2/PhoneNumbers/+1234567890/SIMSwap" -u $TWILIO_SID:$TWILIO_TOKEN
```
Enforce FIDO2 security keys for privileged roles – Windows Hello for Business or YubiKey bypasses push fatigue entirely.

Windows command to check MFA settings for a user:

`Get-MgUserAuthenticationMethod -UserId “[email protected]” | Format-Table -Property Id, AuthenticationMethod`

5. Business Email Compromise (BEC) and Mailbox Persistence

BEC remains a top threat, often via mailbox rules that forward emails or hide phishing replies. The post emphasizes “mailbox persistence” as a key compromise vector.

Step‑by‑step BEC investigation:

Audit all inbox rules – PowerShell for Exchange Online:

Get-InboxRule -Mailbox [email protected] | Select-Object Name, Description, ForwardTo, DeleteMessage, MoveToFolder

Check for hidden forwarding – Look for SMTP forwarding addresses set via Set-Mailbox -ForwardingSmtpAddress. Also check `Set-MailboxAutoReplyConfiguration` for external replies.
Examine mailbox permissions – `Get-MailboxPermission [email protected] | Where-Object {$_.AccessRights -like “FullAccess”}`
4. Search for anomalous message moves – Use eDiscovery to find messages moved to “RSS Feeds” or “Conversation History” folders where attackers hide responses.

Linux command (using `curl` to Graph API for mailbox rules):

curl -X GET -H "Authorization: Bearer $TOKEN" "https://graph.microsoft.com/v1.0/users/[email protected]/mailFolders/inbox/messageRules"

Recovery: Reset password, revoke all sessions, remove malicious rules, and enable audit logging for all mailbox operations.

6. Cloud Privilege Abuse and Guest Account Takeover

Attackers often abuse guest accounts or overprivileged cloud roles. The post calls out “guest account abuse” and “cloud privilege abuse”. Example: A guest user with contributor role on an Azure subscription can spin up crypto miners.

Step‑by‑step hardening cloud RBAC:

List all guest users – Azure CLI: `az ad user list –filter “userType eq ‘Guest'” –query “[].userPrincipalName”`

2. Review role assignments for guests –

az role assignment list --include-inherited --assignee <guest-upn> | jq '.[] | {role: .roleDefinitionName, scope: .scope}'

3. Enforce Just‑In‑Time (JIT) access – Use PIM (Privileged Identity Management) to require activation for any role above Reader.
4. Monitor for privilege escalation – Alert on `RoleAssignmentCreated` events where principal is a guest or external user. Example AWS CloudTrail event: `”eventName”: “AttachRolePolicy”` followed by "userIdentity": {"type": "AWSService"}.

Windows (PowerShell for Azure):

`Get-AzRoleAssignment -ExpandPrincipalType | Where-Object {$_.PrincipalType -eq “Guest”}`

Prevention: Block guest invites by default via Azure AD entitlement management. Use AWS Organizations SCPs to deny guest access to sensitive services.

7. Legacy Authentication Misuse and Device Code Phishing

Legacy protocols (POP3, IMAP, SMTP) cannot enforce MFA, and device code phishing tricks users into entering a code on a malicious device. Both are highlighted in the post.

Step‑by‑step elimination:

Disable legacy authentication – Azure AD Conditional Access policy: “Other clients” block. For Exchange Online, disable Basic Auth via authentication policies.
Detect device code phishing – Monitor for `DeviceCodeFlow` events with unusual user agents. Azure AD sign-in log property: "isDeviceCodeAuthentication": true. Alert if a user completes device code login from two different IPs within 1 minute.

Simulate device code abuse – Use `Microsoft Authentication Library (MSAL)` Python script:

from msal import PublicClientApplication
app = PublicClientApplication("client_id")
flow = app.initiate_device_flow(scopes=["User.Read"])
print(flow["message"])  Trick user to enter code on attacker device

Linux command to search for legacy auth in /var/log/auth.log:
`grep “LOGIN via PLAIN” /var/log/mail.log | awk ‘{print $1, $2, $9}’`

Mitigation: Implement Continuous Access Evaluation (CAE) to instantly revoke tokens upon policy change.

What Undercode Say

Playbooks are not just documents; they are executable logic. The best SOCs integrate playbook steps directly into SOAR platforms, triggering automated containment (e.g., isolating a user via Azure AD block) the moment high-confidence alerts fire.
Identity is the new perimeter, but session tokens are the new crown jewels. The shift from malware to session hijacking means your detection stack must capture token replay anomalies, not just file hashes. Invest in UEBA and HTTP request fingerprinting.

Prediction

By 2027, more than 70% of SOC incidents will originate from identity or SaaS misconfigurations rather than malware. Traditional playbooks that focus on endpoint detection and response (EDR) will become obsolete for cloud-native environments. Expect a rise in “playbook-as-code” frameworks where incident response steps are version-controlled, tested via chaos engineering (e.g., simulating MFA fatigue), and automatically updated from threat intelligence feeds. SOC analysts will transition from log jockeys to identity forensic investigators, and certifications like SC-200 (Microsoft Security Operations Analyst) will incorporate mandatory playbook design labs. Organizations that fail to adopt structured, identity-first playbooks will suffer extended dwell times and recurring compromises through the same vector.

▶️ Related Video (84% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Yildiz Yasemin – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post