How to investigate a suspicious IP address
A practical order of checks for any IP in an alert: who owns it, what it is used for, whether it attacks other people, and when the answer is block, monitor or close. Uses free sources only.
An alert gives you an IP and nothing else. Maybe it's the source of a failed RDP logon, a destination your EDR flagged, or the first public hop in a phishing email. To investigate a suspicious IP address properly you need to answer four questions, in this order: who owns it, what it normally does, whether it attacks other people, and whether it actually touched anything of yours. The free sources below cover all four.
The examples use 203.0.113.45, which is a documentation address. Swap in your own.
Step 1: Is it even a public IP?
It sounds obvious, but a surprising number of tickets get escalated for addresses that never left the building. Rule these out before any lookup:
| Range | What it is |
|---|---|
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | Private (RFC 1918). It's one of your hosts, or a client's. Look it up in your CMDB or DHCP logs, not on the internet. |
100.64.0.0/10 | Carrier-grade NAT. Common on mobile and some home ISPs, and on Tailscale. Not unique, so threat intel on it means nothing. |
169.254.0.0/16 | Link-local. A host that failed to get an address from DHCP. |
127.0.0.0/8 | Loopback: the machine talking to itself. |
For a private IP, the investigation moves inside: which device had that address at that time, and who was using it.
Step 2: Who owns the IP? (WHOIS, ASN and hosting)
Ownership tells you more than any reputation score. Check the ASN and organisation with ipinfo.io or an RDAP lookup at rdap.org. You're looking for one of these:
- A residential or mobile ISP (Comcast, Vodafone, Grameenphone). Could be a real user at home, or a compromised home router. Location matters here.
- A cloud or hosting provider (AWS, Azure, DigitalOcean, OVH, Hetzner, smaller VPS hosts). Real people rarely log in to Microsoft 365 from a VPS. A sign-in or RDP attempt from hosting space deserves suspicion by default.
- A known business (your own vendors, a SaaS provider, a CDN like Cloudflare or Akamai). Usually benign, but CDN IPs are shared by thousands of sites, so blocking one can break things you need.
- A VPN or anonymiser (Mullvad, NordVPN, Tor exit nodes). Not proof of anything, but worth noting against how that user normally works.
My rule of thumb: hosting provider plus authentication attempt is enough to block while you keep digging. Residential ISP plus authentication attempt needs more context before you act, because it might be the user.
Step 3: Does it attack other people? (reputation)
Now check whether others have seen it misbehave. Use more than one source; each sees a different slice of the internet.
| Source | What it's good for | Watch out for |
|---|---|---|
| AbuseIPDB | Community abuse reports: brute force, scanning, spam. The confidence score and the report categories are both useful. | A high score on a shared VPN or CGNAT address can be other users' fault. |
| GreyNoise | Tells you if the IP is mass-scanning the whole internet, and whether it's a known benign scanner (Shodan, Censys, research projects). | "Noise" means untargeted, not harmless. A scanner that found your open RDP is still a problem. |
| VirusTotal | Vendor detections, plus the Relations tab: domains that resolved to the IP and files that contacted it. | Zero detections is common for fresh attacker infrastructure. Absence of evidence isn't a clean bill of health. |
| Shodan | What the host exposes: open ports, banners, TLS certificates. A box with RDP, an outdated web panel and a self-signed cert looks very different from a CDN edge. | Data can be days or weeks old. |
| ThreatFox and URLhaus | Known malware C2 servers and malware download hosts. A hit here is high-confidence. | Coverage is narrower, so no hit doesn't clear it. |
Don't let one source decide. A clean VirusTotal result with 400 AbuseIPDB reports for SSH brute force in the past week is a bad IP. A scary AbuseIPDB score on a Cloudflare or Google address is almost always a false lead: the reports are about sites behind the shared address, not the address itself.
Step 4: Did it touch anything of yours?
Reputation tells you about the IP. Your own logs tell you whether it matters. Search for the IP across the last 7 to 30 days:
- Firewall and VPN logs: was the connection allowed or dropped? A dropped scan is a non-event; an allowed session is an incident.
- Authentication logs: Windows Event ID 4624 and 4625, Entra ID sign-in logs. Any successful logon from the IP changes everything.
- Proxy, DNS and EDR: for outbound traffic, which host talked to it, how often, and which process made the connection.
- Email gateway: did other messages come from the same sending IP?
In Microsoft Sentinel, one query covers several of these:
let ip = "203.0.113.45";
union isfuzzy=true
(SigninLogs | where IPAddress == ip | project TimeGenerated, Source="Entra sign-in", Detail=strcat(UserPrincipalName, " ", ResultType)),
(SecurityEvent | where IpAddress == ip | project TimeGenerated, Source="Windows", Detail=strcat(EventID, " ", TargetAccount)),
(CommonSecurityLog | where SourceIP == ip or DestinationIP == ip | project TimeGenerated, Source="Firewall", Detail=strcat(DeviceAction, " ", DestinationPort))
| order by TimeGenerated descBlock, monitor or close?
| What you found | Decision |
|---|---|
| Private, CGNAT or your own known infrastructure | Close the external angle; investigate the internal host if the behaviour is odd. |
| Known benign scanner (GreyNoise "benign"), traffic dropped | Close. Note it so the next analyst doesn't redo the work. |
| Hosting or VPN IP with failed logons, no success | Block at the edge, check why the service is exposed, close. |
| Any successful authentication from a suspicious IP | Escalate. Reset credentials, revoke sessions, review what the session did. |
| Internal host talking to a known C2 address | Escalate immediately. Isolate the host and preserve evidence. |
| Shared CDN or cloud IP with mixed reputation | Don't block the IP. Investigate the domain or URL instead. |
Whatever you decide, write down the sources you checked and what each one said. "Blocked, AbuseIPDB 100%" won't help the next person. "Hetzner VPS, 312 AbuseIPDB reports for RDP brute force, GreyNoise malicious scanner, 48 failed logons on RDP gateway, no success" will. If you want to read the logon side more closely, see Event ID 4625: failed logons explained and, for cloud sign-ins, Microsoft 365 impossible travel.
FAQ
Can I find the person behind an IP address?
Not with public sources. WHOIS gives you the network owner, such as an ISP or hosting company, not the subscriber. Only the provider can map an IP to a customer, and they will only do that for law enforcement or through their abuse process.
How accurate is IP geolocation?
Country is usually right; city often isn't, especially for mobile networks and VPNs. Use location as one signal, never as proof, and be careful with impossible travel alerts built only on geolocation.
Should I block every IP with a bad reputation?
No. Blocking shared CDN, cloud or CGNAT addresses can cut off legitimate services and customers. Block hosting and VPS addresses that attacked you; for shared infrastructure, block the domain or URL instead.
What does it mean if an IP has no reports anywhere?
Either it's genuinely benign, or it's new attacker infrastructure that nobody has reported yet. Fall back on ownership and on your own logs: a fresh VPS that just logged in successfully as your finance user is an incident whatever the reputation sites say.
Paste a whole alert, log extract or email into the IOC Extractor: it finds and refangs every IP, domain, URL and hash, ready to check.
IOC Triage, our free browser extension, queries AbuseIPDB, GreyNoise, ipinfo, Shodan, VirusTotal and more for any IP you select, explains the verdict and copies a ticket note.