<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->
# NERF 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**
   ```powershell
   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:
     ```bash
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:
   ```bash
   # 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:
   ```bash
   # 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:
   ```bash
   # 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
   ```bash
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 NERF Incident Response Playbooks v1.0*
*Review cycle: Quarterly or after every significant incident*
*Document owner: Security Operations*
*Next review date: 2026-06-14*
