GuardDuty Finding Investigation
Not a staged scenario. I pulled a genuinely recurring finding straight from the account’s own GuardDuty telemetry and worked through whether it was an attack, using the same reasoning process a SOC analyst would.
Finding 1 (real): root credentials invoking ListManagedNotificationEvents
Severity interpretation
LOW, but the count, 1,918 and climbing every few minutes at the time of review, means this is continuous, recurring activity, not a one off. A LOW severity number doesn’t mean “ignore it”; it means GuardDuty’s own confidence that this specific pattern indicates compromise is low. The question worth answering is which root activity this actually is.
Reasoning: true positive or false positive?
ListManagedNotificationEvents against notifications.amazonaws.com is the backend for the AWS Console’s notification bell. When a session signed in as root has the console open, that panel polls this API automatically in the background, producing exactly this signature: root credentials, a real source IP, a read only API, invoked continuously for as long as the tab stays open.
This isn’t a compromised credential: it’s a legitimate but risky practice (leaving a root authenticated console session open) that GuardDuty correctly surfaces. The fix isn’t incident response; it’s a process change: stop using root for day to day console access, and reserve it strictly for the handful of actions that require it.
What I’d check next in a real investigation: confirm via CloudTrail whether the source IP correlates with a known admin’s location; check root’s credential report for an active session rather than relying on inference alone; and if root usage is expected for a specific reason, scope a suppression rule narrowly to this API + service, not to all root credential findings, which would blind the account to genuine root misuse.
Finding 2 (sample): C&C domain query from EC2 instance i-99999999
One of GuardDuty’s built in sample findings, synthetic data (note the GeneratedFinding* placeholders throughout) used here for contrast, not as a genuine incident. Two things it demonstrates: the severity gap between this and the real LOW finding above shows what an actual “stop and act now” finding looks like, and this exact finding shape, HIGH severity, EC2 resource, is precisely what Lab 1’s automated quarantine pipeline is built to catch and act on without a human in the loop.
Evidence
This is a real finding pulled straight from the account, not staged. Root credentials invoking a notifications API, 1,918 times and still climbing. My first move wasn't to panic at the word 'root', it was to look at exactly which API was being called and from where.
I pulled up one of GuardDuty's built in HIGH severity sample findings for contrast, mainly to show the gap between what I was actually investigating and what a real stop everything finding looks like. This exact shape, HIGH severity against an EC2 instance, is what Lab 1's automation is built to catch.