You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+83-1Lines changed: 83 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -215,6 +215,8 @@ In the following page you can check how to **abuse SSM permissions to achieve pe
215
215
216
216
**Elastic Load Balancing** (ELB) is a **load-balancing service for Amazon Web Services** (AWS) deployments. ELB automatically **distributes incoming application traffic** and scales resources to meet traffic demands.
217
217
218
+
For **Application Load Balancers (ALBs)**, the listener rules, authentication actions, header handling, and the alternative paths to the same targets are part of the **security boundary**. Review the full path **CloudFront --> ALB/NLB --> listeners --> rules --> target groups --> instances/IPs/ports/security groups**, not only one listener rule in isolation.
#### CloudFront / WAF bypass via direct ALB origin access
240
+
241
+
If a **CloudFront** distribution fronts an **internet-facing ALB** but the ALB security group still allows public inbound traffic, an attacker can often **request the ALB DNS name directly** and bypass **CloudFront WAF, geo restrictions, rate limits, and cache-layer controls**.
242
+
243
+
```bash
244
+
# Test the origin directly
245
+
curl -isk https://<alb-dns-name>/
246
+
247
+
# If the ALB routes on Host, replay the expected hostname directly to the ALB
- Enumerate CloudFront distributions and their origins, then check whether the origin ALB is still **internet-facing**.
254
+
- Review the ALB **security groups**. If inbound traffic is allowed from `0.0.0.0/0` or broad CIDRs, CloudFront is probably not the only reachable path.
255
+
- A direct **non-error** response from the ALB usually means the CloudFront/WAF layer is bypassable.
256
+
257
+
**Hardening:** If CloudFront should be the only entry point, allow inbound traffic to the ALB only from the AWS-managed prefix list **`com.amazonaws.global.cloudfront.origin-facing`**.
258
+
259
+
#### Listener rule shadowing / auth bypass
260
+
261
+
ALB rules are evaluated in **ascending priority order**. A **broader** rule with a **lower priority number** can capture traffic before a restrictive rule with `authenticate-oidc`, `authenticate-cognito`, or `source-ip` is ever reached.
262
+
263
+
```text
264
+
[10] path /* -> forward -> tg-app
265
+
[20] path /admin* -> authenticate-oidc -> tg-app
266
+
```
267
+
268
+
A request to `/admin` matches `/*` first, so the authentication action never runs.
269
+
270
+
**Audit notes:**
271
+
272
+
- Dump every listener and rule with `aws elbv2 describe-rules --listener-arn <listener_arn>`.
273
+
- Walk rules in ascending priority order and check whether a broad **host/path/header/query** condition matches traffic that should have hit a more restrictive rule first.
#### `source-ip` restrictions can be bypassed through alternate paths
277
+
278
+
A `source-ip` condition only protects the **specific listener rule** where it is configured. If the **same target group**, the **same backend IPs/instances**, or the **same service on another port** is reachable through another ALB, another listener, or an NLB with weaker controls, the IP allowlist can often be bypassed by using that alternate path.
279
+
280
+
**Audit notes:**
281
+
282
+
- For each restrictive rule, enumerate the **target group ARN** and the registered targets.
283
+
- Compare those targets against **all other listeners/load balancers** in the account/region.
284
+
- Also check for direct exposure via **public instance IPs**, permissive **security groups**, or additional listeners on ports such as `80`, `443`, `8080`, or `8443`.
285
+
286
+
A good mental model is: **protect the target, not only one route to the target**.
287
+
288
+
#### Client-controlled `X-Forwarded-For` trust
289
+
290
+
If `routing.http.xff_header_processing.mode` is set to **`preserve`** on an **internet-facing ALB**, the backend can receive an **attacker-supplied**`X-Forwarded-For` value unchanged. If the application trusts that header for **access control**, **rate limiting**, **logging**, or **monitoring**, the attacker may spoof the perceived client IP.
Prefer `append` or `remove` on internet-facing ALBs, and avoid using client-controlled forwarding headers as an authorization primitive.
298
+
299
+
#### Useful tool
300
+
301
+
[**ELBaph**](https://github.com/doyensec/ELBaph) is a read-only auditor that models **ALBs, NLBs, listeners, rules, target groups, and targets as a routing graph** and then probes for reachable exposures.
302
+
303
+
```bash
304
+
elbaph scan --region us-east-1
305
+
elbaph scan --all-regions -p my-pentest-profile
229
306
```
230
307
231
308
## Launch Templates & Autoscaling Groups
@@ -332,7 +409,12 @@ If a **VPN connection was stablished** you should search for **`.opvn`** config
-[AWS Elastic Beanstalk and Amazon EC2 getting started](https://docs.aws.amazon.com/batch/latest/userguide/getting-started-ec2.html)
413
+
-[Doyensec - Navigating Lax Load Balancers: When an Intersection Gets You Inside](https://blog.doyensec.com/2026/05/25/cloudsectidbits-elbaph-alb.html)
414
+
-[AWS - Listener rules for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-rules.html)
415
+
-[AWS - HTTP headers and Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/x-forwarded-headers.html)
416
+
-[AWS - CloudFront managed prefix list for origin-facing servers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html)
0 commit comments