This skill teaches security teams how to deploy and operationalize Amazon GuardDuty for continuous threat detection across AWS accounts and workloads. It covers enabling protection plans for S3, EKS, EC2 runtime monitoring, and Lambda, interpreting finding severity levels, and building automated response workflows using EventBridge and Lambda.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
This skill teaches security teams how to deploy and operationalize Amazon GuardDuty for continuous threat detection across AWS accounts and workloads. It covers enabling protection plans for S3, EKS, EC2 runtime monitoring, and Lambda, interpreting finding severity levels, and building automated response workflows using EventBridge and Lambda.
When establishing continuous threat detection for new or existing AWS accounts
When investigating GuardDuty findings related to compromised instances, credential abuse, or data exfiltration
When building automated incident response playbooks triggered by GuardDuty findings
When extending threat coverage to container workloads running on EKS, ECS, or Fargate
When enabling malware scanning for EBS volumes attached to suspicious EC2 instances
Do not use for Azure or GCP threat detection (see securing-azure-with-microsoft-defender or auditing-gcp-security-posture), for static code analysis, or for compliance posture monitoring (see implementing-aws-security-hub).
Detection Gaps & Validation
Coverage gaps attackers exploit and how to prove the pipeline works:
GuardDuty is regional + per-detector. A detector in us-east-1 is blind to activity in eu-west-1; adversaries deliberately operate in unused regions. Enumerate list-detectors in every region.
Base detector "enabled" ≠ protection plans on. S3 Protection, Runtime Monitoring, EKS Audit Logs, RDS Login, and Malware Protection are independent features — confirm each via get-detector / list-detector-features.
Runtime Monitoring needs the agent actually deployed.EC2_AGENT_MANAGEMENT enabled doesn't mean the agent runs on every instance — check get-coverage-statistics / list-coverage for UNHEALTHY/missing hosts.
Suppression rules and archived findings hide real hits (service.archived == true) — review suppression filters before trusting a quiet console.
Tune FP with suppression rules on known scanners/benign automation rather than disabling whole finding types.
Prerequisites
AWS account with GuardDuty administrative permissions (guardduty:*)
AWS CloudTrail, VPC Flow Logs, and DNS query logs enabled (GuardDuty consumes these automatically)
AWS Organizations configured if deploying GuardDuty across a multi-account estate
EventBridge and Lambda configured for automated response workflows
Workflow
Step 1: Enable GuardDuty and Protection Plans
Activate GuardDuty at the organization level using a delegated administrator account. Enable all protection plans including S3 Protection, EKS Audit Log Monitoring, Runtime Monitoring, Malware Protection, RDS Login Activity, and Lambda Network Activity Monitoring.
Step 3: Interpret Finding Types and Severity Levels
GuardDuty classifies findings into four severity levels: Critical, High, Medium, and Low. Each finding type follows the format ThreatPurpose:ResourceType/ThreatName. Extended Threat Detection generates attack sequence findings that correlate multiple events across time.
Key finding categories:
Recon: Port scanning, API enumeration (e.g., Recon:EC2/PortProbeUnprotectedPort)
UnauthorizedAccess: Credential abuse, console logins from unusual locations
CryptoCurrency: Mining activity detected on instances (e.g., CryptoCurrency:EC2/BitcoinTool.B)
Impact: Resource hijacking, data destruction attempts
AttackSequence: Multi-stage attacks correlating initial access through lateral movement to impact (Critical severity)
Step 4: Build Automated Response with EventBridge
Create EventBridge rules that route GuardDuty findings to Lambda functions for automated containment actions such as isolating compromised EC2 instances, revoking IAM credentials, or blocking malicious IP addresses.
Review Critical-severity attack sequence findings that correlate multiple signals across EC2, ECS, and EKS. These findings represent multi-stage attacks such as initial access through compromised credentials followed by persistence, lateral movement, and crypto mining.
Forward GuardDuty findings to AWS Security Hub for centralized aggregation and to external SIEM platforms via S3 export or Amazon Security Lake for long-term retention and cross-source correlation.
# Verify GuardDuty integration with Security Hub
aws securityhub get-enabled-standards
# Enable Amazon Security Lake with GuardDuty as a source
aws securitylake create-data-lake \
--configurations '[{
"region": "us-east-1",
"lifecycleConfiguration": {
"expiration": {"days": 365}
}
}]'
Key Concepts
Term
Definition
Extended Threat Detection
GuardDuty capability that correlates multiple signals across time to detect multi-stage attacks, generating Critical-severity attack sequence findings
Runtime Monitoring
Protection plan that deploys a security agent to EC2 instances, ECS tasks, and EKS pods to detect runtime threats at the OS level
Amazon Security Lake: OCSF-normalized data lake for long-term security log retention and cross-service correlation
Amazon Detective: Graph-based investigation service that visualizes relationships between GuardDuty findings, resources, and API activity
Common Scenarios
Scenario: Cryptocurrency Mining Detected on ECS Cluster
Context: GuardDuty generates a CryptoCurrency:Runtime/BitcoinTool.B finding with High severity targeting an ECS Fargate task. Runtime Monitoring detected the execution of a mining binary within a container.
Approach:
Review the finding details to identify the ECS cluster, task definition, and container image
Stop the affected ECS task immediately and quarantine the container image in ECR
Check CloudTrail for the ecs:RegisterTaskDefinition and ecs:RunTask calls to identify who deployed the malicious image
Scan the Docker image with ECR enhanced scanning to identify the embedded mining binary
Review IAM credentials used to push the image and revoke compromised access
Update ECR image scanning policies to block images with known mining signatures
Pitfalls: Stopping the task without preserving the container image loses forensic evidence. Failing to trace back to the RegisterTaskDefinition API call misses the initial compromise vector.
