Cloud Saas Exposure

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:

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(.<region>).amazonaws.com, *.storage.googleapis.com, or *.blob.core.windows.net
• certificate SANs matching the same three host patterns
• archived (Wayback) URLs, path- or vhost-style, referencing an S3/GCS/Azure Blob host

6.2 Probe technique — existence vs. listing

One GET per candidate per provider — no separate HEAD, since the GET body is needed anyway to classify listing:

S3 region redirects (301/307) are followed once before final classification. On a listable hit, sample up to 200 object keys straight out of the listing body already returned (<Key>…</Key> for S3/GCS, <Blob><Name>…</Name> for Azure) — never a second request per object, never a fetch of an object's contents.

6.3 The ownership-gated severity model

This is the discipline that stops a permutation hit on a stranger's globally-registered bucket from becoming a false CRITICAL — the exact class of false positive an earlier, unconstrained version of this logic produced: unverified public/listable hits emitted at MEDIUM/LOW severity were the documented source of a 171-finding false-positive flood before this gate was added. (A related, separate incident — filing a merely-exists-but-private 403/400 bucket as a PUBLIC_BUCKET exposure — produced a "33 listable buckets" false read on a fully-private estate; §6.2's reachability classification is what fixed that one.) Two independent axes decide the outcome — what's reachable and whether ownership is verified — and the outcome is no finding at all, not a downgraded severity, whenever the second axis fails.

Ownership verified means at least one of:

• name-tied — the candidate name contains a trusted token (apex root / domain variant / --company)
• observed — the name was mined from the target's own CNAME, cert SAN, or archived URL (§6.1)
• branded object key — on a listable bucket, at least one returned object key itself names the target (checked after listing, so this can promote an otherwise-generic name)

The unverified rows are a deliberate zero, not a soft downgrade to LOW/INFO. A generic permutation like static-delivery or logs-archive matches thousands of unrelated companies' real, live buckets globally; surfacing every one as the client's finding is exactly what this model exists to prevent. The candidate is still recorded as a graph asset for correlation and re-probe on a future scan — it simply never enters the finding stream unattributed.

Object-key triage on a listable bucket — classify the exposed keys into value tiers so the write-up states what is exposed, not merely that listing is open. Pure filename-pattern match over the listing already returned — no object body is ever fetched:

Lead the finding title with the highest tier present (e.g. "publicly listable — credentials exposed") — that one line is what turns a generic bucket finding into something the client acts on immediately.

6.4 Dangling-CNAME bucket takeover — a bonus lead, always in scope

A candidate that returns 404/NoSuchBucket but is still the live target of a subdomain's CNAME is a claimable takeover, independent of the ownership-gating table above — the live CNAME is the ownership evidence (a stranger's dangling bucket doesn't happen to have the target's subdomain pointed at it). Detection only: never register the bucket to prove it. Category TAKEOVER, HIGH, CONFIRMED — the 404-plus-dangling-CNAME combination is unambiguous.

6.5 Recipes

Probe (bash):

NAME="acme-backup"
for url in \
  "https://${NAME}.s3.amazonaws.com/" \
  "https://storage.googleapis.com/${NAME}" \
  "https://${NAME}.blob.core.windows.net/?comp=list"; do
  echo "== $url =="
  curl -sk -m 8 -o /tmp/body.xml -w 'status=%{http_code}\n' "$url"
  grep -oE '<(ListBucketResult|EnumerationResults)|<Key>[^<]+</Key>|<Code>[A-Za-z]+</Code>' /tmp/body.xml | head -20
done

Probe (PowerShell):

$Name = "acme-backup"
$Targets = @(
  "https://$Name.s3.amazonaws.com/",
  "https://storage.googleapis.com/$Name",
  "https://$Name.blob.core.windows.net/?comp=list"
)
foreach ($u in $Targets) {
  try {
    $r = Invoke-WebRequest -Uri $u -TimeoutSec 8 -SkipHttpErrorCheck   # -SkipHttpErrorCheck is PS7+; on PS 5.1 read $_.Exception.Response in the catch
    "{0,-70} status={1}" -f $u, $r.StatusCode
    if ($r.Content -match '<ListBucketResult|<EnumerationResults') {
      [regex]::Matches($r.Content, '<Key>([^<]+)</Key>|<Name>([^<]+)</Name>') |
        Select-Object -First 15 |
        ForEach-Object { $_.Groups[1].Value + $_.Groups[2].Value }
    }
  } catch { "$u -> error: $($_.Exception.Message)" }
}

Candidate generation — apex + full prefix/suffix expansion (bash):

APEX="acme"
PREFIXES=("" "backup-" "assets-" "static-" "dev-" "prod-")
SUFFIXES=("" "-backup" "-assets" "-static" "-media" "-data" "-uploads" "-dev" "-prod" "-staging" "-logs" "-private" "-public" "-dump" "-archive")
for p in "${PREFIXES[@]}"; do
  for s in "${SUFFIXES[@]}"; do
    echo "${p}${APEX}${s}"
  done
done

Candidate generation (PowerShell):

$Apex = "acme"
$Prefixes = @("", "backup-", "assets-", "static-", "dev-", "prod-")
$Suffixes = @("", "-backup", "-assets", "-static", "-media", "-data", "-uploads", "-dev", "-prod", "-staging", "-logs", "-private", "-public", "-dump", "-archive")
foreach ($p in $Prefixes) { foreach ($s in $Suffixes) { "$p$Apex$s" } }

7. AWS Account-ID Recovery from a Leaked Access Key (Offline Decode)

Every AWS access key ID has the 12-digit owning account number encoded inside the key string itself — recoverable by a deterministic base32 decode with no secret key, no network call, and no live AWS credential. A single leaked AKIA…/ASIA…/AROA… string already in hand — even one that's long dead or rotated — discloses the org's AWS account number. This is genuinely offline OSINT (no authorization concern beyond already lawfully holding the key, §1), and it's a real gap in the general arsenal: offensive-osint §22.7 covers ARN-regex extraction and accountId JSON-field scraping, but not this decode.

7.1 Why the account ID matters

• Cross-account trust-policy abuse — target trust policies that reference the account by number.
• IAM role/principal enumeration — an sts:AssumeRole error-message differential ("not authorized" vs. "does not exist") distinguishes real principals from guesses. This reverse step needs the operator's own AWS credentials against the target account and is intrusive/CloudTrail-logged on the target's side — out of scope for this skill, described here only.
• Targeted IAM-role phishing — a real account number lends legitimacy to a role-assumption pretext.

7.2 Key prefixes → entity type

The decode is identical across every prefix; the prefix only tells you which IAM entity type the key belongs to.

Shape: 4-character prefix + exactly 16 base32 characters (A–Z, 2–7) = 20 characters total.

7.3 The algorithm

1. Uppercase the string; take the first 20 characters.
2. Confirm the first 4 characters are a valid prefix (§7.2) and the remaining 16 match [A-Z2-7]{16}.
3. Base32-decode those 16 characters → 10 raw bytes.
4. Take the first 6 bytes, interpret as a big-endian integer z.
5. account = (z & 0x7FFFFFFFFF80) >> 7
6. Zero-pad to 12 digits. If the result exceeds 999,999,999,999, the input wasn't really a key (reject).

Published by Aidan Steele / Tenable; reference implementation credit to A. Frichetten (hackingthe.cloud).

7.4 Runnable — stdlib-only Python

#!/usr/bin/env python3
"""Offline AWS account-ID decode. No secret, no network, no live key needed.
Mirrors core/aws_account.py's account_id_from_access_key(). Stdlib only.

Usage:
  echo "ASIAY34FZKBOKMUTVV7A" | python3 aws_account_decode.py
  python3 aws_account_decode.py AKIA... ASIA...
  python3 aws_account_decode.py < file_with_keys.txt
"""
import base64
import re
import sys

_VALID_PREFIXES = {"AKIA", "ASIA", "AROA", "AIDA", "AGPA", "AIPA",
                    "ANPA", "ANVA", "ABIA", "ACCA"}
_KEY_RE = re.compile(r"\b(A[A-Z0-9]{3}[A-Z2-7]{16})\b")
_MASK = 0x7FFFFFFFFF80
_MAX_ACCOUNT = 999_999_999_999

# AWS documentation / reserved example account IDs — never report these as a
# real disclosure; they pervade IAM policy docs, Terraform tutorials, SDK samples.
EXAMPLE_ACCOUNT_IDS = {
    "123456789012", "111122223333", "222233334444", "333344445555",
    "444455556666", "555566667777", "666677778888", "777788889999",
    "888899990000", "999900001111", "012345678901", "000000000000",
    "123412341234", "101010101010",
}


def account_id_from_access_key(key: str):
    k = (key or "").strip().upper()[:20]
    if len(k) != 20 or k[:4] not in _VALID_PREFIXES:
        return None
    body = k[4:]
    if not re.fullmatch(r"[A-Z2-7]{16}", body):
        return None
    try:
        decoded = base64.b32decode(body)
    except Exception:
        return None
    z = int.from_bytes(decoded[:6], "big")
    account = (z & _MASK) >> 7
    if account > _MAX_ACCOUNT:
        return None
    return f"{account:012d}"


def main() -> int:
    text = " ".join(sys.argv[1:]) or sys.stdin.read()
    seen = set()
    for m in _KEY_RE.finditer(text):
        key = m.group(1)
        if key in seen:
            continue
        seen.add(key)
        acct = account_id_from_access_key(key)
        if acct is None:
            continue
        flag = " (AWS EXAMPLE ID -- not a real disclosure)" if acct in EXAMPLE_ACCOUNT_IDS else ""
        print(f"{key} -> {acct}{flag}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

7.5 Test vector

ASIAY34FZKBOKMUTVV7A -> 609629065308

Verify any reimplementation against this before trusting its output.

7.6 Example-account screening

Screen every decoded (and every ARN-extracted) account ID against the 14 documented AWS example account IDs above — 123456789012 chief among them, present in nearly every AWS IAM policy doc, Terraform tutorial, and SDK sample. Skip this check and a plain documentation page in the response corpus mints a false "owned AWS account" finding.

Two complementary offline extraction paths, in addition to the decode:

• ARN regex (any JSON/HTML/JS body): arn:aws[a-z0-9\-]*:[a-z0-9\-]*:[a-z0-9\-]*:(\d{12}):
• AWS-qualified accountId field only — deliberately requires the aws qualifier (aws[_-]?account[_-]?id), never a bare "accountId":"…", since a bare field is just as likely an internal billing/customer record that happens to be 12 digits.

7.7 Ownership + severity/confidence

Decode every access key found in the corpus, plus pull account IDs from ARNs and AWS-qualified accountId fields. Ownership is structural, not scored:

Every leaking page emits a DISCLOSES_ACCOUNT edge to the account it references — for owned and referenced accounts alike. An owned account additionally earns an OWNED_BY-target edge — a legitimate attack-path pivot. A referenced-only account has just the DISCLOSES_ACCOUNT edge and is never treated as the org's own escalation target — it's a third party's account, though still worth recording.

Note the deliberate severity ceiling: MEDIUM even for an owned account, because the finding itself is "your account number is now public" — real but modest on its own (rotate the leaked key; the number can't be un-disclosed). Severity escalates only through what an attacker does with the number next (§7.1), which this skill does not perform.

8. Dependency Confusion — Internal Signal + Public-Registry Unclaimed Confirmation

offensive-osint §44 covers registry search and secret hunting inside packages the target published. This is the opposite direction: what does the target's own manifests reference? A dependency name that carries an internal signal and is unclaimed on the public registry is a name an attacker can register today and have pulled into the target's build the next time a resolver falls back to the public index.

8.1 Manifest mining (read the target's own captured corpus — never re-fetch for this)

8.2 The internal-signal classifier (zero I/O — pure text logic)

A dependency name is a candidate only when it carries one of these signals:

Org-namespace tokens come from the target's registrable brand label — never the leftmost DNS label; a target reached via staging.acme.com yields the token acme, never staging — plus any ORG-typed asset already in the graph. A bare unscoped name with no private-registry binding and no namespace match carries no signal — indistinguishable from a typo or a yanked release — and is dropped, never emitted as a candidate.

8.3 The two-part confirmation contract — neither half alone is a finding

An internal signal alone is not proof the name is available — plenty of internal packages are also correctly published privately-but-globally-unique. A public-registry 404 alone is meaningless — a typo, an unpublished/yanked version, or a local-only dep all 404 too. Both must hold:

1. Internal signal (§8.2) — screens out ordinary public dependencies and unknown bare names.
2. Public-registry existence check returns 404 — a read-only GET against the real registry.npmjs.org / pypi.org, never the target. This is exactly why it's in scope under the pack's "public-registry 404 checks" line even though it's a live network call: the traffic lands entirely on a third-party public registry, zero packets to the client.

Fail closed on any ambiguity — a 200 (published), 403, 5xx, or timeout never emits a finding. Uncertainty is not evidence of claimability.

8.4 npm scope claimability — the nuance a bare-package check misses

For a scoped name (@scope/pkg), the package 404ing isn't the interesting fact — the whole scope must be unclaimed for the name to be squattable. Check the scope's org and user profile pages, not the public search API:

GET https://www.npmjs.com/org/{scope}    -> 200 = scope owned as an org
GET https://www.npmjs.com/~{scope}       -> 200 = scope owned as a user

The name is registerable only if both 404. The npm search API is deliberately not used for this: it returns total:0 for a scope that is privately owned but hosts no public packages, which would falsely read as "unclaimed." The org/user profile pages return a real 404 only when the scope genuinely doesn't exist, regardless of what it might privately host.

8.5 Severity / confidence

Never CONFIRMED — this is static manifest analysis over a captured corpus, not a live resolver-fallback observation. There is no "the build actually pulled the malicious package" event to point at.

8.6 Recipes

bash:

# unscoped npm
curl -sk -m 15 -o /dev/null -w '%{http_code}\n' "https://registry.npmjs.org/acme-internal-utils"
# scoped npm -- package + both scope-ownership pages
curl -sk -m 15 -o /dev/null -w '%{http_code}\n' "https://registry.npmjs.org/@acme%2Fdesign-system"
curl -sk -m 15 -o /dev/null -w '%{http_code}\n' "https://www.npmjs.com/org/acme"
curl -sk -m 15 -o /dev/null -w '%{http_code}\n' "https://www.npmjs.com/~acme"
# PyPI
curl -sk -m 15 -o /dev/null -w '%{http_code}\n' "https://pypi.org/pypi/acme-internal-tools/json"

PowerShell:

function Test-RegistryStatus {
  param([string]$Url)
  try {
    $r = Invoke-WebRequest -Uri $Url -Method Get -TimeoutSec 15 -SkipHttpErrorCheck   # PS7+; on PS 5.1 read $_.Exception.Response in the catch
    return $r.StatusCode
  } catch { return "error" }
}
Test-RegistryStatus "https://registry.npmjs.org/acme-internal-utils"
Test-RegistryStatus "https://www.npmjs.com/org/acme"
Test-RegistryStatus "https://www.npmjs.com/~acme"
Test-RegistryStatus "https://pypi.org/pypi/acme-internal-tools/json"

Bound the check volume — filter to internal-signalled candidates before hitting the registry (hundreds, not thousands, per engagement) and cache scope-ownership lookups (one org/user check per distinct scope, never per package under that scope).

8.7 Out of scope

Reserving the name — publishing a stub the org controls — is a remediation the client performs, not a step this skill takes. This skill's ceiling is: "this name is internal-signalled and currently unclaimed." Confirming that a live resolver fallback actually pulls a planted package, or registering anything under the discovered name, is active supply-chain interference and out of scope regardless of authorization — hand it to the client as the remediation action (§8.5 evidence + §10 business translation).

9. Cloud-Native & Container/K8s/CI Control-Plane Fingerprinting — an Org-Attribution Surface

Modern infrastructure increasingly is the org-attribution signal: a Lambda Function URL, a *.run.app Cloud Run service, or an exposed kubelet is both an exposure and a fingerprint of which cloud account/cluster belongs to the target. Everything in this section is passive — pattern-matching over hostnames and ports already resolved by earlier recon, zero new network calls of this skill's own. offensive-osint §16.17–§16.19 carries the fuller URL-pattern and active-probe tables (20 cloud-native providers, the full container-registry search list, 11 CI/CD platforms with active curl recipes); this section is the reasoning layer that decides what a hit is worth and whether it's the target's.

9.1 Cloud-native endpoint fingerprint

Match already-resolved hostnames — subdomain CNAME targets, certificate SANs, subdomain FQDNs themselves, and webapp URLs — against provider URL patterns:

(offensive-osint §16.17 extends this to 20 providers — App Runner, CloudFront, ALB/ELB, Amplify, Static Web Apps, Vercel, Netlify, Cloudflare Workers/Pages, Heroku, Render, Fly.io, Railway, DigitalOcean App Platform.)

Ownership gating is structural, not scored — the same discipline as §6.3's bucket model, applied to endpoints:

Owned → MEDIUM/FIRM. Unverified (a bare pattern match with no corroborating tie) → LOW/TENTATIVE. Confirming whether the endpoint is actually invocable without authentication is the stage-6 --validate --validate-cloud step — out of scope; this section only says "this cloud-native surface exists and appears to belong to the target," never "it's exploitable."

9.2 Container / Kubernetes control-plane exposure — passive flag, not active probe

Rather than issuing new probes, treat orchestration control-plane ports already discovered by port/service enumeration as a likely-exposed control plane. All five carry HIGH severity, FIRM confidence once flagged — the port being open is directly observed; the auth posture behind it is not, which is exactly why confirmation is gated separately:

(offensive-osint §16.18 has the fuller table — kube-proxy/controller-manager/scheduler health/metrics endpoints, cAdvisor, Helm Tiller — plus the active curl recipe for each and the public-container-registry search list across Docker Hub/Quay/GHCR/ECR Public.)

The port being open says nothing about its auth posture. Flag it; do not connect to it to find out. A live GET/HEAD against the endpoint to confirm whether it answers unauthenticated is exactly the line this skill stops at.

9.3 CI/CD platform surface

Fingerprint from tech strings already collected by passive web/HTTP enumeration — Jenkins, GitLab (self-hosted), Argo CD, Harbor, TeamCity, Drone. MEDIUM/TENTATIVE — a tech-string match is a weaker signal than a resolved hostname pattern, hence TENTATIVE rather than FIRM. A CI/CD console or API, when reachable unauthenticated, exposes build pipelines, stored credentials, and artifact registries — a supply-chain foothold. offensive-osint §16.19 has the per-platform active probe paths (/script, /api/v4/version, /gate/info, …) and the GitHub Actions secret-leak anti-pattern catalog (workflows that echo ${{ secrets.* }} to logs, or check out fork-PR code under pull_request_target) for an operator who chooses to go further under their own authority.

9.4 What's out of scope here

Any GET/HEAD issued specifically to confirm a fingerprinted cloud-native endpoint or control-plane port is reachable/unauthenticated is a stage-6 --validate --validate-cloud active tier — hard-gated behind explicit --validate plus per-target scope confirmation, default OFF. This skill's ceiling is the passive fingerprint and the "likely exposed, auth posture unconfirmed" flag; describe the confirmation step, never perform it.

10. Severity & Business Translation

11. Skill Self-Test

Drop these into a fresh session to verify the skill loads and routes correctly.

1. "Generate S3/GCS/Azure bucket candidates for acme.com with subdomains api/billing/hr and probe them." → §6.1–§6.2, §6.5.
2. "We found a listable S3 bucket named marketplace-media from a permutation guess — can't tie it to the client. Is that CRITICAL?" → negative. §6.3 — no; an unverified public/listable hit produces no finding at all (not even INFO); it's recorded as an asset only.
3. "Same bucket, but its object listing includes acme-employee-payroll.csv." → §6.3 branded-object-key ownership signal — now verified, promote to CRITICAL.
4. "What's exposed inside a listable bucket, without downloading any object?" → §6.3 object-key triage table (filename-pattern classification of the listing body only).
5. "A subdomain has a live CNAME to a bucket that returns 404 NoSuchBucket. What's the finding?" → §6.4 — dangling-CNAME takeover, HIGH, CONFIRMED, independent of the ownership-gating table.
6. "Decode the AWS account ID from ASIAY34FZKBOKMUTVV7A." → §7.3–§7.5, test vector 609629065308.
7. "We found 123456789012 as an accountId in a Terraform snippet on the target's site. Real disclosure?" → §7.6 — no; that's a documented AWS example account ID, screen it out.
8. "Should I use the decoded account ID to enumerate IAM roles via sts:AssumeRole?" → negative. §7.1/§5 — out of scope; needs the operator's own AWS credentials against the target account and is CloudTrail-logged; describe the pivot value, don't perform it.
9. "package.json references @acme/design-system, and .npmrc binds @acme to a private registry. Is that a finding by itself?" → §8.2–§8.3 — internal signal only; still needs the public-registry 404 (and scope-claimability, §8.4) check before it's a finding.
10. "npm's public search API returns total:0 for @acme. Is the scope claimable?" → §8.4 — no; the search API is blind to privately-owned scopes. Use the org/user profile-page 404 check instead.
11. "Confirmed unclaimed dependency-confusion vector. Should we reserve the package name to protect the client?" → negative. §8.7 — out of scope; that's a client remediation action, not this skill's step.
12. "A subdomain CNAMEs to *.run.app. Is that Cloud Run endpoint owned or unverified?" → §9.1 — CNAME provenance = owned.
13. *"Port 6443 is open per a prior port scan. What do I do ne

…(truncated)