C2 Beacon Investigation

This runbook is the family-specific continuation of Critical Alert Triage for any alert whose evidence points at command-and-control (C2) activity. It covers the two cases an analyst encounters most often: a Beaconing Detection Alert that surfaced the periodicity of an outbound connection, and a C2 Infrastructure Alert that matched the destination or a resolved name against the OPSWAT Eyelet feed. Either alert type routes here from the step-6 hand-off in the generic runbook, and the steps below take the analyst from "an alert with C2-shaped evidence" to "a triage decision recorded in the incident-management system".

This runbook is written for Tier 1 Security Operations Center (SOC) analysts performing first-response triage on outbound-traffic alerts, Tier 2 analysts resolving escalations, and threat hunters pivoting from a beacon lead into a broader compromise investigation. It assumes the analyst has already executed Critical alert triage through step 5 — the affected asset, the supporting sidebar evidence, the repetition history, and any same-flow corroboration are already in hand.

First-use acronym expansions in this runbook: C2 (command-and-control), SOC (Security Operations Center), IOC (Indicator of Compromise), IP (Internet Protocol), DNS (Domain Name System), TLS (Transport Layer Security), SNI (Server Name Indication), ASN (Autonomous System Number), GeoIP (geographical IP lookup), DGA (Domain Generation Algorithm), RAT (remote-access trojan), RFC-1918 (the Internet Engineering Task Force standard reserving private IP ranges), STDDEV (standard deviation), CV (coefficient of variation), MVP (Minimum Viable Product), RDP (Remote Desktop Protocol), SSH (Secure Shell), NXDOMAIN (Non-Existent Domain DNS response), IR (incident response), VPN (Virtual Private Network), SaaS (Software-as-a-Service), EDR (endpoint detection and response), TTL (Time To Live), TIDB (Threat Intelligence Database), REPDB (Reputation Database).

Trigger Scenario

An analyst opens the Hunt Page, navigates to the All Alerts bucket, and sees one of the following rows. In either case, the analyst has advanced into the detail sidebar and the generic Critical alert triage runbook has identified the alert as a candidate for this family-specific continuation.

A Beaconing Detection Alert on the Beaconing Detection Alert sub-tab. The row carries a connection count, a byte coefficient of variation, a server-response ratio, a four-hour window, and a destination ASN. The severity may be Critical, High, Medium, or Low depending on connection count and whether an IOC has matched on the destination.
A C2 Infrastructure Alert on the C2 Infrastructure Alert sub-tab. The row is always Critical / 0.99 confidence (the IOC auto-escalation rule guarantees this), and the C2 Enrichment sidebar section carries an indicator match against an IP, a DNS query name, or an IP resolved from a DNS answer (match_type of ip, dns, or ip_from_dns).

The two trigger surfaces converge in this runbook because the investigation is the same: both describe an internal host talking to an external endpoint in a way that resembles active C2. A C2 Infrastructure Alert on its own identifies the indicator but not always the cadence; a Beaconing Detection on its own identifies the cadence but not always the infrastructure. A lead on either surface prompts the analyst to look for the other.

Prerequisites

Before executing this runbook the analyst confirms the following.

Steps 1 through 5 of Critical Alert Triage are complete. The affected asset, its owner and criticality tier, the sidebar evidence summary, and any repetition or same-flow correlation already live in the incident ticket.
A Hunt session open on the originating Beaconing Detection Alert or C2 Infrastructure Alert tab, with the alert's detail sidebar visible.
Access to the organization's asset inventory for the affected host.
A working mental model of the organization's routine outbound traffic — which corporate Software-as-a-Service (SaaS) endpoints are in daily use, which vendor cloud services the endpoint detection and response (EDR) and patching agents contact, and which office locations or remote sites use Virtual Private Network (VPN) concentrators whose traffic may resemble beacon patterns.
Access to the incident-management system used by the SOC.

Missing any of these is a hard stop. A beacon investigation run without asset context or without the Critical-triage baseline tends to either over-escalate legitimate software-update traffic or under-escalate genuine compromise — both failure modes are avoidable with the prerequisites in place.

Investigation Steps

Each step is numbered, adds a distinct piece of evidence, and feeds the decision tree at the end. The analyst executes steps in order even when the verdict looks obvious early; a C2 disposition is never safely recorded on partial evidence.

On the Hunt page, the analyst clicks the alert row to open the detail sidebar. The section that matters depends on which trigger surface produced the alert.

C2 Infrastructure Alert. The C2 Enrichment section lists one or more c2.matches[] entries. For each entry the analyst records the match type (dns, ip, or ip_from_dns), the value (the indicator as it appears in the feed), the matched field (the exact value observed in the event), the score on the 0–10 threat scale, the confidence on the feed's 0–100 scale, the source feed identifier, the description naming the malware family or actor cluster, and the created and last_seen timestamps. Port-specific indicators carry matched_port and required_port; when present, both are recorded.
Beaconing Detection Alert. The Beaconing Detection section lists connection_count, unique_flows, avg_bytes_per_flow, avg_packets_per_flow, cv_bytes (coefficient of variation — standard deviation (STDDEV) divided by mean), server_response_ratio, window_start and window_end, first_seen, last_seen, malicious_iocs and iocs_checked, and the destination's dest_country, dest_asn, and dest_org.

Either way the base network section above these carries src_ip, src_port, dest_ip, dest_port, proto, app_proto, and the community_id correlator. The analyst captures the full base record so subsequent pivots have a reference point.

2. Examine the source and destination endpoints

The source IP is the affected internal host — identified and profiled in step 2 of Critical alert triage. The destination is the prospective C2 endpoint. The analyst characterizes the destination along four axes before pivoting any further:

Address class. An RFC-1918 destination is almost never C2 in an MVP-scope MetaDefender NDR deployment; the Beaconing pipeline excludes RFC-1918 destinations by construction (see C2 Beacon Investigation), and a C2 Infrastructure Alert against an RFC-1918 destination points at a recycled or private-space indicator that warrants a note to the feed curators rather than an incident. External destinations pass to the next axes.
Port and protocol. A beacon on Transmission Control Protocol (TCP) port 443 that negotiates TLS is the common shape; a beacon on TCP port 80 carrying plaintext Hypertext Transfer Protocol (HTTP) is less common and more suspicious; a beacon on an unusual port (8080, 8443, 4444, 1337, or a random high-numbered port) with an app_proto of null or failed is highly suspicious because beacon frameworks frequently hand-roll the transport. Remote-administration ports (SSH 22, RDP 3389, Windows Management Instrumentation 5985 / 5986) as destinations from a non-administrative host are anomalous on their own.
Name resolution lineage. If the alert is a C2 DNS match (match_type: dns) the destination is a domain name; if it is match_type: ip_from_dns the IP was learned from a DNS answer earlier in the same flow. The analyst follows the Show all events with this community id pivot (see step 4) to find the DNS query that produced the resolution and records the fully-qualified name.
Known-good exceptions. Legitimate corporate SaaS endpoints, EDR vendors, patching infrastructure, and telemetry collectors often resemble beacons (see Common False-Positive Patterns). When the destination falls into one of these categories by ASN or reverse DNS, the analyst records the identification and continues — the verdict is not yet reached but the corroborating evidence required for escalation is now higher.

3. Evaluate the beacon timing and payload uniformity

The beacon is a timing pattern, and the sidebar exposes the numbers that make the pattern visible. The analyst examines the following fields from the Beaconing Detection section (or the equivalents, if the alert is a C2 Infrastructure Alert that happens to carry a beacon block on the same event).

connection_count. The total number of connections the pipeline saw in the four-hour hopping window. Fifteen is the minimum threshold; fifty-plus is Critical by construction. Recurrent connection counts in the thirties and forties across several windows are a strong beacon signal even when no single window reaches Critical on its own.
cv_bytes. The byte coefficient of variation over the window. Coefficient of variation below 0.10 means payloads are nearly identical in size — the fingerprint of a small, templated beacon check-in. Values up to 0.25 are still consistent with beacons; above 0.40 the uniformity argument weakens and the pattern is likely human-driven browsing or software with variable-length payloads.
avg_bytes_per_flow and avg_packets_per_flow. Beacons are small. Average flow sizes in the 100-byte to 2-kilobyte range and average packet counts in single digits are characteristic. Flows averaging tens of kilobytes with high packet counts point at file transfer or interactive session rather than beacon check-in.
Inter-arrival interval. The sidebar does not render the raw interval directly, but it can be derived: (window_end − window_start) / connection_count produces the average period. A period in the tens-of-seconds-to-minutes range with low variance is beacon-shaped; intervals that cluster around exact multiples of a minute (every sixty seconds, every five minutes, every fifteen minutes) are the strongest timing signal because only a timer-driven process produces that regularity.
server_response_ratio. Defined by the pipeline as total_server_packets / (connection_count × 5); a ratio below 0.20 means the server sent fewer than five packets per connection on average, which matches the tasking-channel shape where the implant polls and receives a small acknowledgement or a short task.

A destination that scores on three or more of these fields — high and steady connection_count, low cv_bytes, low avg_bytes_per_flow, a rounded-period interval, and a low server_response_ratio — is behaving like a beacon regardless of whether the IOC feed has flagged the endpoint. The analyst records the scoring explicitly in the ticket; "connection_count 47 over one hour with cv_bytes 0.08, average flow 312 bytes, period 76.6 seconds, server response ratio 0.11" is the kind of note that survives handoff.

4. Pivot to the flow view filtered by the source-destination pair

From the alert sidebar the analyst right-clicks community_id and selects Show all events with this community id. A new All Events tab opens on the Hunt Page filtered to every protocol transaction, flow record, file extraction, and enrichment that belongs to the same connection. This view reveals what the summary detection's windowed aggregate cannot:

The individual flow rows. Each flow record carries timestamp, bytes_toserver, bytes_toclient, pkts_toserver, pkts_toclient, flow.duration, and the flow-end reason. The analyst scrolls through the list and looks for the regularity that generated the beacon alert — rows at similar byte counts separated by similar intervals — and for outlier rows carrying disproportionately larger payloads, which may indicate the moment a tasking channel turned into data transfer.
TLS sessions on the same connection. Every TLS handshake renders with the Server Name Indication (SNI), the certificate subject and issuer, and the JA3 / JA4 client fingerprint. Beacons often reuse a specific SNI across thousands of connections and produce an identical JA3 fingerprint every time; recognizing the fingerprint is the single fastest confirmation of a known malware family.
HTTP sessions on the same connection. Beacons that ride plaintext HTTP expose the full request — method, Uniform Resource Identifier, User-Agent, and response content-type. Uniform User-Agent strings with atypical versioning, GET or POST requests to short numeric paths, and response bodies of nearly-identical size across hundreds of requests are characteristic.
DNS resolutions that preceded the flow. When the destination was reached by name, the DNS query and answer sit on the same community_id. The analyst reads the resolved name, the answer set, and the answer Time To Live (TTL); a very low TTL is a fast-flux indicator (see step 8).

If the connection is inspectable (plaintext HTTP, DNS) the session evidence usually resolves the ambiguity on its own. If the connection is encrypted (TLS) the session evidence narrows the hypothesis but does not prove it; the next steps check the destination population to add independent evidence.

The analyst then opens a second tab using the right-click pivot Hunt all events from this IP on the source IP and widens the time range to Last 7 days. This tab shows every conversation the affected host has held with any external destination. A host beaconing to one destination is a compromise signal; a host beaconing to one destination while also making clean outbound traffic to routine SaaS endpoints helps the analyst judge whether the beacon is an anomaly against an otherwise-normal pattern or whether the entire host is degraded.

5. Check the destination's GeoIP and ASN

The sidebar's network enrichment section carries the destination's country (dest_country), Autonomous System Number (dest_asn), and organization (dest_org). These three fields carry substantial triage signal on their own.

Unexpected geography. A host in a corporate finance function beaconing to a destination in a country the business does not operate in is a strong signal. High-signal geographies vary by organization; most analysts maintain a mental list of the low-expected-traffic regions for their environment.
Hosting ASN versus content ASN. Destinations that resolve to bulletproof or low-reputation hosting providers — regional hosting specialists that are frequently named in threat reports — add weight to the C2 hypothesis. Destinations that resolve to known cloud providers (Amazon Web Services, Microsoft Azure, Google Cloud, Cloudflare, Akamai, DigitalOcean, Linode, Oracle, Hetzner, OVH) are ambiguous — threat actors rent cloud infrastructure heavily, so the ASN rules neither in nor out.
Organization name reverse-lookup. The dest_org field often identifies the operator. When the organization is a recognizable corporate SaaS provider (for example, Microsoft Corporation, Google LLC, Apple Inc., Cloudflare, Zscaler, or a known EDR vendor), the false-positive hypothesis rises. When the organization is a generic reseller or an unknown entity, the indicator-driven hypothesis holds.

Geography and ASN on their own almost never drive a disposition; they tip the weight between the indicator hypothesis and the false-positive hypothesis. The analyst records the reading and moves on.

6. Check for IOC enrichment on the destination

This is the single strongest disposition lever in the runbook. The alert sidebar carries the C2 Enrichment section whenever any feed match fired; the Insights Enrichment section carries parallel matches from the OPSWAT InSights Threat Intelligence Database (TIDB) and Reputation Database (REPDB) feeds.

Any c2.matches[] entry present. The alert is IOC-Critical by construction. Severity is Critical, alert-level confidence is 0.99, and the match payload identifies the threat actor or malware family the indicator belongs to. This finding on its own is sufficient for escalation to incident response (see Decision Tree).
Beaconing pipeline malicious_iocs > 0 with iocs_checked > 0. The behavioral pipeline's independent IOC check observed a feed hit on the destination during the window. The pipeline auto-escalates its own severity to Critical when this field is truthy. Confidence on the alert rises to 0.99 under the same auto-escalation rule.
Parallel InSights match on the destination IP or DNS name. See InSights TIDB and REPDB for the feed semantics. A TIDB hit (threat intelligence) is high-confidence; a REPDB hit (reputation) is lower-confidence but still material in aggregate.
No IOC match on any feed. The alert is threshold-Critical (or sub-Critical) on behavioral evidence alone. The case for escalation now depends on the timing evidence in step 3, the session evidence in step 4, the ASN reading in step 5, and the blast-radius evidence in the next step.

A C2 Infrastructure Alert by definition reaches this step with an IOC match (the alert cannot fire without one). A Beaconing Detection Alert may or may not. The analyst records the IOC state explicitly in the ticket — "IOC match present on dest_ip / dns query name / neither" — because it is the single field that changes downstream dispositions.

7. Check the destination across the rest of the network

A beacon destination that only one internal host contacts is a host-scoped compromise; a beacon destination that many internal hosts contact is an environment-scoped event that is either a coordinated compromise or a benign shared service. Blast radius is a decisive piece of evidence.

From the alert row the analyst right-clicks the destination IP (or the destination domain for a DNS-match alert) and selects Hunt all events from this IP (or runs a quick search on the domain in a new All Events tab). The time range expands to Last 24 hours or Last 7 days as appropriate. The analyst reads the result:

One source only. The compromise is host-scoped. Escalation, isolation, and forensic recovery target the affected host.
A small handful of sources, all in the same business unit. Check whether the hosts share a common software baseline (same EDR agent, same patching policy, same internal build image). If they do and the behavior matches a known vendor, the false-positive hypothesis rises; if they do not, the shared behavior is a coordinated-compromise signal and the blast radius is redrawn to include the whole set.
Many sources across business units. Two possibilities dominate. Either the destination is a routine vendor endpoint that happened to land on a feed (a known false-positive pattern, usually resolved by recognizing the vendor identity in step 5), or the destination is serving a campaign-scale compromise that is already lateral. The analyst does not decide between these on population size alone; the IOC state in step 6 and the vendor identity in step 5 usually resolve the ambiguity.

8. Examine the domain name for DGA characteristics

This step applies only when the destination was reached by name — that is, when a DNS query preceded the flow (alert's match_type is dns or ip_from_dns, or the Show all events with this community id pivot in step 4 surfaced a DNS record). For bare-IP flows with no resolved name, the analyst skips this step.

The analyst reads the queried name from the DNS Session section in the sidebar or from the DNS row in the pivoted All Events tab. Several characteristics raise suspicion of a Domain Generation Algorithm (DGA) — an algorithm that manufactures hundreds or thousands of candidate domains per day so the operator can rotate through them:

Random-looking second-level label. Names like xz8kqt4p7vg2rx.example or qwertyuiopasdfghjk.example consist of characters with high entropy and no pronounceable structure. Contrast against legitimate domains whose labels pronounce as words or abbreviations.
Consistent label length. DGA families often produce labels of a fixed length; several queries to aaaaaaaaaa.example, bbbbbbbbbb.example, cccccccccc.example all with the same length strongly suggests a rotation.
Unusual top-level domain. Country-code top-level domains and niche top-level domains — .xyz, .top, .click, .info, .cc, .ws, .su, .tk — are disproportionately represented in DGA tooling because they are inexpensive to register.
Short answer TTL. Fast-flux infrastructure holds answer TTLs to a few seconds or tens of seconds so the resolved IP can rotate rapidly. A five-second TTL on a domain whose purpose is legitimately long-lived is anomalous.
High Non-Existent Domain (NXDOMAIN) ratio for the parent. Pivoting on the parent (second-level) domain and filtering the DNS Session tab for the last hour reveals whether the parent is serving many non-existent subdomains — a DGA fingerprint that the separate DGA Detection from Behavioral detections will itself flag on its own cadence.

A domain that meets several of these criteria is strong corroborating evidence for a C2 hypothesis. A domain that meets none — a short, pronounceable, branded name under a mainstream top-level domain — is weak evidence for DGA but does not rule out C2 on legitimate-looking fronting infrastructure (threat actors purchase expired domains whose prior reputation was benign).

Decision Tree

The analyst records one of four outcomes. Each branch lists the minimum artifacts captured before the ticket is closed.

Escalate — confirmed or probable C2. The disposition when any of the following holds: the alert is IOC-Critical (any c2.matches[] entry or malicious_iocs > 0) and the blast radius is host-scoped or coordinated-compromise-scoped; the alert is threshold-Critical on Beaconing evidence (fifty-plus connections with cv_bytes under 0.10) on a Tier 1 or Tier 2 asset with corroborating session evidence (recognizable JA3, suspicious SNI, uniform HTTP pattern); or two or more independent indicators converge (IOC hit on destination, plus a suspicious DGA-shaped name, plus a server-response ratio below 0.20). The analyst opens an incident response (IR) ticket, requests endpoint isolation for the affected host, hands the host off to forensic recovery, blocks the destination at the perimeter if the organization's policy allows indicator-based blocking, and transfers the evidence record and pivot tabs into the incident. The Escalate branch is where this runbook ends and incident-response procedures take over.
Monitor — suspicious but not conclusive. The disposition when the evidence is partial: a Beaconing alert with moderate connection counts and no IOC hit, or a C2 Infrastructure Alert on a destination that is a recognized cloud provider, or a matching pattern on a Tier 3 asset with no corroborating signals. The analyst records the observation in the ticket, leaves the Hunt tabs open, schedules a follow-up review (typically within four to twelve hours for Critical severity and twenty-four hours for sub-Critical), and watches for re-occurrence. If the pattern recurs within the review window, the analyst re-enters at step 1 with the accumulated context and re-evaluates; if the pattern does not recur and no new corroboration surfaces, the disposition moves to close as benign.
Close as benign — identified legitimate explanation. The disposition when the evidence positively identifies a recognized pattern: the destination is a confirmed corporate SaaS endpoint (Microsoft, Google, Apple, Zscaler, the organization's EDR vendor) with a matching dest_org and a matching client identity (User-Agent, JA3 fingerprint); the pattern matches a known software-update client; or a red-team or vulnerability-scanning program owns the activity. The analyst records the specific fields that justify the conclusion in the ticket — "destination 52.84.0.0/15, Amazon Web Services CloudFront, JA3 fingerprint matches internal EDR agent, pattern consistent with telemetry check-in" is the shape of a defensible close-note — so later readers can reopen the conclusion if one of those fields changes.
Tune the rule — recurring benign pattern with a scoped policy fix. The disposition when the same benign pattern has been confirmed multiple times across the same population, the source of the noise is understood (a specific vendor's telemetry, a specific internal management workflow), and the policy system supports a scoped exclusion. Tuning is a detection-engineering action, not a triage shortcut: the analyst opens a follow-up task against the detection's policy definition rather than tuning inline, submits the change through the organization's peer-review workflow, and keeps the alert live until the tuned policy deploys. The default disposition for a single confirmed-benign alert is close, not tune — a single occurrence does not justify reducing coverage.

Every branch is recorded in the incident-management system. The runbook reference, the disposition, the asset context, the indicator or timing evidence, and the pivot tab references form the minimum record. When the disposition is Escalate, the record hands off directly into the incident.

Common False-Positive Patterns

A non-trivial share of Beaconing and C2 Infrastructure alerts have benign explanations. Recognizing the patterns saves investigation time and keeps analysts from over-escalating.

Software-update and telemetry beacons. Operating-system update agents, browser update channels, EDR agents, antivirus update services, and vendor telemetry clients check in to well-known infrastructure on a fixed schedule. The shape — regular interval, uniform payload, high connection count, low server-response ratio — is indistinguishable from a C2 beacon without the destination context. The destination ASN and organization usually identify the vendor (Microsoft, Apple, Google, Cloudflare, Akamai, a specific EDR vendor). Disposition: close with the vendor identity recorded. If the same vendor produces sustained alert volume across many hosts, the SOC opens a tuning task against the Beaconing policy.
Push-notification services. Mobile device management and push-notification infrastructure (Apple Push Notification Service, Firebase Cloud Messaging, corporate mobile-device management servers) maintain persistent outbound connections with small, periodic keepalives that score on every Beaconing metric. The client identity is usually visible in the TLS SNI and JA3 fingerprint. Disposition: close when the client and destination are recognized.
VPN concentrators and remote-desktop gateways. Always-on VPN clients and remote-desktop gateway keepalives produce long-duration, regularly-spaced traffic that resembles beaconing on flow metadata alone. The destination is usually the organization's own VPN endpoint or a known commercial VPN provider, and the community_id pivot surfaces the VPN handshake. Disposition: close once the VPN identity is confirmed.
Recycled indicators and indicator false positives. Occasionally a domain or IP that was indicator-worthy at one point has been reclaimed by a benign tenant and the feed has not yet retired the entry. The destination's current reverse DNS, HTTP hostname, or TLS certificate subject identifies the new owner. Disposition: close and file a feed-review request upstream; local suppression is not the MetaDefender NDR pattern for this family (see C2 and Threat Intelligence).
Cloud-fronted services sharing IPs with known-bad tenants. A Cloudflare, Akamai, or Amazon Web Services IP may carry legitimate traffic on one hostname and malicious traffic on another. A Beaconing alert on a shared IP with no SNI or hostname evidence is ambiguous; the session data from step 4 resolves the ambiguity by surfacing the actual requested name. Disposition: close when the name is benign and documented in the ticket; escalate when the name is missing or matches a suspicious pattern.
Red-team, penetration-testing, and attack-simulation activity. Authorized internal testing produces Critical C2 alerts by design — tools like Cobalt Strike, Sliver, and Mythic are the calibration targets for the C2 family. Disposition: close once the activity is confirmed with the red-team or vulnerability-management program. Every SOC maintains a communication channel with internal testing teams so these alerts are identifiable on sight.
Network-monitoring and synthetic-transaction agents. Synthetic-monitoring probes, uptime-check services, and internal network-monitoring agents make many small, regularly-spaced outbound connections that score as beaconing. The destination and client identity usually identify the monitor. Disposition: close with the monitoring identity recorded.

Closing on a false-positive pattern still requires the runbook's evidence record. "Looks like a software update" is not a disposition; "destination Microsoft Update, ASN 8075, User-Agent Windows-Update-Agent/10.0, JA3 cd08e31494f9531f560d64c695473da9, closing as benign" is.