Advanced CloudTrail analysis and custom detection engineering
Prerequisites: CloudTrail basicsAdvanced threat detection requires writing custom rules that catch sophisticated, slow-and-low attacker behaviors. Basic search filters miss multi-stage attacks because attackers deliberately spread their actions over time and across multiple services to avoid triggering simple thresholds. Detection engineering is the discipline of creating and maintaining these detection rules.
Key Detection Patterns: Anomalous behavior detection focuses on finding the needle in a haystack of millions of benign API calls. This involves analyzing rare API calls, unusual timing patterns (e.g., administrative actions at 3 AM), geographic anomalies (logins from countries where the company has no presence), and user agent mismatches (automated tools trying to blend in as standard AWS SDKs). API recon patterns detect initial discovery phases through rapid bursts of Describe* and List* API calls from a single IP address, which indicates an attacker mapping your environment.
Alert Tuning: Reducing false positives is critical for effective detection engineering. You should correlate multiple indicators before triggering an alert: unusual API sequence + new source IP + rare user agent + off-hours timing. Each individual indicator might be benign, but the combination provides high-confidence threat detection.
What pattern in CloudTrail logs might indicate an attacker performing initial reconnaissance?
What technique do attackers use to evade detection by blending their automated tools into normal traffic?
In an Athena SQL query analyzing CloudTrail, which fields would you group by to detect an attacker performing recon from a new IP?
What is the purpose of alert tuning in detection engineering?
Active threat hunting, lateral movement detection, and VPC network analysis
Prerequisites: VPC Networking and IAM Role delegationLateral movement is the progression from an initial entry point (like a compromised web application) to high-value internal assets (like databases, administrative interfaces, or data lakes). In traditional on-premises environments, lateral movement often involves moving from one workstation to another. In the cloud, it typically involves moving between services, accounts, and VPCs.
VPC Peering & Transit Gateways: Attackers abuse trusted routes established through VPC peering connections or transit gateways. Once they compromise a resource in one VPC (e.g., a web server in a staging VPC), they look for peering connections to other VPCs. A staging VPC that has a peering connection to a production VPC is a common lateral movement path. VPC Flow Logs are the primary detection mechanism — they capture metadata about every IP traffic flow, including source, destination, port, protocol, and whether the traffic was accepted or rejected.
Role Assumption Chain: In AWS, attackers can chain multiple IAM role assumptions to move across accounts. A compromised role in Account A can assume a role in Account B if the trust policy allows it, then assume another role in Account C from there. Detecting this requires tracking the chain of AssumeRole API calls in CloudTrail and identifying unusual cross-account access patterns.
What is the primary detection mechanism for identifying lateral movement through VPC peering connections?
How do attackers typically chain IAM role assumptions to move across AWS accounts?
What would you look for in VPC Flow Logs to detect potential lateral movement?
What should you do when you detect unauthorized lateral movement through a VPC peering connection?
EC2 post-exploit investigation, evidence preservation, and artifact analysis
Prerequisites: Linux command line, OS structuresCloud forensics requires special techniques because cloud instances are ephemeral — they can be terminated and lost forever. The first rule of cloud forensics is "preserve before you investigate." Never shut down a compromised instance, because shutting down clears volatile memory (RAM) which may contain running processes, active network connections, and encryption keys. Instead, isolate the instance using a security group that denies all traffic (except your forensic workstation), then capture forensic artifacts.
Key Artifacts to Examine: Bash history (.bash_history) reveals every command the attacker ran, including privilege escalation attempts and data exfiltration commands. Cron jobs at /etc/cron.* and /var/spool/cron/ reveal persistence mechanisms — attackers commonly install reverse shells that run every few minutes to reconnect if disconnected. System logs at /var/log/auth.log or /var/log/secure show login attempts and authentication anomalies. Web server access logs reveal the initial exploitation vector (e.g., a suspicious POST request to a vulnerable endpoint).
Evidence Preservation: Take an EBS snapshot of all volumes attached to the compromised instance. Store the snapshot in a secure forensics account that the attacker cannot access. If possible, capture the instance's RAM using tools like LiME (Linux Memory Extractor) before isolating the instance. Document the chain of custody — who collected the evidence, when, and how.
What is the FIRST thing you should do when you detect a compromised EC2 instance?
Where would you look on a Linux system to find evidence of a reverse shell persistence mechanism?
What forensic artifact in Linux reveals the commands run by an attacker on a compromised system?
Why should you take an EBS snapshot rather than shutting down a compromised instance?
Design modern Zero-Trust architectures, micro-segmentation, and JIT access
Prerequisites: Basic network and identity architectureZero-Trust is a security framework based on the philosophy "Never Trust, Always Verify." No entity — whether a user, device, or service — is trusted by default, even if it is already inside the network perimeter. This is a fundamental shift from the traditional "castle-and-moat" model where everything inside the network was trusted. In the cloud era, where perimeters are fluid and employees work from anywhere, Zero-Trust is essential.
Core Principles: Micro-segmentation breaks networks into tiny, isolated zones so that even if an attacker compromises one segment, they cannot move laterally to others. Just-In-Time (JIT) Access grants highly privileged access only for the exact duration of a specific task, then automatically revokes it — no standing permissions. Non-Human Identity (NHI) Security audits and manages credentials used by service accounts, APIs, and automated scripts, which are frequently overlooked in traditional security programs. Assume Breach means designing your architecture as if attackers are already inside your network, limiting the blast radius of any single compromise.
What is the core philosophy of Zero-Trust security?
What is Just-In-Time (JIT) Access in a Zero-Trust architecture?
What does "Assume Breach" mean in a Zero-Trust context?
How does micro-segmentation prevent lateral movement?
Comprehensive incident response — detect, contain, investigate, and remediate
Prerequisites: Rooms 1-4This capstone brings together detection engineering, lateral movement analysis, forensics, and Zero-Trust architecture into a single incident response scenario. In a real-world cloud security incident, all these disciplines work together: detection engineering identifies the anomaly, forensic analysis determines the scope and method of compromise, lateral movement analysis traces the attacker's path, and Zero-Trust principles guide the remediation strategy.
The Incident Response Lifecycle: Preparation (having tools, runbooks, and trained personnel ready before an incident occurs), Detection & Analysis (identifying suspicious activity through monitoring tools and log analysis), Containment (stopping the attack and preventing further damage), Eradication (removing the attacker's access and persistence mechanisms), Recovery (restoring normal operations), and Post-Incident Activity (documenting lessons learned and improving defenses).
Key Takeaway: Effective cloud incident response requires understanding how attackers chain multiple techniques across IAM, networking, compute, and storage services. Each detection and response action must consider the interconnected nature of cloud environments.
During an incident investigation, you find an attacker exfiltrating data from an S3 bucket. What is your FIRST containment action?
What is the correct order of the incident response phases?
After containing an incident and restoring operations, what is the MOST important remaining step?
How does understanding Zero-Trust architecture principles improve incident response?