Module 10 — Log & Cloud Forensics¶
Type 6 · Reconstruct — reconstruct the attack chain from the paper trail when the disk is gone: triage EVTX with Hayabusa and Chainsaw, then parse AWS CloudTrail to find the API-call sequence that preceded the account compromise. (Secondary: Tool-Build — make the CloudTrail parser an explicit reusable tool.) Go to the hands-on lab →
Last reviewed: 2026-06
Digital Forensics & IR — investigate from the paper trail when the disk is gone, the instance is terminated, and the only artifact is what the platform logged.
In 60 seconds
Cloud incidents often leave no disk — the instance terminated, the function was serverless — so
the log is the evidence. Hayabusa and Chainsaw apply Sigma rules straight to EVTX files,
triaging thousands of events into a severity-ranked timeline in seconds (Hayabusa for speed,
Chainsaw for field-level drilling). CloudTrail is a different model: it logs every API call, so
you trace a compromised credential forward through CreateUser/AssumeRole/AttachUserPolicy
to find the backdoor. The catch — logs only exist if they were enabled before the incident.
Why this matters¶
Cloud-native incidents often produce no disk image. Autoscaling instances terminate and their local storage vanishes; serverless functions leave no filesystem at all. What remains is the log: CloudTrail in AWS, the Unified Audit Log in Microsoft 365, VPC Flow Logs, and Windows Event Logs forwarded to a SIEM before the host was deprovisioned. A responder who can only work from disk images is stranded in a cloud incident. The practitioner who can reconstruct an attacker's actions entirely from log evidence — without ever touching the compromised system — is the one who can actually close cloud investigations.
On the Windows side, the public reference for what attacker activity looks like in the logs is
EVTX-ATTACK-SAMPLES — Samir Bousseaden's
corpus of real .evtx files captured while live attack techniques ran, filed by MITRE ATT&CK ID.
It's the de-facto test set the detection community runs Sigma rules against, which makes it the
ideal input for tools like Hayabusa and Chainsaw: point them at the T1078 (Valid Accounts) or
T1053 (Scheduled Task) samples and you see the real events those rules are written to catch,
not synthetic stand-ins. The lab leans on a slice of exactly this corpus.
Objective¶
Use Hayabusa to rapidly triage Windows Event Log (EVTX) files from the investigation, use Chainsaw for a complementary pass, and parse a set of simulated AWS CloudTrail events with a Python script to identify the sequence of API calls that preceded the developer account compromise.
The core idea¶
Windows Event Logs are rich and noisy in equal measure. A typical endpoint generates thousands of events per hour; an attacker generating a handful of authentication failures, a new scheduled task, and a process creation event is lost in that noise without a way to triage by severity. Hayabusa and Chainsaw solve this by applying Sigma rules directly to EVTX files — the same Sigma language from module 08, now running against the raw log source rather than a SIEM. Load an EVTX archive from a compromised host, run either tool, and within seconds you have a timeline of high-and-medium-severity events sorted by time, ready to pivot on.
The distinction between the two tools is worth understanding because they're often used in sequence. Hayabusa is built around a high-performance Sigma rule engine optimised for speed across large EVTX sets — it can process hundreds of thousands of events in seconds and produces clean columnar output or JSON. Chainsaw takes a heavier-weight approach: it also supports Sigma but adds its own detection grammar, and it provides structured search across log fields (find all events where SubjectUserName is "mfin\dev-svc01") that makes hypothesis-driven investigation faster when you already know what you're looking for. Running both against the same artifact costs little time and produces complementary coverage: Hayabusa for the initial triage heat map, Chainsaw for drilling into specific accounts or techniques.
Go deeper: why run both Hayabusa and Chainsaw
They're complementary, not redundant. Hayabusa is a high-performance Sigma engine optimized
for speed across huge EVTX sets — hundreds of thousands of events in seconds, clean columnar or
JSON output; use it for the initial triage heat map. Chainsaw supports Sigma too but adds
its own grammar and structured field search (SubjectUserName == "mfin\dev-svc01"), which makes
hypothesis-driven drilling faster once you know what you're hunting. Running both costs little
time and widens coverage.
Cloud forensics requires a different model entirely. CloudTrail is not a log of what happened on
a system — it's a log of what the API was asked to do. Every CreateUser, AttachUserPolicy,
AssumeRole, RunInstances, or GetCallerIdentity call is a row. An attacker who compromised
a developer IAM key and then pivoted to create a backdoor role left a complete sequential record
in CloudTrail, if you know how to read it. The investigation pattern is: find the initial API call
from the compromised credential, then trace forward in time to every action that principal took,
then look for any new principals it created or any roles it assumed. The attack graph is in the
event sequence — you're reconstructing a timeline of API calls, not filesystem operations.
The mental model
A host log records what happened on a machine; CloudTrail records what the API was asked to do. The attack graph is the event sequence — start at the first call from the compromised credential and trace forward through every action that principal took, every principal it created, every role it assumed. You reconstruct a timeline of API calls, not filesystem ops.
The gotcha
Log availability is not guaranteed — it's a planning decision made before the incident. AWS keeps CloudTrail management events 90 days in Event History by default, but data events (S3 GetObject, Lambda invocations) are off by default and must be explicitly enabled. If the trail wasn't configured (and forwarded to a tamper-evident archive), the evidence simply doesn't exist. "We'll just check CloudTrail" assumes someone turned it on.
AI caveat
CloudTrail JSON is well-suited to model analysis — consistent, documented schema — and a model can trace an event chain or group events into ATT&CK phases faster than grep. But it misses events needing operational context ("this account doing this is normal here") and sometimes hallucinates from event names without reading the field values. Verify every model-identified event against the raw JSON before citing it.
Learn (~3 hrs)¶
Hayabusa and Chainsaw (~1.5 hrs)
- Hayabusa GitHub — README — start here: the installation, rule sources, and output modes. Run hayabusa --help to see the full option surface; focus on the csv-timeline and json-timeline output modes.
- Chainsaw GitHub — README and documentation — covers Chainsaw's own grammar (chainsaw search) and Sigma integration (chainsaw hunt). The "Usage" section shows how to search for specific account activity.
- EVTX Attack Samples (GitHub) — a large repository of real Windows attack event logs, categorised by ATT&CK technique. Browse the T1078 (Valid Accounts) and T1053 (Scheduled Task) samples — these are the techniques active in this scenario.
AWS CloudTrail forensics (~1 hr)
- AWS CloudTrail — Log Event Reference — the field definitions: userIdentity, eventSource, eventName, sourceIPAddress, requestParameters. These are the fields you parse in the lab.
- AWS CloudTrail User Guide — Searching and Querying Events — official guide to interpreting CloudTrail for forensic investigation; covers privilege escalation and persistence event patterns.
Detection context (~0.5 hrs) - MITRE ATT&CK Cloud Matrix — the cloud-specific technique matrix; map the CloudTrail events you find in the lab to techniques here to understand what the attacker was doing.
Key concepts¶
- Hayabusa and Chainsaw apply Sigma rules directly to EVTX files, triaging thousands of events to a severity-ranked timeline in seconds
- Hayabusa: optimised for speed and volume; best for initial triage across large EVTX archives
- Chainsaw: structured field search + Sigma; best for hypothesis-driven investigation
- CloudTrail records API calls:
userIdentity,eventName,sourceIPAddress,requestParametersare the key investigation fields - Cloud forensics: trace compromised credentials forward through the event sequence to find lateral movement and persistence API calls
- Log availability is a planning decision: CloudTrail data events and VPC Flow Logs must be enabled before they're needed
- EVTX-ATTACK-SAMPLES is the public ATT&CK-tagged corpus of real Windows event logs to run Hayabusa/Chainsaw against — authentic events, not synthetic ones
AI acceleration¶
Hayabusa and Chainsaw produce structured JSON output that a model can reason about directly. Feed the timeline output to a model and ask it to group events by phase (Initial Access, Execution, Persistence, Lateral Movement) and identify the earliest evidence of each. Use this as a starting point for your own timeline, not as the timeline itself — models miss events that require operational context ("this account doing this action is expected in this environment") and sometimes hallucinate by extrapolating from the event names without reading the field values. CloudTrail JSON is particularly well-suited to model analysis: the JSON schema is consistent and well-documented, and the model can trace an event chain faster than grep. Verify every model-identified event against the raw JSON before citing it in the report.
Check yourself
- Why can a cloud incident leave you with no disk image at all, and what becomes your primary evidence instead?
- You have a compromised IAM key. Describe how you'd reconstruct the attacker's actions from CloudTrail.
- The team says "we'll check CloudTrail for the S3 data exfil." Why might that data simply not be there?
Comments
Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).