AWS Builder Center

Builder Center

Reading GuardDuty Findings Like a SOC Analyst: A Beginner's Triage Workflow with CloudTrail

Reading GuardDuty Findings Like a SOC Analyst: A Beginner's Triage Workflow with CloudTrail

How to go from a GuardDuty alert to a confident decision: read the finding, pivot into CloudTrail to see what the identity actually did, contain the problem, and fix the root cause. A practical triage workflow for students and first-time builders.

Kushan Rathnayake

I'm a student at ECU Sri Lanka Campus.
Turning on Amazon GuardDuty is the easy part. The harder part is the first time a finding shows up and you have to decide whether it is a real incident or noise. This article walks through a simple, repeatable triage workflow that combines GuardDuty with AWS CloudTrail, the same pattern a SOC analyst follows.

How to read a finding

GuardDuty finding names follow a consistent structure:
ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact
Take UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS as an example:
  • ThreatPurpose (UnauthorizedAccess): what the attacker is trying to do.
  • ResourceTypeAffected (IAMUser): what is involved. Here, credentials.
  • ThreatFamilyName and DetectionMechanism: the specific behavior, here credentials from an EC2 instance being used from outside AWS.
Other purposes you will see often include Recon, Persistence, Stealth, CryptoCurrency, Policy, and Trojan. Reading the name first tells you what kind of problem you are dealing with before you open a single detail.

Practice safely with sample findings

You do not need a real attack to learn this. In the GuardDuty console, go to Settings and choose Generate sample findings. Sample findings are prefixed with [SAMPLE], so they are easy to tell apart from real ones. Use them to get familiar with the console layout before it matters.

The triage workflow

1. Start with severity and scope

Each finding has a severity score. Start with the highest, then ask: which resource, which principal (user, role, or access key), which Region, and when did it first and last occur? A finding that repeats many times over several days is a different situation from a single event.

2. Pivot into CloudTrail

The finding tells you something looks wrong. CloudTrail tells you what the identity actually did. Take the access key ID or role name from the finding and look up its activity:
1
2
3
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<access-key-id> \
--max-results 50
In each event, focus on these fields:
  • eventName and eventSource: what was called, on which service
  • userIdentity: who or what made the call
  • sourceIPAddress and userAgent: where it came from and with what tool
  • awsRegion: unexpected Regions are a red flag
  • errorCode: a run of AccessDenied often means someone is probing for permissions
Event history only covers the last 90 days of management events. For older data, or to query at scale, send CloudTrail logs to S3 and query them with Athena.

3. Decide: false positive or real?

Questions to answer before acting:
  • Does the source IP belong to you, your VPN, or a known service?
  • Is the activity consistent with what this identity normally does?
  • Did it start with recon (ListUsers, ListBuckets, GetCallerIdentity) and then move to changes?
  • Were any defenses touched, such as StopLogging or DeleteTrail?
If the activity matches a known tool or a teammate's work, document it and, where appropriate, add a suppression rule. If not, treat it as real.

4. Contain first, investigate second

Stop the damage before digging deeper:
  • Leaked access key: set it to inactive instead of deleting it, so you keep the evidence.
1
2
3
4
aws iam update-access-key \
--access-key-id <access-key-id> \
--user-name <user-name> \
--status Inactive
  • Compromised role: revoke active sessions from the IAM console so existing temporary credentials stop working.
  • Compromised EC2 instance: move it to a quarantine security group with no inbound or outbound rules, and snapshot the volume for later analysis.

5. Fix the root cause

Containment is not remediation. Work out how the problem started, such as a key committed to a public repository, an over-permissive role, or an exposed port. Then rotate credentials, tighten the policy, and close the gap. Check CloudTrail for anything the attacker created along the way, like new users, access keys, or roles.

6. Write it down

Even for a learning account, keep a short note: what fired, what you found, what you did, and what you changed. This habit is what separates a lucky fix from a repeatable process.

Quick reference

StepQuestionTool
ReadWhat kind of threat is this?Finding name and severity
ScopeWhich identity, resource, and Region?GuardDuty finding details
InvestigateWhat did it actually do?CloudTrail lookup or Athena
ContainHow do I stop it now?IAM, security groups
RemediateWhy did it happen?Policies, key rotation
DocumentWhat do I do better next time?Your notes

Final thoughts

You do not need years of experience to triage a finding. You need a consistent process: read the name, check the scope, confirm in CloudTrail, contain, fix the cause, and write it down. Start with sample findings and the process will be familiar by the time a real one appears.
What is the most useful CloudTrail field in your investigations? Share it in the comments.
# security# amazon-guardduty# aws-cloudtrail# beginner-projects# incident-response
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article