IP and Domain Attribution: Turning an Address into a Suspect

An IP address in a server log is a useful starting point for a cyber-crime investigation, but it is not a suspect. Converting that address into an identifiable individual requires understanding the allocation hierarchy behind every routable number, the legal mechanisms to compel disclosure at each layer, and several technical traps that have caused attribution errors in court.

How IP addresses are allocated: IANA and the regional registries

The Internet Assigned Numbers Authority (IANA), a function operated by ICANN, sits at the top of the global address-allocation hierarchy. IANA allocates large blocks of IPv4 and IPv6 space to five Regional Internet Registries: ARIN (North America), RIPE NCC (Europe, the Middle East, and parts of Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America and the Caribbean), and AFRINIC (Africa). Each RIR then sub-allocates to Internet service providers and, in some cases, to large organisations directly. The RIRs maintain public databases recording which organisation received each block and on what date.

To identify the ISP behind a suspect IP, query the appropriate RIR database via RDAP. The record returns the registered network block (the range of addresses assigned together), the name of the holding organisation, and an abuse contact address. That organisation is the party to serve with legal process for subscriber records. The RIR record does not tell you which individual was using the address at any particular moment; that step requires a separate request to the ISP.

Reading RDAP (and what WHOIS used to tell you)

ICANN formally sunset WHOIS for generic TLDs on 28 January 2025. The Registration Data Access Protocol (RDAP) is now the required replacement for gTLD registries and registrars, with interim exceptions for .com, .name, and .post. Unlike WHOIS, RDAP returns structured JSON over HTTPS, records precise event timestamps, and enforces tiered access: public queries return registrar name, registration and expiry dates, nameservers, and an abuse contact. Registrant identity fields are withheld unless the requestor holds an authenticated, accredited role under ICANN's access framework. For IP address blocks, the five RIRs are also transitioning their query interfaces to RDAP endpoints.

Investigators can use ICANN's own RDAP look-up at lookup.icann.org, or query the RIR endpoints directly for IP and autonomous-system records. RDAP responses include a "last changed" timestamp, which can help establish when registration details were altered.

Static versus dynamic addresses: why the timestamp is non-negotiable

A static IP is assigned to one account on a long-term basis. A dynamic IP is drawn from a shared pool at session start and returned when the session ends. ISPs reuse dynamic addresses continuously, so the same address may have belonged to dozens of different subscribers within a single month. The ISP's session, DHCP, or RADIUS logs map each address assignment to one account for a specific window of time. Without a precise timestamp, the query is unanswerable. Without a confirmed timezone, timestamps from a server in one country and logs in another will not align, producing an attribution mismatch.

1. Record the exact UTC timestamp. Capture the event time in Coordinated Universal Time as it appears in the original server or application log. Preserve the raw log line, not a screenshot.
2. Confirm the log source's timezone. Many servers log in local time rather than UTC. Establish whether the clock is UTC or a named timezone before making any conversion.
3. Note the source port. On networks using carrier-grade NAT, the source port combined with the IP and timestamp uniquely identifies a subscriber session (see CGNAT section below).
4. Hash the log file. Generate a cryptographic hash (SHA-256) of the original log file at the time of preservation. This supports integrity arguments in court.

From IP address to subscriber: the ISP request

Once you have the ISP identity from the RIR record and a verified timestamp, a formal legal demand to the ISP seeks the subscriber account that held the IP at that moment. The ISP looks up its own session logs and returns the account name and registered address, and often the equipment identifier (modem serial or MAC address) that held the lease. The account holder is not necessarily the perpetrator: it may be a business, a household, or a shared-access operator such as a cafe, hotel, or university. Each of those cases requires a further stage of inquiry at the premises or institution level.

CGNAT: when one public address conceals thousands of subscribers

Carrier-grade NAT (CGNAT) allows an ISP to share a single public IPv4 address across many subscriber connections simultaneously, using an internal addressing range reserved under RFC 6598 (the 100.64.0.0/10 block, standardised in April 2012). The public IP alone cannot identify which subscriber generated a specific connection. The ISP's NAT translation table records the mapping between the subscriber's internal address, the assigned source port, and the public IP, but only for the duration of the session.

When submitting a subscriber-identification request to an ISP operating CGNAT, always supply all five fields: source IP address, source port, destination IP address, destination port, and timestamp in UTC. Requests that supply only the source IP against a CGNAT network will return every subscriber who shared that address during the relevant window, which may number in the hundreds and renders the response unusable.

Sites and accounts behind a CDN

Content delivery networks act as reverse proxies: the IP address that appears in a victim's traffic logs or browser history may belong entirely to the CDN's own infrastructure, not to any server the suspect controls. Attributing that IP to the CDN tells investigators nothing about the origin server.

There are two investigative routes. The first is to issue legal process directly to the CDN provider for the account details and origin-server IP of the domain in question. CDN providers such as Cloudflare require valid legal process, for example a subpoena consistent with the Electronic Communications Privacy Act, before disclosing customer account information, with a narrow emergency exception for an imminent danger to life. (Mandatory reporting of child sexual abuse material to NCMEC is a separate statutory duty on US providers under 18 U.S.C. 2258A, not a discretionary policy exception.) The second route is independent technical identification of the origin: historical DNS records, certificate transparency logs, and server response headers from periods before the CDN was deployed sometimes reveal the underlying hosting IP. Both methods require moving past the proxied address.

Domain attribution: registrar, privacy proxies, and RDAP access

Domain registration data is held by the registrar (the company the customer bought the domain from) and the registry (the operator of the TLD). Before GDPR applied in May 2018, public WHOIS commonly showed the registrant's name, physical address, email, and telephone number. By January 2024, 58.2 percent of gTLD domain records were shielded by privacy-proxy services, up from 29.2 percent in November 2020, according to an Interisle Consulting Group study published through ICANN's Domain Name Industry Brief. Registrant identity has become the exception rather than the rule in public records.

Investigators have two formal routes to registrant identity. ICANN's Registration Data Request Service (RDRS), launched as a pilot in November 2023 and since extended, is a free ticketing system that routes requests for nonpublic gTLD registration data to participating registrars. It is open to law enforcement, intellectual property professionals, and cybersecurity specialists, but registrar participation is voluntary and disclosure is at each registrar's discretion. The second route is a direct legal demand to the registrar under the jurisdiction-appropriate mechanism (see the comparison table below). For country-code TLDs, contact the ccTLD registry or its designated law-enforcement liaison.

VPNs, proxies, and Tor: realistic limits

A commercial VPN service replaces the subscriber's IP with one from the provider's pool. If the provider retains connection logs, a legal demand in that provider's jurisdiction can yield the real IP and session timestamps. Providers that maintain genuine no-log policies will produce no identifying data, but the claimed policy should be tested against disclosed compliance reports and any prior legal proceedings involving that provider. In practice, supporting evidence from outside the network layer (account registration patterns, payment records, device fingerprints from non-VPN sessions) has supported attribution in convicted cases even where the VPN held no logs.

The Tor network routes traffic through a circuit of at least three relays. The last IP visible in a server log is the Tor exit node, not the user. Exit node IP addresses are publicly listed by the Tor Project, so an exit node IP can be confirmed as such quickly. Attribution back through Tor generally requires simultaneous traffic observation at both the circuit entry and exit, a capability outside routine policing. However, suspect activity conducted outside Tor, including account creation, email metadata, and device fingerprints, has contributed to attribution in major prosecutions.

Open proxies, residential proxy networks, and bulletproof hosting each add one or more intermediary layers, each in a potentially different jurisdiction. Each layer requires a separate legal demand.

Preservation: the most time-sensitive step

Connection-level logs at ISPs, CDN providers, registrars, and platforms are retention-limited. Many providers purge them within 30 to 90 days. A preservation request asks the holder to freeze the relevant records in place pending formal legal process, before that window closes. Preservation is faster to send than a production order and should be the first outbound communication once an IP or domain has been identified as relevant evidence.

1. Send the preservation request immediately. Contact the provider's legal or abuse address on the same day attribution work begins. Follow up any email with written confirmation referencing the specific data and date range.
2. Be precise in your request. Include the IP address or domain name, the specific date-time range in UTC, and the categories of data to preserve (session logs, account records, payment records, content where lawfully required).
3. Follow with formal legal process promptly. Preservation buys time; it does not compel production. Issue the appropriate subpoena, court order, or production order before the preservation window expires.
4. For foreign-held data, open the cross-border process in parallel. Formal mutual legal assistance can take many months to over a year. A preservation letter to the foreign provider, sent through the appropriate channel, can often be actioned long before a full request reaches a central authority.

Legal process: a comparative overview

Frequently asked questions

If the suspect used a no-log VPN, is attribution impossible? Not necessarily. Several providers that claimed no-log policies have complied with law enforcement demands when records did exist. More practically, most successful attributions in prosecuted cases drew on evidence outside the network layer: account registration details, payment records, device identifiers from sessions conducted without the VPN, and behavioural patterns. A single anonymisation layer rarely survives a thorough multi-source investigation.

I have a domain name but no IP address. Where do I start? Query RDAP via ICANN's look-up tool to identify the registrar, then approach that registrar through its published law-enforcement or abuse channel, or through ICANN RDRS if the registrar participates. If the domain resolves to CDN address space, identify the CDN and issue legal process to that provider. If it resolves to a hosting provider's block, an RIR RDAP query will identify that provider for a separate demand.

The IP traces to a university or hotel. What next? The ISP request will return the institution, not an individual. A second-stage request to the institution seeks its own internal DHCP or network access logs to identify which device held the internal address at the relevant time. Institutional log retention periods are frequently shorter than ISP retention periods, making immediate preservation critical at this stage.

Does the EU e-evidence Regulation already apply? Regulation (EU) 2023/1543 entered into force on 18 August 2023 but its binding operative articles apply from 18 August 2026. Until that date, cross-border evidence requests within the EU continue under existing mutual legal assistance arrangements and the Budapest Convention. Investigators in EU member states should familiarise themselves with the new order forms and the tiered authority requirements ahead of the 2026 transition.

Hero image: rackmount Ethernet switches and patch panels by Dsimic, via Wikimedia Commons, CC BY-SA 4.0.