Playbook library

Trigger conditions

• • A user clicks 'Report Phishing'
• • Email gateway flags spoofing, look-alike domain, or failed DMARC
• • Display-name impersonation of an executive

Escalation criteria

• • Credentials were submitted to the phishing page
• • The email requests a payment, wire, or bank-detail change
• • An attachment executed on the endpoint

Investigation steps

1. 1. Pull the message headers. Check SPF, DKIM and DMARC results.
2. 2. Compare the sending domain to the real domain character by character (rn vs m, l vs I, 0 vs o).
3. 3. Check the reply-to address — attackers often differ it from the From address.
4. 4. Run WHOIS on any linked domain. Domains under 30 days old are a strong signal.
5. 5. Check whether any recipient clicked (URL rewrite / proxy logs) and whether a POST occurred.
6. 6. Search the mail store for other recipients of the same message ID.

Containment actions

• • Purge the message from all mailboxes
• • Block sender domain, sender address and landing domain
• • Force password reset and revoke sessions for any user who submitted credentials
• • Assign refresher training where appropriate — never blame the reporter

Trigger conditions

• • Many Event ID 4625 failures for one account (brute force)
• • A few failures across many accounts from one source (spray)
• • Failed logons against a disabled or non-existent account

Escalation criteria

• • Any successful logon from the attacking source
• • The targeted account is privileged or a service account
• • The target is a domain controller or other crown-jewel asset

Investigation steps

1. 1. Identify the source IP. Internal (10.20.0.0/16) or external?
2. 2. Check for a 4624 success from the same source after the failures.
3. 3. Check status codes: 0xC000006A = bad password, 0xC0000072 = disabled account, 0xC0000234 = locked out.
4. 4. Look for a 4723/4724 password change just before internal failures — cached credentials cause noise.
5. 5. Check whether the failures come at a fixed interval (automation) or irregularly (a human).
6. 6. Confirm whether MFA was satisfied on any successful sign-in.

Containment actions

• • Block the source IP at the perimeter
• • Reset the password and revoke sessions for any successfully accessed account
• • Enable or enforce MFA and lockout thresholds where missing

Trigger conditions

• • EDR signature or behavioral detection
• • Outbound connection to a known command-and-control address
• • Ransomware canary file modified

Escalation criteria

• • Credential dumping, ransomware behavior, or shadow-copy deletion
• • The detection was alert-only and the activity completed
• • The affected host is a server or crown-jewel asset

Investigation steps

1. 1. Read the action field first: blocked/quarantined changes urgency dramatically versus alert_only.
2. 2. Identify the process path. AppData, Temp and Users\Public are common malware locations.
3. 3. Check the parent process — Office apps spawning shells is abnormal.
4. 4. Look up the file hash for a verdict and first-seen date.
5. 5. Check for persistence: scheduled tasks (4698), run keys, services (7045).
6. 6. Search the fleet for the same hash or destination IP.

Containment actions

• • Isolate the host from the network, keeping the EDR channel up
• • Quarantine the sample and preserve a copy before reimaging
• • Block the hash and C2 infrastructure org-wide

Trigger conditions

• • Two sign-ins from distant locations within an implausible interval
• • Sign-in from a country with no business presence
• • Sign-in from an anonymizing proxy or hosting provider

Escalation criteria

• • Post-sign-in actions such as new inbox rules, MFA changes, or IAM key creation
• • Scripted user agents (python-requests, curl) on an interactive account
• • Any indication of mailbox forwarding or bulk mail access

Investigation steps

1. 1. Compare device IDs and user agents between the two sign-ins.
2. 2. Check the VPN logs — corporate VPN egress is the single most common cause of false positives.
3. 3. Check the IP owner: corporate egress, consumer ISP, hosting provider, or anonymizer?
4. 4. Check MFA state on each sign-in.
5. 5. Look at what happened after sign-in: inbox rules, mass mail access, key creation.
6. 6. Compare against the user's travel pattern and normal hours in the directory record.

Containment actions

• • Revoke all sessions and refresh tokens, then reset the password
• • Re-register MFA from a trusted device
• • Remove malicious inbox rules after capturing them as evidence

Trigger conditions

• • PowerShell launched with -enc, -w hidden, or -ExecutionPolicy Bypass
• • Office application spawning powershell.exe
• • Script block logging reveals a download cradle

Escalation criteria

• • The decoded script downloads or executes remote code
• • A reverse shell or C2 address appears in the script
• • The activity is unsigned, hidden and unexplained by change management

Investigation steps

1. 1. Decode any base64 in the command line and read the actual script.
2. 2. Check the parent process. ccmexec.exe or services.exe is usually management; WINWORD.EXE is not.
3. 3. Check whether the script file is signed, and by whom.
4. 4. Look for outbound connections made by powershell.exe and whether they were blocked.
5. 5. Check for an approved change ticket covering the host and time window.
6. 6. Look for persistence created by the script.

Containment actions

• • Isolate the host if a second stage may have executed
• • Remove created tasks/scripts, preserving copies
• • Consider enabling constrained language mode and script block logging everywhere

Trigger conditions

• • Large upload to personal cloud storage
• • DLP classification match leaving the organization
• • Bulk file-share reads followed by egress
• • Unusual DNS volume that may be tunneling

Escalation criteria

• • Confidential or regulated data reached a personal or unknown destination
• • The user is departing, terminated, or under investigation
• • Evidence of tunneling or covert channels

Investigation steps

1. 1. Determine whether the destination account is corporate or personal.
2. 2. Compare volume against the host's own baseline, not an absolute number.
3. 3. Identify the process: a backup agent and a browser upload mean very different things.
4. 4. Check the classification and how many files were involved.
5. 5. Check HR status — notice periods and terminations change the risk picture entirely.
6. 6. Confirm whether the transfer was allowed or blocked.

Containment actions

• • Preserve DLP and file-access evidence before anything is deleted
• • Block personal cloud storage for the user and revoke share access
• • Engage HR and Legal for insider-risk cases — do not confront the user yourself

Trigger conditions

• • Internal port scanning, especially on 445, 3389 or 22
• • Admin share (C$, ADMIN$) access between workstations
• • Remote service creation or WMI process execution

Escalation criteria

• • Executables written to remote hosts
• • Movement toward a domain controller or OT network
• • The account involved is already tied to an open compromise

Investigation steps

1. 1. Check whether the source is a known scanner in the asset database.
2. 2. Measure the spread: how many hosts, over how long, on which ports?
3. 3. Look for file writes to remote admin shares.
4. 4. Check logon types: 3 (network), 9 (runas), 10 (RDP) tell you how credentials were used.
5. 5. Correlate with any earlier compromise of the same account.
6. 6. Identify which of the touched hosts are crown jewels.

Containment actions

• • Isolate the source host and any host that received a file
• • Disable the account being used for movement
• • Consider blocking SMB between workstations at the network level

Trigger conditions

• • Event 4728/4732 adding a member to an admin group
• • Event 4769 bursts with RC4 encryption (Kerberoasting)
• • New cloud access key or policy attachment granting admin rights

Escalation criteria

• • Domain Admins, Enterprise Admins or cloud AdministratorAccess involved
• • No change record, or the actor's account is already suspected compromised
• • The new privileges were used immediately

Investigation steps

1. 1. Establish scope: local group (4732) or domain group (4728)?
2. 2. Check for an approved change ticket or helpdesk ticket covering the grant.
3. 3. Check whether the rights were later removed (4733/4729) — clean-up suggests legitimate work.
4. 4. Identify who performed the action and from which host and IP.
5. 5. Check what the newly privileged account did next.
6. 6. Look for hardening changes such as PasswordNeverExpires.

Containment actions

• • Remove the group membership or deactivate the key
• • Disable the affected accounts and preserve domain controller logs
• • Prepare a Tier 0 credential reset plan with Tier 2