--- title: "The External Perimeter Is a Graph. The Port List Is Only One View." description: "Modern external pentesting starts by proving how domains, companies, certificates, identity systems, cloud services, and third parties relate. Active scanning then verifies the small part of that graph that is both relevant and authorized." date: 2026-08-29 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/external-perimeter-intelligence-graph/ --- ## External perimeter intelligence in 60 seconds An external penetration test used to begin with an IP range and a port scanner. That still finds listening services, but it no longer describes the perimeter. The same organisation may operate regional domains, acquired brands, cloud endpoints, identity tenants, mobile backends, support portals, API gateways, forgotten migration hosts, and third-party SaaS integrations. Several may share an IP. One hostname may move between providers in a day. The useful unit is not the port. It is the **relationship**. The modern workflow is therefore not _scan everything and investigate whatever responds_. It is: > understand the organisation, build attributed candidates, model their trust relationships, > and actively verify only what is relevant, in scope, and worth testing. Port scanning is not dead. Its job changed. It moved from broad discovery to targeted verification. ## Intelligence comes before infrastructure The first question in an external test is not "what is open?" It is "what organisation am I actually looking at?" A company name is rarely one technical boundary. There may be a parent entity, regional legal entities, subsidiaries, product brands, acquired companies, joint ventures, and domains retained after a rebrand. Public annual reports, investor material, regulatory filings, acquisition notices, press releases, privacy notices, and the organisation's own legal pages describe this structure before a single packet is sent to its infrastructure. This is not financial speculation. A falling share price does not prove weak patching, and a layoff does not prove a vulnerable server. Corporate events are useful because they produce **testable asset hypotheses**. An acquisition creates a migration boundary. A divestiture creates an ownership change. A rebrand creates old domains. A new cloud partnership creates a new trust relationship. The event is a seed; technical evidence decides whether the seed belongs in the surface map. | Intelligence question | Candidate it can produce | What still needs proof | | ----------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------- | | Which companies and brands are controlled by the parent? | Additional root domains and product portals | Current ownership, technical coupling, written scope | | Which businesses were acquired or retired? | Legacy identity, DNS, mail, and application boundaries | Whether the old environment still connects to the parent | | Which regions and regulated services exist? | Country domains, customer portals, separate data flows | Whether they are operated by the same legal and technical entity | | Which providers process identity, payment, support, or telemetry? | SaaS and webhook trust boundaries | The exact integration and whether the provider itself is testable | | Which public repositories, documentation, and mobile apps exist? | API hosts, package names, callback domains, environment labels | Whether each observation is current and in scope | The discipline is to collect organisation-level signals, not build dossiers on individuals. Role names, public team responsibilities, and an official email convention may help explain an identity boundary. Personal phone numbers, private accounts, credential dumps, and employee targeting do not belong in a normal infrastructure assessment unless a separately authorized social-engineering exercise explicitly requires them. ## The perimeter has seven connected layers
organisationENTITY · M&A · BRAND namesDOMAIN · DNS · CT networkASN · PREFIX · EDGE observed servicesPORT · PROTOCOL · TLS applicationsWEB · API · MOBILE trust systemsIDENTITY · SAAS · DATA attributed candidatesSOURCE · TIME · CONFIDENCE targeted validationAUTHORIZED · NARROW application modelENTRY · ROLE · STATE test planHYPOTHESIS THE UNIT OF WORKis an attributed relationship, not an isolated open port
Organisation intelligence produces candidate relationships. Technical sources enrich them. Only ownership, scope, and current-state validation can promote them into the test plan.
The seven layers answer different questions: 1. **Corporate identity:** parent, subsidiary, acquisition, product, region, and brand. 2. **Naming:** root domains, DNS records, certificate names, and historical names. 3. **Routing:** registered networks, announced prefixes, hosting providers, and CDN edges. 4. **Services:** observed ports, actual protocols, banners, TLS properties, and observation time. 5. **Applications:** web properties, APIs, mobile backends, admin surfaces, and workflows. 6. **Trust systems:** SSO, email, payment, support, analytics, webhooks, and data processors. 7. **History:** what appeared, disappeared, moved, or stopped resolving between observations. No one source proves all seven. A certificate name is not ownership. An IP registration is not current routing. A CNAME is not permission to test the provider behind it. A banner is not a confirmed product version. The graph becomes useful precisely because every edge records what supports it and what remains uncertain. ## Build an ownership graph, not a domain dump Start with verified root domains. For each candidate root, record the corporate reason it exists: official brand, regional site, subsidiary, acquired product, redirect, or unknown. Then test the relationship using independent signals. [ICANN's RDAP service](https://www.icann.org/rdap/) provides structured current registration data for domains and internet number resources. It is a better machine-readable starting point than legacy WHOIS, but privacy redaction and registrar variation mean a missing company name proves nothing. Registration is one edge in the graph, not the verdict. [Certificate Transparency logs](https://certificate.transparency.dev/logs/) are public, append-only ledgers of issued certificates. They are excellent for recovering names that never appeared in a public sitemap, including regional hosts, product environments, and old migration boundaries. They prove that a certificate containing a name was logged. They do not prove that the host still resolves, that the certificate was deployed, or that the parent organisation owns it. For network relationships, [RIPEstat](https://stat.ripe.net/docs/getting-started/what-is-ripestat) combines registration and routing information for IP space and ASNs. That helps separate a company-announced prefix from a cloud or CDN address. Again, the distinction matters: an address served by a CDN is evidence of delivery infrastructure, not evidence that the entire CDN range is part of the engagement. A useful ownership record looks like this: | Field | Example meaning | | ---------------------- | ------------------------------------------------------------------------------------------ | | `candidate` | The domain, hostname, prefix, tenant, application, or integration observed | | `relationship` | Parent brand, acquisition, DNS target, shared certificate, identity provider, or unknown | | `source` | Official filing, RDAP, DNS, CT, routing data, service observation, or application evidence | | `observed_at` | When the source actually observed the fact—not when the analyst copied it | | `ownership_confidence` | Confirmed, probable, possible, contradicted | | `scope_state` | In scope, out of scope, needs written decision | | `current_validation` | What was independently checked in the engagement window | | `next_question` | The smallest fact needed to keep or reject the candidate | This model prevents the most expensive recon mistake: promoting a plausible association into a trusted target merely because two tools returned the same string. ## Map the organisation's trust suppliers Modern companies outsource parts of their perimeter without outsourcing the consequences. DNS and application evidence can reveal identity providers, customer-support platforms, payment services, email delivery, analytics, object storage, CDNs, monitoring, and webhook consumers. The useful question is not "which vendors are present?" It is "what authority crosses this boundary?" | Third-party role | Relationship to map | Pentest question | | -------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------- | | Identity provider | Redirects, issuer, tenant, claims, session handoff | Where is authentication converted into application authority? | | Payment or event processor | Webhook destination, signature, replay state | Which service trusts the event, and how is origin verified? | | Support platform | Custom domain, SSO, account data | Does support identity cross into the core account model? | | Storage or CDN | CNAME, origin, upload and delivery path | Which party controls naming, content, and cache behavior? | | Monitoring and analytics | Client SDK, project identifier, submitted data | What data leaves the application, and can configuration alter behavior? | Third-party does **not** mean automatically in scope. It means the relationship belongs in the architecture. The organisation's configuration, callback, custom domain, or trust decision may be testable while the provider's infrastructure remains explicitly out of scope. That distinction must survive all the way into the test plan. ## Censys changes where active scanning begins Censys is often called a passive scanner from the pentester's point of view. That shorthand hides an important fact: Censys actively scans the public internet; the analyst passively queries the resulting map. Its documentation describes continuous IPv4 discovery, scanning across all 65,535 ports, automatic protocol detection, multiple perspectives, and scheduled refresh of known services. A result can therefore provide far more than `IP:port`: observed protocol, TLS material, HTTP behavior, software hints, DNS names, routing context, and an observation timestamp. That makes it an excellent candidate generator: - find SSH or HTTP on a non-standard port without sweeping every address yourself; - connect a certificate name to a service observation; - distinguish the protocol that answered from the protocol normally assigned to that port; - compare present and historical exposure; - prioritize remote access, identity, management, database, and file-sharing surfaces; - identify the exact small set that deserves current-state validation. It is not ground truth. Censys notes that hosts with no recently exposed service, hosts on its blocklists, and systems that block its scanners may be absent from search. Cloud services change, anycast and geographic policy alter perspective, and a banner can outlive the deployment it once described. Every record needs `observed_at`, and every critical conclusion needs a fresh check. ## Why a broad port list is weak evidence Security controls do not simply create false positives. More often they create **ambiguous, perspective-dependent observations**. The Nmap project defines `open`, `closed`, `filtered`, `unfiltered`, `open|filtered`, and `closed|filtered` as what Nmap can infer from the packets returned to one scanner. The same port can look open from one network and filtered from another. Silent firewall drops, loss, ICMP or RST rate limits, forged responses, proxies, and geographic policy all change the picture. This is why a report containing 60,000 filtered ports says almost nothing. It records that a particular probe did not produce a decisive answer. Conversely, one protocol-aware observation on a non-standard port, tied to the right hostname and certificate, may materially change the test plan. The efficient sequence is: 1. Use corporate, naming, routing, certificate, and historical intelligence to generate candidates. 2. Remove shared hosting, CDN edges, parked names, wildcard DNS, and contradicted ownership. 3. Obtain a written scope decision for acquisitions, subsidiaries, and third parties. 4. Validate the smallest candidate set from the approved test perspective. 5. Map the applications behind confirmed services before vulnerability testing. ## From service to application model Discovery tells us _where_. Application mapping tells us _how authority moves_. Two hostnames on the same IP may be unrelated applications. Two applications on different clouds may share the same identity tenant. A marketing site may call a production API from JavaScript. A mobile app may use a backend name absent from the public website. An admin interface may be fronted by the same edge as the customer portal while enforcing a completely different role model. The [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/04-Attack_Surface_Identification) frames attack-surface identification as discovering applications, domains, virtual hosts, exposed services, DNS, non-standard ports, and certificate data. That inventory is the input, not the end. For every confirmed application, classify the boundary: - `APP-0` — core business application; - `APP-1` — authentication and identity; - `APP-2` — administration and management; - `APP-3` — API, BFF, webhook, or backend service; - `APP-X` — third-party-operated application or integration. Then record entry points, authentication mechanism, roles, tokens and sessions, API families, data flows, and meaningful workflow states. Vulnerability discovery without this model is mostly random payload delivery. The model tells us which trust decision is worth testing. ## A fictional engagement: one company, four boundaries Assume the authorized seed is `northstar.example`. No scan has started. 1. An official acquisition notice says Northstar bought "Harbor Metrics" two years ago. This produces a corporate candidate, not a target. 2. A CT record contains `auth.harbor.example`. Current DNS resolves it to a SaaS identity platform. This proves a name and a current DNS relationship, not ownership of the SaaS provider. 3. Censys last observed HTTPS on `8443` for an address historically linked to Harbor. The certificate also contains a Northstar product hostname. This raises confidence and creates a narrow service candidate. 4. Written scope confirms the Harbor application but excludes provider infrastructure. A current TLS and HTTP check, using the hostname and SNI, confirms a login application on `8443`. 5. Application mapping shows the Harbor login issues a token accepted by a Northstar API. The finding hypothesis is no longer "port 8443 is open." It is "an acquired identity boundary may grant authority in the parent application." The port mattered. It mattered only after corporate history, CT, DNS, service intelligence, ownership, scope, and application trust turned it into a defensible test case. ## Change is part of the perimeter A passive source returning a hostname for the first time is not automatically a new asset. It is a new observation. A useful change pipeline first validates DNS, rejects wildcard-only answers, records current HTTP/TLS/service evidence, and then compares two persisted states. Keep at least: - first and last observation time; - previous and current DNS state; - certificate and service observation time; - source and collection identifier; - ownership and scope decision; - the reason an analyst accepted or rejected the change. Disappearance also matters. A hostname that stops resolving may indicate an intentional retirement, a migration, a dangling dependency, or nothing more than temporary DNS failure. Missing evidence never proves remediation and should never close a finding automatically. ## Evidence matrix | Signal | What it proves | What it does not prove | Independent validation | | ----------------------------------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Official filing or acquisition notice links two companies | A corporate relationship existed at the stated time | Current technical integration or testing authority | Confirm present legal ownership and obtain an explicit scope decision | | RDAP record links a domain or network resource | Current structured registration data returned by an authoritative service | Operational control of every host or application using it | Compare DNS, routing, official properties, and customer confirmation | | CT log contains a hostname | A certificate containing the name was publicly logged | Current DNS, deployment, ownership, or reachability | Resolve DNS and compare the live certificate and application identity | | RIPEstat associates a prefix and ASN | Registration or routing data supports a network relationship | That every address in the prefix belongs to the engagement | Separate owned prefixes from providers, peers, and CDN delivery ranges | | Censys observed a protocol on an IP and port | The service answered Censys from a recorded perspective and time | That it is still live, correctly attributed, vulnerable, or in scope | Perform a narrow current handshake from the approved test plane | | CNAME or client code identifies a SaaS provider | An application or naming dependency exists | Permission to test the provider | Test only the authorized configuration and trust boundary | | Active validation confirms service and application identity | The candidate exists from the engagement perspective now | A security vulnerability | Build an application hypothesis and positive/negative controls | ## What to hand the defenders Do not hand over a CSV of hosts and call it an attack-surface map. Provide four connected outputs. **The organisation map.** Parent, brands, regions, subsidiaries, acquisitions, and unresolved ownership questions. This tells the customer why each root entered the investigation. **The attributed surface inventory.** Domain, DNS, IP/prefix, service, certificate, application, hosting class, first/last seen, source, confidence, and scope state. Keep domain-based and address-based observations separate until evidence safely correlates them. **The trust map.** Identity, API, webhook, data, payment, support, and delivery relationships. Third-party nodes stay visible even when they are out of scope, because the organisation still depends on the boundary. **The verification queue.** A ranked set of questions, not an automated finding list. Each item states the smallest authorized check that would confirm or reject the hypothesis, plus the evidence required to stop. The useful outcome of external recon is not "we scanned 65,535 ports." It is "we can explain which external relationships matter, why we believe they belong to this organisation, what changed, what we verified, and where the next trust decision can fail." That is a perimeter a pentester can test—and a defender can actually maintain.