Detection in AWS

Here is the fact that flips the whole module: in AWS, every action is an API call, and CloudTrail records nearly all of them. When an attacker runs aws s3 ls or creates an access key or assumes a role, a JSON event lands in a log with their identity, their source IP, the exact API called, and whether it succeeded. The offense in the earlier lessons is loud by design. The defense is knowing how to read the noise.

CloudTrail is on by default for management events, and it keeps 90 days of history you can query without any setup. For real detection you create a trail that ships events to an S3 bucket and, ideally, to CloudWatch Logs so you can alarm on them. The single field that matters most in every event is eventName, the API call, paired with userIdentity and sourceIPAddress.

An event you should be able to read on sight looks like this, trimmed to what matters:

Read it out loud. The user deploy-bot created an access key for the user admin, from an IP that is not in your office range. That is the privesc from lesson two, caught in one event. A legitimate admin almost never does this, which is exactly why it makes a clean alarm.

GuardDuty does the pattern matching

You will not write every detection by hand. GuardDuty is Amazon's managed threat detector: turn it on and it reads CloudTrail, VPC Flow Logs, and DNS logs, then scores anomalies with no rules from you. It flags credential use from a Tor exit node, an EC2 instance talking to a known crypto-mining pool, and API calls from an IP that never appears for this account.

$aws guardduty list-findings --detector-id abcd1234

The finding type worth memorizing is InstanceCredentialExfiltration. It fires when credentials tied to an EC2 role, the ones you can pull from IMDS, get used from an IP outside AWS. That is the SSRF-to-metadata attack from lesson one, detected. GuardDuty catching it is the reason that attack is not free.

Know its limits too. GuardDuty is anomaly and threat-intel based, so a slow, quiet attacker using expected IPs and normal-looking calls can slide under it. It does not read the contents of your S3 objects, and it will not tell you a bucket policy is wrong. It catches behavior, not misconfiguration. Pair it with Config and Access Analyzer for the config side.

The detections that actually earn their keep map straight to the attack lessons. Alarm on CreateAccessKey and AttachUserPolicy because privesc runs through them. Alarm on StopLogging, DeleteTrail, and PutBucketPolicy on your log bucket because that is an attacker blinding you. Alarm on GetSecretValue spikes and on any use of the root account, which should be close to never. Build those five and you catch most of what the earlier lessons taught.