Command-and-control detection is MetaDefender NDR's earliest-warning layer. Where Suricata signatures match how a conversation looks on the wire, the C2 family matches who the conversation is with — every observed destination IP and every DNS query name is checked against a curated feed of known threat-actor infrastructure. A match is rarely ambiguous: an internal host that resolves or contacts an entry on the C2 feed is almost always compromised, so the pipeline raises these detections at the top of the severity scale and carries the IOC evidence inline with the alert so analysts can act without pivoting.
First-use acronym expansions in this chapter: C2 (command-and-control), IOC (Indicator of Compromise), IP (Internet Protocol), DNS (Domain Name System), FQDN (Fully Qualified Domain Name), TLS (Transport Layer Security), SNI (Server Name Indication), JA3 / JA4 (TLS client fingerprint formats), ASN (Autonomous System Number), FRD (Functional Requirements Document), MVP (Minimum Viable Product).
What It Is
The C2 detection family is an enrichment service running in the MetaDefender NDR Manager pipeline. It maintains two in-memory indicator lists — a set of malicious IP addresses and a set of malicious DNS names — loaded from the OPSWAT Eyelet threat intelligence feed and refreshed on an hourly cadence. Every DNS record and every flow record that the sensors emit passes through the service; any match against the loaded lists produces an entity-level enrichment that the aggregator stitches back onto the originating event, and the alert engine promotes the enriched event to a dedicated C2 alert. The enrichment data stays attached to the event for the life of the record, so the match is visible on the Hunt page long after the alert has been triaged.
What It Detects
The family covers three complementary observables that together characterize early-stage compromise:
- Outbound connections to known-bad IP addresses. An internal host's flow record lists a destination IP that appears on the C2 IP feed — an active Cobalt Strike team server, a remote administration trojan panel, a known phishing landing page, or a staging host for a named intrusion campaign.
- DNS resolution of known-bad domains. An internal host's DNS query resolves a name that appears on the C2 domain feed. DNS catches intent before a connection opens; the query itself is evidence that a compromised host or user-initiated process is attempting to reach threat-actor infrastructure.
- Resolved-IP reachback. A DNS response's A-record answer contains an IP on the C2 IP feed. This catches the case where the queried name is unknown but resolves to known-bad infrastructure.
The shipped indicator categories include malware C2 frameworks (Cobalt Strike, Sliver, Mythic, Metasploit Meterpreter, Havoc), named campaign infrastructure (nation-state clusters such as REF7707, Mustang Panda, APT28, and others tracked by the OPSWAT Analyst Network), commodity trojan panels, and phishing-kit landing pages. Every indicator carries its own threat description, confidence rating, and first-seen / last-seen timestamps sourced from Eyelet.
TLS certificate hash, subject-name, and issuer matching — and JA3 / JA4 TLS client-fingerprint matching — are intentionally not covered by this family. Both are handled by the Suricata engine directly through published rules in the OPSWAT InSights rulepack, so they surface as Suricata signatures and are documented in Suricata Signatures.
How It Works
The pipeline moves a candidate observation through four stages:
- Indicator load. At startup, the C2 enrichment service loads the current IP and DNS indicator lists from disk. The lists are refreshed hourly by a background updater that pulls the latest feed from Eyelet; no redeployment is required to adopt a new indicator. Indicators are held in memory as hash-table lookups so match time is constant regardless of list size.
- Event consumption. The service consumes every DNS event and every flow event from the raw sensor stream. Other event types (HTTP, TLS, SMB, and so on) are skipped at this stage — DNS covers the resolution surface and flow covers the connection surface, which together are sufficient to detect both detection modes listed above.
- Exact-match lookup. For DNS events, the service lowercases every
dns.queries[].rrnameand every A-record answer and looks them up against the in-memory indicator sets. For flow events, it looks up the destination IP. The DNS lookup is exact-match only: an indicator forevil.example.comdoes not match a query forsub.evil.example.com. Parent-domain hierarchy matching is the job of the InSights enrichment family and is covered in InSights TIDB and REPDB. Port-specific IP indicators (entries of the formIP:PORT) match only when both IP and port match; port-agnostic indicators match any port. - Entity enrichment and alert promotion. When a lookup hits, the service attaches a per-entity enrichment block to the matched field —
dest_ip_enrichments.c2on a flow,dns.queries[].rrname_enrichments.c2on a DNS query,dns.grouped.A_enrichments.c2on a DNS answer. The enrichment carries the match type, the indicator details (value, source feed, score, confidence, description, first-seen, last-seen), and ahas_c2_match: trueflag. The aggregator stitches the enrichment back onto the event; the alert engine's C2 rule fires on any enriched event; and the alert engine emits a C2 alert at Critical severity and 0.99 confidence.
The two match kinds described in the Breach Detection FRD — a C2 IP Alert for IP-layer hits and a C2 DNS Alert for DNS-layer hits — are distinguished by the match_type field on the alert's c2.matches[] payload ("ip" or "ip_from_dns" versus "dns"). Both are surfaced under the C2 Infrastructure Alert sub-tab on the Hunt page and both render the same C2 Enrichment sidebar section.
Trigger Conditions
A C2 alert fires when the enrichment service produces a match and the alert engine's C2 rule sees a truthy has_c2_match on any entity in the merged event. The fields below are what analysts read when triaging the alert.
| Field | Meaning |
|---|---|
c2.matches[] | List of indicator matches attached to the alert. Typical count is one; multiple entries occur when the same event carries several matched entities (for example, a DNS answer with two A records, both on the feed). |
c2.matches[].type | Match kind: "dns" (DNS query name hit), "ip" (flow destination IP hit), or "ip_from_dns" (IP in a DNS A-record answer hit). |
c2.matches[].value | The indicator value from the feed — the canonical IP or FQDN as it appears in the Eyelet list. |
c2.matches[].matched | The exact value that was matched in the event — normally identical to value, but preserved separately because case-folding and trailing-dot normalization may apply. |
c2.matches[].score | Threat score from the feed on a 0–10 scale (10 is most severe). |
c2.matches[].confidence | Feed-native confidence on a 0–100 scale. Note: this is the indicator-level confidence published by Eyelet; the alert-level confidence is always 0.99 under IOC auto-escalation. |
c2.matches[].source | Feed-source identifier (for example, labs-c2 for indicators curated by the OPSWAT Analyst Network). |
c2.matches[].description | Human-readable description of the indicator — commonly names the malware family, actor cluster, and external reference article. |
c2.matches[].created, last_seen | First and last observation timestamps from the feed — useful context on whether the indicator is fresh or historical. |
c2.matches[].matched_port, required_port | Populated only for port-specific IP indicators; the port that matched and the port the indicator required. |
The alert also carries every standard Suricata-shaped field (timestamp, flow_id, src_ip, src_port, dest_ip, dest_port, proto, alert.signature, alert.signature_id, alert.severity, alert.category, and MITRE ATT&CK metadata where applicable) so that analysts can pivot into protocol logs and packet capture exactly as they would on a signature-based alert.
Severity Classification
C2 alerts are always raised at Critical severity. This is the family's defining behavior: a match against the curated Eyelet feed is treated as a confirmed-threat signal, not a candidate for further triage.
| Trigger | Unified Severity |
|---|---|
Any c2.matches[] entry present on the alert (match_type of dns, ip, or ip_from_dns). | Critical |
The IOC auto-escalation rule described in Detection Overview is what drives this behavior — a C2 feed hit satisfies the auto-escalation trigger by definition, so every C2 alert is pulled to Critical regardless of what the upstream event's severity would otherwise have been. A flow record that was previously benign (for example, a low-volume 443-only HTTPS flow) becomes a Critical alert the moment its destination IP matches the feed.
Confidence Scoring
C2 alerts are always raised at 0.99 confidence. The confidence scale defined in Detection overview reserves the 0.95–0.99 band for IOC matches and extreme values, and every C2 alert lands in this band by construction.
| Trigger | Alert confidence |
|---|---|
| Any C2 feed hit. | 0.99 |
Analysts should not confuse the alert's 0.99 confidence with the c2.matches[].confidence feed value. The feed value describes the vendor's confidence in the indicator; the alert value describes the pipeline's confidence in the detection. An indicator with feed confidence 70 still produces a 0.99 alert — the match is binary and the pipeline treats every hit with the same gravity.
Where It Surfaces
C2 alerts appear in four places.
- Dashboard — Recent Severities donut. Every C2 alert contributes a Critical slice to the donut. The Top Signature Hits widget is Suricata-only and does not include C2 alerts.
- Dashboard — Recent Alerts. Newest C2 alerts flow through the cross-family feed. Clicking a row opens the same sidebar used on the Hunt page.
- Hunt page — C2 Infrastructure Alert sub-tab. Under the All Alerts bucket, this per-type sub-tab lists every C2 alert with columns for
timestamp,alert.signature, source and destination endpoints,event_type,c2.match_type,c2.matched,c2.confidence,c2.score, andc2.source. Both the C2 IP match and the C2 DNS match kinds are listed here; analysts filter by thec2.match_typecolumn to narrow to one kind. - Hunt detail sidebar — C2 Enrichment section. This section renders on any row whose record carries a
*_enrichments.c2block — not just the C2 alert rows. A DNS session row that matched the C2 feed shows the DNS section alongside the C2 Enrichment section, even though the row itself is a session event rather than a C2 alert; a flow row with a destination-IP hit does the same. The section lists each match with the full indicator payload inline. When the matched entity is also geolocated, the sidebar's ASN and GeoIP enrichment renders alongside so analysts see the destination's country, ASN, and organization without leaving the record.
On the Hunt page's Sessions tab, the c2 column injects a small enrichment ribbon on every DNS, HTTP, TLS, Flow, and protocol-log row that carries a match — analysts do not have to open a record to see that it is C2-adjacent.
Alert Payload Example
Abbreviated JSON for a C2 DNS match. The underlying event is a standard Suricata DNS query; the alert adds the c2 payload and the alert block, and the alert engine sets alert_type: "c2" and severity 1.
{ "timestamp": "2025-11-15T08:42:17.334821+0000", "flow_id": 1847291847291847, "event_type": "alert", "alert_type": "c2", "src_ip": "192.168.10.157", "src_port": 51023, "dest_ip": "10.0.0.53", "dest_port": 53, "proto": "UDP", "app_proto": "dns", "community_id": "1:8K3vN7pL5mQ2rT9uV1wX3yZ5", "alert": { "action": "allowed", "gid": 1, "signature_id": 1000001, "rev": 1, "signature": "MetaDefender NDR C2 DNS Match — update.hobiter.com", "category": "A Network Trojan was Detected", "severity": 1 }, "dns": { "type": "query", "queries": [ {"rrname": "update.hobiter.com", "rrtype": "A"} ] }, "c2": { "matches": [{ "type": "dns", "value": "update.hobiter.com", "matched": "update.hobiter.com", "score": 10, "confidence": 90, "source": "labs-c2", "description": "REF7707 infrastructure — espionage cluster suspected to be related to a Chinese state-sponsored threat actor group. Reported infrastructure includes malware staging, C2, and data exfiltration endpoints used by multiple backdoor trojans.", "created": "2025-04-08T00:41:07Z", "last_seen": "2025-10-17T14:51:02Z" }] }, "rule_name": "C2InfrastructureDetection", "rule_salience": 10, "triggered_at": "2025-11-15T08:42:17.498112Z"}A C2 IP match looks the same with two differences: the dns block is replaced by a flow block carrying the five-tuple counters, and the c2.matches[].type field is "ip" (or "ip_from_dns" when the destination was learned from a DNS A-record answer rather than from the flow itself). A single alert can carry multiple c2.matches[] entries — for example, a DNS response whose answer set contains two A records that both appear on the feed.
Tuning Considerations
The C2 family is deliberately low-knob. The indicator lists are curated upstream and trust in the feed is part of the family's design; operators do not suppress individual indicators the way they suppress noisy Suricata signatures. The Policy-managed knobs that do exist are scoped to the service and to the feed:
- Enable or disable the C2 enrichment service. Operators toggle the enrichment on or off through Policy. Disabling the service leaves the pipeline running — no crash, no dropped events — and suppresses all downstream C2 alerts. See (Link Removed) for the per-policy enrichment toggle.
- Feed update cadence. The default update interval is one hour. Operators on constrained networks may lengthen it; teams running high-sensitivity environments may shorten it. The feed-update workflow, the manual-trigger procedure, and the distribution-status dashboard all live in Updates management.
- Port-specific indicators. A small number of IP indicators carry a
:PORTqualifier. These match only when both IP and port match, so lateral port rotation by an attacker can evade them. Operators who want coarser matching should treat port-specific indicators as strict and complement them with additional behavioral coverage (Long Duration Flow, Beaconing — see Behavioral Detections).
False-positive behavior is rare and usually traceable to recycled infrastructure — an IP or a domain that was indicator-worthy at some point and has since been reclaimed by a benign tenant. When an analyst confirms a false positive, the correct response is to flag the indicator for upstream review; local suppression is not the MetaDefender NDR pattern for this family.
Related Runbook
Every Critical-severity C2 alert starts with (Link Removed). Follow-on investigation for C2 DNS and C2 IP matches uses (Link Removed) — the runbook walks through identifying the originating host, correlating the C2 match with surrounding beaconing or long-duration-flow evidence from Behavioral Detections, pivoting to the full flow and packet capture via (Link Removed), and confirming whether any payload was transferred before containment.