Enriching an IP address with free tools

IP addresses are the most common indicator in a SOC queue and the least reliable one. The same address can be a residential customer today, a VPN exit tomorrow and a cloud VM rented by someone else next week. Enrichment does not tell you whether an IP is “bad”. It tells you what kind of address it is and what others have seen from it, so you can decide what the connection in your logs most likely was.

This is part two of the OSINT series; the ground rules — passive lookups first, defang before you paste — are in OSINT for defenders: the ground rules before the tools. Every tool below is passive: nothing touches the address itself.

Question 1: who owns it?

Ownership tells you more than reputation does. A connection to an address in Microsoft’s or Amazon’s ranges means something very different from one to a small hosting provider or a residential ISP.

RDAP. The Registration Data Access Protocol is the structured successor to WHOIS, and the regional internet registries serve IP data over it. The rdap.org bootstrap service redirects your query to the right registry:

curl -sL https://rdap.org/ip/203.0.113.45 | jq '{name, handle, startAddress, endAddress, country}'

The answer gives the allocation (network range and holder) and usually an abuse contact. A small allocation registered to a hosting company tells you a customer of that company used the address, not who the customer was.

ASN lookup. The Autonomous System Number shows which network announces the address. Team Cymru runs a free IP-to-ASN service over whois:

whois -h whois.cymru.com " -v 203.0.113.45"

IPinfo Lite. IPinfo’s free plan gives country-level geolocation and the ASN name and domain, with no monthly request cap on the API. City-level location, privacy detection (VPN, proxy, Tor) and company data are paid features. Country is usually all triage needs; city-level geolocation is an estimate that is often wrong for mobile and cloud addresses anyway.

Is it a cloud provider or Tor?

The large clouds publish their address ranges as machine-readable files, which makes “is this AWS?” a lookup rather than a guess:

Provider	Published ranges
Amazon Web Services	https://ip-ranges.amazonaws.com/ip-ranges.json
Google Cloud	https://www.gstatic.com/ipranges/cloud.json
Microsoft Azure	Azure IP Ranges and Service Tags JSON, published weekly on the Microsoft Download Center

The Tor Project publishes current exit nodes at https://check.torproject.org/torbulkexitlist. A logon from a Tor exit is worth a closer look whatever else the address’s reputation says.

A cloud address in your alert narrows the question but does not answer it. Attackers rent cloud VMs too; what matters is whether your users or systems have a reason to talk to that service.

Question 2: has anyone reported it?

AbuseIPDB collects abuse reports from administrators and automated systems: brute-force attempts, port scans, web attacks. The free plan includes 1,000 checks and reports per day. Read three things in the result, not just the confidence score:

• When the reports were made. Thirty reports from last year on a cloud address say little about who holds it today.
• What was reported. SSH brute force against someone’s server is a different story from a phishing site.
• How many distinct reporters. One noisy reporter can push a score up on its own.

VirusTotal shows an IP’s detections from URL and domain blocklists and, more usefully, its relations: domains that resolved to it, files that contacted it, URLs hosted on it. The relations often explain an address faster than its reputation does. The public API allows 500 requests per day at four per minute, for non-commercial use.

Question 3: is it just internet noise?

Every internet-facing system is scanned constantly by research projects, search engines for devices, and opportunistic attackers. An address that knocked on your firewall once may be scanning the whole IPv4 space and have no interest in you at all.

GreyNoise answers exactly this. Its Community API returns, for one IP:

• noise — whether the address has been seen scanning the internet in the last 90 days
• riot — whether it belongs to a known benign business service (the RIOT dataset: cloud services, CDNs, public DNS resolvers and the like)
• classification — GreyNoise’s verdict, such as benign or malicious
• name — the organization behind the address, when known

curl -s https://api.greynoise.io/v3/community/203.0.113.45

Without a key, the documented limit is 10 lookups per day. A free account registered with a business email address raises that to 50 lookups per week, shared with the web Visualizer; accounts on free email providers do not get API keys.

How to read the combinations:

Result	What it usually means
noise: true, inbound only	Background scanning. Make sure the exposed service is meant to be exposed, and move on.
riot: true	A common business service. Outbound traffic to it is expected; look elsewhere.
noise: false, riot: false	The address is not scanning everyone. If it targeted you, that is more interesting, not less.
Any result, outbound traffic from your host	GreyNoise describes scanners, not destinations. A host of yours that connects out to a scanner deserves attention.

Question 4: what does it run?

Internet scanning services record which ports an address had open and what answered on them. For an attacker-controlled address, that can reveal a command-and-control panel, a phishing kit on a web port, or an open directory full of tools.

Shodan. All Shodan accounts include a free API plan. Per Shodan’s credit documentation, the first page of an unfiltered search costs nothing, while searches with filters and later result pages use query credits. The one-time Membership ($49) adds 100 query credits per month and monitoring for 16 IPs; the vuln and tag filters require a higher plan. For triage, the host page of a single address — open ports, banners, TLS certificates and when each was seen — is usually what you want.

Censys. The free tier includes 100 credits per month through the web interface only, with no API access. A direct lookup of one host costs one credit; searches and extra result pages cost more. That is enough for a handful of investigations a month and a useful second opinion when Shodan’s data for an address is stale.

Treat scan data as a timestamped snapshot. A port seen open three weeks ago may be closed now, and a cloud address may have changed hands since.

Putting it together

For an IP address in an alert, a quick pass looks like this:

1. RDAP and ASN: who holds the range, and is it a cloud, hosting provider or ISP?
2. Your SIEM: which hosts talked to it, in which direction, how often and since when?
3. GreyNoise: is it scanning everyone, or a known business service?
4. AbuseIPDB and VirusTotal: recent reports, and which domains and files are related?
5. Shodan or Censys: only if the answers so far point to something worth understanding.

Most addresses resolve at step 1 or 3. The ones that do not — a small hosting provider, no scanning history, a domain registered last week pointing at it — are the ones worth an hour.

Limitations

• IP reputation decays fast. Cloud and residential addresses are reassigned constantly, so old reports may describe a previous owner.
• Residential proxy networks route attacker traffic through ordinary home connections. Those addresses look clean in every tool above.
• Shared hosting and CDNs put thousands of sites behind one address. A report against the address may concern a neighbor.
• Geolocation is an estimate. Do not build a verdict on a city name.

Adapting this to your environment

• ADAPT the cloud range check to the providers you actually use, and keep a local copy of their range files so the lookup works during an outage.
• ADAPT your allowlists to riot-style services your users rely on, so analysts do not re-investigate the same CDN every week.
• ADAPT the free-tier limits to your volume: a few manual lookups a day fit every service above; automated enrichment of every alert does not, and some free terms forbid it.

Next in the series: investigating a domain or URL. Corrections and suggestions go to hello@entropywatch.dev.