"Kerberoasting and DNS tunneling have long ceased to be exotic techniques," wrote Kaspersky's Securelist team in its technical overview of Network Anomaly Detection (NAD) as implemented in the Kaspersky Anti Targeted Attack (KATA) platform.
Why Kerberoasting evades signature‑based tools
The Kerberoasting technique leverages the normal operation of Kerberos: an attacker with a compromised low‑privilege account and a valid Ticket‑Granting Ticket (TGT) requests Ticket‑Granting Service (TGS) tickets for accounts that have Service Principal Names (SPNs), then cracks those tickets offline to recover a service account password. TGS‑REQ messages issued by attackers are identical to legitimate requests, and domains naturally generate a high volume of Kerberos traffic. That makes single‑event signature detection ineffective.
Kaspersky identifies the useful, detectable signals as indirect, behavioral indicators: an anomalous request source (an atypical host or user account), a rapid surge in requests for multiple unique SPNs from the same source, requests for non‑system (manually created) service accounts, and timing or volume that deviates from the historical profile of the user and host. At the network level the signal often appears as one host — using a single client account name (cname) — receiving TGS‑REP responses for many unique SPNs (sname) within a short window.
How KATA's NAD flags Kerberoasting
The NAD rule template titled "Signs of a Kerberoasting attack" encodes that behavioral logic as an SQL query executed against KATA’s ClickHouse database. The rule selects Kerberos network sessions that produced successful TGS‑REP responses, applies exclusion lists (excl_sip for IPs, excl_users for client names, and a list of system SPNs omitted from counting), and extracts the cname and sname fields.
Sessions are grouped by source IP and client account, aggregating unique SPNs. An alert is generated if a single IP address using a single client account receives TGS‑REP responses for N unique SPNs within the configured search depth window, where N meets or exceeds the count_spns threshold. Subsequent alerts from the same client IP within the event regeneration window are grouped under the initial alert to avoid duplicates and increment an aggregation counter.
Kaspersky emphasizes that this uniqueness‑aware aggregation cannot be implemented with traditional IDS signatures: an IDS can count packets but cannot readily evaluate the uniqueness of requested SPNs across sessions, leading to high false positive rates unless tuned exhaustively. The NAD approach centralizes exclusions and thresholds as user variables in the interface rather than forcing analysts to rewrite IDS rules.
Why DNS tunneling is difficult to detect
DNS tunneling encodes data inside DNS queries and responses to create a covert channel for C2, data exfiltration, or bypassing network restrictions. One common method uses TXT records: the right‑hand portion of the domain (e.g., testlab[.]local) remains static while the left‑hand subdomain carries encoded data (for example, ZFcABQAIBA[.]testlab[.]local). The server returns commands or messages inside TXT responses.
Legitimate DNS traffic already contains long names and uses TXT records for benign purposes, so detection rests on correlated anomalies: a high volume of long, apparently random subdomains directed at a single static root; high query frequency; many unique names; non‑standard record types; and unusually large combined data volumes in requests and TXT responses. Additional nuances: a tunnel may span multiple sessions, queries may contain multiple names, responses can include multiple TXT records, and traffic between DNS servers must be excluded to avoid duplicated client requests and false positives.
How KATA's NAD detects DNS data tunneling via TXT records
KATA offers a prebuilt "DNS data tunneling via TXT records" template that implements a multi‑indicator detection logic. The rule uses three important variables: user_DNS_servers (a list of internal DNS servers to exclude), excl_sip (IP addresses to exclude), and traffic_size (a byte threshold for combined data volume).
The rule scans DNS sessions in the search‑depth window and retains sessions containing at least one TXT response, excluding sessions initiated by internal DNS servers or excluded IPs. It splits sessions into individual log lines for each request/response, retains only TXT responses, extracts DNS names and TXT data (rdata), keeps unique values, and then groups records by source IP aggregating unique DNS names and TXT blocks. An alert fires if the combined size in bytes of the unique DNS names plus TXT response data for a single IP exceeds the traffic_size threshold. As with the Kerberos rule, subsequent alerts within the event regeneration period are grouped to prevent duplicate records.
Kaspersky argues this correlated approach reduces noise and presents analysts with an actionable hypothesis about a tunnel rather than a flood of fragmented DNS events that are impractical to investigate via signatures alone.
What this means for technologists, KATA analysts, and procurement leaders
- Technologists and security teams: prioritize behavioral correlation over single‑event signatures when monitoring Kerberos and DNS traffic; tune thresholds (count_spns, traffic_size) and exclusions to local baselines to avoid false positives.
- KATA administrators and analysts: NAD rules are not enabled by default and must be added manually from the "Custom rules" → "Intrusion detection" → "Network Anomaly Detection" UI. Analysts can select templates, review SQL variables in the "SQL‑specific query" tab, test rules before deployment, and inspect related network sessions and attributes when an NDR:NAD alert is raised.
- Procurement and IT leadership: the product ships with 59 prebuilt NAD templates (with more delivered via updates) and supports up to 200 active rules simultaneously; rules can remain system templates or be converted into custom rules by unlocking and editing the SQL query.
Network Anomaly Detection, as implemented in KATA, consolidates protocol‑specific behavioral indicators — who initiated activity, how frequent and unique the targets were, and how that differs from baseline — into single, investigator‑ready alerts. As Securelist concludes, "The importance of this capability will only grow" as adversaries increasingly blend malicious actions into routine domain infrastructure traffic.
https://securelist.com/tr/network-anomaly-detection-in-kata/120892/
