The Assumption That Gets Teams Into Trouble
Most security teams treat IP reputation as a binary signal. An IP either appears on a known-bad list or it doesn't, and from that single data point, decisions get made about blocking, alerting, or allowing traffic through. This framing feels efficient. In practice, it collapses under real-world conditions faster than almost any other defensive assumption in the stack.
IP reputation and threat intelligence are genuinely powerful when they inform a layered decision process. They become dangerous when they replace one. The teams that get this right understand that an IP address is a data point with a shelf life, a geographic ambiguity, an infrastructure context, and a behavioral history. All of those dimensions matter. Any one of them in isolation tells you something narrow, often misleading.
This article walks through how IP reputation data actually works, where threat intelligence feeds earn their weight, and what a pragmatic workflow looks like for teams operating under real constraints.
What IP Reputation Data Is Actually Measuring
When a threat intelligence feed assigns a reputation score or classification to an IP address, that assessment reflects observed behavior at a specific point in time from a specific set of sensors. A hosting provider's IP range that ran a botnet command-and-control node six weeks ago may now be serving legitimate SaaS traffic. An IP flagged as a Tor exit node may belong to a researcher. A residential IP with a clean reputation may have been silently recruited into a proxy network hours before it reached your login page.
The NetNut proxy network disruption is a useful illustration here. When researchers identified and disrupted a network of roughly two million infected devices operating as residential proxies, the vast majority of those IPs were clean across every major reputation feed. They belonged to real users, real ISPs, real geographies. The infection layer was invisible to reputation scoring because reputation scoring looks at behavior patterns at the network level, not at what's running on a device behind a residential connection. Traffic from those IPs looked like normal residential traffic because, at the network level, it was.
This is not a criticism of reputation feeds. It is a description of their actual measurement scope. Understanding that scope determines whether you use the data well or trust it where it can't hold.
The Infrastructure Context Reputation Feeds Miss
IP addresses live inside infrastructure. That infrastructure has ownership, routing, history, and behavioral patterns that extend well beyond any single IP's reputation score. Autonomous System Numbers, hosting provider classifications, subnet histories, and registration patterns all contribute to a richer picture than reputation alone provides.
The FortiBleed campaign, which exposed credentials for over 73,000 FortiGate systems, involved reconnaissance and exploitation activity routed through infrastructure that appeared unremarkable in reputation feeds. Many of those source IPs were not flagged. The attack surface was the devices themselves, but the threat intelligence gap was in how teams were evaluating inbound traffic. Organizations that correlated ASN-level data, hosting provider classifications, and timing patterns alongside reputation scores had more signal to work with than those relying on blocklist hits alone.
Similarly, the CL-STA-1062 campaign targeting Southeast Asian governments and critical infrastructure demonstrated how sophisticated threat actors route operations through infrastructure specifically chosen to avoid reputation-based detection. They cycle through providers, use clean IP ranges, and blend into legitimate traffic patterns precisely because reputation feeds are a known defensive layer they can route around.
Threat Intelligence Feeds: What They Contribute and Where They Stop
Commercial and open-source threat intelligence feeds vary significantly in freshness, coverage, and classification accuracy. A feed that aggregates data from honeypots, spam traps, and passive DNS has different strengths than one built from active scanning or ISP telemetry. Neither is comprehensive. Most organizations subscribe to multiple feeds without a clear framework for reconciling conflicting signals or understanding what each feed is actually good at detecting.
Iran-Nexus TAG-182's dissemination of the MarkiRAT surveillance tool offers a concrete example of where threat intelligence feeds contribute meaningfully. Once indicators of compromise were published, including IP addresses associated with command-and-control infrastructure, teams with active feed subscriptions could retrospectively query their logs and identify whether any internal hosts had communicated with those addresses. That retrospective lookup is genuinely valuable. The limitation is that it is retrospective. The IPs were only intelligence after the campaign was documented.
Forward-looking threat intelligence, the kind that gives you signal before an IP has been formally flagged, comes from behavioral analysis, infrastructure correlation, and active hunting rather than from feed subscriptions alone. Feeds are a critical input. They are a starting point for investigation, not the conclusion of one.
Building a Practical IP Investigation Workflow
A repeatable workflow for evaluating suspicious IPs should pull from multiple dimensions simultaneously. Here is a framework that works under operational constraints.
First Pass: Automated Enrichment
When an IP appears in your logs or triggers an alert, automated enrichment should run immediately and populate a structured record. That enrichment should include current reputation scores from at least two feeds, ASN and hosting provider classification, geolocation data with a confidence indicator, passive DNS history showing what domains have resolved to that IP, any recent abuse reports from platforms like AbuseIPDB, and whether the IP is a known Tor exit node, VPN endpoint, or residential proxy.
This enrichment should happen without analyst intervention. The goal is to have a populated context record available before a human looks at the alert.
Second Pass: Behavioral Context
The automated enrichment tells you what the IP is. Behavioral context tells you what it's doing in your environment. Pull the full request history for that IP across your logs. Look at request timing, volume, user agent diversity, endpoint distribution, and authentication attempt patterns. An IP with a clean reputation that has made 400 requests to your password reset endpoint in 90 minutes is behaving like a threat regardless of its reputation score.
This is where many teams find the most actionable signal. Behavioral patterns reveal intent. Reputation scores reveal history. Both matter, but behavior is harder to fake at scale.
Third Pass: Infrastructure Correlation
If the first two passes don't resolve the question, infrastructure correlation often does. Query the ASN for recent abuse history even if the specific IP is clean. Check whether the IP belongs to a hosting provider or ASN range that has been associated with scanning, credential stuffing, or botnet activity. Look at the subnet. If neighboring IPs in the same /24 or /16 have abuse histories, that context is meaningful.
Passive DNS lookups can reveal whether the IP has hosted domains associated with phishing, malware distribution, or infrastructure used in documented campaigns. A clean IP that previously resolved to a known phishing domain is not as clean as its current reputation score suggests.
Operationalizing Threat Intelligence: From Feed to Decision
The gap between subscribing to threat intelligence feeds and actually using them well is significant in most organizations. Several operational patterns separate teams that extract value from those that are paying for feeds that generate noise.
Normalize Feed Confidence Before Acting on It
Different feeds have different false positive rates for different threat categories. A feed that is highly accurate for identifying botnet C2 infrastructure may be noisy for flagging scanning IPs. Build a confidence weighting into your workflow that reflects each feed's actual performance in your environment. Track how often a block or alert driven by a specific feed resulted in a confirmed true positive. Adjust weighting over time based on that evidence.
Set Feed-Specific TTLs
Threat intelligence has a shelf life. An IP flagged as malicious six months ago may have been reassigned, cleaned, or rotated out of the infrastructure it was part of. Applying an indefinitely cached blocklist entry to current traffic is a reliability problem. Set time-to-live values for intelligence entries based on threat category. C2 infrastructure IPs can hold longer. Scanning IPs from shared hosting should age out faster because those ranges recycle quickly.
Feed Intelligence Forward Into Hunting
A threat intelligence feed that is only used to block known-bad IPs is being used at a fraction of its potential. The same indicators can drive proactive hunting. When a new IP or domain indicator is added to a feed, run that indicator against 90 days of historical logs. Identify whether it appeared in your environment before it was flagged. If it did, that's a hunting lead. If the same hosting infrastructure appears repeatedly across incidents, that ASN or provider becomes a hunting hypothesis for future activity.
Where Residential Proxy Networks Change the Calculus
The NetNut disruption is worth examining more closely because it illustrates a class of threat that IP reputation is structurally ill-equipped to handle. Residential proxy networks route malicious traffic through compromised consumer devices, making the source IPs appear as legitimate residential addresses from real ISPs in real cities.
For teams defending authentication endpoints, payment flows, or account management features, residential proxy traffic is a meaningful threat because it passes reputation checks, passes geolocation plausibility checks, and often passes rate limiting because the traffic is distributed across thousands of different IPs. The defensive response to this threat category cannot rely primarily on IP reputation. It has to move to behavioral signals: request timing patterns, device fingerprinting, TLS fingerprint analysis, and behavioral biometrics that detect automation regardless of source IP.
This doesn't mean reputation is useless against residential proxy networks. Some residential proxy exit nodes do appear in feeds, particularly those that have been active long enough to accumulate abuse reports. But the coverage is partial and delayed. Behavioral detection has to carry the weight here.
Applying Threat Intelligence to Supply Chain and Emerging Attack Patterns
Threat intelligence feeds are increasingly being asked to address emerging threat categories that don't map cleanly onto traditional IP reputation models. Browser-only ransomware, AI-hallucinated domain attacks, and supply chain compromise through phantom package names all involve threat vectors where the malicious activity originates from trusted infrastructure or doesn't involve traditional C2 communication patterns.
The concept of phantom squatting, where AI-hallucinated package names or domains are registered and weaponized as supply chain vectors, creates IP reputation challenges because the infrastructure is new. Freshly registered domains resolve to freshly provisioned IPs with no reputation history. Traditional reputation feeds have nothing to report. The defensive response requires domain age analysis, registrar pattern analysis, and behavioral monitoring of what software packages are requesting from the network rather than IP reputation checks.
This is the direction threat intelligence is being pushed. The signal is moving from reactive IP reputation toward infrastructure pattern analysis, behavioral telemetry, and predictive correlation. Teams that build their workflows to accommodate multiple signal types are better positioned than those anchored to IP reputation as the primary filter.
What SMB Security Teams Should Prioritize
Reports that Australian SMBs are facing increased cybercrime pressure as larger organizations harden their defenses reflect a pattern visible globally. As enterprise security investment improves detection and response, threat actors shift activity toward smaller organizations with thinner defenses. SMB security teams typically operate with significantly constrained resources, which makes workflow efficiency critical.
For smaller teams, the practical priority list looks like this. First, implement automated enrichment at the firewall and SIEM level so that IP context is generated without manual effort. Second, subscribe to at least one commercial threat intelligence feed and one open-source feed with complementary coverage, and configure them to automatically update blocklists and alert rules. Third, invest in behavioral detection on authentication endpoints because that is where a disproportionate amount of SMB-targeted activity concentrates. Fourth, establish a quarterly review process for blocklist age-out to avoid the accumulation of stale entries that degrade detection accuracy.
These four steps don't require large teams or large budgets. They require workflow discipline and the willingness to treat threat intelligence as an active process rather than a subscription that runs in the background.
A Note on Attribution and Intelligence Confidence
When threat intelligence reports tie infrastructure to specific threat actors, like the TAG-182 attribution to Iran-Nexus operations, it's worth understanding what that attribution means operationally. Attribution at the nation-state level is useful for understanding campaign intent, target selection patterns, and likely persistence behaviors. It is less useful for day-to-day IP blocking decisions because the specific infrastructure rotates frequently.
What you should carry forward from attribution reporting is the infrastructure pattern, not the specific IPs. TAG-182 uses specific hosting providers, specific registrar patterns, and specific TTPs in infrastructure provisioning. Those patterns are more durable than any specific IP indicator and should inform how you tune your detection logic and what infrastructure signals you treat as elevated-risk.
Making the Intelligence Operational
IP reputation and threat intelligence earn their place in a security program when they drive action rather than generate noise. The teams that get consistent value from these tools share a few characteristics. They understand what each data source is measuring and where it has blind spots. They build workflows that layer multiple signal types rather than relying on any single feed or score. They treat threat intelligence as an input to investigation rather than a substitute for it. And they continuously evaluate whether the intelligence they're consuming is actually improving their detection outcomes.
The IP knocking on your door is carrying more context than its reputation score reflects. How much of that context your stack can read determines whether you catch the threat or process it as normal traffic.
