PurplePanda maps privilege escalation paths across cloud platforms

The question is about chains, not about permissions

Permission reviews usually stop at a single resource: can this role read that bucket, can this token push to that repository. PurplePanda is built for the question that comes after, which is whether a set of individually reasonable permissions can be strung together into a path from a low privilege identity to control of something that matters. The README states the scope in one line: the tool fetches resources from different cloud and SaaS applications focusing on permissions in order to identify privilege escalation paths and dangerous permissions in the cloud and SaaS configurations. The emphasis on within a platform and across platforms is the differentiator, and it matches the platform list, which is Google Cloud Platform, GitHub and Kubernetes. That combination is deliberate. A Kubernetes role binding that reads a secret which happens to contain a cloud credential is a path that spans two systems, and a tool that only looked at Kubernetes would report the role binding as harmless. The repository name and the animal reference in the README make the audience explicit, since the tool is meant mainly for purple teams, and the author notes it is useful for both blue and red teams. The credentials angle is also explicit, since the panda can ingest API keys and tokens found by a separate tool, PEASS.

One folder per platform, each with its own documentation

The architecture is a Python program with a plugin style layout. The top level listing shows main.py as the entry point, a core/ directory, an intel/ directory that holds the platform modules, a config.yml, a Dockerfile, requirements.txt, a TODO.md, and a separate VISUALIZE_GRAPHS.md. The README explains the intel/ convention, stating that each folder inside it defines one platform that can be enumerated and contains a README.md file explaining how to use that specific module. Each folder also carries a HOW_TO_USE.md file with the best queries for an investigation on how to escalate privileges, for purple, blue and red teams, and a QUERIES.md file with all proposed queries to investigate the data. That is a notable design choice. Rather than shipping a fixed set of findings, the tool ships the data and a set of queries over it, so the analysis stays in the hands of the person running it. The module boundaries also mean a new platform is a new folder rather than a change to the core, and the same TODO.md convention appears in the root folder and in each intel folder, with the README inviting pull requests.

A local install needs Neo4j before it needs anything else

The tool is installed from source with a virtual environment, and the database has to exist first. The README asks you to download Neo4j Desktop and create a database, then export two environment variables, PURPLEPANDA_NEO4J_URL and PURPLEPANDA_PWD, holding the URL and the password. A third variable, SHODAN_KEY, is optional and enables Shodan lookups on public IPs found during enumeration. The install sequence is these commands.

git clone https://github.com/carlospolop/PurplePanda
cd PurplePanda
python3 -m venv .
source bin/activate
python3 -m pip install -r requirements.txt
export PURPLEPANDA_NEO4J_URL="bolt://neo4j@localhost:7687"
export PURPLEPANDA_PWD="s3cr3tpassword"

One line is only needed for Google Cloud, since the gke-gcloud-auth-plugin component is what lets the tool authenticate against a cluster.

gcloud components install gke-gcloud-auth-plugin

Then the program is launched with the platforms you want, comma separated, and the help output lists the rest. The example enumerates three platforms at once with platform specific flags switched on.

python3 main.py -e -p google,github,k8s --github-only-org --k8s-get-secret-values --gcp-get-secret-values # Enumerate google, github and k8s

The requirements list shows the client libraries behind that. The Google API client and google-cloud-secret-manager, pygithub, kubernetes, concoursepy, pycircleci, shodan, dnspython, tld, py2neo for the database, pyyaml for config.yml, and rich for terminal output. Several pins are annotated in the file as not directly required and pinned by Snyk to avoid vulnerabilities, which tells you the security posture of the dependency set is being tracked.

Enumerate and analyse are different jobs

PurplePanda has two analysis modes and the distinction matters for how you plan a run. The -e flag is enumerate, described as the main one, which gathers data and analyses it. The -a flag is analyse, which performs a quick analysis of the provided credentials. The second mode is the one to reach for when you already have a set of keys and want a fast read on them, and it is also the sensible first step in an unfamiliar environment, because it produces output without a full enumeration pass. The Docker route mirrors the same interface, with the image built from a Python slim base and carrying the gcloud CLI, nmap, gitleaks and kubectl, and the entrypoint running main.py.

docker rm -f purplepanda
docker build --tag=purplepanda .

The container run passes the same environment variables plus one per platform, GOOGLE_DISCOVERY, GITHUB_DISCOVERY, K8S_DISCOVERY, CONCOURSE_DISCOVERY and CIRCLECI_DISCOVERY, and the README notes that -t is needed to see the output properly and that the host.docker.internal domain is required when the Neo4j instance runs on the desktop. That last point is the same class of problem as everything else here, since the graph has to be reachable from wherever the tool runs.

Credentials decide what the graph contains

The README is explicit about the access requirement, and it is the first thing to read before planning a run. For blue and purple teams, you are told to use credentials for each platform with at least admin read access to all the resources of the platform, because that is what lets you see exactly the privesc paths that can be abused within your configurations in each platform and across them. For red teams, the guidance is different, since in general cloud and SaaS platforms will not give everyone access to read the configuration of the platform, which is why the tool supports the use of several keys for the same platform, so that you can try to enumerate everything with all the keys you compromised and get the most accurate view of the platform configuration. In other words, the graph is a function of your access, and a narrow credential set produces a narrow, and reassuringly incomplete, picture. That is the failure mode to guard against. The two documented reasons for a gap, the reader who lacks permission on some resources and the reader who only enumerated with one of several keys, both look the same in the output, a missing edge, and both are indistinguishable from a genuinely safe configuration unless you know what you could not read.

The findings arrive as CSV, and the graph is the second step

The output design splits investigation from presentation. Using the -d parameter with a directory, PurplePanda writes several interesting analyses in csv format of the information obtained from all the platforms, and the recommendation is to find interesting and unexpected things in those files and then to analyze those interesting cases with the graphs. The CSV files are the artifact you read, diff and attach to a ticket. The graph in Neo4j is the tool for the cases worth a second look, and VISUALIZE_GRAPHS.md holds the instructions for it. So the workflow is deliberately two stage. Enumerate and store the configuration as a graph, export flat findings for the bulk of the findings, and then bring the graph in for the handful of paths that look wrong. This is a sensible division for a tool that deals with large amounts of configuration, and it is also a limitation of the shape. The CSV output is a set of rows, so a path that only becomes visible by joining several rows in the right way is harder to spot in the files than in the graph, and the README's advice to find the interesting and unexpected things by reading is honest about the fact that the tool does not rank the findings for you.

Where the coverage stops

The boundaries are worth setting out before you trust a clean result. First, the platform set is what the intel/ folders contain, and the README names Google Cloud, GitHub and Kubernetes with links to the HackTricks cloud security pages, while the requirements and the container environment point to Concourse and CircleCI as well, so the supported list is larger than the three documented in prose and you should check the intel/ directory for what is actually there. Second, the analysis is over what the credentials can read, so it is an upper bound on paths the tool can see and a lower bound on what exists in the estate. Third, the tool reasons about permissions, and the README does not describe how it handles the application layer above the platform, meaning what a service account can then do with the data it reads, or the runtime behaviour of a workload it identifies. The named successor tool PEASS, which finds API keys and tokens that PurplePanda can then ingest, is that gap made explicit, since the paths PurplePanda finds are about configuration and PEASS covers credential discovery. The alternatives line up along the same axis. Querying each platform's own IAM or RBAC tooling gives you the authoritative permission lists but no cross platform path, and reading cloud security documentation such as the HackTricks pages the README points at gives you the abuse techniques but none of your own configuration. A commercial posture or attack path product covers more of the estate automatically and at the cost of a service and an account, and it also brings its own model of what counts as a path. PurplePanda's advantage is that the queries are in the repository, visible and editable, which suits a team that wants to argue about the definitions rather than accept them.

Editorial conclusion

PurplePanda fits a purple team or a security engineer with admin read access to the platforms in scope, who wants a repeatable way to find escalation chains that a single platform view cannot show, especially the ones that cross from Kubernetes into a cloud. It is the wrong tool for an environment where you are not permitted to read every resource, since coverage depends on the breadth of the credentials, and for a compliance report, since the outputs are investigative CSV files rather than an audit artefact. Before you run it, decide which Neo4j instance will hold the graph and how long it will keep the data, because the enumeration is written into a database that persists after the run finishes, and then run it with the analyse mode first on credentials you already hold to check the output before you point it at a full admin key.

Frequently asked questions

Official sources

1. carlospolop/PurplePanda on GitHub
2. Issues
3. README