Skip to content

Using elbaph

SethBodine edited this page May 27, 2026 · 1 revision

Using ELBaph

ELBaph is an active/passive AWS Elastic Load Balancer configuration auditor written in Go by Doyensec. It finds routing misconfigurations and logical vulnerabilities in ALBs that typical CSPM tools miss — not just "is WAF attached?" checks, but real exploitation-relevant issues such as IP gate bypass, CloudFront origin direct access, rule shadowing, and exposed backend targets.

  • Enumerates ALBs and NLBs across one or all enabled regions
  • Evaluates listener conditions — paths, host headers, source IP rules
  • Cross-references Target Groups and EC2 instance members across different ALBs
  • Analyses interactions with VPCs and CloudFront distributions
  • Performs targeted HTTP reachability probes to confirm whether backend targets are actually exposed
  • Generates an interactive topology.html diagram showing VPC → ALB → listener → rule → target group → target
  • All AWS API calls are read-only — no changes are made to the environment

Required Permissions

ELBaph requires the following minimum IAM policy. Route 53 permissions are optional but improve the alb-vhost-probe check (FQDN corpus and alias correlation).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:DescribeRules",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "ec2:DescribeRegions",
        "ec2:DescribeInstances",
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "*"
    }
  ]
}

See Cloud Access and Permissions for how to attach this policy before running a scan.

Prepare the Environment

No additional setup is required. The elbaph binary is pre-installed.

Ensure AWS credentials are configured before running. See Cloud Authentication via CLI.

Gather Data

Scan a Single Region

# Use whatever is in the default credential chain (env vars, ~/.aws/credentials, instance profile)
elbaph scan --region ap-southeast-2

# Use a named profile
elbaph scan --region us-east-1 -p my-pentest-profile

Scan All Regions

elbaph scan --all-regions
elbaph scan --all-regions -p my-pentest-profile

Authenticate with Inline Keys

# Static access key + secret (temporary STS creds: add --aws-session-token)
elbaph scan -r us-east-1 \
  --aws-access-key-id AKIAEXAMPLE \
  --aws-secret-access-key 'wJalrXUtnFEMI...'

# Inline STS temporary credentials
elbaph scan -r us-east-1 \
  --aws-access-key-id ASIAEXAMPLE \
  --aws-secret-access-key 'wJalrXUtnFEMI...' \
  --aws-session-token 'AQoXnyc4...'

Inline secrets are visible in process listings and shell history. Prefer env vars, a credentials file, or an IAM role where possible.

Authenticate from a Credentials File

# INI file in the same format as ~/.aws/credentials
elbaph scan -r us-east-1 \
  --aws-credentials-file ./readonly.creds \
  -p customer-audit

Run Specific Checks

# Comma-separated list of check IDs
elbaph scan --region us-east-1 \
  --checks alb-external-reachability,alb-ip-gate-bypass

Output Formats

# JSON report
elbaph scan --region us-east-1 --output json

# Markdown report
elbaph scan --region us-east-1 --output markdown

# SARIF (for import into SAST/DAST pipelines)
elbaph scan --region us-east-1 --output sarif

# Write report to /output so it is available outside the container
elbaph scan --region us-east-1 --output json --file /output/elbaph-report.json
elbaph scan --region us-east-1 --output sarif --file /output/elbaph-report.sarif

# No terminal colours — useful in CI or when piping output
elbaph scan --region us-east-1 --no-color

Route Active Probes Through a Proxy

If you are running from inside a corporate VPN or internal network, your machine may have privileged access to backend targets. Use --proxy to route active probing checks through an external vantage point so reachability results reflect an attacker's perspective.

elbaph scan -r us-east-1 --proxy http://remote.vantage.point:8080

# Burp Suite on localhost
elbaph scan -r us-east-1 --proxy http://127.0.0.1:8080

Note: --proxy requires CONNECT to port 80 for HTTP listeners. In Burp, enable this under Proxy settings → Request listeners.

Checks

ELBaph ships with the following built-in checks. For the full methodology, trigger conditions, and sample findings for each check, see the upstream checks documentation.

Check ID Name
alb-client-ip-spoofable Client IP Spoofing via Preserved X-Forwarded-For
cloudfront-bypass CloudFront Origin Direct Access
alb-desync-monitor Desync Mitigation Mode is Monitor
alb-external-reachability Target External Reachability
alb-ip-gate-bypass IP Gate Bypass via Alternate ALB
alb-optional-auth Optional Authentication Allowed
alb-rule-shadowing Restrictive Listener Rule Shadowed by Broader Earlier Rule
alb-vhost-probe ALB Virtual Host Routing Probe
nlb-direct-target-reachability NLB Target Directly Reachable

Output

Every scan creates a timestamped output folder in the current working directory:

elbaph-2026-04-01_22-00-00/
├── summary.txt                     run metadata + per-check finding counts
├── albs.txt                        table of all discovered ALBs
├── nlbs.txt                        table of NLBs (scheme, DNS, listeners)
├── target_groups.txt               target groups + health status
├── rules.txt                       per-ALB listener rule chain dump
├── findings.txt                    one detailed block per finding
├── vhost_route53_attachments.txt   Route 53 FQDNs → ALB alias/cname mapping
├── vhost_route53_corpus.txt        record-owner FQDNs from listed zones
└── topology.html                   interactive vis-network resource map

Open topology.html in a browser for an interactive diagram of how ELBs sit in the VPC and how traffic flows through listeners, rules, target groups, and backend targets.

Findings print live to the terminal as each check completes — you do not need to wait for the full scan to finish.

To save the output folder outside the container, change the output directory to /output:

elbaph scan --region us-east-1 -d /output/elbaph-$(date +%Y%m%d)

All Flags

Flag Default Description
-r, --region us-east-1 AWS region to scan
--all-regions Scan every region enabled for the account
-p, --profile AWS named profile
--aws-access-key-id Inline access key (pair with --aws-secret-access-key)
--aws-secret-access-key Inline secret key
--aws-session-token STS session token for temporary inline credentials
--aws-credentials-file Path to credentials INI file (mutually exclusive with inline keys)
-c, --checks all Comma-separated check IDs to run
-d, --dir elbaph-<timestamp> Output directory name
-o, --output Also export: json | markdown | sarif
-f, --file <dir>/report.<ext> Path for the structured export file
--proxy HTTP proxy URL for active probing checks
--vhost-probe-hosts-file Extra hostnames for alb-vhost-probe (newline-separated)
--vhost-probe-path / URL path used for every GET probe in alb-vhost-probe
--no-color Disable terminal colour output

Known Issues

  • Active probing (alb-external-reachability, alb-vhost-probe) is still under active development. Results may be incomplete or inaccurate depending on network topology and target protocol specifics. Treat probe findings as signals to validate manually.
  • When running from inside a corporate VPN or internal network, use --proxy to avoid false-positive reachability results.
  • When --all-regions is set, us-east-1 is always included for global calls such as DescribeRegions and CloudFront lookups regardless of the -r flag value.
  • Omitting Route 53 permissions (route53:ListHostedZones, route53:ListResourceRecordSets) will not break the scan, but alb-vhost-probe will have a reduced hostname corpus.

Additional Information

Clone this wiki locally