The Incident That Changed How One SOC Team Used Reputation Data
At 2:47 AM on a Tuesday, a mid-sized financial services firm received an automated alert: a single internal workstation had made twelve outbound connections to an IP address flagged in their threat intelligence feed. The on-call analyst acknowledged the alert, checked the IP against the feed, confirmed the flag, and blocked it at the perimeter firewall. Case closed.
Except it was not closed. The same IP had already been rotating through a /24 subnet for six days, making brief connections to seventeen other workstations in the same network segment. By the time the analyst blocked the single flagged address, the attacker had already established persistence through a different, unflagged IP two hops away. The original reputation flag was accurate. The operational response built around it was too narrow.
This scenario is common enough that it deserves a structured look at how IP reputation and threat intelligence actually function inside a working security operation, where the data is reliable, where it degrades under real conditions, and what defenders can do to make it operationally useful rather than just procedurally satisfying.
What IP Reputation Data Actually Measures
IP reputation scores are derived from observed behavior associated with a given address over time. Sources include spam trap hits, honeypot interactions, malware command-and-control communications, participation in DDoS campaigns, brute force login attempts, and reports submitted by other organizations. Aggregators weight these signals differently depending on recency, volume, and confidence level.
The critical thing to understand is that reputation scores are historical by definition. An IP that scored clean yesterday may be hosting a phishing kit today. An IP flagged three weeks ago as a botnet node may now belong to a legitimate cloud tenant who inherited a recycled address from a provider pool. Both failure modes cause real operational problems, and both are common.
Providers like Spamhaus, Cisco Talos, Emerging Threats, and commercial platforms such as Recorded Future, ThreatConnect, and GreyNoise all approach this data collection differently. Spamhaus focuses heavily on email abuse. GreyNoise filters out mass internet noise to surface targeted activity. Talos correlates data from Cisco's telemetry network. Using a single feed as a definitive source treats a probabilistic signal as a binary truth, and that is where most operationalization mistakes begin.
The Current Threat Landscape Making This More Urgent
The ESET Threat Report for H1 2026 documented a significant increase in campaigns that deliberately rotate infrastructure across clean IP ranges to avoid reputation-based blocking. Attackers have become sophisticated consumers of the same threat intelligence feeds that defenders use. They test their own infrastructure against public reputation APIs before launching campaigns, spinning up new nodes when existing ones get flagged.
The breach affecting Unlimited Technology Systems, which exposed data on 3.8 million people, followed an initial access pattern that involved connections from IPs with no prior reputation flags. The attacker infrastructure had been stood up specifically for this campaign and had not accumulated enough behavioral history to trigger reputation-based controls. Defenders relying primarily on reputation scoring had no automated signal at the perimeter during the initial intrusion window.
The disclosure that cybercriminals are actively selling access to Chinese surveillance cameras adds another dimension. These compromised devices often carry clean IP reputations because they belong to legitimate business and residential ISP ranges. When attackers route malicious traffic through them, standard reputation checks see an unremarkable residential or commercial IP rather than a known threat actor address. Volume and behavioral pattern analysis become more important than the reputation score alone.
Building a Detection Architecture Around Reputation Data
The practical starting point is layering reputation data against behavioral signals rather than treating reputation as a standalone gate. Here is how that architecture looks in practice.
Feed Aggregation and Normalization
Consuming multiple threat intelligence feeds simultaneously requires normalization before any of the data becomes useful for automated decisions. Different providers use different confidence scales, different flag categories, and different update frequencies. An IP that appears in three feeds with moderate confidence scores tells a different story than the same IP appearing in one feed with a high-confidence flag based on fresh honeypot data.
Tools like MISP (Malware Information Sharing Platform) and OpenCTI allow teams to ingest multiple feed formats, normalize them into a common schema, and apply weighting rules before the data reaches SIEM correlation rules or firewall automation. Without normalization, you end up with a blocklist that is either dangerously permissive or generates enough false positives to train analysts to ignore the alerts.
Confidence Scoring Before Action Thresholds
Assign action thresholds to confidence tiers rather than treating any positive flag as a blocking trigger. A reasonable tiered approach might work as follows:
- High confidence (multiple independent sources, recent activity, specific threat category): Automated block with alert to SOC queue for review within four hours.
- Medium confidence (single source, older flag, or broad category like scanning): Alert only, no automated block, analyst review required before action.
- Low confidence (single report, no corroboration, aged flag): Log enrichment only, watch list addition, no automated response.
This tiering prevents the situation where a cloud provider's IP gets blocked because a previous tenant used it for spam two months ago. It also keeps high-confidence hits from getting buried in a queue full of low-signal alerts that trained the team to skim rather than investigate.
Behavioral Correlation as Reputation Corroboration
When an IP with a medium or low reputation flag appears in your logs, behavioral signals from your own environment should either elevate or suppress the concern. Useful behavioral signals to correlate include:
- Connection frequency and timing patterns relative to business hours
- Volume of distinct internal endpoints being reached from the same external IP
- Protocol behavior that does not match the declared service (HTTP sessions carrying non-HTTP payloads, for example)
- User-agent strings and TLS fingerprints that appear inconsistent with expected client behavior
- Geolocation drift, where the same session ID or user account is simultaneously active from IPs resolving to different continents
An IP with a low reputation score that is also connecting to nineteen internal endpoints over six hours deserves escalation regardless of what the threat feed says about it. The behavioral signal supersedes the reputation gap.
Operationalizing Threat Intelligence Beyond the Blocklist
Most organizations implement IP reputation as a blocklist, and blocklists have a place in the stack. The problem is that blocklists represent a passive, reactive control. They stop known bad. They do not catch unknown bad, and as the ESET H1 2026 data confirms, attackers increasingly operate from unknown-bad infrastructure.
Enrichment Workflows in the SIEM
Every inbound and outbound connection log should carry enriched metadata before it reaches a correlation rule. That enrichment should include the current reputation status of the IP, the ASN it belongs to, the country of registration versus the country of geolocation, whether it is a known hosting provider, VPN exit, or Tor exit node, and the age of the first-seen date for that IP in your environment.
When analysts see this context alongside the raw log data, they make faster and more accurate decisions. An alert that shows an IP connected to your mail server, that the IP belongs to a major cloud provider's ASN, that it has no reputation flags, but that the specific /28 subnet it sits in has no prior history in your environment and made forty-seven connections in four minutes carries far more actionable information than a simple source IP and port number.
Proactive Hunting Using Reputation Clusters
Threat intelligence feeds often include infrastructure clusters, ASNs, or hosting providers disproportionately associated with malicious activity. Proactive hunting queries against your SIEM can surface historical connections to these clusters even when no individual IP was flagged at the time of the connection.
A practical hunting query structure would pull all outbound connections over the past thirty days to IP ranges belonging to hosting ASNs that appear more than some threshold frequency in your threat feeds, then filter for connections that occurred outside business hours or to ports not associated with approved business services. This surfaces infrastructure that flew under the detection radar at the time of the connection but can now be evaluated in light of updated intelligence.
Feedback Loops Back Into Feed Quality
Organizations that only consume threat intelligence feeds without contributing back operate at a disadvantage relative to their own detection capability. Submitting confirmed malicious infrastructure to feeds you consume, even through informal mechanisms like community forums or formal ISACs relevant to your sector, improves the quality of the data everyone works from.
The Unlimited Technology Systems breach and the student loan breach that exposed 2.5 million records both involved attacker infrastructure that appeared clean at the point of initial contact. Post-incident reporting from affected organizations is one of the primary mechanisms by which that infrastructure eventually gets flagged, protecting the next potential victim. The community intelligence model works when organizations treat it as bidirectional.
Real-World Scenario: Compromised IoT Devices as Reputation Laundering Infrastructure
The growing market for access to compromised surveillance cameras and IoT devices creates a specific threat pattern worth addressing directly. When attackers route campaign traffic through residential and commercial IoT devices, the source IPs carry the reputation of the device owner rather than the attacker.
Detection in this scenario shifts away from reputation entirely and toward behavioral fingerprinting. Surveillance cameras and consumer IoT devices have consistent traffic patterns: regular small keep-alive packets, defined connection intervals to their management infrastructure, predictable protocol behavior. When a device with that kind of baseline IP suddenly sends high-frequency outbound HTTP requests to a domain registered two weeks ago, the behavior diverges from the baseline even though the IP reputation remains clean.
This is where internal network monitoring becomes a reputation complement rather than a reputation replacement. Endpoint visibility, internal east-west traffic monitoring, and DNS query logging can surface the anomaly that reputation-based perimeter controls cannot see.
Incident Response Integration
When a confirmed malicious IP appears in your environment, the incident response workflow should include reputation context as part of the triage package, but the response scope should extend beyond what the reputation data describes.
Infrastructure Expansion Queries
A confirmed malicious IP should immediately trigger queries against your logs for all other IPs in the same /24 subnet, all IPs registered to the same ASN that have appeared in your logs, and all domain names that resolved to the flagged IP or to adjacent IPs in the same range over the past ninety days. Attackers commonly use adjacent infrastructure for different campaign phases, and blocking a single IP while the rest of the campaign infrastructure goes unexamined leaves the operational gap open.
Timeline Reconstruction
Reputation flags carry timestamps that indicate when an IP was first observed behaving maliciously in the feeds. Compare that timestamp against your own log data for that IP. If your logs show connections from the IP predating the reputation flag by days or weeks, your environment may have been targeted before the broader community had intelligence about that infrastructure.
This timeline reconstruction serves two purposes. First, it defines the true scope of the incident rather than the scope that the reputation flag suggests. Second, it identifies whether your environment was an early target of a campaign, which has implications for threat actor profiling and for what other organizations in your sector may not yet know they are facing.
Preserving Forensic Value
Blocking a malicious IP immediately eliminates the forensic visibility you would get from monitoring the connection for a controlled period. In cases where you have confirmed malicious activity and are in a position to do so safely, allowing monitored connections to continue briefly under controlled conditions can reveal additional infrastructure, communication patterns, and attacker objectives that immediate blocking destroys.
This approach requires executive and legal alignment before the incident occurs. Building it into your incident response playbook in advance means the conversation about evidence preservation versus risk reduction happens before 3 AM rather than during it.
Feed Maintenance as an Ongoing Operational Task
Threat intelligence feeds require maintenance that most organizations underinvest in. Stale blocklists block legitimate services and create business friction. Outdated feeds miss active infrastructure. The operational cadence for feed hygiene should include the following practices.
Review false positive reports from your team at least weekly. When analysts document that a blocked IP turned out to be a legitimate service, that record should feed a review of the source that flagged it and the confidence weighting applied to that source. Consistent false positives from a specific feed indicate that its confidence ratings need downward recalibration in your environment.
Audit blocklist age regularly. IPs blocked more than ninety days ago based on threat intelligence flags should be reviewed for continued relevance before auto-renewal. Cloud infrastructure turns over fast enough that an IP flagged as malicious in Q1 may be hosting a legitimate application by Q3.
Track feed latency explicitly. Some feeds update in near-real-time. Others have update cycles measured in days. Knowing the update frequency of each feed in your stack lets you calibrate your reliance on it for time-sensitive decisions. A feed with a 72-hour update cycle should not be the primary data source for automated blocking decisions on active campaigns.
What Mature Programs Do Differently
Organizations with mature threat intelligence programs treat IP reputation as one input into a broader context-building process rather than as a verdict. They invest in feed diversity and normalization infrastructure. They build behavioral correlation rules that work independently of reputation data and use reputation data to accelerate triage rather than replace it. They participate in sector-specific ISACs and contribute observed infrastructure to the community. They run regular exercises that specifically test their detection capability against clean-IP attacker infrastructure to identify the gaps that reputation-only approaches leave open.
The teams that consistently catch sophisticated campaigns earlier have built a habit of asking not just whether an IP is flagged, but what the full context of its behavior in their environment tells them that the flag status does not. That habit, embedded in detection playbooks and analyst training, is what turns threat intelligence from a checkbox into a genuine defensive capability.
Practical Takeaways for Security and IT Teams
- Consume at least three independent IP reputation feeds and normalize them into a common confidence framework before using the data for automated actions.
- Define action thresholds by confidence tier, not by binary flag presence.
- Enrich every connection log with ASN data, hosting provider type, IP age in your environment, and current reputation status before correlation rules fire.
- Build hunting workflows that query historical log data against updated threat intelligence retroactively, not just at the time of the original connection.
- Treat IoT device traffic patterns as behavioral baselines and alert on deviations from those baselines independent of IP reputation status.
- Maintain blocklist hygiene on a defined schedule, including age-based review of long-standing blocks and false positive analysis from analyst feedback.
- Contribute confirmed malicious infrastructure back to the feeds and communities you consume from.
- When an IP is confirmed malicious, immediately expand queries to adjacent infrastructure in the same subnet and ASN before scoping the incident response.
