Cloud Detection and Response for AWS: Threat Hunting Playbook for 2026

Introduction

Cloud Detection and Response (CDR) is the discipline of detecting, investigating, and responding to attacker activity inside cloud control planes and workloads — AWS, Azure, GCP — using the telemetry the cloud provider itself emits. It is the cloud counterpart to traditional endpoint EDR, but the threat model, the telemetry, and the playbooks are fundamentally different.

This guide is a practitioner playbook for AWS CDR, written for the SOC analyst, threat hunter, or detection engineer responsible for protecting an Indian enterprise’s AWS estate. We cover the AWS threat model, the telemetry sources, the highest-value detection rules, and an end-to-end response playbook for the three most common cloud breach scenarios.

Background: Why Cloud Detection Is Different

A traditional endpoint EDR product watches OS-level events on a managed host: process creation, file modification, network connection, registry change. The cloud equivalent looks nothing like this. The endpoint is an EC2 instance or a Lambda function; the attacker rarely lands there. The control plane — API calls to AWS itself — is where the action happens.

The canonical cloud breach sequence:

1. Credential leak (GitHub commit, .env file, supply-chain compromise).
2. Attacker authenticates to AWS API using the leaked credential.
3. Reconnaissance: iam:ListUsers, s3:ListBuckets, ec2:DescribeInstances.
4. Privilege escalation: enumerate IAM policies, find a path to higher privilege via PassRole, attached managed policies, or misconfigured trust relationships.
5. Data exfiltration: s3:GetObject, rds:CreateDBSnapshot + share to attacker account, EBS snapshot share.
6. Persistence: create new IAM user, attach console password, MFA, programmatic key.
7. Potentially: spin up cryptominers, hijack EC2 instances, ransomware via S3 encryption.

None of this touches an EC2 OS layer. Endpoint EDR is blind to this entire kill chain.

Theory: The Telemetry Stack

AWS exposes ten distinct telemetry streams that matter for detection. In order of priority:

1. CloudTrail Management Events — every control-plane API call. The primary detection source.
2. CloudTrail Data Events — data-plane calls: S3 GetObject, Lambda invocations, DynamoDB queries. High volume, high cost, but essential for data-exfil detection.
3. VPC Flow Logs — network-level connection metadata. Catches data exfiltration not visible in CloudTrail.
4. DNS Query Logs — Route 53 Resolver query logs. Catches C2 callbacks.
5. GuardDuty findings — AWS’s managed threat detection. Use as a signal source, not the only one.
6. Security Hub — aggregation layer over GuardDuty, Inspector, Macie, Access Analyzer.
7. EKS audit logs — Kubernetes API server logs from managed clusters.
8. RDS audit logs — per-engine, per-database. Often disabled.
9. WAF logs — web-application requests at the edge.
10. OS-level logs from running instances — CloudWatch agent, third-party EDR. Still useful, just not primary.

Technical Deep Dive: High-Value CloudTrail Detection Rules

A short list of detection rules that catch most real-world AWS attack patterns. All assume CloudTrail logs are streamed into a SIEM (Splunk, Sentinel, Chronicle, Elastic) for correlation.

Rule 1: New IAM user created outside Terraform.

eventSource: "iam.amazonaws.com"
eventName: "CreateUser"
userAgent NOT MATCHING /aws-cli/.*|terraform|cloudformation/

Real-world attackers create IAM users to maintain persistence. Legitimate user creation in mature shops always goes through IaC.

Rule 2: Console login from a country your business does not operate in.

eventName: "ConsoleLogin"
sourceIPAddress geoip.country_name NOT IN ("India", "United States", "Singapore")
responseElements.ConsoleLogin: "Success"

Tune the country allowlist per business; the value is in catching the foreign login that the legitimate user does not know about.

Rule 3: Disabling of detective controls.

eventName IN (
  "StopLogging", "DeleteTrail", "PutEventSelectors",
  "DeleteDetector", "DisassociateMembers",
  "DeleteFlowLogs", "DeleteSecurityConfiguration"
)

The first thing a sophisticated attacker does after gaining sufficient privilege is to blind the defenders. This rule is the canary.

Rule 4: AssumeRole chain from external principal.

eventName: "AssumeRole"
userIdentity.type: "AWSAccount"
userIdentity.accountId NOT IN known_trusted_accounts

Catches cross-account role assumption from accounts that are not on your allowlist.

Rule 5: Mass S3 GetObject from a single principal.

eventSource: "s3.amazonaws.com"
eventName: "GetObject"
bucket: critical_data_bucket
| stats count() by userIdentity.arn, sourceIPAddress
| where count > baseline_p99 * 5

The signal for data exfiltration. Requires baselining; once baselined, very high signal-to-noise.

Rule 6: PutBucketAcl or PutBucketPolicy granting public access.

eventName IN ("PutBucketAcl", "PutBucketPolicy")
requestParameters.AccessControlPolicy.AccessControlList.Grants.Grantee.URI
  CONTAINS "AllUsers" OR "AuthenticatedUsers"

Public-bucket grants are one of the most common vectors behind the high-impact cloud breaches that lead to Section 8(5) “reasonable security safeguards” findings under DPDP.

Technical Deep Dive: GuardDuty Used Correctly

GuardDuty is AWS’s managed threat detection service. It analyses CloudTrail, VPC Flow Logs, DNS logs, EKS audit, RDS login activity, EBS snapshots, and S3 access patterns to surface findings.

GuardDuty findings to prioritise (high signal):

• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration — instance role credentials being used from outside the instance. Almost always a real compromise.
• Discovery:IAMUser/AnomalousBehavior — principal performing recon actions atypical for its role.
• Stealth:IAMUser/CloudTrailLoggingDisabled — logging tamper.
• Backdoor:EC2/C&CActivity.B!DNS — DNS-based C2.
• Trojan:EC2/DNSDataExfiltration — data exfil over DNS.
• CryptoCurrency:EC2/BitcoinTool.B!DNS — cryptomining.

Lower-signal findings (often false positives, but worth aggregating):

• Recon:IAMUser/UserPermissions — can be normal admin behaviour.
• UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B — depends on baseline.

Practical Implementation: Three Response Playbooks

Playbook A: Leaked Access Key.

1. Deactivate the access key (aws iam update-access-key --status Inactive). Do not delete yet — preserve for forensics.
2. Identify the principal: user, role, or instance profile.
3. Pull last 30 days of CloudTrail for that principal; baseline against normal activity.
4. If the principal is a workload identity (instance profile, Lambda execution role), patch the workload to use a new identity; the credential leak is symptomatic of code or configuration exposure.
5. Scan source-code repositories for the leaked key value.
6. Notify the credential owner; rotate any related credentials.
7. If exfiltration is suspected, escalate to legal counsel — DPDP 72-hour clock may have started.

Playbook B: Public S3 Bucket Discovered.

1. Block public access at the account level if not already: s3:PutAccountPublicAccessBlock.
2. Audit the bucket’s contents for personal data, secrets, IP.
3. Audit access logs: who accessed it while public, from which IPs?
4. If personal data was accessed by external IPs, treat as a DPDP-reportable breach.
5. Identify the principal who set the bucket public; review their permissions.
6. Add Kyverno-style IaC policy preventing future "Principal": "*" bucket policies.

Playbook C: Cryptominer on EC2.

1. Snapshot the EBS volume of the affected instance for forensics.
2. Isolate the instance: detach security group, attach quarantine SG that allows no traffic.
3. Identify the entry vector: SSH brute force, exposed Docker socket, web app RCE, supply chain.
4. Rotate any credentials the instance had access to.
5. Determine financial impact: hours of cryptomining * instance type * region pricing.
6. File AWS abuse report if mining was conducted from your account against external infrastructure.

Enterprise Use Cases

Indian fintechs. The combination of CloudTrail + GuardDuty + a SIEM is the baseline for fintechs handling PA-PG operations. RBI examiners increasingly ask to see specific detection rule sets, not just “we have a SIEM.”

Healthcare and ABDM-linked workloads. S3 buckets holding patient data need Object Lock for immutability, Macie for ongoing PII discovery, and tight CloudTrail Data Events monitoring on GetObject.

BFSI multi-account architectures. Use Control Tower with delegated administration for GuardDuty, Security Hub, and IAM Access Analyzer; treat the security tooling account as a tier-0 protected environment.

Common Pitfalls

• CloudTrail logs in the same account as the workload. If the workload is compromised, the attacker can delete the logs. Stream to a separate dedicated logging account.
• Data Events disabled to save cost. Almost any breach involving S3 will be untraceable without Data Events. Enable selectively on sensitive buckets.
• GuardDuty findings ignored. The “Recon” findings are often dismissed as noise; sometimes they are the only signal you get before exfiltration.
• No baseline for principal behaviour. Anomaly detection requires baselines. Without them, you are pattern-matching.
• Single-region CloudTrail. Attackers operate in regions you do not use. Enable in all regions.

Action Items

• Verify CloudTrail is enabled in all regions, multi-region trail, logs to a dedicated account, with log-file validation enabled.
• Enable GuardDuty in every account; aggregate findings centrally.
• Implement the six high-value detection rules above in your SIEM this sprint.
• Tabletop one of the three response playbooks with the IR team this quarter.
• Inventory your account’s S3 Block Public Access settings; enforce at account level where business permits.
• Subscribe to AWS Security Bulletins; they release patterns you can copy.

AWS CDR is mature enough in 2026 that there is no excuse for blind-spotting the cloud control plane. The detection content is well-understood; the operational discipline of acting on it is the differentiator.