---
title: "Attack Surface Discovery by Company Name"
canonical: https://trickest.com/library/legal-entity-attack-surface-mapper
description: "Start from a company's registered name and find the domains it has certified, the networks those resolve into, and the hosts that answer."
---

# Attack Surface Discovery by Company Name

## Overview

Scoping usually starts with a name, not a domain. An acquisition target, a
supplier, a parent company with subsidiaries you have never listed. The estate is
spread across brands and registrars, and asking for a list gets you the one the
other side maintains, which is the one that is already known.

The chain that closes the gap runs name to domains to networks to hosts, and this
runs all of it. Certificate transparency is the first pivot: a certificate
carries the subject organization, so the names a company has proved control over
are reachable from the legal name instead of from a domain you already knew.
Registry data is the second, turning the addresses those domains resolve to into
the origin ASNs the estate sits in, with dedicated ranges expanded to what they
contain. Probing is the third, and it is what separates a name on a list from a
host that answers. You finish with the live hosts and, per host, the evidence
that put it in scope. That is the opening move in an
[M&A security review](/use-cases/exposure-management), before you have
credentials, an agreement, or a scope document.

Nothing in discovery needs an API token or a relationship with the target, which
is what makes it usable on a company that has not agreed to anything yet. Run it
again a quarter later and the difference is the finding: a subsidiary that
started filing certificates, a range that arrived with an acquisition, a brand
that was never on the corporate site.

## Pipeline

1. Read the organization's legal name.
2. Entity discovery resolves the name against certificate transparency for
   domains whose certificates name the organization, and against registry data
   for the origin ASNs those names resolve into.
3. [httpx](/tools/httpx) probes the resulting hosts across the fleet and records
   what answers.
4. Results are correlated back to the entity, so every host carries the reason it
   was attributed, with a confidence score and an off-core drift flag.
5. The dossier is written to a PDF.

## Inputs

- **Org name.** The legal entity as it is written on certificates and in registry
  records. Start from the registered name rather than the trading brand, and run
  a group's filing names one at a time so you can tell which subsidiary each
  result came from.
- **Credentials.** None. Certificate transparency and registry lookups are
  token-free, which is the default worth keeping, because it is what lets the
  run happen before you have any access to the target.
- **Probe scope.** Plain HTTP against the hosts discovery attributed to the
  entity, capped per run. Nothing is authenticated and nothing is fuzzed, so the
  safe default is also the only mode.

## Outputs

- **Domain set from certificate transparency.** The names the entity has proved
  control over, including brands and country sites that are not linked from the
  corporate homepage.
- **Origin ASNs and expanded ranges.** The networks the estate resolves into,
  with dedicated ranges broken out into the addresses they announce.
- **Live host list.** Every probed host that answered, with what it served.
- **Attribution record per host.** The certificate or the ASN that put the host
  in scope, a confidence value, and a flag when the host sits away from the
  entity's core ranges.
- **Footprint dossier (PDF).** The run in one document, which is the artifact you
  attach to a scoping note or a diligence file.

## Sample output

Illustrative, in the record shape a completed run emits. A real run names the entity you scope it to; a documentation entity stands in here.

Discovery starts from the name and produces the identifiers everything else hangs
off:

```jsonl
{"kind": "entity", "org": "Example Corporation", "arin_orgs": 1, "dedicated_asns": [], "hosting_asns": [64496, 64500, 64511]}
{"kind": "asset", "asset": "accounts.example.com", "type": "domain", "origin": "CT cert org=Example Corporation", "source": "crt.sh", "confidence": "high"}
{"kind": "asset", "asset": "portal.example.com", "type": "domain", "origin": "CT cert org=Example Corporation", "source": "crt.sh", "confidence": "high"}
{"kind": "asset", "asset": "api.example.net", "type": "domain", "origin": "CT cert org=Example Corporation", "source": "crt.sh", "confidence": "high"}
{"kind": "asset", "asset": "104.20.23.154", "type": "ip", "origin": "resolves from example.com", "source": "dns", "confidence": "medium"}
{"kind": "summary", "org": "Example Corporation", "seed_domains": 300, "owned_prefixes": 0, "dedicated_asns": [], "hosting_asns": [64496, 64500, 64511], "core_domains": ["example.com", "example.net", "example.org"], "live_assets": 109, "drift_assets": 42}
```

Every asset in the block above carries the reason it was pulled in, in the
`origin` and `confidence` fields.

Attribution is the part to check before you act, and this run is the example. No
ASN came back registered to the entity, so the three that did are providers its
assets are hosted on rather than network it owns, and the dossier labels them as
hosting rather than folding them into scope. The 300 seed domains reduce to 109
hosts that answered, 42 of which sit away from the core ranges and are flagged
for you to confirm or drop.

## FAQ

### Do you need a domain to start?

No, a name is enough. The first pivot is certificate transparency, which is
searchable by the subject organization on a certificate, so the domains come out
of the run rather than into it.

### How is a host attributed to the entity?

By one of two routes, and the dossier says which. Either a certificate naming
the organization produced the domain the host serves, or the address the domain
resolves to sits in an ASN the estate already occupies. Each host carries a
confidence value alongside that reason.

### Why does a range show up that clearly is not theirs?

Because an origin ASN tells you where a name resolves, not who owns the network.
A domain parked on a shared host or fronted by a CDN resolves into that
provider's ASN, and none of that range belongs to the entity. Verifying
attribution is the step before acting on scope, which is why hosts sitting away
from the core ranges are flagged rather than quietly included.

### Is it safe to run against a company you have no agreement with?

Discovery is passive and sends nothing to the target. The probe is plain HTTP
against hosts that are already publicly reachable. Your own rules of engagement
still decide whether you run it.

### What does running it on a schedule buy?

The delta. A subsidiary that starts filing certificates under a new brand, or a
range that arrives with an acquisition, shows up as rows that were not in the
last dossier.

## Related workflows

- [ASN-Wide Vulnerability Scan](/library/asn-vulnerability-scanner). Reach for this
  once attribution holds and you have the netblocks, because it goes after the
  actual vulnerabilities in them rather than inventorying what is there.
- [Domain OSINT & Footprinting](/library/domain-osint-and-footprinting). Reach
  for this instead when you already know the primary domain and want depth on it,
  registration and DNS and certificate history, rather than breadth across an
  entity.
- [Check Email Spoofing (DMARC SPF DKIM)](/library/email-spoofing-scanner-dmarc-spf-dkim).
  Reach for this alongside, because when you are assessing an acquisition or a
  vendor, mail-authentication posture is the cheapest hygiene signal you can
  collect.

---
_Markdown source of https://trickest.com/library/legal-entity-attack-surface-mapper._