Subdomain Takeover Checks Start With the Asset Graph

The scanner was not missing a clever fingerprint. It was asking the wrong asset tree for candidates.

August’s RedBlue work was a reminder that many security failures begin before a detector runs. A subdomain takeover check can be perfectly implemented and still return little if it never receives the subdomains already discovered elsewhere in the platform.

Question

How should a takeover check assemble its candidate set without losing earlier discoveries or widening beyond the authorised asset boundary?

Method

I followed three adjacent commits: loading retained subdomains from the database, correcting the registrable apex used to find project assets, and enabling DNS brute force in the autonomous static seed. I treated them as one data-flow problem rather than three scanner features. The dated changes are recorded in a sanitised evidence record.

The review stops at candidate construction and scope. It does not describe exploitation or claim that every dangling record is takeoverable.

Evidence

The first fix connected the takeover check to subdomains already stored for the project. That replaced an accidental local view with the platform’s retained asset graph.

The second corrected how the scanner derived the registrable apex. Hostnames can contain several labels, and grouping on the wrong boundary can hide related assets or mix unrelated ones. Loading by the proper apex repaired that relationship.

The final change seeded DNS brute force in autonomous runs. That increased potential coverage, but its value depended on the earlier graph and scope work. More names are not useful if ownership, origin, and authorisation are unclear.

Finding

Takeover detection is downstream of asset identity. The platform needs to know where a name came from, which root it belongs to, when it was observed, and whether it is approved for the current operation before a specialised check begins.

This is why I prefer an asset graph over a flat list. Relationships preserve context. They also make it possible to hold newly discovered assets as pending evidence instead of automatically turning discovery into active testing.

Limitations

These commits improve candidate coverage and grouping. They do not establish ownership by themselves, and they do not prove that a provider-specific takeover condition exists. The private code changes are not independently reviewable from this public record.

DNS brute force can also create noise and operational load. Exact scope, rate limits, and explicit authorisation remain required. Public discovery is an input to review, not permission to interact with every discovered host.