iqbal//soc

detection notes · threat intel · triage workflow

Enriching an IP without trusting reputation

An IP with a bad history is a reason to look, not a conclusion. This is the enrichment order I use so that reputation supports an assessment instead of replacing one.

The problem

Reputation lookups are cheap, which makes them the first thing an analyst does and the easiest thing to over-trust. Two failure modes show up constantly in a real queue: a shared-hosting or corporate NAT address that dozens of clean tenants also use, and a source that is right about the address but wrong about the context — a scanner hitting the perimeter is not the same event as the same address authenticating to a mailbox.

The order that works

1. What happened first, indicators second. Read the alert, establish the claimed behaviour, and only then go looking for evidence about the address. Enrichment before comprehension produces confident mistakes.
2. Classify the address. Hosting provider, VPN egress, residential, corporate, cloud tenant. An address is judged differently in each class, and the class changes the question — "is this expected egress for this service" beats "is this address bad".
3. Correlate internally before externally. Does the address appear anywhere else in my telemetry? Newly seen on this tenant, or a recurring pattern? Internal history is more relevant than a third-party score.
4. Enrich across several sources, then weigh them. VirusTotal, AbuseIPDB, Cisco Talos and IBM X-Force answer different questions: file and URL history, crowd-reported abuse, curated reputation, and threat-intel context respectively. Where they disagree, the disagreement is the finding.
5. Decide with confidence stated. Fact / observation / assessment / assumption, and a confidence level attached to the verdict. An inconclusive call written down honestly is worth more than a wrong one written confidently.

What I built for the repetitive part

Step 4 is mechanical, so I wrote a standalone client-side lookup page that queries VirusTotal, AbuseIPDB, Shodan and AlienVault OTX for one indicator and presents a single weighted verdict band instead of four disagreeing panels. API keys are stored locally in the browser and never sent anywhere except the vendors themselves.

Its honest limitation

AbuseIPDB blocks browser-origin requests, so that one source cannot be queried directly from a page like this — it needs a server-side proxy. So the tool is an analyst aid, not an automation pipeline: it collapses four tabs into one view and leaves the judgement with the person using it. The fix is a small proxy, and the reason it is not built is that the value is in the triage reasoning, not in removing one tab.

← all notes