performing-cloud-native-threat-hunting-with-aws-detective
Investigate AWS security incidents using Amazon Detective's behavior graphs, built from CloudTrail, VPC Flow Logs, GuardDuty, and EKS audit logs, to trace entity timelines and profile IAM users, roles, EC2 instances, and IP addresses for lateral movement. Use when triaging GuardDuty findings, investigating a suspected AWS compromise, or reconstructing an attacker's activity timeline across AWS accounts.
- License 许可
- Apache-2.0
- 最近更新
- 2026-08-31
- Stars
- ★ 3.6w
- Forks
- 4.4k
01 前言 Front Matter
- name
- performing-cloud-native-threat-hunting-with-aws-detective
- tags
- [ "aws-detective", "threat-hunting", "cloud-security", "guardduty", "behavior-graph", "aws", "iam", "ec2", "incident-investigation" ]
- author
- juliosuas
- domain
- cybersecurity
- license
- Apache-2.0
- version
- 1.0
- nist_csf
- [ "PR.IR-01", "ID.AM-08", "GV.SC-06", "DE.CM-01" ]
- subdomain
- cloud-security
- description
- Investigate AWS security incidents using Amazon Detective's behavior graphs, built from CloudTrail, VPC Flow Logs, GuardDuty, and EKS audit logs, to trace entity timelines and profile IAM users, roles, EC2 instances, and IP addresses for lateral movement. Use when triaging GuardDuty findings, investigating a suspected AWS compromise, or reconstructing an attacker's activity timeline across AWS accounts.
- mitre_attack
- [ "T1078.004", "T1530", "T1537", "T1580", "T1071" ]
02 资源文件 5
- 资产文件assets/template.md1.1 KB
- 参考文档references/api-reference.md8.5 KB
- 参考文档references/standards.md1.1 KB
- 参考文档references/workflows.md1.1 KB
- 脚本scripts/process.py6.9 KB
03 SKILL.md 正文
Performing Cloud-Native Threat Hunting with AWS Detective
Overview
AWS Detective automatically collects and analyzes log data from AWS CloudTrail, VPC Flow Logs, GuardDuty findings, and EKS audit logs to build interactive behavior graphs. These graphs enable security analysts to investigate entities (IAM users, roles, IP addresses, EC2 instances) across time, identify anomalous API calls, detect lateral movement between accounts, and correlate GuardDuty findings into coherent attack narratives — all without manual log parsing.
Prerequisites
- AWS account with Detective enabled (requires GuardDuty active for 48+ hours)
- AWS CLI v2 configured with appropriate IAM permissions (
detective:*,guardduty:List*) - Python 3.9+ with boto3
- IAM policy:
AmazonDetectiveFullAccessor custom policy withdetective:SearchGraph,detective:GetInvestigation,detective:ListIndicators
Key Concepts
| Concept | Description |
|---|---|
| Behavior Graph | Data structure linking CloudTrail, VPC Flow, GuardDuty, and EKS logs for an account/region |
| Entity | Investigable object: IAM user, IAM role, EC2 instance, IP address, S3 bucket, EKS cluster |
| Finding Group | Correlated set of GuardDuty findings linked to the same attack campaign |
| Entity Profile | Timeline of API calls, network connections, and resource access for a specific entity |
| Scope Time | Investigation window (default 24h, max 1 year) for behavioral analysis |
Steps
Step 1: List Available Behavior Graphs
aws detective list-graphs --output table
Step 2: Investigate a Suspicious IAM User
# Get entity profile for an IAM user
aws detective get-investigation \
--graph-arn arn:aws:detective:us-east-1:123456789012:graph:a1b2c3d4 \
--investigation-id 000000000000000000001
Step 3: Search Entities Programmatically
#!/usr/bin/env python3
"""Search AWS Detective for suspicious entities."""
import boto3
import json
from datetime import datetime, timedelta
detective = boto3.client('detective')
def list_behavior_graphs():
"""List all Detective behavior graphs."""
response = detective.list_graphs()
return response.get('GraphList', [])
def get_investigation_indicators(graph_arn, investigation_id, max_results=50):
"""Get indicators for a specific investigation."""
response = detective.list_indicators(
GraphArn=graph_arn,
InvestigationId=investigation_id,
MaxResults=max_results
)
return response.get('Indicators', [])
def investigate_guardduty_findings(graph_arn):
"""List high-severity investigations correlated by Detective."""
response = detective.list_investigations(
GraphArn=graph_arn,
FilterCriteria={
'Severity': {'Value': 'CRITICAL'},
'Status': {'Value': 'RUNNING'}
},
MaxResults=20
)
for investigation in response.get('InvestigationDetails', []):
print(f"Investigation: {investigation['InvestigationId']}")
print(f" Entity: {investigation['EntityArn']}")
print(f" Status: {investigation['Status']}")
print(f" Severity: {investigation['Severity']}")
print(f" Created: {investigation['CreatedTime']}")
print()
if __name__ == "__main__":
graphs = list_behavior_graphs()
for graph in graphs:
print(f"Graph: {graph['Arn']}")
investigate_guardduty_findings(graph['Arn'])
Step 4: Analyze Finding Groups for Attack Campaigns
# List investigations with high severity
aws detective list-investigations \
--graph-arn arn:aws:detective:us-east-1:123456789012:graph:a1b2c3d4 \
--filter-criteria '{"Severity":{"Value":"HIGH"}}' \
--max-results 10
Step 5: Check Entity Indicators
# Get indicators for a specific investigation
aws detective list-indicators \
--graph-arn arn:aws:detective:us-east-1:123456789012:graph:a1b2c3d4 \
--investigation-id 000000000000000000001 \
--max-results 50
Expected Output
The list-investigations command returns investigation metadata:
{
"InvestigationDetails": [
{
"InvestigationId": "000000000000000000001",
"Severity": "CRITICAL",
"Status": "RUNNING",
"State": "ACTIVE",
"EntityArn": "arn:aws:iam::123456789012:user/suspicious-user",
"EntityType": "IAM_USER",
"CreatedTime": "2026-03-15T14:30:00Z"
}
]
}
Indicators are retrieved separately via list-indicators and include types such as TTP_OBSERVED, IMPOSSIBLE_TRAVEL, FLAGGED_IP_ADDRESS, NEW_GEOLOCATION, NEW_ASO, NEW_USER_AGENT, RELATED_FINDING, and RELATED_FINDING_GROUP.
Verification
- Confirm behavior graph has data:
aws detective list-graphsreturns non-empty list - Validate investigation results contain entity timelines with API call sequences
- Cross-reference Detective findings with raw CloudTrail logs for accuracy
- Verify finding group correlations match manual investigation conclusions
- Confirm automated alerts trigger for HIGH/CRITICAL severity investigations
04 同仓库更多 Skills
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/CD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.
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/tpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware/kernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.
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/air-gapped backups for silent corruption or tampering.
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/triage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.
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/Track*/Attend/Act decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.
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/EDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.