Threat Hunting in the Cloud, Part 2: AWS

AWS threat hunting starts with a useful contradiction: AWS gives defenders extremely rich telemetry, but the signal is spread across services, accounts, regions, and data formats. CloudTrail records API activity. GuardDuty produces threat findings. Security Hub aggregates findings. Security Lake can centralize and normalize security data into OCSF. VPC Flow Logs, Route 53 resolver logs, EKS audit logs, WAF logs, S3 data events, and runtime telemetry all add context. The problem is not that AWS is invisible. The problem is that adversary behavior often crosses the boundaries between these sources.

A practical AWS hunt program should therefore be organized around behavior, not around consoles. Start with the Cloud ATT&CK matrix, choose a hypothesis, identify the AWS telemetry that can prove or disprove it, and then preserve the outcome as a reusable hunt package.

AWS CloudTrail is the backbone. AWS describes CloudTrail as the service for operational and risk auditing, governance, and compliance, recording actions by users, roles, and AWS services. It captures management console, CLI, SDK, and API activity. Trails can deliver events to S3, CloudWatch Logs, and EventBridge, while CloudTrail Lake supports longer-term query and analysis of user and API activity. In AWS, if you cannot reason about API activity, you cannot hunt the control plane.

The AWS Hunt Surface

The AWS hunt surface usually breaks into six layers.

1. IAM and Credentials

Most AWS intrusions begin with credentials or permissions. Access keys leak from code repositories, CI/CD variables, developer laptops, container environments, instance metadata, or third-party systems. Temporary credentials can be abused quickly. Roles can be assumed across accounts. Policies can be broadened quietly.

High-value hunts include:

• CreateAccessKey, UpdateAccessKey, or DeleteAccessKey for privileged users.
• AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy, or CreatePolicyVersion followed by discovery calls.
• AssumeRole into unusual accounts, roles, or regions.
• API calls from unfamiliar ASNs, geographies, user agents, or automation clients.
• Root account use, especially outside known break-glass procedures.
• Failed authorization spikes followed by successful privilege changes.
• iam:PassRole used with compute creation or serverless deployment.

ATT&CK mapping: Valid Accounts, Cloud Accounts, Permission Groups Discovery, Use Alternate Authentication Material, Application Access Token, and Cloud Infrastructure Discovery.

Threat Foundry tie-in: use Hunt Builder with the Cloud matrix to generate a credential abuse hunt, then add the AWS-specific event names as query override notes. If CTI mentions leaked AWS keys or token abuse, CTI intake can promote it into a hunt candidate and CTI Modeling can show whether credential themes are recurring.

2. Control-Plane Change

AWS control-plane activity is where adversaries turn credentials into capability. They enumerate, create, modify, expose, disable, and delete. Many AWS incidents look like a sequence: get credentials, call GetCallerIdentity, enumerate IAM, list S3 buckets, inspect EC2, change permissions, access data, then cover tracks or create persistence.

High-value hunts include:

• CloudTrail stopped, trails deleted, event selectors weakened, or S3 log bucket policies changed.
• GuardDuty, Security Hub, Config, Macie, or other security services disabled.
• New regions used by an account that normally operates in a narrow region set.
• Security groups opened to 0.0.0.0/0 for management ports or sensitive services.
• KMS key policy changes, grants, or key deletion scheduling.
• Secrets Manager reads by unusual roles or after privilege changes.
• New Lambda functions, ECS tasks, EC2 instances, or EKS workloads created by unusual identities.

ATT&CK mapping: Impair Defenses, Cloud Service Dashboard, Cloud Service Discovery, Cloud Infrastructure Discovery, Cloud Storage Object Discovery, and Create or Modify System Process when runtime execution is involved.

Threat Foundry tie-in: Attack Path Builder is ideal for chaining these events. A hunt path might begin with Cloud Account discovery, move to Permission Groups Discovery, then Cloud Infrastructure Discovery, then Data from Cloud Storage. Saving that path gives analysts a reusable way to test for AWS control-plane intrusion.

3. Data Plane: S3, Databases, and Exports

AWS data theft often happens through legitimate services. S3 data events, CloudTrail Lake, Security Lake, Macie, database logs, and storage access logs become crucial. The question is not only whether an object was read. It is whether the read pattern was new for that identity, whether the data was sensitive, whether access was granted externally, and whether the activity followed suspicious IAM changes.

High-value hunts include:

• GetObject, ListBucket, or bulk S3 access by new principals.
• Bucket policies changed to allow public, cross-account, or broad organizational access.
• PutBucketAcl, PutBucketPolicy, PutPublicAccessBlock, or lifecycle changes that weaken protection.
• RDS snapshots created, shared, copied, or exported unexpectedly.
• DynamoDB exports or large scan patterns by unusual roles.
• KMS decrypt spikes against sensitive keys.
• S3 data access followed by deletion, lifecycle expiration, or object lock changes.

ATT&CK mapping: Data from Cloud Storage, Data from Information Repositories, Transfer Data to Cloud Account, Unauthenticated Resource Sharing, and Lifecycle-Triggered Deletion.

Threat Foundry tie-in: Asset Classification and Priority Vendors/Products help weight hunts toward business-critical cloud assets. When a hunt touches crown-jewel buckets, regulated databases, or priority products, the resulting case should carry that context forward.

4. EKS, Containers, and Runtime

Cloud control-plane telemetry tells you what was requested. Runtime telemetry tells you what executed. GuardDuty's protection plans can monitor EKS audit logs, runtime events across EKS, EC2, and ECS Fargate, S3 data events, RDS login activity, Lambda network activity, and malware in EC2 or S3 contexts. GuardDuty's documentation also notes that foundational detection starts with CloudTrail management events, VPC flow logs, and DNS logs.

High-value hunts include:

• EKS exec into pods by unusual identities.
• Kubernetes secrets read by service accounts that do not normally need them.
• Privileged containers, hostPath mounts, or containers with host networking.
• Pods running known offensive tools, miners, curl-to-shell patterns, or reverse shells.
• EC2 metadata service access followed by AWS API calls from the instance role.
• Lambda functions contacting unusual external hosts.
• ECS task definitions containing plaintext credentials or unusual environment variables.

ATT&CK mapping: Cloud Instance Metadata API, Exploitation for Credential Access, Container and Resource Discovery behaviors, Remote Services, and Resource Hijacking.

Threat Foundry tie-in: use Sigma Builder for behavior in CloudTrail, EKS audit logs, VPC Flow Logs, and DNS logs. Use YARA Builder when CTI contains file, script, or malware content that could appear in workloads or object storage. The platform's review-first model keeps generated detection content from becoming unvetted automation.

5. Security Lake and the Normalization Problem

Amazon Security Lake is important because it centralizes security data from AWS, SaaS, on-premises, cloud, and third-party sources into a data lake stored in the customer's account. It converts supported logs into Apache Parquet and maps data to OCSF, making it easier for multiple analytics tools to consume the same data. It supports sources including CloudTrail management and selected data events, EKS audit logs, Route 53 resolver query logs, Security Hub findings, VPC Flow Logs, and WAFv2 logs.

For hunting, the value is not just storage. It is cross-source correlation. A good AWS hunt often needs to join identity, API, DNS, network, and finding data. Without normalization, each hunt becomes a one-off integration exercise.

Threat Foundry tie-in: Field Normalization Mapping and Query Overrides are built for this messy middle. Teams can preserve local source fields, normalized entities, and known-good query adaptations so that an AWS hunt package can survive differences between Security Lake, Splunk, Sentinel, Elastic, LogScale, or another analytics backend.

6. Impact and Recovery

AWS impact hunts should focus on native destructive actions. Adversaries do not need ransomware binaries if they can delete snapshots, modify backup plans, schedule key deletion, remove access, or encrypt data with cloud-native mechanisms.

High-value hunts include:

• AWS Backup vault, plan, recovery point, or lifecycle changes.
• EBS snapshots deleted, copied externally, or shared unexpectedly.
• KMS keys disabled or scheduled for deletion.
• S3 versioning, object lock, lifecycle, replication, or public access block changes.
• CloudTrail, Config, GuardDuty, Security Hub, or logging changes before destructive activity.
• Large-scale resource creation consistent with cryptomining or cost exhaustion.

ATT&CK mapping: Inhibit System Recovery, Data Destruction, Data Encrypted for Impact, Account Access Removal, Service Stop, and Resource Hijacking.

Threat Foundry tie-in: Case Workspace is where these hunts become operational evidence. A good case should show the ATT&CK path, affected accounts, role changes, data access, recovery-control changes, and recommended containment steps.

A Weekly AWS Hunt Pattern

A practical AWS hunt week can look like this:

1. Pick one Cloud ATT&CK behavior, such as Cloud Storage Object Discovery or Application Access Token abuse.
2. Confirm telemetry: CloudTrail management events, S3 data events, GuardDuty findings, VPC/DNS logs, EKS audit logs, or Security Lake tables.
3. Generate the hunt in Threat Foundry using the Cloud matrix.
4. Add AWS query specifics through Query Overrides.
5. Run the hunt in the configured analytics backend.
6. Save the hunt and send findings to triage if evidence appears.
7. Convert stable logic into a reviewed Sigma rule.
8. Record false positives, missing fields, and asset criticality in the case.

AWS hunting gets better when teams stop treating CloudTrail, GuardDuty, Security Lake, and workload telemetry as separate worlds. ATT&CK gives the behavior map. Threat Foundry gives the operational workflow from hypothesis to hunt package to detection content to case.

Sources

• AWS Documentation, What Is AWS CloudTrail?.
• AWS Documentation, What is Amazon GuardDuty?.
• AWS Documentation, What is Amazon Security Lake?.
• MITRE ATT&CK, Enterprise Cloud Matrix.
• Cloud Security Alliance, Top Threats to Cloud Computing 2024.