aws-pentest is a Python-based auditing framework that runs 30+ modules across IAM, S3, compute, network and logging services, producing executive Markdown reports for authorized penetration tests.
| Tool | capture0x/aws-pentest — automated AWS security assessment framework with 30 modules and Markdown reporting |
| Category | Cloud security auditing / penetration testing toolkit |
| Primary Use | Running multi-region authorized audits of AWS accounts, covering IAM privilege escalation paths, S3 exposure, EKS, Lambda, RDS, KMS and logging gaps, then generating remediation-ready reports |
| Safe Use | Explicitly documented for authorized audits, penetration tests and red-team engagements against AWS accounts you own or have written permission to test; also useful for defenders validating their own guardrails |
| Telemetry Note | All enumeration flows through authenticated boto3 API calls, leaving a dense trail of read-heavy CloudTrail events (List/Get/Describe) that defenders can alert on; destructive commands like backdoor-create generate clearly attributable IAM CreateUser/CreateAccessKey events |
aws-pentest from capture0x positions itself as an automated AWS cloud security assessment framework for authorized audits, penetration tests, and red-team engagements, and the README is unusually explicit about that scope: a banner note states that authorization is required and the tool should only be run against AWS accounts you own or have explicit written permission to test. At version v3.0.0, MIT-licensed and written in Python 3.8+, it wraps the AWS SDK (boto3) behind a single CLI entry point, aws_agent.py, that orchestrates a multi-module assessment pipeline and emits a timestamped Markdown report under reports/. The repository sits at a modest 34 stars, but the documentation depth — a module-by-module matrix, a command reference, and sample report output — is well beyond what most tools in this niche ship.
Architecturally the tool is a classic orchestrated enumerator. The audit command runs a pipeline of numbered module files — account.py for caller identity and password policy, iam.py for privilege escalation analysis, s3.py and s3_website.py for bucket exposure, network_sg.py for security group posture, and so on — with each module mapping to a specific AWS service surface. The README lists 30 modules spanning identity (iam.py), storage (s3_versions.py, ebs_snapshots.py), compute (compute.py, lambda_analysis.py, eks_analysis.py), networking (sts_cross_account.py, route53.py), and governance (scp_audit.py, waf_analysis.py). This modular layout means targeted scans can be invoked per-service without running the full pipeline.
Three audit modes control scope. The recon mode covers the core identity, storage, compute, serverless, network, logging, and governance checks and is recommended for a fast initial assessment. The loot mode extends recon with deeper dives into network configuration, RDS, KMS, Secrets Manager, ECR, EBS, and CloudTrail, aimed at sensitive data and exposure review. Finally, all runs the complete scan path for full engagements or final validation. Mode and region selection are passed directly on the command line, e.g. audit --mode all --regions us-east-1,eu-west-1, and the multi-region enumeration through boto3 is highlighted as a core capability rather than an afterthought.
The IAM analysis is where the tool earns its pentest framing. Module 01 (iam.py) looks for wildcard policies, dangerous actions like PassRole, AssumeRole, and CreateAccessKey patterns — the canonical AWS privilege escalation primitives — and the exploit-iam command surfaces those findings with proof-of-concept commands for validation. The README is careful to frame these as findings display rather than automated exploitation: the operator still decides what to do with the identified path. A related exploit-s3 command shows exposure and exploitation hints per bucket, which in practice functions as a prioritized triage view for storage misconfigurations.
One command deserves explicit caution: backdoor-create creates a persistent IAM administrator user. The README marks it as destructive and guarded by confirmation, and shows a --dry-run flag plus a --user-name authorized-test-admin example, which suggests the authors intended it for persistence-validation exercises where the operator needs to demonstrate that a compromised identity could establish durable access. In an authorized engagement this is a legitimate finding category, but it is also the single most operationally risky command in the tool, and any team adopting it should treat it as change-controlled: run it only with engagement-owner sign-off, document the created user, and remove it during cleanup. Notably, the audit pipeline also includes an iam_backdoor.py module labeled as dry-run guarded persistence validation.
Beyond the headline IAM and S3 modules, the coverage matrix reads like a checklist of real-world AWS attack surface. imds_enum.py checks IMDSv1/v2 posture and role credential exposure, the classic SSRF-to-credentials chain precondition. s3_subdomain.py and route53.py hunt for subdomain takeover candidates and dangling CNAME records, while s3_git_detector.py looks for exposed .git objects in buckets — a surprisingly common leak vector. cloudtrail_exfil.py examines log buckets for public exposure and cross-account access, and codebuild_pipeline.py greps buildspecs and environment variables for plaintext secrets and privileged mode. eks_analysis.py rounds out the container angle with public API endpoints and control plane exposure checks.
The reporting layer is what makes this usable for client-facing work rather than raw enumeration. Each audit run produces reports/aws_audit_report_YYYYMMDD_HHMMSS.md containing assessment metadata (generated time, AWS account, caller ARN, overall risk rating), an executive summary with Critical/High/Medium/Low counts, service-by-service findings with evidence tables, proof-of-concept commands where useful for validation, and remediation guidance sorted by security impact. The README lists 29 top-level report sections, ending with consolidated recommendations and the optional auto-backdoor capability assessment. The sample console output shows a Rich-powered progress bar and a summary table — an overall risk rating, finding totals, and per-area highlights like public S3 bucket counts and Route53 takeover candidates.
Credential handling is sensibly designed. The configure command saves AWS credentials to a local .env file with 0600 permissions, and the requirements section notes that standard environment variables or AWS named profiles also work. For engagement hygiene this matters: analysts will typically provision a dedicated read-heavy role via --profile security-audit rather than reusing personal administrator credentials, which also makes the CloudTrail trail attributable. The README's own example audit --mode all --profile security-audit --regions us-east-1,eu-west-1 reflects exactly that workflow.
Getting started follows the standard pattern: git clone the repository, create a virtual environment, and pip install -r requirements.txt, then run python3 aws_agent.py configure followed by python3 aws_agent.py audit --mode recon for a first pass. Targeted service scans are also first-class — scan-sts for cross-account trust analysis, scan-cognito for unauthenticated identity pools and MFA posture, scan-apigw for missing auth and CORS issues, scan-dns for takeover candidates — which makes it practical to re-run a single troubled service after remediation without repeating the full pipeline.
From a defensive perspective the tool is nearly silent on the wire in its read-only modes but very loud in audit logs. Every module is built on authenticated boto3 enumeration, which means a cloud trail analyst will see a burst of List*, Get*, and Describe* calls across many services from a single identity in a short window — a pattern trivially detectable with GuardDuty or custom analytics, and the tool's own logging.py module checks whether that detection layer even exists. The destructive commands are even more visible: backdoor-create generates CreateUser and attached policy events that are hard to miss. This symmetry is worth noting, because the same report the attacker-facing modules produce is exactly the gap list a defender should close.
Where aws-pentest fits in an authorized workflow is as a breadth-first triage engine between lightweight CSPM checks and deep manual exploitation. Its value is the report: severity-counted, evidence-backed findings with remediation guidance that can be handed to a client or internal platform team directly. Compared to doing the same work with raw aws cli scripts, the module matrix ensures coverage consistency across engagements, and the timestamped reports provide the documentation trail that formal assessments require. Its limitations are inherited from its design — it is an enumerator and validator, not an exploitation framework, and its findings are only as good as the credentials it runs with.
In sum, capture0x/aws-pentest is a credible, well-documented entry in the AWS security assessment space. The 30-module coverage, three audit modes, executive Markdown reporting, and explicit authorization framing make it a practical addition to a cloud security practice — provided operators treat the destructive persistence commands with the respect they deserve, scope credentials appropriately, and clean up any validation artifacts before closing the engagement. For defenders, running it against your own accounts is a straightforward way to see your environment the way an assessment team will.
capture0x/aws-pentest.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.