Supply Chain Compromise Playbook¶

Metadata¶

Trigger Conditions¶

Activate this playbook on any of the following:

• [ ] Vendor issues security notification about compromised software/update
• [ ] Hash match on installed software against known-malicious IOC (CISA, VirusTotal, vendor advisory)
• [ ] CISA advisory or US-CERT alert matching an installed vendor's product
• [ ] Threat intelligence feed: vendor product name + "backdoor" / "compromise" / "supply chain"
• [ ] EDR / SIEM alert on behavior consistent with known supply chain TTP (unusual outbound from update service, DLL sideloading from trusted vendor path)
• [ ] Anomalous network traffic from a trusted software agent (RMM tool, monitoring agent, security product)
• [ ] Unexpected code signing certificate from a trusted vendor used for a new, unknown binary
• [ ] Package manager alert: dependency with known-malicious version installed (npm audit, pip audit, Dependabot)

Decision Tree¶

flowchart TD
    A([Supply Chain Trigger]) --> B[Collect: Vendor advisory\nCVE / CISA alert\nIOC hashes]
    B --> C{Do we have the\naffected software\ninstalled?}
    C -- No --> D[Document. Monitor.\nUpdate SBOM. Close.]
    C -- Yes --> E[Scope: How many systems\nhave the affected version?]
    E --> F{Is the compromised\nversion confirmed\nmalicious vs. just vulnerable?}
    F -- Malicious/Backdoored --> G[CRITICAL:\nEstablish full scope first\nthen contain simultaneously]
    F -- Vulnerable only --> H[Patch management track:\nstandard vulnerability process]
    G --> I{Evidence of active\nexploitation in our env?}
    I -- Yes --> J[Full IR activation\nForensics on affected systems\nCredential reset for all\nservice accounts]
    I -- No/Unknown --> K[Block update mechanism\nQuarantine affected systems\nMonitor for IOC activity]
    J --> L[Vendor coordination:\nengage vendor IR team]
    K --> L
    L --> M[SBOM update\nVerify clean replacement\nStaged rollout]
    M --> N([Post-incident:\nThird-party risk review\nVendor assessment])

Phase 1 — Scope Assessment (0–2 Hours)¶

1.1 Identify All Affected Systems¶

# Query endpoint management for affected software version
# SCCM / Intune — PowerShell
Get-CimInstance -ClassName Win32_Product |
    Where-Object { $_.Name -like "*VendorProductName*" } |
    Select-Object Name, Version, Vendor, InstallDate, InstallLocation |
    Export-Csv "affected_systems_$(date +%Y%m%d).csv"

# Using Osquery (cross-platform asset inventory)
osqueryi "SELECT name, version, install_time, path FROM programs
          WHERE name LIKE '%VendorProduct%';"

# For Linux — dpkg / rpm
dpkg -l | grep -i vendorproduct
rpm -qa | grep -i vendorproduct

# Using Ansible for distributed query
ansible all -m shell -a "rpm -qa | grep vendorproduct || dpkg -l | grep vendorproduct" \
  > affected_hosts_$(date +%Y%m%d).txt

1.2 Verify Installed Version Hash¶

# Compare installed binary hash against vendor-provided known-good and known-bad hashes
sha256sum /path/to/installed/vendorproduct.exe

# Bulk hash check against IOC list
while IFS= read -r filepath; do
    hash=$(sha256sum "$filepath" 2>/dev/null | awk '{print $1}')
    if grep -qi "$hash" known_bad_hashes.txt; then
        echo "MATCH — COMPROMISED: $filepath ($hash)"
    fi
done < installed_binary_paths.txt

# VirusTotal hash lookup (requires API key)
curl -s "https://www.virustotal.com/api/v3/files/$HASH" \
  -H "x-apikey: $VT_API_KEY" | jq '.data.attributes.last_analysis_stats'

1.3 Determine Blast Radius¶

• [ ] How many systems have the affected version installed? (from 1.1)
• [ ] What privileges does the software run with? (SYSTEM, root, service account?)
• [ ] What network access does the software have? (can it reach the internet? internal segments?)
• [ ] What data does the software have access to? (credentials, data stores, configs)
• [ ] Was the software used as a management/monitoring tool with elevated access to many hosts?

Phase 2 — Contain (2–4 Hours)¶

2.1 Block Update Mechanism¶

# DNS sinkhole for vendor update domain (coordinate with network team)
# Add to internal DNS resolver:
# vendorupdate.example.com -> 127.0.0.1

# Firewall rule — block all outbound to vendor update infrastructure
iptables -A OUTPUT -d vendor-update-server.example.com -j DROP
# OR via pfSense / Palo Alto alias — add update server IPs to block list

# Windows — Block via Group Policy (Windows Firewall)
netsh advfirewall firewall add rule name="BLOCK_VENDOR_UPDATE" `
    dir=out action=block remoteip=<UPDATE_SERVER_IP> enable=yes

2.2 Network Isolation of Affected Systems¶

# Segment affected hosts into a quarantine VLAN (coordinate with network team)
# If using CrowdStrike — network contain all affected hosts
falconctl contain --hostname affected-host-001
falconctl contain --hostname affected-host-002
# ... or from a list
while IFS= read -r host; do
    falconctl contain --hostname "$host" && echo "Contained: $host"
done < affected_hosts.txt

2.3 Credential Reset — Service Accounts¶

# Identify service accounts associated with affected software
Get-ADUser -Filter {ServicePrincipalNames -like "*VendorProduct*"} `
    -Properties ServicePrincipalNames, PasswordLastSet

# Reset all service accounts that ran on affected hosts
$serviceAccounts = @(
    "svc-vendorproduct",
    "svc-monitoring",
    "svc-mgmt"
)
foreach ($svc in $serviceAccounts) {
    $newPwd = [System.Web.Security.Membership]::GeneratePassword(32, 8)
    Set-ADAccountPassword -Identity $svc -Reset `
        -NewPassword (ConvertTo-SecureString $newPwd -AsPlainText -Force)
    Write-Host "[$(Get-Date -Format u)] Reset: $svc"
}

Phase 3 — Eradicate (4–24 Hours)¶

3.1 Uninstall / Rollback Compromised Software¶

# Windows — silent uninstall
msiexec /x {PRODUCT_GUID} /qn /norestart
# Or via SCCM application deployment (reverse deployment — uninstall package)

# Linux — package manager
apt remove --purge vendorproduct -y
rpm -e vendorproduct

# Docker — pull and validate clean image
docker pull vendor/product:clean-version
docker image inspect vendor/product:clean-version | jq '.[].RootFS.Layers'
# Verify layers match vendor-published manifest

3.2 Full Forensics on Affected Systems¶

• [ ] Pull full EDR process tree for the affected software process (parent/child relationships)
• [ ] Identify any processes spawned by the software (unexpected cmd.exe, powershell.exe, etc.)
• [ ] Pull network connection history for the affected software process
• [ ] Check for files dropped or modified by the software in the compromise window
• [ ] Check for registry modifications made by the software
• [ ] Collect memory dump from critical/high-value affected systems before isolation

# EDR — hunt for suspicious child processes of vendor software
# CrowdStrike Event Search (example query):
# event_simpleName=ProcessRollup2 ParentBaseFileName="vendorproduct.exe"
#   AND FileName IN ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe")
# | table ComputerName, CommandLine, NetworkContainmentState

# Velociraptor — cross-host artifact collection
velociraptor -v artifacts collect Windows.System.Pslist \
  --args processRegex="vendorproduct" \
  --output forensics_output/

3.3 Threat Hunting for Attacker Activity¶

Based on known supply chain TTPs, hunt for:

• [ ] Living-off-the-land binaries (LOLBins) executed in context of vendor software
• [ ] Lateral movement: psexec, wmiexec, winrm from affected hosts
• [ ] Credential harvesting: LSASS access, SAM file reads
• [ ] Persistence: new scheduled tasks, services, or registry run keys post-compromise
• [ ] Exfiltration: DNS tunneling, HTTPS to unknown IPs, large file transfers

# Hunt for LSASS dumps (common credential harvesting method)
# EDR query: event_simpleName=ProcessRollup2 TargetImageFileName CONTAINS "lsass"
#   AND FileName NOT IN ("csrss.exe","taskmgr.exe","MsMpEng.exe")

# Hunt for anomalous outbound HTTPS (non-standard ports)
# Zeek/NetworkMiner: conn.log src=affected_host proto=tcp dest_port NOT IN (443,80,8080,8443)

Phase 4 — Verify and Recover¶

4.1 Verify Clean Software Baseline¶

# Download clean version from vendor with hash verification
wget https://vendor.example.com/downloads/product-clean.tar.gz
sha256sum product-clean.tar.gz
# Compare against vendor's published hash from their security advisory

# Verify code signing certificate (Windows)
Get-AuthenticodeSignature "C:\Program Files\VendorProduct\vendorproduct.exe" |
    Select-Object Status, SignerCertificate, TimeStamperCertificate

# Verify RPM signature (Linux)
rpm --checksig vendorproduct-clean.rpm

4.2 Staged Rollout of Clean Software¶

Stage 1 (10% of fleet): Deploy to low-risk, non-production systems. Monitor 24h.
Stage 2 (30%): Deploy to non-critical production. Monitor 12h.
Stage 3 (60%): Deploy to important production systems. Monitor 6h.
Stage 4 (100%): Complete deployment. Confirm no regressions.

Third-Party Coordination¶

Vendor IR Team Engagement¶

• [ ] Contact vendor's security disclosure / PSIRT (Product Security Incident Response Team) directly
• [ ] Request: official advisory, known IOCs, forensic artifacts, clean binary hashes, remediation timeline
• [ ] Ask: how was the compromise discovered? What was the compromise window? What was the blast radius?
• [ ] Establish a secure communication channel (PGP email or vendor's secure portal)
• [ ] Do not publicly disclose until coordinated with vendor (if they are not already disclosing)

CISA Notification¶

CISA 24/7 Operations Center:
  Phone: 888-282-0870
  Email: central@cisa.dhs.gov
  Web:   cisa.gov/report

Provide:
  - Affected vendor and product name + version
  - Number of systems affected
  - Evidence of active exploitation (if any)
  - SBOM excerpt showing dependency scope

SBOM Review and Update¶

• [ ] Update Software Bill of Materials (SBOM) to remove or flag affected component
• [ ] Identify all other products/services in your environment that depend on the same vendor or component
• [ ] Check for transitive dependencies: does any internal application import the affected library?

# Check for transitive dependency in Node.js project
npm audit
npx npm-why affected-package-name

# Python
pip-audit
pip show affected-package | grep Requires

# Java / Maven
mvn dependency:tree | grep affected-artifact

# Container image scanning (Trivy)
trivy image your-application:latest --severity CRITICAL,HIGH

Recovery Checklist¶

Scope & Assessment¶

• [ ] Full list of affected systems compiled
• [ ] Blast radius determined (privilege level, network access, data access)
• [ ] Vendor advisory and IOC list obtained

Contain¶

• [ ] Update mechanism blocked
• [ ] Affected systems isolated (quarantine VLAN or EDR containment)
• [ ] Service account credentials rotated

Eradicate¶

• [ ] Compromised software uninstalled/rolled back on all systems
• [ ] Forensics complete — attacker activity scoped
• [ ] Persistence mechanisms removed
• [ ] Credential reset for all service accounts on affected hosts

Verify & Recover¶

• [ ] Clean software version hash verified against vendor advisory
• [ ] Staged rollout complete — all systems running verified clean version
• [ ] EDR scan passed on all recovered systems

Third-Party & Documentation¶

• [ ] Vendor IR team engaged
• [ ] CISA notified (if applicable)
• [ ] SBOM updated
• [ ] Regulatory notifications sent (if data exfiltration occurred)

Post-Incident¶

• [ ] Third-party vendor risk assessment initiated for affected vendor
• [ ] Software procurement requirements updated (must provide signed SBOM)
• [ ] Dependency scanning integrated into CI/CD pipeline
• [ ] Tabletop exercise scheduled: supply chain breach scenario