subnethistory.

How to investigate an IP address: a repeatable method

6 min read ·

An address turns up in a log, an alert, or an abuse report, and the pressure is to say something about it immediately. An address on its own is a lead, not an answer. Here is a procedure that turns it into one: what the address is, who routes it, what it has been doing, what has changed, and, just as important, the point where the evidence runs out.

A dated trail of events on one address: registration, announcement, an origin change, a flag, and a change we recorded registered announced origin change flagged recorded
One address, its events placed on a single dated line: the registry record, the first announcement, an origin change, a reputation flag, and a change the archive noticed itself. Attribution is a question about this sequence, not about any one point on it.

Start with what it is, not what it did

The first question is the most boring one, and skipping it is how investigations go wrong. Before anything else, establish what kind of address this is.

A surprising share of the addresses that reach an analyst are not public internet at all. Private ranges such as 10.0.0.0/8 and 192.168.0.0/16, loopback, carrier-grade NAT space, and multicast have no registry holder and are never routed globally, so an address out of them means something happened inside a network, not that a stranger reached in. Recognising reserved space in the first five seconds saves an hour of chasing an owner who does not exist. If the address is public, then it has a holder, a route and a history, and the rest of the procedure applies.

Registration: read it, then distrust it

Pull the registration record: the regional internet registry publishes the block the address sits in, the holder, the country, the allocation and last-changed dates, and the abuse contact. This is where most people stop, and it is the least reliable part of the whole picture, so read it for what it is worth and no more.

The abuse contact and the covering block are the genuinely useful outputs; the first is where a report should go, the second is the unit almost every other signal is keyed to. But the net name and description are typed in by the holder and prove nothing about behaviour. Two dates are worth pausing on: a very recent allocation, or a fresh change on space that is otherwise old, is the kind of thing that becomes meaningful once you reach the history. Read registration as a claim, not a conclusion.

Note which block actually contains the address. A large allocation is often carved into smaller ones with different sub-holders, and attributing behaviour to the wrong boundary, the whole provider for something one customer did, is the most common attribution error there is.

Routing: who is announcing it now

Registration is paperwork. Routing is what is happening. Check whether the covering prefix is actually announced, by which origin autonomous system, and whether that announcement is authorised by RPKI.

The interesting cases are the mismatches. Space that is registered to one party and announced by an unrelated one, an announcement that RPKI marks invalid, or several origins claiming the same space at once, are all worth a hard look, because they are the shapes that hijacks and leaks make. A valid, single, long-standing announcement by the party you would expect is the quiet answer, and quiet is usually the truthful one.

The network behind it

An address is a resident of a network, and the network is often more informative than the address. Pivot from the origin AS to the operator behind it and read it as its own subject: who runs it, what else it announces, who its transit providers and customers are, and what reputation its space carries as a whole.

This is what turns a single hostile address into context. An address inside a mainstream consumer ISP is most likely one compromised or misused customer connection. The same behaviour from a network whose space is broadly flagged, or that exists mainly to announce blocks with no customers of its own, means something different about how much to generalise from the one address to the range around it.

History: what changed and when

Everything to this point is a snapshot. The question that usually matters, whether the address is what it was when the event you are investigating happened, is a question about time.

Put the dated facts on one line: when the block was registered and last changed, the windows during which each origin announced it, any transfer between holders, and any change a watcher recorded by comparing the record against its earlier self. A reputation reading is only meaningful with the date it was taken, because an address becomes a proxy the day someone points proxy software at it and stops being one the day they stop. An address that was quiet three months ago and flagged last week is a different story from one that has been flagged for years, and only the timeline tells them apart. The single most useful habit in IP investigation is refusing to read today's reputation onto last month's event.

Behaviour: anonymised, flagged, or quiet

Now the behavioural layer, read with the timeline in hand. Independent feeds report whether addresses in and around this one operate as VPN, proxy, Tor or datacenter, whether they carry abuse or blocklist history, and at what risk. An active measurement can go further and confirm directly whether the address is answering as a proxy, which is a fact rather than a classification.

Two habits keep this layer honest. First, when feeds disagree, record it as contested rather than picking the answer you expected; the disagreement is often the most informative thing on the page. Second, weigh the address against the block. One flagged host is noise; a dense cluster of flagged addresses across the surrounding range is a finding, and it changes whether the one address in your log is an accident or a representative sample.

Attribution ends where the evidence does

The hardest discipline in this work is naming the point where the evidence stops, and saying so in the write-up.

Registry records are self-reported and describe a holder, not a user. Routing observation sees what collectors' peers see, which is most of the internet but never all of it. Sampling covers the addresses someone has actually checked; the rest of the block is unknown, and unknown is the correct word for it rather than clean. None of these tell you who was at the keyboard, and an address behind a shared VPN, a carrier NAT, or a residential proxy may represent thousands of unrelated people. A good investigation ends with a defensible statement about the address and its network, an explicit note of what could not be determined, and a reputation reading stamped with the date it was true. That is a stronger result than a confident guess, and it is the one that survives being questioned later.

A checklist you can run every time

  • Is it public space at all, or reserved? Reserved space has no owner to chase.
  • What is the covering block, and who is the abuse contact? Attribute to the right boundary.
  • Is it announced, by which origin AS, and does RPKI validate? Watch for mismatches.
  • What is the network behind it, and what does its space look like as a whole?
  • Put the dates on one line. Does today's reputation actually apply to the event you care about?
  • Read behaviour against the block, keep contested verdicts contested, and stamp every reading with its date.
  • Write down what you could not determine. That sentence is part of the finding.

Any address mentioned here can be looked up on the front page, which merges the registration, the routing, the network, the timeline and the reputation into one report, and says plainly, with a date, where each claim comes from and when nobody has checked something.