0.1 What This Course Teaches

Introduction

This course teaches you to investigate, detect and respond to attacks in AWS, using the evidence AWS itself records. It is built around one organization, Northgate Engineering, and one record of its AWS accounts covering five weeks, in which ordinary work and six attacks sit side by side as they would in a real environment.

You will learn to query that record with SQL, the language of Amazon Athena, the service most AWS investigators use to read logs at scale. Then you will use it to reconstruct each attack from first access to impact, write detections that would have caught them sooner, and make the decisions a response requires.

This lesson sets out what the course covers, introduces Northgate and its record, explains how each lesson works and what you will do in each, and describes the Project that closes the course. Nothing in it assumes you have worked in AWS before.

The course is for anyone who wants to learn this work: analysts moving into cloud investigation, engineers who run AWS and want to know what an attacker's work looks like in it, and investigators from other platforms who need AWS's evidence explained in its own terms. Every AWS service, field and term is explained when it first appears, and the SQL starts from a single SELECT.

The figure is the course's order, which is the order of the work in a real organization, and the band beneath it is what ties the parts together. Readiness comes first because an investigation can only read what was recorded.

Querying comes next because every later skill depends on it. Investigation, detection and response follow, each building on the last, and the Project asks you to apply all of it to an account of your own.

The course has ten teaching modules after this one, each built around a kind of work or a kind of attack. The record below lists them in order.

Modules 1 to 3 teach the querying every later module relies on: how CloudTrail's records reach Athena, how to filter, parse and aggregate them, and how to follow an identity across sessions and accounts.

Modules 4 to 8 each investigate one family of attack as it appears in AWS's records: stolen credentials, escalation and persistence in IAM, theft and ransom of S3 data, compromise of instances and functions, and attempts to blind the defenders. Module 9 turns those investigations into detections, tested and specified. Module 10 makes the response decisions, one judgment per lesson, from declaring the incident to closing its review.

Every module investigates the same organization and the same period, deliberately, so a fact established in one is evidence in the next. The key that leaks in Module 4 is the key whose misuse Module 9 detects and Module 10 contains, and the gap Module 0's audit finds in AWS Config's recording is the one Module 10 runs into when it restores the backup bucket.

Reading the modules in order shows how one incident's evidence connects to another's; reading them out of order still works, because each module introduces what it needs.

Each module, from 1 to 10, ends with a summary, a knowledge check of eight scenarios built from real mistakes, and a challenge set of questions no lesson answers. The order matters more in the early modules than the later ones: Modules 1 to 3 are the foundation, and Modules 4 to 8 can be read in any order once they are in place.

The course is also built to a standard of evidence that matters for the work. Every number a lesson states is produced by a query over the record, and the query is on the page.

Every product behavior, API and console path the course describes was checked against AWS's documentation on a recorded date. Where the record cannot settle a question, the lesson says so rather than filling the gap with a guess. You will be asked to hold your own investigations to the same standard.

Every lesson investigates the same organization, so that what you learn in one module is evidence in the next. Northgate is fictional, but its record is built carefully to behave as AWS's records do, with the same fields, the same formats and the same quirks, so the queries you write here work unchanged against a real account.

Northgate Engineering is an engineering firm of about 800 people whose customer portal, data and build systems run on AWS. It runs four AWS accounts in one AWS Organization. The management account holds the organization itself, its single sign-on through IAM Identity Center and the organization trail that records every account.

The security account holds the log archive and runs detection for everyone. Prod runs the customer portal, its data and its backups; dev runs the build pipeline and developers' work. Most activity is in London, eu-west-2, Northgate's home Region, and the few calls elsewhere are, as the course will show, worth reading.

SELECT recipientaccountid AS account, count(*) AS events
FROM cloudtrail_logs
GROUP BY 1
ORDER BY 1

That number, 11,481, is a claim about the record, and the course treats every such claim the same way.

SELECT recipientaccountid, count(*)
FROM cloudtrail_logs
GROUP BY 1

The gate is the course's rule for numbers, and it applies to every lesson from here to the Project. The four accounts differ in how much they record, and the difference tells you what each is for.

Prod is busiest because its applications work all day, every day; management is second because every person's sign-in starts there; the security account barely appears, because its job is to read other accounts' records, not to change anything. An investigator who knows what normal looks like in each account can see what does not belong.

Its people work the way people in most organizations on AWS do. They sign in through Identity Center with permission sets, mostly from the office or home.

A few older IAM users with long-term access keys remain from before Identity Center, for a CI pipeline, a backup job and one developer, and as you will see, that is where much of the trouble starts. Applications run on EC2 instances and Lambda functions with roles of their own. None of this is unusual, which is the point.

The record is the course's evidence, and it is much larger than one log. The query counts the records in each of its ten tables.

SELECT 'cloudtrail_logs' AS source, count(*) AS records FROM cloudtrail_logs
UNION ALL SELECT 'cloudtrail_network_activity', count(*) FROM cloudtrail_network_activity
UNION ALL SELECT 'vpc_flow_logs', count(*) FROM vpc_flow_logs
UNION ALL SELECT 'route53_resolver_logs', count(*) FROM route53_resolver_logs
UNION ALL SELECT 'alb_access_logs', count(*) FROM alb_access_logs
UNION ALL SELECT 's3_access_logs', count(*) FROM s3_access_logs
UNION ALL SELECT 'guardduty_findings', count(*) FROM guardduty_findings
UNION ALL SELECT 'securityhub_findings_asff', count(*) FROM securityhub_findings_asff
UNION ALL SELECT 'securityhub_findings_ocsf', count(*) FROM securityhub_findings_ocsf
UNION ALL SELECT 'awsconfig (items)', count(*) FROM awsconfig CROSS JOIN UNNEST(configurationitems) AS t(ci)

Ten tables, each a source an AWS organization can turn on, and each with its own shape. CloudTrail records API calls, the core of almost every investigation, with network activity events for calls through the prod VPC's endpoints. VPC flow logs record network connections, and the resolver logs the names instances looked up.

The load balancer's logs record requests to the customer portal; S3's access logs record requests to buckets. GuardDuty and Security Hub hold the findings AWS's own detection raised, and AWS Config holds the history of how resources were configured. Which of them an organization has turned on, and for how long it keeps them, is the subject of the rest of this module.

Not every organization has all ten sources, or anything close. Many have CloudTrail's management events and little else, because those are on by default and everything else has to be chosen, configured and paid for.

Northgate has more than most, and still not everything an investigation would want, which is exactly what this module's audits measure. An investigator's first question in any real incident is which of these sources exist for the accounts and the period in question, because the answer decides which questions can be answered at all.

The record covers a single fixed period, and every number in the course is measured inside it. The query reads the first and last event, the days and the Regions.

SELECT min(eventtime) AS first_event, max(eventtime) AS last_event,
  count(DISTINCT substr(eventtime, 1, 10)) AS days,
  count(DISTINCT awsregion) AS regions
FROM cloudtrail_logs

Thirty-eight days, from midday on 14 April to the morning of 21 May, in seven Regions, the first and last events in the record. Most of those days are ordinary, and that is deliberate: applications reading and writing data, the CI pipeline building, backups running at one in the morning, people signing in to do their jobs.

The attacks the course investigates are a small fraction of the events, fewer than two hundred CloudTrail events among more than twenty-three thousand, hidden among the rest, which is how attacks appear in real records and why the course spends so much time on telling the two apart.

The period also fixes, firmly, what the course can and cannot say. Anything before 14 April is outside the record, so a question about how a key first leaked, or whether an attacker was present earlier, has to be answered from other evidence or left open. The course is careful about that boundary throughout, and you will see lessons say plainly when the record cannot settle something.

Five weeks of one organization is also a fair size for learning. It is small enough that a query over the whole period returns in a moment and its result can be read line by line, and large enough that patterns are real: a backup job that runs every night, a pipeline that runs every working day, a few people whose work looks unusual and is not.

Learning to see those patterns is most of what makes an attack stand out.

Every lesson in the course has the same shape, so you always know where you are, and so you can tell at a glance how much of a lesson remains.

A lesson opens with an introduction and a figure that shows its subject at a glance. Seven or eight sections follow, each teaching one idea through something you can look at: a query to run, a record to read, a configuration to audit, a console path, or a procedure.

Queries come with a question to predict before you run them, with three possible answers, because guessing first and checking second is how the shape of the data becomes familiar.

Most lessons include three exercises in an in-page SQL workspace, completing, fixing and writing a query, each checked against the record. A procedure near the end gathers the lesson's method into steps you can reuse, and a Practice set closes the lesson with three values you find yourself.

The procedure above is the one you will follow in every lesson from Module 1 on. Module 0 is different: its lessons are audits of real configuration, and its last step is an assessment rather than a number.

The workspace that runs the queries in each lesson is a full SQL engine in your browser, built to behave as Athena does on these tables, so a query that works here works in Athena against a real organization's logs. Nothing you run can change the record; you can experiment freely, and a query that returns something unexpected is a reason to look closer, not a mistake to undo.

The figures and records in each lesson are not decoration, and they repay attention. A figure shows how the parts of a subject connect; a record holds one object's facts the way a console or an API returns them; a procedure gathers a method you can take to your own work. Each is placed where the prose needs it and explained before and after, never left to speak for itself.

You will also meet the record's limits as you go, module by module, and they are part of the lesson. A field AWS leaves empty, a source that records one thing and not another, a delay between an event and its delivery: each shapes what an investigation can conclude, and the lessons point them out where they matter rather than hiding them.

The record holds six attacks, each the subject of a module, and an undecided case the course leaves deliberately open.

The attacks are realistic in one more way: they are not tidy. One attacker reuses another's guessed password; another tries to stop the logging and is refused; one case looks like an attack and cannot be proven either way.

You do not need to know them yet; each module introduces its own from the first evidence an investigator would see. They are listed here so the course's direction is clear. They are also why Module 0 audits what it does: every gap you find in Northgate's configuration in this module is one an attacker in the record takes advantage of, and Module 10's review closes it.

The undecided case deserves a short word of its own, because it is unusual in a training course. Most training resolves every question it raises. Real investigations do not: some events fit an innocent explanation and an attack equally, and the record cannot choose.

The course keeps that case open on purpose, so you learn to say what the evidence supports and stop there, which is the hardest discipline in investigation and the one most often skipped.

Read the list as a map of the course rather than a summary of it. Each line is a module's starting point, and each module begins where an investigator would: with a finding, an alert or a question from someone who noticed something, not with the answer.

Investigation is the course's core, and two later modules turn it into action. They are where the course stops asking what happened and starts asking what should be done about it, which is the question an organization actually pays an investigator to answer.

Module 9 asks what an organization should have been told, and when, which is a different question from what happened. It reads GuardDuty's findings as an analyst would on the day, triages them, and then writes detections of Northgate's own from the queries the investigations used, tests them against the incidents and the ordinary weeks, tunes the noisy ones and writes one up as a specification another analyst could maintain.

Module 10 asks what to do next, and its lessons are judgments: a proposal that sounds right, the positions a responder could take, and where each leads. You commit to an answer in writing before you read the resolution, because response is a sequence of decisions under uncertainty and reading other people's answers does not train you to make them.

Both are ways of practicing what the course teaches, rather than of reading about it. A detection you have written and tested, or a decision you have committed to and then measured against the record, stays with you in a way a summary does not.

Neither module asks you to memorize anything at all, ever. The finding types, the API names and the console paths are all in the lessons and in the reference modules at the end of the course, and you will look them up as working investigators do. What the course trains is the judgment that decides which to look up, and the habit of checking each answer against the record.

Judgments are also where the course is most honest about uncertainty, by design. Each one names the position it considers right and explains why the others fall short, but the scoring criteria reward a well-reasoned answer, not a matching letter, because in real response two good responders can reach different calls for defensible reasons.

The course closes with a Project, which applies what you learned to something that is yours. It is optional in the sense that nothing gates it, and essential in the sense that it is where the course's skills become yours.

The Project has three parts, each with a test of when it is done, so you know when you have finished rather than guessing. A readiness assessment of an AWS account, your own if you have one or Northgate's if you do not, made with the audits of this module.

Five detections with their specifications, tested against the record as Module 9 tests them. And one investigation report on a prepared case, a new incident none of the modules teaches, written to Module 10's standard. Completing it is the evidence that you can do the work, rather than recognize it.

If you have an AWS account of your own, the course's lab setup module shows how to turn on the sources this course reads, cheaply and safely, and how to generate evidence to investigate without attacking anything.

If you do not, everything in the course and the Project can be done on Northgate's record alone. Either way, the reference modules at the end gather the queries, consoles and policies the course uses, so they are close at hand when you need them in your own work.

Practice

Three questions about the record. They need only a count; Module 1 explains every part of the queries you will write.

Next, 0.2 How Investigation Works in AWS explains why AWS evidence is API calls, sessions and identities, and what that means for every investigation in the course.