Supply Chain Attack Investigation Assessment

Confirm that the investigation window has been defined with clear T-start (earliest known indicator) and T-end boundaries. The timeframe should include a safety buffer of at least 48 hours before the first detected IOC to account for pre-compromise reconnaissance.

Verify that the initially compromised system, account, or entry point has been identified and documented. Patient zero determination should be supported by corroborating evidence from multiple log sources such as EDR, authentication logs, and email gateway records.

Confirm that the vendor advisory has been ingested, including affected product, version range, published IoCs (hashes, C2 domains, certificates), and the earliest malicious release timestamp. Private IoC sharing from ISAC or vendor channels has been requested if the public advisory is incomplete.

Confirm that affected-asset enumeration distinguishes assets with the compromised package present, assets where the payload executed, and assets that contacted attacker C2 infrastructure. These three cohorts have different response requirements.

Confirm that all systems identified as compromised have been isolated from the network. Isolation should be verified through network-level controls (VLAN segmentation, firewall rules, or EDR network quarantine) rather than simply disabling accounts on the host.

Verify that all accounts known or suspected to be compromised have been disabled or had their credentials forcibly rotated. This includes service accounts, shared accounts, and any accounts with elevated privileges that the attacker may have accessed.

Verify that all affected services have been rolled back to a verified safe version of the package with lockfile updates committed. CI/CD pipelines are frozen against redeploying malicious versions; internal registries block the known-bad versions.

Confirm that volatile memory (RAM) has been captured from all key compromised systems before any reboot or remediation action. Memory dumps should be acquired using forensically-sound tools and stored with proper chain of custody documentation.

Verify that all critical log sources have been snapshotted or exported to a tamper-proof location. This includes SIEM data, Windows Event Logs, authentication logs, email gateway logs, and cloud audit trails that fall within the investigation timeframe.

Confirm that the root cause of the incident has been identified, including the initial attack vector, any exploited vulnerabilities, and the conditions that allowed the compromise to succeed. The root cause should be documented with supporting evidence from forensic analysis.

Confirm that all attacker-deployed malware, scripts, remote access tools, and utilities have been identified and removed from every affected system. Removal should be validated through post-remediation scans and manual verification of common persistence locations.

Verify that all attacker persistence mechanisms have been identified and removed. This includes scheduled tasks, registry run keys, startup folder entries, WMI subscriptions, service installations, DLL hijacks, and any modified Group Policy Objects.

Ensure that all credentials known or suspected to be compromised have been reset, including user passwords, service account passwords, API keys, certificates, and Kerberos tickets. The KRBTGT account should be reset twice if domain compromise is suspected.