A mid-market manufacturer added a new IP abuse feed to its edge firewall on a Monday morning. By noon, the SOC had blocked three addresses linked to a fresh phishing kit cluster. Ticket closed. Two days later, the identity team opened an incident: seventeen Okta-style portal logins from unfamiliar cloud VMs, MFA push fatigue on six accounts, and one successful password reset that unlocked a finance shared mailbox. The kit IPs had been on the public feed for nineteen hours before the firewall rule went live. Proxy logs showed eleven employees had already completed TLS sessions to those same destinations during the unblocked window. The perimeter drop arrived after the credentials left the building.
That pattern tracks campaigns like the recent 0ktapus wave against roughly 130 firms. Operators stand up short-lived kit hosts, harvest SSO credentials, and rotate infrastructure faster than many teams refresh deny lists. The hunt that matters starts when a kit address appears on a shared feed, and it asks a narrow question: who inside already talked to that host?
Why the match is an outbound investigation first
Inbound scanners and kit hosting are different operational problems. A listed scanner probing your VPN port is reconnaissance. A listed phishing kit that your users reached is potential credential loss. Both can share the same feed. Your response must not.
For kit-style listings, prioritize telemetry that proves client-initiated contact:
- Forward proxy and secure web gateway logs with client user, destination IP, SNI or Host header, URL path if decrypted, and HTTP status
- DNS resolver logs showing which workstations resolved kit domains that later mapped to the listed IP
- Endpoint browser history or EDR network events for devices that bypass the proxy
- Email security click logs that can confirm the lure that sent traffic to the kit
Firewall deny counters alone cannot reconstruct who submitted a password. They only prove the address became known after someone else already abused it elsewhere.
A workable hunt window after a kit IP lands
Use a fixed playbook when an abuse feed entry is tagged as phishing, credential harvesting, or fake login portal infrastructure.
1. Expand the IOC set before you query
One IP is rarely the full kit. From the feed metadata and quick enrichment, collect co-hosted domains, certificate SANs if available, related URLs from the same campaign bulletin, and neighboring addresses on the same /24 only when the feed or vendor explicitly groups them as one kit. Keep neighbor expansion optional. Shared cloud ranges produce noise quickly.
2. Search outbound history for a defined lookback
Replay proxy, DNS, and EDR network logs for 72 hours before the first listing timestamp and 24 hours after. That bracket covers most kit hosting lifetimes in commodity phishing operations while staying inside common retention SLAs. If your proxy keeps only 48 hours of detail, document that gap in the ticket so identity responders know the coverage floor.
3. Build a visit roster, not a block ticket
Produce a table with user identity, device, destination IP or domain, first and last seen, bytes transferred, and whether TLS inspection saw a login form path. Sort by successful page loads and POST-like volume. Anyone with a completed interactive session becomes a high-priority identity review. DNS-only lookups without a follow-on connection stay medium priority.
4. Hand the roster to identity with a clear ask
For each high-priority user, require within four hours: forced password reset on the targeted IdP, session revocation across SSO apps, MFA method audit for push bombing or newly enrolled factors, and a check for mailbox rules or OAuth grants created after the visit. This is where 0ktapus-style tradecraft pays off for attackers: the network IOC is disposable; the stolen session is durable.
Tradeoffs you have to accept
Retention versus certainty. Longer proxy retention improves kit hunts and raises storage cost plus privacy review burden. Teams that keep only aggregated netflow will miss form posts. Budget detail logs for user egress paths even if you compress east-west traffic sooner.
TLS inspection versus coverage. Without decryption you still get SNI and IP timing, which is often enough to flag a visit. You lose proof of credential submission. Pair undecrypted hits with identity anomalies rather than treating every SNI match as confirmed theft.
Shared hosting false positives. A listed IP may host unrelated sites behind the same cloud load balancer. Require domain or URL corroboration before mass password resets. Prefer user-to-kit domain matches over raw IP matches when the address sits in a hyperscaler range.
Feed lag. Public lists trail private vendor intel. Waiting for a list hit as your only trigger leaves a gap. Subscribe to phishing-kit bulletins and IdP abuse notices in parallel so the same hunt can start from a domain report before the IP is listed.
Where recent threat headlines change the hunt
AI-assisted OSINT lowers the cost of building convincing lures and targeting lists, which means more employees see personalized kit pages hosted on fresh IPs. Fraud operators using those methods still need somewhere to collect credentials. That somewhere still resolves to addresses your proxy can log.
Attackers also abuse trusted AI and SaaS platforms as delivery and hosting surfaces. When kit content sits behind a reputable CDN or collaboration domain, IP blocklists may lag or list only the origin briefly. Your hunt should key off the full URL and SNI chain, then map back to any origin IP the feed eventually names. Blocking the listed origin after users already completed sessions through the trusted front door closes the wrong door.
Papercut-style automated swarm probing and classic scanner noise will continue to inflate the same feeds. Tag feed categories at ingest. Route phishing and credential theft tags into the outbound visit playbook. Route scanning tags into perimeter and management-plane reviews. One feed, two runbooks.
Implementation details that keep the playbook fast
- Normalize abuse feed fields on ingest: first_seen, category, confidence, and source. Store first_seen as the hunt clock anchor.
- Maintain a saved query in your SIEM that joins feed first_seen to proxy events on destination IP and to DNS on resolved A records for related domains.
- Auto-open a case when category equals phishing or credential harvesting and any internal client shows a connection in the lookback window. Empty joins can close automatically after analyst spot-check.
- Export the visit roster in a format identity tooling can consume (UPN plus timestamp) so session kills do not wait on copy-paste.
- Measure mean time from feed arrival to roster delivery. Target under 30 minutes for environments with centralized proxy logging.
What good looks like after the next kit listing
The firewall rule still ships. The difference is the parallel hunt. Analysts pull who visited, identity clears or resets those accounts, and the incident record shows whether any session survived past the listing. That closes the failure mode the manufacturer hit: a green perimeter ticket sitting on top of an unexamined outbound trail.
Actionable takeaways for the next shift:
- Classify feed hits as kit versus scanner before you choose a runbook.
- Search proxy and DNS for 72 hours before first_seen when the category is phishing.
- Treat completed user sessions to kit hosts as identity incidents, then revoke sessions and reset credentials on a fixed clock.
- Corroborate with domain or URL context on shared cloud IPs before mass resets.
- Track roster delivery time as a SOC metric alongside block deployment time.
IP blocklists remain useful denial tools. For phishing kit addresses, they are also a delayed map of infrastructure your people may have already trusted. Pull the visit list while the listing is still warm.
