CIPHER Incident Response Playbooks — Operational Reference

Classification: INTERNAL — For authorized incident responders only Version: 1.0 | Date: 2026-03-14 Framework Alignment: NIST SP 800-61r2, CISA Federal IR Playbook, MITRE ATT&CK v15, ISO 27035 Sources: CISA IR Playbooks, CERT Societe Generale IRM, Counteractive IR Template, NCSC UK Incident Management, SANS IR Policy, OWASP Attack Surface Analysis

---

Document Purpose

These are operational playbooks — not policy documents. Each playbook is designed to be followed under pressure by an incident responder who may be handling this incident type for the first time. Every step is concrete and actionable.

Severity Classification Matrix (All Playbooks)

Level	Label	Criteria	Response SLA	Escalation
SEV-1	Critical	Active data destruction, widespread encryption, confirmed exfiltration of regulated data, complete service outage	15 min initial response	CISO, CEO, Legal, Board within 1 hour
SEV-2	High	Confirmed compromise with lateral movement, partial encryption, targeted data access, significant service degradation	30 min initial response	CISO, Legal within 2 hours
SEV-3	Medium	Confirmed compromise contained to single system/account, no confirmed data access, limited service impact	1 hour initial response	Security Manager within 4 hours
SEV-4	Low	Suspicious activity, potential compromise unconfirmed, no business impact observed	4 hour initial response	Security team lead next business day

Roles Quick Reference

Role	Responsibility
Incident Commander (IC)	Owns the incident. Coordinates all teams. Makes escalation decisions.
Investigation Lead	Directs forensic analysis, evidence collection, IOC development.
Remediation Lead	Directs containment, eradication, and recovery actions.
Communications Lead	Manages internal/external notifications, regulatory reporting, PR.
Scribe	Documents all actions, decisions, and timestamps in real-time.
SMEs	Provide domain expertise (network, endpoint, cloud, application, legal, HR).

---

PLAYBOOK 1: RANSOMWARE

MITRE ATT&CK: T1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery), T1489 (Service Stop), T1021 (Remote Services for lateral spread)

1.1 Detection Triggers

Source	Indicator	Confidence
EDR/AV	Mass file rename operations with new extensions (.crypt, .locked, .enc)	High
EDR	vssadmin.exe / wmic shadowcopy delete / bcdedit /set {default} recoveryenabled No	High
SIEM	High-volume SMB write operations across multiple shares in short timeframe	High
File Integrity Monitoring	Bulk file modification alerts on critical data stores	High
User Report	Ransom note displayed, files inaccessible, changed wallpaper	High
EDR	Execution of known ransomware families (BlackCat, LockBit, Conti, Royal, Akira)	High
Network	Beaconing to known C2 infrastructure, TOR connections from endpoints	Medium
EDR	PowerShell/WMI executing across multiple endpoints simultaneously	Medium
SIEM	Mass authentication events followed by service account lateral movement	Medium
Endpoint	Unexpected CPU/disk utilization spike across multiple systems	Low-Medium

1.2 Severity Classification

Condition	Severity
Encryption actively spreading, critical systems affected, backups at risk	SEV-1
Encryption confirmed on multiple systems, contained to segment, backups secure	SEV-2
Encryption confirmed on single endpoint, no lateral movement observed	SEV-3
Ransomware binary detected but not executed, no encryption observed	SEV-4

1.3 Immediate Containment (First 15 Minutes)

PRIORITY: Stop the spread. Every minute of delay means more encrypted systems.

MINUTE 0-5: ISOLATE

1. Network isolation of confirmed infected systems — Do NOT power off (preserves memory evidence)

   • Disable switch ports or move to quarantine VLAN
   • If remote: disable network adapter via EDR, or instruct user to unplug ethernet / disable WiFi
   • Command (Windows): netsh interface set interface "Ethernet" disable
   • Command (Linux): ip link set eth0 down

2. Block lateral movement vectors immediately

   • Disable SMBv1 network-wide if not already done: Set-SmbServerConfiguration -EnableSMB1Protocol $false
   • Block TCP 445, 135, 139, 3389 between segments at firewall (except to IR jump hosts)
   • Disable WMI and PSRemoting on non-critical systems if feasible

3. Protect backups

   • Disconnect backup systems from network IMMEDIATELY
   • Verify offline/air-gapped backups are intact — do NOT connect them to any network
   • Disable backup service accounts in AD

MINUTE 5-10: ASSESS SCOPE

4. Identify all affected systems

   • Query EDR for IOCs: file hashes, ransom note filenames, renamed extensions
   • Check AD for anomalous logins from service accounts or admin accounts
   • Query SIEM for SMB lateral movement patterns
   • Get-ADComputer -Filter * | ForEach-Object { Test-Path "\\$($_.Name)\C$\README_RANSOM.txt" } (adapt filename)

5. Identify the ransomware variant

   • Collect ransom note text
   • Upload sample to ID Ransomware (https://id-ransomware.malwarehunterteam.com/)
   • Check No More Ransom (https://www.nomoreransom.org/crypto-sheriff.php) for available decryptors
   • Record: extension used, ransom note format, payment address, contact email

MINUTE 10-15: ESCALATE AND MOBILIZE

6. Declare incident and assemble response team
   • Assign Incident Commander
   • Establish war room (physical or virtual — dedicated bridge line + chat channel)
   • Notify: CISO, Legal, IT Operations, Communications
   • If SEV-1: Notify CEO, Board liaison, cyber insurance carrier

1.4 Investigation Steps

Phase 1: Scope and Timeline (Hours 1-4)

1. Establish patient zero and initial access vector

   • Check email gateway logs for recent phishing/malspam delivery
   • Check VPN/RDP logs for brute force or credential stuffing
   • Check vulnerability scan results for unpatched external services
   • Review EDR timeline on first known infected host — trace back from encryption to initial execution
   • Common vectors: phishing email (T1566), exposed RDP (T1133), exploited VPN/firewall (T1190), compromised MSP (T1199)

2. Map lateral movement path

   • Analyze authentication logs for pass-the-hash, Kerberoasting, or credential dumping
   • Check for PsExec, WMIC, PowerShell remoting artifacts
   • Review Group Policy changes (ransomware may deploy via GPO)
   • Check for new scheduled tasks or services across endpoints

3. Determine data exfiltration (double extortion assessment)

   • Review firewall/proxy logs for large outbound transfers (especially to cloud storage, Mega, FTP)
   • Check DNS logs for DNS tunneling or unusual query volumes
   • Review DLP alerts from the past 7-30 days
   • Check for staging directories (e.g., compressed archives in temp folders)

Phase 2: Deep Forensics (Hours 4-24)

4. Memory forensics on key systems (before any remediation)

   • Capture with AVML (Linux) or WinPMEM/DumpIt (Windows)
   • Analyze with Volatility 3: process list, network connections, injected code, command history
   • Extract encryption keys if ransomware is still in memory (variant-dependent)

5. Disk forensics

   • Image affected systems with FTK Imager or dc3dd
   • Timeline analysis with Plaso/log2timeline
   • Parse MFT for file creation/modification timestamps to establish encryption timeline
   • Recover unencrypted file remnants from slack space, shadow copies (if not deleted)

6. Network forensics

   • PCAP analysis for C2 communication patterns
   • NetFlow analysis for lateral movement mapping
   • DNS query logs for C2 domain resolution
   • Identify all C2 infrastructure: IPs, domains, ports, protocols

1.5 Evidence Collection Checklist

Evidence	Tool	Priority	Notes
Memory dumps from infected systems	AVML, DumpIt, WinPMEM	P1 — Collect BEFORE reboot	May contain encryption keys
Ransom notes (all variants found)	Manual collection	P1	Photograph and copy digitally
Ransomware binary samples	EDR quarantine, manual	P1	Hash and submit to sandbox
Windows Event Logs (Security, System, PowerShell)	wevtutil, Chainsaw, Hayabusa	P1	Focus on 4624, 4625, 4648, 4688, 7045
EDR telemetry export	Vendor console	P1	Full timeline for affected hosts
Active Directory logs	DC event logs, Azure AD	P1	Account creation, GPO changes, Kerberos
Firewall/proxy logs	SIEM or device export	P2	Outbound connections, lateral movement
Email gateway logs	EOP, Proofpoint, Mimecast	P2	Delivery of initial payload
VPN/RDP access logs	VPN concentrator, RD Gateway	P2	Initial access evidence
Disk images of patient zero	FTK Imager, dc3dd	P2	Full forensic image
Backup system logs	Backup console	P2	Verify backup integrity/tampering
Network captures	Zeek, tcpdump, Wireshark	P3	If available from time of incident

Chain of Custody: Every evidence item must be logged with: collector name, date/time, source system, hash (SHA-256), storage location, access log.

1.6 Eradication

1. Rebuild all confirmed infected systems from known-good media — Do NOT attempt to "clean" ransomware
2. Reset ALL credentials — Assume credential compromise
   • All domain admin and service accounts (KRBTGT reset twice, 12+ hours apart)
   • All local administrator passwords (deploy LAPS if not already in use)
   • All user passwords for accounts that authenticated to infected systems
   • All application/database service accounts
3. Revoke and reissue certificates if CA infrastructure was in scope
4. Patch the initial access vector — Close the door the attacker used
5. Remove all persistence mechanisms identified during investigation
   • Scheduled tasks, services, registry run keys, WMI subscriptions, startup folders
6. Block all identified IOCs at network perimeter and endpoint
   • C2 domains/IPs in firewall and DNS sinkhole
   • File hashes in EDR block lists
7. Verify Group Policy integrity — Compare against known-good baseline
8. Scan all systems with updated signatures before reconnecting to network

1.7 Recovery

1. Restore from verified clean backups (test backup integrity BEFORE restoring to production)
   • Prioritize restoration order: AD/DNS/DHCP > Email > Critical business applications > File shares > User workstations
   • Scan restored data for ransomware indicators before making accessible
2. Rebuild from gold images where backups are unavailable or compromised
3. Reconnect systems in phases with enhanced monitoring
   • Monitor for re-infection indicators for minimum 72 hours
   • Keep network segmentation tightened during recovery
4. Check for available decryptors at No More Ransom project before considering ransom payment
5. Ransom payment decision (if absolutely necessary — last resort)
   • Engage legal counsel, law enforcement, and cyber insurance BEFORE payment
   • Understand: payment does not guarantee decryption, funds criminal enterprise, may violate OFAC sanctions
   • If paying: use experienced negotiator (insurance carrier typically provides), verify proof of decryption capability first

1.8 Communication Templates

Internal Notification (To All Staff)

Subject: IT Service Disruption — Action Required

[COMPANY] is experiencing a cybersecurity incident affecting [AFFECTED SYSTEMS].
As a precaution, the following actions are required immediately:

- Do NOT access [AFFECTED FILE SHARES/SYSTEMS]
- Do NOT attempt to open files that appear renamed or encrypted
- Disconnect any external storage devices from your computer
- Report any ransom messages or unusual system behavior to [SECURITY HOTLINE]

IT is actively working to resolve this situation. Updates will be provided every [FREQUENCY].

Do NOT discuss this incident on social media or with external parties.
Direct all media inquiries to [COMMUNICATIONS CONTACT].

Executive Briefing Template

INCIDENT BRIEFING — [CODENAME] — [DATE/TIME]
Status: [ACTIVE/CONTAINED/ERADICATED/RECOVERED]
Severity: [SEV-1/2/3/4]

SITUATION:
- Ransomware variant [NAME] detected at [TIME] on [DATE]
- [NUMBER] systems confirmed encrypted across [DEPARTMENTS/LOCATIONS]
- Initial access vector: [VECTOR]
- Data exfiltration: [CONFIRMED/SUSPECTED/NO EVIDENCE]

CURRENT ACTIONS:
- Network segmentation enforced to prevent spread
- Forensic investigation in progress
- Backup integrity verified — restoration planning underway

BUSINESS IMPACT:
- [SYSTEMS/SERVICES] unavailable, estimated [DURATION] to restore
- [NUMBER] employees unable to perform normal duties
- Estimated financial impact: [AMOUNT]

DECISIONS NEEDED:
- [LIST PENDING DECISIONS]

NEXT UPDATE: [DATE/TIME]

1.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline	Authority
GDPR (Art. 33)	Personal data encrypted and unavailable = breach if no backup; data exfiltrated = breach	72 hours from awareness	Supervisory Authority (e.g., ICO, CNIL)
GDPR (Art. 34)	High risk to individuals (exfiltrated PII)	Without undue delay	Affected data subjects
HIPAA (45 CFR 164.408)	ePHI encrypted by ransomware presumed breach unless low probability of compromise	60 days from discovery	HHS OCR, affected individuals, media (if >500)
CCPA/CPRA	Unencrypted personal information exfiltrated	Expedient, without unreasonable delay	California AG, affected consumers
SEC (8-K Item 1.05)	Material cybersecurity incident (public companies)	4 business days from materiality determination	SEC via 8-K filing
PCI DSS	Cardholder data compromised	Immediately	Card brands, acquiring bank
CISA	Federal agencies; critical infrastructure strongly encouraged	72 hours (CIRCIA)	CISA
FBI/IC3	Ransomware recommended reporting	As soon as possible	FBI field office, IC3
State breach laws	Varies by state — check all states where affected individuals reside	Varies (30-90 days typical)	State AG offices

1.10 Post-Incident Actions

1. After-action review (within 5 business days of recovery)

   • Full incident timeline with attacker and responder actions
   • Root cause analysis (5 Whys)
   • What worked, what did not, what was missing
   • Detection gap analysis: where could we have caught this earlier?

2. Detection improvements

   • Deploy Sigma rules for observed TTPs
   • Tune EDR policies based on observed evasion techniques
   • Add behavioral detections for encryption activity patterns
   • Monitor for IOCs related to this threat group for 90+ days

3. Architecture improvements

   • Implement/verify network segmentation
   • Deploy/verify immutable backups (3-2-1-1 rule: 3 copies, 2 media types, 1 offsite, 1 immutable)
   • Implement LAPS for local admin passwords
   • Restrict lateral movement: disable unnecessary SMB, WMI, PSRemoting between workstations
   • Review and restrict service account permissions (least privilege)

4. Training

   • Phishing simulation incorporating observed lure themes
   • Tabletop exercise for ransomware scenario within 90 days

---

PLAYBOOK 2: BUSINESS EMAIL COMPROMISE (BEC)

MITRE ATT&CK: T1566.001 (Spearphishing Attachment), T1566.002 (Spearphishing Link), T1534 (Internal Spearphishing), T1114 (Email Collection), T1078 (Valid Accounts), T1657 (Financial Theft)

2.1 Detection Triggers

Source	Indicator	Confidence
Email Gateway	Mail forwarding rules created to external addresses	High
Azure AD/M365	Inbox rules created via API: delete/move/forward operations	High
User Report	Executive or finance staff report unexpected wire transfer request	High
Email Gateway	Lookalike domain sending emails to finance/executive staff	High
Azure AD	Impossible travel: login from two geographically distant locations within short timeframe	High
Azure AD	Legacy auth protocol usage (IMAP/POP3) from unusual IP	Medium
SIEM	OAuth app consent grant to unknown application	Medium
Azure AD	MFA fatigue: multiple MFA push notifications followed by approval	Medium
DLP	Sensitive financial documents forwarded to personal/external email	Medium
Email Gateway	Email thread hijacking: reply to legitimate conversation from spoofed/compromised account	Medium
Finance Team	Vendor reports bank account change requests they did not initiate	Low-Medium

2.2 Severity Classification

Condition	Severity
Wire transfer executed to attacker-controlled account, funds in transit	SEV-1
Executive account confirmed compromised, internal spearphishing in progress	SEV-1
Account compromised with active forwarding rules exfiltrating data	SEV-2
Compromised account identified, no financial action taken yet	SEV-3
Phishing attempt targeting executive/finance, no compromise confirmed	SEV-4

2.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: STOP THE BLEED

1. If wire transfer is in progress or recently executed

   • Contact bank IMMEDIATELY -- request wire recall/hold
   • File IC3 complaint (https://www.ic3.gov/) -- FBI Recovery Asset Team can freeze funds if <72 hours
   • Document: amount, destination account, routing number, date/time, bank contact person
   • Contact receiving bank if identifiable

2. Lock compromised account(s)

   • Reset password immediately
   • Revoke all active sessions: Revoke-AzureADUserAllRefreshToken -ObjectId <user-id>
   • Disable account if financial fraud is active
   • Revoke OAuth application consents: review and remove suspicious app registrations

3. Preserve mailbox evidence BEFORE remediation

   • Place mailbox on litigation hold: Set-Mailbox -Identity <user> -LitigationHoldEnabled $true
   • Export mailbox to PST or use eDiscovery compliance search
   • Document all inbox rules, forwarding rules, and delegates

MINUTE 5-10: IDENTIFY SCOPE

4. Audit inbox/transport rules

   Get-InboxRule -Mailbox <user> | Where-Object {$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage}
   Get-TransportRule | Where-Object {$_.State -eq 'Enabled'}
   

   • Remove malicious rules immediately after documenting them
   • Check for rules that auto-delete security notifications

5. Check for additional compromised accounts

   • Review Azure AD sign-in logs for same source IP across all accounts
   • Check for OAuth apps consented across multiple users
   • Review mail flow rules at organization level

MINUTE 10-15: ESCALATE

6. Notify stakeholders
   • Legal counsel (potential fraud, regulatory implications)
   • Finance leadership (verify all recent wire transfers and payment changes)
   • If vendor impersonation: notify the real vendor immediately
   • Cyber insurance carrier if financial loss exceeds threshold

2.4 Investigation Steps

Phase 1: Account Compromise Analysis (Hours 1-4)

1. Determine compromise method

   • Review Azure AD sign-in logs: look for successful auth from unusual IP/location/device
   • Check for credential phishing: search email logs for phishing messages received by victim
   • Check for token theft: review OAuth app grants, look for AiTM proxy indicators
   • Check for password spray: correlate with other failed/successful logins from same IP

2. Establish attacker timeline

   • First successful login from attacker IP
   • Mailbox access patterns: what was read, searched, forwarded
   • Inbox rule creation timestamps
   • Internal emails sent by attacker (spearphishing or fraudulent requests)
   • External emails sent by attacker (vendor fraud, data exfiltration)

3. Assess data exposure

   • Review Unified Audit Log: Search-UnifiedAuditLog -StartDate <date> -EndDate <date> -UserIds <user> -Operations MailItemsAccessed,Send,Create
   • Identify all emails read by attacker (especially financial, contractual, PII)
   • Check OneDrive/SharePoint access from attacker IP
   • Review Teams/chat messages accessed

Phase 2: Financial Fraud Analysis (Hours 1-8, parallel)

4. Audit all financial transactions

   • Review all wire transfers, ACH payments, check requests in past 30-90 days
   • Verify all recent vendor bank account change requests with vendors via known phone numbers (NOT email)
   • Check for pending invoices or payment requests that may be fraudulent
   • Review payroll changes (direct deposit modifications)

5. Identify additional victims

   • Search sent items for internal phishing or fraudulent payment requests
   • Check if attacker replied to active email threads (conversation hijacking)
   • Search for emails to external parties impersonating the compromised user
   • Notify all recipients of attacker-sent emails

2.5 Evidence Collection Checklist

Evidence	Tool	Priority
Azure AD sign-in logs (90 days)	Azure Portal, Microsoft Graph API	P1
Unified Audit Log (mailbox actions)	Compliance Center, PowerShell	P1
Inbox rules (current and deleted)	PowerShell, eDiscovery	P1
Forwarded/sent emails from compromise period	eDiscovery Content Search	P1
OAuth application consents	Azure AD Enterprise Applications	P1
Wire transfer records and bank communications	Finance department	P1
Phishing email that compromised account	Email gateway logs, quarantine	P2
MFA registration/modification logs	Azure AD Audit Logs	P2
Conditional Access policy evaluation logs	Azure AD	P2
Email headers from fraudulent messages	Recipient mailboxes	P2

2.6 Eradication

1. Clean compromised account

   • Reset password to strong unique value
   • Remove all suspicious inbox rules, forwarding, and delegates
   • Re-register MFA (remove attacker's MFA method, re-enroll user)
   • Revoke all OAuth app consents and review
   • Remove attacker-added mail flow/transport rules

2. Block attacker infrastructure

   • Block attacker IP addresses at Conditional Access and firewall
   • Block lookalike domains at email gateway and DNS
   • Block phishing URLs at proxy/web filter

3. Harden email environment

   • Disable legacy authentication protocols (IMAP, POP3, SMTP AUTH)
   • Enable Conditional Access policies: require MFA, block legacy auth, restrict by location if appropriate
   • Enable mailbox audit logging if not already on
   • Deploy anti-phishing policies with impersonation protection

4. Verify no persistent access

   • Check for attacker-created app registrations in Azure AD
   • Check for attacker-added authentication methods
   • Review Conditional Access exclusions for tampering

2.7 Recovery

1. Financial recovery

   • Work with bank and FBI IC3 for fund recovery (time-critical -- highest success within 24-48 hours)
   • File insurance claim with cyber insurance carrier
   • Document all financial losses for potential legal action

2. Restore account access

   • Re-enable account with fresh credentials and verified MFA
   • Monitor for re-compromise for 30 days (enhanced logging)
   • Verify all inbox rules and forwarding settings weekly for 30 days

3. Notify affected parties

   • Internal recipients of fraudulent emails
   • External vendors/partners if impersonated
   • Individuals whose PII was exposed in accessed emails

2.8 Communication Templates

Finance Team Alert

Subject: URGENT -- Verify All Wire Transfers and Payment Changes

The security team has identified a business email compromise incident.
Effective immediately:

1. HALT all pending wire transfers until verified via phone callback
2. Verify ALL vendor bank account changes from the past [90] days by calling
   vendors at independently verified phone numbers (NOT from email)
3. Report any suspicious payment requests to [SECURITY CONTACT]
4. Do NOT process any payment requests received via email without verbal
   confirmation from the requestor via known phone number

This is not a drill. Contact [IC NAME] at [PHONE] with questions.

Vendor Notification

Subject: Security Notice -- Email Account Compromise

Dear [VENDOR],

We are writing to inform you that an email account at [COMPANY] was recently
compromised. During the compromise period ([START DATE] to [END DATE]),
unauthorized parties may have:

- Read email correspondence between our organizations
- Sent fraudulent emails appearing to come from [COMPROMISED USER]

ACTION REQUIRED:
- Disregard any emails from [COMPROMISED ADDRESS] during the above period
- If you received requests to change bank account details, payment
  instructions, or sensitive information -- these were fraudulent
- Contact [VERIFIED CONTACT] at [PHONE] to verify any pending transactions

We have secured the affected account and are working with law enforcement.

[COMPANY AUTHORIZED SIGNATORY]

2.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	PII in accessed emails (employee data, customer data, contracts with personal info)	72 hours / without undue delay
HIPAA	PHI in accessed emails	60 days
SEC 8-K	Material financial loss from wire fraud (public companies)	4 business days
State breach laws	PII accessed in emails (SSN, financial account numbers, etc.)	Varies by state
FBI/IC3	Wire fraud -- REPORT IMMEDIATELY for fund recovery	Immediately
FinCEN SAR	Financial institution discovers fraud >$5,000	30 days

2.10 Post-Incident Actions

1. Implement/verify email security controls

   • DMARC at p=reject for all organizational domains
   • SPF and DKIM properly configured
   • Anti-impersonation policies (user and domain)
   • Safe Links and Safe Attachments enabled

2. Process improvements

   • Mandatory dual-authorization for wire transfers above threshold
   • Verbal callback verification for ALL bank account changes (using independently verified numbers)
   • Finance team training on BEC indicators
   • Tag external emails with [EXTERNAL] banner

3. Detection improvements

   • Alert on inbox rule creation with forwarding/deletion actions
   • Alert on impossible travel in Azure AD
   • Alert on OAuth application consent grants
   • Alert on legacy authentication attempts
   • Monitor for lookalike domain registrations (dnstwist, PhishTank)

---

PLAYBOOK 3: WEB APPLICATION COMPROMISE

MITRE ATT&CK: T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter), T1505.003 (Web Shell), T1071 (Application Layer Protocol for C2)

3.1 Detection Triggers

Source	Indicator	Confidence
WAF	SQL injection, XSS, command injection, path traversal blocked/logged	High
EDR on web server	Web server process spawning cmd.exe/powershell/bash/sh	High
FIM	New/modified files in web root (especially .php, .aspx, .jsp, .py files)	High
SIEM	Web server making outbound connections to unusual IPs/domains	High
IDS/IPS	Known exploit signatures for CVEs affecting deployed software	High
WAF/Logs	Anomalous POST requests to unusual endpoints (webshell interaction)	Medium
Web logs	200 response codes to non-existent or unusual paths	Medium
SIEM	Database errors or unusual query patterns from application	Medium
Web logs	Automated scanning patterns (directory brute force, parameter fuzzing)	Medium
Monitoring	Application errors/crashes correlated with specific request patterns	Low-Medium
External	Bug bounty report, researcher disclosure, threat intel on targeted CVE	Varies

3.2 Severity Classification

Condition	Severity
Confirmed RCE, web shell deployed, evidence of lateral movement to internal network	SEV-1
Confirmed data exfiltration (database dump, customer PII)	SEV-1
Confirmed exploitation with server-side access, no lateral movement yet	SEV-2
SQL injection confirmed with data access, application-level only	SEV-2
Vulnerability actively being exploited, no confirmed data access	SEV-3
Scanning/probing detected, no successful exploitation	SEV-4

3.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: STOP EXPLOITATION

1. Block attacker IP(s) at WAF/firewall

   • Add to WAF block list immediately
   • If distributed: implement rate limiting or geographic blocking as appropriate
   • Do NOT take the application offline unless active data exfiltration is confirmed and cannot be stopped otherwise

2. If web shell confirmed -- isolate the server

   • Block outbound connections from web server (except to essential services)
   • Do NOT delete the web shell yet (evidence)
   • Restrict access to web shell path at WAF: deny all access to the specific URL

3. Preserve evidence

   • Enable enhanced web server logging if not already at maximum verbosity
   • Start packet capture on web server segment
   • Snapshot the server (VM snapshot, disk snapshot for cloud instances)

MINUTE 5-10: ASSESS SCOPE

4. Determine what was accessed

   • Review web server access logs for attacker IP(s): grep <ATTACKER_IP> access.log | less
   • Check for database access: review application/database logs for unusual queries
   • Check for file system access: find /var/www -newer /tmp/reference_timestamp -ls
   • Review outbound connections: ss -tunap | grep <web_server_pid>

5. Check for lateral movement

   • Review connections from web server to internal systems
   • Check if web server credentials (DB, API keys, service accounts) have been used elsewhere
   • Review authentication logs for logins from web server IP to other systems

MINUTE 10-15: ESCALATE

6. Determine if customer/user data was accessed
   • If database compromise: check query logs for SELECT on PII/sensitive tables
   • If file access: check for download of configuration files, backup files, user data exports
   • If data accessed: escalate to SEV-1, begin regulatory notification planning

3.4 Investigation Steps

Phase 1: Exploitation Analysis (Hours 1-4)

1. Identify the vulnerability exploited

   • Analyze WAF/web logs for attack patterns
   • Check CVE databases for known vulnerabilities in application stack (framework, CMS, plugins, libraries)
   • If custom application: review the specific endpoint/parameter exploited
   • Tools: Burp Suite (replay attack), nikto, wpscan (WordPress), sqlmap (verify SQLi scope)

2. Analyze web shell / implant (if present)

   • Hash the file: sha256sum /path/to/webshell
   • Submit to VirusTotal, Hybrid Analysis
   • Analyze functionality: file manager, command execution, database access, network pivot
   • Check for additional web shells: find /var/www -name "*.php" -newer /var/www/index.php
   • Common web shell indicators:

     grep -rl "eval\|base64_decode\|system\|passthru\|exec\|shell_exec" /var/www/html/ --include="*.php"
     grep -rl "cmd\|ProcessBuilder\|Runtime.getRuntime" /var/www/html/ --include="*.jsp"
     

3. Establish attacker timeline

   • Parse web logs to build complete request timeline from attacker IP(s)
   • Correlate with application logs, database logs, system auth logs
   • Identify: first exploitation, persistence installation, data access, exfiltration

Phase 2: Impact Assessment (Hours 4-24)

4. Database impact analysis

   • Review database audit logs / slow query logs for attacker activity
   • Check for: data extraction queries, new user creation, stored procedure modification
   • If no database logging: assess what data COULD have been accessed based on application permissions
   • Check for database backdoors: new users, modified procedures, triggers

5. Infrastructure pivot assessment

   • Review server configurations for stored credentials (config files, environment variables, .env files)
   • Assume all credentials stored on compromised server are compromised
   • Check cloud metadata service access (169.254.169.254 -- SSRF to cloud credentials)
   • Review internal API calls made from the server

6. Customer/user impact assessment

   • Determine: which users' data was accessible, which was confirmed accessed
   • Check for session hijacking or authentication bypass
   • Review for defacement or malicious content injection (watering hole)
   • Check for credit card skimmer injection (Magecart-style)

3.5 Evidence Collection Checklist

Evidence	Tool	Priority
Web server access logs (full)	Log collection, SIEM	P1
Web server error logs	Log collection	P1
Web shell files (do not delete)	Manual copy with hashing	P1
Application configuration files	Manual copy	P1
Database audit/query logs	Database console	P1
Server memory dump	AVML/DumpIt	P1
Server disk image or VM snapshot	FTK Imager, cloud snapshot	P2
WAF logs	WAF console/SIEM	P2
Network captures from server segment	tcpdump, Zeek	P2
Application source code (diff against known-good)	Git/source control	P2
Container images (if containerized)	docker save, registry pull	P2
Cloud provider logs (CloudTrail, Activity Log)	Cloud console	P2

3.6 Eradication

1. Remove web shells and malicious files

   • Diff web root against known-good deployment from source control
   • diff -rq /var/www/html/ /path/to/known-good/
   • Remove all files not in source control
   • Check for modified legitimate files (compare hashes)

2. Patch the vulnerability

   • Apply vendor patch or upgrade for known CVE
   • For custom code: deploy fix after code review, add input validation, parameterized queries
   • Update WAF rules to block the specific attack pattern
   • If zero-day: implement virtual patch at WAF while developing permanent fix

3. Rotate all credentials

   • Database credentials
   • API keys stored in application configuration
   • Service account credentials
   • SSL/TLS certificates if private keys were on compromised server
   • Session secrets / JWT signing keys (invalidates all user sessions)
   • Cloud IAM credentials if SSRF was possible

4. Rebuild server from known-good state

   • Do NOT attempt to clean a compromised web server -- rebuild from infrastructure-as-code or gold image
   • Redeploy application from source control
   • Apply all patches before exposing to internet

5. Database remediation

   • Remove attacker-created accounts
   • Restore modified stored procedures/triggers from backup
   • If data integrity compromised: restore from backup and replay legitimate transactions

3.7 Recovery

1. Deploy hardened application

   • Apply principle of least privilege: web server process runs as non-root, minimal file system permissions
   • Remove unnecessary files, default pages, debug endpoints
   • Disable directory listing
   • Implement Content-Security-Policy, X-Frame-Options, HSTS headers

2. Enhanced monitoring for 30 days

   • Increase WAF logging verbosity
   • Monitor for requests to previously identified web shell paths
   • Alert on web server process spawning child processes
   • Monitor outbound connections from web servers

3. User notification (if data was accessed)

   • Force password reset for affected user accounts
   • Enable/require MFA
   • Notify users per regulatory requirements

3.8 Communication Templates

Customer Notification (Data Breach)

Subject: Important Security Notice from [COMPANY]

Dear [CUSTOMER],

We are writing to inform you of a security incident that may have involved
your personal information.

WHAT HAPPENED:
On [DATE], we identified unauthorized access to our [APPLICATION] platform.
Our investigation determined that between [START DATE] and [END DATE],
an unauthorized party accessed [DESCRIPTION OF DATA TYPES].

WHAT INFORMATION WAS INVOLVED:
[Specific data types: name, email, phone, address, payment information, etc.]

WHAT WE ARE DOING:
- We have secured the affected system and eliminated the vulnerability
- We have engaged [FORENSIC FIRM] to conduct a thorough investigation
- We have notified [RELEVANT AUTHORITIES]
- We are offering [CREDIT MONITORING/IDENTITY PROTECTION] at no cost

WHAT YOU CAN DO:
- Change your [APPLICATION] password immediately
- Enable two-factor authentication on your account
- Monitor your accounts for suspicious activity
- [Enroll in complimentary credit monitoring at URL]

For questions, contact [DEDICATED SUPPORT LINE/EMAIL].

[COMPANY OFFICER]

3.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	User PII accessed or exfiltrated	72 hours / without undue delay
PCI DSS	Payment card data compromised (Magecart, DB exfiltration)	Immediately to card brands and acquiring bank
HIPAA	PHI accessed via application	60 days
State breach laws	PII accessed (SSN, financial, health, credentials)	Varies by state
CCPA/CPRA	California residents' personal information	Expedient

3.10 Post-Incident Actions

1. Vulnerability management improvements

   • Implement regular vulnerability scanning of web applications (DAST)
   • Integrate SAST into CI/CD pipeline
   • Establish patch SLA: critical CVEs patched within 24-48 hours
   • Subscribe to security advisories for all deployed software

2. Architecture improvements

   • Deploy WAF if not present; tune rules based on observed attacks
   • Implement network segmentation: web servers in DMZ, database in restricted segment
   • Remove stored credentials from application code -- use secrets manager
   • Implement runtime application self-protection (RASP) for critical applications
   • Restrict outbound network access from web servers (allowlist only)
   • Disable cloud metadata service or require IMDSv2 (AWS)

3. Code security improvements

   • Mandatory security code review for authentication, authorization, input handling
   • Developer security training (OWASP Top 10)
   • Bug bounty program or regular penetration testing

---

PLAYBOOK 4: INSIDER THREAT / DATA THEFT

MITRE ATT&CK: T1567 (Exfiltration Over Web Service), T1048 (Exfiltration Over Alternative Protocol), T1074 (Data Staged), T1119 (Automated Collection), T1530 (Data from Cloud Storage)

4.1 Detection Triggers

Source	Indicator	Confidence
DLP	Large volume data transfer to personal cloud storage (Google Drive, Dropbox, personal OneDrive)	High
DLP	Bulk download of sensitive documents outside normal pattern	High
UEBA	User accessing systems/data outside their role or normal behavior	High
HR Notification	Employee termination pending, resignation submitted, on PIP	High (context)
CASB	Corporate data uploaded to unsanctioned SaaS applications	High
Email Gateway	Large attachments sent to personal email addresses	Medium
EDR	USB mass storage device connected, large data copy operations	Medium
SIEM	Printing volume spike from individual user (especially after-hours)	Medium
UEBA	Access to source code repositories by non-engineering staff	Medium
Source Control	Bulk clone/download of repositories outside normal development patterns	Medium
Network	Large data transfers during non-business hours	Medium
Badge System	After-hours physical access correlated with data access events	Low-Medium
Manager Report	Suspicious behavior observed (photographing screens, unusual interest in sensitive data)	Varies

4.2 Severity Classification

Condition	Severity
Confirmed exfiltration of trade secrets, customer database, or regulated data to external party	SEV-1
Active exfiltration in progress, large volume, high-sensitivity data	SEV-1
Confirmed data staging/collection, exfiltration method identified but transfer not confirmed	SEV-2
Anomalous data access by departing employee, no confirmed exfiltration	SEV-3
Policy violations (USB usage, personal cloud uploads) with low-sensitivity data	SEV-4

4.3 Immediate Containment (First 15 Minutes)

CRITICAL: Insider threat investigations require HR and Legal involvement from the start. Do NOT confront the individual.

MINUTE 0-5: ASSESS AND PRESERVE

1. Do NOT alert the subject -- premature disclosure enables evidence destruction
2. Engage Legal and HR immediately -- all actions must comply with employment law, privacy regulations, and union agreements
3. Preserve evidence
   • Place litigation hold on subject's email, OneDrive, SharePoint
   • Enable enhanced audit logging on subject's accounts (if not already)
   • Snapshot subject's cloud workspaces
   • Begin continuous monitoring (within legal authorization)

MINUTE 5-10: CONTROLLED CONTAINMENT

4. Limit data access without alerting subject (coordinate with HR/Legal on timing)

   • Reduce access permissions to sensitive systems/data (use least suspicious method)
   • Block USB mass storage via endpoint policy (can be deployed broadly to avoid targeting appearance)
   • Block personal cloud storage at proxy (can deploy as "policy update" across department/org)
   • Restrict printing if print-based exfiltration suspected

5. If exfiltration is ACTIVELY IN PROGRESS and confirmed

   • Escalate to SEV-1
   • Decision point with Legal/HR: disable account immediately vs. monitor to gather evidence
   • If disabling: coordinate with HR for simultaneous employee notification
   • Block network egress for identified exfiltration channels

MINUTE 10-15: SCOPE AND PLAN

6. Establish investigation team
   • Incident Commander, Legal counsel, HR representative, Forensic investigator
   • Define investigation scope and legal boundaries
   • Determine if law enforcement engagement is warranted
   • Assess need for external forensic firm (recommended for potential litigation)

4.4 Investigation Steps

Phase 1: Activity Reconstruction (Hours 1-24)

1. Build comprehensive access timeline

   • All file access events: DLP logs, CASB logs, file server audit logs, SharePoint/OneDrive activity
   • All authentication events: VPN, applications, databases, cloud services
   • Email activity: sent messages (especially to personal addresses, external parties, competitors)
   • Web browsing history: cloud storage uploads, job sites, competitor sites, file sharing services
   • Physical access logs: badge swipes, parking, building access

2. Quantify data exposure

   • What specific files/data were accessed?
   • What was downloaded/copied?
   • What was sent externally (email, cloud, USB, print)?
   • Classification level of exposed data (public, internal, confidential, restricted)
   • Volume: number of files, total data size

3. Identify exfiltration channels used

   • Personal email (check sent items, forwarding rules)
   • Cloud storage (Google Drive, Dropbox, iCloud, personal OneDrive)
   • USB devices (check Windows Event 6416, USB device history)
   • Printing (print server logs)
   • Screenshots/photos (harder to detect -- check for screen capture tool usage)
   • Messaging apps (Teams, Slack, Signal -- check for file sharing)
   • Source code: git clone history, repository download logs

Phase 2: Motivation and Scope (Hours 24-72)

4. Assess motivation and context (coordinate with HR)

   • Employment status: resignation, termination pending, PIP, demotion
   • Known grievances or conflicts
   • Financial stressors
   • Contact with competitors (LinkedIn activity, job applications)
   • Has subject been recruited by foreign intelligence? (rare but high-impact)

5. Determine if accomplices exist

   • Check shared access to exfiltration channels
   • Review communications for coordination with internal/external parties
   • Check if other employees accessed same sensitive data unusually

6. Assess for sabotage

   • Check for data deletion, modification, or corruption
   • Review code commits for backdoors or logic bombs
   • Check for system configuration changes that could cause future outages
   • Review scheduled tasks or cron jobs for delayed destructive actions

4.5 Evidence Collection Checklist

Evidence	Tool	Priority	Legal Note
DLP event logs	DLP console	P1	Corporate data, generally accessible
Email archive (sent/received/deleted)	eDiscovery, Litigation Hold	P1	Requires Legal approval
File access audit logs	File server, SharePoint, SIEM	P1	Corporate systems
USB device connection history	EDR, Windows Event Logs	P1	Corporate endpoint
Cloud application activity (CASB)	CASB console	P1	Corporate sanctioned apps
Web proxy/browsing history	Proxy logs, EDR	P1	Corporate network
Badge/physical access logs	Physical security system	P2	Coordinate with facilities
Endpoint forensic image	FTK Imager, KAPE	P2	Corporate asset -- Legal approval recommended
Print server logs	Print management system	P2	Corporate infrastructure
Source control audit logs	GitHub/GitLab/Bitbucket admin	P2	Corporate repositories
Subject's personnel file	HR	P2	HR provides, restrict access
Network flow data	NetFlow collector	P3	Corporate network

Legal requirements: All evidence collection must be authorized by Legal. Maintain strict chain of custody. Do NOT access personal devices or accounts without legal authorization. In jurisdictions with works councils or strong employee privacy (EU, many states), additional restrictions may apply.

4.6 Eradication

1. Revoke all access (coordinate timing with HR for employee separation)

   • Disable all accounts: AD, email, VPN, cloud services, SaaS applications
   • Revoke SSO tokens and OAuth grants
   • Disable physical badge access
   • Remove from all distribution lists and shared resources
   • Revoke code signing certificates or API keys issued to subject

2. Secure corporate assets

   • Collect corporate laptop, phone, badges, keys, access cards
   • Image corporate devices before wiping (preserve for potential litigation)
   • Change shared passwords/credentials the subject had access to
   • Rotate API keys, service account credentials, shared secrets

3. Close exfiltration channels

   • If data was uploaded to personal cloud: engage Legal for takedown requests
   • If data was sent to competitor: engage Legal for injunctive relief
   • If data was sent to external party: notify affected data subjects if required

4.7 Recovery

1. Assess and remediate data exposure

   • Determine if exfiltrated data can be recovered or contained
   • If trade secrets: engage IP attorney, consider cease and desist, injunctive relief
   • If customer data: assess breach notification requirements
   • If source code: audit for backdoors, rotate all embedded secrets

2. Close security gaps

   • Review and improve DLP policies based on evasion methods observed
   • Implement/enhance UEBA for behavioral anomaly detection
   • Review offboarding procedures: ensure access revocation is complete and timely
   • Implement automated access revocation on HR status change

3. Organizational recovery

   • Brief affected teams (without unnecessary detail that could harm the individual or the investigation)
   • If public disclosure necessary: coordinate with Legal and Communications
   • Review and update acceptable use policies

4.8 Communication Templates

HR/Legal Briefing

CONFIDENTIAL -- INSIDER THREAT INVESTIGATION

Subject: [EMPLOYEE NAME], [TITLE], [DEPARTMENT]
Employment Status: [ACTIVE/NOTICE PERIOD/TERMINATED]
Investigation Initiated: [DATE]

SUMMARY:
[BRIEF DESCRIPTION] of data access/exfiltration activity detected on [DATE].
[NUMBER] files containing [DATA CLASSIFICATION] data were [accessed/copied/
exfiltrated] via [CHANNEL].

DATA AT RISK:
- [Type]: [Description], [Volume], [Classification]
- Regulatory data involved: [YES/NO] -- [GDPR/HIPAA/Trade Secret/etc.]

CURRENT STATUS:
- Subject awareness: [UNAWARE/AWARE/CONFRONTED]
- Access status: [ACTIVE/RESTRICTED/REVOKED]
- Law enforcement: [NOT INVOLVED/CONSULTED/ENGAGED]

RECOMMENDED ACTIONS:
1. [Action items requiring HR/Legal decision]

NEXT BRIEFING: [DATE/TIME]

4.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	Personal data of others exfiltrated	72 hours / without undue delay
HIPAA	PHI accessed/exfiltrated	60 days
DTSA (Defend Trade Secrets Act)	Trade secret theft -- enables civil action	File before statute of limitations
CFAA (Computer Fraud and Abuse Act)	Unauthorized access exceeding authorization	Law enforcement referral
State breach laws	PII of customers/employees exfiltrated	Varies by state
SEC	Material IP theft (public companies)	8-K if material

4.10 Post-Incident Actions

1. Process improvements

   • Automate access revocation triggered by HR status changes
   • Implement mandatory exit interviews with security review
   • Enhanced monitoring for employees in notice period (30-day enhanced logging)
   • Review and update NDAs and IP assignment agreements

2. Technical controls

   • Deploy/enhance DLP on all egress points (email, web, USB, cloud, print)
   • Implement UEBA with insider threat use cases
   • Block personal cloud storage or implement CASB inline inspection
   • Implement USB device control (allowlist only)
   • Code repository access reviews (quarterly, role-based)

3. Culture and awareness

   • Insider threat awareness training (annual)
   • Clear reporting channels for suspicious behavior
   • Establish insider threat working group (Security, HR, Legal)

---

PLAYBOOK 5: SUPPLY CHAIN COMPROMISE

MITRE ATT&CK: T1195 (Supply Chain Compromise), T1195.001 (Compromise Software Dependencies), T1195.002 (Compromise Software Supply Chain), T1199 (Trusted Relationship), T1078 (Valid Accounts)

5.1 Detection Triggers

Source	Indicator	Confidence
Threat Intelligence	Vendor/supplier breach announced publicly or via ISAC	High
EDR	Known-good software exhibiting malicious behavior post-update	High
Code Analysis	Malicious code in dependency (npm, PyPI, Maven, NuGet package)	High
Vendor Notification	Supplier notifies of breach affecting their customers	High
SIEM	Trusted vendor VPN/connection used for anomalous internal access	High
Network	C2 beaconing from software that recently updated	Medium-High
EDR	Unsigned or differently-signed update from vendor that normally signs	Medium
SIEM	Vendor service account performing actions outside normal scope	Medium
SCA Tool	Dependency confusion: internal package name resolved from public registry	Medium
Code Review	Unexpected changes in open-source dependency (typosquatting, maintainer takeover)	Medium
Certificate Transparency	Code signing certificate for vendor software revoked/reissued	Low-Medium

5.2 Severity Classification

Condition	Severity
Confirmed malicious update deployed to production, attacker has code execution	SEV-1
Confirmed vendor breach with evidence of access to your systems via trusted connection	SEV-1
Trojanized dependency in production, no confirmed exploitation yet	SEV-2
Vendor breach announced, your exposure assessment in progress	SEV-2
Suspicious vendor update behavior, investigation pending	SEV-3
Vendor reports breach with no apparent impact to your organization	SEV-4

5.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: ISOLATE THE SUPPLY CHAIN VECTOR

1. If compromised software is identified

   • Do NOT update/upgrade the compromised software (the update may be the attack vector)
   • Block the compromised software from communicating externally (firewall/EDR network containment)
   • Identify all systems running the affected software version: EDR inventory, CMDB, package managers
   • If the software is critical: assess business impact of disabling vs. risk of continued operation

2. If vendor/MSP access is the vector

   • Disable all vendor VPN connections immediately
   • Revoke vendor accounts and API keys
   • Block vendor IP ranges at firewall
   • Disable any SSO/federation trust with compromised vendor

3. If compromised dependency (library/package)

   • Pin to last known-good version in all package managers
   • Block the malicious version at artifact proxy (Nexus, Artifactory, npm registry mirror)
   • Do NOT rebuild or deploy until dependency is verified clean

MINUTE 5-10: SCOPE

4. Inventory affected systems

   • Query CMDB/EDR for all installations of affected software/version
   • Check CI/CD pipelines for builds using compromised dependency
   • Identify all environments: development, staging, production, DR
   • Check container registries for images built with compromised components

5. Assess attacker access scope

   • What permissions does the compromised software/vendor have?
   • What data can it access?
   • What network segments can it reach?
   • Review logs for post-compromise activity from the trusted software/connection

MINUTE 10-15: MOBILIZE

6. Escalate and coordinate
   • This is almost always SEV-1 or SEV-2 -- engage full IR team
   • Contact vendor security team directly (not general support)
   • Notify ISAC if applicable
   • Engage external IR firm if compromise scope is unclear
   • Legal notification: potential downstream notification obligations

5.4 Investigation Steps

Phase 1: Exposure Assessment (Hours 1-8)

1. Determine compromised component details

   • Exact version(s) affected
   • Date range of compromise (when was malicious code introduced?)
   • What does the malicious payload do? (backdoor, data exfiltration, credential theft, ransomware staging)
   • Analyze the payload in sandbox if possible

2. Map your exposure window

   • When did you first install/update to the compromised version?
   • How long has it been running?
   • What systems were exposed during this window?
   • Cross-reference with threat intel on known exploitation of this supply chain attack

3. Hunt for post-compromise activity

   • Search for IOCs published by vendor, security researchers, or threat intel feeds
   • Hunt for C2 beaconing from affected systems
   • Review authentication logs for suspicious activity from systems running compromised software
   • Check for persistence mechanisms planted via the compromised software
   • Review lateral movement from affected systems

Phase 2: Deep Investigation (Hours 8-72)

4. Forensic analysis of affected systems

   • Memory acquisition and analysis for systems running compromised software
   • Disk forensics for signs of post-exploitation (web shells, additional malware, staged data)
   • Network forensics: review all traffic from affected systems during exposure window

5. CI/CD pipeline assessment (if dependency compromise)

   • Review all builds during the compromise window
   • Check if build artifacts (deployments, container images) contain malicious code
   • Verify integrity of build systems themselves
   • Review artifact signing and verification processes

6. Vendor assessment

   • Request vendor's incident report and IOC list
   • Assess vendor's remediation status
   • Determine if vendor provided clean update/patch
   • Evaluate whether to continue vendor relationship (risk assessment)

5.5 Evidence Collection Checklist

Evidence	Tool	Priority
Compromised software binary/package (preserve exact version)	Package manager cache, disk	P1
Network traffic from affected systems during exposure window	PCAP, NetFlow, Zeek	P1
EDR telemetry from all affected endpoints	EDR console	P1
CI/CD pipeline build logs	Jenkins/GitLab CI/GitHub Actions	P1
Vendor access logs (VPN, API, SSO)	VPN concentrator, IdP logs	P1
Container registry pull/push logs	Registry audit logs	P2
Artifact repository logs (Nexus, Artifactory)	Repository admin console	P2
SBOM for affected applications	SBOM tools (Syft, SPDX)	P2
Vendor communications and incident reports	Email, vendor portal	P2
ISAC/threat intel advisories	ISAC portal, threat feeds	P2

5.6 Eradication

1. Remove compromised software

   • Uninstall or downgrade to last known-good version on ALL affected systems
   • If vendor has released verified clean update: validate signatures and hashes before deploying
   • Rebuild container images without compromised components
   • Re-run CI/CD pipelines with clean dependencies

2. Remove post-compromise artifacts

   • Eliminate any persistence mechanisms planted via the supply chain vector
   • Remove backdoor accounts, web shells, scheduled tasks, additional malware
   • Reset credentials for all accounts accessible by/from compromised software

3. Secure the supply chain path

   • Implement dependency pinning with hash verification
   • Deploy software composition analysis (SCA) in CI/CD pipeline
   • Implement artifact signature verification
   • If vendor compromise: re-establish trust only after vendor provides root cause analysis

4. Rotate credentials

   • All credentials accessible to compromised software (database, API keys, cloud credentials)
   • All credentials used by compromised vendor connection
   • All credentials stored on systems where compromised software was running

5.7 Recovery

1. Verified rebuild

   • Rebuild affected systems from known-good baselines
   • Verify integrity of all software components using SBOMs and hash verification
   • Deploy in phases with enhanced monitoring

2. Vendor relationship management

   • Require vendor root cause analysis and remediation evidence
   • Update vendor security requirements in contracts
   • Implement enhanced monitoring of vendor connections going forward
   • Consider vendor diversification for critical components

3. Software supply chain hardening

   • Implement SBOM generation for all applications
   • Deploy artifact proxy with vulnerability scanning
   • Implement build provenance verification (SLSA framework)
   • Enable reproducible builds where possible

5.8 Communication Templates

Vendor Inquiry

Subject: URGENT Security Inquiry -- [VENDOR PRODUCT] Compromise

Dear [VENDOR SECURITY TEAM],

We have become aware of a potential security compromise affecting
[PRODUCT/VERSION]. We are a customer using [PRODUCT] in our environment.

We require the following information IMMEDIATELY:
1. Confirmation of the compromise scope and affected versions
2. Indicators of compromise (IOCs) for detection in our environment
3. Timeline: when was malicious code introduced, when was it discovered
4. Recommended mitigation steps
5. Availability of a verified clean update/patch
6. Your incident report and root cause analysis timeline

Our environment details:
- Product version: [VERSION]
- Deployment: [ON-PREM/CLOUD/HYBRID]
- First installed/updated to affected version: [DATE]

Please respond within [TIMEFRAME]. Our security POC is [NAME] at [EMAIL/PHONE].

[COMPANY SECURITY TEAM]

Downstream Customer Notification (if you are the vendor)

Subject: Security Advisory -- [PRODUCT] [VERSION]

SEVERITY: [CRITICAL/HIGH]

AFFECTED VERSIONS: [LIST]
FIXED VERSION: [VERSION]

SUMMARY:
[COMPANY] has identified a security issue in [PRODUCT] that may affect
your environment. [BRIEF DESCRIPTION without revealing exploit details].

IMPACT:
[What could an attacker do? What data/systems are at risk?]

INDICATORS OF COMPROMISE:
[Hashes, IPs, domains, file paths, registry keys, behavioral indicators]

RECOMMENDED ACTIONS:
1. [Specific mitigation steps]
2. [Upgrade instructions]
3. [Detection guidance]

TIMELINE:
- [DATE]: Issue introduced
- [DATE]: Issue discovered
- [DATE]: Fix developed and verified
- [DATE]: This advisory issued

For questions: [SECURITY CONTACT]

5.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	Personal data exposed via supply chain compromise	72 hours / without undue delay
CISA CIRCIA	Critical infrastructure affected by supply chain compromise	72 hours
SEC 8-K	Material impact from supply chain compromise (public companies)	4 business days
Contractual (SLA)	Your customers affected by your vendor's compromise	Per contract terms
Industry ISAC	Sharing IOCs and threat intel with sector peers	As soon as practical
NIS2 (EU)	Essential/important entity supply chain incident	24 hours early warning, 72 hours full

5.10 Post-Incident Actions

1. Supply chain security program

   • Implement vendor security assessment program (questionnaires, SOC 2 review, penetration test results)
   • Require security SLAs in vendor contracts: breach notification timelines, IR cooperation, audit rights
   • Maintain vendor access inventory: who has access, to what, via what method
   • Regular review of vendor access: quarterly access recertification

2. Technical controls

   • Implement SCA in all CI/CD pipelines
   • Generate and maintain SBOMs for all applications
   • Deploy dependency pinning with integrity verification (lock files + hash verification)
   • Implement artifact proxy with caching and scanning
   • Segment vendor access: no direct internal network access, use jump hosts/bastion
   • Monitor vendor connections with enhanced logging and anomaly detection

3. Process improvements

   • Establish supply chain incident response procedures (this playbook)
   • Participate in industry ISACs for threat intelligence sharing
   • Conduct tabletop exercises with supply chain compromise scenarios
   • Maintain list of critical vendors with recovery/replacement plans

---

PLAYBOOK 6: DDoS ATTACK

MITRE ATT&CK: T1498 (Network Denial of Service), T1498.001 (Direct Network Flood), T1498.002 (Reflection Amplification), T1499 (Endpoint Denial of Service), T1499.001 (OS Exhaustion Flood), T1499.002 (Service Exhaustion Flood), T1499.003 (Application Exhaustion Flood), T1499.004 (Application or System Exploitation)

6.1 Detection Triggers

Source	Indicator	Confidence
Network Monitoring	Sudden traffic volume spike exceeding baseline by 3x+	High
CDN/WAF	DDoS mitigation automatically triggered	High
ISP	Upstream provider notifies of volumetric attack toward your IP space	High
APM	Application response time degradation >500% with traffic increase	High
Load Balancer	Connection exhaustion, backend health checks failing	High
Firewall	SYN flood detection, connection table exhaustion	High
User Reports	Multiple users reporting service unavailability simultaneously	Medium-High
DNS	DNS query amplification or DNS server resource exhaustion	Medium
SIEM	Geographically anomalous traffic patterns (traffic from regions with no customers)	Medium
WAF	Application-layer flood: rapid requests to resource-intensive endpoints	Medium
Monitoring	CPU/memory exhaustion on web/app servers without corresponding legitimate load increase	Medium

6.2 Severity Classification

Condition	Severity
Revenue-generating services completely offline, attack sustained >15 min	SEV-1
Multi-vector attack overwhelming all mitigation, customer impact confirmed	SEV-1
Services degraded but partially available, DDoS mitigation actively handling	SEV-2
Attack detected but fully mitigated by existing controls, no customer impact	SEV-3
Probing or low-volume attack with no service impact	SEV-4

6.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: ACTIVATE MITIGATION

1. Engage DDoS mitigation service

   • Activate cloud DDoS protection (Cloudflare, AWS Shield Advanced, Akamai Prolexic, Azure DDoS)
   • If not already on-path: switch DNS/BGP to route through scrubbing center
   • Contact DDoS mitigation provider support: provide target IPs, attack characteristics
   • Enable "I'm Under Attack" mode if available (Cloudflare)

2. Classify the attack type

   • Volumetric (L3/L4): UDP flood, ICMP flood, DNS amplification, NTP amplification, memcached amplification
   • Protocol (L3/L4): SYN flood, fragmented packets, Ping of Death, Smurf
   • Application (L7): HTTP GET/POST flood, Slowloris, RUDY, targeted API abuse
   • Multi-vector attacks combine multiple types -- address each layer

3. Initial network response

   • Implement upstream blackhole routing for source IPs if attack is from limited sources
   • Contact ISP/transit provider to implement upstream filtering
   • Enable rate limiting at edge: iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
   • For L7: deploy WAF rate limiting rules on targeted endpoints

MINUTE 5-10: PROTECT CRITICAL SERVICES

4. Prioritize services

   • If mitigation capacity is limited: direct protection to highest-value services first
   • Enable geographic filtering if attack originates from non-customer regions
   • Implement CAPTCHA challenges for suspected bot traffic (L7 attacks)
   • Scale up infrastructure: auto-scaling groups, additional load balancer capacity

5. Preserve non-targeted services

   • Ensure attack traffic does not collaterally impact other services on shared infrastructure
   • Isolate attacked services to dedicated infrastructure if possible
   • Ensure DNS, email, VPN, and internal services remain operational

MINUTE 10-15: COORDINATE AND COMMUNICATE

6. Coordinate response
   • Notify ISP/hosting provider with attack details and request assistance
   • If ransom demand received (RDoS): engage Legal, do NOT pay, report to law enforcement
   • Prepare status page update for customers
   • Notify CDN/DDoS mitigation provider of attack evolution

6.4 Investigation Steps

Phase 1: Attack Analysis (Hours 1-4)

1. Characterize the attack

   • Peak bandwidth (Gbps), packets per second (PPS), requests per second (RPS)
   • Attack vectors: protocols, ports, packet sizes, source distribution
   • Attack pattern: constant, pulsing, ramping, rotating vectors
   • Source analysis: number of unique source IPs, geographic distribution, likely botnet vs. amplification

2. Assess for smokescreen

   • CRITICAL: DDoS is sometimes used as a distraction while attackers perform other operations
   • While handling DDoS, simultaneously review: authentication logs, IDS/IPS alerts, EDR alerts
   • Check for data exfiltration, lateral movement, or exploitation attempts during the attack
   • Review VPN and remote access logs for unauthorized access

3. Determine motivation

   • Ransom demand received (RDoS/extortion)?
   • Competitor/business rivalry?
   • Hacktivism (check for claims on social media, Telegram channels)?
   • State-sponsored?
   • Distraction for other attack activity?
   • Customer/disgruntled individual?

Phase 2: Ongoing Mitigation (Duration of Attack)

4. Tune mitigation

   • Analyze blocked vs. passed traffic for false positives
   • Adjust rate limiting thresholds to balance availability vs. protection
   • Update WAF rules to target specific L7 attack patterns
   • Coordinate with DDoS mitigation provider for signature updates

5. Monitor for attack evolution

   • Attackers frequently change vectors when initial attack is mitigated
   • Watch for shifts from volumetric to application-layer attacks
   • Monitor for new target IPs or services
   • Track attack duration and intensity patterns

6.5 Evidence Collection Checklist

Evidence	Tool	Priority
Traffic captures during attack (sampled)	tcpdump, Zeek, NetFlow	P1
DDoS mitigation provider reports	Provider dashboard/API	P1
Firewall/IPS logs during attack	SIEM, device logs	P1
Web server/load balancer logs	Log aggregator	P1
Ransom demand (if received)	Screenshot, preserve original	P1
ISP/upstream provider communications	Email/ticket records	P2
APM data (response times, error rates)	APM platform	P2
BGP route changes during attack	BGP monitoring tools	P3
Botnet C2 infrastructure (if identified)	Threat intel platforms	P3

6.6 Eradication

DDoS eradication differs from other incident types -- the "eradication" is primarily ensuring robust mitigation is in place and attack motivation is addressed.

1. Confirm mitigation is effective

   • Verify service availability is restored
   • Confirm false positive rate is acceptable
   • Ensure mitigation does not degrade performance for legitimate users

2. Address ransom demands (if RDoS)

   • Do NOT pay -- payment encourages future attacks and does not guarantee cessation
   • Report to law enforcement (FBI IC3, local LE)
   • Document all communications from attacker

3. Verify no secondary compromise

   • Complete the smokescreen assessment from investigation phase
   • Confirm no unauthorized access occurred during the attack
   • Review all security events from the attack window

6.7 Recovery

1. Restore full service

   • Gradually remove emergency mitigation rules (keep DDoS protection active)
   • Monitor for attack resumption for 48-72 hours minimum
   • Restore any services that were deprioritized during attack
   • Clear connection/state tables on affected network devices

2. Communicate resolution

   • Update status page
   • Notify affected customers
   • Prepare internal summary for leadership

3. Infrastructure hardening

   • Review and optimize auto-scaling configurations
   • Pre-provision DDoS mitigation (always-on vs. on-demand)
   • Implement Anycast for critical services
   • Review CDN caching policies to reduce origin load during attacks

6.8 Communication Templates

Status Page Update

[DATE TIME UTC] -- SERVICE DISRUPTION

CURRENT STATUS: [INVESTIGATING / IDENTIFIED / MONITORING / RESOLVED]

We are currently experiencing elevated error rates and degraded performance
for [AFFECTED SERVICES]. Our team has identified the cause as a distributed
denial of service attack and has engaged mitigation measures.

Impact: [DESCRIPTION OF USER-FACING IMPACT]
Start time: [TIME UTC]
Estimated resolution: [TIME or "Updates every 30 minutes"]

We will provide updates as the situation develops.

[FOLLOW-UP UPDATE]
Mitigation measures are in place and service is [recovering/restored].
Some users may continue to experience intermittent issues as we optimize
our response. We will continue monitoring.

Law Enforcement Report (RDoS)

REPORT: Ransomware/DDoS Extortion Attack

Victim Organization: [COMPANY]
Attack Start: [DATE/TIME]
Attack Type: [VOLUMETRIC/PROTOCOL/APPLICATION/MULTI-VECTOR]
Peak Volume: [GBPS/PPS/RPS]
Services Affected: [LIST]

Ransom Demand Details:
- Received via: [EMAIL/WEBSITE MESSAGE/NOTE IN ATTACK PAYLOAD]
- Amount demanded: [AMOUNT AND CURRENCY]
- Payment address: [CRYPTO ADDRESS]
- Deadline: [DATE/TIME]
- Attacker identity claimed: [GROUP NAME IF ANY]

Full text of demand: [ATTACHED]
Attack traffic samples: [ATTACHED]

Business Impact: [DESCRIPTION]
Estimated financial loss: [AMOUNT]

6.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
NIS2 (EU)	Significant incident affecting essential/important entity service availability	24-hour early warning, 72-hour notification
GDPR	Only if DDoS resulted in personal data unavailability AND no backup recovery	72 hours (unusual for pure DDoS)
SEC 8-K	Material business impact from DDoS (public companies)	4 business days if material
CISA CIRCIA	Critical infrastructure service disruption	72 hours
Industry regulators	Financial services (OCC, FFIEC), healthcare, utilities -- sector-specific requirements	Varies
Cyber insurance	Claim for business interruption losses	Per policy terms

6.10 Post-Incident Actions

1. DDoS preparedness improvements

   • Implement or upgrade always-on DDoS protection
   • Conduct DDoS simulation/testing (coordinate with ISP and DDoS provider)
   • Document runbook with provider-specific activation procedures
   • Establish direct communication channel with ISP/hosting provider NOC

2. Architecture hardening

   • Implement Anycast DNS and CDN for all public services
   • Deploy rate limiting at application layer for all API endpoints
   • Implement connection limits and SYN cookies on all public-facing infrastructure
   • Ensure auto-scaling is configured with appropriate limits and budgets
   • Separate critical internal services from public-facing infrastructure

3. Process improvements

   • Establish DDoS response team with clear roles
   • Create decision tree for mitigation escalation
   • Regular DDoS tabletop exercises (quarterly for high-risk organizations)
   • Maintain relationships with upstream providers and DDoS mitigation vendors

---

PLAYBOOK 7: ACCOUNT TAKEOVER

MITRE ATT&CK: T1078 (Valid Accounts), T1110 (Brute Force), T1110.001 (Password Guessing), T1110.003 (Password Spraying), T1110.004 (Credential Stuffing), T1556 (Modify Authentication Process), T1539 (Steal Web Session Cookie)

7.1 Detection Triggers

Source	Indicator	Confidence
IdP/SIEM	Successful login following multiple failed attempts from same source	High
IdP	Login from new device/location followed by sensitive operations	High
User Report	User reports account activity they did not perform	High
IdP	MFA method changed followed by login from new location	High
IdP	Impossible travel: authentications from geographically distant locations in short time	High
SIEM	Credential stuffing pattern: many accounts, few attempts each, from distributed IPs	Medium-High
SIEM	Password spray: single password attempted across many accounts	Medium-High
IdP	Successful login using legacy/non-MFA authentication pathway	Medium
Application	Password reset requests from unusual IP/device	Medium
CASB	Unusual data access or download patterns from authenticated session	Medium
Dark Web Monitoring	Organization credentials found in breach dump or paste site	Medium
Application	Session hijacking: session used from different IP than authentication IP	Medium
IdP	OAuth token used from unexpected application or IP	Low-Medium

7.2 Severity Classification

Condition	Severity
Privileged account (admin, root, service) compromised with confirmed malicious actions	SEV-1
Multiple accounts compromised simultaneously (credential stuffing campaign)	SEV-1
Single account compromised with confirmed data access/exfiltration	SEV-2
Account compromised, attacker activity limited to email/profile changes	SEV-3
Failed takeover attempt, no compromise confirmed	SEV-4

7.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: SECURE THE ACCOUNT

1. Reset credentials immediately

   • Force password reset on compromised account(s)
   • Revoke all active sessions and tokens
   • For cloud/SaaS: Revoke-AzureADUserAllRefreshToken or equivalent
   • For applications: invalidate all session cookies, force re-authentication

2. Lock out attacker's access path

   • Block source IP(s) at WAF/firewall (cautious with shared IPs like VPN providers)
   • If credential stuffing: implement global rate limiting on authentication endpoints
   • If password spray: temporarily lock targeted accounts, implement progressive delays
   • Disable any MFA methods added by attacker before resetting user's MFA

3. Preserve evidence

   • Export authentication logs for affected account(s)
   • Capture session details: source IP, user agent, geographic location, timestamps
   • Document account changes made by attacker (profile, MFA, recovery email/phone)

MINUTE 5-10: SCOPE

4. Identify all affected accounts

   • Search for authentications from attacker's IP(s) across all accounts
   • If credential stuffing: check for successful logins from the same IP range
   • Query breached credential databases to identify exposed accounts
   • Check for password reuse: test affected credential against other organizational systems

5. Assess attacker actions

   • What did the attacker do after login? (email access, data download, profile changes, privilege escalation)
   • Were any internal phishing messages sent from the compromised account?
   • Were any financial actions taken?
   • Were persistence mechanisms established (new MFA device, recovery email, OAuth app consent)?

MINUTE 10-15: ESCALATE

6. Determine escalation level
   • If privileged account: treat as full infrastructure compromise until proven otherwise
   • If customer-facing accounts: assess customer data exposure, prepare notification
   • If credential stuffing at scale: engage additional resources for mass remediation
   • Notify Legal if regulated data was accessible from compromised account

7.4 Investigation Steps

Phase 1: Compromise Analysis (Hours 1-4)

1. Determine compromise vector

   • Credential stuffing: Check if user's credentials appear in known breach databases (Have I Been Pwned API)
   • Password spray: Check for widespread failed login attempts before success
   • Phishing: Check email logs for credential harvesting messages received by victim
   • Session hijacking: Check for malware on user's device (infostealer, session cookie theft)
   • MFA bypass: Check for SIM swap (contact carrier), AiTM proxy, MFA fatigue attack
   • Social engineering: Check if help desk reset password without proper verification

2. Map attacker activity post-compromise

   • Complete timeline of all actions taken by attacker-controlled session(s)
   • Data accessed, downloaded, or modified
   • Emails sent or read
   • Settings changed (forwarding rules, recovery options, MFA enrollment)
   • Privilege escalation attempts
   • Lateral movement to other accounts or systems

3. Assess credential exposure scope

   • Was the same password used on other systems? (check password hash if available)
   • Were credentials for other accounts accessible from compromised account? (password managers, email)
   • Were API keys, tokens, or certificates accessible?

Phase 2: Impact Assessment (Hours 4-24)

4. Data exposure assessment

   • Enumerate all data the compromised account could access
   • Determine what was actually accessed based on audit logs
   • Classify data sensitivity: PII, financial, health, trade secret, public
   • Determine regulatory implications

5. Check for persistence and lateral movement

   • Search for OAuth apps consented during compromise period
   • Check for API keys or service credentials created
   • Review for new accounts created by compromised account
   • Check for elevated privileges granted

7.5 Evidence Collection Checklist

Evidence	Tool	Priority
Authentication logs (success/failure)	IdP, SIEM, Azure AD	P1
Session activity logs	Application audit logs	P1
Account modification logs (password, MFA, profile changes)	IdP audit logs	P1
Source IPs, user agents, geo-location data	IdP, WAF	P1
Email activity from compromised account	eDiscovery, mail logs	P1
OAuth/API token grants	IdP, application logs	P2
Endpoint forensics (if infostealer suspected)	EDR, memory capture	P2
Dark web/breach database matches	Have I Been Pwned, threat intel	P2
Help desk ticket history (social engineering)	ITSM platform	P2
Phishing email that captured credentials	Email gateway	P2

7.6 Eradication

1. Secure all affected accounts

   • Force password change to unique, strong passwords
   • Re-enroll MFA with verified methods (remove all existing, add fresh)
   • Remove all OAuth app consents added during compromise window
   • Remove forwarding rules, delegates, recovery email/phone added by attacker
   • Revoke all API keys/tokens created during compromise window

2. Block attack infrastructure

   • Block identified attacker IPs (if not from botnets/residential proxies)
   • Block credential stuffing sources: implement IP reputation scoring
   • Update WAF rules for authentication endpoint protection

3. Address root cause

   • If credential stuffing: implement credential screening against breach databases
   • If password spray: enforce strong password policy, implement smart lockout
   • If phishing: deploy phishing-resistant MFA (FIDO2/WebAuthn)
   • If infostealer: remediate infected endpoint, scan for additional infections
   • If help desk social engineering: implement identity verification procedures

4. Scan for broader compromise

   • If privileged account: full AD health check (Bloodhound, PingCastle)
   • Check for Golden Ticket / Silver Ticket if domain admin was compromised
   • Review all changes made by compromised account in directory services

7.7 Recovery

1. Restore account access to legitimate user

   • Verify identity through out-of-band channel before restoring access
   • Walk user through MFA re-enrollment
   • Inform user of what attacker accessed (within appropriate disclosure limits)
   • Provide guidance on personal credential hygiene (password manager, no reuse)

2. Customer notification (if customer accounts compromised)

   • Force password reset for all affected accounts
   • Notify affected users with specific guidance
   • Offer credit monitoring if financial data was accessible

3. Monitoring enhancement

   • Enhanced monitoring on previously compromised accounts for 90 days
   • Alert on any login from previously seen attacker infrastructure
   • Monitor for re-compromise indicators

7.8 Communication Templates

User Notification (Individual Account)

Subject: Action Required -- Your Account Security

Dear [USER],

We detected unauthorized access to your [COMPANY/APPLICATION] account on
[DATE]. We have immediately secured your account by resetting your credentials
and revoking active sessions.

WHAT HAPPENED:
An unauthorized party accessed your account from [GENERAL LOCATION] using
credentials obtained [through a data breach at another service / via phishing].

WHAT WAS ACCESSED:
[Specific description of data/services the attacker accessed]

WHAT WE HAVE DONE:
- Your account password has been reset
- All active sessions have been terminated
- [MFA has been re-enrolled / will need to be re-enrolled at next login]

WHAT YOU NEED TO DO:
1. Set a new unique password at [RESET URL] (do not reuse passwords)
2. Enable multi-factor authentication if not already active
3. Review your account activity for any changes you did not make
4. If you used this password on other services, change those passwords immediately
5. Consider using a password manager

If you notice any suspicious activity, contact [SUPPORT].

Mass Credential Stuffing Notification

Subject: Security Notice -- Password Reset Required

Dear [COMPANY] Users,

As part of our ongoing security monitoring, we have detected a credential
stuffing attack targeting [COMPANY] accounts. Credential stuffing uses
usernames and passwords stolen from other services to attempt access to
your account.

Out of an abundance of caution, we are requiring a password reset for
[all users / affected users]. You will be prompted to create a new password
at your next login.

IMPORTANT:
- Your new password must be UNIQUE to [COMPANY] -- not used anywhere else
- Enable multi-factor authentication at [MFA SETUP URL]
- Consider using a password manager to generate and store unique passwords

This is a precautionary measure. If your account shows no unauthorized
activity, no further action is needed beyond the password reset.

[COMPANY SECURITY TEAM]

7.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	Personal data accessed via compromised account	72 hours / without undue delay
HIPAA	PHI accessible from compromised account	60 days
State breach laws	PII accessed (credentials themselves may constitute PII in some jurisdictions)	Varies by state
CCPA/CPRA	California residents' credentials or data accessed	Expedient
PCI DSS	Payment account data accessed	Immediately
Platform-specific (e.g., Apple, Google)	If operating as service provider with platform requirements	Per agreement

7.10 Post-Incident Actions

1. Authentication hardening

   • Deploy phishing-resistant MFA (FIDO2/WebAuthn) for all users, prioritizing privileged accounts
   • Implement credential screening: check new passwords against breach databases at creation
   • Deploy adaptive/risk-based authentication (challenge on anomalous login patterns)
   • Implement smart lockout with progressive delays
   • Block legacy authentication protocols

2. Detection improvements

   • Implement real-time credential stuffing detection (high velocity, distributed login failures)
   • Deploy impossible travel detection
   • Alert on authentication from anonymizing proxies (TOR, VPN services)
   • Monitor for new MFA device enrollment followed by login from new location
   • Implement session anomaly detection (IP change mid-session)

3. User education

   • Password manager deployment and training
   • MFA enrollment campaign
   • Phishing awareness with credential harvesting scenarios
   • "Have I Been Pwned" notification service for employees

---

PLAYBOOK 8: MALWARE OUTBREAK

MITRE ATT&CK: T1204 (User Execution), T1059 (Command and Scripting Interpreter), T1547 (Boot or Logon Autostart Execution), T1055 (Process Injection), T1036 (Masquerading), T1027 (Obfuscated Files or Information), T1105 (Ingress Tool Transfer)

8.1 Detection Triggers

Source	Indicator	Confidence
EDR/AV	Malware detection on multiple endpoints simultaneously	High
EDR	Known malware family identified (Emotet, QakBot, IcedID, Cobalt Strike, etc.)	High
EDR	Suspicious process behavior: LOLBins execution chain, process injection	High
SIEM	C2 beaconing detected from multiple internal hosts	High
Email Gateway	Malicious attachment campaign targeting multiple employees	High
Sandbox	Detonated attachment exhibits malicious behavior	High
Network IDS	Known malware signatures or behavioral detections in network traffic	High
EDR	PowerShell/WMI/MSHTA executing encoded/obfuscated commands	Medium-High
SIEM	Multiple hosts connecting to same newly registered domain	Medium
EDR	Scheduled task or service creation across multiple endpoints	Medium
SIEM	Unusual DNS query patterns (DGA-like domains, high volume NXDOMAIN)	Medium
UEBA	Multiple users executing unusual processes after opening email	Medium

8.2 Severity Classification

Condition	Severity
Worm-like propagation active, infections growing exponentially	SEV-1
Cobalt Strike / C2 framework with lateral movement confirmed	SEV-1
Banking trojan / infostealer confirmed on systems with access to financial/sensitive data	SEV-1
Malware on multiple endpoints, containment controls holding	SEV-2
Single endpoint infection, no lateral movement	SEV-3
Malware detected and blocked by AV, no execution confirmed	SEV-4

8.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: STOP THE SPREAD

1. Isolate confirmed infected endpoints

   • EDR network containment (preferred -- maintains forensic access)
   • Disable switch port / move to quarantine VLAN
   • Do NOT power off (preserve memory evidence)

2. Block C2 communication

   • Add identified C2 domains/IPs to DNS sinkhole and firewall block lists
   • If C2 unknown: consider blocking all non-essential outbound traffic from infected segment
   • Block known malware distribution URLs at proxy

3. Prevent further infection

   • Block malicious email attachment hashes at email gateway
   • Quarantine/recall malicious emails from all mailboxes
   • Update EDR custom IOC block lists with known file hashes, process names, mutex names
   • If worm: block propagation protocols (SMB, WMI, RPC) between workstation segments

MINUTE 5-10: SCOPE THE OUTBREAK

4. Identify all infected systems

   • EDR sweep for IOCs: file hashes, process names, registry keys, network connections
   • SIEM query for C2 beaconing pattern across all endpoints
   • DNS log query for malware domains across all resolvers
   • Active Directory query for anomalous logins if credential theft suspected

5. Identify the infection vector

   • Email: search gateway for matching attachment/URL delivery
   • Web: check proxy logs for drive-by download indicators
   • USB: check EDR for removable media events preceding infection
   • Lateral movement: check if initial infection came from already-compromised internal system

MINUTE 10-15: MOBILIZE

6. Classify the malware and assess risk
   • Submit samples to sandbox (Cuckoo, Any.Run, Hybrid Analysis, Joe Sandbox)
   • Check VirusTotal for community intelligence on the sample
   • Determine malware type: loader, infostealer, RAT, worm, ransomware precursor, cryptominer
   • If malware is a known ransomware precursor (BazarLoader, QakBot, IcedID, Emotet, Cobalt Strike): escalate to SEV-1 immediately -- ransomware deployment typically follows within 24-72 hours

8.4 Investigation Steps

Phase 1: Malware Analysis (Hours 1-8)

1. Static and dynamic analysis

   • Hash all samples (MD5, SHA1, SHA256)
   • Static analysis: strings, imports, resources, packing, signing
   • Dynamic analysis in sandbox: behavior, network connections, file system changes, registry changes
   • Extract IOCs: C2 addresses, dropped files, persistence mechanisms, mutexes

2. Determine malware capabilities

   • Data exfiltration (infostealer, keylogger)
   • Credential harvesting (Mimikatz, LSASS dump)
   • Lateral movement (worm functionality, remote execution)
   • Persistence mechanisms (scheduled tasks, services, registry, WMI)
   • Anti-analysis / evasion techniques
   • Payload delivery (dropper for additional malware stages)

3. Map infection chain

   • Initial access -> execution -> persistence -> C2 -> post-exploitation
   • Document each stage with associated IOCs
   • Identify all dropped/downloaded secondary payloads
   • Check for modular capabilities (additional plugins downloaded post-infection)

Phase 2: Scope and Impact (Hours 8-48)

4. Complete scope assessment

   • Full list of confirmed infected systems
   • List of potentially infected systems (exposed but not confirmed)
   • Data that was accessible from infected systems
   • Credentials harvested (assume any credential used on infected system is compromised)

5. Assess data theft

   • Review proxy/firewall logs for data exfiltration from infected hosts
   • Check for staging directories (compressed archives, encrypted files)
   • If infostealer: assume browser saved passwords, cookies, autofill data compromised
   • Check for screenshots, keylog files, clipboard data exfiltration

6. Threat attribution (if relevant)

   • Map TTPs to known threat groups using MITRE ATT&CK
   • Check threat intelligence for campaign information
   • Share IOCs with ISAC for correlation

8.5 Evidence Collection Checklist

Evidence	Tool	Priority
Malware samples (all stages)	EDR quarantine, manual collection	P1
Memory dump from infected systems	AVML, DumpIt, WinPMEM	P1
EDR telemetry (process tree, file, registry, network)	EDR console	P1
C2 network traffic captures	Zeek, tcpdump, NetFlow	P1
Windows Event Logs (Sysmon if available)	Chainsaw, Hayabusa	P1
Email delivering malware	Email gateway quarantine	P1
Sandbox analysis reports	Sandbox platform	P2
DNS query logs for C2 domains	DNS server logs	P2
Proxy logs for infected hosts	Proxy/SIEM	P2
Disk image of patient zero	FTK Imager	P2
Persistence artifacts (scheduled tasks, services, registry)	Autoruns, EDR	P2

8.6 Eradication

1. Remove malware from all infected systems

   • Use EDR remediation capabilities to quarantine/delete malicious files
   • Remove persistence mechanisms: scheduled tasks, services, registry run keys, WMI subscriptions, startup items
   • Remove dropped files and directories
   • Clear browser credential stores if infostealer was present
   • For severe infections: rebuild from gold image (preferred over cleaning)

2. Reset compromised credentials

   • All credentials cached/used on infected endpoints (browser, RDP, network shares)
   • If credential dumping confirmed: full domain password reset, KRBTGT reset (twice, 12h apart)
   • Service account credentials used on infected systems
   • Any credentials stored in browser password managers on infected systems

3. Block all IOCs

   • Deploy file hash blocks to all endpoints via EDR
   • Block C2 domains/IPs at DNS, firewall, proxy
   • Block email IOCs (sender addresses, subject lines, attachment hashes) at gateway
   • Deploy Sigma/SIEM detection rules for observed TTPs

4. Close initial access vector

   • If email: improve email filtering rules, block sender domain, report to email provider
   • If web: block malicious sites, review web filtering policies
   • If USB: implement device control policies
   • If vulnerability: patch affected systems

8.7 Recovery

1. Restore cleaned/rebuilt systems

   • Verify clean state: run full AV/EDR scan before reconnecting to network
   • Reconnect in phases with enhanced monitoring
   • Monitor for re-infection for 72+ hours

2. Validate environment cleanliness

   • Sweep entire environment for remaining IOCs
   • Check for dormant persistence mechanisms
   • Verify no secondary payloads are present
   • If Cobalt Strike/C2 framework was used: assume full domain compromise until verified clean

3. User communication

   • Notify affected users about credential reset requirements
   • Provide guidance on identifying similar threats
   • Update security awareness training with observed attack techniques

8.8 Communication Templates

IT/User Advisory

Subject: Security Alert -- Malicious Email Campaign

The security team has identified a malicious email campaign targeting
[COMPANY] employees. The emails appear as [DESCRIPTION -- e.g., "invoice
notifications from a known vendor"] and contain [malicious attachments /
links to malicious sites].

IF YOU RECEIVED THIS EMAIL:
- Do NOT open any attachments
- Do NOT click any links
- Report it using the [PHISH BUTTON / forward to security@company.com]
- Delete the email

IF YOU ALREADY OPENED THE ATTACHMENT OR CLICKED THE LINK:
- Disconnect your computer from the network immediately
  [UNPLUG ETHERNET / DISABLE WIFI]
- Call the security hotline at [NUMBER] immediately
- Do NOT attempt to fix the problem yourself
- Do NOT power off your computer

Our team is actively containing this threat. Thank you for your vigilance.

8.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	Infostealer exfiltrated PII; malware accessed personal data stores	72 hours / without undue delay
HIPAA	Malware on systems containing ePHI	60 days
PCI DSS	Malware on systems in cardholder data environment	Immediately
State breach laws	Credential theft affecting employee/customer PII	Varies by state
CISA CIRCIA	Critical infrastructure with significant malware outbreak	72 hours

8.10 Post-Incident Actions

1. Detection improvements

   • Deploy Sigma rules for observed TTPs
   • Improve email filtering based on observed evasion techniques
   • Implement Sysmon with comprehensive configuration if not deployed
   • Tune EDR behavioral detection policies
   • Add YARA rules for observed malware families

2. Prevention improvements

   • Application whitelisting on critical systems
   • Restrict PowerShell: Constrained Language Mode, script block logging, AMSI
   • Disable macros in Office documents from internet (Mark of the Web)
   • Implement WDAC/AppLocker policies
   • Restrict LOLBins execution from user-writable locations

3. Architecture improvements

   • Network segmentation between workstations (prevent lateral movement)
   • Implement DNS sinkholing for known malicious domains
   • Deploy deception technology (honeypots, honeytokens)
   • Implement least privilege for user accounts (remove local admin)

---

PLAYBOOK 9: CLOUD INFRASTRUCTURE COMPROMISE (AWS/Azure/GCP)

MITRE ATT&CK (Cloud Matrix): T1078.004 (Cloud Accounts), T1190 (Exploit Public-Facing Application), T1537 (Transfer Data to Cloud Account), T1530 (Data from Cloud Storage), T1578 (Modify Cloud Compute Infrastructure), T1580 (Cloud Infrastructure Discovery)

9.1 Detection Triggers

Source	Indicator	Confidence
CloudTrail/Activity Log	Root/Organization admin account login	High
Cloud SIEM	IAM user creation or role assumption from unknown IP	High
GuardDuty/Defender/SCC	High-severity finding: crypto mining, credential exfiltration, policy change	High
CloudTrail	ConsoleLogin without MFA for IAM user	High
CloudTrail	API calls from TOR exit nodes or known-bad IPs	High
Cloud Monitoring	Unusual compute instance launch (crypto mining, C2 infrastructure)	High
CloudTrail	S3 bucket policy changed to public, or data download spike	High
Cost Alerts	Unexpected billing spike (crypto mining, large data transfer)	Medium-High
CloudTrail	Access key usage from geographic location inconsistent with user	Medium
CloudTrail	Unused IAM user/role suddenly active	Medium
Cloud SIEM	Security group/firewall rules modified to allow broad ingress	Medium
CloudTrail	CloudTrail logging disabled or modified	Medium
Cloud Monitoring	Lambda/Function invocations from unusual triggers	Medium
SCM	Infrastructure-as-code modified to weaken security controls	Low-Medium

9.2 Severity Classification

Condition	Severity
Root/Organization admin compromised, attacker making infrastructure changes	SEV-1
Data exfiltration from production datastores confirmed	SEV-1
Attacker has persistent access and is modifying security controls	SEV-1
Compromised IAM credentials with broad permissions, activity detected	SEV-2
Crypto mining instances detected, no data access confirmed	SEV-2
Single service compromise (S3 bucket exposed, single instance compromised)	SEV-3
Suspicious activity from cloud account, no confirmed compromise	SEV-4

9.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: STOP ATTACKER ACCESS

1. Disable compromised credentials immediately

   AWS:

   # Disable access key
   aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <user>
   # Attach deny-all policy to compromised user/role
   aws iam attach-user-policy --user-name <user> --policy-arn arn:aws:iam::policy/AWSDenyAll
   # For compromised role: revoke all sessions
   aws iam put-role-policy --role-name <role> --policy-name RevokeOlderSessions --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*","Condition":{"DateLessThan":{"aws:TokenIssueTime":"<current-time>"}}}]}'
   

   Azure:

   # Disable user
   az ad user update --id <user-id> --account-enabled false
   # Revoke sessions
   az ad user revoke-sign-in-sessions --id <user-id>
   # Revoke service principal credentials
   az ad sp credential reset --name <sp-name>
   

   GCP:

   # Disable service account
   gcloud iam service-accounts disable <sa-email>
   # Disable user (via Admin SDK or Google Workspace admin)
   # Remove IAM bindings
   gcloud projects remove-iam-policy-binding <project> --member=user:<email> --role=<role>
   

2. Preserve audit logs

   • Verify CloudTrail/Activity Log/Cloud Audit Logs are still enabled (attacker may have disabled them)
   • If disabled: re-enable immediately
   • Export logs to secure, separate account: aws s3 sync s3://cloudtrail-bucket s3://ir-evidence-bucket
   • Enable additional logging if not already: VPC Flow Logs, S3 access logging, DNS query logging

3. Restrict network access

   • Revoke security group changes made by attacker
   • Block attacker IPs in NACLs/NSGs/firewall rules
   • If instances are compromised: isolate to IR security group (deny all ingress/egress except from IR team)

MINUTE 5-10: SCOPE THE COMPROMISE

4. Determine what the attacker did

   AWS: Query CloudTrail

   aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... --start-time <time> --end-time <time>
   

   Key events to look for:

   • IAM changes: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, UpdateAssumeRolePolicy
   • Data access: GetObject, PutBucketPolicy, GetSecretValue, DescribeDBInstances
   • Infrastructure: RunInstances, CreateFunction, CreateStack, ModifyInstanceAttribute
   • Defense evasion: StopLogging, DeleteTrail, PutEventSelectors, ModifyVpcAttribute
   • Persistence: CreateLoginProfile, CreateAccessKey, UpdateLoginProfile

5. Check for lateral movement across accounts

   • Review cross-account role assumptions
   • Check for organization-level changes (if attacker compromised management account)
   • Verify SCPs (Service Control Policies) are intact

MINUTE 10-15: ESCALATE

6. Engage cloud provider and escalate
   • AWS: Open AWS Support case (Business/Enterprise support), contact AWS Incident Response
   • Azure: Open Microsoft security incident support case
   • GCP: Contact Google Cloud security operations
   • Notify internal cloud team, CISO, Legal
   • Assess regulatory implications based on data stores accessed

9.4 Investigation Steps

Phase 1: Access Analysis (Hours 1-8)

1. Reconstruct attacker access timeline

   • Build complete timeline from cloud audit logs
   • Identify: initial access method, credential used, first API call, geographic location
   • Common initial access methods:
     • Leaked credentials (GitHub, CI/CD logs, config files)
     • Compromised instance with IAM role (SSRF, application vulnerability)
     • Phished cloud console credentials
     • Compromised third-party integration/OAuth app
     • Compromised CI/CD pipeline with cloud deployment credentials

2. Map attacker's permissions and actions

   • What IAM permissions did the compromised identity have?
   • What services did the attacker enumerate? (List*, Describe*, Get* calls)
   • What data stores were accessed? (S3, RDS, DynamoDB, Secrets Manager, Parameter Store)
   • What infrastructure was created or modified?
   • Were new IAM users, roles, or access keys created (persistence)?

3. Check for backdoors and persistence

   • New IAM users, roles, or access keys
   • Modified trust policies on existing roles
   • Lambda functions (potential backdoor or data exfiltration)
   • EC2 instances in unusual regions
   • Modified S3 bucket policies (public access, cross-account access)
   • SSM documents or automations
   • CloudFormation stacks (infrastructure backdoor)
   • New OAuth applications or API integrations

Phase 2: Data Impact Assessment (Hours 8-48)

4. S3/Blob/GCS data assessment

   • Review S3 server access logs or CloudTrail data events for GetObject calls
   • Identify: which buckets, which objects, data volume transferred
   • Check for bucket policy changes enabling public/cross-account access
   • Verify no data was uploaded (staging for later retrieval)

5. Database assessment

   • Check for RDS/Cloud SQL snapshot creation (data exfiltration method)
   • Review database connection logs during compromise window
   • Check for database user creation or privilege changes
   • Assess if database contents were dumped or queried

6. Secrets and credentials assessment

   • Review Secrets Manager / Key Vault / Secret Manager access logs
   • All secrets accessed during compromise window should be considered compromised
   • Check Parameter Store / SSM for credential access
   • Review KMS key usage (decrypt operations from attacker)
   • Check for customer-managed key policy changes

9.5 Evidence Collection Checklist

Evidence	Tool	Priority	Notes
CloudTrail / Activity Log / Audit Logs (management events)	Cloud console, CLI, SIEM	P1	Export to secure location immediately
CloudTrail data events (S3, Lambda, DynamoDB)	CloudTrail, Athena	P1	Often not enabled by default
VPC Flow Logs	CloudWatch, S3	P1	Shows network connections
IAM credential report	aws iam generate-credential-report	P1	All users, keys, MFA status
GuardDuty / Defender / SCC findings	Cloud console	P1	High-level threat detection
S3 access logs	S3, Athena	P2	Object-level access
Lambda function code (backdoors)	CLI export	P2	Preserve before deletion
EC2 instance metadata and disk snapshots	Cloud CLI	P2	For forensics
DNS query logs (Route53/Cloud DNS)	CloudWatch, Cloud Logging	P2	C2 communication
Container registry audit logs	ECR/ACR/GCR	P2	If container compromise
Cost and billing reports	Billing console	P3	Quantify attacker resource usage

9.6 Eradication

1. Remove all attacker persistence

   • Delete attacker-created IAM users, roles, access keys, login profiles
   • Remove attacker-added IAM policies and permission boundaries
   • Revert modified trust policies on roles
   • Delete attacker-deployed Lambda functions, EC2 instances, CloudFormation stacks
   • Remove attacker-created VPC peering, VPN connections, or transit gateway attachments
   • Revert security group and NACL changes
   • Remove attacker-created S3 buckets or modified bucket policies

2. Rotate ALL compromised credentials

   • All IAM user passwords and access keys in affected accounts
   • All secrets in Secrets Manager / Key Vault accessed during compromise
   • All service account keys
   • All application credentials (database passwords, API keys)
   • EC2 key pairs if instances were compromised
   • OAuth application secrets

3. Verify logging integrity

   • Confirm CloudTrail/audit logging is enabled in ALL regions
   • Verify log file validation is enabled
   • Confirm logs are going to immutable/protected storage
   • Check for gaps in logging (attacker may have paused logging)

4. Terminate attacker infrastructure

   • Terminate EC2/VM instances created by attacker (snapshot first for forensics)
   • Delete attacker-deployed resources in ALL regions (attackers often deploy in unused regions)
   • Check for resources in unusual regions: for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do echo "=== $region ===" && aws ec2 describe-instances --region $region --query 'Reservations[].Instances[].[InstanceId,LaunchTime,InstanceType]' --output table; done

9.7 Recovery

1. Restore secure configuration

   • Apply infrastructure-as-code to reset all configurations to known-good state
   • Verify SCPs/Organization policies are intact
   • Re-enable and verify all security controls (GuardDuty, CloudTrail, Config rules)
   • Review and reapply security baselines

2. Rebuild compromised workloads

   • If EC2/VM instances were compromised: terminate and redeploy from AMI/image
   • If container images were modified: rebuild from Dockerfile and trusted base images
   • If Lambda/Functions were modified: redeploy from source control
   • Verify integrity of all deployed code

3. Enhanced monitoring

   • Enable GuardDuty/Defender/SCC in all accounts and regions
   • Enable CloudTrail data events for S3 and Lambda
   • Deploy custom CloudWatch/Log Analytics alerts for:
     • Root account usage
     • IAM changes from unexpected sources
     • CloudTrail configuration changes
     • Resource creation in unused regions
     • Sensitive data access patterns

9.8 Communication Templates

Cloud Team Incident Brief

CLOUD INFRASTRUCTURE COMPROMISE -- INCIDENT BRIEF

Account(s) Affected: [ACCOUNT IDS AND NAMES]
Cloud Provider: [AWS/Azure/GCP]
Severity: [SEV LEVEL]
Status: [ACTIVE/CONTAINED/ERADICATED]

INITIAL ACCESS:
- Compromised credential: [IAM USER/ROLE/SERVICE PRINCIPAL]
- Access method: [LEAKED KEY/PHISHED CONSOLE/SSRF/CI-CD COMPROMISE]
- First unauthorized API call: [TIMESTAMP]

ATTACKER ACTIONS:
- Services accessed: [LIST]
- Data stores accessed: [S3 BUCKETS/DATABASES/SECRETS]
- Infrastructure created: [EC2 INSTANCES/LAMBDA/ETC]
- Persistence mechanisms: [IAM USERS/KEYS/ROLES CREATED]
- Estimated cost impact: [$AMOUNT]

CONTAINMENT STATUS:
- Compromised credentials: [DISABLED/ROTATED]
- Attacker infrastructure: [TERMINATED/ISOLATED]
- Logging: [VERIFIED INTACT/RESTORED]

DATA IMPACT:
- Data potentially accessed: [DESCRIPTION]
- Data confirmed exfiltrated: [DESCRIPTION]
- Regulatory data involved: [YES/NO -- TYPE]

NEXT STEPS:
1. [ORDERED ACTION ITEMS]

9.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	PII in accessed S3 buckets, databases, or secrets	72 hours / without undue delay
HIPAA	PHI in cloud storage or databases accessed	60 days
PCI DSS	Cardholder data in compromised cloud environment	Immediately
SOC 2	Cloud infrastructure security incident affecting customer data	Per trust services criteria
Cloud provider shared responsibility	Report to provider; provider reports controls on their side	Varies
FedRAMP	Federal government cloud systems compromised	Per agency ATO terms

9.10 Post-Incident Actions

1. IAM hardening

   • Enforce MFA on all IAM users (especially console access)
   • Implement least-privilege IAM policies (remove * permissions)
   • Deploy IAM Access Analyzer to identify over-permissioned roles
   • Implement permission boundaries for delegated administration
   • Regular access key rotation (or eliminate long-lived keys entirely -- use roles/temporary credentials)
   • Implement SCPs to restrict unused regions and dangerous actions

2. Cloud security posture management

   • Deploy CSPM tool (AWS Security Hub, Azure Defender, GCP SCC, or third-party)
   • Implement guardrails via SCPs, Azure Policy, GCP Organization Policies
   • Enable and enforce encryption at rest for all data stores
   • Implement VPC endpoints / Private Link to eliminate public internet data paths
   • Regular cloud security assessments and penetration testing

3. Detection improvements

   • CloudTrail enabled in ALL regions with data events for critical services
   • GuardDuty/Defender/SCC enabled in ALL accounts
   • Custom detections for: root login, IAM changes, security group changes, logging changes
   • Integrate cloud logs into central SIEM
   • Implement cloud-specific SOAR playbooks for automated response

4. Secrets management

   • Migrate from long-lived access keys to IAM roles with temporary credentials
   • Use Secrets Manager / Key Vault for all application credentials
   • Implement automated secret rotation
   • Scan code repositories for leaked credentials (git-secrets, truffleHog, GitHub secret scanning)

---

PLAYBOOK 10: PHYSICAL SECURITY BREACH (WITH CYBER IMPLICATIONS)

MITRE ATT&CK: T1200 (Hardware Additions), T1091 (Replication Through Removable Media), T1052 (Exfiltration Over Physical Medium), T1598 (Phishing for Information -- social engineering for physical access)

10.1 Detection Triggers

Source	Indicator	Confidence
Physical Security	Unauthorized individual observed in restricted area (data center, server room, executive floor)	High
Badge System	Tailgating detected (anti-passback violation)	High
Badge System	Cloned/stolen badge used (employee reports badge missing + badge used at facility)	High
CCTV	Unidentified individual accessing server room, network closets, or executive offices	High
Network	Unknown device connected to network port (NAC alert, rogue device detection)	High
Physical Security	Lock tampering, forced entry, or window breach detected	High
EDR	USB device insertion of unknown/unauthorized device (potential keystroke logger, USB Rubber Ducky, LAN Turtle)	High
Badge System	After-hours access by non-authorized personnel	Medium
Facilities	Damage or tampering to surveillance equipment	Medium
Network	New wireless access point detected (evil twin / rogue AP)	Medium
Physical Security	Visitor not properly escorted in restricted areas	Medium
Mail Room	Suspicious package containing electronic devices	Medium
Security Guard	Social engineering attempt at reception (impersonating vendor, delivery, IT)	Low-Medium

10.2 Severity Classification

Condition	Severity
Data center / server room breach with evidence of system access or tampering	SEV-1
Hardware implant (network tap, keystroke logger, rogue device) discovered	SEV-1
Physical theft of servers, hard drives, backup media, or devices with sensitive data	SEV-1
Unauthorized access to restricted area, no confirmed system interaction	SEV-2
Lost/stolen corporate device with encrypted sensitive data	SEV-2
Tailgating or unauthorized visitor in general office area	SEV-3
Failed social engineering attempt at reception	SEV-4

10.3 Immediate Containment (First 15 Minutes)

MINUTE 0-5: SECURE THE PHYSICAL SPACE

1. If intruder is STILL PRESENT

   • Contact building security and/or law enforcement (911 if threat to safety)
   • Do NOT confront the individual if there is any safety concern
   • Observe and document: appearance, behavior, items carried, areas accessed
   • Secure exits if safe to do so (security team only)
   • Activate lockdown procedures if warranted

2. If intruder has LEFT or equipment is missing/tampered

   • Secure the affected area: restrict access, post security
   • Preserve CCTV footage immediately (overwrite risk)
   • Do NOT touch or clean the area (preserve fingerprints, DNA, trace evidence)
   • Document the scene: photographs, notes on what appears disturbed

3. Preserve digital evidence from the physical space

   • Pull badge access logs for the affected area (past 72 hours minimum)
   • Pull CCTV footage from all cameras covering: the area, entry/exit points, parking, elevators
   • Export visitor logs from reception

MINUTE 5-10: ASSESS CYBER IMPACT

4. Check for planted devices

   • Visually inspect all network ports, USB ports, and exposed cabling in affected area
   • Look for: USB keystroke loggers, network implants (LAN Turtle, Packet Squirrel), rogue WiFi APs
   • Check for devices attached to KVM switches, monitors, or docking stations
   • Use wireless spectrum analysis to detect rogue access points
   • Check under desks, behind equipment, in ceiling tiles, in cable trays

5. Check for device theft or tampering

   • Inventory all devices in affected area against asset register
   • Check for missing hard drives, servers, backup tapes, USB drives
   • Check if any systems were powered on, logged into, or booted from external media
   • Review screen lock status of workstations in the area
   • Check for evidence of hard drive removal (case screws, drive bays)

6. Check for unauthorized network connections

   • Query NAC/802.1X logs for new MAC addresses in affected area's switch ports
   • Check for new devices on network segments serving the physical area
   • Scan for rogue wireless access points: airodump-ng or equivalent
   • Review DHCP logs for new leases in affected area

MINUTE 10-15: ESCALATE AND INVESTIGATE

7. Establish joint physical-cyber investigation
   • Coordinate physical security team + cybersecurity team + facilities
   • If law enforcement called: establish evidence coordination
   • Notify HR if insider involvement suspected
   • Notify Legal if regulated data potentially accessed/stolen

10.4 Investigation Steps

Phase 1: Physical Investigation (Hours 1-8)

1. CCTV and access log analysis

   • Review all camera footage for the 24-48 hours before and after the incident
   • Map intruder's movement through the facility
   • Identify: entry method, areas visited, duration, items carried in/out, accomplices
   • Cross-reference with badge access logs for all doors

2. Identify the intruder

   • Visitor logs: was the intruder signed in? Who was their host?
   • Badge system: was a stolen/cloned badge used? Whose badge?
   • CCTV facial capture for identification (coordinate with law enforcement)
   • Check for vehicle identification (license plates, make/model in parking footage)
   • Social engineering assessment: did anyone speak with the intruder?

3. Forensic sweep of affected area

   • Professional sweep for electronic surveillance devices (bugs, cameras, transmitters)
   • Check for hardware implants on ALL network-connected equipment
   • Inspect server/networking equipment for signs of tampering
   • Check telephone systems for wiretaps or recording devices
   • Check for modified firmware on network switches, firewalls, or other infrastructure

Phase 2: Cyber Impact Assessment (Hours 1-24, parallel)

4. Assess planted device capabilities (if found)

   • Do NOT connect found device to your network -- use isolated analysis environment
   • Analyze device type and capabilities:
     • Network tap/implant: what traffic could it capture?
     • Keystroke logger: what credentials could be harvested?
     • Rogue AP: man-in-the-middle, credential capture?
     • USB attack tool (Rubber Ducky, Bash Bunny): what payload was delivered?
   • Determine how long the device was in place (correlated with access logs/CCTV)

5. Assess data exposure from stolen equipment

   • Was full disk encryption enabled on stolen devices?
   • What data was stored on stolen devices?
   • Were any credentials cached on stolen devices?
   • Was the device connected to VPN or had cached cloud tokens?
   • Check MDM for device status and remote wipe capability

6. Assess direct system access

   • If systems were accessed: review authentication logs for local/console logins
   • Check for boot from external media (BIOS/UEFI logs if available)
   • Review for data copied to USB or external devices
   • Check for firmware modifications (especially on network equipment and servers)
   • If BIOS/BMC/IPMI was accessible: check for firmware implants

10.5 Evidence Collection Checklist

Evidence	Tool	Priority	Notes
CCTV footage (all relevant cameras)	CCTV DVR/NVR	P1	Preserve before overwrite cycle
Badge access logs (affected area, all entries/exits)	Physical access control system	P1	Pull 72+ hours
Planted devices (do not modify)	Photograph in situ, then collect with gloves	P1	Chain of custody critical
Fingerprints/DNA from tampered equipment	Law enforcement	P1	Do not touch/clean
Visitor logs	Reception system	P1
Network connection logs for affected ports	Switch logs, NAC	P1	New MAC addresses
EDR logs from workstations in affected area	EDR console	P2	USB insertions, logins
Wireless survey data	WiFi analyzer	P2	Rogue AP detection
Photographs of scene	Digital camera	P2	Before anything is moved
Stolen device forensic data (if recovered)	MDM, disk forensics	P2
Vehicle identification from parking cameras	CCTV, ALPR	P3	Law enforcement may assist

10.6 Eradication

1. Remove planted devices

   • Remove all identified implants with proper evidence handling (photograph, bag, chain of custody)
   • Have professional TSCM (Technical Surveillance Countermeasures) team sweep entire facility if implant found (likely not the only one)
   • Replace compromised network cables, switches, or equipment if tampering confirmed

2. Address stolen equipment

   • Remote wipe stolen devices via MDM if possible
   • Disable all accounts/certificates/VPN profiles associated with stolen devices
   • Revoke device certificates
   • Blacklist stolen device serial numbers/MAC addresses

3. Rotate compromised credentials

   • All passwords entered on systems where keystroke loggers were found
   • All credentials for systems accessible from compromised network ports
   • WiFi passwords if rogue AP could have captured them
   • All credentials cached on stolen devices

4. Remediate physical access

   • Disable stolen/cloned badges
   • Rekey affected locks if physical keys were stolen or copied
   • Change access codes for affected areas
   • Review and update access control lists for sensitive areas

10.7 Recovery

1. Restore physical security

   • Repair any damage (doors, locks, windows, cameras)
   • Replace tampered equipment
   • Verify all surveillance cameras are operational
   • Verify all badge readers and access controls are functional
   • Consider adding temporary additional security (guards, cameras)

2. Restore cyber security posture

   • Complete network sweep for any remaining unauthorized devices
   • Verify integrity of all network equipment firmware
   • Re-scan for rogue wireless access points
   • Confirm NAC policies are enforced on all ports

3. Replace stolen equipment

   • Provision replacement devices with fresh credentials
   • Restore data from backup to new devices
   • Enroll new devices in MDM and security tools

10.8 Communication Templates

All-Staff Security Alert

Subject: Physical Security Incident -- Heightened Awareness Required

[COMPANY] experienced a physical security incident at [LOCATION] on [DATE].
[BRIEF FACTUAL DESCRIPTION without sensitive investigative details].

EFFECTIVE IMMEDIATELY, please observe the following:
- Always wear your badge visibly
- Do NOT hold doors for anyone -- everyone must badge in individually
- Challenge or report any unescorted individuals in restricted areas
- Report any unfamiliar devices connected to your workstation or network ports
- Report suspicious behavior to security at [NUMBER]
- Check your workstation for unauthorized USB devices or items plugged
  into your equipment

If you observed anything unusual on [DATE] near [LOCATION], please contact
[SECURITY CONTACT] at [NUMBER] -- even small details may be important.

Your vigilance helps protect our organization and our data.

Law Enforcement Report

PHYSICAL SECURITY BREACH REPORT

Reporting Organization: [COMPANY]
Location: [FULL ADDRESS]
Incident Date/Time: [DATE/TIME]
Discovery Date/Time: [DATE/TIME]

INCIDENT DESCRIPTION:
[Detailed factual description of the breach]

AREAS ACCESSED:
[List of rooms, floors, areas the intruder accessed]

DURATION:
Entry time: [TIME] | Exit time: [TIME] | Total: [DURATION]

SUSPECT DESCRIPTION:
[Physical description, clothing, distinguishing features from CCTV]

EVIDENCE PRESERVED:
- CCTV footage: [YES/NO -- duration preserved]
- Access logs: [YES/NO]
- Physical evidence: [fingerprints, dropped items, planted devices]

ITEMS STOLEN/TAMPERED:
[Inventory of missing or tampered equipment with serial numbers]

CYBER IMPLICATIONS:
[Description of potential data exposure or system compromise]

ESTIMATED VALUE OF LOSS: [$AMOUNT]

POINT OF CONTACT: [NAME, TITLE, PHONE, EMAIL]

10.9 Regulatory Notification Requirements

Regulation	Trigger	Timeline
GDPR Art. 33/34	Unencrypted devices with PII stolen; planted devices captured PII	72 hours / without undue delay
HIPAA	Theft of devices containing ePHI; physical access to systems with ePHI	60 days
PCI DSS	Physical access to cardholder data environment	Immediately to card brands
State breach laws	Unencrypted personal information on stolen devices	Varies by state
FISMA/FedRAMP	Physical breach of federal data processing facility	Per agency requirements
Insurance	Theft claim, property damage, business interruption	Per policy terms

10.10 Post-Incident Actions

1. Physical security improvements

   • Deploy/upgrade anti-tailgating controls (mantraps, turnstiles, anti-passback)
   • Implement multi-factor physical access (badge + PIN/biometric) for sensitive areas
   • Upgrade CCTV: coverage gaps, resolution, retention period, analytics
   • Implement ALPR for parking areas
   • Security guard training on social engineering awareness
   • Regular TSCM sweeps of sensitive areas
   • Visitor management system upgrade: photo ID, escort requirements, pre-registration

2. Cyber-physical convergence

   • Integrate physical access logs with SIEM
   • Correlate badge access with network authentication (user badged into building X but logging in from building Y = alert)
   • Implement NAC/802.1X on all network ports (including in restricted areas)
   • Deploy rogue device detection (continuous wireless monitoring)
   • Encrypt all endpoint storage (full disk encryption mandatory)
   • Enable remote wipe capability on all mobile devices
   • Disable unused network ports in sensitive areas
   • Implement USB port control / device whitelisting

3. Process improvements

   • Regular physical security assessments (penetration testing of physical controls)
   • Social engineering testing (physical pretexting exercises)
   • Tabletop exercises combining physical and cyber breach scenarios
   • Review and update clean desk policy
   • Implement equipment tamper-evident seals on critical infrastructure

---

APPENDIX A: CROSS-PLAYBOOK REFERENCE

Regulatory Notification Quick Reference

Regulation	Notification Timeline	Authority	Key Trigger
GDPR Art. 33	72 hours from awareness	Supervisory Authority	Personal data breach
GDPR Art. 34	Without undue delay	Data subjects	High risk to individuals
HIPAA	60 days from discovery	HHS OCR, individuals, media (>500)	Unsecured PHI breach
CCPA/CPRA	Expedient, no unreasonable delay	CA AG, consumers	Personal information breach
SEC 8-K (1.05)	4 business days from materiality determination	SEC	Material cybersecurity incident
PCI DSS	Immediately	Card brands, acquiring bank	Cardholder data compromise
CISA CIRCIA	72 hours (incident) / 24 hours (ransom payment)	CISA	Critical infrastructure
NIS2 (EU)	24h early warning, 72h full notification	CSIRT/competent authority	Significant incident
State breach laws	30-90 days typically (varies by state)	State AG offices	PII of residents

Evidence Handling Standards

1. Chain of Custody: Every evidence item documented with collector, date/time, source, method, hash, storage location
2. Hashing: SHA-256 minimum for all digital evidence at time of collection
3. Storage: Evidence stored in access-controlled location with audit logging
4. Integrity: Write-block all forensic media; verify hash before and after analysis
5. Retention: Minimum 1 year or per legal hold requirements, whichever is longer
6. Legal admissibility: Follow organization's legal counsel guidance for evidence that may be used in proceedings

Tool Quick Reference

Category	Tools
Memory Acquisition	AVML (Linux), DumpIt/WinPMEM/Magnet RAM Capture (Windows), LiME (Linux kernel)
Memory Analysis	Volatility 3, MemProcFS, Rekall
Disk Forensics	FTK Imager, Autopsy/Sleuth Kit, KAPE, dc3dd
Timeline	Plaso/log2timeline
Log Analysis	Chainsaw, Hayabusa, WELA, Sigma, Zircolite
Network Forensics	Zeek, tcpdump, Wireshark, NetworkMiner
Malware Analysis	Cuckoo, Any.Run, Joe Sandbox, Hybrid Analysis, VirusTotal
Endpoint Detection	Velociraptor, GRR Rapid Response, osquery
Incident Management	TheHive, IRIS, DFIR-IRIS, RTIR
Cloud Forensics	Diffy (Netflix), Prowler (AWS), ScoutSuite, CloudQuery
Email Analysis	PhishTool, emailheaders.net, MXToolbox
IOC Management	MISP, OpenCTI, STIX/TAXII

Incident Severity Decision Tree

START
  |
  v
Is there active data destruction, encryption, or exfiltration? --YES--> SEV-1
  |NO
  v
Is a privileged account (admin/root) confirmed compromised? --YES--> SEV-1
  |NO
  v
Is there confirmed compromise with lateral movement? --YES--> SEV-2
  |NO
  v
Is regulated data (PII/PHI/PCI) confirmed accessed? --YES--> SEV-2
  |NO
  v
Is there confirmed compromise of single system/account? --YES--> SEV-3
  |NO
  v
Is there suspicious but unconfirmed activity? --YES--> SEV-4
  |NO
  v
Not an incident -- handle via standard support channels

---

End of CIPHER Incident Response Playbooks v1.0 Review cycle: Quarterly or after every significant incident Document owner: Security Operations Next review date: 2026-06-14