SOC & Incident Response Tools

Alert triage is mostly a question of context. The detection has already fired; what you need to know is whether the thing it fired on is normal for this user, this network, and this time of day. An IP address on its own answers none of that, which is why the first move is almost always enrichment — who owns the address, what kind of network is it, has it been seen doing something else.

What these tools will not do is make the decision for you. A tool that says “malicious” with no working shown is worse than no tool, because it invites an analyst to skip the reasoning and inherit someone else's. Each of these shows the inputs it used and says plainly when the data cannot support a conclusion.

They are also deliberately narrow. General-purpose data manipulation — defanging indicators, decoding payloads, converting timestamps, identifying hash types — is covered thoroughly and for free by CyberChef, and duplicating it here would add pages without adding anything useful.

Why IP geolocation cannot be trusted precisely

Several of these tools rest on IP geolocation, so it is worth being blunt about how approximate it is. A geolocation database does not know where a device is. It knows which addresses an operator has registered, and infers a location — usually the centroid of a city, sometimes the middle of a country.

The published error bars are large. City-level accuracy sits around half the time within the stated radius, and mobile networks are far worse than fixed lines: errors of roughly 180–200 km are ordinary, because a phone's traffic may egress from a carrier gateway in a different region entirely. That is not a database defect, it is what the data can support.

This matters most when a calculation divides distance by a short time interval, because a small absolute error becomes an enormous implied speed. Two logins five minutes apart, with a couple of hundred kilometres of geolocation noise between them, imply thousands of kilometres per hour — from a user who never left their desk. Our impossible travel detector handles this by carrying the accuracy radius through the arithmetic and returning “cannot tell” when the error bars are wide enough to decide the answer, rather than reporting a confident false positive.

A VPN, a corporate proxy, or carrier-grade NAT breaks the premise completely: in those cases the address never described where the person was. How IP geolocation works covers the mechanics, and VPN detection will tell you whether you are looking at one.

Common scenarios

“This account logged in from two countries in one hour.”

Put both addresses and both timestamps into the impossible travel detector. If it returns implausible, the geolocation error would have to be larger than reported for one person to have made that trip — worth escalating. If it returns cannot tell, the gap is too short relative to the accuracy radii, and the pair is not evidence either way. Check whether either address is a VPN before drawing any conclusion.

“What is this IP address in my logs?”

IOC enrichment gives you geo, ASN, our datacenter and VPN classification, Tor-exit status, reverse DNS, and a curated blocklist summary on one page. The ASN is usually the most informative field: a residential ISP, a hosting provider, and a cloud region imply very different stories for the same behaviour.

“I have a hundred addresses from an export.”

Bulk IP lookup takes up to 100 at once and returns geolocation and ASN for each, which is usually enough to spot the handful worth looking at individually. Group by ASN first — a set of addresses that resolves to one hosting provider is one finding, not a hundred.

“Is this CVE actually urgent?”

CVE Explorer returns the NVD description and CVSS severity, and tells you whether CISA lists it as known-exploited. Known exploitation is the signal that should move a patch up the queue; a high CVSS score on something nobody is attacking often should not.