---

name: cloud-saas-exposure description: "Organization-grade cloud and supply-chain attack-surface discovery: S3/GCS/Azure Blob bucket discovery via observed-name mining (CNAME/cert-SAN/Wayback) and bounded two-class permutation (6 prefixes x 15 suffixes on trusted tokens, bounded target-bound expansion on subdomain stems), existence (HEAD/GET) vs public-listing confirmation, object-key triage into 9 value tiers (database dumps, credentials, IaC state, kubeconfig, VCS dirs, config, archives, PII, logs), dangling-CNAME bucket-takeover detection, and the ownership-gated severity model that stops an unattributable public bucket from becoming a false CRITICAL; the fully offline AWS-account-ID recovery from a leaked AKIA/ASIA/AROA access key (base32 decode, runnable stdlib Python, canonical test vector, AWS-documentation-example-ID screening); dependency-confusion confirmation for npm/PyPI (internal-signal classifier -- private-registry binding vs org-namespace match -- paired with a read-only public-registry 404 check and the npm scope-claimability nuance the public search API misses); and passive cloud-native/container/Kubernetes/CI control-plane fingerprinting (Lambda URLs, API Gateway, Cloud Run, App Service, kubelet/etcd/K8s API/dashboard, Jenkins/GitLab/Argo CD) as an org-attribution and exposure surface. Passive/discovery only -- no exploitation, no credential submission, no active control-plane confirmation (a stage-6 validate_cloud active tier is described but out of scope). Use when enumerating a target's cloud storage footprint, recovering an AWS account ID from a leaked key, confirming a supply-chain dependency-confusion vector, or fingerprinting cloud-native/K8s/CI infrastructure for an authorized external recon engagement." version: 1.0 sources: asm_reference_impl, public_research triggers:

• cloud attack surface
• cloud exposure
• SaaS exposure
• cloud bucket enumeration
• S3 bucket enum
• GCS bucket enum
• Azure blob enum
• bucket takeover
• dangling CNAME bucket
• public cloud bucket
• listable bucket
• bucket ownership
• object storage exposure
• bucket permutation
• AWS account ID
• AWS account ID from access key
• AKIA decode
• access key account ID
• offline AWS decode
• base32 AWS account
• AWS account enumeration
• cross-account trust
• IAM role phishing
• sts assume role
• dependency confusion
• npm dependency confusion
• PyPI dependency confusion
• supply chain attack surface
• unclaimed package
• internal package registry
• private npm registry
• scoped npm package
• npm scope claimability
• package registry leak
• cloud native fingerprint
• Lambda function URL
• API Gateway exposure
• Cloud Run exposure
• App Service exposure
• serverless exposure
• Kubernetes exposure
• K8s exposure
• kubelet exposure
• etcd exposure
• Docker API exposure
• CI CD exposure
• Jenkins exposure
• GitLab exposure
• control plane exposure
• cloud footprint
• cloud account attribution

---

Cloud & SaaS Exposure — Buckets, Offline AWS Account-ID Recovery, Dependency Confusion, and Cloud-Native/K8s Fingerprinting

Companion skills: osint-methodology (the pipeline this plugs into — Stage 2 asset expansion, Stage 4 exposure analysis, Stage 5 supply-chain confirmation). offensive-osint §16.8 (bucket-permutation raw wordlist), §16.17 (cloud-native URL pattern table), §16.18– §16.19 (container/K8s/CI paths + active curl recipes), §44 (package-registry search). This skill does not repeat those lists — it builds the reasoning layer on top: the ownership-gated bucket severity model, the offline AKIA→account-ID decode, the dependency-confusion two-part confirmation contract, and cloud-native/K8s as an org-attribution surface, not just another probe list.

0. When to Use / When NOT

Use this skill when: you're mapping an authorized target's cloud and supply-chain footprint — enumerating storage buckets and judging whether a hit is actually the target's risk (not a stranger's public bucket that happens to match a permutation); recovering the AWS account ID behind a leaked access key you already hold (dead or live); confirming whether an internal-looking npm/PyPI dependency is a registerable supply-chain vector; or fingerprinting cloud-native (Lambda/Cloud Run/App Service/…) and container/K8s/CI control-plane surface for org attribution and exposure triage.

Do NOT use this skill when: you just need the raw bucket-permutation wordlist, cloud-native URL pattern table, or container/K8s/CI path list with no reasoning layer — go straight to offensive-osint §16.8/§16.17–16.19/§44. Do NOT use it for anything past discovery/confirmation: registering an unclaimed package, submitting AWS credentials, authenticating to a Kubernetes API, or confirming a fingerprinted control plane actually answers unauthenticated (that's a stage-6 --validate --validate-cloud active tier — described, never performed, §5/§9.4).

---

1. Authorization & Legal Posture

Reuses osint-methodology §1 — assets you own or have written authorization to assess. Three of this skill's four subsystems carry a distinct authorization shape, worth being explicit about before you run any of them:

• Bucket probing (§6) is a real HTTP GET against bucket infrastructure that may or may not be the target's — the same "active but low-intrusion" tier as any other GET against target-adjacent infra. Standard engagement authorization applies.
• AWS account-ID decode (§7) is fully offline. No authorization question beyond already lawfully holding the leaked key.
• Dependency-confusion confirmation (§8) issues live GETs, but only against the public npm/PyPI registries — zero packets to the target. This is why it's explicitly in scope even though it's "active."
• Cloud-native/K8s/CI fingerprinting (§9) is pattern-matching over hostnames and ports already resolved by earlier recon — no new network traffic of its own.

---

2. Confidence Levels

Reuses osint-methodology §2. Domain-specific anchors:

| Level | Cloud/SaaS example | |---|---| | TENTATIVE | Org-namespace-matched dependency name (medium strength) with no private-registry binding — namesake-prone. | | FIRM | Bucket exists (403/private) and is name-tied or CNAME/SAN/Wayback-observed; AWS account ID offline-decoded from a leaked key with no live validation; cloud-native endpoint pattern-matched via an owned CNAME/cert-SAN/subdomain FQDN; a container/K8s orchestration port is open (directly observed — its auth posture is not). | | CONFIRMED | Bucket is publicly listable/readable and ownership-verified; AWS account ID corroborated by a live STS-validated key; dependency-confusion "strong" signal (private-registry binding) confirmed unclaimed via the public-registry 404 + scope-claimability check. |

An unattributable public bucket hit does not get a confidence label at all — it never reaches the finding stream (§6.3).

---

3. Output Format

Finding:
  id:          <stable hash or UUID>
  module:      <technique that discovered it>
  asset_key:   <typed key, e.g. bucket:s3:acme-backup, account:aws:609629065308>
  category:    <PUBLIC_BUCKET | INFO_DISCLOSURE | TAKEOVER | DEPENDENCY_CONFUSION | MISCONFIG | OPEN_SERVICE | EXPOSED_PANEL>
  severity:    <info|low|medium|high|critical>
  confidence:  <tentative|firm|confirmed>
  title:       <one-line summary>
  description: <2-5 sentences — issue + attacker impact, not a terse restatement of the title>
  evidence:
    url:       <where found>
    timestamp: <UTC ISO8601>
    sha256:    <hash of any downloaded artifact — never an object body, see §5>
    raw:       <truncated to 2 KiB>
  references:  [<advisory URL, vendor doc>]
  remediation: <action the asset owner can take>

UTC timestamps everywhere.

---

4. Source Hygiene & Citations

URL + UTC timestamp + SHA-256 + tool version + run_id, every artifact. For bucket listings, hash the listing response (the XML/JSON), never an object's contents — this skill never fetches an object body (§5). For a decoded AWS account ID, cite the key string it was derived from (redacted to first/last 4 chars in client-facing output) and the algorithm version. For a dependency-confusion hit, cite both registry-check timestamps (the package 404 and, for scoped npm, the scope-ownership 404) — claimability is a point-in-time fact that can flip the moment someone else registers the name.

---

5. Do NOT

• Do NOT fetch or download the contents of any object inside a bucket. Listing keys / sampling object names from the listing response is in scope (§6.3); retrieving an object's body is not — the reference implementation gates raw object reads behind --validate.
• Do NOT claim CRITICAL severity for a bucket, endpoint, or account hit that isn't ownership-verified. An unattributable public hit is not the client's risk — see the ownership-gated model, §6.3.
• Do NOT register, reserve, or publish a package name found unclaimed by the dependency-confusion check. Confirmation only — §8.7.
• Do NOT use a decoded/derived AWS account ID to call AWS APIs (sts:AssumeRole, GetCallerIdentity) against real infrastructure, with your own or the target's credentials. That reverse step needs the operator's own AWS credentials against a third party's account, is CloudTrail-logged on the target's side, and is out of this skill's scope entirely — describe the pivot value (§7.1), never perform it.
• Do NOT actively probe or authenticate against a fingerprinted Kubernetes API, etcd, kubelet, or Docker daemon endpoint to confirm its auth posture. Passive fingerprint only — live confirmation is a stage-6 --validate --validate-cloud active tier, out of scope.
• Do NOT single-source attribute a bucket/account/dependency/endpoint to the target — apply the rule of three (osint-methodology §2) or the explicit ownership signals in §6.3/§7.7/§9.1.

---

6. Storage Bucket Discovery — Candidate Generation, Existence vs. Listing, and the Ownership-Gated Severity Model

6.1 Two-class candidate generation

Two distinct expansion classes — mixing them either misses brand buckets or produces a candidate storm (an unconstrained full-expansion-per-subdomain-stem approach measured at ~95k candidates on a large-subdomain target).

Class A — trusted tokens (apex root, the domain with dots replaced by hyphens, the domain with dots stripped, and a sanitized --company token if supplied): full prefix × suffix expansion.

6 prefixes: "" (bare) backup- assets- static- dev- prod-

15 suffixes: "" (bare) -backup -assets -static -media -data -uploads -dev -prod -staging -logs -private -public -dump -archive

→ up to 90 candidates per trusted token.

Class B — subdomain stems (the first label of every discovered subdomain, excluding www/mail/ns1/ns2): bounded and target-bound only —

• Bare probe, but only when the stem is distinctive: not in the broad (~90-entry) generic-stem filter (api, admin, backup, dev, staging, mail, data, docs, internal, vault, secure, sandbox, preprod, … — a stricter, larger list than the 47-word variant in offensive-osint §16.8) and longer than 3 characters — or the stem already contains a trusted token.
• Target-bound permutation only: {apex_root|company}-{stem} and {stem}-{apex_root|company} (hyphen joiner, both orders).

No standalone prefix/suffix expansion is ever applied to a subdomain stem. Every candidate must satisfy the bucket-name shape ^[a-z0-9][a-z0-9.\-]{1,61}[a-z0-9]$ (3–63 characters).

Observed-name mining bypasses the filter entirely. A bucket name mined from the target's own DNS, certificate, or archived pages is near-certain to be theirs, so it's probed regardless of the rules above:

• subdomain CNAME chains resolving to `*.s3(.<re