[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEAPY7A1YRM3T098QGTP20":3,"skill-same:01M6AEAPY7A1YRM3T098QGTP20":121},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":69,"ownerHtmlUrl":70,"ownerBlogUrl":71,"ownerDescription":72,"updatedAt":73,"install":74,"resources":87},"01M6AEAPY7A1YRM3T098QGTP20","detecting-cloud-threats-with-guardduty",null,"Deploy and operationalize Amazon GuardDuty, covering protection plans for S3, EKS, EC2 runtime monitoring, and Lambda, interpreting finding severity, and building automated response with EventBridge and Lambda. Use when establishing threat detection for AWS accounts, investigating findings on compromised instances or credential abuse, or building automated incident-response playbooks.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-cloud-threats-with-guardduty\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"detecting cloud threats with guardduty","cloud","guardduty","severity","cloud-soc","runtime-monitoring","aws-security","amazon-guardduty","lambda","eventbridge","detection","cybersecurity","eks","aws","threat-detection","soc","cloud-security","s3","monitoring","pr","2026-11-10 10:12:30",false,"---\nname: detecting-cloud-threats-with-guardduty\ndescription: 'Deploy and operationalize Amazon GuardDuty, covering protection plans\n  for S3, EKS, EC2 runtime monitoring, and Lambda, interpreting finding severity, and\n  building automated response with EventBridge and Lambda. Use when establishing threat\n  detection for AWS accounts, investigating findings on compromised instances or credential\n  abuse, or building automated incident-response playbooks.\n\n  '\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- amazon-guardduty\n- threat-detection\n- aws-security\n- runtime-monitoring\n- cloud-soc\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\n- T1071\n---\n\n# Detecting Cloud Threats with GuardDuty\n\n## When to Use\n\n- When establishing continuous threat detection for new or existing AWS accounts\n- When investigating GuardDuty findings related to compromised instances, credential abuse, or data exfiltration\n- When building automated incident response playbooks triggered by GuardDuty findings\n- When extending threat coverage to container workloads running on EKS, ECS, or Fargate\n- When enabling malware scanning for EBS volumes attached to suspicious EC2 instances\n\n**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).\n\n## Prerequisites\n\n- AWS account with GuardDuty administrative permissions (guardduty:*)\n- AWS CloudTrail, VPC Flow Logs, and DNS query logs enabled (GuardDuty consumes these automatically)\n- AWS Organizations configured if deploying GuardDuty across a multi-account estate\n- EventBridge and Lambda configured for automated response workflows\n\n## Workflow\n\n### Step 1: Enable GuardDuty and Protection Plans\n\nActivate 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.\n\n```bash\n# Enable GuardDuty as organization delegated administrator\naws guardduty create-detector \\\n  --enable \\\n  --finding-publishing-frequency FIFTEEN_MINUTES \\\n  --data-sources '{\n    \"S3Logs\": {\"Enable\": true},\n    \"Kubernetes\": {\"AuditLogs\": {\"Enable\": true}},\n    \"MalwareProtection\": {\"ScanEc2InstanceWithFindings\": {\"EbsVolumes\": true}}\n  }'\n\n# Enable Runtime Monitoring for EC2 and ECS\naws guardduty update-detector \\\n  --detector-id \u003Cdetector-id> \\\n  --features '[\n    {\"Name\": \"RUNTIME_MONITORING\", \"Status\": \"ENABLED\",\n     \"AdditionalConfiguration\": [\n       {\"Name\": \"ECS_FARGATE_AGENT_MANAGEMENT\", \"Status\": \"ENABLED\"},\n       {\"Name\": \"EC2_AGENT_MANAGEMENT\", \"Status\": \"ENABLED\"}\n     ]}\n  ]'\n\n# Designate delegated admin for multi-account\naws guardduty enable-organization-admin-account \\\n  --admin-account-id 111122223333\n```\n\n### Step 2: Configure Multi-Account Aggregation\n\nAutomatically enroll all organization member accounts and configure finding export to a centralized S3 bucket for retention and SIEM ingestion.\n\n```bash\n# Auto-enable GuardDuty for all org members\naws guardduty update-organization-configuration \\\n  --detector-id \u003Cdetector-id> \\\n  --auto-enable-organization-members ALL \\\n  --features '[\n    {\"Name\": \"S3_DATA_EVENTS\", \"AutoEnable\": \"ALL\"},\n    {\"Name\": \"EKS_AUDIT_LOGS\", \"AutoEnable\": \"ALL\"},\n    {\"Name\": \"RUNTIME_MONITORING\", \"AutoEnable\": \"ALL\"}\n  ]'\n\n# Configure finding export to S3\naws guardduty create-publishing-destination \\\n  --detector-id \u003Cdetector-id> \\\n  --destination-type S3 \\\n  --destination-properties '{\n    \"DestinationArn\": \"arn:aws:s3:::guardduty-findings-centralized\",\n    \"KmsKeyArn\": \"arn:aws:kms:us-east-1:123456789012:key\u002Fkey-id\"\n  }'\n```\n\n### Step 3: Interpret Finding Types and Severity Levels\n\nGuardDuty classifies findings into four severity levels: Critical, High, Medium, and Low. Each finding type follows the format ThreatPurpose:ResourceType\u002FThreatName. Extended Threat Detection generates attack sequence findings that correlate multiple events across time.\n\nKey finding categories:\n- **Recon**: Port scanning, API enumeration (e.g., Recon:EC2\u002FPortProbeUnprotectedPort)\n- **UnauthorizedAccess**: Credential abuse, console logins from unusual locations\n- **CryptoCurrency**: Mining activity detected on instances (e.g., CryptoCurrency:EC2\u002FBitcoinTool.B)\n- **Impact**: Resource hijacking, data destruction attempts\n- **AttackSequence**: Multi-stage attacks correlating initial access through lateral movement to impact (Critical severity)\n\n### Step 4: Build Automated Response with EventBridge\n\nCreate 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.\n\n```bash\n# EventBridge rule for high\u002Fcritical GuardDuty findings\naws events put-rule \\\n  --name GuardDutyHighSeverity \\\n  --event-pattern '{\n    \"source\": [\"aws.guardduty\"],\n    \"detail-type\": [\"GuardDuty Finding\"],\n    \"detail\": {\n      \"severity\": [{\"numeric\": [\">=\", 7]}]\n    }\n  }'\n\n# Target Lambda function for auto-remediation\naws events put-targets \\\n  --rule GuardDutyHighSeverity \\\n  --targets '[{\n    \"Id\": \"AutoRemediateTarget\",\n    \"Arn\": \"arn:aws:lambda:us-east-1:123456789012:function\u002Fguardduty-auto-remediate\"\n  }]'\n```\n\nAuto-remediation Lambda example for isolating a compromised EC2 instance:\n\n```python\nimport boto3\n\ndef lambda_handler(event, context):\n    finding = event['detail']\n    finding_type = finding['type']\n    severity = finding['severity']\n\n    if finding_type.startswith('UnauthorizedAccess:EC2') and severity >= 7:\n        instance_id = finding['resource']['instanceDetails']['instanceId']\n        ec2 = boto3.client('ec2')\n\n        # Create isolation security group (no inbound\u002Foutbound rules)\n        vpc_id = finding['resource']['instanceDetails']['networkInterfaces'][0]['vpcId']\n        isolation_sg = ec2.create_security_group(\n            GroupName=f'isolation-{instance_id}',\n            Description='GuardDuty auto-isolation',\n            VpcId=vpc_id\n        )\n\n        # Replace all security groups with isolation group\n        ec2.modify_instance_attribute(\n            InstanceId=instance_id,\n            Groups=[isolation_sg['GroupId']]\n        )\n\n        # Tag instance for investigation\n        ec2.create_tags(\n            Resources=[instance_id],\n            Tags=[{'Key': 'SecurityStatus', 'Value': 'ISOLATED'},\n                  {'Key': 'GuardDutyFinding', 'Value': finding_type}]\n        )\n\n        return {'status': 'isolated', 'instance': instance_id}\n```\n\n### Step 5: Investigate Extended Threat Detection Attack Sequences\n\nReview 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.\n\n```bash\n# List critical attack sequence findings\naws guardduty list-findings \\\n  --detector-id \u003Cdetector-id> \\\n  --finding-criteria '{\n    \"Criterion\": {\n      \"severity\": {\"Gte\": 9},\n      \"type\": {\"Eq\": [\"AttackSequence:EC2\u002FCompromisedInstanceGroup\",\n                       \"AttackSequence:ECS\u002FCompromisedCluster\",\n                       \"AttackSequence:EKS\u002FCompromisedCluster\"]}\n    }\n  }'\n\n# Get full finding details with attack sequence timeline\naws guardduty get-findings \\\n  --detector-id \u003Cdetector-id> \\\n  --finding-ids \u003Cfinding-id>\n```\n\n### Step 6: Integrate with Security Hub and SIEM\n\nForward 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.\n\n```bash\n# Verify GuardDuty integration with Security Hub\naws securityhub get-enabled-standards\n\n# Enable Amazon Security Lake with GuardDuty as a source\naws securitylake create-data-lake \\\n  --configurations '[{\n    \"region\": \"us-east-1\",\n    \"lifecycleConfiguration\": {\n      \"expiration\": {\"days\": 365}\n    }\n  }]'\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Extended Threat Detection | GuardDuty capability that correlates multiple signals across time to detect multi-stage attacks, generating Critical-severity attack sequence findings |\n| 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 |\n| Finding Severity | Four-tier classification (Low, Medium, High, Critical) where Critical indicates confirmed multi-stage attacks requiring immediate response |\n| Malware Protection | On-demand and automatic EBS volume scanning triggered by suspicious EC2 behavior to detect malware without agent installation |\n| Delegated Administrator | Organization member account designated to manage GuardDuty across all accounts in an AWS Organization |\n| Suppression Rule | Filter that automatically archives findings matching specific criteria to reduce noise from known benign activity |\n| Threat Intelligence | IP reputation lists and domain threat feeds used by GuardDuty to identify communication with known malicious infrastructure |\n\n## Tools & Systems\n\n- **Amazon GuardDuty**: Core threat detection service analyzing CloudTrail, VPC Flow Logs, DNS logs, and runtime telemetry\n- **Amazon EventBridge**: Serverless event bus for routing GuardDuty findings to automated response targets\n- **AWS Security Hub**: Centralized security findings aggregation supporting automated remediation workflows\n- **Amazon Security Lake**: OCSF-normalized data lake for long-term security log retention and cross-service correlation\n- **Amazon Detective**: Graph-based investigation service that visualizes relationships between GuardDuty findings, resources, and API activity\n\n## Common Scenarios\n\n### Scenario: Cryptocurrency Mining Detected on ECS Cluster\n\n**Context**: GuardDuty generates a CryptoCurrency:Runtime\u002FBitcoinTool.B finding with High severity targeting an ECS Fargate task. Runtime Monitoring detected the execution of a mining binary within a container.\n\n**Approach**:\n1. Review the finding details to identify the ECS cluster, task definition, and container image\n2. Stop the affected ECS task immediately and quarantine the container image in ECR\n3. Check CloudTrail for the ecs:RegisterTaskDefinition and ecs:RunTask calls to identify who deployed the malicious image\n4. Scan the Docker image with ECR enhanced scanning to identify the embedded mining binary\n5. Review IAM credentials used to push the image and revoke compromised access\n6. Update ECR image scanning policies to block images with known mining signatures\n\n**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.\n\n## Output Format\n\n```\nGuardDuty Threat Detection Summary\n====================================\nAccount: 123456789012 (production)\nRegion: us-east-1\nPeriod: 2025-02-01 to 2025-02-23\n\nCRITICAL FINDINGS (Immediate Action Required):\n[CRIT-001] AttackSequence:EC2\u002FCompromisedInstanceGroup\n  - Instances: i-0abc123def, i-0def456abc\n  - Attack Chain: Credential theft -> Persistence -> Crypto mining\n  - First Signal: 2025-02-15T08:23:00Z\n  - Duration: 4 hours across 3 stages\n  - Status: Auto-isolated via Lambda\n\nHIGH FINDINGS:\n[HIGH-001] UnauthorizedAccess:IAMUser\u002FMaliciousIPCaller\n  - Principal: arn:aws:iam::123456789012:user\u002Fci-deploy\n  - Source IP: 198.51.100.42 (Tor exit node)\n  - API Calls: 47 calls to ec2:RunInstances\n  - Status: Access key deactivated\n\n[HIGH-002] CryptoCurrency:Runtime\u002FBitcoinTool.B\n  - Resource: ECS Task arn:aws:ecs:us-east-1:123456789012:task\u002Fcluster\u002Ftask-id\n  - Image: 123456789012.dkr.ecr.us-east-1.amazonaws.com\u002Fapp:v2.1\n  - Process: \u002Ftmp\u002F.hidden\u002Fxmrig --pool stratum+tcp:\u002F\u002Fpool.example.com:3333\n  - Status: Task stopped, image quarantined\n\nSTATISTICS:\n  Total Findings: 23\n  Critical: 1 | High: 3 | Medium: 8 | Low: 11\n  Auto-Remediated: 4\n  Pending Investigation: 2\n```\n","# Detecting Cloud Threats with GuardDuty\n\n## When to Use\n\n- When establishing continuous threat detection for new or existing AWS accounts\n- When investigating GuardDuty findings related to compromised instances, credential abuse, or data exfiltration\n- When building automated incident response playbooks triggered by GuardDuty findings\n- When extending threat coverage to container workloads running on EKS, ECS, or Fargate\n- When enabling malware scanning for EBS volumes attached to suspicious EC2 instances\n\n**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).\n\n## Prerequisites\n\n- AWS account with GuardDuty administrative permissions (guardduty:*)\n- AWS CloudTrail, VPC Flow Logs, and DNS query logs enabled (GuardDuty consumes these automatically)\n- AWS Organizations configured if deploying GuardDuty across a multi-account estate\n- EventBridge and Lambda configured for automated response workflows\n\n## Workflow\n\n### Step 1: Enable GuardDuty and Protection Plans\n\nActivate 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.\n\n```bash\n# Enable GuardDuty as organization delegated administrator\naws guardduty create-detector \\\n  --enable \\\n  --finding-publishing-frequency FIFTEEN_MINUTES \\\n  --data-sources '{\n    \"S3Logs\": {\"Enable\": true},\n    \"Kubernetes\": {\"AuditLogs\": {\"Enable\": true}},\n    \"MalwareProtection\": {\"ScanEc2InstanceWithFindings\": {\"EbsVolumes\": true}}\n  }'\n\n# Enable Runtime Monitoring for EC2 and ECS\naws guardduty update-detector \\\n  --detector-id \u003Cdetector-id> \\\n  --features '[\n    {\"Name\": \"RUNTIME_MONITORING\", \"Status\": \"ENABLED\",\n     \"AdditionalConfiguration\": [\n       {\"Name\": \"ECS_FARGATE_AGENT_MANAGEMENT\", \"Status\": \"ENABLED\"},\n       {\"Name\": \"EC2_AGENT_MANAGEMENT\", \"Status\": \"ENABLED\"}\n     ]}\n  ]'\n\n# Designate delegated admin for multi-account\naws guardduty enable-organization-admin-account \\\n  --admin-account-id 111122223333\n```\n\n### Step 2: Configure Multi-Account Aggregation\n\nAutomatically enroll all organization member accounts and configure finding export to a centralized S3 bucket for retention and SIEM ingestion.\n\n```bash\n# Auto-enable GuardDuty for all org members\naws guardduty update-organization-configuration \\\n  --detector-id \u003Cdetector-id> \\\n  --auto-enable-organization-members ALL \\\n  --features '[\n    {\"Name\": \"S3_DATA_EVENTS\", \"AutoEnable\": \"ALL\"},\n    {\"Name\": \"EKS_AUDIT_LOGS\", \"AutoEnable\": \"ALL\"},\n    {\"Name\": \"RUNTIME_MONITORING\", \"AutoEnable\": \"ALL\"}\n  ]'\n\n# Configure finding export to S3\naws guardduty create-publishing-destination \\\n  --detector-id \u003Cdetector-id> \\\n  --destination-type S3 \\\n  --destination-properties '{\n    \"DestinationArn\": \"arn:aws:s3:::guardduty-findings-centralized\",\n    \"KmsKeyArn\": \"arn:aws:kms:us-east-1:123456789012:key\u002Fkey-id\"\n  }'\n```\n\n### Step 3: Interpret Finding Types and Severity Levels\n\nGuardDuty classifies findings into four severity levels: Critical, High, Medium, and Low. Each finding type follows the format ThreatPurpose:ResourceType\u002FThreatName. Extended Threat Detection generates attack sequence findings that correlate multiple events across time.\n\nKey finding categories:\n- **Recon**: Port scanning, API enumeration (e.g., Recon:EC2\u002FPortProbeUnprotectedPort)\n- **UnauthorizedAccess**: Credential abuse, console logins from unusual locations\n- **CryptoCurrency**: Mining activity detected on instances (e.g., CryptoCurrency:EC2\u002FBitcoinTool.B)\n- **Impact**: Resource hijacking, data destruction attempts\n- **AttackSequence**: Multi-stage attacks correlating initial access through lateral movement to impact (Critical severity)\n\n### Step 4: Build Automated Response with EventBridge\n\nCreate 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.\n\n```bash\n# EventBridge rule for high\u002Fcritical GuardDuty findings\naws events put-rule \\\n  --name GuardDutyHighSeverity \\\n  --event-pattern '{\n    \"source\": [\"aws.guardduty\"],\n    \"detail-type\": [\"GuardDuty Finding\"],\n    \"detail\": {\n      \"severity\": [{\"numeric\": [\">=\", 7]}]\n    }\n  }'\n\n# Target Lambda function for auto-remediation\naws events put-targets \\\n  --rule GuardDutyHighSeverity \\\n  --targets '[{\n    \"Id\": \"AutoRemediateTarget\",\n    \"Arn\": \"arn:aws:lambda:us-east-1:123456789012:function\u002Fguardduty-auto-remediate\"\n  }]'\n```\n\nAuto-remediation Lambda example for isolating a compromised EC2 instance:\n\n```python\nimport boto3\n\ndef lambda_handler(event, context):\n    finding = event['detail']\n    finding_type = finding['type']\n    severity = finding['severity']\n\n    if finding_type.startswith('UnauthorizedAccess:EC2') and severity >= 7:\n        instance_id = finding['resource']['instanceDetails']['instanceId']\n        ec2 = boto3.client('ec2')\n\n        # Create isolation security group (no inbound\u002Foutbound rules)\n        vpc_id = finding['resource']['instanceDetails']['networkInterfaces'][0]['vpcId']\n        isolation_sg = ec2.create_security_group(\n            GroupName=f'isolation-{instance_id}',\n            Description='GuardDuty auto-isolation',\n            VpcId=vpc_id\n        )\n\n        # Replace all security groups with isolation group\n        ec2.modify_instance_attribute(\n            InstanceId=instance_id,\n            Groups=[isolation_sg['GroupId']]\n        )\n\n        # Tag instance for investigation\n        ec2.create_tags(\n            Resources=[instance_id],\n            Tags=[{'Key': 'SecurityStatus', 'Value': 'ISOLATED'},\n                  {'Key': 'GuardDutyFinding', 'Value': finding_type}]\n        )\n\n        return {'status': 'isolated', 'instance': instance_id}\n```\n\n### Step 5: Investigate Extended Threat Detection Attack Sequences\n\nReview 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.\n\n```bash\n# List critical attack sequence findings\naws guardduty list-findings \\\n  --detector-id \u003Cdetector-id> \\\n  --finding-criteria '{\n    \"Criterion\": {\n      \"severity\": {\"Gte\": 9},\n      \"type\": {\"Eq\": [\"AttackSequence:EC2\u002FCompromisedInstanceGroup\",\n                       \"AttackSequence:ECS\u002FCompromisedCluster\",\n                       \"AttackSequence:EKS\u002FCompromisedCluster\"]}\n    }\n  }'\n\n# Get full finding details with attack sequence timeline\naws guardduty get-findings \\\n  --detector-id \u003Cdetector-id> \\\n  --finding-ids \u003Cfinding-id>\n```\n\n### Step 6: Integrate with Security Hub and SIEM\n\nForward 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.\n\n```bash\n# Verify GuardDuty integration with Security Hub\naws securityhub get-enabled-standards\n\n# Enable Amazon Security Lake with GuardDuty as a source\naws securitylake create-data-lake \\\n  --configurations '[{\n    \"region\": \"us-east-1\",\n    \"lifecycleConfiguration\": {\n      \"expiration\": {\"days\": 365}\n    }\n  }]'\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Extended Threat Detection | GuardDuty capability that correlates multiple signals across time to detect multi-stage attacks, generating Critical-severity attack sequence findings |\n| 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 |\n| Finding Severity | Four-tier classification (Low, Medium, High, Critical) where Critical indicates confirmed multi-stage attacks requiring immediate response |\n| Malware Protection | On-demand and automatic EBS volume scanning triggered by suspicious EC2 behavior to detect malware without agent installation |\n| Delegated Administrator | Organization member account designated to manage GuardDuty across all accounts in an AWS Organization |\n| Suppression Rule | Filter that automatically archives findings matching specific criteria to reduce noise from known benign activity |\n| Threat Intelligence | IP reputation lists and domain threat feeds used by GuardDuty to identify communication with known malicious infrastructure |\n\n## Tools & Systems\n\n- **Amazon GuardDuty**: Core threat detection service analyzing CloudTrail, VPC Flow Logs, DNS logs, and runtime telemetry\n- **Amazon EventBridge**: Serverless event bus for routing GuardDuty findings to automated response targets\n- **AWS Security Hub**: Centralized security findings aggregation supporting automated remediation workflows\n- **Amazon Security Lake**: OCSF-normalized data lake for long-term security log retention and cross-service correlation\n- **Amazon Detective**: Graph-based investigation service that visualizes relationships between GuardDuty findings, resources, and API activity\n\n## Common Scenarios\n\n### Scenario: Cryptocurrency Mining Detected on ECS Cluster\n\n**Context**: GuardDuty generates a CryptoCurrency:Runtime\u002FBitcoinTool.B finding with High severity targeting an ECS Fargate task. Runtime Monitoring detected the execution of a mining binary within a container.\n\n**Approach**:\n1. Review the finding details to identify the ECS cluster, task definition, and container image\n2. Stop the affected ECS task immediately and quarantine the container image in ECR\n3. Check CloudTrail for the ecs:RegisterTaskDefinition and ecs:RunTask calls to identify who deployed the malicious image\n4. Scan the Docker image with ECR enhanced scanning to identify the embedded mining binary\n5. Review IAM credentials used to push the image and revoke compromised access\n6. Update ECR image scanning policies to block images with known mining signatures\n\n**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.\n\n## Output Format\n\n```\nGuardDuty Threat Detection Summary\n====================================\nAccount: 123456789012 (production)\nRegion: us-east-1\nPeriod: 2025-02-01 to 2025-02-23\n\nCRITICAL FINDINGS (Immediate Action Required):\n[CRIT-001] AttackSequence:EC2\u002FCompromisedInstanceGroup\n  - Instances: i-0abc123def, i-0def456abc\n  - Attack Chain: Credential theft -> Persistence -> Crypto mining\n  - First Signal: 2025-02-15T08:23:00Z\n  - Duration: 4 hours across 3 stages\n  - Status: Auto-isolated via Lambda\n\nHIGH FINDINGS:\n[HIGH-001] UnauthorizedAccess:IAMUser\u002FMaliciousIPCaller\n  - Principal: arn:aws:iam::123456789012:user\u002Fci-deploy\n  - Source IP: 198.51.100.42 (Tor exit node)\n  - API Calls: 47 calls to ec2:RunInstances\n  - Status: Access key deactivated\n\n[HIGH-002] CryptoCurrency:Runtime\u002FBitcoinTool.B\n  - Resource: ECS Task arn:aws:ecs:us-east-1:123456789012:task\u002Fcluster\u002Ftask-id\n  - Image: 123456789012.dkr.ecr.us-east-1.amazonaws.com\u002Fapp:v2.1\n  - Process: \u002Ftmp\u002F.hidden\u002Fxmrig --pool stratum+tcp:\u002F\u002Fpool.example.com:3333\n  - Status: Task stopped, image quarantined\n\nSTATISTICS:\n  Total Findings: 23\n  Critical: 1 | High: 3 | Medium: 8 | Low: 11\n  Auto-Remediated: 4\n  Pending Investigation: 2\n```\n",{"name":5,"tags":49,"author":50,"domain":35,"license":15,"version":51,"nist_csf":52,"subdomain":40,"description":57,"mitre_attack":58},[31,38,30,29,28],"mahipal","1.0.0",[53,54,55,56],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01","Deploy and operationalize Amazon GuardDuty, covering protection plans for S3, EKS, EC2 runtime monitoring, and Lambda, interpreting finding severity, and building automated response with EventBridge and Lambda. Use when establishing threat detection for AWS accounts, investigating findings on compromised instances or credential abuse, or building automated incident-response playbooks.\n",[59,60,61,62,63],"T1078.004","T1530","T1537","T1580","T1071","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fdetecting-cloud-threats-with-guardduty",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":75,"prompt":85,"zipAvailable":86},[76,79,82],{"tool":77,"command":78},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-cloud-threats-with-guardduty",{"tool":80,"command":81},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-cloud-threats-with-guardduty",{"tool":83,"command":84},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-cloud-threats-with-guardduty","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-cloud-threats-with-guardduty\u002FSKILL.md",true,[88,93,99,103,109,113,117],{"path":89,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-cloud-threats-with-guardduty\u002FLICENSE",{"path":94,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fapi_reference.md","REFERENCE","参考文档",15857,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbrenda-database\u002Freferences\u002Fapi_reference.md",{"path":100,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fapi-reference.md",2300,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-cloud-threats-with-guardduty\u002Freferences\u002Fapi-reference.md",{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fagent.py","SCRIPT","脚本",6692,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-cloud-threats-with-guardduty\u002Fscripts\u002Fagent.py",{"path":110,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fbrenda_queries.py",30872,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbrenda-database\u002Fscripts\u002Fbrenda_queries.py",{"path":114,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fbrenda_visualization.py",29361,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbrenda-database\u002Fscripts\u002Fbrenda_visualization.py",{"path":118,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fenzyme_pathway_builder.py",44863,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbrenda-database\u002Fscripts\u002Fenzyme_pathway_builder.py",[122,148,172,199,225,252],{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":44},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132,133,134,35,135,136,43,137,138,139,140,141,142,143,144,145,146,147],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":44},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[154],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[156,144,157,158,134,159,35,43,160,161,162,163,164,165,166,167,168,169,170,171],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":182,"publishedAt":44},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[178,181],{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[166,183,184,185,186,35,187,188,160,189,190,191,192,193,34,194,195,196,197,198],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":44},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[205],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[207,208,209,35,210,211,212,213,214,215,216,217,218,219,220,221,163,222,223,224],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":232,"publishedAt":44},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[231],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[233,234,235,35,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":256,"categories":257,"keywords":259,"publishedAt":44},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[258],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[134,260,35,261,262,263,39,264,265,27,266,194,267,195,268,269,270,271,272,273],"triaging security incident","siem","file","ioc","NIST-800-61","NIST","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]