Series · 5 partsExternal Perimeter IntelligencePart 4 · You are here
- 1The External Perimeter Is a Graph. The Port List Is Only One View.
- 2The Domain Resolved. Ownership Was Still a Hypothesis.
- 3The Vendor Was Out of Scope. The Trust Boundary Was Not.
- 4The Service Was Observed. The Application Was Still Unknown.You are here
- 5The Login Page Was Public. The Identity Boundary Was Somewhere Else.
Service observation in 60 seconds
A passive internet platform reports that 203.0.113.42:8443 spoke TLS yesterday. The certificate
contained a familiar domain. The response resembled an application server. That is valuable
intelligence—but it is not yet an application, an asset, a vulnerability, or permission to test.
The observation answers a narrow question:
From one external vantage, at one recorded time, this address and port returned evidence consistent with this protocol and these response properties.
It does not automatically answer:
- who controls the address now;
- which hostname the service expects;
- whether the certificate name was active, default, stale, or shared;
- which virtual host or tenant produced the response;
- whether the endpoint is an edge, proxy, origin, appliance, API, or ordinary website;
- what identity and business workflow exist behind it;
- whether the observed endpoint is included in the current Rules of Engagement.
A modern external pentest therefore uses passive service data to reduce uncertainty before active work. It does not replace uncertainty with tool output. The workflow is:
preserve the observation → attribute the endpoint → recover the expected name and protocol context → confirm scope → perform the smallest current verification → map the application.
Only then does vulnerability testing have a meaningful target.
A service record is a measurement, not a noun
The phrase “an HTTPS service exists” hides the fields that determine whether the statement remains useful. A defensible observation record needs at least:
| Field | Question it preserves |
|---|---|
observed_at | When did the service produce this evidence? |
vantage | From which scanner or network perspective was it observed? |
ip / port | Which transport endpoint answered? |
transport | TCP, UDP, QUIC, or another transport? |
service_name | Which protocol did the scanner identify? |
service_confidence | Was it proved by a handshake or guessed from the port? |
banner_or_response | Which smallest response supports the classification? |
tls_names | Which names appeared in the observed certificate? |
redirect_target | Did the service point toward a hostname or application? |
source_record | Can another analyst retrieve the original observation? |
scope_state | Is current interaction approved, excluded, or undecided? |
Censys documents continuous service discovery, automatic protocol detection, protocol-specific handshakes, and follow-up classification. It also states that its internet scanning is for information gathering and does not attempt authenticated entry. This makes the data an excellent source of externally observed service evidence.
The same documentation explains why the result still needs context. Services are found across
standard and non-standard ports; some remain UNKNOWN; HTTP observations may follow local
redirects; known services are refreshed on a cadence rather than continuously at every instant.
The record is a measurement produced by a scanner’s behavior and time window—not a live socket
held open for the pentester.
Preserve the raw facts before enriching them. If an analyst copies only IP:port into a target
list, the timestamp, protocol evidence, hostname clues, and uncertainty disappear. Later activity
then looks more authoritative than its source warrants.
Keep five layers separate
An observed service becomes useful through successive attribution layers. Skipping a layer creates the most common external-pentest false positives.
Observation. A scanner recorded a response on an address and port. The raw timestamp and response belong here.
Endpoint. Routing, ASN, provider, address history, load balancer, CDN, NAT, and shared-hosting context explain what the address represents. This layer can weaken attribution as easily as it strengthens it.
Name and protocol context. DNS, SNI, HTTP Host, TLS certificate, redirect, application
protocol, and response variation identify the name the service expects. An IP response without the
correct name may show a default virtual host that no real user visits.
Application. Page families, API roots, authentication starts, static assets, headers, error behavior, and visual identity distinguish one application boundary from another.
Business flow. Roles, objects, actions, state transitions, integrations, and data sensitivity explain why the application matters and which security hypotheses deserve testing.
The port belongs only to the first two layers. Vulnerability impact belongs to the last two.
Passive coverage changes the order of work
Broad active scanning often produces a large volume of technically correct but operationally weak results: WAF responses, shared CDN edges, generic cloud addresses, honeypots, stale assets, and duplicate services. Rate limits and defensive controls can also make repeated scans look inconsistent, while high-volume verification consumes the engagement’s noise budget before the important applications are understood.
Passive platforms invert that workflow. Search the attributed graph for recent services, protocols, certificates, banners, and historical changes; then select the small set whose relationship and potential business role justify current verification. The platform has already performed the broad observation. The pentester’s job is to determine which observations are relevant, current, attributable, authorized, and worth touching.
This is not “scan without scanning.” Internet measurement still involved packets; another party sent them under its own published methodology. The distinction is about the engagement’s active interaction with the customer target. Record the passive source and its collection behavior so the client understands what evidence existed before the assessment contacted anything.
Freshness must remain visible. Censys says known services are continually evaluated and stale records are rescanned according to its cadence, but an organisation can redeploy a cloud address, rotate an origin, or remove a listener between observations. A record from yesterday may be ideal triage evidence and still be wrong now.
Use three time states:
observed— what the passive platform measured at its timestamp;current-unverified— no approved present check has confirmed or contradicted it;current-verified— a bounded engagement check confirmed the named behavior and recorded when.
Never overwrite observed with current-verified. Historical drift can explain exposure windows,
migrations, and why two analysts reached different conclusions.
Recover the name before judging the web service
Modern hosting breaks the one-address-one-application assumption. OWASP’s attack-surface identification guidance explicitly calls out domains, virtual hosts, non-standard ports, certificates, and the fact that a single IP can host multiple applications.
For HTTPS, the expected name can influence two separate stages. The TLS server_name extension
defined by RFC 6066 lets a client indicate the server
name during negotiation. After TLS, the HTTP target URI and Host information defined by
RFC 9110 help the server select the intended resource
and virtual host. A check made only against https://IP:port/ can therefore negotiate the wrong
certificate, reach a default site, or miss the application entirely.
Name recovery should combine independent clues:
- current forward DNS from attributed domains to the address;
- observed certificate SANs, validity, and collection time;
- current certificate behavior with the approved name as SNI;
- local redirects from the service to a canonical hostname;
- official application links and documentation;
- content, API, and identity relationships tied to the customer;
- customer confirmation when the technical signals are ambiguous.
Do not try every certificate name against every address. A multi-tenant certificate, shared edge, or provider wildcard can create an enormous out-of-scope test matrix. Generate candidates from attributed customer names, apply written scope, and verify only the exact combinations needed to resolve the application boundary.
Wildcard DNS needs a negative control. If random hostnames resolve and return the same response, the apparent discovery may be a catch-all rather than a real application. Compare response status, certificate, title, body fingerprint, redirect, and server behavior across the attributed name, a random label, and the bare address. The goal is to reject false names, not to enumerate hidden tenants on shared infrastructure.
Service detection is evidence with a confidence level
Port numbers are conventions, not protocol proof. An application can expose HTTPS on 8443, SSH
on a high port, or a custom service on a port associated with something else. Passive data that
shows a completed protocol-specific exchange is stronger than a label derived only from the port.
Nmap’s service and version detection documentation describes how version detection interrogates an open service, matches responses against probes, and can identify protocols on unexpected ports. It also exposes an important safety lesson: probes have effects. Nmap excludes TCP 9100 by default from version detection because some printers may print probe data. “Banner grab” is not automatically harmless.
Classify active verification intensity before execution:
| Level | Verification behavior | Typical use |
|---|---|---|
V0 | No new target interaction | Passive record and source preservation |
V1 | One transport connection or protocol-safe greeting | Confirm listener and basic protocol |
V2 | One named TLS/HTTP request with redirects bounded locally | Confirm hostname, virtual host, and current response |
V3 | Small approved protocol-specific handshake | Confirm service family or security configuration |
V4 | Authenticated or stateful application journey | Map roles, objects, APIs, and workflow with test data |
Each service type needs its own ceiling. An HTTP GET / is not equivalent to sending bytes to a
printer, mail relay, industrial protocol, database, or message broker. Use the platform’s existing
observation when a current probe adds little value or its effect is uncertain. The Rules of
Engagement should identify prohibited protocols, maximum requests, timeouts, source addresses, and
stop conditions.
Turn HTTP response data into an application identity
A 200, 401, 403, or 302 response is not an application classification. Status codes often
describe the edge policy rather than the origin. WAF block pages, generic reverse-proxy errors,
default server pages, and identity redirects can make unrelated applications look identical.
Use a small application fingerprint composed of explainable fields:
- final approved URL and redirect chain;
- status and content type;
- page title and a stable body fingerprint;
- certificate identity and current validity;
- response headers, cookies, and cache behavior;
- application-specific static assets or manifest;
- authentication start and callback destinations;
- linked API origins, WebSocket endpoints, and upload/download hosts;
- organisation-specific legal, product, or account context;
- screenshot with timestamp and viewport.
A screenshot is excellent triage evidence. It can separate a forgotten admin console from a generic server page in seconds. It cannot prove ownership, authorization, technology version, or a vulnerability. Logos and titles can be copied; visual similarity needs DNS, certificate, identity, API, or customer evidence behind it.
After identifying an application, enumerate entry points before vulnerability classes. OWASP’s entry-point guidance recommends recording requests, parameters, methods, authentication state, transport protection, and multi-step behavior. Extend that record with role, object, state transition, trust boundary, evidence reference, and data sensitivity.
The output is no longer “HTTPS on 8443.” It is:
A customer-operated partner administration application, reached through this hostname and edge, using this identity flow, exposing these unauthenticated and authenticated entry points, and controlling these business objects under these roles.
That sentence can support a test plan. A port list cannot.
Use a bounded admission pipeline
Every observation should either advance through explicit gates or stop with a reason.
The pipeline protects against confirmation bias. If current DNS disagrees with the passive certificate, or the approved hostname produces a generic provider page, the analyst should demote the candidate and explain the conflict. Increasing scan intensity until something looks familiar does not resolve attribution.
For each gate, store the decision and reason:
- Source gate: is the original record retrievable, timestamped, and specific enough to use?
- Attribution gate: which current and historical facts tie the endpoint to the customer?
- Shared-infrastructure gate: could the signal belong to an edge, provider, or unrelated tenant?
- Scope gate: which exact name, address, port, protocol, and action are approved?
- Freshness gate: what smallest request can confirm the relevant current behavior?
- Application gate: is there enough entry-point, identity, API, and workflow context to form a security hypothesis?
The rejected records still matter. A stale certificate may expose a retired brand. A moved service may reveal unmanaged decommissioning. A shared edge may identify a supplier relationship. Those are intelligence outcomes, not permission to test the old address or provider.
A fictional service-to-application review
Assume a passive record observed TLS on 203.0.113.42:8443 eighteen hours ago. The certificate
contained partners.meridian.example, and the response redirected to /login.
- The analyst stores the passive record, timestamp, certificate fingerprint, SAN, redirect, and
scanner source. The candidate state is
observed, notlive. - Current RDAP and routing data show that the address belongs to a cloud provider. That supports hosting context, not Meridian ownership.
- Current DNS for
partners.meridian.exampleresolves to the observed address. The hostname is linked from Meridian’s official supplier documentation. Attribution becomesprobable, but shared cloud hosting remains a constraint. - The customer confirms the partner portal and approves one named HTTPS request to that hostname on port 8443 from the assessment address. The cloud provider range, other names, and origin discovery remain excluded.
- A
V2request with the approved SNI and hostname returns the expected certificate, redirects locally, and renders a Meridian partner login. The bare IP returns a generic default site. The difference proves why the name context mattered. - The analyst records the login start, identity-provider redirect, callback, cookies, public JavaScript, API origin, unauthenticated recovery route, and role vocabulary visible to the two supplied test accounts.
- Only now does the test plan contain hypotheses: tenant separation between suppliers, role conversion after SSO, object authorization in the partner API, and workflow enforcement around invoice approval. Each is tied to an approved account, object, endpoint, and expected effect.
The passive platform found the signal. Attribution made it a candidate. A narrow request made it current. Application mapping made it testable.
Evidence matrix
| Signal or result | What it supports | What it cannot prove | Required next step |
|---|---|---|---|
| Passive IP and open-port observation | A listener answered from a stated vantage and time | Current reachability, ownership, protocol, or application | Preserve source and compare current attribution |
| Protocol-specific passive handshake | Response behavior matched a service classification | Product version accuracy, safety, or customer control | Record confidence and decide whether current proof is needed |
| Certificate contains customer hostname | Naming evidence existed at certificate or observation time | Deployment, exclusivity, current DNS, ownership, or scope | Correlate DNS, official links, routing, and customer input |
| Current DNS points hostname to observed address | A present name-to-address relationship | Which virtual host, tenant, origin, or business app responds | Obtain scope for the exact hostname and protocol context |
| Bare IP shows a login or admin page | The default virtual host exposes that content | That real users reach it or that it belongs to the customer | Recover approved hostname; reject shared/default responses |
| Named TLS/HTTP request matches expected app | Current behavior for one approved name and timestamp | All paths, origins, roles, or vulnerability classes | Build entry-point and trust-boundary model |
| Screenshot matches customer branding | Useful visual correlation and triage evidence | Ownership, technology version, authorization, or security | Seek technical and customer corroboration |
| Service banner names a product and version | A product hypothesis from disclosed response data | Patch level, vulnerable configuration, or exploitability | Verify safely, then test the actual control rather than CVE matching |
| Application entry-point map is complete enough | Requests, roles, objects, and flows can support hypotheses | That any hypothesis is exploitable | Run bounded positive and negative tests |
What the customer should receive
The final deliverable should preserve the transformation from observation to application.
Observation ledger. Raw service facts, source, timestamp, scanner behavior, response evidence, and initial uncertainty.
Attribution decisions. DNS, certificate, routing, hosting, official-link, and customer evidence with contradictions and confidence state.
Verification plan and result. Approved hostname, address, port, protocol context, request budget, source address, expected response, observed response, timestamp, and stop condition.
Application map. Entry points, identity path, roles, objects, APIs, state transitions, third-party dependencies, data classes, and evidence references.
Rejection register. Stale services, shared edges, default virtual hosts, unrelated tenants, provider infrastructure, wildcard results, and unsupported version matches.
Change signal. What differs from the previous passive or engagement observation: new service, moved address, certificate change, renamed application, new identity boundary, or retired route.
This structure gives defenders something a port list never can: the reason a service matters, the application owner who can act, the exact control that should be tested, and the evidence needed to retest it.
Passive discovery is valuable precisely because it lets the engagement be quieter and more selective. Its purpose is not to declare vulnerabilities at a distance. It is to spend active verification only where a current, attributable, authorized application boundary has emerged.
The next article follows the most common high-value boundary found in that model: the login page was public, but the identity boundary was somewhere else.
How current is this note?
The latest source-review, content-update, or publication date is shown.
Primary public records were checked. Environment-specific behavior remains outside the claim unless separately reproduced.