# Attack Surface Management > Attack surface management that proves ownership before any active check: 20 exposure rules, evidenced CVE claims, findings ranked by decoy activity. Source: https://wahukeza.com/platform/attack-surface 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. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. external asset · hostApproved 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 | Sample asset, documentation addresses. Every observation names the source that saw it. 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 3 Read 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 4 Read 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 4 Read 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 4 Read 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 3 Read 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 2 Judged 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 EPSS scores: see EPSS at first.org/epss. 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](https://wahukeza.com/platform/sensors) exposure findings · opensort: pressure ↓ - service-plaintext-management 203.0.113.30 · tcp/23 Medium1,204 sources / 7 d - service-admin-exposed rdp.example.com · tcp/3389 High312 sources / 7 d - service-database-exposed 203.0.113.24 · tcp/6379 Critical41 sources / 7 d - service-admin-exposed ssh.example.com · tcp/22 High0 sources / 7 d Sample data. The Medium Telnet finding outranks the Critical database because a thousand sources knocked on port 23 this week; its severity stays Medium. 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 No runner yet? Shodan or Censys under your own key answers the service rules. With neither, those rules read “not evaluated”. 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 Emulation](https://wahukeza.com/platform/emulation)[Endpoint Intelligence](https://wahukeza.com/platform/endpoint-intelligence)[The Deception Fabric](https://wahukeza.com/platform/sensors) 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.
Seeds25 per licence by default
Assets2,000 non-Gone assets per licence by default
Range sizeUp to /22 (IPv4) and /64 (IPv6) per seed; wider is several seeds
Probe targets500 per day by default, shared by the light tier and the runner
CadenceDiscovery daily · light tier every 6 h · runner at most once per asset per 24 h
GoneUnseen for 45 days; kept 180 days, revived with history
RetentionResolved findings 365 days; false positives stay with their asset
One surface, one tenantA range or domain proven by one tenant cannot be proven by another on the same deployment
[Packages and what is metered](https://wahukeza.com/pricing) · [Ask for a quote](https://wahukeza.com/contact?intent=quote) 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. [Book a demo](https://wahukeza.com/contact?intent=demo) [Packages & licensing](https://wahukeza.com/pricing)