Critical Alert Triage

This runbook is the general-purpose first-response procedure for any Critical-severity alert in MetaDefender NDR, regardless of which detection family raised it. It runs before any family-specific runbook and determines whether the alert warrants escalation, ongoing monitoring, closure, or a rule-tuning action. When the alert belongs to a family that has its own runbook, this runbook hands off to it at step 6.

This runbook is written for Tier 1 Security Operations Center (SOC) analysts handling the first pass on an alert queue. Tier 2 and Tier 3 analysts use it when opening an alert forwarded from Tier 1 to confirm the upstream triage before deeper investigation. It assumes familiarity with the Hunt Page workspace and the six detection families described in (Link Removed).

First-use acronym expansions in this runbook: SOC (Security Operations Center), IOC (Indicator of Compromise), C2 (command-and-control), TIDB (Threat Intelligence Database), REPDB (Reputation Database), RCF (Random Cut Forest), AV (antivirus), IP (Internet Protocol), TLS (Transport Layer Security), SNI (Server Name Indication), DNS (Domain Name System), ASN (Autonomous System Number), RFC-1918 (the Internet Engineering Task Force standard reserving private IP ranges), SID (Signature Identifier), PCAP (packet capture), MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), DHCP (Dynamic Host Configuration Protocol), ARP (Address Resolution Protocol), PUA (potentially-unwanted application), NAT (Network Address Translation), BGP (Border Gateway Protocol), EDR (endpoint detection and response).

Trigger Scenario

An analyst sees a Critical-severity alert surface in one of two places:

The Recent Alerts widget on the Dashboard, where the row carries a red Critical severity badge.
The All Alerts tab on the Hunt page, where the analyst is working through a severity-sorted queue.

The alert may come from any detection family — a Suricata signature match, a C2 Infrastructure Alert, an InSights Alert, an MDCore Alert, a Behavioral Detection, or an ML Random Cut Forest Anomaly. What the alert has in common across families is the severity label: the unified severity scale sets Critical only when a detection carries an IOC match or clears the highest family-specific threshold (see Detection Overview). Every Critical warrants this runbook before any disposition is recorded.

Prerequisites

Before executing the runbook the analyst confirms the following.

A signed-in MetaDefender NDR session with a role that grants Hunting access.
Access to the organization's asset inventory or host directory so the affected endpoint can be identified by business function, owner, and criticality. The inventory is outside MetaDefender NDR on the MVP end-state.
Access to the incident-management system used by the SOC (ticket tracker, paging platform, or case-management tool). Every Critical triage produces a record in that system regardless of outcome.
If the alert is an MDCore Alert, a mental model of the organization's file-scanning policy — which hosts are allowed to receive executables and what the whitelisted software-distribution paths are. If the alert is a C2 or InSights alert, awareness of which third-party Software-as-a-Service (SaaS) endpoints are in routine use so legitimate destinations are not misread as malicious infrastructure.

Missing any of these is a hard stop. The investigation cannot be completed without an asset context or an escalation channel.

Investigation Steps

Each step is numbered, adds a distinct piece of evidence, and feeds the decision tree at the end. The analyst executes the steps in order; skipping is tempting when the verdict looks obvious, but a Critical-severity disposition is never safe to record on partial evidence.

1. Open the alert and confirm severity provenance

The analyst clicks the Recent Alerts row on the Dashboard — which mounts the Hunt detail sidebar in place — or selects the row on the Hunt page's All Alerts tab to open the sidebar there. The sidebar header shows the alert type, the severity label, and the confidence score.

The first question is why the alert is Critical, because Critical on MetaDefender NDR has two distinct meanings:

IOC-Critical. The sidebar carries a C2 Enrichment Section or an InSights Enrichment Section with a matched entity, source feed, and score. The unified pipeline auto-escalates any detection with an IOC match to severity Critical and confidence 0.99. The detection's native threshold is secondary in this case — a 16-connection Beaconing alert is Critical because its destination is on the C2 feed, not because 16 connections is high.
Threshold-Critical. The sidebar carries no IOC enrichment. The alert reached Critical on the detection family's own threshold — for example, 50-plus connections in a Beaconing window, six-plus positive AV engines on an MDCore scan, a Suricata signature with native severity 1, or a Data Exfiltration with a 10-to-1 upload ratio and 100-plus megabytes uploaded.

The distinction changes what the rest of the investigation looks for. IOC-Critical investigations center on the indicator — where else on the network is anyone communicating with it, what feed tagged it, does it corroborate another detection on the same host. Threshold-Critical investigations center on the behavior — what the metrics look like, whether the pattern is recurrent, whether a legitimate explanation exists.

2. Confirm the affected asset and its business criticality

The analyst reads the source and destination endpoints on the sidebar's base network section. At least one endpoint is an internal host that is either the victim (incoming Suricata signature, inbound scan) or the infected party (outbound beaconing, outbound data exfiltration, outbound DNS tunneling, file download). That internal host is the affected asset.

The analyst identifies the host in the organization's asset inventory and records three attributes before proceeding:

Owner — which team or user is responsible for the host.
Function — what the host does (domain controller, finance workstation, build server, guest Wi-Fi device, operational-technology gateway, Internet of Things sensor).
Criticality — whether the host is Tier 1 (business-critical, elevated blast radius), Tier 2 (important but not single-point-of-failure), or Tier 3 (commodity endpoint). Tier 1 hosts change the decision tree — a plausibly-benign alert on a domain controller is still escalated for confirmation; the same alert on a guest Wi-Fi device is more readily closed.

If the source is an RFC-1918 address that does not appear in the inventory, the analyst checks for a DHCP lease mapping or a recent ARP observation before proceeding; ghost endpoints on internal subnets are a known blind spot and the alert cannot be dispositioned correctly without an identity.

The sidebar renders a type-specific view of the event with every block the record carries (see Hunt Page). The analyst scans every section top to bottom and records the evidence that justifies the Critical rating. Which sections matter depends on the family.

Suricata Alert section. Signature message, SID, category, MITRE ATT&CK technique and tactic, action (alert or drop), and the printable payload. The analyst reads the signature message to understand the matched behavior, notes the MITRE technique for cross-referencing, and inspects the payload for visible indicators (encoded strings, exploit-framework fingerprints, suspicious user agents).
C2 Enrichment section. Match type (IP or DNS), matched value, confidence, score, and source feed. The analyst captures the matched entity — it is the centerpiece of the indicator-pivot in step 4.
InSights Enrichment section. Matched entity, feed tagging (TIDB, REPDB, or both), and any additional threat-feed context.
MDCore Enrichment section. Scan result, threat name, positive engines over total engines, scan details per AV engine, and file metadata (SHA-256, filename, size, type). The analyst records the hash and threat name.
Behavioral Alert section. Detection-specific metadata: connection count, byte standard deviation and coefficient of variation, upload and download totals, upload ratio, window bounds, destination country, destination ASN, destination organization, and IOC match status.
ML Anomaly fields. Anomaly score, threshold crossed, model version, and the underlying event type (DNS, HTTP, or Flow). For ML anomalies, the supporting evidence is the underlying event payload rather than a family-specific field block — the analyst reads the network-base section of the underlying event to understand what was anomalous.

Any blocks that are absent tell the analyst something too. A Behavioral Detection with no C2 or InSights enrichment is threshold-Critical and warrants a harder look at the behavior metrics. A C2 Infrastructure Alert with no Beaconing section means the indicator fired on a one-off connection rather than a sustained pattern.

4. Check for repetition on the same source or destination

Before the analyst asks is this threat real?, the analyst asks has this happened before? A recurring pattern changes the disposition — a first-time alert may be a one-off event, but the same alert firing on the same source for the tenth time in a week is a sustained problem.

From the alert row or sidebar, the analyst right-clicks the source IP and selects Hunt all events from this IP. A new Hunt Page tab opens on All Events filtered to that IP. The analyst widens the time range to Last 7 days and reviews:

Prior alerts on the same source — same type, different type, any severity. Count them and note the detection families.
Whether the current alert's destination appears repeatedly in the source's recent history — recurrent contact with the same external endpoint over days is a strong signal for C2 beaconing or long-running tunneling.
Whether other sources on the internal network have been observed talking to the same destination — a shared external indicator across multiple internal hosts raises the blast radius.

The analyst then repeats the pivot on the destination IP or destination domain — Hunt all events from this IP or a quick-search on the domain in a new All Events tab. This answers the symmetric question: is anyone else on the network currently communicating with the same external endpoint? The pivot is especially important for IOC-Critical alerts, where the external indicator is the anchor and the affected population may extend far beyond the originating host.

Tab persistence preserves these pivot tabs across the investigation so the analyst can return to the original alert and to each pivot view without losing state.

5. Correlate with other detection signals on the same flow

Multi-signal convergence is the single strongest basis for escalation (see Investigation Runbooks). The analyst checks whether other detection families fired on the same connection.

From the alert row or sidebar, the analyst right-clicks the community_id column and selects Show all events with this community id. A new All Events tab opens with every protocol transaction, flow record, file extraction, and enrichment that shares the connection's 5-tuple correlator. The analyst scans the tab for:

Other alert rows on the same flow — a Beaconing Detection that co-occurs with a Suricata signature alert and a C2 Enrichment is three signals on one connection, not one.
Session records (DNS, HTTP, TLS, FileInfo) that expose payload metadata. The analyst checks for:
- TLS SNI, certificate subject, and JA3 / JA4 fingerprints that indicate malicious tooling.
- HTTP hostnames, user agents, and response content types inconsistent with the traffic's declared purpose.
- DNS query names that resolved to the destination — a meaningful domain name changes the read of a bare-IP alert.
- FileInfo extractions tied to the same flow — files downloaded or uploaded during the alerting window.
The Flow record — total bytes, packet counts per direction, flow duration, and abnormal termination reasons.

A single-family alert with no corroborating signals on the same flow is a weaker hypothesis than a multi-family cluster. The analyst records the corroborating signal count and notes which families contributed.

6. Hand off to the family-specific runbook

At this point the analyst has a full picture of the alert: its severity provenance (IOC or threshold), the affected asset and its business criticality, the supporting sidebar evidence, the repetition history on both endpoints, and any correlating signals on the same flow. The final investigation step is to apply the family-specific runbook for deeper evidence-gathering before making a disposition.

Alert Family	Runbook
Beaconing Detection, C2 Infrastructure Alert (IP or DNS), any Critical carrying a C2 Enrichment	C2 Beacon Investigation
Data Exfiltration Detection, any Critical with an anomalous upload-ratio pattern	Data Exfiltration Investigation
MDCore High, Medium, or Low AV Detection; any Critical with an MDCore enrichment carrying `threat_found`	ML Anomaly Investigation
ML Random Cut Forest Anomaly	ML Anomaly Investigation
DNS Tunneling Detection or DNS Tunneling Hourly aggregate	Tunneling Investigation
Suricata Alert, InSights Alert (not combined with any of the above), or any family not covered by a dedicated runbook	Continue this runbook to the decision tree

The Alert, Flow, and PCAP Pivoting meta-runbook documents the pivot patterns every family-specific runbook uses and is the reference for any pivot step whose motion is unfamiliar.

Decision Tree

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

Escalate. The evidence indicates a confirmed or probable threat. Escalation is the disposition when any of the following holds: the alert is IOC-Critical (C2 or InSights match) on a Tier 1 or Tier 2 asset; the alert is threshold-Critical and at least one additional detection family corroborates on the same flow or the same source over the trailing seven days; an MDCore alert reports a found threat with six or more positive engines; a Suricata signature of native severity 1 fires with corroborating behavioral or enrichment evidence. The analyst opens an incident ticket with the alert identifier, the asset identity, the sidebar evidence summary, the pivot tab references, and the corroborating signals. The runbook hand-off at step 6 resumes inside the incident.
Monitor. The evidence is suggestive but not conclusive — single-signal alerts, IOC-Critical on a low-criticality asset with no prior history, or threshold-Critical with no repetition and no corroboration. The analyst leaves the Hunt tab and pivot tabs open, records the current observations in the ticket, and schedules a follow-up review — typically within four to twelve hours for Critical severity. If the pattern recurs, the analyst re-enters at step 1 with the accumulated context; if the pattern does not recur within the review window, the disposition moves to close as benign.
Close as benign. The evidence positively identifies a legitimate explanation — the destination resolves to a known corporate SaaS endpoint, the file hash is a legitimate installer from a whitelisted update channel, the beaconing pattern is a software-update client checking in, the long-duration flow is a monitored Virtual Private Network (VPN) tunnel, the anomaly score reflects a known environment change (new subnet, new load balancer). The analyst records the specific fields that justify the conclusion in the ticket — for example, "destination 52.84.0.0/15 is AWS CloudFront, confirmed by ASN enrichment; user agent matches internal software update client" — so later readers can reopen the conclusion if one of those fields changes.
Tune the rule. The same benign pattern has been confirmed multiple times across the same population, the source of the noise is understood, 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.

Every branch is recorded in the incident-management system. The runbook reference, the disposition, the asset context, the evidence summary, and the pivot tab references form the minimum record.

Common False-Positive Patterns

Critical alerts produce a recurring set of false positives across deployments. Recognizing the patterns saves investigation time and prevents the analyst from over-escalating.

Software-update beacons. Operating-system update agents, browser update channels, EDR agents, and telemetry clients check in to well-known infrastructure on a schedule that looks like C2 beaconing — regular intervals, uniform payload sizes, and high connection counts over long windows. The destination ASN and reverse DNS usually identify the vendor — Microsoft, Apple, Google, Cloudflare, Akamai, or a specific EDR vendor — and the IOC feeds do not flag them. Triaged as close with the vendor identity recorded; tuned via policy only if the same software covers a large population and produces sustained noise.
Cloud backup and file-sync uploads. Endpoints with configured cloud backup (corporate OneDrive, Dropbox Business, Google Workspace, Box) produce outbound upload volumes that trip Data Exfiltration thresholds. The destination resolves to the backup vendor's storage cluster and the user agent or TLS SNI identifies the client. Triaged as close when the destination and client are recognized; escalated if the destination is unknown or the client's presence on the host is unexpected.
Legitimate large file downloads flagged by MDCore. Installers that include packers, installers signed but marked as PUA, and development tools flagged by heuristics can produce MDCore alerts with one to two positive engines. Triaged as close when the file is recognized and its delivery path is legitimate; escalated if the file reaches a Tier 1 host outside the sanctioned software-distribution channel.
Service discovery and telemetry as DNS tunneling. Some telemetry protocols, BGP anycast routing health checks, and service-discovery mechanisms emit DNS queries with unusually long labels, unusual record types, or high unique-subdomain counts. Triaged as close once the parent domain and source service are identified; tuned via policy only if a specific vendor's DNS pattern generates recurring alerts across a known population.
Internal-to-internal alerts from misclassified subnets. If an RFC-1918 subnet is incorrectly marked as external in the sensor's home-net configuration, or a NAT boundary misrepresents the source, internal traffic may trip detections designed for internal-to-external flows. Triaged as close, and a follow-up task is opened against the sensor configuration.
Load-balancer and proxy artifacts. Forward proxies, reverse proxies, and load balancers that rewrite source IPs can create the appearance of a single host communicating with an impossibly large number of destinations, firing Connection Spray or anomaly detections. Triaged as close once the proxy identity is confirmed; tuned via policy by excluding the proxy IP from the affected detection.
Red-team and vulnerability-scanning activity. Authorized internal red-team exercises and vulnerability scanners produce Critical alerts by design — they use real exploit traffic, real C2 tooling, and real malware samples. Triaged as 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.

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 Services, ASN 8075, user agent Windows-Update-Agent" is.