---

name: org-attack-surface description: "Org-grade attack-surface mapping: given a company's legal identity, discover its ENTIRE owned internet footprint — corporate family -> owned domains -> owned netblocks/ASN -> live assets — with attribution discipline, not just DNS breadth. The org-first attribution pyramid (legal entity -> LEI/registration -> corporate family -> owned domains -> owned netblocks/ASN -> live assets). Corporate-identity resolution via the GLEIF LEI API (legal name -> LEI, exact-LEI direct-children expansion, downward-only depth-capped BFS, NEVER a name re-resolution), SEC-EDGAR full-text search + Exhibit-21 subsidiary entity names, OpenCorporates entity corroboration, Wikidata SPARQL corporate graph (P856/P355/P749/P1830). Domain attribution via reverse-WHOIS (WhoisXML preview-then-purchase quota guard, SecurityTrails associated-domains — both paid), crt.sh O= certificate-transparency organization pivot (keyless), infrastructure correlation (shared NS/MX/SaaS-TXT, netblock membership, reverse-DNS PTR), and the independent-evidence combiner (1-prod(1-w_i), rule of three, OwnerTier NONE/WEAK/MODERATE/STRONG/CONFIRMED) — discover-only related: candidates are NEVER auto-scanned. Netblock/ASN attribution via org-first RIR queries (ARIN Whois-RWS org-handle search, RIPE DB organisation + inverse-org search) that recover 'dark netblocks' with no DNS link to the seed, ASN discovery (RIPEstat + BGPView union), the HYPERSCALER-SCOPE GUARD (never attribute a whole AWS/GCP/Azure/Cloudflare announced range to a tenant — keep only the seed-containing block, tag shared_hosting_cdn), and org-identity-seeded internet-scan-index queries (Shodan/Censys/ZoomEye/FOFA/BinaryEdge org: filters + an always-on keyless crt.sh fallback). Promote-to-scan triage ranks forgotten discover-only netblocks by remote-access exposure (gateway-vendor/KEV/control-plane/datastore port scoring) into an operator queue. Attribution confidence rubric + anti-patterns (namesake grafting via GLEIF name re-resolution, single-signal ownership, hyperscaler over-attribution, privacy-WHOIS pivot poisoning, RIR org-name collisions). Passive/keyless-first OSINT only — every paid-key dependency is enrichment on top of a keyless core, never a hard requirement. Use when mapping an organization's full corporate-family internet footprint, resolving a legal entity to its LEI/subsidiaries, discovering domains/netblocks/ASNs an org owns beyond its one seed domain, auditing M&A/shadow-IT sprawl, or scoping an engagement that starts from a company NAME rather than a domain." version: 1.0 sources: asm_reference_impl, gleif, public_research triggers:

• org attack surface
• organization attack surface
• org footprint
• corporate footprint
• corporate family
• corporate family mapping
• corporate family tree
• subsidiary discovery
• subsidiary attack surface
• subsidiary mapping
• GLEIF
• LEI lookup
• legal entity identifier
• legal name to LEI
• EDGAR subsidiary
• SEC EDGAR
• Exhibit 21
• 10-K subsidiaries
• OpenCorporates
• Wikidata corporate graph
• reverse WHOIS
• reverse whois pivot
• crt.sh organization search
• crt.sh O=
• certificate transparency org pivot
• CT org pivot
• dark netblock
• org-first RIR search
• ARIN Whois-RWS
• ARIN org search
• RIPE DB search
• RIPE organisation search
• RDAP entity search
• ASN discovery
• BGPView
• RIPEstat
• hyperscaler scope guard
• cloud netblock over-attribution
• shared hosting CDN attribution
• AWS netblock attribution
• M&A footprint
• M&A attack surface
• shadow IT discovery
• promote to scan
• discover-only candidate
• org identity resolution
• corporate identity resolution
• owned netblock discovery
• owned ASN discovery
• org index search
• outward identity search
• identity-seeded discovery
• attribution confidence
• ownership tier
• owner signal
• independent evidence combiner
• rule of three attribution
• namesake grafting
• org tree walk
• subsidiary entity pivot
• registrant org pivot
• WHOIS privacy pivot
• Shodan org filter
• Censys organization filter
• company name to attack surface

---

Org Attack Surface — Corporate-Family Footprint Mapping

Companion skills: osint-methodology (the "how to think" 5-stage recon pipeline this plugs into) and offensive-osint (the per-host arsenal you run once this skill hands you owned domains/netblocks — see its §14 Public Records and §28 Infrastructure OSINT for the tool directory this skill deepens rather than duplicates). This skill answers a different, upstream question: not "what does acme.com expose", but "what does Acme Corporation, the legal entity, own across every domain, netblock, and subsidiary it has — including the parts with no DNS trail back to the seed at all."

0. When to Use / When NOT

Use this skill when:

• The engagement starts from a company name or legal entity, not a domain — you need to derive the domain(s) first, not just enumerate one.
• You need to find an org's subsidiaries, sister brands, or M&A-acquired footprint that a DNS/CT-only sweep of one seed domain would never surface.
• You suspect "dark" IP space — netblocks or ASNs registered to the org's legal entity with no DNS record pointing at them (forgotten datacenter allocations, un-linked M&A infrastructure, IPs that only ever ran raw services).
• You need attribution discipline: every candidate domain/netblock/ASN this skill surfaces carries an explicit, auditable ownership score — never a bare "looks related."
• You are scoping a large or conglomerate engagement and need to prune scope by real corporate ownership before spending recon budget on strangers.

Do NOT use this skill when:

• You already have a confirmed, bounded target list and just need per-host recon — go straight to offensive-osint.
• The target's authorization isn't established — see §1.
• You need active exploitation or post-exploitation — out of scope here and everywhere in this skill family.

---

1. Authorization & Legal Posture

Same posture as the companion skills: intended for assets the operator owns or has written authorization to assess. This skill is unusually likely to surface entities the operator did NOT ask about (subsidiaries, sister brands, M&A targets) — that is the point, but it sharpens the scope question rather than loosening it.

Soft scope check — ask once when unclear:

"This will surface the target's subsidiaries and related infrastructure, some of which may be outside your engagement scope. Should I include the full corporate family, or stay bounded to the named entity and its direct domains?"

Always-on guardrail specific to this skill: every asset this skill discovers beyond the seed domain — related domains, dark netblocks, discover-only ASNs, index-search IPs — is a lead, not a target. See §6.6 and every "discover-only" callout below. Nothing this skill produces is automatically in scope for active testing; a human confirms ownership first.

---

2. Confidence Levels & Ownership Tiers (two axes — do not conflate them)

This skill runs two separate scoring axes, and mixing them up is the single most common way to misreport a finding.

Axis 1 — Finding confidence (same as the companion skills): TENTATIVE / FIRM / CONFIRMED. Answers "how sure am I this asset/record exists and I read it correctly."

Axis 2 — Ownership tier: answers "how sure am I this asset belongs to the target organization." Computed by combining every OwnerSignal that fired for a candidate via an independent-evidence formula (full mechanics in §8.4):

| Score band | Tier | Meaning | |---|---|---| | 0 | NONE | No signal fired. | | 0–39 | WEAK | One low-weight signal (e.g. shared nameserver) — a lead, not attribution. | | 40–69 | MODERATE | Multiple weak signals, or one medium signal — worth an operator's eyeball. | | 70–89 | STRONG | Multiple independent signals, or one high-confidence signal — an active-scan-eligible score in a typical ASM promotion gate. | | 90–100 | CONFIRMED | Independent corroboration close to certainty, or a confirming signal (e.g. the seed domain itself) that forces 100 directly. |

A NOT_OWNED (stranger-lock) signal caps the score at 20 regardless of how many weak positives also fired — so a foreign asset that happens to share a generic nameserver with the seed can never climb into an owned tier.

Critical nuance: ownership tier is advisory, not a gate. Every domain/netblock/ASN/IP this skill mints beyond the seed carries an explicit discover_only=True structural flag that keeps it out of active scanning independent of its score — a related: domain that happens to score STRONG (85) still does not get auto-scanned. The score tells the operator which discover-only lead to promote first; only an explicit operator action (§10, promote-to-scan) moves an asset into the active pipeline.

Rule of three still applies on top of the numeric score: a single signal type, however individually weighted, is a lead. Treat anything below STRONG as requiring a second, independent signal class before you say it out loud to a client as "this belongs to them."

---

3. Output Format

Every candidate carries the standard finding schema (see companion skill §3) plus the org-attribution evidence block:

Finding:
  id:          <stable hash>
  module:      org-attack-surface
  asset_key:   <typed key — e.g. org:acme-corp, related:acmesub.com, net:203.0.113.0/24, asn:64500>
  category:    ORG_FOOTPRINT | RELATED_DOMAIN | DARK_NETBLOCK | PROMOTE_QUEUE
  severity:    info                      # attribution work is discovery, not a vuln — see §6.6
  confidence:  <tentative|firm|confirmed>   # Axis 1 — did I read the record right
  title:       <one-line summary>
  description: <what was found + why it's plausibly the org's>
  attribution:
    owner_score:    <0-100>              # Axis 2 — combine() output
    owner_tier:      <none|weak|moderate|strong|confirmed>
    discover_only:   true                # structural gate; independent of owner_score
    signals:
      - name:       <signal name, e.g. cert_org_match>
        weight:      <0.0-1.0>
        confirming:  <bool>
        detail:      <human-readable evidence, e.g. "crt.sh O= match: Acme Corp">
        source:      <module/connector>
  evidence:
    url:       <where found>
    timestamp: <UTC ISO8601>
    raw:       <truncated to 2 KiB>
  references:  [<registry URL, RFC, etc.>]
  remediation: <"confirm ownership before promoting to active scan" — always the remediation here>

UTC timestamps everywhere. Never collapse attribution.signals to a bare count — the reviewing operator (or an auditor asking "why did you attribute this to them") needs to see exactly which evidence fired, not just how much.

---

4. Source Hygiene & Citations

Same discipline as the companion skills: URL + UTC timestamp + tool/API version + run_id on every artifact. For registry lookups specifically:

• Record the exact query string sent to GLEIF/EDGAR/ARIN/RIPE — registry search results are not reproducible from a vague "I searched for the company" note months later.
• Cache raw registry JSON responses (GLEIF, ARIN, RIPE, EDGAR) — these APIs change/deprecate fields and a re-run six months later may not reproduce the same shape.
• GLEIF LEI records and EDGAR filings are durable references (an LEI or CIK doesn't expire); prefer citing those over an ephemeral index-search hit.

---

5. Do NOT

• Do NOT auto-scan a related: domain, a discover_only netblock/ASN, or a discover_only IP. Ever. That is the entire structural contract of this skill (§2, §6.6).
• Do NOT re-resolve a subsidiary's name against GLEIF/EDGAR/OpenCorporates once you already hold its exact L