When a machine on your network is infected with malware, it rarely operates in isolation. Almost every modern malware family phones home to a command-and-control (C2) server — an external IP address that issues instructions, receives stolen data, and coordinates the botnet. That C2 server is the brain. If you can get it taken down, every bot in the network loses its ability to receive commands.
This is why reporting C2 infrastructure matters so much. A single abuse report that leads to a server takedown can neutralize thousands of compromised machines at once. I have seen hosting providers null-route C2 servers within hours of receiving a well-documented report, instantly severing the attacker's control channel.
This article is part of my complete guide to reporting IP abuse. Here I focus specifically on identifying, documenting, and reporting malware and botnet C2 traffic.
How to Identify C2 Traffic
C2 traffic is designed to blend in, but it always leaves traces. Here are the indicators I look for when investigating potential C2 activity on a network.
DNS Beaconing Patterns
Most C2 frameworks use DNS for initial communication or as a fallback channel. Beaconing shows up as periodic DNS queries to the same domain at regular intervals — every 30 seconds, every 5 minutes, or with slight jitter to avoid detection.
# DNS query log showing beaconing pattern
2025-04-26 14:00:01 192.168.1.45 A update-check.x8kd2m.example.net
2025-04-26 14:05:03 192.168.1.45 A update-check.x8kd2m.example.net
2025-04-26 14:10:01 192.168.1.45 A update-check.x8kd2m.example.net
2025-04-26 14:15:02 192.168.1.45 A update-check.x8kd2m.example.net
The consistent timing and the domain structure (random-looking subdomain under a recently registered domain) are classic beaconing signatures. Use DNS Inspector to examine the DNS records for suspicious domains — newly registered domains with no legitimate web presence are a strong indicator.
Unusual Outbound Connections
Watch for connections to IPs with no corresponding legitimate service, especially on uncommon ports. C2 traffic often uses ports like 443 (to blend with HTTPS), 8080, 8443, or entirely non-standard ports in the high ranges.
# Firewall log showing suspicious outbound connections
SRC=192.168.1.45 DST=185.234.72.19 PROTO=TCP DPT=443 LEN=124
SRC=192.168.1.45 DST=185.234.72.19 PROTO=TCP DPT=443 LEN=89
SRC=192.168.1.45 DST=185.234.72.19 PROTO=TCP DPT=443 LEN=3847
Small, regular outbound packets followed by occasional larger transfers suggest a check-in/command pattern. The bot sends a short heartbeat, and the C2 occasionally responds with a larger payload containing instructions or exfiltration requests.
EDR and IDS Alerts
If you are running an EDR solution (CrowdStrike, SentinelOne, Defender for Endpoint) or network IDS (Suricata, Snort, Zeek), these tools often flag C2 traffic directly. Suricata rules from Emerging Threats and Proofpoint maintain signatures for known C2 frameworks like Cobalt Strike, Metasploit, Sliver, and commodity malware families.
Threat Intelligence Feed Correlation
Cross-reference suspicious IPs against threat intelligence feeds. Services like abuse.ch's ThreatFox, VirusTotal, and AlienVault OTX maintain databases of known C2 infrastructure. If an IP your host is contacting appears in these databases, you have strong confirmation of C2 activity.
Evidence Gathering Checklist
Before you file a report, you need evidence that will convince an abuse desk to act. Vague complaints get ignored. Detailed, timestamped evidence gets servers taken down. Here is what I collect before writing a C2 abuse report.
Network Captures (PCAP)
Capture the actual traffic between the infected host and the C2 server. Even a few minutes of packet capture provides concrete proof.
# Capture traffic to/from the suspected C2 IP
tcpdump -i eth0 host 185.234.72.19 -w c2_capture_20250426.pcap -c 5000
If the traffic is encrypted (TLS), the packet capture still shows connection timing, frequency, data volumes, and TLS certificate details — all useful evidence.
DNS Query Logs
Export DNS logs showing the beaconing pattern. The regularity and domain structure tell the story.
# Extract queries to suspicious domain from DNS logs
grep "x8kd2m.example.net" /var/log/named/query.log > c2_dns_evidence.txt
Firewall and Flow Logs
Firewall logs and NetFlow/sFlow data showing connection patterns over time. This establishes the persistence and regularity of the C2 communication.
Threat Intelligence Correlation
Document what threat intelligence sources flag the IP. Include links to VirusTotal reports, ThreatFox entries, or Shodan data. If you can identify the specific malware family, include the malware name and any known MITRE ATT&CK technique IDs.
Malware Sample Hashes
If you have recovered the malware binary from the infected host, include its SHA-256 hash. This allows the abuse team to verify the threat independently.
Malware sample SHA-256: a1b2c3d4e5f6...
VirusTotal: https://www.virustotal.com/gui/file/a1b2c3d4e5f6.../detection
Detection rate: 52/71 engines
Family: Emotet (Epoch5)
Indicators of Compromise (IOCs)
Compile a concise IOC list: IP addresses, domain names, URLs, file hashes, and any unique TLS certificate fingerprints associated with the C2 infrastructure.
Finding the Abuse Contact
Every IP address is allocated to an organization that is responsible for what happens on their network. To file a report, you need to find the right abuse desk.
Use the IP Location tool to look up the C2 server's IP address. The results will show you the hosting provider or ISP, the ASN, and the geographic location. From there, look up the abuse contact.
For most networks, the abuse contact is listed in the WHOIS record under abuse-mailbox or OrgAbuseEmail. You can also query the WHOIS data directly:
whois 185.234.72.19 | grep -i abuse
# abuse-mailbox: [email protected]
Many bulletproof hosting providers deliberately make abuse contacts hard to find or simply ignore reports. If you suspect the C2 is hosted on bulletproof infrastructure, skip directly to reporting through threat intelligence platforms and CERTs, which I cover below.
C2/Malware Abuse Report Template
When writing your abuse report, be specific, technical, and factual. Here is a template I use:
Subject: Malware C2 Server - Active Botnet Command-and-Control on [IP ADDRESS]
To: [email protected]
Dear Abuse Team,
I am reporting active malware command-and-control (C2) infrastructure
hosted on your network.
C2 Server IP: 185.234.72.19
Port(s): 443/TCP
Protocol: HTTPS (Cobalt Strike Beacon)
First observed: 2025-04-22 08:14 UTC
Last observed: 2025-04-26 14:15 UTC
Status: Currently active
Malware family: Cobalt Strike (version 4.9, watermark 123456789)
MITRE ATT&CK: T1071.001 (Application Layer Protocol: Web Protocols)
Evidence summary:
- Infected hosts beacon to this IP every 5 minutes over HTTPS
- TLS certificate CN: "Microsoft Update" (self-signed, SHA-1: AB:CD:EF:...)
- Traffic pattern: 100-200 byte POST requests, occasional 2-5 KB responses
- IP flagged on ThreatFox (ID: 98765), VirusTotal (45/91 detections)
- Beaconing observed from multiple independent networks
DNS indicators:
- C2 domain: update-check.x8kd2m.example.net
- Resolves to: 185.234.72.19
- Domain registered: 2025-04-20 via NameCheap
- No legitimate web content at this domain
I have attached a packet capture (c2_capture_20250426.pcap) and
DNS query logs demonstrating the beaconing pattern.
This server is actively controlling compromised machines and should
be taken offline immediately to disrupt the botnet operation.
Please confirm receipt and let me know if you need additional evidence.
Regards,
[Your Name]
[Your Organization]
[Contact Information]
Where to Report C2 Infrastructure
C2 servers warrant a broader reporting approach than a typical abuse complaint. I report to multiple channels simultaneously.
ISP/Hosting Provider Abuse Desk
Always start here. The hosting provider has the most direct ability to take the server offline. Send your report to the abuse contact email identified through WHOIS.
Threat Intelligence Sharing Platforms
These platforms aggregate reports from researchers worldwide and feed into automated blocklists:
- abuse.ch ThreatFox — submit IOCs at threatfox.abuse.ch. Feeds into the abuse.ch ecosystem used by thousands of organizations.
- abuse.ch URLhaus — if the C2 uses HTTP/HTTPS URLs, submit them here.
- MalwareBazaar — submit malware samples linked to the C2.
- VirusTotal — upload malware samples and flag malicious IPs/domains.
- AlienVault OTX — share pulse reports with the broader threat intelligence community.
National CERTs
For significant botnet activity, report to your national CERT team. CERTs coordinate across borders and can apply pressure that individual abuse reports cannot. See my guide on reporting security incidents to CERT teams for details on the process.
Law Enforcement
For large-scale botnets causing widespread damage, consider reporting to law enforcement. In the US, the FBI's IC3 (ic3.gov) handles cybercrime reports. Europol's EC3 coordinates across EU member states. Law enforcement involvement is what led to takedowns of Emotet, Trickbot, and QakBot.
Sub-Scenarios
HTTP/HTTPS C2 Beaconing
This is the most common C2 channel today. The malware makes regular HTTP POST requests to a web server controlled by the attacker, often mimicking legitimate API calls or software update checks. The traffic blends in with normal HTTPS traffic, making it harder to detect without TLS inspection or behavioral analysis.
Key evidence: TLS certificate details (often self-signed or using free certificates with suspicious CNs), URL paths, request timing patterns, and HTTP headers. Many C2 frameworks like Cobalt Strike use malleable profiles that mimic legitimate services — look for subtle inconsistencies in HTTP headers or response patterns.
DNS-Based C2 (DNS Tunneling)
Some malware families encode commands and data within DNS queries and responses, using TXT, CNAME, or even A records as a covert communication channel. This is particularly insidious because DNS traffic is rarely blocked or inspected. For a deeper technical explanation, see my article on DNS tunneling attacks.
# DNS tunneling indicators - encoded data in subdomain labels
TXT query: aGVsbG8gd29ybGQ.c2.malicious-domain.net
TXT query: dGhpcyBpcyBkYXRh.c2.malicious-domain.net
The subdomain labels contain base64-encoded data. Reporting DNS-based C2 requires reporting both the IP address hosting the authoritative DNS server and the domain registrar responsible for the domain.
IRC-Based Botnets
Older but still active, IRC-based botnets connect to IRC servers (typically port 6667 or non-standard ports) and join specific channels to receive commands. These are easier to detect because IRC traffic is unusual on most corporate networks.
Evidence collection is straightforward: capture the IRC connection, document the server, port, channel name, and any commands observed. Many IRC botnets are unencrypted, making packet inspection simple.
Tor-Based C2
Some sophisticated malware routes C2 traffic through Tor hidden services, making the actual C2 server's IP address invisible. In this case, you cannot report the C2 server directly. Instead, focus on:
- Reporting the Tor exit nodes being used (if identifiable) to the Tor Project's abuse channels
- Sharing IOCs (hidden service .onion addresses, malware hashes) with threat intelligence platforms
- Working with law enforcement, who have capabilities to deanonymize hidden services in some cases
What to Expect After Reporting
Takedown timelines vary dramatically depending on the hosting provider.
Reputable hosting providers (major cloud providers, established hosting companies) typically respond within 24-48 hours and take action within 1-5 business days. Many have automated abuse processing that can act even faster.
Offshore or smaller hosting providers may take 1-2 weeks or may not respond at all. Follow up after 7 days with your original report plus any new evidence collected in the interim.
Bulletproof hosting providers intentionally ignore abuse reports. For C2 hosted on bulletproof infrastructure, your best strategy is upstream reporting — contact the provider's upstream bandwidth providers and transit peers, and coordinate through CERTs and threat intelligence platforms that maintain relationships with these networks.
If the C2 server is taken down, the attacker will likely set up a new one. Many malware families have fallback C2 addresses or domain generation algorithms (DGAs). Continue monitoring and be prepared to file follow-up reports. This is also why reporting to threat intelligence platforms matters — it feeds automated detection that catches infrastructure as it spins up.
If a compromised legitimate server is being used as C2 infrastructure, the hosting provider's response is usually faster since their own customer is also a victim. Similarly, if the C2 traffic is part of a larger DDoS operation, mention that in your report — it escalates priority.
Prevention Tips
Reporting C2 infrastructure is reactive. Here is what I recommend for proactive defense against C2 communication.
Network segmentation — isolate critical systems so that if one machine is compromised, the malware cannot spread laterally or reach the internet directly. Force all outbound traffic through monitored chokepoints.
DNS filtering — use DNS-based threat protection (Quad9, Cloudflare Gateway, Cisco Umbrella) that blocks queries to known malicious domains. This stops many C2 callbacks at the DNS layer before a TCP connection is even established.
EDR deployment — modern endpoint detection and response tools detect C2 frameworks by behavioral signatures, not just known hashes. They catch the process injection, named pipes, and memory patterns that C2 agents use.
TLS inspection — for environments where policy allows it, inspecting outbound TLS traffic reveals C2 communication that hides behind encryption. Deploy cautiously with proper certificate management.
Egress filtering — restrict outbound connections to only necessary destinations and ports. Most workstations do not need to make arbitrary outbound connections on port 443 to unknown IPs.
Threat intelligence integration — feed threat intelligence into your firewall and proxy rules automatically. When a new C2 IP is identified by the community, your network should block it before any internal host tries to contact it.