An IP address in a firewall log is a starting point, not an answer. "We were attacked from 185.220.x.x" tells you almost nothing useful on its own. This post walks through the full passive-recon chain for attributing a source IP to a real-world organization and approximate location — using only free, open-source tooling. Everything here was applied during a real phishing campaign investigation to trace infrastructure back to its operators.
Step 1: WHOIS and IPWHOIS
The first query. WHOIS on an IP gives you the Regional Internet Registry (RIR) record: who the IP block is allocated to, the ASN it belongs to, the registration country, and abuse contact information.
# Command line
whois 185.220.101.1
# Or use a web tool
# https://ipwhois.io
# https://mxtoolbox.com/SuperTool.aspx (select IP Lookup)What to look for: the org name and netname fields. A residential ISP ASN means a compromised home machine or residential proxy. A datacenter ASN (Amazon, DigitalOcean, Hetzner, Linode) means a rented VPS — common for malware C2 and phishing infrastructure. A hosting company you've never heard of in a jurisdiction with lax abuse policies is a strong signal.
The registration country is where the block was registered, not necessarily where the traffic originates. VPN and proxy operators register blocks globally. Don't over-index on country alone.
Step 2: ASN Analysis
The Autonomous System Number groups IP ranges under a single operator. Knowing the ASN tells you:
- →What other IP ranges the operator controls — useful for expanding your block list
- →Whether the ASN has a known reputation as a bulletproof hosting provider or Tor exit node operator
- →Routing history — BGPView and similar tools show when the ASN announced the prefix and whether it's been hijacked
Tools: BGPView, Team Cymru IP to ASN, and the ASN lookup on MxToolbox. Cross-reference the ASN against known bad actor lists — Spamhaus ASN DROP list is a good start.
Step 3: Passive DNS History
What domain names have pointed to this IP? Passive DNS databases record historical A/AAAA record resolutions collected from recursive resolvers globally. A single IP that has hosted fifty throwaway domains over three months is very different from one hosting a legitimate business's infrastructure for years.
During the phishing campaign investigation, passive DNS revealed that the attacking IP had previously resolved a cluster of domains sharing naming conventions — all following the pattern of AI product typosquats. This is how you move from "one suspicious URL" to "this is a coordinated campaign with infrastructure patterns."
Tools: SecurityTrails (free tier with registration), mnemonic passivedns, VirusTotal IP Relations tab.
Step 4: Certificate Transparency Logs
Every TLS certificate issued by a public CA is logged in Certificate Transparency (CT) logs. This is a goldmine for attribution. If an attacker registers a phishing domain, they almost certainly issue a Let's Encrypt certificate for it — which means it's permanently logged in CT.
Query CT logs for the apex domain to find all subdomains that have had certificates issued. A phishing operator who got sloppy and issued certs for staging or management subdomains has exposed their entire infrastructure to passive enumeration.
Tools: crt.sh — search by domain, wildcard, or organization name. Also indexed by Censys with more filtering options.
Step 5: Shodan Host Records
Shodan continuously scans the internet and indexes banners, open ports, TLS certificate details, and service responses for every publicly-routable IP. An IP that looks like a bare hosting node on WHOIS might be running an exposed admin panel, a familiar C2 framework's default port, or a server header that fingerprints the exact software stack.
# In Shodan web interface: search by IP
# Or via CLI:
shodan host 185.220.101.1
# Look for:
# - Open ports and what's running on them
# - TLS cert organization field (often contains real org name)
# - HTTP response headers (server, X-Powered-By, etc.)
# - Historical scan data showing what changed over timeThe TLS certificate's Subject Organization field is frequently filled in with real information even when the registrant's WHOIS data is privacy-protected. This is how you sometimes get an actual company name from what looked like an anonymous VPS.
Step 6: Email Header Analysis with MxToolbox
When the investigation originates from a phishing email rather than a network log, the email headers are the primary evidence source. Every hop the email passed through is recorded, including the originating server's IP before it hit any anonymization layer.
MxToolbox's Email Header Analyzer parses raw headers and presents the hop chain in a readable timeline, flags SPF/DKIM/DMARC failures, and lets you click through to WHOIS on each IP directly. This was used during the credential-harvesting campaign investigation to confirm the sending IP was inconsistent with the claimed sending domain — the SPF record explicitly failed, and the originating IP traced to a datacenter in a jurisdiction completely unrelated to the claimed sender's country.
Geolocation: When Sources Disagree
MaxMind, ipinfo.io, and ip-api.com will sometimes give you three different cities for the same IP. This is normal and expected — IP geolocation databases are built from inference, not ground truth. The registration country from RIR data is the most reliable field. City-level geolocation is an estimate. VPN and proxy services deliberately cause geolocation to lie.
When sources disagree significantly (different countries, not just different cities), that disagreement is itself a signal — the IP is likely behind a proxy or VPN, or the geolocation databases have stale data for that block.
When to Block at ASN Level
ASN-level blocking is a blunt instrument. Blocking an entire Tor exit ASN might be appropriate for a healthcare organization with no legitimate reason to receive Tor traffic. Blocking all of Hetzner because one attacker rented a node there would break connectivity with a large portion of the legitimate European internet.
The decision framework: What is the expected ratio of malicious to legitimate traffic from this ASN? For bulletproof hosting providers with documented histories of ignoring abuse reports, ASN-level blocking is justified and has minimal collateral damage. For major cloud providers, IP-specific blocks only.