--- title: "The Domain Resolved. Ownership Was Still a Hypothesis." description: "A defensible external pentest does not turn company names, CT records, shared IPs, or acquisition news into targets. It separates association, current control, and written scope—then records the evidence for each decision." date: 2026-09-08 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/domain-ownership-attribution-evidence/ --- ## Domain attribution in 60 seconds A domain can resolve, present a familiar brand, share a certificate with a known host, and sit on an address once used by an acquired company. None of those facts alone proves that the customer controls it today. Even confirmed ownership does not create permission to test it. External pentest recon therefore has to answer three different questions: 1. **Association:** why did this candidate enter the investigation? 2. **Current control:** what evidence shows who operates or governs it now? 3. **Authorization:** what does the written scope allow the testing team to do? Collapsing those questions into one `in_scope` boolean is how plausible OSINT becomes unsafe targeting. The correct output is an attributed candidate ledger: every relationship has a source, an observation time, a confidence state, contradictory evidence, and a separate scope decision. The domain is not the finding. The reasoning that admits or rejects it is the work. ## A company name is a seed, not a boundary The first article in this series treated the external perimeter as a graph. Corporate identity is the graph's starting layer because most organisations operate through more than one name: parent entities, regional companies, product brands, acquisitions, divestitures, joint ventures, and domains retained after a migration. Those relationships are useful candidate generators. They are not testing authority. For public companies, the [SEC's EDGAR search](https://www.sec.gov/search-filings) provides access to filings that can describe subsidiaries, material agreements, acquisitions, divestitures, and business segments. Other jurisdictions have their own official company registries. An organisation's investor pages, legal notices, privacy policies, product documentation, and acquisition announcements can add current operational context. The safest sequence is: - record the legal or commercial relationship exactly as the source describes it; - record when that relationship was stated; - generate domain and application candidates from it; - seek independent technical evidence of current control; - ask the customer to resolve anything that would change the authorized target set. An acquisition announcement proves that a transaction was announced or completed at a stated time. It does not prove that every historic domain transferred, that systems were integrated, or that the acquired company's infrastructure is included in this engagement. A divestiture can make the reverse mistake equally dangerous: a familiar old hostname may now belong to somebody else. ## Keep attribution and scope on separate axes Attribution confidence describes the evidence. Scope state describes permission. Neither can substitute for the other.

A technically convincing ownership case can still be out of scope. Written approval can also contain an attribution mistake. Execution begins only when both axes are resolved.

Use explicit states rather than a percentage that implies more precision than the evidence can support. | Attribution state | Meaning | | ----------------- | ------------------------------------------------------------------------- | | `confirmed` | Current control is supported by authoritative or customer-confirmed facts | | `probable` | Multiple independent current signals support the same operator | | `possible` | A credible association exists, but current control remains unresolved | | `contradicted` | Stronger evidence conflicts with the original ownership hypothesis | Scope needs its own vocabulary: | Scope state | Required behavior | | ------------------ | --------------------------------------------------------------------------- | | `approved` | Test only through the methods, time window, and source addresses in the RoE | | `excluded` | Preserve context; do not interact with the candidate | | `needs-decision` | Send a bounded evidence packet to the customer | | `approval-expired` | Reconfirm before further interaction | This distinction also improves reporting. A client can disagree with an attribution decision without silently changing the Rules of Engagement, and a scope change does not rewrite the historical evidence. ## Build the corporate seed ledger Begin with sources that describe the organisation in its own legal and commercial context. The goal is not to collect every mention of the company. It is to identify relationships capable of producing a technical trust boundary. Useful seed questions include: - Which legal entities and brands does the parent publicly control? - Which companies were acquired, merged, divested, or retired? - Which country or product domains appear in official legal and privacy notices? - Which applications are linked from official documentation or mobile-store listings? - Which identity, payment, support, delivery, and data-processing providers are named? - Which old product names still appear in current customer journeys? Each seed should retain the smallest useful quotation or paraphrase, the source URL, publication or observation date, and the relationship claimed. Do not convert employee profiles into target lists. Public role information may explain which team owns an identity or infrastructure boundary; personal accounts, phone numbers, home addresses, credential dumps, and individual targeting do not belong in normal infrastructure recon. A corporate seed record can be compact: | Field | Example | | ---------------------- | ------------------------------------------------------------ | | `entity` | The parent, subsidiary, acquired company, brand, or provider | | `relationship_claimed` | Acquired by, operated by, regional entity, product of | | `source_class` | Filing, official site, legal notice, press release | | `source_date` | When the source described the relationship | | `candidate_roots` | Domain hypotheses generated from that relationship | | `open_question` | The next fact needed to establish current technical control | The ledger protects against a common failure: a search result is copied into a domain list, the source disappears, and nobody can later explain why the domain was tested. ## Corroborate current control with technical evidence Corporate evidence explains why a candidate matters. Technical evidence tests whether the relationship still exists. ### Registration data [ICANN describes RDAP](https://www.icann.org/rdap/) as the protocol for accessing current domain and internet-number registration data and the replacement for legacy WHOIS. Its structured format makes it a useful source for registrar, status, nameserver, event, and redacted entity data. Registration data is supporting evidence, not a verdict. Privacy redaction can hide the operator. Corporate registrars and privacy services create common infrastructure across unrelated customers. Old registrant data may survive a reorganisation. A matching organisation name is useful; its absence is not disproof. ### Certificate history [Certificate Transparency logs](https://certificate.transparency.dev/logs/) are public, append-only and auditable records of certificate activity. A logged certificate can recover hostnames absent from current documentation and expose naming relationships around migrations, regional platforms, and acquired products. CT proves that a certificate containing the name was logged. It does not prove that the name ever resolved, that the certificate was deployed, that the organisation requested it, or that the host is still controlled by the same party. Issuance time and certificate validity are evidence times, not ownership times. ### DNS and application behavior Current DNS is stronger when it forms a coherent chain: an official root delegates to known nameservers, a hostname resolves without wildcard behavior, redirects remain within an official journey, and the application presents organisation-specific identity or legal context. A CNAME to a SaaS provider proves a naming dependency. It does not put the provider's platform in scope. Application behavior can be more probative than visual branding. A legacy hostname that participates in the parent's SSO flow, calls a parent-controlled API, or is linked from an official account portal demonstrates a present trust relationship. Those observations still need to be captured without submitting credentials or changing state before approval. ### Routing and hosting [RIPEstat](https://stat.ripe.net/docs/getting-started/what-is-ripestat) combines registration, routing, DNS, and other data about IP space and ASNs. It helps distinguish an organisation-announced prefix from a cloud, CDN, or hosting provider and exposes the observation time and source behind the result. The same IP or ASN is weak ownership evidence by itself. Shared hosting, CDN edges, managed security providers, and cloud platforms place unrelated tenants together. Even a company-operated ASN can include services owned by customers or partners. Attribute names first; expand toward addresses only when the evidence and written scope support it. ## Use an evidence ladder, not tool consensus Three tools returning the same source record are not three independent confirmations. They may all copy the same CT entry, passive DNS feed, or registry database. Confidence should rise when different evidence classes agree.

Attribution is a reviewable admission pipeline. Contradictory evidence can demote or reject a candidate at any point; no tool result bypasses the customer scope decision.

A practical evidence ladder looks like this: 1. **String coincidence:** similar brand or domain name. Candidate only. 2. **Historical corporate association:** filing, acquisition notice, or archived official page. 3. **Current naming evidence:** RDAP, DNS, CT, official link, or active redirect. 4. **Operational coupling:** shared SSO, parent API, controlled nameserver, current legal identity, or customer-confirmed service ownership. 5. **Written scope decision:** approval or exclusion with the applicable RoE constraints. 6. **Narrow current validation:** the smallest safe check from the approved test perspective. Level five is not stronger attribution evidence than level four; it is the separate authorization gate. The ladder is a workflow, not a mathematical score. ## Reject the attractive false positives The most convincing-looking candidates are often the ones most likely to be misattributed. **Shared hosting and CDNs.** Hundreds of unrelated tenants can share an address, certificate infrastructure, or edge provider. Test the approved hostname and application boundary, never the provider range inferred from it. **Wildcard DNS.** Every invented hostname appears to resolve, making wordlist results look like real applications. Compare random labels and record answer similarity, TTL behavior, and HTTP/TLS identity before accepting any discovered name. **Parked and expired domains.** A familiar brand string can now lead to a registrar parking page, reseller, or new registrant. Historical ownership can increase the security relevance of the change, but it decreases confidence that the current endpoint belongs to the customer. **Old CT records.** A certificate issued during a migration may remain visible long after the system was retired or transferred. Validate present DNS and application context. **Third-party custom domains.** A customer-controlled CNAME may point at support, identity, marketing, or storage infrastructure operated by a provider. The customer configuration and trust decision may be testable; the multi-tenant platform normally is not. **Copied branding.** Logos, CSS, page titles, favicons, and legal text are easy to clone. Treat visual similarity as a lead until control-plane or customer evidence supports it. Every rejection should remain in the ledger. Otherwise the same attractive false positive returns in the next engagement and consumes the same analyst time. ## A fictional attribution review Assume the written seed is `meridian.example`. Public material says Meridian acquired a company called Lattice four years ago. 1. An archived acquisition announcement links the two entities. `lattice.example` enters the ledger with a historical corporate association and `possible` attribution. 2. A CT record from three years ago contains `login.lattice.example` and a Meridian product name. This adds naming history, not current control. 3. Current RDAP data is privacy-redacted. DNS still resolves, but the address belongs to a large cloud provider. Neither fact moves confidence beyond `possible`. 4. The application redirects to Meridian's current identity tenant and returns to a Meridian API callback. No credentials are submitted. This present operational coupling moves attribution to `probable`. 5. A customer contact confirms that Lattice remains a supported product but says its marketing site is managed by an agency. The login application is approved; the agency platform and cloud provider are excluded. 6. The test plan identifies the hostname, SNI, permitted source address, authentication accounts, time window, and prohibited provider-level actions. Only then does active validation begin. The final target is not “everything related to Lattice.” It is one approved application boundary whose current relationship and limits can be explained. ## Make time part of every claim Ownership is not static. Domains expire, brands are sold, nameservers move, identity tenants are consolidated, and acquired applications are retired. Store at least three different times: - `source_date` — when the corporate or registration source described the relationship; - `observed_at` — when the analyst or data provider observed the technical state; - `decision_at` — when the customer approved, excluded, or deferred the candidate. Do not overwrite these with a single `last_seen` field. A five-year-old acquisition announcement, a two-month-old CT record, current DNS, and today's scope decision describe different facts. Changes also need review. A candidate that was confirmed last year may now be transferred or outsourced. A previously excluded domain may become relevant after an identity migration. Scope approval should expire with the engagement; it must not become permanent testing authority. ## Evidence matrix | Signal | What it supports | What it cannot prove | Required next step | | ----------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------- | | Filing or official acquisition announcement | A corporate relationship at a stated time | Current domain control or testing authority | Find present technical coupling and request a scope decision | | Official legal, privacy, or product page links domain | The organisation currently represents a relationship publicly | Backend ownership or permission to test every linked service | Inspect the exact application and provider boundary | | RDAP contains matching organisation data | Registration data supports the operator hypothesis | Current application operation or exclusive control | Compare DNS, official properties, and customer confirmation | | CT contains the hostname | A certificate containing the name was logged | Deployment, current reachability, ownership, or scope | Resolve current DNS and compare live TLS/application identity | | Same IP, ASN, nameserver, or CDN | Infrastructure correlation | Common ownership | Identify hosting class and seek independent evidence | | Shared SSO, API callback, or account journey | A present operational trust relationship | Permission to test the provider or every connected system | Bound the customer-controlled configuration and obtain approval | | Customer confirms ownership and scope | The named boundary is authorized under stated conditions | That the target is live, secure, or correctly attributed now | Perform the smallest current validation from the approved plane | ## What the customer should receive The deliverable is not a “verified domains” text file with the reasoning removed. Provide four connected views. **Corporate relationship map.** Entities, brands, acquisitions, divestitures, official sources, source dates, and unresolved ownership questions. **Candidate ledger.** Domain or application, discovery reason, evidence classes, observation times, confidence, contradictory evidence, hosting class, and next question. **Scope decision queue.** A short packet for each candidate that would materially change testing: why it matters, what is known, what remains uncertain, and the exact decision required. Avoid sending hundreds of raw names to the customer. **Rejection register.** Parked names, wildcard results, unrelated shared infrastructure, transferred assets, providers, and unsupported brand matches—each with a reason and evidence time. This makes attribution reproducible. Another analyst can replay the decision, a client can correct it, and the next engagement can detect what changed instead of rebuilding the same untraceable list. The goal is not to claim the largest perimeter. It is to produce the smallest target set that is current, attributable, authorized, and rich enough to support meaningful testing. The next article in this series follows the hardest relationship in that set: **the vendor may be out of scope while the trust boundary it participates in remains part of the assessment.**