CloudPEASS answers what a stolen cloud credential can actually reach

The question is what a stolen credential can reach, not what it is allowed

CloudPEASS is the Cloud Privilege Escalation Awesome Script Suite, and the stated purpose is to find your permissions whenever you compromise a principal in a red team across the major cloud platforms, Azure, GCP and AWS, plus Kubernetes.

The tool is designed to help you determine all your permissions and also what it is possible to accomplish with them, focusing on privilege escalation and accessing sensitive information and other potential attack vectors, without modifying any resources.

That last clause is the design constraint that shapes everything else. The scripts are read-only by construction, not by convention. The Azure script performs no write or delete operations and never executes commands inside workloads. The GCP script's transport rejects non-read-only endpoints outright, so it never creates, changes, enables, executes, invokes, starts, stops or deletes cloud resources.

The permission model underneath is a shared categorisation. The toolkit uses insights from HackTricks Cloud and the shared permission categorisations maintained in that book to classify permissions as critical, high, medium or low. The bundled categorisations for AWS, GCP, Azure and Kubernetes update weekly from HackTricks Cloud, and each script also tries to download its latest YAML from this repository's main branch when it starts. A failed download falls back to the last valid cached copy, then the bundled copy, and there is a `--no-update-rules` flag to use the bundled YAML with no network request at all.

That fallback chain is a nice piece of engineering on its own. A security tool that silently degrades its ruleset when the network is down is worse than useless, and this one keeps two levels of cache before giving up.

The ratings follow a shared severity policy with audited source evidence recorded in a CSV in the docs directory, so the ranking is meant to be checkable rather than asserted.

Azure enumerates in five ordered steps so a denial never ends the scan

AzurePEAS enumerates the effective permissions of a compromised user, service principal or managed identity in Azure Resource Manager and Microsoft Entra ID, and the enumeration order is the interesting part of the design.

The first step is token claims, which need no directory permissions. It identifies the principal and records the Graph scp, roles and wids claims, and these are useful even when every Graph enumeration endpoint returns 403.

The second is effective ARM permissions, which asks Azure's permissions endpoint at every discovered subscription, resource group, resource, management group and explicitly supplied scope. The documentation notes this does not require permission to list IAM role assignments, which is a meaningful bypass of a common blocker.

The third is IAM reconstruction, where allowed, listing transitive ARM and Entra assignments, role definitions, conditions and PIM-eligible roles. Failure here does not stop other methods.

The fourth is resource discovery evidence, where successful read-only subscription, resource-group and resource calls are reported even when IAM cannot be read.

The fifth is an Azure CLI fallback, used when `--use-az-cli` is set and ARM returns no permissions. AzurePEAS can then probe Azure CLI commands that are demonstrably read-only and require no arguments, and it uses no shell, disables dynamic extension installation and prompts, and skips unknown or potentially state-changing commands. `--azure-services` narrows the probe set and `--skip-az-cli-fallback` disables it.

There is also a path for the hardest case. If resource listing is denied but you know an ARM resource ID from a VM's metadata, logs, scripts or a previous foothold, you can pass it with `--scopes`, and AzurePEAS will query that scope directly. The documentation calls this the most reliable low-permission fallback, and it is the one that matters, because a low-privilege foothold is exactly the situation the tool is designed for.

Authentication is layered, and the tokens are never printed

The Azure script supports several authentication routes, listed in the order you would reach for them.

Reuse an existing Azure CLI login with `--use-az-cli`, which is recommended when available. Supply ARM and Graph access tokens as arguments or through the AZURE_ARM_TOKEN and AZURE_GRAPH_TOKEN environment variables. Use device code with MFA by running without credentials at all. Use username and password or service-principal credentials with `--use-username-password`, which is marked legacy and has no MFA. And supply an existing FOCI refresh token with `--foci-refresh-token` to try the optional Microsoft 365 checks.

The security rule is stated plainly. Tokens are never printed, and you should prefer environment variables over command-line arguments because command-line values may be visible in process listings. AZURE_PASSWORD and AZURE_FOCI_REFRESH_TOKEN are supported as environment variables.

That is a small but correct piece of advice for a tool that handles live credentials during a red team engagement, where a token leaking into a process list or a shell history is a real risk.

The cloud routing is specific too. Known ARM and Microsoft Graph audiences for Azure public, US Government and DoD, and China clouds, plus legacy Germany ARM, are routed only to their matching trusted API host, and Azure CLI authentication follows the cloud configured in az.

The Microsoft 365 checks are described as bounded and read-only, covering SharePoint, OneDrive, Outlook, Teams, OneNote, contacts and tasks, and they can be omitted with `--not-enumerate-m365`. The documentation is careful about their scope: these checks indicate accessible data, they are not intended to download a complete tenant.

GCP stacks independent techniques for the same reason

GCPPEAS enumerates the current principal's effective GCP permissions and highlights privilege-escalation and sensitive-access paths, and it layers several independent techniques so a denied enumeration call does not stop the scan.

The first layer is permissionless and local clues. Explicit `--project`, `--service-account` and repeatable `--resource` values are always tested, and `--group` preserves a known current-principal group membership when Cloud Identity discovery is denied. On a GCP workload, the metadata server supplies the current project, VM and attached service account without IAM permissions, and credential and standard project environment variables are also used.

That metadata server point is the same idea as the Azure token claims step. The script is designed for the situation right after a foothold, where the interesting facts about the principal are often available locally even though the identity APIs are closed.

The second layer is container and resource discovery, through Resource Manager search, Cloud Asset Inventory and independent service-specific list calls. The listed targets are wide: projects, folders, organizations, VMs, Functions, buckets, service accounts, secrets, Cloud Run services and jobs, Artifact Registry repositories, Pub/Sub topics, subscriptions and snapshots, BigQuery datasets, tables and routines, Workflows, KMS key rings and keys, Cloud DNS managed zones, Agent Identity auth providers, and Integration Connector connections.

Each failure is isolated and summarized, and regional fallbacks continue when only some locations are denied, which is the same isolation principle applied at the region level rather than the service level.

The result is a script that keeps producing evidence from whatever it can reach, and reports what it could not reach as part of the answer rather than failing.

One script per platform, with a shared rules layer underneath

The repository layout is small and shows the structure of the suite.

There are four scripts at the root, AWSPEAS.py, AzurePEAS.py, GCPPEAS.py and K8sPEAS.py, one per platform, plus a src/ directory holding the shared code, a scripts/ directory, a docs/ directory, tests/, a requirements.txt and the cloudpeass.png image used in the header.

The requirements list tells you what each platform needs. msal and requests for the Microsoft side, google-auth and google-api-python-client for Google, boto3 for AWS, kubernetes at 28.1.0 or newer for the cluster side, and PyJWT, PyYAML, tqdm, colorama and tqdm for the shared concerns, which are authentication token handling, the rule files, progress reporting and terminal output.

The shared categorisation layer is the part that makes the suite more than four independent scripts. Because all four rank permissions against the same critical, high, medium and low vocabulary derived from HackTricks Cloud, a finding in Azure and a finding in GCP are comparable, which is what a red team report needs.

The documentation directory carries the rules for that layer. There is the page on maintaining the shared categorisations, which explains the weekly sync and the fallback behaviour, and there is the severity policy with audited source evidence in a CSV, so a rating can be traced to the source that justifies it.

The project is Python, the last push was on 2026-10-11, and there are no GitHub releases, so the rule files and the scripts are pulled from the repository rather than from a package.

How the Azure script is actually invoked

The examples in the documentation show the common invocations, and the flags are worth reading because they express the fallback strategy directly.

To reuse the current az login and enumerate one subscription:

python3 AzurePEAS.py --use-az-cli --check-only-these-subs <SUBSCRIPTION_ID>

To pass tokens from the environment:

export AZURE_ARM_TOKEN="<ARM_TOKEN>"
export AZURE_GRAPH_TOKEN="<GRAPH_TOKEN>"
python3 AzurePEAS.py --no-ask

To check an exact known scope directly, which is the fallback for a denied resource listing:

python3 AzurePEAS.py --arm-token "<TOKEN>" \
  --check-only-these-subs <SUBSCRIPTION_ID> \
  --scopes "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RG>/providers/Microsoft.KeyVault/vaults/<VAULT>"

To limit the CLI probes:

python3 AzurePEAS.py --use-az-cli --azure-services vm,keyvault,storage

To run ARM only and write a JSON report:

python3 AzurePEAS.py --use-az-cli --skip-entraid --out-json-path azure-results.json

The two flags that show up most are `--use-az-cli` and `--no-ask`, which together are the everyday path: reuse the credentials you already have and do not prompt.

The `--scopes` example is the most instructive, because it shows the intended workflow in a real engagement. You do not begin with a full directory enumeration, you begin with what you already know from the machine you are standing on, and you ask about that one scope, and the tool tells you what the principal can do there.

Editorial conclusion

Adopt CloudPEASS if you run authorised red team engagements where the question after a credential compromise is what the attacker can actually reach, since the scripts enumerate effective permissions across four platforms and classify them by severity. Skip it if you need an exploitation tool, because the scripts are built to be read-only and explicitly refuse to modify resources. Verify first that you have authorisation to test the principal, that you understand the token handling rules since tokens are never printed but command-line values can leak through process listings, and which severity policy version you are running, since the categorisations update weekly from an external source.

Frequently asked questions

Official sources

1. Issues
2. peass-ng/CloudPEASS on GitHub
3. README