Attack Surface Management
You cannot defend the asset nobody told you about.
Starting from nothing but your domain name, we map what you actually have facing the internet — then keep mapping it, because it changes every week without anyone filing a ticket.
Expansion signals
- DNS and zone records412 namesComplete
- Certificate transparency214 certificatesComplete
- WHOIS and registration9 registrant recordsComplete
- ASN and IP attribution6 netblocksComplete
- Cloud tenant enumeration63 cloud assetsComplete
- Third-party SaaS footprint19 vendor propertiesIn progress
Inventory
Exposures by severity
- Critical2
- High6
- Medium11
- Low8
- Input required
- One domain name
- Discovery
- Passive first, active only with permission
- Prioritisation
- Exploitability and business context, not raw CVSS
Discovery
Start with one domain. Expand until it stops finding things.
Asset inventories go stale because they are maintained by hand. So we do not ask you for one. We take a single domain name and expand outwards through the public record until the new-asset curve flattens — then keep going on a schedule, because it never stays flat.
01
DNS and zone records
We walk the zone from the outside: A, AAAA, CNAME, MX, TXT, NS and SRV records, plus how wildcards behave. The names that appear in only one record type are usually the ones missing from your inventory spreadsheet.
02
Certificate transparency
Every publicly trusted certificate is written to a public log. The subject alternative names in those logs expose hostnames that were never announced anywhere else — sometimes before they resolve.
03
WHOIS and registration data
Registrant details, name servers and creation dates connect the domains you registered years ago to the ones you use today, including the campaign domain a marketing team bought on a company card.
04
ASN and IP range attribution
Routing and registry data show which netblocks are announced under your organisation. We work forward from the range and backward from reverse DNS, and only claim an address when both directions agree.
05
Cloud tenant enumeration
The major clouds use predictable public naming for tenants, storage endpoints and app services. That is how a container created in a subscription nobody tracks ends up in your inventory rather than in an incident report.
06
Third-party SaaS footprint
A subdomain delegated to a vendor is still your front door. Status pages, help centres, form hosts and marketing portals get inventoried and watched like anything you run yourself.
Inventory
One list, with the evidence attached
Discovery is only useful if the result is a list somebody can act on. Every asset gets a type, a first-seen timestamp, the exposure we found, how sure we are it is yours, and a severity — so the queue orders itself.
Asset inventory
example.com · 683 assetsIllustrative sample data| Asset | Type | First seen | Exposure | Confidence | Severity |
|---|---|---|---|---|---|
| build-controller.example.com | Web app | 2 days ago | Build server login page reachable; anonymous read enabled | Confirmed | Critical |
| db-01.example.com:27017 | Database | 9 days ago | Database answers on the public internet without authentication | Confirmed | Critical |
| assets-legacy.example.com | DNS record | 21 days ago | CNAME points at a deprovisioned bucket — subdomain takeover possible | Confirmed | High |
| exampleco-backups (object storage) | Cloud storage | 6 days ago | Container listing enabled to anonymous callers | Probable | High |
| vpn.example.com | Network edge | 8 months ago | Remote access gateway running two releases behind the vendor's current | Confirmed | High |
| staging.checkout.example.com | Web app | 5 weeks ago | Pre-production checkout reachable and indexed by search engines | Confirmed | Medium |
| mail.eu.example.net | 4 months ago | SPF record ends in ~all and DMARC policy is set to p=none | Confirmed | Medium | |
| 198.51.100.0/24 | Netblock | 11 months ago | Attributed from routing and registration data; no exposure found | Candidate | Low |
Sample rows, not a real estate. In the product every asset carries the evidence behind its attribution — the certificate, the DNS answer, the routing record — and you can reject an asset that is not yours. The rejection sticks, so it does not come back next week.
- First seen, not last scanned
- Assets keep their history. You can show an auditor the day a host appeared, the day the exposure opened, and the day it closed.
- Confidence you can argue with
- Attribution is a judgement, so we show ours. Candidates are labelled as candidates instead of padding the total.
- Exposure in one sentence
- Written so a duty engineer at 2am knows what is wrong and what to do, without opening three other tools first.
Exposure classes
What we look for once we know what you have
Discovery finds the asset. These are the conditions that turn an asset into an exposure — the same handful of mistakes, on every estate, in every industry.
Exposed admin interfaces
Management consoles that were meant to sit behind the VPN and never got moved back.
/admin · :8080/manager · Jenkins · Grafana · phpMyAdmin
Unauthenticated databases and caches
A database bound to 0.0.0.0 instead of localhost answers anyone who asks.
:27017 · :6379 · :9200/_cat/indices — no credentials required
Open storage buckets
Object storage with listing or read access left open to anonymous callers.
bucket listing returns object keys to an unauthenticated GET
Expired or mis-issued certificates
Certificates past their validity date, or issued for names you no longer control.
expired 3 days ago · wildcard covering a domain you divested
Dangling DNS records
A record still points at a cloud endpoint nobody owns — so somebody else can claim it and serve content on your name.
CNAME → deprovisioned bucket, app service or CDN origin
Default credentials on edge devices
Firewalls, load balancers, cameras and appliances still on the credentials they shipped with.
vendor default accepted on a management page facing the internet
Forgotten staging environments
Pre-production copies with production data, weaker authentication and no monitoring.
staging. · uat. · -dev. · old release hosts nobody retired
Secrets in public code and bundles
Keys committed to a public repository, or shipped inside a front-end bundle where anyone can read them.
API key in app.js · .env or .git/config served from the web root
Drift
The surface changes weekly. Nobody files a ticket.
This is the reason attack surface management exists as a category. Not because the exposures are exotic, but because the list of things to check will not hold still.
A team ships a service. A vendor stands up a portal on one of your subdomains. Someone renews a certificate with a different name on it. A contractor leaves a staging box running after the project closes. None of that arrives as a change request, and none of it is malicious.
Shadow IT is usually just speed. An agency registers a campaign domain because waiting a week was not an option. A data team opens a storage container to share a file and forgets to close it. The intent is fine. The exposure is real, and nobody owns watching it.
A penetration test is scoped to a list of targets on the day it begins. It is the right tool for depth on that list. It cannot tell you about the host that appeared the following Tuesday, and by the time the report is signed off the list has moved on.
So the useful question is not “what is exposed?” It is “what changed since we last looked?” Answering that needs continuous collection and kept history.
Change feed
last 7 daysIllustrativeAssets added and retired, ten weeks
- Added
- Retired
- Tue 09:14Newpayments-api.example.com
New host, resolving to a cloud account outside your main subscription
- Tue 22:41Opened198.51.100.42:3306
Database port now answering from any source address
- Wed 11:02Changed*.example.com
Wildcard certificate reissued by a different certificate authority
- Thu 08:30Newexampleco-eu-uploads
Storage container created in a subscription your team does not manage
- Fri 16:55Retiredold-crm.example.com
Stopped resolving; removed from the live inventory, kept in history
A point-in-time test
- Scope agreed before it starts
- Depth on the targets in that scope
- Findings begin ageing the day of the report
- Repeats quarterly or annually
Continuous discovery
- Scope re-derived on every run
- Breadth across everything attributable to you
- New exposure flagged when it appears
- History kept, so you can read the diff
You want both. They answer different questions, and neither replaces the other.
Prioritisation
A severity is an argument, not a number
A list of 400 findings sorted by CVSS is a list nobody works through. We rank by whether a thing can actually be used against you, and we show the reasoning so you can disagree with it.
What moves a finding up the queue
- Input 1
Can it be used, and is it being used?
Public exploit code and evidence of exploitation in the wild move a finding up. A high score with no practical route into your environment does not.
- Input 2
Is it actually reachable?
Reachable from any address, with no credentials, no VPN and nothing in front of it, counts for far more than a number in a vulnerability database.
- Input 3
What does the asset do?
An identity provider, a build server or a payment path is not the same risk as a marketing microsite running identical software.
- Input 4
What else do we already know?
If credentials for that host are sitting in a leak we are tracking, or a lookalike domain is phishing for them, the finding is ranked with that context rather than in isolation.
Asset criticality is the one input we cannot work out from the outside. You define which systems matter — payments, identity, the release path — and the ranking follows your definition rather than a generic one.
Why this is critical
Rank inputs
- ExploitabilityTrivial — no credentials needed
- ReachabilityOpen to the internet
- Asset criticalityBuild and release path
- Correlated exposureLeaked credentials on file
- Step 1AttributionPassive
Resolves into 198.51.100.0/24, a range registered to your organisation. The TLS certificate names the same legal entity.
- Step 2Service identifiedPassive
Answers on 443. Response headers, favicon hash and login page all match a self-hosted continuous integration controller.
- Step 3Exposure confirmedActive · authorised
One unauthenticated GET to /api/json returned job names. Single request, rate-limited, read-only, inside your signed scope.
- Step 4ReachabilityPassive
No WAF, no IP allow-list and no VPN in front of it. Reachable from any source address on the internet.
- Step 5CorrelationPassive
Three build accounts on this host appear in credential leaks already sitting in your dark web feed.
- Step 6Blast radiusPassive
Build controllers hold deployment credentials. A foothold here reaches production without crossing the perimeter again.
Verdict and next steps
Unauthenticated service, reachable from anywhere, credentials for it already circulating, and a straight path to production. That combination is what makes it critical — not the software version.
- Step 01Put the host behind the VPN or an IP allow-list today.
- Step 02Disable anonymous read and require SSO on the console.
- Step 03Rotate every deployment credential the controller holds.
- Step 04Review build history for job triggers nobody recognises.
Collection safety
Passive by default. Active only on paper.
Your security team is right to ask what we send at your infrastructure. Here is the whole answer, without hedging — it is also the part of the contract we expect to be held to.
- Stage 1
Passive collection
Default. Nothing is sent to your systems.
Public records only: DNS answers, certificate transparency logs, domain registration data, routing and registry data, and search indexes. Your hosts see no traffic from us at all.
- Stage 2
Non-intrusive confirmation
The request a browser would make.
To confirm what a host actually serves we fetch it the way any visitor would — read the response, the headers and the certificate, and stop. Rate-limited, logged, and sent from source addresses you can allow-list.
- Stage 3
Active checks
Only with written authorisation.
Anything beyond a plain read needs a signed scope: the hostnames and ranges in play, the window, and named contacts on both sides. Read-only, non-destructive, and paused the moment you ask.
What we never do
No exploitation. We do not attempt access, escalate privileges or run code on your systems.
No credential attacks. No brute force, no password spraying, and we never replay leaked credentials against your estate to see whether they still work.
No writes. Nothing uploaded, created, modified or deleted. Verification is read-only.
No stress on your services. Request rates are conservative by default and we will lower them further on request, per host or per range.
No third-party targets. If an asset is not yours, we do not test it — even when it carries your name. We report it to you instead.
How you check what we did
Our traffic identifies itself, and every request behind a finding is logged. If something in your access logs looks like us, you can confirm it — or stop it.
- user-agent:
- 0DaySecure-ASM (+/legal/security)
- source ranges:
- published and allow-listable
- request log:
- available for any finding, on request
- pause:
- security@0daysecure.com
Authorisation is a document, not a checkbox. Stage 3 does not begin until a scope is signed by someone at your organisation who can sign for it. If your estate includes assets hosted by a third party, that provider has to agree too — and we will say so rather than quietly proceeding.
Questions
Before you book anything
The five things security teams ask us first about discovery and scanning.
One domain name. Everything else is derived from it. If you already know about other brands, netblocks, cloud account identifiers or acquired companies, tell us and we will seed those too — it shortens the first pass, but it is not a prerequisite.
No. Discovery starts from public records only — DNS, certificate transparency, registration data, routing data — which means your hosts see no traffic from us. Confirming what a host serves involves a normal, rate-limited HTTPS read. Anything more intrusive than that requires a written, signed scope, and stops when you say stop.
A scanner needs a list of targets; attack surface management builds the list. A penetration test goes deep on a scope agreed on the day it starts, which is the right tool for depth but cannot cover the host that appeared the following week. We work from the outside with no agent and no credentials, and we keep looking.
Every asset carries the evidence behind its attribution — the certificate, the DNS answer, the routing record — and a confidence level from candidate through to confirmed. Low-confidence assets are shown as candidates rather than folded silently into your inventory, and if you reject one, the rejection persists.
Email and a shared workspace by default, with severity-based routing so a critical exposure does not queue behind a certificate expiry notice. Webhook, chat and ticketing delivery are on the roadmap for the modules being built now — ask us where a specific integration stands before you plan around it.
Give us one domain.
We will run discovery on your real estate and walk you through what came back, including the assets you did not expect. Thirty minutes.
- One domain to start
- Passive collection by default
- Findings are yours to keep