Path Traversal to AWS credentials to S3

What this lab covers

You enumerate a web application, identify a parameter that resolves file paths from user input, and use it to read files the application never intended to expose, including the credentials that let you continue into AWS.

The chain is short and that is the point. One input validation failure connects directly to cloud access, without privilege escalation on the host and without any cloud vulnerability being involved.

It suits web testers moving into cloud work and assumes no prior AWS experience. Familiarity with an intercepting proxy is helpful but taught along the way.

How path traversal reaches cloud credentials

Path traversal occurs when an application builds a filesystem path from user input without properly constraining it. Sequences that move up the directory tree let a request escape the intended directory and reach any file the application process can read.

What makes this severe in the cloud is predictability. Cloud SDKs and command line tools store credentials in well-known locations within the user's home directory, and configuration for the application itself is usually somewhere equally guessable. An attacker does not need to explore, they request known paths.

Encoding is the practical complication. Applications commonly filter obvious traversal sequences, so testing involves encoded and double-encoded variants, alternative separators and absolute paths. The filter is usually incomplete rather than absent, which is why manual testing with a proxy finds what automated scanning misses.

How to detect this in your own environment

Watch for traversal patterns in request parameters at the edge, including encoded variants. This catches unsophisticated attempts and is worth having, though a determined attacker will find an encoding your rules do not cover.

Application-level detection is more reliable. File access outside the expected directory, or a web process reading credential files in a home directory, are strong signals that do not depend on recognizing the input.

The most valuable cloud-side detection is the same as for any credential theft: the credential being used from somewhere it should not be. If a workload's credentials appear from an external address, the source of the theft matters less than the fact of it.

How to prevent it

Resolve the requested path and verify it falls inside the permitted directory, rather than filtering the input for bad sequences. Allow-listing the resolved location fails closed and does not depend on anticipating every encoding.

Do not use long-lived credential files on cloud hosts. Instance roles supply short-lived credentials through the metadata service, which means there is no credential file to read, removing the target rather than protecting it.

Run the application as a user with minimal filesystem access. Defense in depth matters here because the traversal grants exactly the reach the process already has, and a narrower process reads fewer interesting files.

Real-world context

Path traversal remains one of the most persistent web application flaw classes and appears regularly in vulnerability disclosures for widely deployed software. It is well understood and still common, largely because it is easy to fix incorrectly by filtering input rather than validating the resolved path.

Exploitation of internet-facing applications is now a leading route into cloud environments, and this lab shows the shape of it. The application flaw is the entry, and the credentials available on the host determine what follows.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1083 File and Directory Discovery and T1552.001 Credentials In Files.

Applying this at work

• Search your applications for anywhere a file path is constructed from user input, and confirm each validates the resolved path rather than filtering the raw input.
• Audit your cloud hosts for long-lived credential files and replace them with instance roles or workload identity.
• Check what filesystem access your web application processes actually have, and reduce it.
• Add detection for web processes reading credential files in home directories.
• Confirm you would notice a workload's credentials being used from an unexpected source address.

Frequently asked questions

Why is path traversal worse on a cloud host?

Because cloud tooling stores credentials in predictable file locations. An attacker who can read arbitrary files does not need to escalate privileges, they read the credential file and continue as that identity in the cloud.

How should path traversal be fixed properly?

Resolve the path and verify the result falls within the permitted directory, rather than filtering the input for traversal sequences. Filtering requires anticipating every encoding and typically misses one.

Would using an instance role have prevented this?

It removes the credential file, which is the specific target here. Credentials would instead come from the metadata service, so the fix is to protect that endpoint and scope the role tightly rather than to protect a file.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS initial access and privilege escalation paths in full, and is assessed hands-on in a live AWS account.