CloudFox: Situational Awareness for AWS, Azure and GCP Pentests

What CloudFox is for, and who ends up using it

CloudFox answers orientation questions about a cloud account you did not build. The README frames it as a way to gain situational awareness in unfamiliar environments, and lists the questions it targets: which regions an AWS account uses and roughly how many resources sit in it, what secrets are lurking in EC2 userdata or service-specific environment variables, which workloads have administrative permissions attached, what actions a given principal can perform, which role trusts are overly permissive or allow cross-account assumption, and which endpoints are reachable from the public internet or from inside the VPC.

The intended operator is an offensive security professional running an objective-based penetration test, not a defender building a compliance report. Bishop Fox describes the tool as designed to be executed by a principal with limited read-only permissions, and its purpose as finding attack paths that can be exploited in simulated compromise scenarios. That distinction matters when you evaluate the output: a list of over-permissive roles is a finding here, not a dashboard metric.

There is a second mode. The README notes CloudFox can be used with found credentials, in the way weirdAAL or enumerate-iam are used, and that checks which fail do so silently. That silence is a design decision with a real cost, covered further below.

How the enumeration actually runs across AWS, Azure and GCP

The repository is organized by provider. Top-level directories aws/, azure/ and gcp/ sit beside cli/, globals/ and internal/, with main.go at the root. The go.mod file shows the mechanism behind that split: the AWS side depends on the aws-sdk-go-v2 service packages, one module per service (apigateway, apprunner, athena, cloud9, cloudformation, cloudfront, cloudtrail, codeartifact, codebuild, codecommit, codedeploy, directoryservice, docdb, dynamodb, ec2, and more), while the GCP side pulls cloud.google.com/go modules for artifactregistry, bigquery, iam, resourcemanager, secretmanager and storage. Azure uses the azure-sdk-for-go and azidentity modules.

That dependency list is the clearest statement of how CloudFox works. Each check is a thin wrapper over a provider API call, and the tool's coverage tracks whichever service SDKs the maintainers have added. It is not a graph engine that infers relationships from a configuration model. It queries, formats into tables (the aquasecurity/table dependency), and prints.

Command structure is modular. You can run one command at a time, or hand the work to a single aggregator. The README gives the aggregator as `cloudfox aws --profile [profile-name] all-checks`, described as running the other AWS commands with sane defaults. Credential resolution follows the usual AWS chain: profiles, environment variables, or metadata retrieval on an EC2 instance. Multiple profiles can be run at once by passing a file of newline-separated profile names with the `-l` flag, or every stored profile with the `-a` flag.

Installing CloudFox and running a first aws all-checks pass

The README lists five install routes. The two shortest are a Homebrew formula and a Go install from remote source. Both assume you have already arranged credentials for the account you intend to assess.

brew install cloudfox

The alternative, if you have Go installed:

go install github.com/BishopFox/cloudfox@latest

Binary releases for each platform are also published on the GitHub releases page, and the Makefile shows the cross-compilation targets the maintainers build (windows, linux, linux-arm64, macos). If you are compiling yourself, the developer path in the README is a clone followed by `go build .` in the repository root, which produces a `cloudfox` binary in that directory.

Before the first run, attach permissions. For AWS the README recommends `SecurityAudit` plus the project's own custom policy, `misc/aws/cloudfox-policy.json`, which it describes as a complete list of every permission CloudFox uses and nothing else. The broader managed policies each have gaps: SecurityAudit is missing newer permissions such as apprunner:*, grafana:*, lambda:GetFunctionURL and lightsail:GetContainerServices, and ViewOnlyAccess is missing those plus iam:SimulatePrincipalPolicy.

With a profile configured, the aggregate command is:

cloudfox aws --profile [profile-name] all-checks

What you should see is table output covering the questions listed earlier: regions in use, resource counts, secrets in userdata, principals with administrative permissions, and reachable endpoints. The README's screenshots show the shape of that output. If you prefer to work incrementally, run the individual AWS subcommands instead; the README describes the tool as modular for exactly that reason.

Silent failures are the sharpest edge in CloudFox

The README states plainly that checks which fail do so silently, and that in black-box use any data returned means your found credentials have the access needed to retrieve it. That is a coherent design for the found-credentials workflow, where the absence of output is itself the answer about what a credential can reach.

It is a poor fit for any other workflow. If you attach a policy that is missing a permission, the corresponding check produces nothing, and nothing in the output distinguishes a permission denial from an empty account. The README's own policy comparison table exists because this happens: SecurityAudit and ViewOnlyAccess both leave gaps in newer services, and a tester who does not read that table may conclude a service is unused when the principal simply could not list it. The ReadOnlyAccess policy avoids most gaps but, as the README notes, grants things like s3:Get* that are more permissive than the task requires.

The practical consequence is that CloudFox output is only as trustworthy as your knowledge of the permissions behind it. Treat an empty result as unverified rather than negative, and cross-check the policy you attached against the custom policy file before drawing conclusions.

Provider coverage is lopsided, and Kubernetes is not there

The README's provider table gives the command counts directly: 34 for AWS, 4 for Azure, and 60 for GCP, with Kubernetes marked as support planned. Those numbers describe breadth of commands, not depth of analysis per command, but the imbalance is large enough to shape how you plan an engagement.

Azure is the weakest of the three shipped providers at four commands, so an Azure assessment will lean on other tooling for most of its surface. GCP carries the highest command count, and the README pairs it with a detailed permission model that distinguishes minimal from comprehensive access: `roles/viewer` on a single project for basic enumeration, against an organization-wide set spanning `roles/resourcemanager.organizationViewer`, `roles/iam.securityReviewer`, `roles/cloudasset.viewer` and `roles/cloudidentity.groupsViewer` at the organization level, `roles/resourcemanager.folderViewer` at folder level, and `roles/viewer` at project level. GCP also requires the Google Cloud SDK installed and authenticated, with Application Default Credentials configured through `gcloud auth application-default login`.

Kubernetes being planned rather than shipped is worth stating plainly. If your engagement centers on cluster attack paths, CloudFox is the wrong tool today, and the README says so by omission from the command table.

Where CloudFox sits against Pacu and ScoutSuite

Pacu is the closest comparison for the AWS side, and the difference is in what each tool does with what it finds. Pacu is an exploitation framework: it maintains a session against an account, and its modules are built to act on the credentials and permissions they discover. CloudFox does not exploit. It enumerates and prints, leaving the exploitation step to you and to whatever tool you prefer. The README's own framing supports this: CloudFox is for finding attack paths that can be exploited in simulated compromise scenarios, not for exploiting them.

ScoutSuite sits on the other side of the line. It is an auditing tool aimed at producing a configuration assessment, which makes it useful for defenders and for reporting on posture. CloudFox's output is oriented toward an operator asking where the next step is, which is why the README organizes the tool around questions like which endpoints are reachable from an internal starting point rather than around control compliance. If you need a findings report for a client, ScoutSuite's model fits better; if you need to know what a specific principal can reach right now, CloudFox's model does.

The custom policy file is the detail that separates CloudFox from both. It is written to grant exactly the permissions the tool uses, which is a smaller blast radius than ReadOnlyAccess or AdministratorAccess, and it is the reason the tool can be handed a deliberately narrow credential.

Maintenance, the v1.17.0 floor, and the MIT licence

The repository is not archived, and the last push was on 2026-08-20. Recent releases are v2.0.5 (2026-05-26), v2.0.4 (2026-04-21) and v2.0.3 (2026-04-13), so the release cadence through 2026 has been roughly monthly. The go.mod pins Go 1.25.9, which means building from source requires a toolchain at least that recent.

There is a hard version floor that the README states in a dated update: if you are using cloudfox, you need v1.17.0 or greater, because all earlier versions stopped working after a format change in AWS's public service mapping file. That is not a soft recommendation. An older binary will fail, and the failure will not look like a version problem from the outside. Check your version before you start an engagement, particularly if you are pulling a pinned binary from an internal artifact store.

The project is MIT licensed, which permits commercial and internal use with the usual attribution requirement and no warranty. That is a permissive licence, so licence review is unlikely to be the blocker. The real upgrade cost is different: because each check depends on a provider SDK version, upgrading CloudFox can pull in newer AWS, Azure or GCP SDK modules, and the README's policy tables are dated (the AWS policy notes carry a 09/2022 date), so a policy you validated a year ago may not match the permissions the current build requests. Re-read misc/aws/cloudfox-policy.json after each upgrade rather than assuming your attached policy still covers the tool.

Editorial conclusion

Adopt CloudFox if you run objective-based cloud penetration tests and already hold scoped read-only credentials for the target account, and start with the AWS all-checks command after confirming your principal carries SecurityAudit plus the CloudFox custom policy. Skip it if Kubernetes is your target, since the README lists that provider as planned only, and skip it if you need a tool that explains a failed check rather than staying silent. Before relying on it, verify two things: that your build is v1.17.0 or later, because earlier versions stopped working after a format change in AWS's public service mapping file, and that your GCP roles match the scope you intend to assess, since the README separates a minimal single-project role from a comprehensive organization-wide set.

Frequently asked questions

Official sources

1. BishopFox/cloudfox on GitHub
2. License: MIT
3. Project website
4. README
5. Releases