DedSec Security Research ·
Consider two errors in one asset inventory. The first is an address, 198.51.100.23, listed against example.com because last quarter api-old.example.com resolved to it. The record has since been deleted and the cloud address released, and the provider has allocated it to another tenant. A scheduled scan still targets the address, so it is now probing someone else's server on your behalf. The second error is a missing entry. A marketing agency registered offers-example.example in its own name for a campaign, and it runs a login form that posts to your identity provider. Nothing in example.com's DNS points at it, so no discovery run that started from example.com has ever listed it.
Both are attribution errors, in opposite directions. This post covers how an asset is attributed to an organisation from public data, what each signal proves and what it does not, how to combine signals without counting one fact twice, and why an attribution made last month is not evidence about today. The checks themselves need only dig, curl, openssl and the public registries. The examples use the reserved names example.com, example.net and the .example top-level domain (RFC 2606), and the documentation address ranges from RFC 5737.
Enumeration produces three different kinds of object, and ownership means something different for each.
These separate as soon as anything is outsourced. If shop.example.com is a CNAME to a hosted storefront, the name is yours and the address and service are the vendor's. An inventory line that says "shop.example.com, ours" has merged three claims, and only one of them is true.
So an attribution should be written as a claim about one object: this organisation controls this name, address or service, according to this evidence, observed at this time. Each part matters later. The object decides what you may do to it, the evidence lets someone re-check the claim, and the timestamp tells you when to stop trusting it.
Each signal below is rated by what it can establish on its own, with the way it fails. None of the ratings is a weight from any particular tool; they describe what the evidence is capable of proving.
Strong for the name. Silent about the target. A record can only exist under example.com if someone with write access to the example.com zone created it, or to a zone example.com delegated. That makes "this name is ours" a sound conclusion for anything that resolves under your registered domain.
Where it fails:
Moderate when present, and redaction can remove it entirely. RDAP is the structured successor to WHOIS: queries are HTTP paths defined in RFC 9082 (domain/example.com, ip/203.0.113.10, autnum/64500) and responses are JSON defined in RFC 9083. A response lists entities by role (registrant, registrar, technical, abuse), events such as registration and expiration, the nameservers, and status values. The server for a given TLD or address block is found from the IANA bootstrap files described in RFC 9224 (data.iana.org/rdap/dns.json, and the ipv4, ipv6 and asn equivalents).
Where it fails:
What survives redaction and is worth reading: the nameservers (strong if they are your own self-hosted nameservers, weak if they belong to a managed DNS provider shared by its customers) and the expiration event, which you want for the decay section below.
Strong for addresses in your own allocation. Says nothing about a tenant inside someone else's. The regional internet registries publish who holds each address block and autonomous system number, queryable over RDAP. If an address sits in a block allocated to your organisation and announced from your AS (or, for bring-your-own-IP space, announced by a provider on your behalf; the documentation ASNs 64496 to 64511 and 65536 to 65551 are reserved by RFC 5398 for examples like the one above), that is solid evidence for the address.
Where it fails:
Moderate to strong, depending on what was checked. A completed TLS handshake proves the server holds the private key for the certificate it presented. If that certificate chains to a trusted root and is valid for your name, the host is run by someone who could obtain a certificate for that name: you, a provider you delegated the name or a key to (including a CDN or load balancer terminating TLS for you), or anyone who controlled the name long enough to pass validation, which includes whoever took over a dangling record. To read what a host presents, openssl s_client -connect 203.0.113.10:443 -servername shop.example.com piped into openssl x509 -noout -subject -issuer -ext subjectAltName shows the subject, issuer and SAN list.
Where it fails:
The post on TLS posture drift covers CT as a discovery source and its limits as an inventory. For attribution, two points. A logged certificate for a name under your domain shows that someone passed domain validation for that name, by DNS, web endpoint or email to an administrative address, at some point within the validation-reuse period before issuance. It says nothing about the host the name points at today. And searching CT by a validated organisation field (your legal name in the subject of OV or EV certificates) can surface domains that share no DNS with your main one. These are candidate seeds, validated by a CA at issuance, and worth a human look.
Weak alone. Useful for producing candidates. A favicon hash, an analytics or tag-manager property ID, an HTML title, a copyright string, a support address in the footer, a distinctive script filename. Internet-scanning search engines index some of these, so one artefact from your known site can return every host serving the same value.
Where it fails: every one of these is copied with the page. A phishing kit that clones your login page brings your favicon, title, footer and analytics ID with it. An agency that builds sites for several clients from one template brings its own artefacts to all of them. Four matching artefacts on a cloned page are one event, not four signals. One defender-side tell does come out of this: if a clone kept your analytics ID, its visits can arrive in your own analytics property under the clone's hostname.
Weak. A PTR record for 203.0.113.10 lives in the in-addr.arpa zone of whoever holds the address block, which for a cloud or ISP address is the provider, writing whatever the tenant asks for through whatever check the provider applies. A PTR saying host.example.com is a statement by the address holder, not by you. Forward-confirmed reverse DNS, where the PTR name resolves back to the same address, adds that your zone points that name at the address, which is the DNS signal again rather than a new one. A PTR record can also outlive a reassignment if the address holder does not clear it, so treat one as history until a current forward record agrees with it.
Points at providers, not assets. An MX record names the mail service that receives your mail. An SPF record (RFC 7208) authorises senders, and an include: mechanism pulls in a provider's own SPF record and, through it, address ranges shared with other customers of that provider. Expanding SPF includes into address ranges and adding them to an inventory adds the provider's whole sending estate. An ip4: entry you wrote yourself is a self-assertion that the address sends mail for you, worth a look and possibly stale. A DMARC rua address points at whoever processes your aggregate reports. The post on email authentication covers what these records mean for mail; for attribution, they are a list of vendors.
Requiring more than one signal only helps if the signals are independent, and two signals are independent only if no single party or action could have produced both.
Group each signal by where it originates:
Then count origins, not signals. A CNAME into a SaaS platform plus the platform's certificate covering your name is zone-derived twice: both exist because you configured the vendor, and neither says whether the vendor still serves your account. A favicon, title and analytics match is content-derived three times, and a cloned page produces all of them in one copy. By contrast, a name in your zone resolving to an address, that address in a block allocated to your organisation, and an OV certificate with your legal name presented with a valid chain come from three origins that would have to fail separately.
Record the evidence with the attribution, per object: the seed it was reached from, each signal with its raw value, its source and its timestamp, and the resulting tier. A workable set of tiers:
An attribution with its evidence attached can be re-checked by someone who did not make it, and withdrawn when the evidence lapses. An attribution recorded only as a yes/no flag can do neither.
The cost of a false positive in attribution grows with what is done to the asset. In a dashboard it is noise. In a ticket queue it sends an engineer to fix a server nobody in the organisation can log in to. In an active test it means testing someone else's system.
Passive observation (resolving a name, completing a handshake, fetching a public page) is what any visitor does. Active checks are different: exploit validation, injection payloads, credential attempts, aggressive port scanning. Running them against a host requires authorisation from whoever operates it, and a cloud provider's published testing policy, where it has one, covers resources in your own account, not other tenants'. The address that was yours last quarter, the neighbour on a shared CDN edge, the range expanded from an SPF include, the look-alike domain carrying your name in its registrant field: each is a host where an active check is directed at a third party.
The control is to keep inventory and scope as two different lists. Inventory is what you believe is exposed in your name. Scope is what you have decided you are authorised to test actively, set by people, and narrower. Attribution may propose additions to scope; it should not make them. A scope boundary checked at the moment a test is sent, against the current resolution of the target, catches the case where a name still in scope now resolves to an address that is not.
A single domain is a seed, not an organisation. Discovery that expands from one seed cannot reach a host with no DNS, registration or certificate link to it, and these are the hosts with no such link:
Ways to find them, roughly in order of reliability. Ask finance for every registrar, DNS and hosting invoice, because payment records list what the organisation pays to own. Ask legal for the list of entities and acquisitions. Query for domains delegated to your own self-hosted nameservers. Search CT for your validated legal names. Then use shared artefacts to generate candidates. Treat each result as a proposed seed with its provenance: a human confirms the seed, and discovery expands from it.
Every signal has a lifetime, and the attribution is only as current as its shortest-lived signal.
The practical rule is to re-attribute every object from current evidence on every run, rather than carrying "ours" forward. Keep the history so a change can be explained. An object that loses its attribution between runs is itself a finding: either it was retired properly and should leave scope, or something was released while still referenced. A static list of addresses in a scanner configuration is attribution that is never re-checked, which is how the opening example happened.
A status page, help centre or landing page served by a SaaS vendor on a CNAME under your domain sits in the second tier: your name, their host. What you may do and what you answer for are different lists.
What you can test yourself: the DNS record (where it points, whether the target still exists and still belongs to your account), the certificate as presented, the headers and content any visitor receives, and your own account configuration on the vendor's platform. Anything active against the vendor's infrastructure needs the vendor's authorisation, through its published security-testing or disclosure policy where it has one.
What you are still accountable for:
Maphra starts from a domain name and works outward: it enumerates subdomains, resolves infrastructure, fingerprints live services and attributes each discovered asset to the organisation it believes owns it. It monitors certificate transparency, re-runs discovery on a schedule and diffs the result against the last known surface, reporting what appeared, what changed and what disappeared. Active validation runs only inside an explicit scope boundary you define, and a scope gate prevents active checks from reaching third-party hosts that merely appear in your surface. Every finding carries the evidence that produced it, and findings are deduplicated across scans and tracked through new, reopened and fixed states.
That is the whole claim. This post does not claim which signals Maphra uses to attribute an asset or how it weighs them, nor that it queries RDAP or WHOIS, reads RIR or ASN allocations, hashes favicons, matches analytics IDs, consults the Public Suffix List, keeps passive DNS or address history, expands acquisitions or subsidiaries into seeds, or assigns attribution tiers like the ones above, or that its scope gate re-checks a target's current resolution at the moment each check is sent. The signals, their failure modes and the corroboration method are general practice, written so that you can apply them with a terminal and public data.
It is the address your name points at today. If the address is in a cloud or CDN provider's allocation, the provider holds it and may serve other customers from it, and once you stop using it, it can be reassigned. Treat it as yours for testing only if you can show you hold it now, for example from the cloud account that has it assigned.
You can test what any visitor sees and everything in your own DNS and account configuration. Active testing of the host itself is testing the vendor's infrastructure and needs the vendor's authorisation. What the name exposes, including cookies scoped to the parent domain, is still yours to fix.
Two possibilities, and the evidence decides which. Either it is a real asset nobody recorded (an agency site, an acquired company's server, a forgotten staging host), or it was attributed through a signal that does not prove ownership: a shared address, a multi-tenant certificate, a copied favicon, an SPF include. Ask for the evidence behind the attribution and check which origin it came from.
Start with records that describe ownership rather than DNS: registrar and hosting invoices, the legal entity list, acquisition records. Then search certificate transparency for each entity's validated legal name, and look for domains delegated to your own nameservers. Shared page artefacts can suggest more, but each needs confirming by a person before it becomes a seed.
Enumeration tells you what answers. Attribution is a separate claim about who it answers for, it needs evidence that can be re-checked, and it expires.