AWS CloudTrail Leaves 25% Of Attack Traces Invisible: How To Close The Logging Gap Before Hackers Exploit T1552005 + Video

Introduction:

Default AWS CloudTrail configurations capture only about 75% of primary log sources, leaving a dangerous 25% gap where attackers operate without generating detection events. This blind spot includes 13 critical log sources that are off by default, each hiding specific MITRE ATT&CK techniques such as T1552.005 (unsecured credentials via EC2 instance metadata) and T1651 (cloud administration command obscurity).

Learning Objectives:

Identify the 13 off‑by‑default AWS log sources and map them to MITRE ATT&CK techniques (T1552.005, T1651, T1021.007, T1040, T1190).
Enable VPC Flow Logs, Session Manager logs, and WAF logs using AWS CLI and console commands to detect metadata credential harvesting and hidden command execution.
Build detection rules that correlate incomplete CloudTrail events with supplemental logs to close the logging gap.

You Should Know:

The Silent Threat: T1552.005 – Unsecured Credentials via EC2 Instance Metadata

Attackers query the instance metadata service (IMDS) at `169.254.169.254` to steal IAM role credentials. CloudTrail writes zero events for these requests. The only reliable detection path is VPC Flow Logs – also off by default.

Step‑by‑step guide to simulate and detect:

Simulate the attack (Linux on an EC2 instance with IMDSv1 enabled):

Query metadata for IAM role credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/YourRoleName

Verify CloudTrail blind spot – Check CloudTrail event history; no `GetCredentials` or metadata access events appear.

Enable VPC Flow Logs to capture metadata traffic (destination port 80 to 169.254.169.254):

Create VPC Flow Log to CloudWatch Logs
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-12345678 \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name my-vpc-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole

4. Detection query (CloudWatch Logs Insights):

filter dstAddr = "169.254.169.254" and dstPort = 80 and action = "ACCEPT"
| stats count() by srcAddr, interfaceId

What this does: Metadata queries become visible as network flows, allowing you to alert on unexpected internal HTTP requests to the IMDS endpoint.

2. T1651 & T1021.007: What SSM SendCommand Hides

CloudTrail logs that `ssm:SendCommand` ran, but never logs the actual command content (e.g., rm -rf /data, exfiltration scripts). Session Manager logs contain the command payload – off by default.

Step‑by‑step to enable Session Manager logging:

Enable S3 logging for Session Manager (AWS CLI):

aws ssm update-service-setting \
--setting-id arn:aws:ssm:us-east-1:123456789012:servicesetting/ssm/manager/s3-logging \
--setting-value "{\"S3BucketName\":\"my-session-logs\",\"S3KeyPrefix\":\"sessionmanager\"}"

2. Verify logging is on:

aws ssm get-service-setting --setting-id arn:aws:ssm:us-east-1:123456789012:servicesetting/ssm/manager/s3-logging

3. Detection rule – Correlate CloudTrail `SendCommand` events with Session Manager logs:

-- Athena query on CloudTrail table
SELECT userIdentity.arn, eventTime, requestParameters.commandId
FROM cloudtrail_logs
WHERE eventName = 'SendCommand'

Then cross‑reference commandId with Session Manager logs in S3 to extract the actual command string.

Windows alternative: For SSM on Windows instances, enable PowerShell module logging and forward to CloudWatch.

3. T1040 Network Sniffing: Traffic Mirroring Blind Spot

Attackers using traffic mirroring to sniff VPC traffic leave traces of the mirror session setup in CloudTrail, but the captured traffic content is never logged. VPC Flow Logs provide metadata but not packet payloads. You need flow logs to detect unusual mirror destinations.

Step‑by‑step to configure and detect mirror abuse:

Create a traffic mirror filter for suspicious outbound traffic:

aws ec2 create-traffic-mirror-filter \
--description "Detect mirror to unknown IP"
aws ec2 create-traffic-mirror-filter-rule \
--traffic-mirror-filter-id tmf-12345678 \
--rule-number 10 \
--rule-action accept \
--source-cidr-block 10.0.0.0/16 \
--destination-cidr-block 0.0.0.0/0 \
--protocol 6

Enable VPC Flow Logs (as in section 1) and look for traffic to common mirror targets:
```
filter dstAddr like /^(192.0.2.|203.0.113.)/ and action = "ACCEPT"
```
Mitigation: Restrict IAM policies that allow `ec2:CreateTrafficMirrorSession` to only trusted roles.
T1190 Web Exploitation: WAF Logs to the Rescue

Web application exploits (SQLi, XSS, path traversal) leave no CloudTrail footprint unless AWS WAF Web ACL logs are enabled. Attackers can scan, inject, and exfiltrate while CloudTrail remains silent.

Step‑by‑step to enable WAF logging:

Enable logging on a Web ACL (AWS CLI):

aws wafv2 put-logging-configuration \
--logging-configuration '{
"ResourceArn": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/MyWebACL/abcd1234",
"LogDestinationConfigs": ["arn:aws:logs:us-east-1:123456789012:log-group:aws-waf-logs-myacl"]
}'

Create a Kinesis Firehose for WAF logs if sending to S3:

aws logs create-log-group --log-group-name aws-waf-logs-myacl

Detection query (CloudWatch Logs Insights on WAF logs):

filter action = "BLOCK" and terminatingRuleId like /SQLi|XSS/
| stats count() by httpRequest.clientIp, httpRequest.uri

Proactive hardening: Deploy WAF with OWASP top‑10 rule groups and enable logging before any public application goes live.
Automating Log Enablement: CLI Commands from the Mitigant Catalog

The full catalog of 13 log sources with executable CLI commands is available at threats.mitigant.io. Below is a script to enable the top five missing sources in one go.

Linux / macOS script (AWS CLI):

!/bin/bash
 Enable missing log sources
 1. VPC Flow Logs
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-xxxxx --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name vpc-flow-logs --deliver-logs-permission-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/FlowLogsRole

<ol>
<li>Session Manager logs
aws ssm update-service-setting --setting-id arn:aws:ssm:us-east-1:$(aws sts get-caller-identity --query Account --output text):servicesetting/ssm/manager/s3-logging --setting-value "{\"S3BucketName\":\"ssm-session-logs\"}"</p></li>
<li><p>WAF Web ACL logs (replace WebACL ARN)
aws wafv2 put-logging-configuration --logging-configuration '{"ResourceArn":"arn:aws:wafv2:us-east-1:XXXXXX:global/webacl/MyWebACL/ID","LogDestinationConfigs":["arn:aws:logs:us-east-1:XXXXXX:log-group:aws-waf-logs"]}'</p></li>
<li><p>S3 Access Logs (for bucket-level attacks)
aws s3api put-bucket-logging --bucket my-critical-bucket --bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"my-log-bucket","TargetPrefix":"s3-access-logs/"}}'</p></li>
<li><p>RDS Enhanced Monitoring
aws rds modify-db-instance --db-instance-identifier mydb --monitoring-interval 60 --monitoring-role-arn arn:aws:iam::XXXXXX:role/rds-monitoring-role

Windows (PowerShell with AWS Tools):

 Enable VPC Flow Logs
New-EC2FlowLog -ResourceType VPC -ResourceId vpc-xxxxx -TrafficType ALL -LogDestinationType cloud-watch-logs -LogGroupName vpc-flow-logs -DeliverLogsPermissionArn "arn:aws:iam::xxxxx:role/FlowLogsRole"

Detection Engineering: Correlating MITRE Techniques with Log Sources

Build a detection rule set that pairs each MITRE technique with its enabled log source:

| MITRE Technique | Log Source (Off by Default) | Detection Logic |

|-||-|

Step‑by‑step to deploy a custom GuardDuty‑style rule using EventBridge:

Create an EventBridge rule that matches CloudTrail `SendCommand` events.
Trigger a Lambda function that fetches the Session Manager log from S3 for that commandId.
If the command contains sensitive strings (e.g., cat /etc/shadow), send an alert to SNS.

 Lambda snippet (Python 3.9)
import boto3
def lambda_handler(event, context):
command_id = event['detail']['requestParameters']['commandId']
s3 = boto3.client('s3')
obj = s3.get_object(Bucket='ssm-session-logs', Key=f'sessionmanager/{command_id}.log')
log_content = obj['Body'].read().decode('utf-8')
if 'base64' in log_content or 'nc -e' in log_content:
sns = boto3.client('sns')
sns.publish(TopicArn='arn:aws:sns:region:account:alerts', Message=f'Suspicious SSM command: {command_id}')

What Undercode Say:

Key Takeaway 1: Default cloud logging configurations are deliberately minimal to reduce costs and storage, but they create a predictable attack surface. The 13 off‑by‑default logs are not optional for mature security programs – they are mandatory for detecting techniques like T1552.005 that leave zero CloudTrail events.
Key Takeaway 2: Detection engineering must shift from relying solely on control‑plane logs (CloudTrail) to aggressively enabling data‑plane logs (VPC Flow Logs, Session Manager, WAF). The attacker’s edge is the gap between what you assume is logged and what actually is. Automating enablement via CLI (as in the Mitigant catalog) closes that gap at scale.

Prediction:

Over the next 12–18 months, we will see a surge in cloud breaches that exploit the 25% logging gap, particularly targeting IMDS credential harvesting (T1552.005) and blind SSM commands. In response, AWS and other CSPs will likely introduce “audit‑grade” logging tiers that enable these 13 sources by default for compliance‑sensitive workloads, but until then, security teams must proactively implement the CLI commands outlined above. Attackers are already scanning for environments with default logging; the window to close the gap is narrow.

▶️ Related Video (72% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Aondona Cloudsecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post