The Operator Pain Point Nobody Talks About Loudly Enough
Security operations teams run into the same wall every week. An IP address arrives at the edge, a blocklist lookup returns clean, and the traffic gets passed through. Three days later, that same address shows up in an incident report. The blocklist wasn't wrong exactly — it just described yesterday's threat landscape, and yesterday's threat landscape is not the same as today's.
IP reputation data and threat intelligence feeds are foundational controls, but the gap between what those feeds cover and what's actively targeting your environment in real time is where incidents find room to develop. Closing that gap requires treating IP reputation as a live, layered operational discipline rather than a lookup table that gets refreshed on someone else's schedule.
The HelloNet campaign, which pushed malicious modules through the ViPNet update system, demonstrated this gap precisely. Infrastructure used in early stages of that campaign appeared clean across multiple commercial reputation feeds while reconnaissance and staging were already underway. The addresses only accumulated reputation signals after the campaign reached a certain volume threshold. By then, teams relying solely on feed data were already behind.
What IP Reputation Data Actually Measures
Commercial threat intelligence feeds aggregate signals from a range of sources: honeypot networks, sinkhole infrastructure, passive DNS data, spam trap hits, malware sandbox detonations, and abuse reports submitted by other organizations. The picture that emerges from all of those sources is accurate, but it reflects past behavior. An IP that served malware last Tuesday carries a reputation score that reflects last Tuesday. An IP that started scanning your environment this morning carries no reputation score at all if it has never appeared in any of those source systems before.
This isn't a flaw in how threat intelligence vendors operate. It's an inherent structural characteristic of reputation-based systems. Reputation requires a track record. Attackers who rotate infrastructure deliberately exploit this by using fresh IP space, cloud-provisioned addresses, and residential proxy networks that have no prior association with malicious activity.
The P2P botnet ecosystem makes this problem concrete. Modern peer-to-peer botnets distribute their command and control functions across thousands of infected residential nodes. Those nodes are not blacklisted. They are home broadband addresses in ordinary ISP ranges. Blocking them based on reputation data alone is effectively impossible. Detection requires behavioral analysis of what those addresses are doing, not what they've done previously.
Building a Layered Reputation Architecture
A production-grade IP reputation system needs at least three distinct layers operating in parallel. Each layer contributes context that the others cannot provide on their own.
Layer One: Commercial Feed Integration
Commercial threat intelligence feeds from vendors that aggregate globally should form the baseline. The operational requirement here is not simply subscribing to one feed — it's normalizing and correlating across multiple feeds so that an address appearing in two independent sources carries more weight than one appearing in a single source. Confidence scoring based on feed consensus is significantly more reliable than binary block or allow decisions based on any single feed's output.
Feed freshness matters enormously. A feed updated every 24 hours provides materially different coverage than one updated every 15 minutes. For perimeter enforcement, feed latency directly translates to exposure window. Teams should document the update cadence of every feed in their stack and factor that cadence into risk calculations for decisions made at the edge.
Layer Two: Behavioral Enrichment at the Edge
This layer operates on what an IP address is doing in your environment right now, regardless of what it has done anywhere else. Behavioral signals include request rate and pattern, user-agent consistency, session behavior relative to authenticated users at the same address, geographic velocity (the same address appearing across multiple regions in a time window that makes physical travel impossible), and protocol anomalies that suggest automated tooling rather than human interaction.
The Rondo campaign targeting GeoServer instances, which emerged in July 2025, used IP infrastructure that was behaviorally distinctive well before reputation feeds flagged those addresses. The scanning pattern — systematic port probing across a narrow target profile — was visible at the network layer for any team running behavioral enrichment on inbound traffic. Reputation feeds caught up, but behavioral detection had a material head start.
Layer Three: Environmental Intelligence From Your Own Infrastructure
Your own logs contain threat intelligence that no external vendor can replicate. Authentication failure patterns, web application firewall event clusters, DNS query anomalies, and lateral movement indicators all generate IP-linked signals that are specific to your environment and your adversaries. Feeding those signals back into your reputation scoring system allows you to build a local blocklist and watchlist that reflects who is targeting you, not just who is targeting the general population of organizations that feed external reputation providers.
This local intelligence layer also addresses the cross-tenant identity issues surfaced by the Default Azure Automation configuration finding. When an identity takeover originates from an internal automation process rather than an external IP, traditional reputation feeds offer nothing. Environmental intelligence built from your own audit logs and automation activity records provides the visibility that external feeds structurally cannot.
Operationalizing Threat Intelligence in a Security Operations Center
Intelligence without an operational workflow is just data storage. The following phased approach moves teams from reactive feed consumption to active threat intelligence operations.
Today: Audit What You're Actually Using
Start by documenting every feed currently integrated into your security stack. Record the feed name, the update frequency, the integration method, and whether the feed is being used for blocking, alerting, or enrichment. Many organizations discover during this audit that feeds integrated years ago have drifted in quality, changed their update cadence, or are no longer being actively maintained by the vendor.
Check whether your blocking decisions are binary or scored. Binary block decisions based on reputation data produce a high false positive rate and cause legitimate traffic to be dropped. Scored decisions that use reputation as one signal among several are more accurate and easier to tune. If your current stack only supports binary blocking, that's a short-term architectural gap worth prioritizing.
This Week: Add Behavioral Context to Edge Decisions
Identify the point in your traffic path where you have the most complete visibility into inbound connection behavior. For most organizations, this is either a web application firewall, an API gateway, or a network-layer inspection point upstream of those systems. Configure that point to capture and log request rate, session behavior, and user-agent data for every inbound IP, not just addresses already flagged by reputation feeds.
Build a simple query in your SIEM or log analysis platform that surfaces IP addresses generating more than a threshold number of authentication failures within a rolling window. Cross-reference that output against your current reputation feed data. The addresses that appear in authentication failure data but not in reputation feeds represent your most immediate visibility gap.
The Modern Attack Vectors framework published by Recorded Future specifically calls out behavioral telemetry at the edge as a primary detection surface that organizations systematically underutilize. The data is already being generated. The operational step is creating the pipeline that makes it queryable and actionable.
This Quarter: Build a Continuous Monitoring Program for IP Infrastructure
Mature threat intelligence operations treat IP infrastructure monitoring as an ongoing function rather than an incident response activity. This means tracking changes in the infrastructure used by threat actors observed in your environment over time, following ASN-level patterns when individual IP addresses rotate, and monitoring passive DNS data for domains that resolve to infrastructure previously associated with attacks against your organization.
P2P botnet tracking, documented extensively in recent operational security research, demonstrates why this longitudinal view matters. Individual nodes in a P2P botnet have short operational lifespans. The infrastructure pattern — the ASNs used, the hosting providers favored, the geographic distribution of nodes — persists across multiple campaign cycles. Teams tracking infrastructure patterns catch the next campaign faster than teams responding to individual IP alerts.
Establish a threat intelligence sharing relationship with at least one peer organization in your sector. The CIA-derived Hive toolkit variants now circulating in criminal markets, as reported in recent threat intelligence bulletins, spread through campaigns that target specific industries sequentially. Organizations in the same industry vertical that share indicator data in near real time give each other detection lead time that no commercial feed can provide.
Practical Scenarios Where This Matters
Residential Proxy Networks and Fraud Prevention
A financial services team running account takeover prevention blocked 40,000 IP addresses from a commercial threat intelligence feed over 90 days. During that same period, their fraud team identified 300 confirmed account takeovers. Cross-referencing the fraud events against blocked IPs revealed that fewer than 8% of confirmed takeover attempts came from addresses that had been in the reputation feed before the attack. The rest used residential proxy infrastructure — addresses associated with home broadband subscribers whose devices had been compromised.
The solution was not adding more reputation feeds. It was building a device fingerprint correlation layer that identified inconsistencies between the claimed geolocation of the connecting IP and device-level signals like timezone, browser language settings, and hardware capability profile. That behavioral layer caught residential proxy abuse that reputation data systematically missed.
Cloud Infrastructure as Staging Ground
Attackers using freshly provisioned cloud compute instances present a particular challenge for reputation-based systems because those addresses are genuinely clean at the time of use. A manufacturing company's security operations team addressed this by building an ASN classification layer that assigned different trust baselines to different categories of IP space. Traffic from major cloud provider ASN ranges — where individuals can provision addresses in minutes — received a lower initial trust score than traffic from established residential ISP ranges or enterprise network space, even when the individual addresses had no reputation history.
This approach does introduce false positives for legitimate cloud-originating traffic, which the team managed by creating a fast-track allowlisting path for authenticated sessions from cloud IP space that presented valid client certificates. The friction was low for legitimate users and significantly higher for automated tooling.
Integrating Threat Intelligence Into Incident Response
IP reputation data collected during an active incident should feed back into your threat intelligence program, not simply inform the current response. When an address involved in an incident is investigated, the full context — the ASN, the hosting provider, the geographic registration data, the passive DNS history, and any associated domain infrastructure — should be documented and retained in a structured format.
During subsequent incidents, that historical context allows analysts to recognize infrastructure reuse patterns quickly. Attackers reuse hosting providers, ASN ranges, and domain registration patterns even when they rotate individual IP addresses. Teams that document and query this infrastructure context catch campaign continuity that address-level analysis misses entirely.
Building this capability requires a threat intelligence platform or a structured repository that your team actually queries during investigations. A spreadsheet of past incidents does not qualify. The data needs to be searchable by ASN, by hosting provider, by registrar, and by infrastructure attribute so that analysts can run pattern queries across historical incident data in real time during active investigations.
Where This Goes From Here
The threat intelligence ecosystem is moving toward greater automation of feed correlation, behavioral enrichment, and infrastructure tracking. Machine learning systems that identify relationships between newly observed IP addresses and previously seen attacker infrastructure are becoming practical at production scale. The operational foundation that makes those systems useful is the data collection discipline described above: consistent logging of behavioral signals at the edge, structured documentation of incident infrastructure, and continuous monitoring of the ASN and hosting provider patterns associated with threats to your environment.
Teams that build that foundation now will be in a position to adopt more automated intelligence correlation as the tooling matures. Teams that continue treating IP reputation as a lookup-and-block function will find that the gap between feed coverage and actual threat landscape keeps widening as attackers systematically industrialize the use of clean infrastructure.
The operational shift is not about replacing reputation feeds. It's about building the contextual layers around them that transform point-in-time lookup data into continuous, environmentally-aware threat intelligence.
