Attack Surface Intelligence (ASMINT): Intelligence Discipline Guide

You cannot defend what you do not know you own. Attack surface intelligence is the discipline of inventorying your exposed estate before someone else does it for you.

What Attack Surface Intelligence is as a discipline

Attack surface intelligence is the continuous discovery, enumeration and attribution of every internet-reachable asset an organisation owns or is accountable for: domains and subdomains, IP ranges, cloud tenants, exposed services, certificates, mobile applications, code repositories and SaaS instances. Collection is passive-first, drawing on public DNS, Certificate Transparency, regional registry allocations, internet-wide scan datasets and cloud naming conventions, then confirmed with authorised active probing. The product is not a host list but an attributed inventory, where each asset is tied to an owning business unit, a business function and a risk rating.

Maturity runs from periodic manual sweeps, through scheduled seed-based automated discovery, to continuous change detection where new exposure raises a ticket within hours. Sub-methods include seed expansion outward from known domains and ASNs, reverse discovery inward from scan data using TLS names, HTTP headers and favicon hashes, and shadow-IT discovery through SaaS tenant naming and repository leakage. In the intelligence cycle it sits in direction: it defines the estate everything else must monitor.

Why it matters

This is the only discipline that answers what the adversary sees when they look at you today. Vulnerability scanning covers assets already in the asset register; attack surface intelligence finds the ones that are not, such as a forgotten staging box, an acquisition legacy VPN, a misconfigured storage bucket or an exposed CI runner. A large share of opportunistic intrusions begin at an asset nobody claimed, which makes discovery of unknown exposure the highest-yield and lowest-cost control available.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

• Newly resolving subdomains with their host records, wildcard behaviour, and dangling CNAMEs pointing at deprovisioned cloud resources
• Open ports and service banners across owned IP space, with product and version strings from HTTP, SSH, SMTP and RDP responses
• TLS subject alternative names exposing internal hostnames, staging environments and unannounced product names ahead of launch
• Cloud storage buckets, blob containers and object stores matching organisational naming conventions, with their public read or list permissions
• Exposed administrative interfaces: management consoles, database ports, Kubernetes API endpoints, CI dashboards and remote-access gateways
• Public repositories, package registries and mobile application binaries containing organisational identifiers, internal endpoints or embedded keys
• ASN and IP allocation records confirming which netblocks you announce, including space inherited through acquisitions and legacy hosting
• Third-party assets carrying your branding: marketing microsites, ticketing portals and subdomains delegated to agencies or resellers

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

• crt.sh — Certificate Transparency search surfacing subdomains and internal names from every publicly issued certificate
• Censys — Internet-wide scan data with parsed service, certificate and software metadata queryable by netblock or ASN
• Shodan — Banner and service data across IPv4 and IPv6, with historical views of what was exposed and when
• RIPEstat and RIR whois — Authoritative allocation and ASN data confirming which address space your organisation actually holds
• OWASP Amass — Open-source subdomain enumeration combining passive sources with authorised active resolution and graph output
• SecurityTrails — Historic DNS and hosting records revealing decommissioned hosts and infrastructure that predates your inventory
• GitHub code search — Public repositories referencing internal hostnames, API endpoints, configuration files and organisational identifiers

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

1. Fix the seeds — Establish authoritative seeds: registered domains, ASNs, netblocks, cloud account identifiers, brands and acquisition history, with legal confirmation of what may be probed.
2. Expand passively — Grow the candidate set using Certificate Transparency, passive DNS, registration data and scan archives, without sending a single packet to the target.
3. Attribute and prune — Confirm ownership for each candidate using registration, hosting, certificate and content evidence. Discard false positives and document the evidence behind every asset retained.
4. Verify under authorisation — With written scope, resolve, port-scan and fingerprint confirmed assets. Record service versions, TLS configuration, authentication surfaces and default credential exposure.
5. Rank the estate — Score assets by exposure type, data sensitivity, patch state and ownership gap. Escalate unowned or unmanaged assets to the responsible business unit by name.
6. Diff continuously — Re-run discovery on a schedule, diff against the prior inventory, and alert on new exposure, changed services and newly dangling DNS records.
7. Close the loop — Push validated findings into asset management and vulnerability workflows with a named owner, a deadline and an explicit verification step.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Applied in these mission domains

• Operational Security

Operates on these data points

• Email Address — Electronic mail address tied to an individual or organization.
• Username / Handle — Screen name or handle used across online platforms and services.
• Password / Credential — An exposed password or credential pair from leaks or dumps.
• Credential / API Token — An exposed secret — API key, token, or JWT — granting access to systems and data.
• Subdomain — A host under a parent domain — often reveals staging, admin, and forgotten infrastructure.
• SSL/TLS Certificate — A digital certificate binding a public key to an identity.

Related disciplines

• Breach Intelligence — Exposed Credentials and Compromised Data
• Certificate Intelligence — TLS Certificates and Certificate Transparency
• Cyber Intelligence — Adversary Activity in Networks and Systems
• Dark Web Intelligence — Hidden Services and Closed Criminal Venues
• Domain Intelligence — Domains, DNS, and Registration Intelligence
• Malware Intelligence — Understanding Malicious Code

Inside the platform: where Attack Surface Intelligence lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

• discipline.php?d=ASMINT — Discipline hub
• source-catalog.php?disc=ASMINT — Source catalogue filtered to this discipline
• email-profile.php — Email Address profile
• url-profile.php — Subdomain profile
• search.php — Advanced search, filter and pivot
• correlate.php — Correlation graph
• cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

• Correlate Infrastructure
• DNS Audit
• Threat Hunt
• Detection Rules
• Enrichment Runner
• Summarise (Copilot)
• Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

1. Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Fix the seeds is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
2. Building the picture. A single indicator is rarely the story. Attribute and prune turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
3. Producing something actionable. Analysis that ends in a document nobody can use is wasted. Close the loop feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Attack Surface Intelligence

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Defence practitioners run attack surface intelligence against their own networks and mission systems as a force protection and readiness function, and against coalition or contractor estates where an agreement grants that authority. The output is an attributed inventory tied to mission systems, feeding cyber terrain mapping, defensive task organisation and commander risk acceptance decisions. Discovery of an unclaimed asset carrying mission traffic is a reportable readiness issue, not a housekeeping item. The constraint that matters is authority: passive discovery against your own estate is routine, but active probing requires a scoped authorisation, and any scanning that reaches host nation or partner infrastructure needs explicit legal clearance before a packet is sent.

🕵 National intelligence

National intelligence bodies practise this discipline defensively over their own and their partner estates, and analytically over the exposed infrastructure of entities of interest using only passive, publicly available data. The methodological point is that the same passive techniques used to inventory yourself also characterise a foreign network from the outside, which is why the tradecraft is dual purpose and why the authorities differ sharply between the two. Defensive products feed accreditation and continuous monitoring; analytical products feed infrastructure assessments. Handling separates the two: an internal exposure inventory is highly sensitive because it is a target list, and is normally held at a higher classification than the analysis it supports.

👮 Law enforcement

Law enforcement uses attack surface techniques in two lawful modes. Defensively, agencies inventory their own exposure, which matters acutely because police systems hold sensitive victim and intelligence data. Investigatively, passive discovery from public scan data and Certificate Transparency helps map criminal infrastructure such as phishing estates, counterfeit shops and abuse hosting, and that mapping supports production orders and takedown requests. Passive collection from public datasets is generally unproblematic; active probing of a third party system may itself engage computer misuse offences and needs authority. Evidential use requires capture with timestamps, tool version and configuration recorded, plus hashes, so the observation can be reproduced and challenged.

🔍 Private investigation and corporate security

Corporate security teams practise this as continuous discovery over the estate they own, plus contractually authorised assessment of suppliers and acquisition targets. Passive discovery from public sources is lawful against any organisation; active scanning is not, and running a port scan or a web crawl against a third party without written authorisation risks criminal liability under computer misuse legislation regardless of intent. In transactions, passive external exposure assessment is a standard diligence input and is defensible; anything touching the target systems requires a signed scope. Output is an attributed inventory with owner, business function and risk rating, feeding remediation ownership rather than a raw list of hosts.

📰 Journalism and OSINT media

Journalists use attack surface techniques to evidence stories about exposed public services, leaking databases and negligent handling of personal data. The ethical line is strict: use passive, already-public scan and certificate data, do not access an exposed system beyond confirming its existence, and never download personal data to prove it was exposed. Verify with at least two independent datasets and preserve the evidence with timestamps. Responsible disclosure comes before publication, giving the owner and the relevant regulator or national CERT time to remediate, and publication should avoid detail that lets a reader reach the exposure while it is still live. Right of reply is standard.

🌍 NGO, humanitarian and human rights

Civil society organisations practise this defensively, because they are heavily targeted and usually run sprawling estates built by volunteers and short-term projects. The discipline is finding the forgotten campaign microsite, the abandoned volunteer portal and the misconfigured storage bucket holding beneficiary data before an adversary does. Do-no-harm is direct here: an exposed asset can reveal the location of a shelter, the identity of a witness or the existence of a programme in a hostile jurisdiction, so triage is by harm to people rather than by technical severity. Duty of care extends to partner organisations in the field, who often lack the capability and should be helped rather than reported.

🎓 University and research

Researchers use internet-wide measurement as a method for studying exposure at population scale: prevalence of vulnerable services, adoption of security protocols, cloud misconfiguration rates and the lifecycle of abandoned infrastructure. Methodology requires stating the vantage point, the scan dataset and its collection date, since results differ substantially between measurement platforms. Ethics review is required whenever measurement touches identifiable organisations or persons, and active scanning by the institution needs an approved protocol with opt-out handling, clear scan attribution and a published rationale. Prefer existing public scan corpora over generating new traffic, share the analysis code rather than redistributing licensed data, and cite the dataset snapshot rather than the live service.

Playbook: working Attack Surface Intelligence end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Establish scope and authority

Before any collection, define whose estate you are inventorying and under what authority. Separate assets you own, assets you are contractually responsible for, assets a supplier operates on your behalf, and assets that merely carry your brand. Record who has authorised active probing, over what address space, in what window, and who to contact if something breaks. Ambiguity here is the single most common source of legal exposure in the discipline. A good output is a written scope and authorisation document with named approvers and an explicit exclusion list. Stop when every planned collection technique is matched to a documented authority.

Phase 2 — Build the seed set

Assemble the authoritative starting points: registered domains, announced ASNs and netblocks, cloud tenant and subscription identifiers, brand names and trading names, and the legal entities in the group including recent acquisitions. Take these from registry and procurement records rather than from the IT asset register, which is usually incomplete by definition. Include historic names, since expired brands still resolve. A good output is a versioned seed list with the source and owner of each seed. Stop when finance, legal and corporate development have each confirmed no entity or brand is missing, because they know about acquisitions before IT does.

Phase 3 — Passive outward expansion

Expand from seeds using only public data: Certificate Transparency logs for subject alternative names, passive DNS for historic resolutions, registry allocation records for address space, and search of code and package registries for organisational identifiers. This phase generates no traffic to the target and can be run against anything lawfully. Record which technique produced each candidate, because provenance determines how much validation it needs. A good output is a candidate asset list with a discovery method recorded per entry. Stop when new expansion cycles produce mostly duplicates rather than new candidates.

Phase 4 — Reverse discovery from scan data

Work inward from internet-wide scan corpora using distinguishing features rather than names: TLS certificate fields, HTTP response headers and body fingerprints, favicon hashes, distinctive error pages and cloud metadata. This finds assets that use no organisational naming at all, which is exactly where shadow IT and forgotten estate live. Validate each candidate against at least one independent signal before accepting it. A good output is a set of confirmed assets that the outward expansion did not reach, with the fingerprint that found each one. Stop when your fingerprints stop yielding assets that pass validation.

Phase 5 — Attribute ownership

Turn candidates into an inventory by establishing who owns each asset. Attribution combines registry and allocation records, hosting and cloud account data, internal configuration management sources, and direct enquiry to business units. Every asset needs a named accountable owner, a business function and a data sensitivity rating, because an asset with no owner cannot be remediated. Resolve disputed and disowned assets rather than parking them: disowned assets are the highest risk category in the whole inventory. A good output is an inventory where every entry has an owner. Stop when the unattributed count is small enough to work individually.

Phase 6 — Authorised active confirmation

Within the authorised scope, confirm the passive picture with active probing: service and version confirmation, TLS configuration, HTTP responses and authentication surface. Use rate limits, identify your scanner in its traffic, and coordinate with operations so alerts are expected. Confirm rather than exploit; testing for exploitability is a different discipline with a different authorisation. A good output is a confirmed service inventory with evidence captured and timestamped, and a record of anything that did not respond. Stop when the authorised scope has been covered once and the discrepancies against the passive picture are documented.

Phase 7 — Identify and triage exposure

Assess what the confirmed inventory actually exposes: administrative interfaces reachable from the internet, unauthenticated services, dangling DNS records pointing at deprovisioned cloud resources, storage with public read or list permissions, expired or misissued certificates, and end-of-life software. Triage on business impact and reachability rather than on a generic severity score, and treat subdomain takeover risk as urgent because it is trivially exploitable and directly reputational. A good output is a ranked exposure list with owner, impact statement and a specific remediation action. Stop when every item has an owner and a due date.

Phase 8 — Route to remediation and verify

Push findings into the ticketing and change process that the owning team actually uses, with enough evidence for them to reproduce the finding without further help. Agree remediation timescales by severity in advance so each finding is not renegotiated. Verify closure by re-testing rather than by accepting a status update, and reopen anything that reappears. A good output is a closure rate and a verified-fixed count, not a findings count. Stop chasing an item only when re-testing confirms the exposure is gone or a documented risk acceptance exists with a named accepter and an expiry date.

Phase 9 — Establish continuous change detection

Move from a point-in-time sweep to a running capability: monitor Certificate Transparency for new names, watch for new resolutions and new services in owned space, alert on cloud resource creation outside approved patterns, and detect DNS records that begin dangling. Tune thresholds so a new asset raises a ticket within hours rather than at the next quarterly sweep. A good output is an alerting pipeline with measured time from asset appearing to ticket raised. Stop tuning when the false positive rate is low enough that alerts are actually triaged rather than filtered.

Phase 10 — Close the loop with governance

Feed the inventory back into the processes that create exposure: cloud provisioning standards, DNS record lifecycle, decommissioning checklists, acquisition onboarding and supplier onboarding. The measure of a mature capability is that new unknown assets stop appearing, not that you find them faster. Report the rate of newly discovered unknown assets to governance as a control effectiveness indicator. A good output is a demonstrable decline in unknown asset creation attributable to a specific process change. Stop when discovery is dominated by known, approved change rather than by surprises.

Phase 11 — Extend to third parties within authority

Apply passive-only discovery to suppliers, acquisitions and brand-affiliated third parties, since your exposure includes systems you do not run. Do not probe actively without a written authorisation in the contract or the transaction scope. Use the findings to drive contractual security requirements and pre-acquisition remediation conditions rather than to compile a scorecard nobody acts on. A good output is a supplier exposure summary tied to a specific contractual or transactional decision. Stop when the finding has been converted into an obligation, a condition or an accepted risk with a named owner.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
crt.sh	Open	Searchable interface to Certificate Transparency logs covering certificates issued by publicly trusted authorities with subject alternative names.	Primary outward expansion source for discovering subdomains and unannounced hostnames within hours of certificate issuance.
Certificate Transparency project	Open	Documentation and log ecosystem specifying append-only public logging of publicly trusted certificate issuance.	Explains log coverage and inclusion behaviour so discovery gaps are understood rather than assumed to be absence.
Censys	Registration	Internet-wide scan dataset covering hosts, services, software versions and certificates with historical snapshots.	Reverse discovery from certificate fields and service fingerprints to find assets that use no organisational naming.
Shodan	Registration	Internet-wide service scanning platform indexing banners, protocols, device types and exposed control interfaces.	Locates exposed administrative interfaces, databases and industrial devices within owned or authorised address space.
RIPEstat	Open	Query interface over registry allocation, routing and reverse DNS data for addresses, prefixes and autonomous systems.	Confirms which netblocks and ASNs the organisation actually holds, including space inherited through acquisition.
BGPView	Open	Interface to routing and allocation data linking organisations, ASNs, prefixes and upstream relationships.	Enumerates announced prefixes for the organisation and its subsidiaries as seed material for scanning scope.
Team Cymru IP to ASN service	Open	Mapping service resolving IP addresses to originating autonomous system, prefix and registry country.	Bulk attribution of discovered addresses to networks, separating self-hosted assets from cloud and third-party hosting.
Shadowserver	Registration	Non-profit scanning and sinkhole operation providing free daily reports of exposed and compromised assets to network owners.	Independent external confirmation of exposure in your own address space, delivered without you generating any traffic.
GreyNoise	Registration	Classification of internet-wide scanning and exploitation traffic, identifying which sources are mass scanners.	Establishes which of your exposed services are already being touched by opportunistic scanning, which sharpens triage.
ICANN Centralized Zone Data Service	Registration	Access programme for generic top level domain zone files listing delegated domains and their nameservers.	Authoritative enumeration of domains under a given nameserver, supporting discovery of forgotten registered names.
ICANN lookup and RDAP	Open	Registration data lookup for domain names returning registrar, status, nameservers and available contact fields.	Confirms which registered domains belong to the organisation and identifies expiry risk on assets still in use.
OSV.dev	Open	Open vulnerability database for software packages with precise affected version ranges across ecosystems.	Assesses discovered application and dependency versions on exposed assets against known vulnerable ranges.
CISA Known Exploited Vulnerabilities catalog	Open	Authoritative list of vulnerabilities with confirmed exploitation in the wild and remediation due dates.	Sets triage priority for exposed services, since a KEV-listed weakness on an internet-facing asset outranks severity scores.
OWASP	Open	Open community publishing application security guidance, testing methodology and reference risk classifications.	Provides the testing methodology reference for confirming web application exposure within an authorised scope.
NIST	Open	Publisher of security control catalogues, testing guidance and the cybersecurity framework used for asset management controls.	Anchors the inventory requirement and authorised testing practice to a recognised control framework.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Attack Surface Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Amass — Combines passive sources and optional active resolution for subdomain enumeration and mapping. Limitation: active modes generate significant traffic and require explicit authorisation.
• Subfinder — Fast passive subdomain enumeration across many public data sources. Limitation: entirely dependent on source coverage and API keys, so results vary between runs.
• Nmap — Authoritative service and version detection during authorised active confirmation. Limitation: intrusive by default and easily misconfigured into disruptive scanning.
• Masscan — Very fast port sweeps across large address ranges for initial coverage. Limitation: speed causes packet loss and false negatives, and can overwhelm intermediate devices.
• httpx — Probes discovered hosts for web services and captures titles, headers and fingerprints. Limitation: only sees what responds, so it misses filtered and dormant services.
• Certificate Transparency monitors — Alert on newly logged certificates matching organisational patterns. Limitation: only covers publicly trusted issuance, so internal and private certificate authorities are invisible.
• Cloud provider asset inventory APIs — Authoritative enumeration of resources within known accounts and subscriptions. Limitation: only covers accounts you know about, which is the actual problem.
• DNS record monitoring and dangling detection scripts — Detect CNAME and alias records pointing at deprovisioned resources. Limitation: provider takeover behaviour changes, so detection logic needs regular revalidation.
• Secret scanning across public repositories — Finds credentials and internal endpoints leaked in public code. Limitation: high false positive rate and coverage limited to indexed public repositories.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

• Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
• DNS Audit — Bulk-resolves A/AAAA/MX/NS/TXT/CNAME/SOA records and stores them as observations, building passive DNS from your own collection.
• Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
• Detection Rules — Generates YARA, Sigma and Snort/Suricata logic from the selected indicators, ready to deploy.
• Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
• Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
• Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• Passive first, always. Everything discoverable without touching the target is lawful anywhere and leaves no trace, and it should be exhausted before a single active packet is authorised, because active probing changes both the legal position and the adversary awareness.
• The seed list is the whole capability. Discovery is only as complete as its starting points, and the assets that hurt you sit under a brand that legal knows about, an acquisition that finance knows about, and a domain that nobody in IT has heard of.
• An asset with no owner is a finding in itself. Disowned assets are consistently the highest risk category, because nobody patches them, nobody monitors them and nobody notices when they change.
• Reverse discovery from fingerprints beats name-based enumeration for shadow IT. Anything deliberately set up outside process will not carry the organisational naming convention, but it will still carry a recognisable header, certificate or favicon.
• Dangling DNS records deserve separate, urgent handling. Subdomain takeover is cheap for an attacker, immediately usable for phishing under your own name, and is one of the few exposures that can be fully fixed in minutes.
• Measure the rate at which new unknown assets appear, not the number of assets found. A capability that finds more every quarter without that rate falling is documenting a governance failure rather than fixing one.
• Validate every candidate against a second independent signal before it enters the inventory. False attribution of a third party asset to your own estate leads to unauthorised scanning, which is a legal problem rather than a data quality problem.
• Scan data has a vantage point and a collection date. Two commercial datasets disagree routinely on the same host, so absence from one corpus proves nothing and citing a snapshot date is part of the finding.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Attack Surface Intelligence is producing anything, and they are worth baselining before you change process or tooling.

• Rate at which previously unknown assets are discovered per quarter, which should decline as provisioning and decommissioning controls improve.
• Median time from an asset first becoming internet-reachable to it appearing in the attributed inventory with a named owner.
• Percentage of inventory entries carrying a named accountable owner, a business function and a data sensitivity rating rather than being unattributed.
• Median time from discovery of a dangling DNS record or exposed administrative interface to verified remediation, tracked separately from other findings.
• Proportion of remediation claims verified by re-testing rather than accepted on assertion, and the reopen rate on those verifications.
• Share of externally reported exposures, from Shadowserver or a researcher, that the internal capability had already identified before the report arrived.
• Number of active scans executed outside a documented authorisation, which should be zero and is a control failure rather than a performance measure.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

• Over-attribution: claiming shared hosting or CDN infrastructure as yours creates scan targets you have no authority to touch
• Treating raw discovery output as an inventory; without ownership attribution, findings never reach anyone able to remediate them
• Scanning on a slower cadence than your cloud deployment rate, so ephemeral exposure appears and vanishes between runs
• Excluding subsidiaries, joint ventures and recent acquisitions whose assets still carry your brand and your breach liability
• Missing dangling DNS records, where a deprovisioned cloud resource with a live CNAME is a subdomain takeover waiting to happen
• Chasing volume metrics, so ten thousand informational findings bury the single exposed administrative interface that matters

Legal and ethical considerations

Passive collection from public registries, Certificate Transparency and third-party scan data is generally lawful. Active probing is not. Port scanning, credential testing and content retrieval against assets you do not conclusively own may breach computer-misuse legislation and provider terms of service. Maintain written authorisation defining scope and permitted techniques, and re-verify ownership before every active step. For supplier assets, escalate contractually rather than testing directly. Registration and developer data encountered during discovery is personal data and carries retention and minimisation duties.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Attack Surface Intelligence, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 data points, 1 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Is passive discovery against another organisation lawful?

Querying public datasets such as Certificate Transparency, passive DNS, registry allocation records and existing internet-wide scan corpora involves no interaction with the target and is generally lawful, including for suppliers and acquisition targets. What changes the position is generating traffic to their systems. Port scanning, web crawling, credential testing and any form of probing can engage computer misuse offences in many jurisdictions regardless of whether damage results, and intent to help is not a defence. The practical rule is that passive research needs no permission, active testing needs written authorisation naming the scope, the window and the approver.

How do I find assets that use none of our naming conventions?

Stop looking for names and look for fingerprints. Deliberate shadow IT and legacy estate rarely carry the corporate naming pattern, but they usually carry something distinctive: a TLS certificate issued to an internal name, a specific HTTP header set, a favicon hash from the corporate template, a login page from a standard product build, or an error page with an internal contact address. Search internet-wide scan corpora on those features rather than on domain names. Also mine public code repositories and mobile application binaries for internal endpoints, which frequently reveal infrastructure that no DNS enumeration will reach.

How is this different from vulnerability scanning?

Vulnerability scanning tests assets that are already in the register for known weaknesses. Attack surface intelligence establishes what the register is missing. The two fail in different directions: a vulnerability programme with perfect coverage of a register that omits a third of the estate is measuring the wrong denominator. In practice attack surface work feeds the vulnerability programme by expanding its scope, and the handover point is the attributed inventory. Keep them organisationally distinct, because the incentive to report a high remediation percentage will otherwise quietly discourage discovery of assets that would worsen the number.

What is the right handling for an exposure found in a supplier estate?

Report it to the supplier through the contractual security contact, or to their published vulnerability disclosure address, with enough detail to reproduce and a clear statement of how you found it. Do not probe further to characterise the issue, do not access data, and do not publish. If the supplier is unresponsive and the exposure affects your data, escalate through contract management and consider notifying the relevant national CERT, which has established channels. Record the whole sequence, because if the exposure is later breached you will need to demonstrate that you identified it, reported it and escalated appropriately.

Do commercial attack surface platforms replace doing this yourself?

They accelerate discovery and are worth having, but they cannot do attribution, which is the part that determines whether the output is usable. A platform will show you assets that look related to your organisation; only you can determine which business unit owns each one, what data it holds and who fixes it. Platforms also disagree substantially with each other because their scan vantage points and seed logic differ, so treat any single vendor inventory as one input. The internal work that no product does is maintaining the seed list and resolving disowned assets.

How often should discovery run?

Certificate Transparency monitoring should be continuous, because a new certificate is often the first evidence of a new asset and appears within minutes of issuance. Passive expansion and reverse discovery are reasonable weekly. Authorised active confirmation is typically monthly for the core estate and immediately on any newly discovered asset. Quarterly sweeps are inadequate for any organisation with cloud self-service provisioning, since the mean time an unknown asset stays unknown then becomes six weeks. Set the cadence against how quickly your organisation can create new exposure, not against an audit calendar.

What do I do about assets carrying our brand that we do not control?

Inventory them separately and treat them as a distinct risk class, because you cannot remediate them technically. Typical cases are marketing agency microsites, regional distributor portals, event platforms and lapsed campaign domains. The controls available are contractual, through security requirements and a right to assess, and administrative, through brand protection and domain recovery processes for names that have lapsed. Lapsed domains that still receive traffic or still appear in printed material are the priority, since re-registration by a third party gives them a credible platform for fraud under your name.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

• NIST Cybersecurity Framework, whose identify function governs the requirement for a complete and maintained asset inventory.
• NIST SP 800-115 on technical security testing, which governs the planning, authorisation and conduct of active assessment activity.
• ISO/IEC 27001 Annex A controls on inventory of information and associated assets, which govern ownership and classification of discovered assets.
• CIS Critical Security Controls 1 and 2, which govern enterprise asset and software inventory as the foundational controls.
• The UK Computer Misuse Act 1990 and equivalent computer misuse legislation, which govern whether active probing of a third party system is lawful.
• RFC 6962 on Certificate Transparency, which governs the public logging behaviour that makes certificate-based discovery possible.
• ISO/IEC 29147 on vulnerability disclosure, which governs how exposure found in a third party estate should be reported.
• CISA Binding Operational Directive 22-01, which governs remediation timelines for known exploited vulnerabilities on internet-facing federal assets.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. Certificate Transparency logs search — Sectigo crt.sh. Public search interface over Certificate Transparency logs used for hostname discovery
2. Certificate Transparency — Certificate Transparency project. Specification and ecosystem documentation for public logging of certificate issuance
3. Internet-wide scan data — Censys. Host, service and certificate scan corpus used for reverse asset discovery
4. RIPEstat data service — RIPE NCC. Registry allocation, routing and reverse DNS data for verifying owned address space
5. Daily network reports — Shadowserver Foundation. Free reporting of exposed and compromised assets to verified network owners
6. Known Exploited Vulnerabilities catalog — Cybersecurity and Infrastructure Security Agency. Authoritative list of actively exploited vulnerabilities with remediation deadlines
7. Cybersecurity Framework — National Institute of Standards and Technology. Control framework whose identify function requires maintained asset inventory
8. Critical Security Controls — Center for Internet Security. Prioritised control set placing asset and software inventory as controls one and two
9. Open vulnerability database — OSV.dev. Package-level vulnerability data with precise affected version ranges
10. Application security guidance — OWASP Foundation. Community methodology and risk references for testing exposed web applications

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: runs continuous seed-driven discovery with ownership attribution and change alerting across your external estate. Explore the platform, or browse the rest of the library by following any tag above.