Your deny rule treats every listed address the same
Most SOC runbooks still fold every IP blocklist match into one motion: drop at the edge, ticket the hit, move on. That motion fits noisy scanners. It fails when the listed address is a compromised public host that your users already resolved, clicked, or bookmarked. Watering-hole campaigns and SEO-poisoned government mirrors sit on the same abuse feeds as botnet exits, yet the hunt they demand starts with visitor identity and payload delivery, not with another firewall line.
Recent reporting keeps forcing that distinction. Watering-hole activity pushing the ScanBox keylogger shows attackers prefer trusted destinations users already visit. Separate coverage of a Chinese-speaking actor turning Brazilian government sites into SEO weapons shows how “clean” public infrastructure becomes distribution and lure infrastructure overnight. Those addresses often land on shared blocklists beside commodity scanners. Treating both classes as identical deny events is how teams miss who inside already loaded the page.
Why the shared playbook keeps winning
Blocklists are operationally convenient. One feed, one match field, one automated action. Perimeter tools score “listed” as “hostile,” and hostile usually means inbound probe. Analysts inherit that bias in SIEM rules that only alert on inbound drops. Outbound connects, DNS resolutions, and proxy 200s to the same address look like successful browsing, so they stay quiet.
Three habits reinforce the mistake:
- Feed homogeneity. Scanner, C2, phishing kit, and compromised-site entries share one column in the ticket. Severity defaults to the list name, not the entry type.
- Inbound-first muscle memory. Perimeter drops feel like proof of control. Analysts close the case while proxy and EDR still hold the successful client fetches.
- Business-exception paralysis. When the listed host is a government portal, news site, or vendor docs domain, teams hesitate to block and then also hesitate to hunt, waiting for a cleaner indicator.
Supply-chain weeks make the confusion worse. A maximum-severity GitLab flaw and a Microsoft wave that closes hundreds of holes both drive opportunistic scanning. Those scanner IPs deserve short, protocol-focused hunts against unpatched services. The same week, watering-hole and SEO-compromised hosts deserve user-centric hunts. Collapsing both into “blocklist noise during patch week” is how ScanBox-style payloads slip under volume alerts.
Classify the listing before you write the query
Open every high-value blocklist match with a two-minute classification, not a drop confirmation.
- Ownership signal. ASN, WHOIS, certificate SAN, and historical DNS. Attacker-rented VPS and compromised public sites diverge quickly here.
- Service signal. Does the host serve a real site users would visit, or only probe paths and exploit payloads?
- List context. Why did the feed include it: scanning, malware callback, phishing hosting, or compromised redirector?
- Your exposure window. First internal DNS or proxy sighting versus first feed listing. Pre-listing contact changes priority.
If classification says compromised public host or watering hole, switch playbooks. Keep the perimeter drop if policy allows, then prioritize who talked to it and what they received.
Hunt the visitor population, not the source ASN
For watering-hole class matches, rebuild a short timeline from client telemetry:
- DNS queries and recursive resolver logs for the hostname and sibling names on the same certificate.
- Proxy or secure-web-gateway records with full URL path, referrer, user agent, and response codes. Harvest and keylogger pages often live one path deeper than the homepage your URL filters trust.
- Endpoint process trees for the same users in a ±2 hour window: browser child processes, unexpected script hosts, clipboard or keylogging-adjacent modules, and new persistence.
- Identity logs for password changes, MFA prompts, and token issuance after the browse event. ScanBox-style keyloggers turn a single visit into credential theft without a second phishing mail.
Concrete scenario: an abuse feed lists a Brazilian municipal site IP after SEO abuse reports. Your proxy shows twelve employees hit /noticias/ and three followed a redirect to a path that returned an obfuscated script. The firewall already drops new inbound from that IP. The hunt that matters is those three endpoints, their browser extensions, and any outbound callbacks in the next day, including addresses that still look clean on public feeds.
Keep scanner listings on a different clock
When classification says scanner or exploit probe, especially around GitLab-class supply-chain CVEs or large Microsoft patch waves, run a perimeter and exposure hunt:
- Match the source IP to auth and management-plane paths: VPN, Git, CI, hypervisor consoles, router admin ports.
- Diff configs and patch state for the probed product versions.
- Replay edge logs for neighbor addresses in the same /24 or cloud project that are not listed yet.
That work is valuable. It is the wrong depth for a watering-hole listing, where the attacker’s success condition was a successful page load from a trusted brand, not a login banner probe.
Implementation details that make the split real
Wire classification into the ticket, not a wiki page nobody opens.
- Enrich blocklist hits with a entry_class field: scanner, c2, phish_host, compromised_site, unknown. Require analysts to set it before closing.
- Split detections: inbound-drop heavy for scanner; DNS/proxy/EDR correlation heavy for compromised_site.
- Hold automatic “informational” severity for outbound allows to newly listed public sites until visitor correlation finishes.
- Preserve thirty days of proxy URL detail for hosts that flip from clean to listed. Delisting does not erase prior successful fetches.
- Feed hunt outcomes back into allow and block decisions. A government IP used as an SEO weapon may need selective path blocks and DNS sinkholing for malicious paths while leaving legitimate services reachable through tighter controls.
Breach headlines this season (student-loan record theft, utility customer data theft, large stolen-credential markets) remind teams why visitor hunts matter. Credential exposure often starts with a trusted page and a keylogger, then moves to account takeover. IP blocklists surface the host late. Your proxy and identity logs hold the earlier truth.
A pragmatic close-out checklist
When a blocklist match arrives, finish these steps before you call the case closed:
- Classify the entry; do not inherit the feed’s generic “malicious IP” label.
- If compromised or watering-hole class, enumerate every internal identity that resolved or fetched it, including pre-listing contacts.
- Pull full paths and redirect chains; homepage blocks miss harvest and keylogger routes.
- Pivot those users through EDR and identity for credential and session abuse.
- Expand once to related hostnames and still-clean neighbor addresses used in the same campaign week.
- Only then tune the long-term control: path-aware block, DNS policy, or full deny.
Scanner exits earn a fast drop and a focused exposure review. Watering-hole addresses on the same list earn a user hunt. Same feed match field; different attacker success condition; different work. Build that split into your runbooks while ScanBox-style watering holes and SEO-compromised public sites keep landing beside ordinary scanner noise on the feeds you already trust.
