CloudTrail is the cornerstone of AWS threat detection — and yet sophisticated adversaries operate freely inside it for hours because they know exactly which events it does not capture. This article maps every structural blind spot in the default CloudTrail configuration, the techniques adversaries use to exploit each one, and the compensating hunt patterns that close the visibility gap.
If your AWS threat-detection strategy assumes CloudTrail captures everything that matters, you have a structural problem. CloudTrail is excellent at logging control-plane API calls but it deliberately omits several categories of activity for cost, scale, or design reasons. Adversaries who have done their homework — and most have — choose those omitted categories on purpose.
This first part of the AWS Threat Hunting series catalogues twelve specific CloudTrail blind spots, ranks them by exploitation likelihood, and ships hunt queries that surface activity in each gap using compensating data sources. Print this article and pin it to your detection-coverage spreadsheet. Every cloud SOC has at least four of these gaps active right now.
HuntIntel ships continuously refreshed adversary cluster attribution and MITRE technique mappings — the data that turns a static hunt into a living one. Stop hunting yesterday’s IOCs. Hunt today’s techniques.
01 · Why this hunt matters
CloudTrail is a default-on service in every AWS account, and most security teams treat it as the canonical audit log. That assumption is correct for the use cases CloudTrail was designed for — management-plane API calls in commercial regions — and dangerously wrong for the use cases it was not.
Three forces make blind-spot hunting urgent in 2026. First, the surface area of AWS has grown faster than CloudTrail’s default-capture coverage. New services routinely launch with data-plane events disabled by default. Second, adversaries automate cross-region operations to deliberately rotate into regions where the victim has not enabled CloudTrail. Third, the financial pressure to control CloudTrail data-event costs has pushed many organisations to selectively disable categories of capture — creating exploitable gaps that did not exist five years ago.
The hunt is straightforward but counter-intuitive: look for the activity that should produce CloudTrail events but doesn’t, using compensating telemetry. The hunt patterns below are organised by gap category and ship with the compensating data source identified for each.
02 · Adversary tradecraft
Adversary tradecraft in this space falls into three operational categories.
The 12 blind spots, ranked by exploitation likelihood
- S3 Object-Level Data Events. By default CloudTrail does not log GetObject, PutObject, or DeleteObject calls. Adversaries who exfiltrate from S3 buckets operate in this gap.
- Lambda Function Invocations. Function invocation events are data-plane and disabled by default. Adversaries who use Lambda as a covert execution layer rely on this.
- DynamoDB Data Events. Read and write operations on tables are not captured by default. Slow-and-low data exfiltration from DynamoDB is invisible.
- EC2 Instance Metadata Service. IMDS requests originate inside the instance and are completely invisible to CloudTrail. The pivot from a compromised instance to AssumeRole on the role credentials is the canonical attack pattern.
- Disabled regions. If CloudTrail is enabled in only a subset of regions, adversary activity in an unmonitored region produces zero events. Adversaries probe for unmonitored regions before staging.
- Container runtime events. Container creation and destruction inside ECS or EKS clusters are captured at the cluster level but not at the container-runtime level. East-west container movement is invisible without runtime sensors.
- Inside-VPC traffic. Network flows inside a VPC do not appear in CloudTrail. VPC Flow Logs are the compensating source — and they are also often selectively enabled.
- VPC endpoint-private API calls. Calls routed through interface endpoints can be captured but require explicit configuration. Adversaries use private endpoints to evade boundary monitoring.
- Organization-level events for delegated administrator. Some org-level actions are captured in the management account only. Adversaries who compromise a delegated-admin account exploit this asymmetry.
- Service-linked role activity. Actions performed by service-linked roles can be filtered out at the trail-event-selector level. Adversaries who hijack service-linked role policies operate under reduced visibility.
- Read-only API calls when only write events are captured. A common cost optimisation is to capture only write events. Reconnaissance is invisible.
- Insights events and management events for specific event sources. If event selectors exclude an event source, that source’s actions disappear entirely. Adversaries enumerate which event sources have been excluded.
The unifying adversary pattern
The unifying pattern is straightforward: adversaries prefer the gaps. A sophisticated operator running an AWS intrusion will, when they have a choice between two functionally equivalent techniques, choose the one that produces fewer CloudTrail events. This means that an unusually high ratio of compensating-telemetry events to CloudTrail events for an identity, a region, or a service is itself a signal worth hunting on.
03 · Telemetry needed
The compensating telemetry stack that closes the CloudTrail blind spots:
- VPC Flow Logs — east-west and north-south network behaviour. Closes blind spots 6, 7, and 8.
- S3 Server Access Logs / Access Analyzer — object-level S3 access. Closes blind spot 1 when enabled.
- Lambda CloudWatch Logs / function execution logs — Lambda invocations and runtime behaviour. Closes blind spot 2.
- Container runtime telemetry — process creation, file system events, network calls inside containers. Closes blind spot 6.
- DynamoDB Streams / database audit logs — table-level operations. Closes blind spot 3.
- EC2 host-level telemetry — endpoint detection agent on the instance. Closes blind spot 4.
- Multi-region CloudTrail with all regions enabled — closes blind spot 5.
- Organization-trail aggregation — closes blind spot 9.
- IAM Access Analyzer + Access Advisor — closes blind spot 10 partially.
The single most impactful change most organisations can make: enable management events plus data events for the top three highest-value S3 buckets, the top five Lambda functions, and the top three DynamoDB tables. This costs more than the default but eliminates the largest categories of blind spot at a fraction of the cost of a breach.
Run this hunt against real adversary intelligence.
HuntIntel exposes every catalogued IOC with provenance, confidence, MITRE technique, and adversary cluster pre-mapped. Export Sigma in two clicks, push to your SIEM, ship coverage in minutes.
04 · Hunt queries
The hunts below assume CloudTrail logs are queryable via a SQL-style interface against the configured trail bucket. Adapt to your environment’s tooling.
Hunt query 01 — Identity with high compensating-telemetry to CloudTrail ratio
-- Identities producing far more VPC Flow / S3 access events than CloudTrail events
WITH ct_counts AS (
SELECT userIdentity.arn AS principal, COUNT(*) AS ct_events
FROM cloudtrail_logs
WHERE eventTime BETWEEN '2026-06-08' AND '2026-06-14'
GROUP BY userIdentity.arn
),
flow_counts AS (
SELECT principal, COUNT(*) AS flow_events
FROM vpc_flow_logs_with_principal_join
WHERE log_ts BETWEEN '2026-06-08' AND '2026-06-14'
GROUP BY principal
)
SELECT c.principal, c.ct_events, f.flow_events,
CAST(f.flow_events AS DOUBLE) / NULLIF(c.ct_events, 0) AS ratio
FROM ct_counts c
JOIN flow_counts f ON c.principal = f.principal
WHERE c.ct_events > 0 AND f.flow_events > 100
AND CAST(f.flow_events AS DOUBLE) / c.ct_events > 50
ORDER BY ratio DESC;
Hunt query 02 — IMDS pivot pattern (compensating EC2 telemetry)
-- Process on EC2 calling IMDS → AssumeRole on same role credentials within minutes
WITH imds_calls AS (
SELECT host_id, ts, process_image
FROM endpoint_telemetry
WHERE dst_ip = '169.254.169.254'
AND ts BETWEEN '2026-06-08' AND '2026-06-14'
),
assume_role AS (
SELECT principal, sourceIPAddress, eventTime
FROM cloudtrail_logs
WHERE eventName = 'AssumeRole'
AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
)
SELECT i.host_id, i.process_image, a.principal, a.sourceIPAddress
FROM imds_calls i
JOIN assume_role a ON a.eventTime BETWEEN i.ts AND i.ts + INTERVAL '5 minutes'
WHERE a.sourceIPAddress NOT IN (SELECT private_ip FROM corp_egress_baseline);
Hunt query 03 — Region skipping detection
-- Identity active in a region where they have no historical baseline
SELECT userIdentity.arn AS principal, awsRegion, COUNT(*) AS event_count
FROM cloudtrail_logs
WHERE eventTime BETWEEN '2026-06-08' AND '2026-06-14'
AND awsRegion NOT IN (
SELECT DISTINCT awsRegion
FROM cloudtrail_logs
WHERE eventTime > '2026-04-01' AND eventTime < '2026-06-01'
AND userIdentity.arn = principal
)
GROUP BY userIdentity.arn, awsRegion
HAVING event_count > 5;
05 · Sigma rule
The Sigma rule below detects the highest-fidelity blind-spot indicator: an identity that issues an unusually high volume of network or data-plane activity relative to its CloudTrail footprint. — or pull pre-mapped clusters from HuntIntel
title: AWS Identity High Data-to-Control-Plane Activity Ratio
id: 3a8b2c44-5d6e-4f12-9a0b-1c2d3e4f5a6b
status: experimental
description: |
Detects an IAM principal whose data-plane or network activity
vastly exceeds their CloudTrail control-plane footprint, indicating
potential use of CloudTrail blind spots for exfiltration or pivoting.
author: HackForLab
date: 2026/06/16
references:
- https://hackforlab.com/aws-cloudtrail-blind-spots-hunt-2026/
tags:
- attack.defense_evasion
- attack.t1562
- attack.exfiltration
logsource:
product: aws
service: cross-source
detection:
selection:
principal_type:
- 'iam_role'
- 'iam_user'
timeframe: 24h
aggregation: |
sum(data_plane_events) / NULLIF(sum(control_plane_events), 0) > 50
and sum(data_plane_events) > 1000
condition: selection
fields:
- principal
- data_plane_events
- control_plane_events
- regions
falsepositives:
- Bulk-data processing roles (allowlist by ARN)
level: medium
06 · Ship as a production detection
Production deployment of this detection requires the compensating telemetry pipeline to land in your SIEM with identity attribution. Two engineering steps are non-negotiable:
Step 1 · Identity enrichment of compensating telemetry. VPC Flow Logs do not naturally include the IAM principal making the call. You must join flow records to ENI ownership records and then to the role attached to the instance (or the principal that invoked the function). Without this join, the ratio metric is unanchored to identity.
Step 2 · Per-principal baselining over a sliding window. Some principals legitimately produce high data-to-control-plane ratios (data-processing service roles, batch ETL jobs). Maintain a rolling 30-day median ratio per principal and alert on deviations above 5x the median rather than on absolute thresholds.
Map this rule to T1562 (Impair Defenses) and T1530 (Data from Cloud Storage Object), and pair it with the response playbook below.
07 · False-positive considerations
Three categories of false positive dominate this rule’s noise floor.
Bulk data processing service roles. EMR clusters, AWS Glue jobs, and SageMaker training jobs legitimately produce huge data-to-control-plane ratios. Allowlist by ARN pattern.
Application identities behind load balancers. The role attached to a web tier behind an ALB will produce many object reads from a content bucket. Tune by destination — alerts should fire only when the data flows go to destinations outside the host’s 30-day baseline.
Logging and backup roles. Roles that ship logs to S3 or run backup pipelines will trip the rule. These should be enumerated explicitly and excluded.
A healthy noise floor for this rule, after baselining and allowlisting, is roughly two hits per week in a 500-account environment. More than that suggests insufficient baselining; fewer suggests overly aggressive allowlisting.
08 · Response actions
When this rule fires, the response sequence is: — Sign in to huntintel.hackforlab.com to pull the live catalogue and pivot on the cluster directly.
- Snapshot the identity’s session. Capture the active access keys and session tokens for the principal. Do not invalidate them yet — you want to observe what the operator does next while you investigate.
- Pull a 24-hour timeline of all activity by the principal. Include CloudTrail, VPC Flow, S3 access logs, and any endpoint telemetry from instances the principal touched.
- Identify the operating region and the destinations. If the destinations are outside your organisation’s normal egress baseline, escalate to incident response immediately.
- Rotate credentials. Once you have a complete picture, rotate the role’s session credentials and revoke any associated access keys.
- Add the indicator to your detection portfolio. Whatever technique surfaced this hit deserves its own dedicated detection if it does not have one.
09 · FAQ
Why doesn’t AWS log everything by default?
CloudTrail at full data-event capture would produce log volume that is impractically expensive for most accounts. The default-off design balances cost against visibility — but the trade-off shifts toward the adversary in any account that has not deliberately tuned event selectors for high-value resources.
How much does enabling data events cost?
Roughly an order of magnitude more than management events alone, though the exact figure depends on the access pattern of the data source. A common approach is to enable data events only on the top-N highest-value buckets, functions, and tables.
Are blind spots the same in every region?
The blind-spot categories are the same, but the operational risk varies by region. Regions used for data warehousing or content storage have higher relative risk; regions used only for compute or networking have lower relative risk.
Should we enable CloudTrail in every region even ones we don’t use?
Yes. Adversaries explicitly probe for unmonitored regions. The marginal cost is near zero in an unused region; the marginal visibility gain is high.
What if we have organisation trails?
Organisation trails close several blind spots but not all of them. Verify that data-event capture is enabled at the organisation-trail level for the highest-value resources, not only management-event capture.
How do we baseline the data-to-control-plane ratio?
Capture the ratio per principal for the last 30 days and store as a per-principal metric. Update weekly. Detection should fire on deviation from the principal’s own baseline, not on absolute thresholds.
HuntIntel turns adversary intelligence into hunt-ready queries and production detection rules — without the spreadsheet engineering. Run the hunt. Ship the rule. Track the coverage.
AWS Hunt Library (hub) ·
Threat Hunting pillar ·
Cloud Threat Hunting ·
Detection Engineering ·
All Cyber Threat posts
