Cloud object-storage misconfiguration

SkillFiles & storage

Find and prove misconfigured cloud object storage (S3/GCS/Azure Blob). Load when assets load from *.s3.amazonaws.com, storage.googleapis.com, *.blob.core.windows.net, bucket-looking hostnames, or "bucket". Signals: public-read/list, unauthenticated writes, predictable bucket names.

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Account requirements not reviewed. Check the skill instructions before use; ahel provides instructions and does not run this skill.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the Cloud object-storage misconfiguration skill

What this skill tells your AI

The instructions your AI receives, as published by noorqureshi/sploitagent in skills/cloud/cloud-s3-exposure/SKILL.md and read by ahel’s review.

When it applies

The app stores files in S3/GCS/Azure Blob and the bucket's ACL/policy is too open — public listing, public read of private objects, or (worst) unauthenticated write.

Why it works

Object-storage ACLs are easy to get wrong: "public" gets applied at the bucket level, or an IAM policy grants s3:ListBucket/GetObject/PutObject to *. Predictable names (companyname-backups, -assets, -dev) make discovery trivial.

Method

Find bucket names: from asset URLs, JS, DNS CNAMEs, and permutations of the org name (company, company-prod, company-backups, region suffixes).
Test list/read (S3): aws s3 ls s3://bucket --no-sign-request (list) and aws s3 cp s3://bucket/file . --no-sign-request (read). --no-sign-request = anonymous.
Test write (high impact, do carefully & in scope): aws s3 cp poc.txt s3://bucket/ --no-sign-request — a successful anonymous write is critical (defacement/malware hosting).
GCS/Azure: gsutil ls gs://bucket / anonymous HTTPS GET; Azure ?comp=list on the container.
Scale carefully with s3scanner/gcpbucketbrute on name lists — respect scope & rate.

Gotchas

403 on the bucket root ≠ safe — individual objects may still be public; test known object paths.
Anonymous write is the crown jewel but easy to over-test — upload one harmless marker, then stop.
Region matters for the endpoint; a wrong region gives misleading 301/403.

Verify success

Anonymous listing/read of non-public objects, or a successful anonymous write of a harmless proof file (then remove it). Capture the exact command + response.

References

AWS S3 security docs; "hacking the cloud" S3 guides; s3scanner README.

Signals

GitHub stars: 20
Forks: 7
Last commit: Sep 2026

Advanced

Item type: skill
Key: cloud-s3-exposure
Source: github.com/noorqureshi/sploitagent

github.com/noorqureshi/sploitagent