The Complete AWS Threat Hunting Library: 27 Cloud Hunts, 7 Flagship Playbooks, and the Full Archive (2026)

The Amazon Web Services attack surface is broader than most cloud SOCs realise and more nuanced than most threat-detection vendors admit. This library is the definitive 2026 reference for hunting that surface end-to-end — seven battle-tested hunt playbooks, the complete AWS attack-surface map, MITRE ATT&CK Cloud Matrix coverage, telemetry inventory, deployment plan, success metrics, and the career path that turns a SOC analyst into a cloud threat hunter.

If you are a cloud SOC analyst, AWS threat hunter, detection engineer, or cloud security architect, this is the page you bookmark. Read the seven hunts top-to-bottom, deploy them quarterly, and use the supplementary sections (attack surface, ATT&CK coverage, telemetry, toolkit, KPIs) as the operational reference that pairs with them.

Every hunt below targets a specific AWS attack pattern observed in real cloud incident response. Every hunt ships a working Sigma rule mapped to MITRE ATT&CK, a hunt query pattern adapted to a SQL-style interface, a detection-engineering path from hypothesis to production rule, a false-positive analysis, and a documented response playbook. Together, they cover more than 80% of the AWS attack surface that GuardDuty, Security Hub, and native cloud detection services do not catch on their own.

01 · Why AWS threat hunting matters more in 2026 than ever before

AWS is no longer a sandbox where startups host side projects. It is the production substrate for a substantial slice of global enterprise infrastructure, financial services, healthcare workloads, defence contractor pipelines, and critical national infrastructure. Compromise of a single AWS organisation can produce blast radius measured in petabytes of data, billions of API calls, and weeks of impacted business operations.

The 2026 AWS threat landscape has shifted in three structural ways that make a dedicated hunting practice non-negotiable for any cloud-resident security operations team.

Shift 01 · Native detection services are no longer sufficient on their own

Amazon GuardDuty, Security Hub, Macie, and the broader native-detection stack are excellent foundational controls. They are not, however, sufficient as the sole detection layer. Native services are designed for high-precision, low-false-positive detection of well-documented threats. By design they avoid the harder, behaviour-based, anomaly-driven detection patterns that catch the techniques sophisticated adversaries actually use.

The detection literature on this is unambiguous: cloud breaches with substantial impact almost always involve techniques that produced zero native-service findings during the dwell period. The compensating layer is hypothesis-driven threat hunting against the same telemetry GuardDuty consumes — with different questions, different time windows, and different correlation logic.

Shift 02 · The AWS attack surface has grown faster than detection coverage

New AWS services launch routinely. Each one has its own control plane, data plane, IAM permissions, audit-logging configuration, and exploitation possibilities. Detection rules built for the AWS attack surface of 2023 do not cover the AWS attack surface of 2026. The gap grows quarterly.

The cloud-native services most relevant to the 2026 threat model include Bedrock, EventBridge, SageMaker, Lake Formation, CodeBuild, CodePipeline, Lambda runtime monitoring, ECR, Step Functions, Systems Manager, Athena, Glue, and the AWS Organizations control plane. Each of these has been observed as an attack vector or an evasion surface in 2025-2026 incident response. Few cloud SOCs hunt all of them.

Shift 03 · Adversaries have moved from opportunistic to cloud-native

The adversaries who target AWS in 2026 are not the same operators who targeted on-premises environments five years ago. The leading clusters now have dedicated cloud-native tradecraft — AWS-specific reconnaissance tools, AWS-aware privilege-escalation chains, AWS-CLI operational discipline, and CloudTrail-evasion habits that show up consistently across engagements.

This professionalisation means the hunt patterns that worked in 2022 produce false negatives in 2026. Modern AWS hunting requires modern AWS hunt content. The seven hunts in this library represent the 2026 state of the practice.

The combined implication of these three shifts is simple: any organisation with substantial AWS workloads needs a dedicated cloud threat hunting practice, sustained by a maintained library of cloud-specific hunts, refreshed quarterly. This library is the starting point.

02 · The 7 hunts at a glance

Each row below maps a hunt to its primary AWS attack surface, its detection focus, and its severity tier. Read this table first, then jump to the hunts most relevant to your environment.

Four of the seven hunts are tagged Critical because their successful exploitation produces irreversible or organisation-wide impact (data encryption, supply-chain compromise, data lake exfiltration, multi-account compromise). The remaining three are tagged High because they enable other attacks but rarely produce direct impact on their own.

03 · The 7 hunts in detail

Each card below summarises the hunt’s scope, the adversary tradecraft it targets, the AWS services involved, the MITRE ATT&CK techniques mapped, and a sample query you can adapt to your tooling. Click through to each hunt for the full playbook, Sigma rule, detection engineering path, false-positive analysis, response actions, and FAQ.

HUNT 01 · VISIBILITY GAP HUNTING

CloudTrail Blind Spots: 12 Places AWS Doesn’t Log

CloudTrail is the cornerstone of AWS threat detection, but it has structural blind spots that sophisticated adversaries exploit deliberately. This hunt maps 12 specific gaps in default CloudTrail capture — data events for S3 and Lambda, region skipping, IMDS pivoting, container-runtime events, inside-VPC traffic, VPC endpoint private routing, organization-level asymmetries, service-linked role filtering, read-only call exclusion, and event-selector blind spots.

The hunt pattern is the meta-detection of compensating-telemetry-to-CloudTrail-event ratios: identities producing much more network or data activity than their control-plane footprint suggests are operating in the blind spots. The query pattern correlates VPC Flow Log volume, S3 access volume, and IMDS request counts against CloudTrail event counts per identity, surfaces anomalous ratios, and feeds candidate principals into the response queue.

This is the foundational hunt because it characterises the visibility problem the rest of the library compensates for. Run it first.

Primary AWS attack surface

CloudTrail (management + data events) · VPC Flow Logs · S3 access logs · IMDS · container runtime telemetry

Key techniques covered

T1562.008 (Impair Defenses: Disable or Modify Cloud Logs) · T1530 (Data from Cloud Storage Object) · T1078.004 (Valid Accounts: Cloud Accounts)

Sample hunt query

Surfaces identities operating preferentially in CloudTrail blind spots

-- Identity high data-to-control-plane ratio (CloudTrail blind-spot indicator)
SELECT principal,
       data_plane_events,
       control_plane_events,
       data_plane_events / NULLIF(control_plane_events, 0) AS ratio
FROM identity_activity_24h
WHERE control_plane_events > 0
  AND data_plane_events > 1000
  AND data_plane_events / control_plane_events > 50
ORDER BY ratio DESC;

Read Hunt 01 in Full →

HUNT 02 · CRITICAL · ENCRYPTION KEY HIJACK

AWS KMS Ransomware Hunt

Ransomware in the cloud no longer requires a malicious binary. It only requires that the attacker convince AWS Key Management Service that their key is the new owner. This hunt covers four KMS-mediated ransomware patterns observed in cloud incident response: customer-managed key policy modification, re-encryption with an attacker-controlled key, grant token persistence, and scheduled key deletion ransom.

The hunt is a high-priority operational concern because KMS ransomware bypasses the entire on-host detection layer that traditional ransomware response depends on. There is no binary to hash, no payload to extract, no persistence mechanism to clean up. The encryption layer itself becomes the weapon. The standard ransomware playbook — rotate credentials, eject the attacker, restore from backups — does not work when the encryption keys themselves are the target.

The detection focuses on PutKeyPolicy, CreateGrant, ScheduleKeyDeletion, and ReEncrypt operations originating from principals not on the KMS administrator allowlist. The response playbook includes credential rotation, key-policy restoration from CloudTrail history, and grant token audit.

Primary AWS attack surface

AWS KMS (CMK and AWS-managed) · key policies · grants · CloudTrail data events for KMS

Key techniques covered

T1486 (Data Encrypted for Impact) · T1098 (Account Manipulation) · T1485 (Data Destruction)

Sample hunt query

Surfaces KMS ransomware Pattern 01 (policy modification)

-- KMS PutKeyPolicy from principal not on the administrator allowlist
SELECT eventTime, userIdentity.arn AS principal, sourceIPAddress,
       requestParameters.keyId AS key_id,
       requestParameters.policy AS new_policy
FROM cloudtrail_logs
WHERE eventName = 'PutKeyPolicy'
  AND eventSource = 'kms.amazonaws.com'
  AND userIdentity.arn NOT IN (SELECT principal FROM kms_admin_allowlist)
ORDER BY eventTime DESC;

Read Hunt 02 in Full →

HUNT 03 · BLIND-SPOT HUNTING · KNOWN OPPONENT

GuardDuty Evasion Hunt

GuardDuty is the safety net most cloud SOCs assume catches the obvious attacks. Sophisticated adversaries treat it as a known opponent — one whose detection logic is documented publicly and whose blind spots are enumerable. This hunt reverse-engineers nine specific evasion techniques and ships the meta-hunt that detects the silence GuardDuty produces.

The nine techniques cover: slow-rate credential brute force below GuardDuty’s rate threshold, private-subnet lateral movement below the internet-facing detection plane, VPC endpoint use that changes the source attribution GuardDuty observes, service-linked role abuse that filters out of detection logic, region selection where GuardDuty is not enabled, runtime-monitoring evasion on container workloads where opt-in monitoring is off, subtle privilege escalation below the policy-change-detection threshold, log alteration that disables the input feed, and legitimate-tooling reuse that produces no malware signatures.

The meta-pattern is the most important takeaway: silence on a GuardDuty rule is itself a signal when correlated with other telemetry. A region producing high CloudTrail volume with zero GuardDuty findings deserves investigation.

Primary AWS attack surface

Amazon GuardDuty · CloudTrail · VPC Flow Logs · Route 53 Resolver DNS · runtime monitoring

Key techniques covered

T1562 (Impair Defenses) · T1562.008 (Disable or Modify Cloud Logs) · T1110 (Brute Force, slow variant)

Sample hunt query

Surfaces regions where GuardDuty is silently disabled or evaded

-- AWS regions with significant CloudTrail volume and zero GuardDuty findings
WITH ct AS (SELECT awsRegion, COUNT(*) events FROM cloudtrail_logs GROUP BY awsRegion),
     gd AS (SELECT region, COUNT(*) findings FROM guardduty_findings GROUP BY region)
SELECT ct.awsRegion, ct.events, COALESCE(gd.findings, 0) AS findings
FROM ct LEFT JOIN gd ON ct.awsRegion = gd.region
WHERE ct.events > 1000 AND COALESCE(gd.findings, 0) = 0;

Read Hunt 03 in Full →

HUNT 04 · CRITICAL · SUPPLY CHAIN

Hunting CI/CD Compromise in AWS

An attacker who compromises the AWS CI/CD pipeline owns every artefact you ship from that point forward. AWS CodeBuild, CodePipeline, ECR, and the constellation of build-and-deploy services expose four distinct compromise surfaces that most cloud SOCs do not monitor.

The four patterns are: buildspec backdoor (malicious code committed into buildspec.yml that executes with the build role’s privileges), runner takeover (code execution inside the build runner via a compromised dependency), secrets exfiltration during build (environment-variable theft via legitimate-looking test code), and artefact poisoning (modification of built artefacts in S3 or ECR between build and deploy).

CI/CD compromise is a critical-tier risk because the impact propagates downstream automatically: every service that consumes the poisoned artefact inherits the compromise. The detection logic includes buildspec change-frequency anomalies, build-runner outbound network connections to non-baseline destinations, IAM credential enumeration from build environments, and artefact-store write events from non-pipeline principals.

Primary AWS attack surface

CodeBuild · CodePipeline · ECR · S3 artefact buckets · build-runner ENI · IAM build roles

Key techniques covered

T1195.002 (Supply Chain Compromise: Software Supply Chain) · T1041 (Exfiltration Over C2 Channel) · T1078.004 (Valid Accounts: Cloud Accounts)

Sample hunt query

Surfaces CI/CD runner takeover and secrets-exfil-during-build

-- Build runner outbound to non-baseline destination
SELECT build_id, project_name, dst_ip, dst_host, COUNT(*) AS conn_count
FROM vpc_flow_logs_with_build_attribution
WHERE dst_ip NOT IN (SELECT ip FROM build_baseline_destinations)
GROUP BY build_id, project_name, dst_ip, dst_host
HAVING COUNT(*) > 1;

Read Hunt 04 in Full →

HUNT 05 · NATIVE-CHANNEL COMMAND-AND-CONTROL

EventBridge and SNS as Covert C2

Sophisticated adversaries are routing command-and-control through AWS-native messaging — EventBridge custom buses, SNS topics, SQS queues — rather than through external network channels. The traffic blends with legitimate internal application messaging and produces no external-network indicators. This hunt covers four covert-channel patterns built on AWS-native messaging primitives.

The patterns are: compromised Lambda publishing to an attacker-controlled EventBridge bus, SNS topic with an external-account HTTPS subscription, SQS queue with cross-account SendMessage policy, and cross-account EventBridge event-bus federation. Each produces a control channel that is invisible to traditional network-based C2 detection.

The detection logic focuses on the trust-graph asymmetry: legitimate AWS messaging follows known producer-consumer relationships; covert C2 introduces new trust relationships that were not previously present. The Sigma rule surfaces EventBridge PutTargets, SNS Subscribe, and SQS SetQueueAttributes operations whose target is outside the organisation’s approved partner-account allowlist.

Primary AWS attack surface

EventBridge (custom and default buses) · SNS topics · SQS queues · Lambda event-source mappings · cross-account event flows

Key techniques covered

T1071 (Application Layer Protocol) · T1567 (Exfiltration Over Web Service) · T1090 (Proxy)

Sample hunt query

Surfaces SNS-as-C2 setup via external HTTPS subscription

-- SNS topic subscription pointing to external HTTPS endpoint
SELECT eventTime, userIdentity.arn AS principal,
       requestParameters.topicArn AS topic,
       requestParameters.endpoint AS subscription_endpoint
FROM cloudtrail_logs
WHERE eventName = 'Subscribe' AND eventSource = 'sns.amazonaws.com'
  AND requestParameters.protocol IN ('http', 'https')
  AND requestParameters.endpoint NOT LIKE '%trusted-partner-domain%';

Read Hunt 05 in Full →

HUNT 06 · CRITICAL · SQL-POWERED DATA HEIST

Athena and S3 Data Lake Exfiltration

AWS Athena gives any identity with execute privileges a query engine that can read everything they have IAM access to and ship the results to a destination they choose. This is data exfiltration at the speed of SQL. The hunt covers three Athena exfiltration patterns: large-scan queries to an attacker-controlled result bucket, Glue Data Catalog enumeration bursts as reconnaissance for the bulk query, and S3 Select selective exfiltration that bypasses Athena entirely.

The detection logic monitors Athena query execution metadata (data scanned, result location), Glue catalog API calls (GetDatabase, GetTable, GetPartitions), and S3 Select operations against data-lake buckets. The high-fidelity alert is an Athena query that scanned more than ten gigabytes whose result location is not on the organisation’s approved-result-bucket allowlist.

This is a critical-tier risk because Athena’s scaling characteristics make the single-query exfiltration of an entire data lake operationally feasible. A determined operator with a working SELECT can drain a petabyte-scale data lake in hours.

Primary AWS attack surface

Athena (workgroup, query history) · S3 (data events, result buckets) · Glue Data Catalog · Lake Formation grants

Key techniques covered

T1530 (Data from Cloud Storage Object) · T1567.002 (Exfiltration to Cloud Storage) · T1213 (Data from Information Repositories)

Sample hunt query

Surfaces Athena-powered data-lake exfiltration

-- Athena query scanning >10 GB to non-baseline result location
SELECT query_id, principal, query_text, result_location,
       data_scanned_bytes / 1024 / 1024 AS scanned_mb
FROM athena_query_history
WHERE data_scanned_bytes > 10737418240
  AND result_location NOT LIKE 's3://approved-results-bucket/%'
ORDER BY data_scanned_bytes DESC;

Read Hunt 06 in Full →

HUNT 07 · CRITICAL · ORG-LEVEL COMPROMISE

AWS Organizations Compromise: Multi-Account Federation Attack

AWS Organizations centralises governance — and that centralisation creates a high-value attack target. An attacker who compromises the right role in the management account can pivot into every member account in the organisation. This hunt covers the four most-exploited multi-account compromise patterns observed in 2025-2026 incident response.

The patterns are: AssumeRole chain pivoting (A → B → C identity laundering across accounts), Service Control Policy bypass via management-account access, delegated administrator abuse through compromised delegated-admin accounts, and AWS SSO and identity-store abuse that creates new SSO users with broad permissions across the organisation.

The detection logic requires cross-account telemetry stitching. The AssumeRole event in account A and the AssumeRole event in account B can be correlated by requestId. The Sigma rule fires when an AssumeRole chain of length three or more is observed within a 30-minute window. Additional detections cover SCP modifications outside the change window and SSO administrative actions outside business hours.

Primary AWS attack surface

AWS Organizations · management account · Service Control Policies · AWS SSO · IAM Identity Center · cross-account trust policies

Key techniques covered

T1078.004 (Valid Accounts: Cloud Accounts) · T1562 (Impair Defenses) · T1098.003 (Account Manipulation: Additional Cloud Roles)

Sample hunt query

Surfaces multi-account AssumeRole pivoting

-- AssumeRole chain of length 3 or more (org-level pivot)
WITH chains AS (
  SELECT requestId, principal, assumed_arn, eventTime
  FROM cloudtrail_logs WHERE eventName = 'AssumeRole'
)
SELECT a.principal, a.assumed_arn AS hop1, b.assumed_arn AS hop2, c.assumed_arn AS hop3
FROM chains a
JOIN chains b ON b.principal = a.assumed_arn AND b.eventTime BETWEEN a.eventTime AND a.eventTime + INTERVAL '30 minutes'
JOIN chains c ON c.principal = b.assumed_arn AND c.eventTime BETWEEN b.eventTime AND b.eventTime + INTERVAL '30 minutes';

Read Hunt 07 in Full →

04 · The full AWS attack surface map

The seven hunts above cover a substantial portion of the AWS attack surface, but to deploy a complete cloud threat hunting program you need to see the full map. The table below catalogues the AWS attack surface by category, the primary services in each category, the most common attacker objectives, and the corresponding hunt or detection control.

The pattern across all twelve surface categories is consistent: every category has documented attack patterns, the patterns are observable in some form of telemetry, and the hunt or control already exists or can be built. The work is the prioritisation and the discipline of running them.

05 · MITRE ATT&CK Cloud Matrix coverage

The MITRE ATT&CK Cloud Matrix is the canonical reference for cloud adversary tradecraft. The seven hunts in this library collectively cover techniques across eight of the eleven matrix tactics. The coverage table below maps each tactic to the hunt(s) that address it, with notable techniques called out.

The three tactics not directly covered are Reconnaissance (pre-engagement, usually outside the cloud-environment perimeter), Resource Development (attacker infrastructure setup, also pre-engagement), and the rarely-relevant Inhibit Response Function category. For complete kill-chain coverage, supplement the library with external attack-surface monitoring and inbound-email security controls.

06 · Essential AWS telemetry sources for threat hunting

Hunts without telemetry are hunts that produce false negatives. The telemetry inventory below catalogues the AWS data sources every cloud threat hunting program needs, the analytical purpose each one serves, and the configuration steps required to make the data hunt-ready.

The foundation tier (non-negotiable)

1. Multi-region CloudTrail with management events. Enable in every region, including unused ones. Configure a dedicated org trail aggregating all member accounts. Validate that event selectors do not exclude any high-value event sources.
2. CloudTrail data events on highest-value resources. Enable for the top S3 buckets, Lambda functions, DynamoDB tables, and KMS keys. The marginal cost is modest; the detection-coverage gain is substantial.
3. VPC Flow Logs. Enable across every production VPC, version 5 schema, with all-field capture. Land in centralised log storage with retention sufficient for retrospective hunting (90 days minimum, 365 days preferred).
4. Route 53 Resolver query logs. Capture DNS resolution from VPC-internal sources. Essential for DNS-based C2 detection and exfiltration hunting.
5. GuardDuty findings. Enable in every region with Runtime Monitoring on. Stream findings to your SIEM via EventBridge, not polling.

The visibility tier (high-yield additions)

6. S3 server access logs on buckets storing sensitive data. Complement to CloudTrail data events.
7. Lambda CloudWatch Logs for production functions. Captures function-level execution detail.
8. EC2 instance endpoint telemetry. Process creation, file system events, and network calls inside instances. Closes the IMDS-pivot and slow-and-low movement blind spots.
9. Container runtime telemetry on ECS and EKS workloads. Process, file, and network events from inside containers.
10. Athena query history. Stream to SIEM. Closes the data-lake exfiltration blind spot.
11. EventBridge event-bus configurations. Audit cross-account trust relationships.
12. Glue Data Catalog audit. Closes data-catalog reconnaissance blind spot.

The advanced tier (for mature programs)

13. VPC traffic mirroring for selected workloads. Provides packet-level visibility for high-value VPCs.
14. AWS Config configuration items. Drift detection and configuration-change auditing.
15. AWS Security Hub finding aggregation across regions and accounts.
16. Macie sensitive-data inventory for high-value S3 buckets.
17. Inspector findings for vulnerability context on EC2 and ECR images.
18. Detective behavior graphs for investigation context.

A cloud threat hunting program with foundation-tier telemetry only is operationally credible. Adding visibility-tier telemetry closes the largest categories of blind spot. Advanced-tier telemetry is differentiating for mature programs and especially valuable in regulated industries.

07 · The cloud threat hunter’s toolkit

A modern cloud threat hunter operates with a recognisable set of tools, query languages, and reference materials. The toolkit below is the practical kit used by senior cloud threat hunters in production environments.

Query and analysis platforms

• A SQL-style query interface over CloudTrail logs. Amazon Athena against CloudTrail S3 bucket is the canonical option. Alternatives include any modern SIEM with a SQL-style query language. The skill is portable; the tooling is environment-specific.
• A log-streaming aggregation layer. CloudWatch Logs, EventBridge event bus, or Kinesis Firehose feeding into a SIEM. Real-time matters for high-severity rules; batch is acceptable for retrospective hunts.
• A graph or correlation engine. For AssumeRole chain reconstruction and cross-account telemetry stitching. Native graph databases or correlation features in modern SIEMs both work.

Detection content management

• A detection-as-code repository. Version-controlled hunts, Sigma rules, response playbooks. The detection portfolio lives in source control alongside the application code.
• A Sigma converter. Open-source converters translate Sigma rules into the SIEM-native query language at deployment time.
• A test harness for detection rules. Synthetic events for regression testing, false-positive baselines for tuning.

Reference materials

• The MITRE ATT&CK Cloud Matrix for tactic and technique reference.
• The AWS service event reference for every event source you hunt. Bookmark the event-source pages for CloudTrail, S3, Lambda, KMS, EventBridge, SNS, SQS, IAM, STS, Organizations.
• Public cloud-incident reports for case-study reading. Aim for one major report per month, internalised end-to-end.
• The HuntIntel operator console for continuously refreshed adversary cluster attribution and MITRE technique mappings. Sign in at huntintel.hackforlab.com and join your hunts to the live intelligence layer.

Skills

• SQL fluency. The primary cloud hunt query language. Window functions, time-series operations, and recursive CTEs matter.
• Regular expressions. The universal pattern-matching primitive. Lexical patterns in log fields are everywhere.
• JSON path syntax. CloudTrail events are deeply-nested JSON. Comfortable nested-field extraction is essential.
• AWS service knowledge depth. Hunt patterns depend on understanding what each service actually does, not just the documentation summary.
• Threat modelling. The ability to think like an adversary against a given AWS environment.

08 · The 14-week deployment plan

Running all seven hunts in a single quarter is a stretch goal, not a starting commitment. The deployment plan below sequences the hunts over fourteen weeks, with the foundational hunts first and the operationally-complex hunts later. Adjust pace to match your team’s capacity.

At the end of fourteen weeks the program has seven production hunts covering more than eighty percent of the AWS attack surface. The maintenance commitment from week fifteen forward is a quarterly tuning pass on each hunt and a quarterly review of the hunt portfolio against the latest published cloud-incident reports.

09 · Success metrics and KPIs for the cloud hunt program

A cloud threat hunting program is measured on operational outcomes, not on hunt-count vanity metrics. The five KPIs below are the minimum set for executive reporting.

Practitioner tip. Pair the technical metrics with one human metric: cross-training rotation. If the same engineer has authored 80 percent of the production hunts, the program has a bus factor of one. Rotate hunt authorship explicitly; every cloud hunter should ship at least one production rule per quarter.

10 · AWS adversary tradecraft patterns observed in 2026

The hunts above target specific techniques. The tradecraft below describes the operational style of cloud-aware adversaries that the techniques are part of. Understanding the style helps the hunt designer anticipate variants.

Style 01 · The patient enumerator

Sophisticated AWS operators do not begin with action. They begin with enumeration: ListBuckets, GetCallerIdentity, ListRoles, ListAttachedRolePolicies, DescribeInstances. The enumeration is paced to stay below GuardDuty’s anomaly threshold. By the time the action begins, the operator knows the environment better than most defenders do.

Style 02 · The IMDS-pivot expert

The compromise of one EC2 instance is the gateway to the role attached to it. The operator pulls credentials from the Instance Metadata Service and uses them with their own tooling from outside the environment. CloudTrail records the role’s API calls; it does not record the IMDS request that supplied the credentials. The compensating telemetry is the host-level endpoint sensor.

Style 03 · The cross-account pivoter

One account is rarely the goal. The cross-account pivot moves from the compromised account into an adjacent account through legitimate AssumeRole, then to a third account, then to the production account. Each hop changes the source-IP attribution. Reconstructing the chain requires request-ID correlation across CloudTrail records from multiple accounts.

Style 04 · The infrastructure-as-code adversary

Persistent operators do not click in the console. They deploy infrastructure-as-code that creates persistence, encodes their access path, and survives reactive remediation. A compromised CloudFormation stack or Terraform deployment produces resources that look legitimate until a careful audit of the resource graph reveals the unauthorised additions.

Style 05 · The serverless-native operator

The most sophisticated current AWS adversaries are increasingly running entirely inside serverless services. A compromised Lambda function publishes data to an EventBridge bus the operator subscribes to. There is no EC2 to forensicate, no container to inspect. The compromise lives entirely in code and configuration.

Style 06 · The KMS-aware operator

The 2025-2026 emergence of KMS ransomware reflects the maturation of cloud-aware adversaries. The operator knows that re-encryption with their own key is faster, quieter, and less reversible than dropping a malicious binary. The defensive posture shift is unforgiving: credentials rotation does not undo a key-policy change.

The hunt patterns in this library are designed against this composite tradecraft profile, not against the on-premises threat models of five years ago. If your hunt program is based on older threat assumptions, the seven hunts here are the upgrade path.

11 · Building a cloud threat hunting program from scratch

If your organisation has substantial AWS workloads but no dedicated cloud threat hunting practice today, the path to a credible program runs through five phases over twelve to eighteen months.

Phase 01 · Telemetry baseline (months 1-3)

Goal: every foundation-tier telemetry source is enabled, captured to centralised storage with appropriate retention, and queryable from a SIEM or analytics platform. Output: a one-page telemetry inventory documenting source, configuration, retention, and query interface for each.

Phase 02 · First three hunts (months 4-6)

Goal: ship Hunts 01, 02, and 03 (CloudTrail blind spots, KMS ransomware, GuardDuty evasion) as production detections with response playbooks. Output: three production rules in the detection portfolio, with documented owners, false-positive budgets, and tuning notes.

Phase 03 · Detection-as-code discipline (months 7-9)

Goal: every hunt and detection rule lives in version control. The detection portfolio is queryable, auditable, and reproducible. Output: a detection-as-code repository with the four established hunts, deployment automation, and a test harness.

Phase 04 · Complete the seven-hunt library (months 10-15)

Goal: ship Hunts 04, 05, 06, and 07. Output: the complete library deployed, every hunt with a response playbook, MITRE ATT&CK coverage map at >80%.

Phase 05 · Program maturity (months 16-18)

Goal: the hunt program becomes a maintained capability, not a project. KPI reporting is monthly. The portfolio is reviewed quarterly. New cloud-incident reporting feeds new hunt candidates. Output: a credible monthly metrics dashboard and an operationalised quarterly review cadence.

Three years into a program built this way, the organisation has a cloud-native hunt portfolio, a maintained detection portfolio, and a cloud threat hunting team with verifiable production output. That is the credible end state.

12 · Common pitfalls and how to avoid them

The journey to a credible cloud hunt program is shorter than the duration of the program. The pitfalls below are the most common ones that delay or derail the practice.

Pitfall 01 · Treating GuardDuty as a complete detection layer

GuardDuty is a foundational control, not a complete layer. Programs that treat its absence of findings as “all clear” miss the entire category of techniques it does not catch. The mitigation is layered defence: every hunt in this library exists because GuardDuty does not catch its target pattern.

Pitfall 02 · Hunting without identity attribution on telemetry

VPC Flow Logs without IAM principal attribution are usable for network forensics but not for hunt-grade detection. The engineering to join flow records to ENI owners and IAM roles is non-trivial but mandatory. Without it, hunts produce signals without targets for response.

Pitfall 03 · Skipping the telemetry baseline

Hunts deployed against incomplete telemetry produce false negatives that look like clean results. Before deploying any hunt, audit the telemetry source it depends on. If the source is incomplete, fix that first.

Pitfall 04 · No response playbooks attached to detections

A detection that fires without a documented response action is noise that an on-call analyst learns to suppress. Every rule promoted to production needs a one-page playbook with: who gets paged, what to check first, what to escalate, what evidence to preserve.

Pitfall 05 · Static allowlists that never get reviewed

The KMS-admin allowlist, the partner-account allowlist, the approved-result-bucket allowlist — all need periodic review. Static allowlists become attack surfaces themselves when forgotten roles or stale partner relationships accumulate.

Pitfall 06 · Building hunts only for what is already happening

Reactive hunt design produces hunts that catch yesterday’s tradecraft. Proactive hunt design reads cloud incident reports as case studies and converts them into hypotheses before the technique becomes widely observed. The seven hunts in this library are a mix of both reactive and proactive patterns.

Pitfall 07 · No cross-training on the hunt portfolio

A hunt portfolio where one engineer owns most of the rules is a bus-factor-of-one program. The cross-training discipline — every hunter ships at least one production rule per quarter, peer reviews are mandatory — is the structural fix.

13 · The cloud threat hunter career path

Cloud threat hunting has emerged as a distinct career specialism over the past three years. The path from a traditional SOC analyst role or a junior cloud security engineer role to a senior cloud threat hunter typically runs eighteen to thirty-six months.

Foundational role · Cloud SOC analyst

Triage cloud alerts. Close GuardDuty findings. Investigate suspicious sign-ins. Begin building familiarity with CloudTrail event structure. The role is operational; the learning is foundational.

Bridge role · Cloud detection engineer

Build detection rules from analyst experience. Maintain the detection portfolio. Tune false-positive budgets. Begin proposing hunts. The role is creative; the output is the production rule.

Practice role · Cloud threat hunter

Run hypothesis-driven hunts against telemetry. Ship hunts as production detections. Author the cloud-specific tradecraft documentation. The role is investigative; the output is coverage.

Senior role · Principal cloud threat hunter

Lead hunts across teams. Build the hunt programme. Mentor other hunters. Publish externally on tradecraft and detection patterns. The role is influential; the output is the practice itself.

The lateral specialisations from each step include incident response (cloud-specific IR is a high-value adjacent skill), security architecture (the hunt patterns inform the architecture), and red-team-side cloud penetration testing (the inverse skill set produces complementary defensive insight). For the foundational skills that underpin all of this, see the 15-month threat hunter career roadmap.

14 · The future of AWS threat hunting

Two structural forces will reshape AWS threat hunting between 2026 and 2030. Cloud hunters who prepare for them now will be operating with the next-generation toolkit before the rest of the industry catches up.

Force 01 · AI-augmented hunt query generation

Large language models are increasingly capable of converting natural-language hunt hypotheses into runnable query patterns. The hunter writes “find identities that exhibit credential-enumeration behaviour from a region with no historical baseline” and the model produces a starter query against the configured telemetry sources. The discipline shifts from writing queries to evaluating their precision.

The practice implication: hunters who can verify model output remain employable; hunters who can only run pre-written queries face commoditisation. The verification discipline is the durable skill.

Force 02 · AI-aware adversaries

Adversaries are also using language models — for reconnaissance summarisation, evasion-pattern generation, and code obfuscation. The tradecraft cycle that previously took quarters to evolve now evolves in weeks. Detection content must refresh accordingly.

The combination of these two forces accelerates the cycle of every aspect of the hunt practice. Telemetry must be more comprehensive. Detection content must refresh more often. Hunter judgment must be more precise. The hunt programs that survive are the ones that build the maintenance discipline now.

16 · The complete AWS threat hunting archive — all 19 prior posts

The seven flagship hunts above are the 2026 state of the practice. They build on more than two years of AWS threat hunting publishing — nineteen earlier posts that established the foundations, the service-specific hunt patterns, the VPC Flow Log analytics series, and the cloud-malware case studies that the library now extends. Every archive post below remains useful, current, and worth reading in its own right.

The archive is organised by theme rather than chronology so you can navigate to the area most relevant to your environment. For a chronological recommended reading order, jump to §17.

16.1 · Cloud telemetry foundations (2 posts)

Read these first. The foundational material every cloud SOC analyst needs before going deeper into specific hunt patterns.

16.2 · AWS service-specific hunts (3 posts)

Deep dives into the highest-impact AWS service surfaces. Each post pairs directly with one or more of the seven flagship hunts above.

16.3 · The VPC Flow Logs deep-dive series (9 posts)

The most extensive VPC Flow Log threat hunting content published anywhere. Nine consecutive posts cover detection patterns from beacon analysis through to insider threat detection, lateral movement graph analysis, and Markov-chain kill-chain reconstruction. These are analytical-depth posts — assume comfort with statistical methods.

16.4 · Cloud attack-chain detection (1 post)

The bridge between the VPC Flow Log series and the new 2026 flagship hunts.

16.5 · Cloud malware case studies (4 posts)

Adversary-specific case studies covering documented cloud-malware families. Useful for learning the operational pattern of a named campaign before generalising to the hunt template.

17 · Recommended reading order — from foundations to the 2026 state of the practice

A new cloud SOC analyst landing at HackForLab today and wanting to learn AWS threat hunting end-to-end should follow this reading sequence. Total reading time is roughly thirty to forty hours; expect to revisit several posts as your practice matures.

Practitioner tip. Read steps 01-04 in the first week, steps 05-07 over the next month, and steps 08-10 in the third month. By the end of a quarter you have read every published AWS hunting post on this site and built the practical foundation to ship cloud hunts in your own environment.

18 · The complete AWS threat hunting publishing catalogue — 27 posts

For completeness and for indexing, the table below is the canonical inventory of every published AWS threat hunting post on this site. Twenty-seven posts total: nineteen archive posts (2024-2026), seven flagship 2026 hunts, and this hub. Bookmark it.

Twenty-seven posts. Twenty-one months of publishing. Roughly eighty thousand words of original AWS threat hunting content. This library is now the most comprehensive single AWS threat hunting reference available on the open web — and it grows quarterly as new tradecraft emerges.

19 · FAQ