Pacu and Cloud Attack Tooling Detection Guide: Catching AWS Exploitation Frameworks in CloudTrail

Open source cloud attack frameworks such as Pacu turn one stolen AWS access key into automated enumeration, privilege escalation, credential harvesting and log tampering within minutes, and every step is an ordinary AWS API call. Pacu, CloudFox and Stratus Red Team are built for penetration testers and detection engineers, but the techniques they automate are the same ones criminals run after buying or scraping leaked keys. This guide profiles the main AWS tools, maps their capabilities to MITRE ATT&CK and to the CloudTrail events they leave, and sets out the detections, preventive guardrails and test approach that catch them. It is written for cloud detection engineers, SOC analysts and AWS platform owners, and it is defensive only: it names capabilities and evidence, not usage. For the general three-cloud detection set, see the Cloud Detection Engineering Guide.

This is an independent guide from NHI Mgmt Group, based on the public documentation of Pacu (Rhino Security Labs), CloudFox (Bishop Fox), Stratus Red Team (Datadog) and AWS as of November 2026. It is not sponsored or reviewed by any of those projects or by AWS. Tools change, so confirm behaviour against the projects' and AWS's current documentation.

Key takeaways

• The tool is invisible, the credential is not. Every framework works through a valid access key or role session, so detection is about what an identity does compared with its normal behaviour, not about spotting a binary.
• Pacu covers the whole kill chain. ATT&CK v20 maps Pacu (S1091) to 21 techniques, from cloud discovery and secrets store access to disabling cloud logs and modifying cloud firewalls.
• Log tampering is the highest-value alert. Pacu's documentation describes "minimising" CloudTrail rather than stopping it, and adding attacker IPs to the GuardDuty trusted list, so alert on any change to trails, detectors and IP sets, not only on deletion.
• Use the same tools to test yourself. Stratus Red Team detonates single, ATT&CK-mapped AWS techniques in a controlled way, which makes it the natural harness for proving your detections fire.
• Guardrails beat alerts for the worst moves. Organisation-level policies that deny logging changes, plus short-lived role credentials instead of long-term keys, remove whole module categories from play.

The tools and what they automate

Pacu is an open source AWS exploitation framework created and maintained by Rhino Security Labs and released under the BSD-3-Clause licence. Its README describes it as designed for offensive security testing, with modules for privilege escalation, backdooring IAM users, attacking vulnerable Lambda functions and more. It stores keys and enumerated data in a local SQLite database, which the project says minimises API calls "and associated logs". That design point matters for defenders: after the first enumeration pass, much of the analysis happens offline and the tenant sees fewer, more targeted calls.

The last row is the reason to write detections against behaviour. TruffleNet operators tested stolen keys at scale with simple identity and quota checks before abusing Amazon SES, no framework required. See the TruffleNet 2025 breach page.

Pacu module categories mapped to ATT&CK and CloudTrail

Pacu's module documentation groups modules into reconnaissance (authenticated and unauthenticated), enumeration, escalation, exploitation, persistence, evasion, lateral movement and exfiltration. The table maps each group to ATT&CK v20 techniques from the Pacu software entry and to CloudTrail evidence.

Two module descriptions deserve special attention. The "minimise" option for CloudTrail leaves a trail enabled while removing its SNS topic, global service events, multi-Region collection, log file validation, CloudWatch Logs integration and encryption, precisely to avoid the obvious stop and delete calls. And the honeytoken check module states that it identifies known canary keys and the owning account while avoiding CloudTrail. Design canary credentials so their value does not depend on looking unidentifiable, and alert on any use at all.

Detections that work

High-fidelity rules (alert directly)

• Any change to logging or detection: trail stop, delete or update, event selector changes, S3 lifecycle rules on the log bucket, GuardDuty detector or IP set changes, flow log deletion, Config recorder stops, and attempts to leave the AWS Organization. GuardDuty raises Stealth:IAMUser/CloudTrailLoggingDisabled for trail changes, but its own detector changes need your rule. See the AWS CloudTrail Guide.
• Credentials created for someone else: CreateAccessKey or CreateLoginProfile where the calling identity differs from the target user. See How to detect AWS access key creation for another user.
• Role trust edits: UpdateAssumeRolePolicy that adds an external account or wildcard principal.
• Snapshot or AMI sharing to an account outside your Organization.
• Penetration testing distribution findings: GuardDuty's PenTest:IAMUser/KaliLinux family flags API calls made from known testing distributions. Easy to evade by changing the user agent, but cheap and worth routing to the authorisation register check.

Behavioural rules (baseline, then alert)

• Enumeration burst: one access key or role session calling more than a set number of distinct eventName values across more than five eventSource services within 15 minutes, especially when it never did so before. GuardDuty's Discovery:IAMUser/AnomalousBehavior covers part of this.
• Error storm: access denied errors above baseline for one principal. Permission brute forcing produces error rates no legitimate workload does.
• Secrets harvesting: a principal reading more parameters or secrets in an hour than it reads in a typical week.
• Workload credentials used elsewhere: GuardDuty's InstanceCredentialExfiltration.OutsideAWS and InsideAWS findings flag EC2 role credentials used from another host. The Capital One breach is the classic case of role credentials taken from instance metadata.
• Fresh key, fast actions: long-term keys that sat unused and suddenly enumerate, or keys that call GetCallerIdentity from a new ASN and then act within minutes.

Low-value signals to avoid relying on

The userAgent field is supplied by the caller. A framework string in it is useful when present, but an absent string proves nothing. Source IP reputation is weak against residential proxies and cloud-hosted attackers. Treat both as enrichment.

Preventive guardrails

Where identity fits

Every module needs credentials, and the credentials that start these intrusions are almost always non-human: CI access keys, forgotten automation users, and role credentials lifted from workloads. The Codefinger S3 ransomware campaign used stolen long-term keys with S3 read and write rights, and the 2025 AWS crypto-mining campaign had miners running within minutes of compromise. An inventory of access keys with owner, last use and permissions, plus aggressive removal of unused keys, shrinks the pool of credentials these tools can start from. See the How to Investigate CloudTrail for a Compromised Access Key guide when one is found.

How to implement

1. Confirm coverage. An organisation trail in all Regions with log file validation, delivered to a log archive account, plus GuardDuty enabled organisation-wide. Add data events for your most sensitive buckets.
2. Deploy the guardrails in a test organisational unit. Apply the logging-protection service control policy to a sandbox OU first, confirm deployment pipelines still work, then roll out to production OUs. Roll back by detaching the policy.
3. Write the high-fidelity rules. Logging changes, cross-user key creation, trust edits and external sharing go straight to alerting.
4. Emulate, with authorisation. In a dedicated test account, run Stratus Red Team techniques one at a time (it handles set-up and clean-up) and confirm each rule fires. Run a scoped Pacu enumeration from a known IP to measure the burst and error-storm baselines. Follow the AWS penetration testing policy and record every run in the authorisation register.
5. Tune the behavioural rules. Run them in report mode for two to four weeks, exclude known scanners (CSPM, CNAPP, inventory tools) by role ARN rather than by user agent, then promote.
6. Automate first response. For a confirmed malicious key: deactivate (not delete) the key, revoke active role sessions, preserve CloudTrail for the key, and check for keys, login profiles and trust edits it created.

Decision guidance

• Single account or small estate: GuardDuty plus a few EventBridge rules on logging and IAM changes give most of the value. Remove long-term keys first.
• Large AWS Organization: service control policies and an organisation trail are mandatory; centralise detections in the SIEM and correlate by access key ID across accounts.
• Native findings or custom rules: GuardDuty is anomaly and threat-intelligence based and needs no tuning to start; custom rules catch the specific write events that matter to you. Use both.
• Which emulation tool: Stratus Red Team for repeatable, single-technique detection tests; Pacu or CloudFox for scoped penetration tests that look for real escalation paths. CloudFox is designed to run with read-only permissions, which makes it the lower-risk choice for attack path reviews.

Detection and measurement

• Emulation pass rate: share of Stratus Red Team AWS techniques relevant to you that raise an alert within 15 minutes (target above 90% for evasion and persistence).
• Logging integrity: number of accounts without the organisation trail or GuardDuty (target zero).
• Long-term key count: active IAM user access keys, trending down, with none older than 90 days.
• Mean time to contain: from first alert to key deactivation for confirmed misuse.
• Exception hygiene: scanner exclusions defined by role ARN and reviewed quarterly.

Common failure patterns

• Alerting only on StopLogging and DeleteTrail. Minimising a trail, changing event selectors or adding a lifecycle rule to the log bucket achieves the same effect quietly.
• Allow-listing scanners by user agent. Anyone can set it, so a rule that ignores a CSPM user agent ignores an attacker who copies it.
• No owner for long-term keys. Keys with no owner cannot be checked quickly, so analysts close enumeration alerts as "probably a script". The Sumo Logic breach began with one compromised AWS credential.
• Testing in production without a register. Unannounced penetration tests train analysts to dismiss real alerts.
• GuardDuty trusted IP lists nobody reviews. An IP added to the trusted list silences future findings from it.

Framework mapping

Practitioner checklist

• Run an organisation trail in all Regions with validation, owned outside workload accounts.
• Enable GuardDuty organisation-wide and route PenTest, Stealth and credential exfiltration findings to the SOC.
• Protect logging services with a service control policy.
• Alert on every trail, detector, IP set, flow log and Config recorder change.
• Alert on access keys or login profiles created for another user and on role trust edits.
• Baseline enumeration and error rates per principal, then alert on bursts.
• Require IMDSv2 and remove unused long-term access keys.
• Test detections with Stratus Red Team in a dedicated account under an authorisation register.
• Exclude scanners by role ARN, never by user agent.

Standards and references

• MITRE ATT&CK: Pacu (S1091)
• AWS: GuardDuty IAM finding types
• GitHub: Pacu project documentation
• GitHub: Pacu module details
• GitHub: Stratus Red Team
• GitHub: CloudFox

Related NHI Mgmt Group resources: Cloud Detection Engineering Guide · AWS CloudTrail Guide · AWS Access Keys Security Guide · ROADtools and AADInternals Detection Guide · Cloud Detection and Response Guide