📧 Business Email Compromise 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 business email compromise message has been analyzed for impersonation technique (display name spoofing, domain lookalike, compromised account), urgency indicators, and requested actions. Header analysis should identify the true sender infrastructure and any reply-to redirection.

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 financial transactions initiated as a result of the BEC attack have been identified and frozen or reversed where possible. Coordination with the finance department and banking partners should be immediate to maximize the chance of fund recovery.

Confirm that all active cloud sessions and refresh tokens for compromised accounts have been revoked, not just passwords reset. Verify revocation in Azure AD, Google Workspace, or the relevant identity provider by confirming no active sessions remain.

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.