# Pacu: an AWS exploitation framework for authorised cloud penetration tests > Pacu is a Python framework from Rhino Security Labs that runs modular AWS attacks against an account you are allowed to test. It stores everything in a local SQLite session, and the last push to the repository was on 2026-05-19. **RhinoSecurityLabs/pacu** — The AWS exploitation framework, designed for testing the security of Amazon Web Services environments. - Repository: https://github.com/RhinoSecurityLabs/pacu - Website: https://rhinosecuritylabs.com/aws/pacu-open-source-aws-exploitation-framework/ - Stars: 5,345 · Forks: 800 - Language: Python - License: BSD-3-Clause - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/rhinosecuritylabs-pacu ## What Pacu is for, and who is expected to run it Pacu is described in its README as an open-source AWS exploitation framework for offensive security testing against cloud environments. The distinction matters. This is not a posture scanner that lists misconfigurations and hands you a PDF. It is a tool that, given an AWS access key ID and secret access key, runs modules that escalate privileges, backdoor IAM users, attack Lambda functions and exfiltrate data. The README names those capabilities directly. The intended user is a penetration tester working under a scope agreement. Pacu assumes you hold at least one valid AWS credential for the target account, obtained through whatever the engagement allows: a leaked key, a phishing result, an assumed role. Everything after that is the tool's problem. It is also aimed at people who want to write their own AWS attacks, since the framework is built around plug-in modules with a shared syntax and data structure, and the README invites contributions to the core module collection. If your job is to answer "are we compliant with this benchmark", Pacu is the wrong instrument. If your job is to answer "having stolen this key, how far can an attacker get, and what would they leave behind", Pacu is built for exactly that question. ## The session and SQLite design that shapes every Pacu run On first launch Pacu asks you to create and name a session. That session holds the AWS key pairs you set and the data produced by any module you run. You can keep multiple sessions with separate keys and separate data, and the README notes one real constraint: switching between sessions currently requires a restart. The storage decision is the interesting part. Pacu keeps retrieved data in a local SQLite database, and the README gives the reason plainly: minimising API calls, and therefore the associated CloudTrail logs that those calls generate. That is an operational choice, not a performance one. Every AWS API call an attacker makes is a log line a defender can find, so a framework that enumerates once and then answers later questions from a local cache is materially quieter than one that re-queries on every command. The database is also the reporting surface. Pacu logs commands and can export them, which the README frames as building a timeline for the testing process. In practice the SQLite file is the artefact you carry out of an engagement: it is where the enumerated users, roles, policies and downloaded data live, and the CLI exposes it through a query flag rather than a separate reporting tool. Treat that file as sensitive client data, because it contains the credentials and findings for the account you tested. ## Installing Pacu with pip3 or pipx and setting your first keys The README calls Pacu lightweight: Python 3.7+ and pip3 are the stated requirements, while pyproject.toml pins the package to Python ^3.9, so treat 3.9 as the floor that actually applies. The quick path upgrades pip, installs the published package and starts the interactive shell. ```bash pip3 install -U pip pip3 install -U pacu pacu ``` On Kali Linux, where pip is no longer installed by default, the README calls pipx the preferred method. That command installs from the git repository rather than the released package, so you get the latest commits, which the README warns may not be in the official release. ```bash pipx install git+https://github.com/RhinoSecurityLabs/pacu.git ``` There is also a published Docker image. The simplest invocation runs Pacu directly through its default entrypoint. ```bash docker run -it rhinosecuritylabs/pacu:latest ``` If you want a shell instead of Pacu's prompt, override the entrypoint with /bin/sh. Mounting your host credentials is possible but the README carries an explicit warning that anyone with access to the container then has access to your host's AWS credentials, so that variant belongs on a disposable machine. Once you are at the Pacu prompt, the first real task is giving the session a key. The set_keys command prompts for a key alias, an AWS access key ID, a secret access key and, if applicable, a session token. ```text set_keys ``` From there, list shows the modules available for the regions configured in the session, help module_name returns a module's own help, and run module_name executes it with defaults. To narrow a run, the README's example passes regions explicitly. ```text run module_name --regions eu-west-1,us-west-1 ``` The same work is available non-interactively. pacu --list-modules and pacu --pacu-help need no session, while pacu --session selects one, pacu --module-name with --exec runs a module, --module-info describes it, and pacu --module-args=" " supplies arguments. pacu --data queries the local database, and pacu --whoami reports on the current user. The README does not document a rollback command for anything a module does to the target account, which is worth knowing before you run an escalation module against production. ## Where Pacu stops being the right tool Pacu's own README is candid about the sharp edges. Session switching requires a restart, which is friction on a long engagement where you move between accounts. The framework development goals list, published in the README, is effectively an admission of what is unfinished: database forward-migrations and version tracking, attack playbooks for chaining modules, coloured console output, module dry-run functionality, standalone config files. A dry-run mode that does not exist yet means there is no supported way to preview what a module will do to the target before it does it. That absence is the limitation to weigh hardest. Modules that backdoor IAM users or attack Lambda functions change the account. Running one to see what happens is not a test, it is an incident. The README documents no undo, so recovery is your problem, and it is the client's account you are recovering. The other boundary is scope. Pacu needs a credential. It is not a scanner that discovers exposed S3 buckets from the outside, and it is not a continuous monitor. Anything you want to know about an account you have no key for is out of its reach by design. Finally, the dependency set is pinned tightly in pyproject.toml, including botocore >=1.16,<1.32, so a bleeding-edge AWS SDK in the same environment can conflict with Pacu's own requirements. ## Pacu against ScoutSuite: exploitation versus configuration review ScoutSuite is the comparison people reach for, and the two tools answer different questions. ScoutSuite performs a multi-cloud security auditing pass: it reads configuration across services and produces a report of what looks wrong. It is non-destructive by construction, because it only reads. Pacu starts from an attacker's credential and asks what that credential can be turned into. Its modules escalate privilege, backdoor IAM users, attack Lambda functions and exfiltrate data, and its local database exists to reduce the API calls that would otherwise be logged. A ScoutSuite run ends with a findings document. A Pacu run ends with a modified account, a SQLite file of enumerated data, and a command log you can turn into a timeline. That difference decides which one you reach for. If you need an auditor's view of a whole organisation, ScoutSuite's read-only pass is the safer and more appropriate instrument. If you need to demonstrate that a specific stolen key leads to full account takeover, only the exploitation path proves it, and that is Pacu's territory. ## Licence and the cost of keeping Pacu current Pacu is released under BSD-3-Clause, and pyproject.toml declares the licence as BSD-3. That is a permissive licence: it allows use and modification, and it carries the usual warranty disclaimer. It does not restrict what you point the tool at, which is precisely why the authorisation question is yours and not the licence's. Nothing here is legal advice; if you redistribute Pacu or a modified version, read the licence text in the repository. The upgrade cost is dominated by AWS itself. Modules track AWS services, and AWS ships new services and new IAM behaviour continuously, so a Pacu install that is a year old is missing attack surface. The project's release cadence reflects that: v1.7.0 was released on 2026-03-23, following v1.6.1 on 2025-07-24 and v1.6.0 on 2024-05-28. The last push to the repository was on 2026-05-19, so the codebase is being touched, but the gaps between releases mean you should not assume a module covers a service AWS launched last month. Upgrading is cheap in the normal case: pip3 install -U pacu, or reinstall through pipx if that is how you set it up. The Docker image tag rhinosecuritylabs/pacu:latest is rebuilt independently of the Python release, so pinning a digest matters if you need a reproducible toolkit across an engagement. The dependency pins in pyproject.toml are the other cost: botocore is capped below 1.32, so an isolated environment per engagement is less painful than sharing one with other AWS tooling. ## Conclusion Adopt Pacu if you are a penetration tester with written authorisation to attack a specific AWS account and you want enumeration, privilege escalation and reporting in one session-scoped tool. Do not adopt it if you need continuous, read-only posture monitoring: it is built to exploit, not to watch. Before your first engagement, verify that your Python is 3.9 or newer, that the module you intend to run supports the regions you will target, and that your rules of engagement cover the local SQLite database that Pacu writes to disk. ## FAQ ### What is Pacu in cybersecurity? Pacu is an open-source AWS exploitation framework from Rhino Security Labs, built for offensive security testing against cloud environments. It runs plug-in modules that enumerate an AWS account, escalate privileges, backdoor IAM users and attack Lambda functions, using credentials you supply. ### What are AWS security tools? Pacu is one example: an AWS exploitation framework for offensive security testing, whose modules cover enumeration, privilege escalation, data exfiltration, service exploitation and log manipulation within AWS environments. The README does not attempt a wider survey of the category. ### Which AWS service helps assess security and compliance? Pacu is not an AWS service; it is a Python framework you install and run against an AWS account using a key you supply. Its README describes offensive testing rather than compliance assessment, and it does not name an AWS service for that purpose. ### What are the best practices for cloud security in AWS? Pacu's README does not set out cloud security best practices. It does give the operational reason behind the local SQLite database: minimising API calls and the associated CloudTrail logs, which is the defensive signal a tester is trying not to generate. ## Sources - [License: BSD-3-Clause](https://github.com/RhinoSecurityLabs/pacu/blob/master/LICENSE) - [Project website](https://rhinosecuritylabs.com/aws/pacu-open-source-aws-exploitation-framework/) - [README](https://github.com/RhinoSecurityLabs/pacu/blob/master/README.md) - [Releases](https://github.com/RhinoSecurityLabs/pacu/releases) - [RhinoSecurityLabs/pacu on GitHub](https://github.com/RhinoSecurityLabs/pacu) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rhinosecuritylabs-pacu