Network Security Audit and Digital Forensics Design Guide › Chapter 3

Scenarios & Selection

Eight real-world application scenarios illustrating how the audit and forensics platform addresses specific threat classes, with technical indicators, evidence requirements, and selection guidance for each.

Scenario 1: Ransomware Outbreak & Lateral Movement Reconstruction

When ransomware strikes an enterprise network, the most critical forensic challenge is reconstructing the full attack chain — from initial access through lateral movement to encryption detonation — within hours. This scenario requires tight integration between EDR telemetry, authentication logs, and network flow data to establish a defensible timeline that identifies patient zero, propagation paths, and the exact scope of compromise.

Ransomware Outbreak SOC Response
Figure 3.1: Ransomware Outbreak Response — SOC analysts correlating EDR process trees, Kerberos authentication anomalies, and lateral movement indicators across the SIEM dashboard

Scenario Description

An enterprise with 2,000 endpoints experiences a ransomware outbreak that begins with a phishing email, escalates through credential theft, and spreads via PsExec and SMB shares before encrypting file servers. The forensics team must reconstruct the full kill chain within 4 hours to support business continuity decisions and regulatory notification timelines.

Key Technical Indicators

  • Evidence Sources: EDR process trees, Windows Event Logs (4624/4625/4648), Kerberos TGT/TGS requests, SMB access logs, NetFlow east-west traffic
  • Time Correlation: NTP skew ≤1s mandatory; events from 15+ sources must align within milliseconds
  • Reconstruction SLA: Full kill chain reconstruction within 4 hours of alert
  • Evidence Retention: Hot index 90 days; cold archive 7 years for legal proceedings
  • PCAP Requirement: Egress + inter-segment captures with 72-hour rolling retention
  • Bastion Coverage: 100% admin sessions recorded; session replay available for all lateral movement via admin tools

Scenario 2: Insider Data Theft via SaaS & Cloud Storage

Insider threats involving data exfiltration through SaaS platforms and cloud storage services represent one of the most challenging audit scenarios because the evidence is distributed across multiple cloud providers, each with different API structures, log formats, and retention policies. Effective detection requires unified identity correlation across on-premises IAM, SaaS audit logs, and DLP telemetry.

Insider Data Theft via SaaS
Figure 3.2: Insider Data Theft Investigation — Security analyst monitoring DLP alerts, SaaS audit logs, and identity access management anomalies while correlating with VPN connection records

Scenario Description

A departing employee downloads 50GB of proprietary data from SharePoint Online and OneDrive to a personal device over three weeks before their last day. The investigation must prove the identity of the actor, the exact files accessed, the destination devices, and the timeline — all using cloud audit logs that may have limited retention windows.

Key Technical Indicators

  • Evidence Sources: Microsoft 365 Unified Audit Log, Azure AD sign-in logs, DLP policy match events, VPN connection logs, endpoint USB/print logs
  • Identity Correlation: Single user ID across all systems; MFA authentication records required for non-repudiation
  • Volume Baseline: Behavioral baseline of normal download volume; anomaly threshold at 3× rolling 30-day average
  • Retention Gap Risk: M365 audit logs default 90 days; must extend to 1 year for insider threat investigations
  • DLP Coverage: Endpoint DLP + cloud CASB integration required for complete exfiltration evidence
  • Export SLA: Evidence package for legal/HR within 4 hours of investigation authorization

Scenario 3: Privileged Admin Cover-Up Attempt Detection

When a privileged administrator attempts to cover their tracks by deleting logs, modifying audit trails, or altering system configurations, the forensics platform must have pre-positioned evidence points that are architecturally inaccessible to the admin. This scenario validates the "record the recorder" principle and the value of immutable, out-of-band evidence collection.

Privileged Admin Cover-Up Detection
Figure 3.3: Privileged Admin Forensics — Investigator examining bastion session replay showing log clearing attempts, cross-referenced with configuration diffs and chain-of-custody evidence records

Scenario Description

A database administrator with root access to production systems deletes application logs and modifies audit configurations to conceal unauthorized data access. The investigation relies entirely on the bastion session recording, out-of-band log forwarding that occurred before deletion, and configuration version history to reconstruct the cover-up attempt.

Key Technical Indicators

  • Evidence Sources: Bastion/PAM full session recordings (keystroke + screen), out-of-band syslog forwarded before deletion, config version diffs, SIEM meta-audit logs
  • Bastion Architecture: Admin access exclusively via bastion; direct SSH/RDP blocked by network ACL
  • Session Integrity: Session recordings stored in WORM vault; admin cannot access recording storage
  • Config Versioning: Automated snapshots every 15 minutes; signed diffs with timestamps
  • Meta-Audit: All SIEM/vault admin actions logged to separate immutable index
  • Segregation of Duties: Storage admin ≠ SOC analyst; dual control for evidence access

Scenario 4: WAF Bypass & Application Layer Attack Investigation

Advanced web application attacks that bypass WAF controls require forensic analysis at the application layer, combining HTTP request/response logs, WAF decision logs, API gateway telemetry, and PCAP data to reconstruct the attack payload and determine the scope of data exposure. This scenario highlights the importance of application-layer logging depth and PCAP retention at web tiers.

WAF Bypass Attack Investigation
Figure 3.4: WAF Bypass Investigation — Security engineer analyzing PCAP captures and WAF decision logs to reconstruct application layer attack patterns and determine data exposure scope

Scenario Description

An attacker uses a novel HTTP header injection technique to bypass WAF rules and exfiltrate customer PII through a REST API. The investigation must determine exactly which records were accessed, prove the attack vector, and provide evidence for regulatory breach notification — all within 72 hours of discovery.

Key Technical Indicators

  • Evidence Sources: WAF full request/response logs, API gateway access logs, application server logs, PCAP at web tier, database query logs
  • Log Depth: Full HTTP request bodies required (not just headers); response codes and sizes for exfiltration detection
  • PCAP Retention: Web tier PCAP with 7-day rolling retention; trigger-based extended capture on WAF alerts
  • Correlation: WAF session ID → API gateway request ID → application transaction ID → database query ID
  • Breach Scope: Record-level access logging in database tier required for PII breach quantification
  • Notification Timeline: Evidence package for regulatory notification within 72 hours

Scenario 5: Cloud IAM Credential Leak & Unauthorized Access

Cloud IAM credential compromise — whether through phishing, code repository exposure, or third-party breach — enables attackers to operate as legitimate cloud identities, making detection dependent on behavioral analysis of API call patterns rather than traditional signature-based detection. Forensic reconstruction requires comprehensive cloud audit trail collection across multiple cloud services and regions.

Cloud IAM Credential Leak Investigation
Figure 3.5: Cloud IAM Forensics — Cloud security engineer analyzing IAM role assumption chains, geographic access anomalies, and KMS key usage patterns to reconstruct unauthorized cloud access

Scenario Description

AWS access keys exposed in a public GitHub repository are used by an external attacker to assume IAM roles, access S3 buckets containing customer data, and exfiltrate 200GB before detection. The investigation must prove the full scope of access, the timeline, and the exact data touched — using only cloud audit logs as primary evidence.

Key Technical Indicators

  • Evidence Sources: AWS CloudTrail (all regions), S3 access logs, VPC Flow Logs, KMS key usage logs, IAM credential report
  • Geographic Anomaly: Access from unexpected IP ranges/countries; impossible travel detection
  • Role Assumption Chain: Full STS AssumeRole chain with source identity preserved
  • Data Scope: S3 object-level logging required for per-file access evidence
  • Retention: CloudTrail logs centralized to immutable S3 with object lock; 7-year retention
  • Cross-Account: CloudTrail organization trail covering all accounts in AWS Organization

Scenario 6: Software Supply Chain Attack Forensics

Supply chain attacks that introduce malicious code through trusted software update mechanisms or compromised third-party libraries require forensic analysis that spans software integrity verification, endpoint execution telemetry, and network communication analysis. The evidence chain must prove the integrity of the original software, the point of compromise, and the scope of malicious activity.

Supply Chain Attack Forensics
Figure 3.6: Supply Chain Attack Investigation — Digital forensics team comparing file hashes against known-good baselines, analyzing proxy/DNS logs for C2 communication, and mapping EDR execution chains

Scenario Description

A compromised software update for a widely-used enterprise tool installs a backdoor DLL on 500 endpoints. The investigation must identify all affected systems, prove the malicious DLL's origin, reconstruct C2 communication patterns, and determine whether any data was exfiltrated — using hash catalogs, EDR telemetry, and proxy logs as primary evidence.

Key Technical Indicators

  • Evidence Sources: EDR file hash telemetry, software inventory/CMDB, proxy/DNS logs, NetFlow to C2 IPs, memory dump analysis
  • Hash Catalog: Known-good hash baseline for all enterprise software; automated integrity scanning
  • EDR Coverage: 100% endpoint coverage required; process injection and DLL load events captured
  • Proxy Logs: Full URL + SNI logging; DNS query logs with response data for C2 identification
  • Scope Assessment: Automated query across all endpoints for malicious hash indicators
  • Tool Integrity: Forensic tool hash catalog maintained; tool versions documented in case records

Scenario 7: OT/ICS Network Anomaly & Jump Host Audit

Operational Technology (OT) and Industrial Control System (ICS) environments present unique forensic challenges: limited logging capability on legacy PLCs and HMIs, strict change control requirements, and the potential for physical safety consequences from cyber incidents. Audit coverage must be achieved through network-layer telemetry and strict control of the jump host/bastion that provides IT-to-OT access.

OT/ICS Network Anomaly Monitoring
Figure 3.7: OT/ICS Security Monitoring — Industrial network engineer analyzing NetFlow anomalies between OT segments and reviewing bastion jump host session logs for unauthorized OT access

Scenario Description

Anomalous east-west traffic is detected between two isolated OT segments in a manufacturing facility. The investigation must determine whether the traffic represents a legitimate maintenance activity, a misconfiguration, or an active intrusion — using only network telemetry and jump host session records, as the PLCs themselves generate no audit logs.

Key Technical Indicators

  • Evidence Sources: NetFlow/IPFIX at OT segment boundaries, jump host full session recordings, industrial protocol logs (Modbus/DNP3), firewall ACL hit counters
  • Network TAP: Passive TAP sensors at OT segment boundaries; no active probing of OT devices
  • Jump Host Coverage: All IT-to-OT access exclusively via hardened bastion with MFA and session recording
  • Baseline Deviation: OT traffic baseline established; alerts on new protocol/destination combinations
  • Change Control: All OT configuration changes require approved change ticket; bastion session linked to ticket ID
  • Safety Boundary: Forensic collection must not impact OT availability; passive-only collection methods

Scenario 8: Regulatory Compliance Audit & Legal Hold Evidence Production

Regulatory compliance audits and legal proceedings require the production of evidence that meets strict admissibility standards: provable integrity, documented chain of custody, and verifiable authenticity. This scenario validates the entire evidence lifecycle — from collection through preservation, export, and presentation — ensuring that the platform can produce court-ready evidence packages on demand.

Compliance Audit Evidence Presentation
Figure 3.8: Compliance Audit Evidence Production — Compliance team presenting WORM storage proofs, signed evidence manifests, and chain-of-custody records to external auditors in a formal review session

Scenario Description

A financial services firm receives a regulatory examination request requiring production of all privileged access records, configuration change logs, and data access audit trails for a 90-day period. The evidence must be produced within 5 business days with full chain-of-custody documentation and cryptographic integrity proofs acceptable to the regulator.

Key Technical Indicators

  • Evidence Sources: WORM vault with object lock, signed manifests (SHA-256), chain-of-custody logs, export audit trail, retention policy documentation
  • Integrity Proof: SHA-256 hash of each evidence object; manifest signed with HSM-backed key; verification guide included in package
  • Export SLA: Evidence package production within 4 hours of authorized request; 5 business days for full regulatory response
  • Retention Compliance: Minimum 7 years for financial records; legal hold capability to extend beyond standard retention
  • Access Control: Evidence export requires dual approval; all export actions logged in immutable meta-audit
  • Format: Industry-standard formats (PCAP, JSON, CSV) with schema documentation; no proprietary formats

Scenario Selection Matrix

The following matrix maps each scenario to the required platform capabilities, enabling teams to prioritize implementation based on their most likely threat scenarios and compliance requirements. A checkmark indicates that the capability is mandatory for that scenario; a dash indicates it is optional but recommended.

Capability S1 Ransomware S2 Insider S3 Admin S4 WAF S5 Cloud IAM S6 Supply Chain S7 OT/ICS S8 Compliance
NTP Sync ≤1s✓✓✓✓✓✓✓✓
EDR Telemetry✓✓———✓——
Bastion/PAM Recording✓—✓———✓✓
Network Flow (NetFlow)✓———✓✓✓—
PCAP Capture✓——✓——✓—
Cloud Audit API—✓——✓——✓
WORM Evidence Vault✓✓✓✓✓✓✓✓
Config Version Tracking✓—✓———✓✓
DLP Integration—✓—✓————
Chain-of-Custody Workflow✓✓✓✓✓✓✓✓