From C2 Detection to Possible Victim Identification

One of the questions I hear most often is: Can Team Cymru identify possible victims of malicious infrastructure?

The answer is yes—when we have sufficient network telemetry covering the infrastructure involved.

It’s an important nuance. Identifying command-and-control infrastructure is only one part of the problem. The next—and often more valuable—question is whether we can observe systems consistently communicating with that infrastructure in a way that may indicate infection or compromise.

Turning controller intelligence into victim insight

The Total Insights Feed includes behavioral tags designed to help answer that question.

When an IP address is identified as command-and-control infrastructure, we can evaluate available NetFlow observations for sustained, high-confidence interactions with that controller. When the behavior meets our analytic criteria, the communicating IP may be tagged as a possible bot associated with the relevant malware or C2 family.

For example, an IP interacting with infrastructure attributed to the Sliver C2 framework could receive a tag such as sliver-bot.

This creates two practical workflows:

• A security team can check its organization’s IP ranges against the Total Insights Feed to identify systems that may have communicated with known malicious controllers.
• An analyst investigating a controller can review associated bot tags to identify potential downstream victims and better understand the infrastructure’s operational reach.

These observations should not be treated as definitive proof of compromise. They are high-value investigative leads that can help teams prioritize validation, containment, and response.

Why this changes the investigation

Traditional infrastructure intelligence often stops at identifying a suspicious server, domain, or open service.

That is useful—but defenders still have to determine whether the infrastructure affected them.

Behavioral tagging moves the investigation closer to the outcome security teams actually need: understanding whether a system within their environment may be communicating with known attacker infrastructure.

Instead of beginning with a complex sequence of searches, pivots, and enrichment steps, a customer can evaluate its network ranges against intelligence that has already been classified and contextualized.

For an MSSP, SOC, incident-response team, or threat-intelligence function, this can significantly reduce the time between infrastructure discovery and action.

Detection becomes more valuable over time

The value compounds as new command-and-control families are identified.

Each time our detections team develops a reliable way to identify a new family of malicious infrastructure, we can begin evaluating the telemetry available around it. That may reveal likely related infrastructure, higher-tier management, recurring communication patterns, and potential victim activity.

This is not a single detection or one-time query. It is an incremental system of classification and labeling built across multiple forms of internet telemetry, including:

• NetFlow observations
• Open ports and service fingerprints
• Custom internet probes
• Infrastructure relationships
• Analyst-developed detections and validation

We think that combination is important. Scanning can help identify infrastructure that looks like a controller. Network telemetry can help reveal how that infrastructure is actually being used.

Without sufficient traffic visibility, a provider may be able to identify a possible C2 server but remain unable to observe meaningful interactions with it. With that visibility, infrastructure intelligence can begin to answer a much more consequential question:

Who may be affected?

Visibility is the foundation.

This capability is ultimately grounded in data visibility.

Detection logic, classification, and automation are essential, but their effectiveness depends on the underlying telemetry. The broader and more representative the visibility, the more confidently analysts can evaluate infrastructure behavior over time.

That is what turns a list of suspicious IP addresses into something operationally useful: intelligence that helps defenders identify possible exposure, accelerate investigations, and act before a weak signal becomes a larger incident.

The goal is not simply to describe malicious infrastructure.

It is to help defenders understand what that infrastructure is doing—and what they should investigate next.