Network Anomaly Detection in KATA

What Happened

This article explains how Kaspersky's KATA platform detects two stealthy attack techniques that hide inside normal network traffic: Kerberoasting (stealing service account passwords) and DNS tunneling (secretly sending data through DNS queries). Traditional security tools struggle to catch these attacks because the network traffic looks identical to legitimate activity. KATA's solution analyzes behavioral patterns instead of looking for known attack signatures — for example, flagging when one computer suddenly requests tickets for many different service accounts, or when DNS queries carry unusually large amounts of data. Organizations using Active Directory and DNS infrastructure should evaluate whether their current detection tools can identify these behavioral anomalies, and consider whether network anomaly detection capabilities would fill gaps in their security monitoring.

Key Takeaways

• Kaspersky Anti Targeted Attack (KATA) implements Network Anomaly Detection (NAD) using SQL queries against a ClickHouse database to detect behavioral anomalies in network traffic that traditional signature-based IDS tools cannot identify.
• Kerberoasting detection relies on correlating indirect indicators: a single source IP and client account requesting TGS tickets for an anomalous number of unique non-system SPNs within a short time window, rather than matching packet signatures.
• DNS tunneling detection via TXT records aggregates the combined byte volume of unique DNS query names and TXT response data per source IP, triggering when a configurable threshold is exceeded — a metric impossible to implement accurately with IDS signatures.
• KATA ships with 59 prebuilt NAD rule templates across six categories (Large Data Transfers, Suspicious Connections, Domain Attacks, Reconnaissance Activity, Connections to Suspicious Resources, C2 Communication) and supports up to 200 active rules simultaneously.
• NAD rules are not enabled by default; analysts must manually add and tune them using infrastructure-specific variables (excluded IPs, DNS server lists, thresholds) to minimize false positives.

Affected Systems

• Windows domain environments using Kerberos authentication
• Corporate networks with DNS infrastructure permitting outbound DNS traffic
• Active Directory environments with service accounts configured with SPNs

Vulnerabilities (CVEs)

None identified.

Attack Chain

1. Initial Access: Attacker breaches corporate network and obtains a low-privileged account with a valid TGT
2. Credential Access: Attacker requests TGS tickets for numerous non-system service accounts with SPNs (Kerberoasting), generating traffic indistinguishable from legitimate Kerberos activity
3. Credential Access: Attacker cracks service account passwords offline from extracted tickets without generating network activity
4. Command and Control: Attacker establishes DNS tunneling via TXT records, encoding data in subdomain strings and receiving commands via TXT response data
5. Exfiltration: Data is transmitted through the DNS tunnel, bypassing firewall restrictions using a protocol permitted in most corporate networks

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: Yes
• Platforms: KATA NAD SQL queries (ClickHouse), KATA prebuilt rule templates

The article describes SQL-based NAD rules within KATA's ClickHouse database for detecting Kerberoasting and DNS tunneling. Rule logic and variables are described in prose; SQL query snippets are shown in screenshots but full rule bodies are not reproduced in text. Rules are available as prebuilt templates within the KATA platform interface.

Detection Engineering Assessment

Required Log Sources

• Kerberos network session logs (TGS-REQ/TGS-REP with cname and sname fields)
• DNS query and response logs (including TXT record type and rdata fields)
• Network flow data with source/destination IP, port, and protocol metadata
• Active Directory service account and SPN inventory for baseline comparison

Hunting Hypotheses

Control Gaps

• Traditional IDS/IPS signature-based tools cannot correlate unique SPN counts across multiple Kerberos sessions, producing high false positives or missing Kerberoasting entirely
• Signature-based DNS monitoring cannot detect DNS tunneling without static tool markers, as individual queries appear legitimate
• Endpoint-only detection lacks network session aggregation needed to identify behavioral anomalies across multiple protocol interactions
• Firewall rules permitting DNS traffic outbound do not inspect TXT record data volume or subdomain entropy patterns

Key Behavioral Indicators

• Single source IP and client account (cname) receiving TGS-REP responses for N or more unique non-system SPNs within a defined time window
• DNS queries with abnormally long left-hand subdomain strings paired with a static right-hand domain portion, using TXT record types
• Cumulative byte volume of unique DNS query names plus TXT response data per source IP exceeding a baseline threshold
• Kerberos TGS requests targeting manually-created service accounts rather than system-generated SPNs (e.g., excluding CIFS/fileserver patterns)
• DNS sessions where the source IP is not an internal DNS server but is sending zone replication or high-volume TXT queries

False Positive Assessment

Recommendations

Immediate Mitigation

Infrastructure Hardening

• Consider implementing network-level monitoring that aggregates Kerberos session metadata (cname, sname, source IP) to detect anomalous SPN request patterns.
• Evaluate whether your DNS infrastructure can detect and alert on anomalous TXT record volume or unusually long subdomain strings per source host.
• Consider restricting outbound DNS traffic to authorized internal DNS resolvers only, preventing direct host-to-external DNS communication that could facilitate tunneling.
• If applicable, consider deploying or evaluating network anomaly detection platforms that support SQL-based behavioral rules with infrastructure-specific variable tuning.

User Protection

• Consider enforcing strong, complex passwords for all service accounts with SPNs, as Kerberoasting targets accounts with weak or unchanged passwords.
• Evaluate whether managed service accounts (gMSAs) can replace manually-created service accounts where supported, as they feature automatically rotated complex passwords.
• Consider monitoring for service accounts that have not had password changes in an extended period, as these are prime Kerberoasting targets.

Security Awareness

• Consider incorporating awareness of Kerberoasting and DNS tunneling risks into existing security operations training, emphasizing that these techniques blend with legitimate traffic.
• If your organization conducts purple team exercises, consider including Kerberoasting and DNS tunneling scenarios to test detection capabilities against behavioral anomalies.
• Consider educating infrastructure administrators on the security implications of creating service accounts with SPNs and the importance of strong password policies for these accounts.

MITRE ATT&CK Mapping