You cannot test what you have not found
Every assessment begins by mapping what is actually there (subdomains, ports, services, endpoints, JavaScript bundles, API schemas) and fingerprinting the technology behind each one.
This phase decides the quality of everything after it. A test is only as good as its map.
Discovery from live behaviour · Scope verified before any test runs · Feeds directly into testing
Overview
Discovery is the least discussed phase of security testing and the one that determines whether the rest of it is worth doing.
The reason is arithmetic. Testing is applied to what has been found. If reconnaissance surfaces sixty percent of the actual attack surface, then the most sophisticated testing engine available is producing a thorough assessment of sixty percent, and the report will not mention the other forty, because from the tool's point of view it does not exist.
That gap is not usually a failure of process. It is a consequence of how infrastructure gets created. Cloud made exposure a self-service action. A team spins up an environment for a launch. A subdomain is registered for a campaign. A service is exposed for an integration and never withdrawn. A DNS record outlives the infrastructure it points at. None of it passed through a change process, and none of it appears in a CMDB.
AIPTx discovers from live behaviour rather than from declaration. It asks what responds, not what is recorded, and what responds is the only definition of an attack surface that matters.
How It Works
Discovery is Phase 1 of every assessment. It is also available as an ongoing capability across a domain portfolio.
- Step 01
What gets enumerated
Subdomains. Enumerated across the domains you own, the layer where forgotten campaign sites, staging environments and inherited brand estates accumulate.
Ports and services. Across discovered ranges, establishing what is listening rather than what is documented as listening.
Endpoints. Discovered within applications, including those the interface never calls.
JavaScript bundles. Analysed for the endpoints a front end calls at runtime, which is how single-page applications get mapped, since a crawler following links finds almost none of it.
API schemas. Parsed where present, so declared endpoints, methods and parameters enter the map even when nothing exercises them.
Authentication flows. Mapped as part of reconnaissance, so the agent knows how to reach the authenticated surface rather than stopping at the login form.
- Step 02
What gets fingerprinted
Frameworks, libraries, server software and versions, identified from live behaviour: response signatures, header artefacts, bundled client code and dependency information.
This is what makes CVE matching meaningful. A version guess produces a CVE guess, and guessing is the origin of most of the noise in vulnerability management. Fingerprinting from behaviour is how the identification stays accurate enough for the matching to be worth anything.
Behaviour is also harder to disguise than a banner. A server header can be blanked, rewritten by a proxy, or left at a default that has nothing to do with what is actually running, so anything that trusts the banner inherits whatever the banner happens to say.
The fingerprint is what the rest of the assessment is written against. The CVE match, the version-specific check and the remediation advice all depend on knowing which build is really there.
See Threat Intelligence - Step 03
What happens to what is found
Discovery does not end in a list. Discovered network ranges receive port scanning, service detection, version detection, CVE matching, SSL/TLS analysis and default credential testing. Discovered web and API surfaces receive application-layer testing across the seven vulnerability classes.
The output is an inventory with the exploitable entries marked and evidenced, which is a materially different object from an asset list, and the difference is the point.
See AI Agent
Internal discovery
The AIPTx agent deploys via Docker with outbound connectivity only, and discovers across internal IP ranges and CIDR blocks. On flat internal networks this is frequently the first accurate inventory a team has had.
Capabilities
Subdomain enumeration
Across every domain you own, surfacing the hosts that answer rather than the ones the inventory lists.
Port and service detection
Across the IP ranges and CIDR blocks you authorise, identifying what is listening and what is answering on each.
Version detection
Software and version identified on each discovered service, which is what CVE matching runs against.
Endpoint discovery
Within applications, including the endpoints the interface never calls and nobody remembers deploying.
JavaScript bundle analysis
The endpoints a single-page application calls at runtime, which a link-following crawler structurally cannot reach.
API schema analysis
Declared endpoints, methods and parameters.
Authentication flow mapping
Login, session and token handling mapped during reconnaissance, so authenticated surface is testable rather than invisible.
Technology fingerprinting
Frameworks, libraries, server software and versions, from live behaviour.
Asset discovery outputs
Endpoints, technology stacks, authentication methods, API versions and subdomains.
Internal discovery
Via the AIPTx agent deployed as a Docker container with outbound connectivity only, across the ranges you authorise.
Assessment of what is found
Network-layer testing including TLS analysis and default credentials; application-layer testing across seven classes.
Alerting on what appears
Slack and Microsoft Teams notifications when the surface changes, with webhooks for custom routing.
Persistent tracking
Findings carry first_seen, and reports carry trend comparison, so surface growth and reduction are both visible.
Scope enforcement
Discovery is bounded by the domains and ranges you declare and control.
Benefits
- 01
The map is accurate before the testing starts.
Which is the difference between a thorough assessment and a thorough assessment of the part you already knew about.
- 02
Shadow infrastructure becomes visible.
Staging environments, campaign sites and forgotten services surface as assets to deal with rather than as post-incident findings.
- 03
Single-page applications get properly mapped.
JavaScript bundle analysis reaches the endpoints a crawler structurally cannot.
- 04
Undocumented API endpoints enter scope.
Schema analysis covers what was declared; endpoint discovery covers what exists. Between them, the endpoints nobody reviewed get tested.
- 05
CVE matching becomes trustworthy.
Because fingerprinting comes from behaviour rather than from a stale inventory, the matches are worth acting on.
- 06
Acquisitions get mapped in days.
Point discovery at the domains and establish what was actually acquired before integration decisions harden.
- 07
Surface change becomes measurable.
With persistent tracking and trend comparison, whether your estate is growing or contracting is a number rather than an impression.
- 08
Discovery keeps pace with the environment.
Cloud resources, applications and services change constantly; continuous reconnaissance ensures the assessment reflects what exists today rather than what existed when the asset register was last updated.
What the first run tends to find.
Illustrative example. Not a customer account.
An organisation runs discovery against its primary domain and four secondary domains inherited through acquisitions. The security team's asset register lists 47 internet-facing systems.
Discovery enumerates 210 responding hosts.
The difference is not a failure of record-keeping. It is thirteen years of ordinary activity:
- 01
A campaign subdomain from a product launch. Still resolving, still serving a marketing site on a framework three major versions behind, with a contact form that posts somewhere.
- 02
A staging environment. Basic-auth protected, indexed, and running a near-current copy of the production application with a database snapshot behind it.
- 03
An API gateway. Spun up for a partner integration that ended two years ago. Still accepting requests. Still holding valid credentials for a downstream service.
- 04
Eleven hosts from an acquisition. Belonging to a brand that was retired but whose infrastructure was never decommissioned, because the team that owned it left with the transition.
- 05
A DNS record pointing at a deprovisioned cloud resource. Resolving to an address the organisation no longer controls.
What discovery does next. Each responding host is fingerprinted and assessed. The framework on the campaign site matches known CVEs. The staging environment answers to a default credential pair. The partner gateway exposes an endpoint with no authentication at all, and the agent validates it, capturing the request and response.
What the team receives. Not 210 new problems. An inventory of 210 assets, of which 163 are unremarkable, 38 warrant attention, and 9 are validated and exploitable with the evidence attached, ranked by exploitability, impact, asset value and exposure.
Why this is the right framing.
A discovery tool that hands you 163 unremarkable assets alongside the 9 that matter has moved your problem rather than solved it. The value is the ranking, and the ranking is only possible because discovery ends in testing.
FAQ
Frequently Asked Questions
How do you find assets we do not know about?
By enumerating from the domains you own and observing what responds — subdomains, ports, services, endpoints — then fingerprinting the technology behind each, so discovery follows what is reachable rather than what is documented.
Do you test what you discover, or just list it?
Both: discovered network ranges receive service and version detection, CVE matching, TLS analysis and default credential testing, and discovered web and API surfaces receive application-layer testing across all seven vulnerability classes.
Can you map single-page applications?
Yes, through JavaScript bundle analysis, which surfaces the endpoints the front end calls at runtime and a link-following crawler structurally cannot reach.
Will you touch assets we do not own?
No, scope is verified before anything runs and discovery is bounded by the domains and ranges you declare and control.
Does it cover internal networks?
Yes, via the AIPTx agent deployed as a Docker container with outbound connectivity only, across the internal IP ranges and CIDR blocks you authorise.
How often does discovery run?
Discovery runs as Phase 1 of every assessment, so the map is rebuilt from live behaviour on each run rather than carried over.
Will we be alerted when something new appears?
Alerting is available through Slack and Microsoft Teams, with webhooks for routing new assets into whatever else you run.
Can you detect subdomain takeover conditions?
SSL/TLS and certificate posture analysis runs across discovered assets, which surfaces much of the underlying hygiene problem that makes a takeover possible.
The platform capabilities behind this feature
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
An agent that changes its mind
Agents that read the response and decide what to try next, which is what makes access control and business logic testing possible at all.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
Proven beats predicted
Intelligence tells you what is exploited somewhere. Validation tells you what is exploitable here, with the request and response to prove it.
Find out what is actually reachable
Give us your domains. We will map what responds, fingerprint it, and test what we find.
Scope verified before any test runs · Discovery ends in testing