C2 Intelligence gives you visibility into the infrastructure attackers rely on after a successful exploit — the servers that deliver malware payloads, host staged files, and orchestrate command and control. This guide covers how to put that intelligence to work across three core workflows: C2 detection, SIEM/SOAR enrichment, and historical investigation.

Use Case 1: C2 Detection from Outbound Traffic

Most perimeter security focuses on inbound threats: blocking scanners before they reach you. C2 Intelligence inverts that model. Instead of looking at who's knocking at your door, you're looking at whether anything inside your environment is calling out to known attacker infrastructure.

The workflow is straightforward:

1. Log all outbound egress traffic from your edge devices (firewalls, proxies) to your SIEM.
2. Create a correlation rule that matches destination IPs against the C2 dataset.
3. Use the attack stage of the matched IP to drive your response.

Understanding Attack Stages

Unconfirmed: GreyNoise observed this IP in a scanner payload but could not successfully download a file from it. An outbound hit here is suspicious and worth investigating, but not conclusive. Check whether the affected machine shows other signs of compromise before escalating.

Stage 1 — File Downloaded: GreyNoise confirmed this IP is actively serving file payloads. If a machine in your environment is making outbound connections to a Stage 1 IP address, treat it as likely compromised. Begin your investigation immediately and determine whether a payload was delivered and whether the host needs to be isolated.

Stage 2 — C2 Suspected: This IP is suspected to be part of a command-and-control chain, based on a weighted analysis of VirusTotal detections, sandbox network activity, and malware associations. An outbound connection to a Stage 2 IP indicates the attacker has progressed deeper into the kill chain — past initial delivery, into post-exploitation communication. At this point, assume the attacker is active in your environment. Lateral movement and persistence are the next steps.

📘

Tip

Callback IP detail pages include the malware family and file hashes (SHA256, SHA1, MD5) for any files GreyNoise successfully downloaded from a Stage 1 or Stage 2 IP. Use those hashes in your EDR or SIEM to identify which endpoints may have received the payload.

Use Case 2: SIEM and SOAR Enrichment

C2 Intelligence is designed to integrate naturally into existing security workflows. Because the dataset is available via an API, you can enrich inbound log data at scale and drive differentiated automation by stage.

In your SIEM, use the C2 dataset as a high-value correlation source alongside your standard outbound egress logs. A basic rule matches destination IPs against the callback list and enriches matching events with the stage field and associated metadata. Configure alert severity to reflect the stage: a Stage 2 match warrants a higher-priority alert than an unconfirmed one.

In your SOAR, the stage field enables you to branch your playbooks meaningfully:

• Stage 1 match → Open a case, isolate the endpoint, initiate targeted investigation.
• Stage 2 match → Escalate immediately, page the IR team, trigger auto-containment, run deeper triage.

📘

Tip

The C2 dataset can also be integrated at the IP lookup level. Callback stage and associated metadata are surfaced on standard IP detail pages for IPs that appear in both the scanner and C2 datasets, so your existing IP enrichment workflows will surface this data without additional configuration.

🚧

Important

Because C2 intelligence is derived from payload analysis rather than direct scanning observation, a callback IP may return "not observed" in a standard IP lookup if it has no scanner history. Use the dedicated callback API endpoint or the Callback tab in the Visualizer for reliable access to callback-specific data.

Use Case 3: Historical Investigation and Retrospective Analysis

Callback infrastructure ages differently from scanner infrastructure. Scanning IPs are transactional; they rotate frequently, often within days or weeks. Callback and malware-hosting infrastructure tend to be more durable because they have to remain reachable to be useful. An IP that served payloads six months ago may have been part of a sustained campaign that you're only now investigating.

This makes callback data particularly valuable for retrospective analysis, enabling a look back at historical traffic to determine whether a host was communicating with known attacker infrastructure before an incident was detected.

Practical examples:

• Incident retrospective: You're investigating a compromise and trying to establish a timeline. Match historical outbound logs against the C2 dataset to determine when a host first contacted a known malware-hosting IP.
• Threat hunting: You've identified a callback IP in a new threat report. Use the callback_ips GNQL parameter to find which scanner IPs have referenced that destination in their payloads, surfacing the full set of attackers associated with that infrastructure.

callback_ips:175.107.3.226

The callback_ipsGNQL query above returns all scanner IPs whose payloads reference the specified callback destination. This is useful for understanding the campaign scope and identifying which scanners were delivering payloads that pointed to the same downstream infrastructure.