Behavioral Detections

Behavioral detections answer the question "does this traffic pattern look like something malicious hosts do, even without a known signature or indicator?" Where Suricata signatures match on packet content and the C2 / InSights / MetaDefender Core families match observed entities against curated intelligence, the behavioral family looks only at the shape of the traffic — how often a client connects back, how much it uploads, how long a flow stays open, how many ports or destinations one host touches, how DNS queries are structured and how often they fail. Eight detections run continuously over the merged event stream and emit alert payloads when a host or a flow crosses a threshold that no benign pattern reaches in production traffic. This chapter describes all eight — what each one looks for, which conditions raise it, how severity and confidence are assigned, and how analysts find the resulting alert on the Dashboard and the Hunt page.

First-use acronym expansions in this chapter: C2 (command-and-control), SQL (Structured Query Language), IOC (Indicator of Compromise), RFC-1918 (the IETF-reserved private-use IP address ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), STDDEV (standard deviation), CV (coefficient of variation — STDDEV divided by mean), HOP (hopping window), TUMBLE (tumbling window), DNS (Domain Name System), NXDOMAIN (Non-Existent Domain DNS response), TLS (Transport Layer Security), SNI (Server Name Indication), TTL (Time To Live), ASN (Autonomous System Number), GeoIP (geographical IP lookup), DGA (Domain Generation Algorithm), MB (megabyte — 1,048,576 bytes),

Overview

The behavioral detection family runs in a dedicated streaming SQL engine — RisingWave — that consumes the aggregator's merged event stream and applies eight continuously-running analytics pipelines. Each pipeline is a SQL query over a sliding or tumbling time window; every new event updates the pipeline's state incrementally, and every threshold crossing produces an alert payload on the behavioral alert stream. The alert engine promotes each payload to a typed behavioral alert, stamps it with the unified severity and confidence vocabulary defined in Detection Overview, and publishes it to the Hunt page and Dashboard.

Three pipeline properties shape how behavioral detections behave in practice and are worth keeping in mind while reading the per-detection sections below.

  • Window-based latency. Detections that require a windowed aggregate (Beaconing's four-hour hop, DNS Tunneling's one-hour tumble, DGA's one-hour tumble, and so on) cannot produce an alert faster than the window boundary — a beacon candidate with fifteen connections in the first fifteen minutes does not fire until those connections persist far enough into the window. Long Duration Flow is the only per-flow detection and fires as soon as the flow crosses its duration threshold.
  • IOC auto-escalation. Every behavioral detection supports the IOC auto-escalation rule defined in Detection overview: whenever the detection's source, destination, or queried domain coincides with a hit from the C2 feed or the InSights TIDB (Threat Intelligence Database) or REPDB (Reputation Database) feeds, the alert is promoted to Critical severity and 0.99 confidence regardless of the detection's own thresholds. The match itself is visible in the matching C2 Enrichment or Insights Enrichment section of the Hunt detail sidebar so analysts can see which feed drove the escalation.
  • Noise controls at the pipeline level. Every pipeline ships with exclusions that keep mechanically-periodic protocols (DNS, DHCP, NTP, dhcpv6), broadcast and multicast destinations, and RFC-1918 internal-to-internal traffic out of the candidate set. These exclusions are not tunable at the alert level — they are baked into the pipeline SQL — because they are far too noisy to surface as alerts in any production network.

The eight detections are presented below in the order used on the Hunt page's behavioral sub-tabs.

Beaconing Detection

What It Is

Beaconing Detection flags periodic client-to-server communication that matches the shape of command-and-control (C2) beacon traffic. A compromised host that has landed a remote-access implant will phone home on a regular cadence — every minute, every five minutes, every hour — with a small, consistently-sized check-in payload, and will receive little or nothing in return until the operator schedules an action. Beaconing Detection looks for exactly that shape: many connections, uniform byte sizes, little server response, sustained over hours.

What It Detects

  • Compromised internal hosts with an active remote-access trojan. Cobalt Strike, Sliver, Mythic, Metasploit, and commodity remote-administration-trojan beacon channels that stay resident and keep a control channel open.
  • Malware in its dormant phase. Implants waiting for an operator task surface as beacon traffic before any data exfiltration or lateral movement is observable.
  • Legitimate-looking back-channels on encrypted transports. HTTPS, TLS, DNS-over-HTTPS tunneled beacons whose payload cannot be inspected but whose periodicity is still visible from flow metadata.
  • Custom or bespoke C2 frameworks. The detection is signature-free — a threat actor's new C2 framework triggers the same way as a commodity one if the periodicity and uniformity are there.

How It Works

The pipeline groups flow records by the triple (src_ip, dest_ip, dest_port) and evaluates each group over a four-hour hopping window that slides forward every hour. A group is flagged when it carries at least fifteen connections, when the per-flow byte count has a standard deviation under 1,000 bytes (uniform payloads), and when the server side sent fewer than five times as many packets as the number of connections (low server response). Internal-to-internal traffic is excluded at the pipeline level: any RFC-1918 destination (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12), any broadcast or multicast destination, and any flow on the inherently-periodic ports for DNS, DHCP, NTP, and their application-protocol equivalents are dropped before evaluation. Suricata occasionally re-emits a flow with a refined app_proto value as more bytes flow (null → http → failed); the pipeline aggregates across all app_proto values for the same tuple and renders the most specific non-failed protocol in the alert payload.

Trigger Conditions

ConditionThresholdRationale
Minimum connections≥ 15Filters low-frequency legitimate traffic.
Byte-size consistencySTDDEV(bytes) < 1,000Beacon check-ins are uniform; normal traffic is not.
Low server responseserver_packets < connections × 5C2 beacons send more than they receive.
RFC-1918 destination exclusionExclude 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16Internal-to-internal traffic is never C2 beaconing; the exclusion removed a significant false-positive population during tuning.
Broadcast / multicast exclusionExclude 255.255.255.255, 224.0.0.0/4, *.255, *.0Broadcast and multicast are not C2 destinations.
Periodic-protocol exclusionExclude ports 53, 67, 68, 123, 5353 and app_proto ∈ {dns, dhcp, ntp, dhcpv6}These protocols are mechanically periodic; their regular timing is expected, not suspicious.

Group key: src_ip, dest_ip, dest_port. Window: hopping, 4 hours, 1-hour slide.

Severity Classification

SeverityCondition
CriticalIOC match (malicious_iocs > 0) OR connections ≥ 50.
HighConnections ≥ 30.
MediumConnections ≥ 20.
LowConnections ≥ 15 (minimum threshold).

Confidence Scoring

ConfidenceCondition
0.99IOC match on destination.
0.95Byte STDDEV < 100 (highly uniform payloads).
0.85Byte STDDEV < 500.
0.75All other qualifying candidates.

Where It Surfaces

  • Dashboard — Recent Severities donut. Contributes to the Critical / High / Medium / Low slices according to the alert's assigned severity. Top Signature Hits is Suricata-only and does not include behavioral alerts.
  • Dashboard — Recent Alerts feed. Newest Beaconing alerts flow through the cross-family feed, distinguishable by the alert_type: beaconing label.
  • Hunt page — Beaconing Detection Alert sub-tab. Under All Alerts, this per-type sub-tab lists every Beaconing alert with the base alert columns (minus proto and src_port, which vary per connection and are not meaningful at the pattern level) plus the Beaconing-specific columns — beacon_score, connection_count, avg_bytes_per_flow, cv_bytes, window_start, window_end.
  • Hunt detail sidebar — Beaconing Detection section. Rendered on any record that carries a beaconing block. Lists connection count, unique flow count, byte / packet averages, byte and packet coefficients of variation, server response ratio, window bounds, and destination country / ASN / organization.

Alert Payload Example

JSON
Copy

Tuning Considerations

The detection's main false-positive surface is legitimate machine-to-machine traffic with beacon-like shape — software-update check-ins, metrics telemetry, cloud-agent health pings, and managed-endpoint keepalives. The pipeline-level exclusions (RFC-1918 destinations, broadcast, inherently-periodic protocols) remove the most common cases before evaluation. The remaining false positives are typically internet-bound telemetry to well-known vendors; these concentrate in the Low tier at the minimum connection threshold and resolve cleanly once analysts add the destination ASN or organization to the suppression list. Minimum connection count, byte STDDEV threshold, and server-response ratio are exposed through Policy for per-environment tuning, but the defaults in the threshold tables above are intentionally strict and should remain the starting point; loosening them widens the false-positive surface faster than it increases coverage.

Beaconing alerts route through (Link Removed), which covers identifying the compromised host, correlating with DNS and TLS sessions on the same source IP, checking for concurrent Long Duration Flow or Data Exfiltration signals, and pivoting to packet capture when the flow protocol is inspectable.

Data Exfiltration Detection

What It Is

Data Exfiltration Detection flags flows where a client uploads substantially more data than it downloads to a destination that crosses the network boundary. The shape is distinctive: a browser session downloads far more than it uploads; a backup-agent session alternates; an exfiltration session uploads disproportionately more than it receives. The detection measures the upload-to-download byte ratio on each flow and raises when the ratio and the absolute upload volume both cross their thresholds.

What It Detects

  • Bulk data theft over approved encrypted transports. HTTPS, TLS, custom TCP uploads — the payload is opaque but the byte-direction ratio is not.
  • Staging-server exfiltration. Compromised internal host uploading to an attacker-controlled dropbox, public paste site, cloud-storage bucket, or file-sharing service.
  • Covert exfiltration channels. DNS, ICMP, and application-layer covert channels are covered indirectly — any tunneled upload with enough volume crosses the byte threshold.
  • Insider data movement. Large outbound uploads from workstations or servers that were never expected to send traffic outbound.

The detection does not, by itself, distinguish a malicious exfiltration from a legitimate large backup upload; the combination of Data Exfiltration plus a C2 or InSights enrichment on the destination is a far stronger signal, which is why the IOC auto-escalation rule elevates such events to Critical.

How It Works

The pipeline groups flow records by the quad (src_ip, dest_ip, dest_port, app_proto) and evaluates each group over a 15-minute hopping window with a 5-minute slide. A group is flagged when the sum of bytes_toserver (client upload) across the window is at least twice the sum of bytes_toclient (server download) and the absolute upload volume is at least 1 MB. Two directional boundaries restrict the candidate set further: the source must be inside an RFC-1918 range (so internal-file-transfer-to-internal-file-server patterns do not score as exfiltration), and the destination must be outside all RFC-1918 ranges (exfiltration must cross the network boundary). When the server sends zero bytes but the client sends data, the ratio is capped at 999.99 for the payload.

Trigger Conditions

ConditionThresholdRationale
Minimum upload ratio≥ 2:1 (bytes_toserver / bytes_toclient)Client sends at least twice what it receives.
Minimum upload volume≥ 1 MBEliminates low-volume noise.
Internal source requirementsrc_ip is RFC-1918Prevents CDN downloads and cloud-service push traffic from scoring.
External destination requirementdest_ip is not RFC-1918Exfiltration must cross the network boundary.

Group key: src_ip, dest_ip, dest_port, app_proto. Window: hopping, 15 minutes, 5-minute slide.

Severity Classification

SeverityCondition
CriticalIOC match OR (ratio ≥ 10:1 AND upload ≥ 100 MB).
High(Ratio ≥ 5:1 AND upload ≥ 10 MB) OR (ratio ≥ 2:1 AND upload ≥ 100 MB).
MediumRatio ≥ 2:1 AND upload ≥ 10 MB.
LowMeets minimum threshold (ratio ≥ 2:1 AND upload ≥ 1 MB).

Confidence Scoring

ConfidenceCondition
0.99IOC match.
0.95Ratio ≥ 10:1 AND upload ≥ 100 MB.
0.85Ratio ≥ 5:1 AND upload ≥ 10 MB.
0.80Ratio ≥ 2:1 AND upload ≥ 100 MB.
0.70All other qualifying candidates.

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: data_exfiltration.
  • Hunt page — Data Exfiltration Detection Alert sub-tab. Base alert columns minus proto plus the Data-Exfiltration-specific columns — upload_ratio, upload_mb, download_mb, flow_count, total_upload_bytes, total_download_bytes.
  • Hunt detail sidebar — Data Exfiltration Detection section. Lists flow count, unique flow count, total upload / download in megabytes, upload ratio, IOC status, destination country / ASN / organization.

Alert Payload Example

JSON
Copy

Tuning Considerations

The 15-minute window is short enough to fire on a single exfiltration burst and long enough to average over typical session jitter. The 1 MB minimum upload floor is conservative; environments with high-volume legitimate uploads (development teams pushing large artifacts, media organizations publishing video, scientific workloads uploading datasets) may see the Low tier fire on benign traffic. The correct tuning is to add specific destinations (for example, internal-to-cloud storage, approved source-code repositories) to the Policy's exfiltration allowlist rather than raise the floor globally; an attacker conducting a low-and-slow exfiltration will stay under a raised floor but will still hit a scoped allowlist.

Data Exfiltration alerts route through (Link Removed).

Long Duration Flow Detection

What It Is

Long Duration Flow Detection flags individual flows whose elapsed wall-clock duration exceeds an hour. Persistent connections that stay open across session boundaries are characteristic of C2 control channels, reverse tunnels, VPN (Virtual Private Network) tunnels punched through a monitored boundary, and long-running interactive sessions — all of which may be legitimate, but none of which should go un-triaged in a security context.

What It Detects

  • Persistent C2 control channels. A reverse shell or a long-poll beacon whose socket stays open for the operator's convenience.
  • SSH (Secure Shell) tunnels, reverse-SSH port forwards, and VPN-over-TLS tunnels that stay connected for the duration of an interactive session or longer.
  • Database replication, application heartbeats, and managed-service control planes that hold a long-lived connection. These are frequent false positives and should be suppressed per-source or per-destination once identified.
  • Compromised IoT (Internet of Things) devices with a persistent outbound socket to a command server.

How It Works

The pipeline evaluates each flow record individually as the flow.age field (Suricata-reported duration in seconds) crosses 3,600 seconds. No sliding or tumbling window is used — this is a per-event detection and fires as soon as the threshold is crossed. The alert is re-emitted at subsequent thresholds (10 hours, 20 hours, 24 hours) so analysts tracking a long-running session can see the severity escalate without losing the original alert.

Trigger Conditions

ConditionThresholdRationale
Minimum durationflow.age ≥ 3,600 s (1 hour)Below this, most persistent sessions are benign (web sockets, streaming media).
Flow is still active or newly observedYesHistorical backfill is not in scope.

Group key: per-flow. Window: none (per-event).

Severity Classification

SeverityAlert LevelDuration
CriticalREDIOC match OR ≥ 86,400 s (24 hours).
HighORANGE≥ 36,000 s (10 hours).
MediumYELLOW≥ 3,600 s (1 hour).

Confidence Scoring

ConfidenceDuration
0.99IOC match.
0.95≥ 86,400 s (24 hours).
0.90≥ 72,000 s (20 hours).
0.80≥ 36,000 s (10 hours).
0.60≥ 18,000 s (5 hours).
0.40≥ 3,600 s (1 hour, minimum).

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: long_duration.
  • Hunt page — Long Duration Flow Alert sub-tab. Base alert columns minus proto plus — duration_seconds, duration_hours, total_bytes, bytes_per_second, alert_level (RED / ORANGE / YELLOW).
  • Hunt detail sidebar — Long Duration Flow section. Lists flow_id, duration in seconds and hours, total bytes and packets, bytes-per-second, IOC status, destination country / ASN / organization.

Alert Payload Example

JSON
Copy

Tuning Considerations

The three-level alert scheme (YELLOW → ORANGE → RED) keeps analysts informed as a session ages without creating alert fatigue — a session opened at T+0 emits Medium at one hour, then High at ten hours, then Critical at twenty-four hours. The primary false-positive population is operational: managed-service control planes, cloud-agent persistent connections, database replication sessions, and administrative SSH sessions. When an alert destination is identified as benign, Policy supports suppression by source-destination pair so analysts do not have to triage the same alert again on every re-trigger. The duration thresholds and alert-level mapping are not recommended for per-environment tuning.

Long Duration Flow alerts route through (Link Removed) when they coincide with a suspicious destination, and through (Link Removed) for duration-only alerts that need context before classification.

Port Scanning Detection

What It Is

Port Scanning Detection flags vertical scans — one source IP touching many different ports on one destination IP. The shape is unmistakable: a TCP or UDP probe to port 22, then 23, then 25, then 80, then 443, and so on, across a port range, from the same source, to the same destination, usually in a short time window. The detection counts distinct destination ports per source-destination pair over a one-hour window and raises when the count crosses the threshold.

What It Detects

  • Reconnaissance against a specific host. Attacker probing a newly-identified target for open services before choosing an attack vector.
  • Service-discovery steps inside an established intrusion. Internal pivot after initial access — the attacker enumerates the local network one host at a time.
  • Vulnerability-scanner traffic from an unauthorized source. Authorized scanners should be excluded via Policy.

How It Works

The pipeline groups flow records by the pair (src_ip, dest_ip) and counts DISTINCT dest_port per group over a one-hour hopping window with a 15-minute slide. A group is flagged when the distinct-port count reaches 10. The detection does not attempt to distinguish scan type (SYN, connect, UDP probe) because the signal comes from the port variety rather than the scan technique — any method that touches enough distinct ports produces the same alert.

Trigger Conditions

ConditionThresholdRationale
Unique destination ports per src→dest pair≥ 10Minimum to distinguish scanning from normal multi-service access.

Group key: src_ip, dest_ip. Window: hopping, 1 hour, 15-minute slide.

Severity Classification

SeverityCondition
CriticalIOC match OR ≥ 100 ports.
High≥ 50 ports.
Medium≥ 20 ports.
Low≥ 10 ports (minimum threshold).

Confidence Scoring

ConfidenceUnique POrts
0.99IOC match.
0.95≥ 100 ports.
0.85≥ 50 ports.
0.75≥ 20 ports.
0.65≥ 10 ports.

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: port_scan.
  • Hunt page — Port Scan Detection Alert sub-tab. Base alert columns minus proto plus — unique_ports_scanned, total_connections, protocols_used, first_seen, last_seen.
  • Hunt detail sidebar — Port Scan Detection section. Lists unique port count, total connection count, protocol list, window bounds, IOC status, destination country / ASN / organization.

Alert Payload Example

JSON
Copy

Tuning Considerations

Authorized vulnerability scanners (internal and vendor-operated) are the dominant false-positive population. The appropriate response is to add the scanner source IPs or the scanner Classless Inter-Domain Routing range to a Policy suppression list so the pipeline skips them entirely rather than raising and then dismissing alerts. Port-scan alerts firing from unexpected internal sources are a high-value signal — port scanning from a workstation is almost never legitimate.

Port Scan alerts have no dedicated runbook at MVP; analysts triage them through (Link Removed) when Critical / High, and through (Link Removed) otherwise.

Connection Spray Detection

What It Is

Connection Spray Detection flags horizontal scans — one source IP touching many different destination IPs in a short window. Where Port Scanning enumerates services on a single host, Connection Spray enumerates hosts across the network. The shape appears in worm-style lateral propagation, brute-force credential spraying against many targets, and post-breach reconnaissance across a subnet.

What It Detects

  • Worm and ransomware-precursor lateral movement. An infected host probing for a Server Message Block, Remote Desktop Protocol, or exposed-service neighbor to spread to.
  • Credential spraying. One source trying the same username / password pair against many hosts.
  • Recon sweeps. Post-access reconnaissance walking a subnet looking for high-value targets.

How It Works

The pipeline groups flow records by src_ip and counts DISTINCT dest_ip per source over a one-hour hopping window with a 15-minute slide. A group is flagged when the distinct-destination count reaches 20.

Trigger Conditions

ConditionThresholdRationale
Unique destination IPs per source≥ 20Minimum to distinguish spray behavior from normal browsing / application traffic.

Group key: src_ip. Window: hopping, 1 hour, 15-minute slide.

Severity Classification

SeverityCondition
CriticalIOC match OR ≥ 200 destinations.
High≥ 100 destinations.
Medium≥ 50 destinations.
Low≥ 20 destinations (minimum threshold).

Confidence Scoring

ConfidenceUnique destinations
0.99IOC match.
0.95≥ 200 destinations.
0.85≥ 100 destinations.
0.75≥ 50 destinations.
0.65≥ 20 destinations.

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: connection_spray.
  • Hunt page — Connection Spray Detection Alert sub-tab. Base alert columns minus proto plus — unique_destinations, total_connections, unique_ports, first_seen, last_seen.
  • Hunt detail sidebar — Connection Spray Detection section. Lists unique destination count, total connection count, unique port count, window bounds, IOC status.

Alert Payload Example

JSON
Copy

Tuning Considerations

Backup clients, DNS recursive resolvers talking to authoritative servers, and monitoring / observability agents polling many targets are the most common false positives. As with Port Scanning, the right remedy is a source-IP suppression list on the operational hosts rather than threshold tuning — an attacker staying under a raised threshold is still a problem.

Connection Spray alerts triage through (Link Removed) when Critical / High; the runbook covers correlating spray with destination alert patterns, identifying the source, and determining whether the source is authorized for scan behavior.

DNS Tunneling Detection

What It Is

DNS Tunneling Detection flags DNS queries whose shape indicates the DNS protocol is being used as a covert data channel. Tunneling tools (iodine, dnscat2, DNScat, custom C2) encode payload bytes into subdomain labels of attacker-controlled domains; legitimate DNS traffic rarely has long, high-entropy, deeply-nested query names. The detection scores each individual query against five indicators and also aggregates queries by parent domain on an hourly basis to identify the parent domain driving the activity.

What It Detects

  • Active DNS tunnels. Exfiltration over DNS, interactive C2 over DNS, file transfer over DNS — encoded in subdomain labels of an attacker-controlled domain.
  • DNS amplification artifacts. Large TXT or NULL response payloads that look like tunneled responses.
  • High-entropy subdomain enumeration. Bulk queries to varied subdomains of a single parent domain (a common fingerprint of a DNS-based covert channel).

How It Works

The pipeline operates in two modes: per-query suspicion scoring and hourly parent-domain aggregation. Per-query, each DNS query event (event_type = 'dns' AND dns.type = 'query') is scored against five binary indicators — long query name, many subdomains, unusual record type, large response, and long first-subdomain label — with each satisfied indicator adding one to a suspicion_score (0–4). Any score of at least 1 produces a per-query alert. Hourly, queries are grouped by parent domain over a one-hour tumbling window; the aggregate carries total queries, unique subdomains, unique sources, and counts of each suspicious-indicator class, allowing analysts to see the parent domain driving the alert volume.

Trigger Conditions

Per-query indicators:

IndicatorConditionScore
Long query nameLENGTH(query_name) > 50+1
Many subdomainsSubdomain count > 3 levels+1
Unusual record typeTXT, NULL, or CNAME+1
Large responseLENGTH(answers) > 200 chars+1
Encoded labelFirst subdomain label > 25 chars+1

A per-query alert raises when any indicator is satisfied (suspicion_score ≥ 1). Input filter: event_type = 'dns' AND dns.type = 'query'.

Hourly parent-domain aggregation (dns_tunneling_hourly) is computed per parent domain per hour and carries total_queries, unique_subdomains, unique_sources, long_query_count, many_subdomain_count, unusual_type_count, large_response_count, has_high_unique_ratio (unique_queries / total_queries > 0.8), and has_high_query_rate (total_queries > 100). Only parent domains with more than 5 queries per hour are output.

Severity Classification (per-query)

ServerityCondition
CriticalIOC match on query domain.
HighSuspicion score ≥ 3.
MediumSuspicion score = 2.
LowSuspicion score = 1.

Confidence Scoring (per-query)

ConfidenceCondition
0.99IOC match.
0.85Suspicion score ≥ 3.
0.70Suspicion score = 2.
0.50Suspicion score = 1.

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: dns_tunneling.
  • Hunt page — DNS Tunneling Suspicious Alert sub-tab. Base alert columns minus proto plus — query_name, record_type, query_length, subdomain_count, suspicion_score, and the per-indicator boolean flags.
  • Hunt detail sidebar — DNS Tunneling Suspicious section. Lists the full query name, first subdomain, record type, query and answer length, suspicion score, the per-indicator booleans, and IOC status.

Alert Payload Example

JSON
Copy

Tuning Considerations

The per-query indicators are deliberately generous — they are designed to catch weak signals and surface them at the Low tier so analysts can review rather than miss. In production, the single largest false-positive source is cloud-service and anti-malware telemetry that encodes state into subdomain labels (for example, some anti-virus cloud-lookup services, some cache-busting content-delivery hostnames, and some analytics services). The dns_tunneling_hourly aggregate is the pivot point for suppression — analysts identify the parent domain driving false positives and add the parent to a Policy allowlist, removing the entire family of queries from the detection without changing the per-query thresholds. The five per-query thresholds are exposed through Policy but the defaults should stay in place; tightening them risks missing sophisticated tunnels that stay just under whatever threshold operators raise.

DNS Tunneling alerts route through (Link Removed), which covers pivoting from the flagged query to the full query stream for the source and parent domain, cross-referencing with C2 and InSights enrichments, and determining whether the host needs isolation.

DGA Detection

What It Is

DGA Detection flags hosts that are querying large numbers of algorithmically-generated domain names — a hallmark of DGA-based malware. DGA families generate hundreds of random-looking domains per day and query them in bulk, expecting most to fail with NXDOMAIN until one of them resolves to the attacker's current C2 server. The resulting DNS traffic has a distinctive shape: high query volume, high NXDOMAIN ratio, and high unique-domain variety, all from a single source.

What It Detects

  • DGA-based commodity malware families. Conficker, Locky, CryptoLocker lineage, Qakbot, Emotet phases that use DGA domains as a fallback to hard-coded C2.
  • DGA-enabled loaders and persistence implants that use a generated domain as the rendezvous point.
  • Algorithmic domain-resolution libraries in advanced implants that generate candidate domains per day or per hour.

How It Works

The pipeline groups DNS events by src_ip over a one-hour tumbling window and computes the NXDOMAIN ratio (fraction of queries whose response was an NXDOMAIN) and the total query count per source. A source is flagged when the NXDOMAIN ratio is at least 0.5 and the total query count is at least 20, or when any queried domain matches an IOC. The combined threshold is what distinguishes DGA behavior from benign typos or misconfigurations: a host typing a handful of invalid domains has a high NXDOMAIN ratio but low volume, and a host with high DNS volume on valid domains has low NXDOMAIN ratio.

Trigger Conditions

ConditionThresholdRationale
NXDOMAIN ratio≥ 0.5 (50%)Legitimate DNS has very low NXDOMAIN rates; DGA produces mostly failures.
Minimum queries≥ 20Filters out hosts that simply mistyped a domain.
Combinedratio ≥ 0.5 AND queries ≥ 20, OR IOC matchBoth conditions must be true unless a known-malicious domain was queried.

Group key: src_ip. Window: tumbling, 1 hour.

Severity Classification

SeverityCondition
CriticalIOC match.
HighNXDOMAIN ratio ≥ 0.7 AND total queries ≥ 50.
MediumNXDOMAIN ratio ≥ 0.5 AND total queries ≥ 20.
LowAll others above threshold.

Confidence Scoring

ConfidenceCondition
0.99IOC match.
0.85NXDOMAIN ratio ≥ 0.7 AND total queries ≥ 50.
0.70NXDOMAIN ratio ≥ 0.5 AND total queries ≥ 20.
0.50Above minimum threshold.0.99

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: dga.
  • Hunt page — DGA Detection Alert sub-tab. Base alert columns minus proto plus — nxdomain_ratio, unique_domains, total_queries.
  • Hunt detail sidebar — DGA Detection section. Lists NXDOMAIN ratio, unique domain count, total query count, and IOC status.

Alert Payload Example

JSON
Copy

Tuning Considerations

Misconfigured applications that query dead hostnames repeatedly — legacy DNS clients, failed service-discovery loops, stale-configuration agents — will raise DGA alerts at the Low and Medium tiers. The remedy is the same as with the other detections: add the offending source IP to a Policy suppression list once identified, rather than raise the NXDOMAIN ratio or query thresholds globally. The unique-domain variety field (unique_domains) is the strongest corroborating signal — a real DGA exhibits fifty or more distinct domains per hour while a misconfigured client typically fails the same small handful of names.

DGA alerts triage through (Link Removed) — DGA activity is, functionally, the pre-beaconing rendezvous step for a DGA-enabled implant; analysts correlate DGA alerts with Beaconing and C2 Infrastructure alerts to locate the implant and its C2 destination.

Fast Flux Detection

What It Is

Fast Flux Detection flags DNS domains that resolve to many different IP addresses over a short period and with very short TTLs — a fast-flux hosting pattern used to hide C2 servers, phishing landing pages, and malicious content behind a rapidly-rotating set of compromised hosts acting as reverse-proxy front ends. The detection distinguishes fast flux from legitimate large-scale content delivery by combining unique-IP count with TTL value: a content-delivery network has many IPs but long TTLs; fast flux has many IPs and very short TTLs.

What It Detects

  • Fast-flux C2 hosting. A control domain that resolves to a different compromised proxy every few minutes.
  • Phishing and credential-harvester infrastructure hosted on fast-flux botnets.
  • Exploit-kit landing pages that rotate IPs to evade block lists.

How It Works

The pipeline consumes DNS response events (A or AAAA records with non-null rdata) and groups them by the queried domain over a one-hour tumbling window. A domain is flagged when the window carries at least 5 unique response IPs and the average TTL across the responses is under 600 seconds, or when any response matches an IOC.

Trigger Conditions

ConditionThresholdRationale
Unique response IPs per domain≥ 5Legitimate domains rarely resolve to more than three or four IPs in an hour.
Average TTL< 600 secondsFast-flux operators rotate IPs quickly; legitimate content-delivery networks use 300–3,600 s TTLs.
Combinedunique IPs ≥ 5 AND avg TTL < 600, OR IOC matchBoth conditions must be true unless a known-malicious IP or domain was observed.

Group key: domain (query name). Window: tumbling, 1 hour. Input: DNS responses for A / AAAA records with non-null rdata.

Severity Classification

severityCondition
CriticalIOC match.
HighUnique IPs ≥ 10 AND avg TTL < 300.
MediumUnique IPs ≥ 5 AND avg TTL < 600.
LowAll others above threshold.

Confidence Scoring

ConfidenceCondition
0.99IOC match.
0.85Unique IPs ≥ 10 AND avg TTL < 300.
0.70Unique IPs ≥ 5 AND avg TTL < 600.
0.50Above minimum threshold.

Where It Surfaces

  • Dashboard — Recent Severities donut and Recent Alerts feed with alert_type: fast_flux.
  • Hunt page — Fast Flux Detection Alert sub-tab. Base alert columns minus proto plus — domain, unique_ips, avg_ttl, min_ttl, max_ttl, unique_requestors.
  • Hunt detail sidebar — Fast Flux Detection section. Lists the domain, unique IP count, TTL statistics, unique requestor count, and IOC status.

Alert Payload Example

JSON
Copy

Tuning Considerations

Large global content-delivery networks occasionally satisfy the fast-flux condition on new properties whose TTLs are tuned aggressively for cache-invalidation reasons. The detection intentionally does not carve out content-delivery-network ASN ranges because doing so would give an attacker a cheap evasion (host the flux front end inside a popular network). When a content-delivery network's domain triggers repeatedly with no other corroborating signal, the appropriate remedy is a per-domain Policy allowlist rather than loosening the unique-IP or TTL thresholds.

Fast Flux alerts triage through (Link Removed); the runbook covers resolving the flagged domain's current IP set, cross-referencing with C2 / InSights enrichments on the resolved IPs, identifying the internal hosts that queried the domain, and determining whether any host also shows Beaconing or Long Duration Flow activity against one of the rotating IPs.

Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
Next to read:
ML Anomaly Detections
null
On This Page
Behavioral DetectionsOverviewBeaconing DetectionData Exfiltration DetectionLong Duration Flow DetectionPort Scanning DetectionConnection Spray DetectionDNS Tunneling DetectionDGA DetectionFast Flux DetectionWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity Classification (per-query)Confidence Scoring (per-query)Where It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated RunbookWhat It IsWhat It DetectsHow It WorksTrigger ConditionsSeverity ClassificationConfidence ScoringWhere It SurfacesAlert Payload ExampleTuning ConsiderationsRelated Runbook