Protect · Attack surface
What an attacker sees of you, ranked by what attackers are probing this week.
Declare your domains and address ranges. The platform proves they are yours, maps what sits under them from public records, and judges every asset against a closed catalogue of 20 exposure rules. Findings carry their evidence, close themselves when you fix the problem, and sort by how hard your own sensors say that port is being hunted.
Before anything is touched
Declare, prove, consent. Then discover and judge.
Passive discovery runs for every seed. Anything that opens a connection to an asset waits for two things: proof that the asset is yours, and a separate, audited consent to look at it.
01
Declare
Seeds are your domains and your public address ranges (up to a /22 in IPv4, a /64 in IPv6). Import them in one call from a monitored brand’s domains or an asset group’s ranges.
02
Prove
A domain is proven by a DNS TXT record or a /.well-known file carrying a token we issue (no redirects followed). A range is proven by an RDAP organisation match plus an audited attestation naming who vouches.
03
Consent
Proving you own something and asking us to touch it are two acts. Consent to active checks is a second, separate, audited decision, and withdrawing it cancels any outstanding probe plan at once.
04
Discover
Public records only: certificate transparency, DNS and RDAP, plus Shodan or Censys under your own key. One hop from the seed, inside its zone.
05
Judge
Every asset is evaluated against a closed catalogue of 20 rules. Findings carry their evidence and resolve themselves when the evidence is gone.
Inventory
Every asset says why we think it is yours.
Domains, hosts, addresses and certificates, each with first-seen and last-seen dates, its observations and their source, and an ordered list of attribution reasons. Two independent reasons make an asset Approved on arrival; one makes it a Candidate for an analyst to decide.
- One hop, in zone. A certificate that also names someone else’s domain contributes only your names; the rest are dropped at the adapter and counted, never stored. A shared hosting block does not pull in the provider’s other customers.
- The second hop is a proposal. Apexes that share your certificates, or your registrant’s mail domain, arrive as candidate seeds, never as assets. An Admin accepts or rejects; a rejection is final.
- States are a person’s call. Candidate, Approved, Dependency, Monitor only, Dismissed, Gone. Discovery sets the first state once and never demotes a human decision. Unseen for 45 days, an asset goes Gone: kept, and revived with its history if it returns.
vpn.example.com
Why we think it is yours
- subdomain-of-seed
- cert-san-with-seed
- cname-of-owned
Score 1.0 · seed example.com · proven by DNS TXT · probe consent given
| kind | observation | source |
|---|---|---|
| dns | A 203.0.113.7 | dns |
| tls | served leaf · expires in 9 days | light tier |
| http | 443 HEAD 200 · Server: nginx/1.18.0 | light tier |
| service | tcp/22 open · SSH-2.0-OpenSSH_8.9p1 | probe runner |
Exposure catalogue
A closed catalogue of 20 rules. Reviewable at a glance.
Each rule names its default severity, the evidence it requires and what it needs to be evaluated. There is no rule language and no imported scanner templates: a rule is added by a code change with a test that counts them. A rule this deployment cannot evaluate says “not evaluated”, never a silent pass.
DNS
3Read from public DNS
dns-dangling-cname
Dangling CNAME
A CNAME whose target answers NXDOMAIN.
Highneeds: passive
dns-takeover-fingerprint
Subdomain takeover
A CNAME to a provider on the takeover fingerprint list that no longer resolves, or whose page shows the provider’s “unclaimed” signature. Supersedes the dangling finding: one exposure, one finding.
Criticalneeds: passive + light
dns-zone-transfer-allowed
Zone transfer allowed
An authoritative nameserver answers AXFR. Catalogued and opt-in per seed; it reads “not evaluated” until the active DNS check is switched on.
Highneeds: active DNS
E-mail authentication
4Read from public DNS
email-spf-missing
SPF record missing
No v=spf1 TXT record at the apex.
Mediumneeds: passive
email-spf-permissive
SPF record permissive
The SPF record ends in +all or ?all.
Mediumneeds: passive
email-dmarc-missing
DMARC record missing
No v=DMARC1 record at _dmarc.
Mediumneeds: passive
email-dmarc-policy-none
DMARC policy is none
The DMARC record carries p=none.
Lowneeds: passive
Certificates
4Read from the served certificate
cert-expired
Certificate expired
The served leaf certificate is past its notAfter date.
Highneeds: light
cert-expiring-soon
Certificate expiring soon
The served leaf expires within 14 days.
Lowneeds: light
cert-hostname-mismatch
Hostname mismatch
No name on the served certificate matches the host.
Mediumneeds: light
cert-weak
Weak certificate
A SHA-1 signature, or an RSA key shorter than 2048 bits.
Mediumneeds: light
Web
4Read from one HEAD on 80 and 443
web-no-https
No HTTPS
Port 80 answers and port 443 does not.
Lowneeds: light
web-hsts-missing
HSTS missing
The HTTPS answer carries no Strict-Transport-Security header.
Lowneeds: light
web-admin-panel-exposed
Admin panel exposed
The page title or a header matches the closed admin-panel fingerprint list.
Highneeds: light
web-server-version-disclosed
Server version disclosed
Server or X-Powered-By carries a version, which is exactly what the CVE matcher reads.
Infoneeds: light
Exposed services
3Read by the Probe runner, or your Shodan or Censys key
service-admin-exposed
Remote administration exposed
SSH, RDP, VNC or WinRM answers from the internet (ports 22, 3389, 5900, 5985).
Highneeds: runner or your key
service-database-exposed
Database exposed
A database or search port answers: 1433, 3306, 5432, 6379, 9200, 27017.
Criticalneeds: runner or your key
service-plaintext-management
Plaintext management protocol
FTP or Telnet answering on 21 or 23 (runner or your key); SNMP on 161 from your Shodan or Censys data.
Mediumneeds: runner or your key
Known vulnerabilities
2Judged by the version-aware matcher
vuln-cve-confirmed
Known vulnerability (confirmed)
An exact version, read through a reviewed product resolution, inside an NVD range, with a network attack vector.
CVSS band · Critical if in KEVneeds: matcher
vuln-cve-potential
Potential known vulnerability
The product resolved but the version is major-only or carries a distribution suffix. Shown, never notified, never exported.
Medium at mostneeds: matcher
Findings close themselves
When the next complete evaluation no longer sees the evidence, the finding resolves. If the evidence returns, it reopens with its history. A check that did not run touches nothing.
Dispositions that stick
Accept a risk until a date and the acceptance lapses on its own; mark a false positive and it is never re-paged. Findings on someone else’s box (a CDN edge, a SaaS login) are shown and never notified.
A bell, not a pager
Findings are posture, not events: they reach the notification centre, never the alert pipeline, a playbook or the blocklist. The first run for a seed is one digest (“17 assets, 9 findings”), not twenty-six bells.
CVE claims
A CVE from a version, never from a name. In one of two tiers, with the evidence attached.
Observed banners and headers are resolved to a product through a reviewed table (no fingerprint corpus is imported), and the version is judged against an NVD mirror kept on your deployment. The claim lands in exactly one tier, or nowhere.
- EPSS sorts, never scores. The exploit-prediction probability and percentile are a sort key on the list. They never change a severity and never ring a bell.
- A measured false-positive budget. Per product, the 30-day ratio of withdrawn Confirmed claims. At 30 % or more (with at least ten decisions) that product’s matches drop to Potential and its resolution is flagged for review.
- Confirmed-tier bells ship off. Findings are stored, scored and shown from day one; the bell for them stays off until the tier’s measured false-positive ratio is 10 % or lower.
Confirmed
- Exact upstream version: two or more components, no distribution suffix
- Inside a vulnerable NVD range
- Network attack vector
- Severity from CVSS; Critical when in CISA KEV
Potential
- Major-only version, or a suffix such as Ubuntu-3ubuntu0.7; a backported fix does not change the banner
- Capped at Medium, titled “Potential”
- Never notified, never exported, never counted as “affects you”
Refused: no finding at all
A product name with no version. A banner with no reviewed resolution. A local, adjacent or physical attack vector on an internet-facing asset.
evidence ≤ 2 KB: observed-at · source · banner excerpt · parsed product and version · CPE · matched range · NVD last-modified · tier reason
Prioritised by your own sensors
The finding your sensors say is being hunted goes to the top.
Each exposed-service finding carries a chip: “probed on your sensors: N sources / 7 d”, the distinct source addresses your internet-facing deception fabric saw hitting the same ports in the last week. A standalone EASM service cannot tell you that: it does not run your sensors.
Pressure is a sort key, not a severity. The catalogue says how bad an exposure is; the fabric says how loud the weather is. Internal decoys are never counted. The Deception Fabric
service-plaintext-management
203.0.113.30 · tcp/23
Medium1,204 sources / 7 dservice-admin-exposed
rdp.example.com · tcp/3389
High312 sources / 7 dservice-database-exposed
203.0.113.24 · tcp/6379
Critical41 sources / 7 dservice-admin-exposed
ssh.example.com · tcp/22
High0 sources / 7 d
Compared fairly
Against a standalone EASM service.
Dedicated external-attack-surface products discover further and keep longer history. This module is built for something else: joining your surface to what your own sensors see and to the validation you already run.
| Typical standalone EASM | Wahukeza | |
|---|---|---|
| What ranks a finding | Severity, CVSS, KEV and exploit-prediction scores: what is being exploited somewhere. | The same, plus how many distinct sources hit that port on your own sensors in the last seven days. |
| After prioritisation | Usually stops. Validation is a separate product, bought separately. | A finding proposes a draft emulation engagement; the coverage report says whether your SOC saw the benign probe. |
| Discovery depth | Recursive chains over large historical DNS, WHOIS and certificate datasets. | One hop from proven seeds, in zone only; anything further out is a proposal a person accepts. Narrower by design. |
| Who scans, from where | The vendor’s scanners, from the vendor’s address space. | A Probe runner you operate from your own network, or one Wahukeza operates for you, either way under a published scanner identity, executing only a signed plan against assets you proved and consented to. |
| Where the inventory lives | In the vendor’s cloud. | In your own database: on your premises, or your own tenant database on an instance we operate. Shodan or Censys results under your key stay there and are never exported or exchanged. |
Active checks
Ports beyond 80 and 443 are checked by a Probe runner (yours or ours) from a signed plan.
The platform itself never sweeps a port. Its built-in light tier touches only proven, consented hosts: DNS, one TLS handshake on 443 that reads the certificate without trusting it, one HEAD on 80 and 443. Everything else is the Probe runner’s job.
- Your runner or ours. Run cti-probe yourself (your scanner identity, your network) or have Wahukeza run it for you. Either way it executes only the signed plan, against ownership-proven, consented targets, under a published scanner identity with an opt-out page.
- A signed plan, or nothing. cti-probe polls for an Ed25519-signed plan, verifies it against a pinned key and refuses the whole plan if anything is off: a port outside its list, a private address, more than 500 targets, an expired window. It runs each plan once.
- Thirteen ports, compiled in. The binary carries the catalogue’s port list as a literal, and a test fails the build if the two ever differ.
- ≤ 1 KB per port. A TCP connect with a one-second timeout, then whatever the service volunteers, up to 1,024 bytes. It sends nothing, except one fixed HEAD request on WinRM and Elasticsearch. No TLS, no DNS, no shell: a standard-library Go binary, unprivileged, with a kill-switch file.
- A published identity. A fixed User-Agent citing a public scanning page; reverse DNS on the runner’s address naming its purpose; an abuse mailbox that is read. Anyone can opt out without an account, proving their domain or range the same way you proved yours.
- 21
- 22
- 23
- 161
- 1433
- 3306
- 3389
- 5432
- 5900
- 5985
- 6379
- 9200
- 27017
Never
What the active tier will not do, by construction.
No internet-wide scanning
Nothing is ever surveyed that you did not declare as a seed, prove and consent to. Opted-out addresses are left out before a plan is signed.
No exploitation
A finding is never “confirmed” by trying it. The only validation is the adversary-emulation module’s benign procedures, inside an engagement a person authorised.
No port scan from the platform
The built-in light tier has no code path to any port but 80 and 443, and a test proves it, so the platform’s shared egress address is never put at risk by one tenant’s port scan.
No imported fingerprints
Product resolution and the admin-panel and takeover lists are closed, reviewed in-repo tables. No GPL or proprietary fingerprint corpus, no third-party scanner templates.
Bridges
A finding is where the next step starts.
propose-engagement-targets
To adversary emulation
An exposed-service or CVE finding on an Approved asset proposes a Draft engagement with that asset as the target. It has no window and no procedures; nothing runs until an Admin who is not its author authorises it. The coverage report then answers the question: the RDP port was open; did anyone see the probe?
Needs Adversary Emulation
one matcher, two inventories
To endpoint vulnerabilities
The same two-tier matcher reads your endpoints’ installed packages from the inside, against Red Hat, Microsoft, Debian and Alpine advisories, backport-aware, so a patched distribution package is not mistaken for a vulnerable one.
Needs Endpoint Intelligence
affects you · exposed-service
To the security wire
When a news item names a CVE that is a Confirmed finding on one of your Approved assets, it is flagged as affecting you. Potential matches never are.
Adversary EmulationEndpoint IntelligenceThe Deception Fabric
Limits and defaults
Bounded, and the bounds are written down.
Seeds and assets are the metered units of the module. Attack Surface Management is part of the Advanced and Complete packages, and can be licensed on its own.
| Seeds | 25 per licence by default |
| Assets | 2,000 non-Gone assets per licence by default |
| Range size | Up to /22 (IPv4) and /64 (IPv6) per seed; wider is several seeds |
| Probe targets | 500 per day by default, shared by the light tier and the runner |
| Cadence | Discovery daily · light tier every 6 h · runner at most once per asset per 24 h |
| Gone | Unseen for 45 days; kept 180 days, revived with history |
| Retention | Resolved findings 365 days; false positives stay with their asset |
| One surface, one tenant | A range or domain proven by one tenant cannot be proven by another on the same deployment |
Straight answer
What it does not do.
Not a deep-history discovery engine
One hop from your seeds, from public records and your own Shodan or Censys key. If you need years of passive-DNS history, that is a different product; this is where its results get used.
No cloud accounts, buckets or suppliers
No AWS, Azure or GCP inventory connectors, no public-bucket discovery, no third-party or supplier surface. A seed is always your own.
No scanning outside a signed plan
Whether you run the Probe runner or Wahukeza runs it for you, active checks leave only under a published scanner identity, only for a signed plan, and only against assets you proved and consented to. Nothing is scanned on speculation.
Not web-application testing
No crawling behind a login, no fuzzing, no DAST. A HEAD, a certificate read, at most one bounded page read for a title, and a banner of at most 1 KB are the whole of it.
ASN seeds ship switched off
Expanding an AS number into its announced prefixes is built, but its data source restricts commercial use without permission. Until a deployment holds that permission, add your prefixes as range seeds.
Vulnerability bells wait for a number
CVE findings are shown from day one; they ring only once the Confirmed tier’s false-positive ratio has been measured and holds at 10 % or lower.
Give us one domain.
We will prove it with you, map what sits under it, and show the findings, with the reason each asset is yours and which of them your sensors say are being probed right now.