Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
AWS Incident Detection and Response: Course Orientation
Module 0
AWS INCIDENT DETECTION AND RESPONSE · MODULE 00
No disk to image. No packet to capture. Just the logs, read well.
In AWS, the crime scene is the control plane, and the evidence is the API call the platform recorded. This course teaches you to take an account you have never seen, pull the right logs, and reconstruct exactly what an attacker did, from a leaked key through privilege escalation, persistence, and data theft, to full containment. This module shows you what you'll be able to do, the evidence you'll query, and how the course gets you there.
12 modules
across 6 phases
Real evidence
CloudTrail, GuardDuty, Flow Logs
Live queries
Athena SQL, results on the page
40 CPE
credits on completion
Why this course exists
When an AWS account is compromised, the habits from on-premises and endpoint work fail. There is no disk to image and no packet to capture. The resources are ephemeral by design, an instance that ran the attack may already be gone, and the only durable record of what happened is the evidence AWS itself logged: the API call in CloudTrail, the finding in GuardDuty, the connection in VPC Flow Logs, the configuration change in Config. The investigation is built entirely on reading those logs well, and most responders have never been taught to.
This course teaches exactly that, against the attacks that actually happen in AWS. A long-lived access key leaks in a public repository and is used from the other side of the world. An application is tricked into handing over the credentials of its instance role. A storage bucket is opened and emptied. A principal quietly rewrites a policy to grant itself admin, then plants a backdoor that survives a password reset. You take an unknown account, pull the right evidence, query it at scale, and reconstruct the whole chain from first access to impact, then contain it. The work runs against Northgate Engineering's AWS Organization, so the environment, the people, and the attacker stay consistent from the first query to the last.
What you will be able to do
This course is built around the intrusions you can reconstruct at the end, not the services you can name. Every module works real evidence from a real attack and makes you query it to an answer you can defend.
Read the AWS log sources
Know what CloudTrail, GuardDuty, VPC Flow Logs, Config, and S3 access logs each capture, what they miss, and how long they last.
Query evidence at scale
Run the SQL-over-CloudTrail workflow with Athena: filter, group, extract nested fields, and reconcile evidence across sources.
Investigate identity attacks
Read IAM, roles, and AssumeRole in CloudTrail, and detect and scope leaked-key use, anomalous role assumption, and MFA gaps.
Trace privesc, persistence, exfil
Follow IAM privilege-escalation paths, Lambda and EventBridge backdoors that survive a reset, and data leaving through S3.
Handle compute and evasion
Catch the SSRF-to-IMDS credential theft pattern, Lambda abuse, and cryptomining, and detect CloudTrail and GuardDuty tampering even when it partly works.
Contain and report
Isolate resources, revoke sessions and keys, preserve evidence with snapshots, run organization-level response, and write the incident report.
You also leave with things you keep: a containment runbook, reusable Athena queries for AWS evidence, and a full capstone investigation of a chained cloud incident, reconstructed end to end and written up as a report.
The evidence you will query
AWS records what happens to it, and that record is the case. The control plane logs every API call to CloudTrail, GuardDuty raises findings, VPC Flow Logs capture the connections, and Config tracks how resources changed. None of it is a disk or a packet, it is structured log data, and the investigation is a query problem: pull the right sources and read them well enough to rebuild the attacker's path. This course works that full surface, from the raw log sources to a reconstructed timeline and a report.
You query that evidence with Athena SQL, and every search runs on the page against real CloudTrail, GuardDuty, and VPC Flow Logs from Northgate Engineering's AWS Organization, with the attacks staged inside, so what you read is what a real engagement produces. The discipline is what carries: pull the right sources, query them at scale, reconcile across them, and reconstruct the timeline is how cloud incident response works on any provider, and the log-reading habit transfers to Azure and GCP investigation just as cleanly.
How the course is built
Twelve modules move through six phases. You ground the platform and the analysis surface you query, then work the attack chain in order, identity, persistence and data, compute and evasion, before the full response process and a capstone investigation.
What you need and who this is for
The AWS services and the query workflow are taught from first use, you do not need to be an AWS specialist to start. This course is for people doing security work who need to handle the cloud: SOC analysts and incident responders moving into AWS, cloud and DevSecOps engineers who own the environment, and detection engineers extending coverage past the endpoint and the SIEM. Comfort with security-investigation fundamentals and reading a basic query will help you move faster, but the AWS-specific knowledge is built up as you go.
Transferable cloud-IR discipline
Pull the right sources, query at scale, reconcile across them, reconstruct the timeline. The services are AWS; the discipline transfers to Azure and GCP investigation.
Nothing to set up
Every query runs on the page against real CloudTrail, GuardDuty, and Flow Logs. No AWS account to provision, no bill to watch, you investigate from Module 0.
How to get the most
Write each query yourself and predict the result before you run it. Save the queries that work, that is how your reusable AWS-evidence library gets built.
Do I already know this material?
Six quick scenarios across the full range of this course, from AWS log sources to cloud incident containment. Answer them to find out where you sit, and whether this course fits or it will sharpen knowledge you already have.
You need a record of who made which API calls in an AWS account during an incident. What is the primary source?
The EC2 instance system logs.
AWS CloudTrail, which records management API activity across the account, including who did what, when, and from where.
CloudTrail is the account's API audit log. Almost every control-plane action by a principal is recorded there with identity, time, and source, which makes it the backbone of AWS detection and investigation.
The billing console.
Route 53 query logs.
An attacker read objects from an S3 bucket, but CloudTrail shows nothing about the object reads. Why?
S3 object-level (data) events are not captured unless data event logging is explicitly enabled; by default CloudTrail records management events, not every object read.
CloudTrail logs management events by default, but high-volume data-plane activity like S3 GetObject is only recorded when data events are turned on. If you need to see object reads, that logging has to be enabled in advance.
CloudTrail never logs anything about S3.
The attacker deleted the logs.
S3 access is invisible by design.
Reviewing IAM, you find a role whose policy allows iam:PassRole together with broad permissions to launch compute. Why is this a privilege-escalation risk?
It is not a risk; PassRole is harmless.
PassRole only affects billing.
An attacker holding that role can pass a more privileged role to a service they launch and inherit its permissions, escalating beyond their own; PassRole combined with a launch permission is a classic AWS escalation path.
PassRole lets a principal hand a role to a service. Paired with the ability to launch compute, an attacker attaches a high-privilege role to something they start and inherits those permissions, climbing above their own access without ever touching IAM directly.
It only risks higher costs, nothing more.
An IAM access key suddenly makes API calls from an unfamiliar region and a new address, running reconnaissance calls the owning identity never normally makes. What is the strongest signal here?
The raw number of calls.
The deviation from the identity's normal pattern: a new region, a new source, and unusual API actions for that principal, which together indicate the key is compromised.
A valid key used abnormally is the classic sign of compromise. No single field is conclusive, but a principal suddenly operating from a new region and source and making out-of-character calls is a strong, correlated indicator that someone else holds the key.
The time of day only.
Which AWS service is being called.
During an incident you notice CloudTrail logging was stopped and a GuardDuty detector disabled shortly after initial access. How should a defender treat these events?
As routine administration.
As unrelated noise.
As proof the account is now safe.
As high-priority attacker defense evasion: disabling logging and detection is itself a strong incident signal, so those events and who made them are key evidence and should be alerted on.
Turning off logging and detection right after access is an attacker trying to go dark, not housekeeping. The disabling actions are themselves high-value detections, and the identity behind them is a prime lead in the investigation.
You confirm a compromised IAM role is being assumed by an attacker using stolen credentials. What is the right containment, with the least disruption?
Delete the entire AWS account.
Reboot all EC2 instances.
Revoke the role's active sessions and rotate or disable the compromised credentials, attaching a deny policy if needed, so the attacker's access is cut while workloads using other identities keep running.
Containment should sever the attacker's specific access, not the business. Revoking the role's sessions, rotating or disabling the credentials, and applying a targeted deny stops them while legitimate identities and workloads continue, preserving evidence and uptime.
Change the account root password only.
This course is for you.
You will build AWS detection and incident response from the log sources up through IAM attacks, credential compromise, data exfiltration, evasion, and cloud containment, on real AWS evidence.
You have the fundamentals. The value here is the harder half.
You know the log sources and IAM basics, so the payoff is the back half: privilege escalation and persistence, data exfiltration, compute compromise, defense evasion, and full cloud incident response.
You handled the audit sources, IAM escalation, credential-compromise signals, and cloud containment, the senior end of the discipline. Take the course to sharpen what you have, close the gaps you did not expect, and turn strong instincts into end-to-end cloud incident response.
You are a student of this course now, so start by deciding what you want from it. Are you here to be ready when your AWS account is the one compromised, to extend your investigation skills into the cloud, or to build a cloud incident-response capability from the ground up? Name that outcome, then turn it into a study plan: which attack phases matter most to your environment, how much time you will give it each week, and what you want to be able to investigate by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to see how AWS detection and response differ from on-premises and Microsoft 365 work, why the control plane is the crime scene, why cloud evidence is ephemeral and identity is the perimeter, the threats you will learn to catch, and the toolkit you will use. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
