Right, so GuardDuty has found something. Don’t panic. It’s probably fine. Or it’s a crypto-miner running on your production database instance. One of the two. The real trick isn’t just seeing the alert; it’s knowing what to do with it. GuardDuty is like that brilliant, slightly paranoid friend who notices every unlocked door in the neighborhood. It’s on you to decide which ones actually need a deadbolt.

GuardDuty’s findings are its core currency. They’re not just raw logs; they’re intelligent inferences based on multiple data sources—VPC Flow Logs, DNS queries, and CloudTrail management events. It’s connecting dots you didn’t even know were on the page.

Severity Levels: From “Huh” to “Oh God”

Findings come with a severity level, and you need to know what these actually mean for your blood pressure.

  • Low: This is the “probably nothing, but you should know” notification. Think: a failed SSH attempt from a Tor exit node. Annoying? Yes. A five-alarm fire? No. It’s background radiation on the internet.
  • Medium: Now we’re talking. This is the “hey, wake up” tier. An API call is made from an IP in a country your company has no business in. An IAM user’s credentials are being used from an unfamiliar EC2 instance. It’s suspicious behavior that demands investigation.
  • High: This is the “drop what you’re doing” level. GuardDuty has high confidence that something actively malicious is happening. This is where you see things like “CredentialAccess: IAMUser/AnomalousBehavior” for a user who just uploaded a secret to a public GitHub repo, or “Impact: EC2/PortProbeUnprotectedPort” on an instance that’s clearly been compromised and is now being used to probe other systems.

The severity isn’t just about the action itself; it’s about GuardDuty’s confidence. A High finding means its machine learning models are screaming that this is bad news.

Common Finding Types You’ll Actually See

The list of findings is long, but you’ll see a few classics again and again.

  • CryptoCurrency: EC2/CurrencyMining: The classic. Some script kiddie got into your instance and installed XMRig. It’s the digital equivalent of finding a squatter in your vacation home, using your electricity to mine for gold.
  • Backdoor: EC2/Spambot: Your instance has been turned into a spam cannon. This is embarrassingly common if you leave SMTP ports open to the world (which you should never, ever do).
  • Stealth: IAMUser/CloudTrailLoggingDisabled: Someone, or some thing, just turned off CloudTrail logging. This is a massive red flag. Attackers try to cover their tracks. This finding means they tried and GuardDuty caught them in the act.
  • UnauthorizedAccess: IAMUser/ConsoleLogin: A successful console login from an IP address that’s nowhere near your normal operations. Maybe it’s a developer logging in from a coffee shop in Bali. Maybe it’s not. You need to find out.

Automated Remediation: Stop the Bleed

You can’t sit there watching findings roll in all day. This is AWS; we automate things. The best practice is to use GuardDuty findings as triggers in Amazon EventBridge, which can then kick off AWS Lambda functions or send commands via AWS Systems Manager to contain the threat.

Let’s say you get a CryptoCurrency: EC2/CurrencyMining finding. The only sane immediate response is to isolate the instance. Here’s a Lambda function that does exactly that. It triggers from an EventBridge rule that matches that specific finding type.

import json
import boto3

def lambda_handler(event, context):
    # Extract the finding details from the EventBridge event
    finding = event['detail']
    instance_id = finding['resource']['instanceDetails']['instanceId']
    
    # Initialize the EC2 client
    ec2 = boto3.client('ec2')
    
    # Isolate the instance: Stop it and change its security group to one that allows no traffic.
    # First, stop the instance. This halts the malicious activity immediately.
    ec2.stop_instances(InstanceIds=[instance_id])
    print(f"Stopped instance: {instance_id}")
    
    # Now, detach its current security groups and attach a 'quarantine' SG.
    # You must have a pre-made security group with NO allowed inbound/outbound rules.
    QUARANTINE_SG = 'sg-0abcdef1234567890' # Your quarantine SG ID
    ec2.modify_instance_attribute(
        InstanceId=instance_id,
        Groups=[QUARANTINE_SG]
    )
    print(f"Attached quarantine security group to instance: {instance_id}")
    
    # You could also snapshot the volume for forensic analysis here.
    
    return {
        'statusCode': 200,
        'body': json.dumps(f"Successfully quarantined {instance_id}")
    }

Why this works: This is a classic “break the network” response. Stopping the instance kills the malicious process. Removing all its network access by applying an empty security group contains the damage, preventing it from talking to other internal systems or phoning home to its command-and-control server. It’s the first and most important step before a human investigates.

The Rough Edges and Pitfalls

Now, the honest part. This automation is powerful but also dangerous if implemented poorly.

  • False Positives: This is the big one. What if your automated remediation stops a critical production instance? Your EventBridge rule must be incredibly specific. Don’t just trigger on any Medium+ finding. Trigger on a specific finding type you’re confident is always bad, like cryptocurrency mining.
  • The Quarantine SG: You must create that “quarantine” security group with no rules before you need it. If you try to create it on the fly in your Lambda function, you’re adding critical seconds to your response time.
  • Investigation vs. Eradication: Automation is for eradication—stopping the immediate threat. It doesn’t do the investigation. You still need a human to figure out how it happened, what was accessed, and how to prevent it next time. Your Lambda function should also send a notification to a security channel; don’t just silently remediate.

GuardDuty is an incredible force multiplier, but it’s not a set-and-forget magic box. Tune it, understand its findings, and build your automated responses carefully. It’s the difference between being a victim of an incident and being in control of one.