Get Situational Awareness in AWS with Cloudfox

What this lab covers

You use CloudFox to orient yourself in an unfamiliar AWS account, then follow what it surfaces into serverless application code and a database table to demonstrate why reconnaissance output matters rather than stopping at the inventory.

The lab is as relevant to defenders as to testers. Running this tooling against your own environment is one of the fastest ways to see what an attacker would see after a single credential compromise, and the results are usually uncomfortable.

No prior AWS experience is required, though it helps to have done some manual IAM enumeration first so that you understand what the tool is automating rather than treating it as a black box.

How cloud situational awareness tooling works

Reconnaissance tooling makes a large number of ordinary read-only API calls across many services and correlates the results. Nothing it does is exploitative. The value is in breadth and in the correlation, because a human enumerating service by service will miss relationships that matter.

The questions it answers are consistent across engagements. Which principals exist and what can they do, which compute resources exist and what roles are attached, where is data stored, what is reachable from the internet, and where are secrets referenced. Answering these manually across every region is slow, which is precisely why automation dominates this phase.

Serverless components are disproportionately valuable in the output. Function configuration frequently contains environment variables, and function code can be downloaded by anyone permitted to read it, so application logic and the credentials it references often become available without touching a host.

How to detect this in your own environment

This is one of the most detectable phases of a cloud intrusion, because the tooling is loud by design. A single principal issuing a broad sweep of list and describe calls across many services in a short window is a strong and low-noise signal, and it is captured by default in CloudTrail.

Build the detection on rate and breadth rather than on specific API names. Tool authors change call patterns between versions, but the underlying behavior of touching many services quickly from one identity does not change.

Corroborate with identity context. Reconnaissance from an identity that normally performs a narrow set of actions, or from an access key used outside its usual source network, moves this from an interesting pattern to an actionable alert.

How to prevent it

Constrain what a compromised identity can enumerate. Broad read-only access is routinely granted on the assumption that reading is harmless, but it is exactly what converts a single stolen credential into a full map of the environment.

Keep secrets out of function environment variables and use a secrets manager with scoped access, so that reading a function's configuration does not hand over credentials to other systems.

Use short-lived credentials so that reconnaissance results decay. An attacker who maps an account with credentials that expire in an hour must act quickly, which shortens the window in which detection has to succeed.

Real-world context

Situational awareness tooling is a normal part of professional cloud assessment work, and the same tools appear in real intrusions because the task is identical whether the operator is authorised or not. Public reporting on cloud incidents consistently describes a broad discovery phase before any impact.

For defenders this is the most valuable single exercise available. Running reconnaissance tooling against your own account surfaces over-permissioned roles, forgotten resources and exposed secrets faster than a policy review, and it produces findings that are concrete rather than theoretical.

The activity maps to MITRE ATT&CK T1580 Cloud Infrastructure Discovery, T1087 Account Discovery and T1526 Cloud Service Discovery.

Applying this at work

• Run reconnaissance tooling against your own AWS accounts and treat the output as a findings list. Start with the identities that have the broadest permissions.
• Write a detection for one principal issuing describe and list calls across an unusual number of distinct services within a short window.
• Audit serverless function environment variables for anything that resembles a credential.
• Review which identities hold broad read-only access and reduce it where the breadth is not required.
• Check that access key usage from unfamiliar source networks generates an alert.

Frequently asked questions

Is CloudFox an exploitation tool?

No. It performs read-only enumeration and correlates the results. It finds paths and exposures rather than exploiting them, which is why it is equally useful for auditing your own environment.

Will running reconnaissance tooling be noticed?

It should be. The activity is high volume across many services from a single identity and is recorded in CloudTrail by default. If it is not noticed in your environment, that is itself a finding worth acting on.

Why is Lambda source code a reconnaissance target?

Function code can be downloaded by anyone with permission to read it, and function configuration commonly holds environment variables. Together they frequently reveal application logic and references to other systems and credentials.

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 reconnaissance and privilege escalation in full, and is assessed hands-on in a live AWS account.