Detection Overview

MetaDefender NDR generates alerts from six complementary detection engines. Each engine answers a different question about the network — "has this signature fired before?", "is this entity on a threat-intelligence list?", "did a scanned file come back malicious?", "does this traffic pattern look like beaconing or exfiltration?", "is this event statistically anomalous?" — and every engine feeds into a single unified alert pipeline with the same severity and confidence vocabulary. This chapter introduces the six families, traces how a detection travels from the wire to the analyst, and defines the severity and confidence scales every subsequent chapter uses.

This chapter is written for Tier 1, 2, and 3 Security Operations Center (SOC) analysts, threat hunters, Managed Security Service Provider (MSSP) analysts, and SOC leads. It assumes a running MetaDefender NDR deployment and familiarity with the Dashboard and Hunt Page

First-use acronym expansions in this chapter: SOC (Security Operations Center), MSSP (Managed Security Service Provider), C2 (command-and-control), IOC (Indicator of Compromise), TIDB (Threat Intelligence Database), REPDB (Reputation Database), IDS (Intrusion Detection System), AV (antivirus), SID (Signature Identifier), MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), DNS (Domain Name System), TLS (Transport Layer Security), SNI (Server Name Indication), JA3 / JA4 (TLS client fingerprint formats), DGA (Domain Generation Algorithm), NXDOMAIN (Non-Existent Domain DNS response), TTL (Time To Live), ML (machine learning), RCF (Random Cut Forest), MVP (Minimum Viable Product).

The Detection Landscape

MetaDefender NDR ships six detection families. Each family is engineered around a distinct evidence type, runs on its own pipeline stage, and produces its own alert shape — but every family converges on the same unified alert stream that the Hunt Page and Dashboardsurface.

• Suricata signatures. Deep-packet-inspection signatures from Proofpoint Emerging Threats Pro and other rulepacks shipped with the OPSWAT InSights rulepack. Classical intrusion-detection matches on packet content, protocol anomalies, and rule metadata. See Suricata Signatures.
• Command-and-control (C2) threat intelligence. Exact-match lookups of Internet Protocol (IP) addresses and Domain Name System (DNS) query names against the OPSWAT Eyelet C2 feed. Produces dedicated C2 IP and C2 DNS alerts. See C2 and Threat Intelligence.
• OPSWAT InSights threat intelligence (TIDB and REPDB). Hash-lookup matches against two curated threat-intelligence feeds — the high-confidence Threat Intelligence Database (TIDB) and the broader-coverage Reputation Database (REPDB) — applied to IPs, hostnames, and domain hierarchies across DNS, TLS, and HTTP traffic. See InSights TIDB and REPDB
• MetaDefender Core file scanning. Extracted files are submitted to MetaDefender Cloud or an on-premises MetaDefender Core cluster for multi-antivirus (multi-AV) scanning. Three alert tiers are raised on the basis of positive-engine count. See MetaDefender Core File Scanning
• Behavioral analytics. Streaming structured-query-language (SQL) detections running in RisingWave produce eight behavioral alert types — Beaconing, Data Exfiltration, Long Duration Flow, Port Scanning, Connection Spray, DNS Tunneling, Domain Generation Algorithm (DGA) activity, and Fast Flux hosting. See Behavioral Detections.
• Machine-learning (ML) anomaly detection. Random Cut Forest (RCF) unsupervised anomaly scoring applied per event type (DNS, HTTP, Flow) with configurable score thresholds. See ML Anomaly Detections

Suricata signatures run inside the sensor process. The C2, InSights, and MetaDefender Core families run as enrichment services fed from a shared raw-events Kafka topic. The behavioral family runs in a separate RisingWave streaming pipeline reading the aggregator's merged event stream, and the ML family runs in the RCF pipeline on the same merged stream. All five post-sensor families converge on the alert engine, which applies the rules that translate each stream into a categorized alert.

How Detections Reach the Analyst

A detection travels through a fixed pipeline before it becomes an alert on an operator screen. Understanding that pipeline makes the where and when of each detection family predictable.

1. Sensor. A MetaDefender NDR sensor observes traffic on a tapped interface. Suricata parses packets, emits session records (DNS, HTTP, TLS, Server Message Block (SMB), Remote Desktop Protocol (RDP), Simple Mail Transfer Protocol (SMTP), Secure Shell (SSH), Quick User Datagram Protocol Internet Connection (QUIC), File Transfer Protocol (FTP), FileInfo), flow records, and Suricata signature alerts when a rule matches. All output is published to the raw sensor-events stream on the Manager.
2. Enrichment services. Each enrichment service consumes the raw stream and adds its own payload when relevant: C2 looks up IPs and DNS names against the Eyelet feed; InSights does the same against TIDB and REPDB; MetaDefender Core submits extracted files for multi-AV scanning; and per-IP metadata services add Autonomous System Number (ASN) and GeoIP data. Enrichment output is published to an enriched stream that names the event's identifier and carries the enrichment status.
3. Aggregator. The aggregator waits until every expected enrichment has reported in for a given event, stitches the enrichments back onto the correct entities on the event, and emits a single merged event. If an enrichment never reports, the aggregator synthesizes a timeout status and ships the merged event anyway — no event is lost because an enrichment stalled.
4. Streaming analytics. The merged event is consumed in parallel by the RisingWave behavioral pipeline and the RCF ML pipeline. Each pipeline applies its own windowed SQL or anomaly-scoring logic and publishes its findings to dedicated behavioral and ML alert streams.
5. Alert engine. A rules engine consumes the merged event stream and the behavioral and ML alert streams. It evaluates a small catalog of rules (one per detection family plus per-tier rules for MetaDefender Core) and, when a rule matches, produces a typed alert with a canonical severity, confidence, and payload. The alert is stored and published to downstream consumers.
6. User interface (UI) surfaces. The alert reaches the analyst in three places: the Dashboard Recent Alerts widget and Recent Severities donut (recent activity at a glance), the Hunt Page All Alerts tab and its per-type sub-tabs (full investigation surface), and, for any alert with an attached enrichment, the Hunt detail sidebar's per-enrichment section that renders the enrichment payload inline next to the event.

End-to-end latency from sensor observation to the Hunt table is under ten seconds under normal conditions. Detections that require windowed aggregation (Beaconing, DGA, Fast Flux, Connection Spray, Port Scanning, Long Duration Flow) incur the window size as an additional delay — a one-hour window detection cannot raise an alert faster than one hour after the first qualifying event.

Where Each Family Surfaces in the UI

Detections are presented consistently across surfaces so analysts can pivot freely between orientation and investigation.

Note on enrichment rendering: one record can fire several sidebar sections at once. A DNS session row that matched a TIDB entry renders the DNS section alongside the InSights Enrichment section. A FileInfo row with a MetaDefender Core hit renders the FileInfo section alongside the MDCore Enrichment section. This is intentional — the sidebar is a composite view of every block the record carries.

The Unified Severity Scale

Every alert MetaDefender NDR produces carries a severity level drawn from the same four-level scale. The severity is set by the alert engine on the basis of the detection's trigger conditions.

Suricata signatures carry their own native severity on a 1–4 scale (1 = Critical, 2 = High, 3 = Medium, 4 = Low); the alert engine maps this one-to-one onto the unified scale above so analysts never have to translate between them.

The Confidence Scale

Every alert also carries a confidence score expressed as a floating-point number. Confidence ranges from 0.40 to 0.99, with the bands defined as follows.

Analysts use confidence to order work within a severity tier: among ten Medium alerts, the one at 0.78 confidence is triaged before the one at 0.42.

IOC Auto-Escalation Rule

When a detection carries an IOC match — any matched entity from the C2 feed or the InSights TIDB or REPDB feeds — the unified pipeline applies a single hard override: the alert is escalated to severity Critical and confidence 0.99 regardless of the detection family's normal thresholds.

This rule applies to every family that can carry an IOC reference. A Beaconing detection with 16 connections (normally Low severity) that hits a destination on the C2 IP feed is raised as Critical at 0.99 confidence. A Long Duration Flow of 3,700 seconds (normally Medium) to a REPDB-listed domain is raised as Critical at 0.99. The rule is intentional and not tunable: once a detection crosses with a known-bad indicator, the signal is too strong to demote.

Analysts interpreting Critical alerts therefore distinguish between threshold-Critical (the behavioral or file-scan evidence alone was strong enough to reach Critical) and IOC-Critical (the evidence tripped the auto-escalation). The alert's sidebar enrichment sections make the distinction visible: an IOC-Critical alert shows the matched entity and source feed in the C2 or InSights Enrichment section, whereas a threshold-Critical alert carries only the family-native metadata.

Detection Family Quick Reference

The table below summarizes the six families at a glance.

The rest of this chapter group covers each family in full, following the same template: what it is, what it detects, how it works, trigger conditions, severity classification, confidence scoring, where it surfaces in the UI, a representative alert payload, tuning considerations, and a cross-link to the matching (Link Removed) entry.