AWS GuardDuty + Security Hub: — Catching Crypto-Mining and Compromise in Real Time

① GuardDuty — the agentless watchman

Picture Sneha, an L1 cloud engineer at Flipkart, getting a 2 a.m. page: the monthly AWS bill is climbing fast and a fleet of GPU instances she never launched is running in a region nobody uses. By the time she logs in, an attacker has been mining cryptocurrency on her account for six hours. The question every team asks after this: why didn't anything catch it in real time? That is precisely the gap Amazon GuardDuty fills.

GuardDuty is a managed threat-detection service. You enable it once per account/region from AWS Console → GuardDuty → Get Started → Enable GuardDuty, and from that moment it continuously reads three foundational data sources for you: CloudTrail (the API audit trail — who called what), VPC Flow Logs (network connection metadata — who talked to whom), and Route 53 DNS query logs (what domains your instances looked up). The trick that surprises people: GuardDuty reads these independently — you don't have to enable VPC Flow Logs or DNS logging on your side, and there are no agents to install on EC2.

On top of those raw logs GuardDuty layers ML/anomaly models (it learns the normal behaviour of your principals and instances) and threat-intelligence feeds (known-bad IPs, mining pools, malware domains). That combination is what lets it catch the things prefix-based monitoring misses: a credential used from a brand-new country (impossible-travel), an instance suddenly talking to a mining pool, an IAM user calling APIs it has never called, or an outside host using credentials stolen from an instance.

Beyond the three free foundational sources, you can switch on extra protection plans for deeper coverage: EKS Protection (Kubernetes audit logs), S3 Protection (CloudTrail S3 data events), Malware Protection (scans EBS volumes), RDS Protection (login-activity monitoring), Lambda Protection and Runtime Monitoring (an eBPF agent for in-host visibility). In December 2025 AWS also turned on Extended Threat Detection for EC2/ECS, which stitches several weak signals into a single AttackSequence Critical finding.

What GuardDuty catches that plain logs miss

Tap each card — these are the four attack patterns interviewers and the SCS-C02 exam love to test.

② Reading findings — type, severity & cutting the noise

A GuardDuty finding looks scary until you learn to read its name. The name follows a fixed grammar: ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact. Read it left to right and it tells you the whole story. Take CryptoCurrency:EC2/BitcoinTool.B!DNS — the ThreatPurpose is CryptoCurrency (someone is mining), the resource affected is an EC2 instance, the threat family is BitcoinTool variant B, and the !DNS artifact says GuardDuty saw it via a DNS query to a crypto domain.

The ThreatPurpose is essentially the attacker's intent and maps loosely to MITRE ATT&CK tactics: Recon (scoping you out), UnauthorizedAccess (brute force, stolen creds), CryptoCurrency (mining), Exfiltration (stealing data), Backdoor (C2 callbacks), Trojan, Impact and Discovery. Two you must know cold for the exam: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS (an outside host is using credentials stolen from an instance role — High severity) and the anomaly-based Exfiltration:IAMUser/AnomalousBehavior (an IAM principal is doing data-movement API calls the ML has never seen it do — also High).

Every finding carries a severity on a 0.1–8.9 scale, bucketed into bands: Low (1.0–3.9), Medium (4.0–6.9) and High (7.0–8.9). The newest band, Critical, is reserved for the AI-correlated AttackSequence findings from Extended Threat Detection. A rough mental model: UnauthorizedAccess:EC2/SSHBruteForce is usually Low (internet noise everyone gets), Recon:EC2/Portscan is Medium, and CryptoCurrency:EC2/BitcoinTool.B or credential exfiltration are High — drop everything.

Now the part nobody warns juniors about: noise. A real account throws hundreds of SSHBruteForce and Portscan findings a week — most are just the internet knocking. GuardDuty gives you two precise tools to cut it. A suppression rule auto-archives findings matching a filter (e.g. a specific finding type + a known-benign instance ID), and a trusted IP list tells GuardDuty not to alert on your own scanner or VPN egress. The mirror of that is a threat IP list for IPs you always want flagged.

③ Security Hub — the aggregator and posture score

GuardDuty isn't the only thing raising alarms in a real account. Amazon Inspector finds vulnerable packages, Amazon Macie finds exposed PII in S3, and AWS Config flags misconfigurations. Four services, four consoles, four formats. AWS Security Hub is the single pane that collects all of them into one prioritised list so your team works one queue instead of four.

The glue that makes that possible is a common schema: the AWS Security Finding Format (ASFF). Security Hub normalises every incoming finding to ASFF — GuardDuty's crypto alert, Inspector's CVE, Macie's PII finding all end up in the same JSON shape with the same fields (severity, resource, types, workflow status). That's what lets one EventBridge rule or one ticketing integration handle findings from any source without custom parsing per tool.

Security Hub's second job is compliance posture. It runs security standards as continuous automated checks against your resources. The big ones: AWS Foundational Security Best Practices (FSBP) — AWS's own opinionated baseline; the CIS AWS Foundations Benchmark (v1.2.0 and v1.4.0); PCI DSS (v3.2.1 and v4.0.1) for cardholder environments; and NIST SP 800-53. Each control (e.g. "S3 Block Public Access is on", "root has MFA") passes or fails per resource, and Security Hub rolls the pass-rate into a security score — a percentage you can show leadership and track week to week.

aws securityhub enable-security-hub \
  --enable-default-standards \
  --region ap-south-1

aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' \
  --query 'Findings[].{Title:Title,Sev:Severity.Label,Res:Resources[0].Id}' \
  --region ap-south-1

{
    "HubArn": "arn:aws:securityhub:ap-south-1:123456789012:hub/default"
}
[
  { "Title": "EC2 instance i-0a1b2c3d communicating with crypto mining pool",
    "Sev": "HIGH", "Res": "arn:aws:ec2:ap-south-1:123456789012:instance/i-0a1b2c3d" }
]

④ From finding to response — auto-isolate a mining instance

Detecting and aggregating is only half the job; the value is in responding fast. The standard AWS pattern is event-driven: a finding (from GuardDuty, or from Security Hub) is an event on the EventBridge bus. You write an EventBridge rule that matches, say, CryptoCurrency:EC2 at High severity, and routes it to two targets at once: an SNS topic (page the on-call) and a Lambda function (or an SSM Automation runbook) that performs the fix.

The classic remediation for a compromised instance is quarantine: the Lambda reads the instance ID out of the finding's ASFF body and swaps the instance's security group for a locked-down quarantine SG with no rules. The instance stops talking to the mining pool and the attacker's C2 in seconds, but it isn't terminated — so your forensics team can still snapshot the EBS volume and investigate. That's the worked flow this whole lesson builds to: GuardDuty flags a mining instance → Security Hub aggregates it → EventBridge fires → Lambda isolates it.

In a company with 50 AWS accounts you don't enable and watch GuardDuty 50 times. You designate one account as the delegated administrator for GuardDuty (and Security Hub), enable for the whole AWS Organization with auto-enable for new accounts, and every member account's findings flow up to that one security account. AWS's guidance: use the same delegated-admin account across GuardDuty, Security Hub, Inspector and Macie so one team sees everything from one place. That's how a real SOC runs cloud detection at scale.

import boto3

ec2 = boto3.client("ec2")
QUARANTINE_SG = "sg-0quarantine99"   # no inbound, no outbound

def handler(event, context):
    # GuardDuty finding arrives via EventBridge
    detail = event["detail"]
    instance_id = detail["resource"]["instanceDetails"]["instanceId"]
    finding_type = detail["type"]

    ec2.modify_instance_attribute(
        InstanceId=instance_id,
        Groups=[QUARANTINE_SG],          # replace ALL SGs with quarantine
    )
    print(f"Isolated {instance_id} due to {finding_type}")
    return {"isolated": instance_id, "finding": finding_type}

START RequestId: 7b2c... Version: $LATEST
Isolated i-0a1b2c3d due to CryptoCurrency:EC2/BitcoinTool.B!DNS
END RequestId: 7b2c...
REPORT Duration: 412.55 ms  Billed Duration: 413 ms  Memory Size: 128 MB

For your AWS Certified Security – Specialty (SCS-C02) path, this lesson sits dead-centre of the Threat Detection and Incident Response domain (14% of the exam) and overlaps Security Logging and Monitoring (18%). The exam loves multi-service scenarios: a finding type is given, and you pick the right service (GuardDuty detects, Security Hub aggregates, Detective investigates) and the right automated response (EventBridge → Lambda/SSM). Nail detect→aggregate→respond and you've covered a big slice of two domains.