Reading width
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 Attack Classes: The Threats This Course Teaches You to Catch
The attacks in this course are not exotic. They are the handful of patterns that show up again and again in real AWS incidents, because they work and because the conditions that allow them are common. A key leaks in a public repository. A web app is tricked into surrendering the credentials of its instance role. A storage bucket is opened to the internet. A principal quietly grants itself more power and plants a way back in.
Knowing the shape of these patterns ahead of time is what lets you recognize one from a single early signal, instead of reconstructing it after the damage.
These few patterns dominate for a reason. Cloud environments fail in predictable ways: credentials end up where they should not be, permissions are broader than anyone intended, and storage is exposed by a configuration nobody reviewed. Attackers know this, so they reach for the techniques that exploit those common failures rather than novel ones. That is good news for a defender, because it means a focused set of detection skills covers most of what you will actually face.
The course concentrates on these patterns precisely because mastering them gives you the widest real-world coverage for the effort, and because the investigative habits they teach, following identity, reading the chain, checking the evidence, transfer to whatever variant you meet next.
The shape of an AWS attack
Most AWS intrusions move through the same stages, and the MITRE ATT&CK for Cloud framework gives them names that the wider field shares. An attacker gets a credential and uses it (initial access), looks around to learn what it can reach (discovery), grants itself more power (privilege escalation), arranges to keep its access (persistence), takes what it came for (collection and exfiltration), and sometimes tries to blind the defender along the way (defense evasion).
You do not need to memorize the framework. You need to recognize that a single finding is usually one stage of something longer, and that your job is to place it in the chain.
A typical AWS intrusion is a chain, not an event. A finding partway along is a thread to pull in both directions: what came before it, and what came after.
Each stage tends to leave its trace in a particular source, which is why knowing the chain tells you where to look. Initial access and the role assumptions that follow it are management events in CloudTrail. Discovery is a burst of read-only List and Describe calls, also in CloudTrail. Exfiltration may show as data events on a bucket or as outbound connections in VPC Flow Logs.
The blinding attempts of defense evasion are management events too, the calls that stop a trail or disable a detector. GuardDuty sits across the top, turning some of these into findings automatically. When you can name the stage you are looking at, you can name the source most likely to hold the evidence for the stages on either side of it, and that is most of what makes an investigation efficient rather than a fishing trip.
The stages also rarely arrive labeled; part of the skill the course builds is recognizing, from the shape of the activity in front of you, which stage you are seeing, so you know whether to look upstream for the foothold or downstream for the damage.
The classes you will learn to catch
Credential compromise. A long-lived access key leaks, or a session is stolen, and an attacker uses it from a place and at a time the real owner never would. This is initial access through valid cloud accounts (MITRE ATT&CK T1078.004), often visible first as activity from an unused region (T1535) or a sudden burst of enumeration as the attacker maps what the credential can reach (T1580, T1087.004).
The signal you learn to catch is the mismatch: an AKIA key that has only ever called a handful of APIs from one IP suddenly calling ListBuckets, ListUsers, and GetAccountAuthorizationDetails from an address and region with no history. It is all in CloudTrail, in the identity and source fields you met in AWS0.5. Modules 4 and 5 build the identity foundation and then teach you to detect the leaked key, the anomalous role assumption, and the new-IP, new-region signals that give it away, including the cluster of AccessDenied results that marks an attacker probing the edges of what a stolen credential allows.
Here the leaked m.chen-dev key, now driven from an external address, tries to dump the whole account's IAM configuration and is refused. One such denial is noise; a burst of them from a credential that has never made these calls is the discovery phase happening in front of you. The errorCode of AccessDenied is doing useful work, because failed enumeration is often louder than success: it shows you what the attacker was reaching for and did not yet have.
Privilege escalation and persistence. A foothold with limited rights is not the goal; the attacker wants more power and a way to keep it. They find an over-permissive role to assume, or rewrite a policy to grant themselves administrative access, then arrange to survive a cleanup by creating a second access key on another user (Additional Cloud Credentials, T1098.001) or planting a Lambda function that re-creates their access after you remove it.
The signals are specific management calls in the wrong context: AttachUserPolicy or PutUserPolicy granting broad permissions, CreateAccessKey on a user that already has one, CreateUser for an account nobody requested. Module 6 teaches the IAM escalation paths and the backdoors that outlive a password reset, which is why containment that only resets the obvious credential fails and the attacker is back an hour later.
S3 and data exfiltration. Storage is usually the target. The attacker enumerates buckets, finds one exposed or reachable with the credential they hold, and reads its contents (Data from Cloud Storage, T1530), sometimes copying it into a bucket in their own account to blend with normal API traffic (Transfer Data to Cloud Account, T1537). Some campaigns end in extortion, deleting or encrypting the data and demanding payment.
The detection problem here is sharper than elsewhere: the management events that show a bucket being made public or its policy changed are always logged, but proving which objects were actually read depends entirely on whether S3 data events were enabled before the incident. Module 7 teaches how to detect the exposure, scope what was accessed, and state your findings honestly when the data-plane evidence is missing.
Compute compromise through the metadata service. A web application with a server-side request forgery flaw can be coerced into requesting its own instance metadata, and the metadata service will hand back the temporary credentials of the role attached to that instance (Cloud Instance Metadata API, T1552.005). The attacker now holds the instance's permissions without ever logging into the instance. This is the pattern behind the 2019 Capital One breach, in which an attacker reached the metadata service of a misconfigured component, obtained a role's credentials, and used them to read large volumes of data from S3, a case that remains the textbook example of why this technique matters.
The tell that catches it is instance-role credentials, the ASIA keys tied to a service role, being used from an IP address outside AWS, because a real instance role is only ever used from inside the instance. Module 8 teaches you to spot exactly that pattern.
Defense evasion and anti-forensics. A capable attacker tries to blind you, stopping a CloudTrail trail, deleting it, or disabling GuardDuty so their later actions go unrecorded (Disable or Modify Cloud Logs, T1562.008). The saving grace, covered in AWS0.3, is that the act of disabling logging is itself a loud, logged management event, a StopLogging or DeleteTrail that lands in the record before the lights go out, and in a well-run organization the trail already shipped its earlier records to an account the attacker cannot reach.
Module 9 teaches you to detect the blinding attempt, read the gap it creates as evidence in itself, and work with the partial record it leaves behind.
These are not five separate courses. In a real incident they chain, and the opening Northgate case threads through most of them: a developer's key leaks, the attacker uses it from an unfamiliar location, enumerates what it can reach, assumes a more powerful role across the account boundary, creates a second access key so a password reset will not lock them out, and finally reads data out of a bucket.
One investigation, several classes, one connected story. That is why the course teaches them in sequence rather than in isolation, and why the recurring discipline is to treat any single finding as a link in a chain you trace in both directions. By the capstone you are working a full incident that touches all of them at once, the way the job actually arrives.
What a detector hands you, and what it does not
It helps to be clear about what GuardDuty is before you lean on it. It is a managed detection service that watches CloudTrail, VPC Flow Logs, DNS, and other signals, and raises findings when its logic, a mix of threat intelligence, known-bad indicators, and machine-learning anomaly detection, sees something suspicious. It is genuinely useful and it is also finite. It catches the patterns it was built to catch and misses the ones it was not, it can be slow to learn what is normal in a new environment, and a sophisticated attacker may operate deliberately below its thresholds.
So you treat its findings as high-quality leads rather than the boundary of the incident: every finding is worth investigating, and the absence of a finding never proves the absence of an attack. The analyst who hunts only where GuardDuty points is an analyst who sees only what it was designed to show.
When one of these attacks does trip a detector, you often meet it first as a GuardDuty finding. Here is one from the compute-compromise class: instance-role credentials being used from outside AWS.
This is a strong lead. It names the role whose credentials were stolen, the API they were used to call, and the external IP that used them, at high severity. It is also not the whole story. It does not tell you how the credentials were stolen, what else the attacker did with them, or whether they still hold access.
What it does is give you threads to pull, and naming them is the difference between triaging a finding and working an incident.
The access key becomes a search for every call it made, in time order, across every account. The external IP becomes a second search for whatever else arrived from it.
The timestamp anchors a window you widen in both directions, and the role name tells you what the credential was permitted to do, which bounds the worst case before you have confirmed anything.
None of that is in the finding itself; all of it is reachable from the fields the finding hands you. The finding is the start of an investigation, not its conclusion, and the rest of the course is about everything that comes after this card appears.
Anti-Pattern
Closing the finding instead of pulling the thread.
Treating each finding as a self-contained event: confirm it, remediate the one thing it names, mark it resolved. Almost every attack above is a chain, and a finding is one visible link. Resolve only that link and the attacker keeps the access the finding never mentioned, the backdoor key, the assumed role, the persistence in another account. The habit to build is to treat every finding as a question about what came before and after it.
You now have the mental model: the control plane is the evidence, resources are ephemeral, identity is the perimeter, and the threats are chains you trace through the log. AWS0.7 turns to the practical side, the toolkit you investigate with and the Northgate environment and cast you will follow through every one of these attacks.