Wiz CTF #1: Perimeter Leak

No flags are included in this writeup.

Overview

Perimeter Leak was the first challenge in the Wiz Ultimate Cloud Security Championship, and it set the tone nicely: the solution was not about one loud bug, but about stitching together small pieces of cloud context.

The challenge placed me in front of a Spring Boot application running in AWS. The objective was to extract a protected secret from a hardened data perimeter. The important part was that the perimeter was not broken directly. It was bypassed by making the right component access the protected object from the right network location.

Initial Enumeration

I started with the application surface. Spring Boot Actuator endpoints are always worth checking because they often reveal runtime configuration, route mappings, environment variables, or health details that were never meant to become public reconnaissance.

The exposed Actuator data gave two useful leads:

• the application had a proxy-like route that accepted a URL parameter
• the environment included the S3 bucket name that mattered for the challenge

Direct bucket access was blocked, which was expected. The bucket policy was not simply “public object, hidden name.” It had an explicit perimeter condition around where access had to come from.

Turning The Proxy Into A Cloud Primitive

The proxy was restricted, but not useless. It allowed requests to AWS-style destinations and IP-based destinations. That immediately made the EC2 metadata service interesting.

IMDSv2 added one more step: first request a metadata token, then use that token for metadata paths. Once I had valid instance role credentials, I could inspect the identity and test S3 access like the application’s AWS role instead of like an anonymous internet user.

That still did not immediately expose the protected object. The bucket policy denied access outside the expected network path. The key was realizing that the application server was already in the trusted path, while my terminal was not.

The Actual Perimeter Bypass

The clean path was:

1. discover the bucket name through application metadata
2. use the proxy to reach AWS metadata
3. obtain temporary instance role credentials
4. generate a signed S3 request for the protected object
5. send that signed request through the application proxy so the request came from the trusted side of the perimeter

That last step is the challenge’s whole personality. The credentials alone were not enough, and the proxy alone was not enough. The solve needed both: identity plus network placement.

Root Cause

The failure was not only “metadata exposed” or “proxy exposed.” It was the combination:

• Actuator leaked enough application and route metadata to identify the target
• the proxy allowed sensitive internal/AWS destinations
• instance role credentials were reachable through IMDSv2 when the proxy could make the right requests
• the S3 perimeter trusted network origin strongly enough that a proxied signed request could reach the protected object

Takeaways

This challenge is a good reminder that cloud data perimeters are not magic walls. They work only if the identities and network paths that can reach the perimeter are tightly controlled.

For real environments, I would look for:

• exposed Actuator or debug endpoints
• SSRF-like proxy behavior, even when it has allowlists
• metadata service reachability from application-controlled request paths
• S3 policies that trust a VPC endpoint or source network without considering who can route through it
• logs that correlate presigned URLs, proxy access, and metadata access

Perimeter Leak was easy by solve count, but it was a strong first stamp because the lesson was realistic: cloud security failures often appear at the intersection of app behavior, identity, and network trust.