Network Intelligence (NETINT): Intelligence Discipline Guide

Every packet on the internet is routed by an announcement someone made, on trust. Network intelligence reads those announcements, and the exposed services sitting behind them.

What Network Intelligence is as a discipline

Network intelligence is the analysis of internet infrastructure at the level of addresses, autonomous systems and routing. It combines regional registry allocation records, BGP routing tables and update streams, internet routing registry and RPKI objects, active measurement such as traceroute and reachability testing, and internet-wide service scan data. Analysts use it to determine who controls a block of address space, how traffic reaches it, which hosting providers an adversary favours, and when routing changes indicate hijack, leak, outage or filtering. It is the substrate beneath domain and certificate analysis.

Sub-methods include ASN profiling, covering what an operator announces, who peers with it and its abuse history; routing surveillance, detecting more-specific announcements, origin changes and RPKI-invalid routes; hosting characterisation, identifying abuse-tolerant providers; and service mapping across a netblock using scan data. Maturity moves from ad-hoc lookups to continuous monitoring of your own prefixes and of adversary-associated address space, with alerting on route and exposure change.

Why it matters

Network intelligence answers who really controls an address and whether the path to it changed. Geolocation databases are commercial estimates and frequently wrong; allocation and routing data is authoritative about control. It detects prefix hijacks and route leaks affecting your own space, which no endpoint telemetry can see. It also reveals hosting concentration behind adversary infrastructure, letting you scrutinise or block at ASN granularity instead of chasing individual addresses that rotate hourly.

What analysts actually look for

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

• Autonomous system numbers, announced prefixes and origin changes over time, timestamped from archived BGP update streams
• Registry allocation and transfer records establishing who was assigned an address block and when, independent of geolocation guesses
• More-specific prefix announcements and unexpected origin ASNs indicating hijack, route leak or legitimate traffic engineering
• RPKI validation state showing whether a route is authorised by the address holder and which invalid routes are propagating
• Peering and transit relationships revealing the upstream providers who can actually be approached for abuse remediation
• Open service inventories per netblock: banners, TLS configuration, protocol versions and exposed management interfaces
• Reverse DNS naming conventions across a block, revealing hosting product lines, customer segmentation and physical geography
• Abuse density per ASN measured by blocklist appearance rate, characterising providers that tolerate criminal hosting

Where the data comes from

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

• RIPEstat — Consolidated routing, allocation, registration and measurement data for any prefix, address or ASN
• BGPView — ASN, prefix, peering and upstream relationship lookups with a straightforward API for bulk work
• RIPE RIS and RouteViews — Historical and near-real-time BGP update archives from many collectors for route change analysis
• Team Cymru IP-to-ASN — Free authoritative origin ASN lookup service designed for bulk resolution of address lists
• Shodan — Internet-wide service banners and exposure inventory queryable directly by ASN or netblock
• Censys — Parsed scan data with certificate, software and protocol detail across large ranges of address space
• RIPE Atlas — Distributed active measurement for traceroute, latency and reachability testing from thousands of vantage points
• Cloudflare Radar — Aggregate traffic, routing and outage observations at country and network level with historical series

A working method

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

1. Baseline your own space — Document every prefix you hold, its correct origin ASN and its ROA state. Hijack cannot be detected without a documented baseline.
2. Resolve address to control — Map observed addresses to origin ASN, allocation holder and hosting product rather than trusting geolocation attributes as fact.
3. Monitor routing continuously — Watch BGP updates for your prefixes and adversary-associated space, alerting on origin change, more-specifics and RPKI invalids.
4. Characterise the host network — Profile the ASN by size, customer type, abuse history and upstreams, then decide whether to act at address, prefix or provider level.
5. Correlate service exposure — Pull scan data across the block to see what else the operator runs and whether the infrastructure is dedicated or shared.
6. Measure the path — Use distributed traceroute to confirm reachability, detect filtering or interception, and independently validate outage and disruption claims.
7. Escalate at the right layer — Take evidenced abuse reports to the upstream or registry where warranted, and block at the narrowest scope that achieves the effect.

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.

Related disciplines

• Attack Surface Intelligence — Your Own Exposed Attack Surface
• 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

Inside the platform: where Network 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=NETINT — Discipline hub
• source-catalog.php?disc=NETINT — Source catalogue filtered to this discipline
• 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. Baseline your own space 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. Monitor routing continuously 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. Escalate at the right layer 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 Network 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 use network intelligence to understand the communications terrain: who controls the address space and routing in an area of operations, which providers carry which traffic, where the physical and logical chokepoints sit, and how resilient a partner or host nation network is. Products support cyber terrain mapping, communications planning, resilience assessment for supported infrastructure and force protection where a provider outage would affect operations. Passive registry and routing analysis generates no target contact, which is why it is available where other techniques are not. Constraint: active measurement into foreign networks requires legal clearance, and analysis of civilian communications infrastructure carries protections that must be reflected in any product touching targeting.

🕵 National intelligence

National services use routing and allocation data as a continuous, entirely passive collection stream. Requirements typically concern infrastructure ownership and control, dependency and chokepoint analysis, detection of routing manipulation such as hijacks and deliberate leaks, and identification of hosting providers habitually used by adversaries. The data is open and global, which makes it exceptionally useful for cueing and for corroborating reporting from protected sources. Fusion with scan, certificate and passive DNS data resolves ownership questions that registry records alone cannot. Handling separates the source, which is public, from the target and the requirement, which reveal collection priorities and are protected accordingly.

👮 Law enforcement

Investigators use network intelligence to identify who is responsible for an address or a prefix and therefore where legal process should be directed. Registry allocation records establish the holder of an address range and the relevant regional registry, and routing data establishes who was announcing it at a given time, which matters because attribution by address alone is unsafe when prefixes are reassigned, hijacked or shared. Subscriber identification requires a production order to the provider, and cross-border requests need mutual legal assistance. Evidential use requires the record with its retrieval time, because allocation and routing state changes and historical views are not always reconstructable later.

🔍 Private investigation and corporate security

Corporate practitioners use network intelligence for asset scoping, hosting due diligence, supplier resilience assessment and abuse handling. Determining which prefixes your organisation actually announces is a prerequisite for authorised scanning, and understanding which upstream providers your key suppliers depend on is a real continuity finding. Passive analysis of registry and routing data about third parties is lawful, since the data is published as part of internet operations. Active measurement such as traceroute is generally acceptable at low volume, but scanning services in a third party network is not without written authorisation. Findings support contractual resilience requirements and abuse escalation.

📰 Journalism and OSINT media

Journalists use network intelligence to evidence stories about censorship, shutdowns, traffic interception and infrastructure ownership. Routing and measurement data provides independently verifiable evidence that a country disconnected, that traffic was diverted, or that a specific provider blocked a service, and much of it comes from projects that publish their raw observations. Verification requires citing the measurement platform, the vantage points and the timestamps, and having the interpretation checked by an independent network engineer. Distinguish deliberate manipulation from misconfiguration, since route leaks caused by error look similar to hijacks and the difference is the entire story.

🌍 NGO, humanitarian and human rights

Digital rights and humanitarian organisations use network intelligence to document internet shutdowns, throttling and censorship, and to assess connectivity for programme delivery. Measurement platforms with volunteer probes provide the evidentiary basis for shutdown reporting used in advocacy and litigation, and routing data shows precisely when and how a network was withdrawn. Do-no-harm applies to the volunteers who host measurement probes, who can face real risk in repressive states, so their identification must be protected and consent must be informed about that risk. Documentation is prepared to accountability standards for use before courts and United Nations mechanisms.

🎓 University and research

Researchers use routing, allocation and measurement data to study internet topology, resilience, routing security adoption, censorship and interconnection economics. Methodology must state the vantage points, because routing observation is fundamentally partial and different collector sets see different subsets of the internet, and results that ignore this are unreliable. Reproducibility requires archiving the specific data snapshots, since routing archives are large and views change constantly. Ethics review applies to active measurement, particularly where probes are hosted by volunteers in repressive jurisdictions or where measurement could be attributed to an individual. Cite the collector, the dataset and the observation window explicitly.

Playbook: working Network 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 — Define the network question

Establish precisely what must be determined: who controls this address, what does this organisation announce, is this prefix being hijacked, what does this network depend on, or is this country experiencing a shutdown. These require different data and different vantage points. Fix the time period, because routing state at the moment of an incident is what matters and it is not the same as today. A good output is a written question naming the addresses, prefixes or autonomous systems in scope and the period. Stop when the question can be answered from a specific dataset rather than by general exploration.

Phase 2 — Resolve allocation and holder

Establish the registry chain for the addresses in question: which regional registry allocated the space, to which organisation, when, and whether it has since been transferred or sub-allocated. Registry records show the holder of record, which may be a hosting provider rather than the user, so distinguish the allocation holder from the operational user. Record the retrieval time, since records change on transfer. A good output is an allocation record identifying the responsible organisation and the abuse contact. Stop when you can name the entity legally responsible for the space and the route to contact it.

Phase 3 — Establish routing origin and history

Determine which autonomous system originates the prefix now and originated it during the period of interest, using routing collector archives rather than a live query. Note the specific prefix length announced, since a more specific announcement inside a legitimate aggregate is a classic hijack signature. Check for multiple origins for the same prefix, which is either a legitimate multi-origin arrangement or an anomaly. A good output is an origin history with timestamps and collector attribution. Stop when the origin for the period is established or the disagreement between collectors is documented.

Phase 4 — Map the upstream and peering topology

Establish who the network buys transit from, who it peers with, and how many independent paths exist to it. This determines resilience and identifies the chokepoints whose failure or interference would isolate the network. Use routing observation rather than published claims, since business relationships and actual paths differ. Note geographic concentration, single points of interconnection and dependence on a single submarine cable or exchange. A good output is a topology and dependency picture with the single points of failure named. Stop when the paths that matter for the question are characterised.

Phase 5 — Validate routing security posture

Check whether the prefix has valid route origin authorisations under the resource public key infrastructure, whether the announcing network signs and validates, and whether internet routing registry objects exist and are consistent. Discrepancies between registry objects, route origin authorisations and observed announcements are the standard indicator of either hijack or long-standing misconfiguration. A good output is a validation state per prefix with the specific inconsistencies listed. Stop when each prefix in scope is classified as valid, invalid or not found with the evidence recorded.

Phase 6 — Detect and characterise anomalies

Where a routing anomaly is suspected, establish what happened precisely: a more specific prefix announced by an unauthorised origin, an origin change, a path with an implausible autonomous system sequence, or a leak where a customer re-announced transit routes. Establish start and end times and which collectors observed it, since partial visibility is normal. Then determine impact: what traffic would have been affected and for how long. A good output is a characterised incident with timing, scope and observed impact. Stop when the anomaly is described in terms an affected network could verify independently.

Phase 7 — Distinguish attack from error

Most routing anomalies are misconfiguration rather than malice, and the distinction is the whole finding. Look at duration, whether the announcement was corrected quickly, whether the announcing network has a history of similar errors, whether the affected prefixes are commercially or strategically interesting, and whether traffic was actually diverted through infrastructure capable of interception. Consult the networks involved where appropriate. A good output is an assessment with the alternative explanation stated and the discriminating evidence identified. Stop when the assessment can defend the characterisation against a competent operator.

Phase 8 — Correlate with service-level evidence

Routing observation shows reachability at the network layer; it does not show whether a service worked. Correlate with active measurement of reachability from multiple vantage points, scan data showing services responding, and application-level testing where available. This matters especially for shutdown and censorship work, where blocking is often applied at the resolver or application layer with routing untouched. A good output is a combined picture stating what was and was not reachable at each layer. Stop when the layer at which the disruption occurred is identified.

Phase 9 — Use measurement platforms with care

Where active measurement is needed, use distributed measurement platforms rather than probing from a single point, since a single vantage point cannot distinguish a local problem from a global one. Respect the constraints of the platform and the safety of probe hosts, particularly in repressive jurisdictions where hosting a probe carries personal risk. Record the probes used, their locations and the measurement times. A good output is a multi-vantage measurement with the probe set documented. Stop when the observation is consistent across enough independent vantage points to support the claim.

Phase 10 — Attribute infrastructure responsibly

Combine allocation, routing, scan, certificate and passive DNS evidence to determine who operates a given piece of infrastructure, distinguishing the hosting provider, the reseller and the end user. Bulletproof and abuse-tolerant hosting complicates this deliberately. Never attribute activity to an organisation solely because its address space was used, since shared hosting, compromised servers and reassigned addresses are the norm. A good output is an attribution with the layer of responsibility explicitly identified. Stop when the responsible party for abuse handling is identified and the end user question is either resolved or referred to legal process.

Phase 11 — Act through operator channels

Route findings to the parties who can fix them: the announcing network, the upstream transit providers, the regional registry where allocation misuse is involved, national CERTs and the relevant operator community lists. Supply the specific prefixes, timestamps and collector evidence so the recipient can verify without repeating your work. For your own prefixes, publish route origin authorisations and adopt routing security practice so future anomalies are automatically invalid. A good output is a notification with a tracked outcome. Stop when the announcement is withdrawn or the responsible party has responded.

Phase 12 — Monitor continuously

Set alerting on your own prefixes for unexpected origins, more specific announcements and sudden path changes, and on key dependencies for availability changes. Routing hijacks are often short, so periodic manual checking misses them entirely. Record detections with their collector evidence for later analysis. A good output is a monitoring configuration with measured detection latency and a low enough false positive rate that alerts are investigated. Stop tuning when a genuine origin change on your own space is detected and escalated within minutes.

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
RIPEstat	Open	Query interface over registry allocation, routing history, reverse DNS, geolocation and abuse contact data for addresses and prefixes.	Primary lookup for allocation holder, announcement history and abuse contact for any address or prefix.
RIPE NCC	Open	Regional internet registry for Europe, the Middle East and Central Asia, publishing allocation policy, registry data and routing registry objects.	Authoritative allocation and transfer records plus policy defining what registry data means.
ARIN	Open	Regional internet registry for North America publishing allocation records, routing registry objects and transfer history.	Authoritative allocation and holder data for North American address space and autonomous system numbers.
APNIC	Open	Regional internet registry for the Asia Pacific region publishing allocation data, routing registry objects and research on address usage.	Authoritative allocation records for Asia Pacific space plus published research on routing and address behaviour.
BGPView	Open	Interface linking organisations, autonomous systems, prefixes, upstream and downstream relationships and observed routing data.	Rapid enumeration of prefixes and peering relationships for an organisation during scoping and dependency analysis.
RouteViews	Open	Long-running project archiving routing tables and update streams from collectors peered with many networks worldwide.	Authoritative historical routing archive for reconstructing origin and path state at the time of an incident.
RIPE RIS	Open	Routing information service collecting and archiving routing updates from collectors placed at exchanges globally.	Independent collector set for corroborating routing observations and measuring the visibility of an anomaly.
RIPE Atlas	Registration	Global network of measurement probes supporting traceroute, ping, DNS and TLS measurements from thousands of vantage points.	Multi-vantage active measurement establishing reachability and path changes independently of routing observation.
Team Cymru	Open	Provider of the IP to autonomous system mapping service and bogon reference data used widely in network operations.	Bulk mapping of addresses to originating networks for attribution and for classifying large observation sets.
IANA	Open	Registry of address space delegations to regional registries, autonomous system number ranges, protocol parameters and root zone data.	Establishes which regional registry is authoritative for a given address range before any lookup is attempted.
MANRS	Open	Initiative defining routing security norms including filtering, anti-spoofing, coordination and validation, with participant listings.	Benchmark for assessing whether a network follows accepted routing security practice during resilience assessment.
Censys	Registration	Internet-wide scan dataset of hosts, services, certificates and software banners with historical snapshots by address.	Characterises what is actually running in a prefix, supporting attribution of hosting and identification of exposure.
Shodan	Registration	Internet-wide service scanning platform indexing banners, protocols and device metadata with historical records.	Identifies device and service populations within a network, including exposed infrastructure and control systems.
Shadowserver	Registration	Non-profit scanning and sinkhole operation providing free daily exposure and compromise reporting to verified network owners.	External reporting on compromised and exposed hosts within your own prefixes without generating your own traffic.
GreyNoise	Registration	Classification of internet-wide scanning and exploitation traffic, distinguishing mass background activity from targeted behaviour.	Determines whether observed traffic from a network is indiscriminate scanning or something requiring investigation.

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 Network Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Routing archive query tools — Retrieve historical routing tables and updates from collector archives for incident reconstruction. Limitation: collector coverage is partial, so an anomaly may be invisible to your chosen collectors.
• RIPE Atlas measurement API — Schedule traceroute, ping and DNS measurements from thousands of distributed probes. Limitation: probe distribution is uneven and sparse in exactly the regions most often studied.
• whois and RDAP clients — Retrieve allocation and holder records directly from regional registries. Limitation: records reflect the allocation holder, not necessarily the operational user of the space.
• RPKI validators — Check route origin authorisations against observed announcements to classify validity. Limitation: not found is common and is not the same as invalid.
• Traceroute and path analysis tools — Establish observed forwarding paths and identify where a path changes or breaks. Limitation: asymmetric routing and filtering make single-direction traceroute misleading.
• BGP monitoring and alerting services — Alert on unexpected origins and more specific announcements for your own prefixes. Limitation: short hijacks can complete before an alert is actioned.
• Internet-wide scan platforms — Characterise what services exist in a prefix and how they change over time. Limitation: snapshots lag reality and vantage points differ between providers.
• Network topology visualisation tools — Render autonomous system relationships and dependency structures for analysis and briefing. Limitation: inferred business relationships are estimates, not facts.

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:

• Routing observation is fundamentally partial. Every collector sees only what its peers announce to it, so absence of an anomaly in one archive is not evidence it did not happen, and multi-collector corroboration is the baseline standard.
• Distinguish the allocation holder from the operational user. Registry records name who holds the space, which is very often a hosting provider several layers removed from whoever was actually using the address.
• A more specific prefix announced by an unexpected origin is the classic hijack signature, because longest prefix match means the more specific announcement wins regardless of the legitimacy of the aggregate.
• Most routing anomalies are misconfiguration, not attack. Duration, speed of correction, the announcing network history and whether traffic actually traversed interception-capable infrastructure are what distinguish the two, and getting it wrong is expensive.
• Never attribute activity to an organisation solely because its address space was involved. Shared hosting, compromised servers, dynamic reassignment and resale mean address-based attribution without corroboration is unsafe in every context.
• Routing reachability is not service availability. Censorship and shutdowns are frequently implemented at the resolver or application layer with routing untouched, so a clean routing picture does not mean users could reach anything.
• Publish route origin authorisations for your own space and validate on your own network. It is the single control that converts a future hijack of your prefixes from a business problem into an automatically invalid announcement.
• Record collector, vantage point and timestamp with every routing claim. Routing state is not reconstructable from a live query, and a claim without its observation context cannot be verified by anyone else later.

Measuring whether it is working

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

• Proportion of organisational prefixes covered by valid route origin authorisations, and the proportion of upstream providers performing validation.
• Median time from an unexpected origin or more specific announcement affecting your space to detection and to escalation with the upstream provider.
• Number of single points of failure identified in critical network dependencies and the proportion subsequently mitigated with an independent path.
• Share of routing findings corroborated across at least two independent collector sets before being reported.
• Rate at which anomalies were correctly characterised as misconfiguration or malice, measured against the eventual operator explanation.
• Percentage of address attributions in issued products that identify the layer of responsibility rather than naming an organisation from the allocation record alone.
• Coverage of active measurement vantage points for the regions of interest, with gaps explicitly recorded rather than silently assumed away.

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

• Treating IP geolocation as fact when it is a commercial estimate, an error that has caused real-world harm to uninvolved people
• Blocking an entire ASN because of a handful of malicious hosts, cutting off legitimate customers on shared infrastructure
• Assuming an address stays with one tenant when cloud and hosting addresses recycle within hours, making timestamps mandatory
• Reading a single BGP collector as global truth, when route visibility differs substantially between vantage points
• Confusing carrier-grade NAT egress addresses with individual subscribers, producing confident but false attribution of activity
• Ignoring IPv6, where allocation sizes and address rotation make single-address indicators nearly useless without prefix aggregation

Legal and ethical considerations

Passive use of routing, allocation and published scan data is lawful and expected. Active measurement needs care: traceroute and reachability testing are broadly accepted, but port scanning and service interrogation against third-party networks may breach computer-misuse law and provider terms in several jurisdictions. Address data can constitute personal data under GDPR where it identifies a subscriber, so purpose limitation and retention rules apply. Abuse escalations to upstreams and registries should carry evidence and timestamps and must never be used to pressure a provider without substantiation.

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 Network 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 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Can I identify who used an IP address at a given time?

Not from public data. Registry records identify the organisation holding the allocation, which is frequently a hosting or access provider, and routing data identifies the network announcing the prefix. Mapping an address at a specific time to a subscriber or a customer requires the provider internal records, which are obtained through a production order or equivalent legal process, and cross-border through mutual legal assistance. Preserve early, because provider retention periods are finite and often short. Geolocation databases are commercial estimates and are frequently wrong at city level, so they should never be presented as establishing a location.

How do I tell a hijack from a misconfiguration?

Look at behaviour rather than at the announcement alone. Hijacks tend to be short, targeted at commercially or strategically valuable prefixes, and sometimes involve paths that route traffic through infrastructure capable of interception before returning it. Misconfigurations tend to be broader, less selective, corrected within hours once the operator is told, and consistent with a known error pattern such as a filter failure or a customer re-announcing transit routes. Check the announcing network history and ask them. State the alternative explicitly in your assessment, because publicly calling an error an attack has real consequences.

Why do different routing sources disagree?

Because each collector only sees what its peers choose to announce to it, and no collector sees the whole internet. A short or geographically limited announcement may be visible to a handful of peers and invisible everywhere else. This is a property of the system, not a data quality problem. The correct practice is to consult more than one collector project, report which collectors observed the event and which did not, and treat the observation breadth as part of the finding, since a hijack visible globally is a materially different event from one visible at two collectors.

Is running traceroute against a third party lawful?

Generally yes at normal volumes, since traceroute uses ordinary traffic and is fundamental to internet operations, and distributed measurement platforms operate on that basis. What changes the analysis is intensity and intent: high-rate probing, port scanning, service enumeration and anything that could degrade a service can engage computer misuse and unauthorised access provisions. Use established measurement platforms where possible, keep volumes low, identify your measurement traffic where the platform supports it, and get written authorisation before any activity that goes beyond reachability testing into service assessment.

What does route origin validation actually protect against?

It cryptographically associates a prefix with the autonomous system authorised to originate it, so a validating network can reject an announcement from an unauthorised origin. That defeats the common origin hijack. It does not validate the rest of the path, so path manipulation attacks remain possible, and it only helps where the networks between you and the attacker actually validate, which is now common but not universal. Publishing authorisations for your own space costs little and is worth doing regardless, because it converts a hijack of your prefixes into an announcement that a growing majority of networks will drop.

How do I evidence an internet shutdown?

Combine layers. Routing archives show whether prefixes were withdrawn and when, with collector attribution and timestamps. Distributed active measurement shows loss of reachability from independent vantage points. Traffic observation from platforms that publish aggregate country-level data corroborates the scale. Application-level testing shows whether specific services were blocked while general connectivity continued, which is a different and very common pattern. Report all of it with timestamps in a stated timezone, and protect the identity of any in-country probe hosts, who face real risk in exactly the jurisdictions where shutdowns occur.

How much does address geolocation matter?

Less than people assume, and it is frequently wrong. Commercial geolocation databases infer location from registry data, routing, latency and self-reported information, and can be wrong by hundreds of kilometres or attribute an entire country of users to a single point, which has caused real harm to residents at default coordinates. Use it as a weak indicator to be corroborated, never as evidence of where a person was. Where location genuinely matters, the reliable routes are provider records obtained under legal process and, for infrastructure, active latency measurement from known vantage points.

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:

• RFC 4271 defining the Border Gateway Protocol, which governs how routing announcements are made and propagated between networks.
• RFC 6480 and the resource public key infrastructure specifications, which govern cryptographic authorisation of prefix origination.
• RFC 6811 on prefix origin validation, which governs how a router classifies an announcement as valid, invalid or not found.
• MANRS routing security norms, which govern the filtering, anti-spoofing, coordination and validation practices expected of network operators.
• Regional internet registry allocation and transfer policies, which govern who holds address space and how registry records are maintained.
• RFC 7454 on BGP operations and security, which governs operational practice for securing routing configuration.
• The Budapest Convention on Cybercrime, which governs cross-border preservation and production requests to network operators.
• ISO/IEC 27037 on digital evidence handling, which governs preservation of routing and registry observations for evidential use.

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. RIPEstat data service — RIPE NCC. Registry, routing history and abuse contact data for addresses and prefixes
2. Routing Information Service — RIPE NCC. Archived routing updates from collectors placed at exchanges worldwide
3. RouteViews routing archive — University of Oregon RouteViews Project. Long-running archive of routing tables and updates from global collectors
4. RIPE Atlas measurement network — RIPE NCC. Distributed probe network for multi-vantage active measurement
5. IP to ASN mapping service — Team Cymru. Bulk mapping of addresses to originating autonomous systems and prefixes
6. Number resource delegation records — IANA. Authoritative delegation of address space and autonomous system numbers to regional registries
7. Routing security norms and participant data — MANRS. Accepted operator practices for filtering, validation and coordination
8. Registry data and allocation policy — RIPE NCC. Authoritative allocation records and the policy defining their meaning
9. Daily network exposure reporting — Shadowserver Foundation. Free reporting of exposed and compromised hosts to verified network owners
10. Internet-wide scan data — Censys. Host and service observations used to characterise activity within a prefix

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: monitors your prefixes and ASNs with hijack alerting, ownership resolution and exposure correlation. Explore the platform, or browse the rest of the library by following any tag above.