hunt-cloud-misconfig

Validates cloud storage, serverless, and IAM misconfigurations within authorized engagement scope.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-cloud-misconfig-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-cloud-misconfig
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-cloud-misconfig
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-cloud-misconfig-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Cloud security assessments often stall because testers lack a disciplined, evidence-gated method for verifying object storage, serverless, and IAM misconfigurations without crossing authorization boundaries or triggering false positives. ## Core Features & Use Cases - Signal-Driven Routing: Triggers on concrete indicators such as bucket references, serverless endpoints, CloudFront markers, metadata proxies, and IAM config leaks. - Safe Validation Protocol: Uses canary objects, anonymous versus authorized read/write comparisons, CORS checks, and presigned URL binding tests instead of account enumeration. - Strict Oracle and Stop Rules: Distinguishes real authorization boundary failures from expected public assets, 403 responses, and expired signed URLs, and halts on IAM/ACL modification or cross-tenant access. - Use Case: During an authorized engagement, you discover a bucket reference in application JavaScript; this Skill guides you to confirm ownership, test a self-owned canary object across identity states, and record reproducible evidence. ## Quick Start Ask the agent to validate whether the in-scope cloud bucket and serverless endpoints from this engagement expose unauthorized access, using canary objects and evidence-gated probes.

Frequently Asked Questions about hunt-cloud-misconfig

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test S3 bucket misconfigurations during an authorized pentest?

Confirm bucket ownership and scope first, then compare anonymous, low-privilege, and authorized access against a self-owned canary object. Test write denial, CORS policies, and presigned URL binding rather than enumerating account-level resources.

What signals indicate a cloud misconfiguration worth investigating?

Actionable signals include bucket references in application code, serverless endpoints, CloudFront markers, metadata proxy exposure, IAM configuration leaks, and cloud console links. DNS name similarity alone is not authorization to test.

Can I test cloud metadata endpoints for SSRF exposure?

Metadata endpoints should only be tested through controlled OAST callbacks under explicit SSRF authorization, never by directly fetching real metadata IP addresses. Reading actual metadata credentials is a hard stop condition.

Why do public bucket contents not count as a vulnerability?

Publicly accessible static content and intentionally public assets are expected configurations, not misconfigurations. A valid finding requires an identity that should lack access successfully reading or writing an in-scope canary resource.

What actions are prohibited during cloud misconfiguration testing?

Prohibited actions include account-level enumeration, modifying IAM policies or ACLs, using real credentials, cross-tenant access, and reading metadata credentials. Any of these triggers an immediate stop with evidence preservation.