Detection Overview

MetaDefender NDR generates alerts from six complementary detection engines. Each engine answers a different question about the network. The questions include signature matches, threat-intelligence matches, malicious file results, traffic patterns, and statistical anomalies. Every engine feeds one unified alert pipeline. The pipeline uses the same severity and confidence vocabulary. This chapter introduces the six families. It traces how a detection travels from the wire to the analyst. It also defines the severity and confidence scales that each later chapter uses.

This chapter is 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 MetaDefender NDR deployment. It also assumes 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 uses a distinct evidence type. Each family runs on its own pipeline stage and produces its own alert shape. Every family converges on the same unified alert stream. The Hunt Page and Dashboard show that stream.

• 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 apply to IPs, hostnames, and domain hierarchies across DNS, TLS, and HTTP traffic. The matches use two curated feeds: the high-confidence Threat Intelligence Database (TIDB) and the broader-coverage Reputation Database (REPDB). See InSights TIDB and REPDB

• MetaDefender Core file scanning. MetaDefender NDR submits extracted files to MetaDefender Cloud or an on-premises MetaDefender Core cluster for multi-antivirus (multi-AV) scanning. The pipeline raises three alert tiers on the basis of positive-engine count. See MetaDefender Core File Scanning

• Behavioral analytics. RisingWave streaming structured-query-language (SQL) detections produce eight behavioral alert types. These types are 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. It reads the aggregator's merged event stream. 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 and emits session records. Session records include DNS, HTTP, TLS, SMB, RDP, SMTP, SSH, QUIC, FTP, and FileInfo. Suricata also emits flow records and signature alerts when a rule matches. The sensor publishes all output to the raw sensor-events stream on the Manager.

2. Enrichment services. Each enrichment service consumes the raw stream and adds its 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. Per-IP metadata services add Autonomous System Number (ASN) and GeoIP data. Each service publishes enrichment output to an enriched stream. The stream names the event identifier and carries the enrichment status.

3. Aggregator. The aggregator waits until every expected enrichment reports for an event. It stitches the enrichments back onto the correct entities on the event. It emits a single merged event. If an enrichment never reports, the aggregator synthesizes a timeout status. The aggregator ships the merged event anyway, so an enrichment stall does not lose an event.

4. Streaming analytics. The RisingWave behavioral pipeline and the RCF ML pipeline consume the merged event in parallel. Each pipeline applies its own windowed SQL or anomaly-score logic. Each pipeline publishes 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. The catalog has one rule per detection family and per-tier rules for MetaDefender Core. When a rule matches, the engine produces a typed alert with canonical severity, confidence, and payload. The engine stores the alert and publishes it to downstream consumers.

6. User interface (UI) surfaces. The alert reaches the analyst in three places. The Dashboard shows the Recent Alerts widget and Recent Severities donut. The Hunt Page shows the All Alerts tab and per-type sub-tabs. For an alert with enrichment, the Hunt detail sidebar 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 add the window size as a delay. These detections include Beaconing, DGA, Fast Flux, Connection Spray, Port Scanning, and Long Duration Flow. A one-hour window detection cannot raise an alert faster than one hour after the first qualifying event.

Where each family appears in the UI

MetaDefender NDR presents detections consistently across surfaces. 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 alert engine sets severity on the basis of the detection's trigger conditions.

Suricata signatures carry their own native severity on a 1-4 scale. The scale is 1 = Critical, 2 = High, 3 = Medium, 4 = Low. The alert engine maps this one-to-one onto the unified scale above. Analysts do not 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, analysts triage the one at 0.78 confidence before the one at 0.42.

IOC auto-escalation rule

When a detection carries an IOC match, the unified pipeline applies one hard override. IOC matches include any matched entity from the C2 feed or the InSights TIDB or REPDB feeds. The pipeline escalates the alert 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 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. 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. Each chapter uses the same template: what it is, what it detects, how it works, trigger conditions, severity classification, confidence scoring, UI surfaces, a representative alert payload, tuning considerations, and a cross-link to the matching Investigation Runbooks entry.