St. Lucie County in Florida discovered (alt link) a dozen Flock cameras whose ownership it can’t identify, and that the county government had not permitted.

I am reminded of the decade-old story of StingRay cell phone surveillance devices in Washington, DC, whose operators were also unknown.

My guess is that in the StingRay case, the devices were operated by foreign actors. This Flock case is more likely some local government entity that didn’t bother getting approval. Were I a foreign actor, I would rather hack the existing Flock network—like Israel did with Tehran’s surveillance cameras—than risk installing my own.

Regardless, once we normalize a surveillance infrastructure, both friends and foes will take advantage of it.

Introduction

Once the attacker has breached the corporate network, subsequent stages of the attack often involve leveraging standard domain infrastructure protocols: using Kerberos, running DNS queries, accessing internal services, opening network shares, and other common networking actions. Because this activity is virtually indistinguishable from legitimate network traffic, it is extremely difficult to detect it with traditional network attack detection tools.
Kerberoasting and DNS tunneling have long ceased to be exotic techniques. They are becoming standard methods in modern attacks because they allow attackers to execute critical compromise stages while remaining undetected by traditional security tools. A clear example of this trend is seen in latest campaigns, employing both Kerberoasting and DNS tunneling.

Traditional network security tools perform well when the attack features a distinct and identifiable indicator: a characteristic query string, a known malicious traffic pattern, or the source code of an already discovered exploit. While this approach to threat detection remains effective, it cannot always be applied to discovering network attacks that blend seamlessly with legitimate traffic inside a corporate network.

Instead of searching for explicit indicators of attack, Network Anomaly Detection (NAD) analyzes all traffic for suspicious artifacts that deviate from the host’s typical network activity. Within Kaspersky’s solution portfolio, this technology is implemented specifically in the Kaspersky Anti Targeted Attack (KATA) platform.

The system analyzes network traffic data (DNS, DCE/RPC, Kerberos and other packets) and extracts key parameters used to identify anomalous behavior. This approach enables searching for attacks on domain controllers, signs of traffic tunneling and exfiltration, C2 communications, and other scenarios that may point to compromise of network infrastructure.

However, Network Anomaly Detection is not built on a single, universal set of indicators. Each attack scenario employs tailored detection models that account for the specifics of the corresponding network protocol, typical host behavior, and characteristic deviations from that baseline. This article examines two practical examples – detecting Kerberoasting and DNS tunneling – to demonstrate how these principles are implemented in KATA’s NAD rules and why this approach proves more effective than traditional signature-based analysis.

Kerberoasting attack detection by KATA

Why standard tools have a hard time detecting Kerberoasting

The Kerberoasting attack leverages the standard operational logic of the Kerberos protocol. The attacker identifies service accounts configured with a Service Principal Name (SPN), requests a Ticket-Granting Service (TGS) ticket for them, and attempts to crack the password offline using a dictionary attack against the retrieved ticket. If the password is weak or hasn’t been changed in a long time, the adversary can bruteforce it to get it in cleartext. Subsequently, these compromised credentials can be leveraged for both vertical and horizontal movement across the network.

The essence of a Kerberoasting attack is that an adversary possessing a compromised low-privileged account and a valid Ticket-Granting Ticket (TGT) for that account can request TGS tickets with weakened encryption for service accounts with SPNs. Crucially, it doesn’t matter whether the compromised account actually holds access permissions for those services. Having obtained these tickets, the attacker can then take them offline and bruteforce the service account’s password by trying to decrypt the corresponding ticket locally, without generating any network activity. As the encryption key is based on the password hash, the adversary can guess the password upon finding the correct key.

The attacker’s objective is to find a service account that has a simple password. Most likely, this will be an account created manually by the administrators of the infrastructure or a service. This is precisely why attackers are not interested in system service accounts with SPNs (such as CIFS/fileserver.company.local); these are generated automatically and feature highly complex passwords that are impossible to bruteforce.

We should note that the TGS ticket requests made by attackers are identical to standard, legitimate requests. Every domain naturally exhibits a high volume of Kerberos traffic. Therein lies the primary challenge of detecting Kerberoasting: legitimate service ticket requests (TGS-REQ) are indistinguishable from those issued by attackers. Consequently, the primary detection method relies on correlating indirect indicators rather than signature matching. Key indicators include an anomalous request source (atypical host or user account), a surge in requested SPNs within a short time window, attempts to obtain service tickets for sensitive or privileged service accounts, and off-hour timing or unusual request volume when benchmarked against the historical profile of both the user and the host.

Most of these indicators can be detected using NAD technology, which helps analysts cut through high volumes of Kerberos traffic to establish a concrete hypothesis: who initiated the Kerberoasting attack, which service accounts are at risk, and why this activity deviates from the baseline.

In the context of this attack, the network anomaly stems from a single host – likely using a single user account (cname) – receiving TGS tickets ("msg_type": "KRB_TGS_REP") for numerous unique services with SPNs (sname) within a short timeframe. These service accounts are non-system accounts.

Example of a TGS-REQ – TGS-REP event pair from network session attributes

To detect this anomaly, the NAD rule titled “Signs of a Kerberoasting attack” implements the following logic:

1. From Kerberos network sessions during the search depth period, select only those with a successful Kerberos TGS-REP response, subject to the following conditions:
   • The IP address that initiated the session must not be excluded in the excl_sip variable.
   • The requesting client name (cname) must not be included in the excluded users list (excl_users variable).
   • The SPN (sname) must not be excluded within the rule. System SPNs are omitted from detection logic because they exist across most corporate environments and hold no interest for adversaries in this attack vector; including them in the total count of unique SPNs could lead to predefined threshold being exceeded, triggering false positives.
2. Extract the cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.
3. Group the sessions by the source IP address and client account name (cname), while aggregating sessions with unique SPNs.
4. Generate an alert if a single IP address using a single client account receives TGS-REP responses for N unique SPN names within the specified search depth window, where N equals or exceeds the threshold variable count_spns.
5. Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).

We should note that this type of logic cannot be implemented using IDS signatures. Consider creating a Suricata rule designed to detect Kerberos TGS-REP packets. To minimize false positives, we’ll exclude system SPNs (which carry highly complex passwords) and apply a threshold for the number of responses a single client can receive. However, such a rule cannot evaluate the uniqueness of the requested SPNs; it can only track packet counts. As a result, this signature would produce a high volume of false positives because any domain naturally generates large amounts of identical legitimate TGS-REP messages.

Furthermore, adding exclusions and tuning thresholds to fit your specific infrastructure environments is significantly more practical when managed through user variables in the interface rather than directly modifying the underlying structure of the IDS rule itself.

Creating a Network Anomaly Detection rule

Network Anomaly Detection (NAD) rules are written as SQL queries executed against KATA’s ClickHouse database. Below, we demonstrate how to add and deploy a rule.

To begin working with NAD rules, navigate to the “Custom rules” section of the interface and select “Intrusion detection”. Under the “Network Anomaly Detection” tab, you can create a new rule.

The Network Anomaly Detection page UI

When adding a new rule, an analyst can select an appropriate rule template from the prebuilt set supplied with product updates. They can also manually modify the rule added from the template (converting it to a custom rule while keeping the original template intact) or author a rule from scratch using the provided guide.

Upon selecting a template, the analyst can review the rule description and either adjust or leave the default values for the following settings:

• Search depth (the lookback window over which the SQL query will run)
• Schedule (the execution frequency for running the query against the specified search depth)
• Event regeneration period (the timeframe during which identical alerts will be aggregated into a single record rather than displayed as distinct events)

UI for creating a new NAD rule

To ensure the rule functions correctly, we recommend navigating to the “SQL-specific query” tab before deployment to review the variables used within the rule – a description for each variable is available by hovering over the question mark icon.

The variables are lists of IP addresses, dates, strings or numeric values that define the network infrastructure – such as domain controllers, DNS servers, time ranges, critical segments, and other entities. This allows you to tailor each rule to different network environments and incorporate specific infrastructure characteristics without modifying the underlying logic.

In our example, using variables allows you to adjust the “Signs of a Kerberoasting attack” rule as follows without altering the underlying SQL query:

• Exclude the source IP address of the TGS-REQ requests from the scope of detection logic (you can specify a single address, a subnet mask, or a dictionary containing addresses and subnets) as well as the requesting client account (accepts a single value or a dictionary with multiple values).
• Adjust the threshold value required to trigger an alert based on the number of unique SPNs in the TGS-REQ messages.

Query contents and variables used in the new rule

On this same page, you can test if the rule is functional prior to saving it.

Rule execution test results

When this rule triggers, an NDR:NAD alert is generated. In the alert card, the analyst can review basic information: IP addresses, ports, and participating network endpoints.

Alert card for the NAD rule

From there, the analyst can navigate to the associated event, which provides a detailed breakdown of the anomaly alongside links to the affected hosts.

NAD rule triggering event

If needed, the analyst can view and export the network sessions associated with the alert. These sessions can be accessed directly from the alert or within the event card via the “Show related” drop-down list.

Network sessions that triggered the rule

Within an individual session, the analyst can inspect standard details including interacting parties, data volume sent and received, and other fields and metrics. On the “Attributes” tab, the analyst can review the specific events recorded within that session.

Network session attributes

Detecting DNS tunneling in KATA

How DNS tunnels work

DNS tunneling is a technique used to transmit data or control malware through firewalls by encoding information within DNS protocol requests and responses. Instead of performing standard name resolution, an infected host transmits data encoded within subdomain strings and receives response data via DNS records. This covert channel can be leveraged for C2 communication, bypassing network restrictions, or data exfiltration.

One method of implementing DNS tunneling involves utilizing TXT records. In this scenario, the client issues DNS TXT record queries for domain names where the right-hand portion of the domain name (the higher-level domains) remains static, while the left-hand portion (the lowest-level subdomain) carries encoded or encrypted data sent from the client to the server. Under this structure, a sample domain name might look like ZFcABQAIBA[.]testlab[.]local, where testlab[.]local serves as the static right-hand portion and ZFcABQAIBA represents the variable left-hand string containing the data transmitted by the client.

In response to these queries, the server delivers commands or messages inside the data field of the TXT response. Because the right-hand portion of the domain name remains static, all client queries are consistently routed to the same C2 server, even if the intermediate DNS resolvers targeted by the client change.

DNS query (left) and corresponding response (right) during DNS tunneling via TXT records

It is rather challenging to identify this malicious activity within DNS traffic without generating false positives. DNS traffic is permitted across almost all corporate networks, long domain names occur routinely in both internal and external environments, and TXT records are frequently leveraged for legitimate operational purposes.

Suspicion is established through a combination of indicators: a high volume of long, seemingly random subdomains associated with a single top-level domain, high request frequency, an unusually large number of unique names, non-standard record types, and significant data transfer volumes within a single DNS session.

By analyzing DNS traffic for threat detection, we identified three primary fields of interest:

• Requested DNS name
• DNS record type
• TXT data field within the response

As shown in the image above, all of these fields are present in the DNS response. In a real-world scenario, a tunnel of this nature will transmit a volume of data that is abnormally large compared to standard DNS traffic.

Data exchange within a DNS tunnel

Thus, in the context of DNS tunneling, a network anomaly occurs when 1) a single query source host sends data embedded in the variable left-hand portion of domain names (rrname) while 2) maintaining a static right-hand portion (rrname) and 3) receives DNS server responses containing TXT records (rtype) with varying data (rdata), while 4) the total volume of data transmitted in the left-hand portion of the requested domain name together with the TXT data response (rdata + rrname) exceeds a predefined threshold.

Request and response events from DNS session attributes

When detecting DNS tunneling, the following nuances must be considered:

• A single tunnel will not be constrained to a single DNS session; data may be transmitted across multiple sessions with the DNS server, or each individual request may occur within a separate session.
• A client DNS query can contain more than one requested domain name.
• A DNS response can contain multiple TXT records, as well as a large volume of various non-TXT record types.
• Traffic between DNS servers must be excluded, as it duplicates client requests and can trigger false positives.
• Although the factors outlined above (an abnormally large or frequently changing left-hand subdomain alongside a static right-hand domain, or an unusually long string in a TXT record) serve as key indicators of DNS tunneling, they can also occur within legitimate network traffic.

These challenges create a high likelihood of false positives when detecting DNS tunneling, particularly when using IDS-based tools. Writing an accurate IDS rule for this type of activity is practically impossible. With rare exceptions, DNS tunneling tools possess static markers that can be leveraged for signature-based detection. However, in the absence of such markers, signature methods fail to deliver high detection accuracy without generating an overwhelming number of false positives. In these cases, a comprehensive approach combining multiple correlated indicators is essential to improve overall detection quality.

DNS tunneling detection logic

To add a rule for detecting this anomaly, you can use the prebuilt “DNS data tunneling via TXT records” template in the new rule creation interface. The “SQL-specific query” tab will display the list of variables used:

• user_DNS_servers: a list of internal DNS server addresses within the infrastructure, required for the rule to function correctly and minimize potential false positives
• excl_sip: IP addresses to be excluded from the scope of the rule (you can specify a single address, a subnet mask, or a list containing both addresses and subnets)
• traffic_size: the threshold value for the total volume of data (in bytes) transmitted through the tunnel

Variables used in the “DNS data tunneling via TXT records” rule

The detection logic for this network anomaly is structured as follows:

1. From network sessions using the DNS protocol within the timeframe defined by the rule’s search depth, select only those sessions containing at least one TXT response.
   Additionally:
   • The IP address that initiated the session must not be excluded in the excl_sip variable.
   • The source IP address that initiated the session must not belong to the internal DNS servers listed in the user_DNS_servers variable.
   • The DNS names requested by the client must not be excluded within the rule.
2. Split qualifying DNS sessions into individual log lines, each corresponding to an individual request or response. Retain only DNS responses containing TXT data.
3. Extract DNS names and their associated TXT data from these DNS responses. Retain only unique values.
4. Group all resulting records by the session’s source IP address, aggregating all unique DNS names and TXT data blocks.
5. Generate an alert if the combined size (in bytes) of the unique DNS names and TXT response data for a single IP address within the search depth window exceeds the specified threshold (the traffic_size parameter).
6. Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).

“DNS data tunneling via TXT records” rule triggering event

The primary value of NAD technology in this scenario lies in noise reduction – by minimizing false positives – and faster investigation times. A DNS tunnel rarely presents itself as a single, blatantly malicious request. Instead, it leaves behind a behavioral footprint: repetition, length, domain structure, unusual record types, numerous subdomains branching off an unchanging root domain, and anomalous host behavior. KATA consolidates these indicators into a single alert, presenting the analyst with an actionable attack hypothesis rather than a set of fragmented DNS events.

Prebuilt rules for detecting network anomalies in KATA

KATA users should note that Network Anomaly Detection (NAD) rules are not enabled by default. Rules must be added manually using the procedure described in the preceding sections. This design ensures that analysts can fine-tune rules to fit specific network infrastructures using variables.

Analysts have three ways of creating new rules:

1. Adding a rule from a prebuilt template and adjusting custom variables. In this case, the rule is classified as a system rule.
2. Adding a rule from a prebuilt template and modifying its underlying SQL query (which requires enabling the “Unlock all template values” option) to create a custom rule based on the template. When modified this way, the rule transitions from a system rule to a custom rule.
3. Authoring a custom rule from scratch, which requires a basic understanding of ClickHouse SQL queries and familiarity with the product documentation.

As of this publication, the product ships with 59 prebuilt NAD rule templates (with additional templates delivered via product updates). KATA supports running up to 200 active rules simultaneously.

Prebuilt rules are divided into six categories:

• Large Data Transfers: tracking abnormally large network sessions across various protocols during regular hours, at night, or over weekends.
• Suspicious Connections: detecting suspicious connections that may indicate hazardous activity, shadow IT, evasion of attack detection mechanisms, and other threats.
• Domain Attacks: detecting classic attacks targeting domain network infrastructures using offensive tooling.
• Reconnaissance Activity: identifying suspicious activity within domain protocol sessions (Kerberos, DCE/RPC, LDAP, DNS) resembling domain reconnaissance.
• Connections to Suspicious Resources: detects actions that violate security policies, potential data exfiltration beyond the perimeter, and unauthorized internet access originating from secured network segments.
• C2 Communication: identifies network sessions characteristic of a potential C2 communication channel or tunnel.

The table below lists the rule templates for detecting network anomalies in KATA:

Conclusion

The examples of Kerberoasting and DNS tunneling clearly demonstrate why modern security defenses cannot rely solely on looking for known signatures and indicators of compromise. Both attack techniques abuse protocols that operate inside corporate networks every day. At the individual event level, they may look like legitimate activity, yet in behavioral context, they stand out as clear indicators of compromise.

NAD directly addresses this gap. Instead of relying purely on signature matches across Kerberos or DNS traffic, it highlights deviations from established baselines: who initiated the activity, how frequently it recurred, which services or domains were targeted, and why that matters for a specific infrastructure.

As a result, analysts gain a clear, actionable starting point for investigation. This capability is especially valuable for spotting the signs of APT group activity, which runs stealthily and is designed to blend in with legitimate operations. The importance of this capability will only grow: as attack techniques evolve, detecting suspicious activity at its earliest stages – before it escalates into critical service compromise or a data breach – becomes increasingly vital.

Introduction

Once the attacker has breached the corporate network, subsequent stages of the attack often involve leveraging standard domain infrastructure protocols: using Kerberos, running DNS queries, accessing internal services, opening network shares, and other common networking actions. Because this activity is virtually indistinguishable from legitimate network traffic, it is extremely difficult to detect it with traditional network attack detection tools.
Kerberoasting and DNS tunneling have long ceased to be exotic techniques. They are becoming standard methods in modern attacks because they allow attackers to execute critical compromise stages while remaining undetected by traditional security tools. A clear example of this trend is seen in latest campaigns, employing both Kerberoasting and DNS tunneling.

Traditional network security tools perform well when the attack features a distinct and identifiable indicator: a characteristic query string, a known malicious traffic pattern, or the source code of an already discovered exploit. While this approach to threat detection remains effective, it cannot always be applied to discovering network attacks that blend seamlessly with legitimate traffic inside a corporate network.

Instead of searching for explicit indicators of attack, Network Anomaly Detection (NAD) analyzes all traffic for suspicious artifacts that deviate from the host’s typical network activity. Within Kaspersky’s solution portfolio, this technology is implemented specifically in the Kaspersky Anti Targeted Attack (KATA) platform.

The system analyzes network traffic data (DNS, DCE/RPC, Kerberos and other packets) and extracts key parameters used to identify anomalous behavior. This approach enables searching for attacks on domain controllers, signs of traffic tunneling and exfiltration, C2 communications, and other scenarios that may point to compromise of network infrastructure.

However, Network Anomaly Detection is not built on a single, universal set of indicators. Each attack scenario employs tailored detection models that account for the specifics of the corresponding network protocol, typical host behavior, and characteristic deviations from that baseline. This article examines two practical examples – detecting Kerberoasting and DNS tunneling – to demonstrate how these principles are implemented in KATA’s NAD rules and why this approach proves more effective than traditional signature-based analysis.

Kerberoasting attack detection by KATA

Why standard tools have a hard time detecting Kerberoasting

The Kerberoasting attack leverages the standard operational logic of the Kerberos protocol. The attacker identifies service accounts configured with a Service Principal Name (SPN), requests a Ticket-Granting Service (TGS) ticket for them, and attempts to crack the password offline using a dictionary attack against the retrieved ticket. If the password is weak or hasn’t been changed in a long time, the adversary can bruteforce it to get it in cleartext. Subsequently, these compromised credentials can be leveraged for both vertical and horizontal movement across the network.

The essence of a Kerberoasting attack is that an adversary possessing a compromised low-privileged account and a valid Ticket-Granting Ticket (TGT) for that account can request TGS tickets with weakened encryption for service accounts with SPNs. Crucially, it doesn’t matter whether the compromised account actually holds access permissions for those services. Having obtained these tickets, the attacker can then take them offline and bruteforce the service account’s password by trying to decrypt the corresponding ticket locally, without generating any network activity. As the encryption key is based on the password hash, the adversary can guess the password upon finding the correct key.

The attacker’s objective is to find a service account that has a simple password. Most likely, this will be an account created manually by the administrators of the infrastructure or a service. This is precisely why attackers are not interested in system service accounts with SPNs (such as CIFS/fileserver.company.local); these are generated automatically and feature highly complex passwords that are impossible to bruteforce.

We should note that the TGS ticket requests made by attackers are identical to standard, legitimate requests. Every domain naturally exhibits a high volume of Kerberos traffic. Therein lies the primary challenge of detecting Kerberoasting: legitimate service ticket requests (TGS-REQ) are indistinguishable from those issued by attackers. Consequently, the primary detection method relies on correlating indirect indicators rather than signature matching. Key indicators include an anomalous request source (atypical host or user account), a surge in requested SPNs within a short time window, attempts to obtain service tickets for sensitive or privileged service accounts, and off-hour timing or unusual request volume when benchmarked against the historical profile of both the user and the host.

Most of these indicators can be detected using NAD technology, which helps analysts cut through high volumes of Kerberos traffic to establish a concrete hypothesis: who initiated the Kerberoasting attack, which service accounts are at risk, and why this activity deviates from the baseline.

In the context of this attack, the network anomaly stems from a single host – likely using a single user account (cname) – receiving TGS tickets ("msg_type": "KRB_TGS_REP") for numerous unique services with SPNs (sname) within a short timeframe. These service accounts are non-system accounts.

Example of a TGS-REQ – TGS-REP event pair from network session attributes

To detect this anomaly, the NAD rule titled “Signs of a Kerberoasting attack” implements the following logic:

1. From Kerberos network sessions during the search depth period, select only those with a successful Kerberos TGS-REP response, subject to the following conditions:
   • The IP address that initiated the session must not be excluded in the excl_sip variable.
   • The requesting client name (cname) must not be included in the excluded users list (excl_users variable).
   • The SPN (sname) must not be excluded within the rule. System SPNs are omitted from detection logic because they exist across most corporate environments and hold no interest for adversaries in this attack vector; including them in the total count of unique SPNs could lead to predefined threshold being exceeded, triggering false positives.
2. Extract the cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.
3. Group the sessions by the source IP address and client account name (cname), while aggregating sessions with unique SPNs.
4. Generate an alert if a single IP address using a single client account receives TGS-REP responses for N unique SPN names within the specified search depth window, where N equals or exceeds the threshold variable count_spns.
5. Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).

We should note that this type of logic cannot be implemented using IDS signatures. Consider creating a Suricata rule designed to detect Kerberos TGS-REP packets. To minimize false positives, we’ll exclude system SPNs (which carry highly complex passwords) and apply a threshold for the number of responses a single client can receive. However, such a rule cannot evaluate the uniqueness of the requested SPNs; it can only track packet counts. As a result, this signature would produce a high volume of false positives because any domain naturally generates large amounts of identical legitimate TGS-REP messages.

Furthermore, adding exclusions and tuning thresholds to fit your specific infrastructure environments is significantly more practical when managed through user variables in the interface rather than directly modifying the underlying structure of the IDS rule itself.

Creating a Network Anomaly Detection rule

Network Anomaly Detection (NAD) rules are written as SQL queries executed against KATA’s ClickHouse database. Below, we demonstrate how to add and deploy a rule.

To begin working with NAD rules, navigate to the “Custom rules” section of the interface and select “Intrusion detection”. Under the “Network Anomaly Detection” tab, you can create a new rule.

The Network Anomaly Detection page UI

When adding a new rule, an analyst can select an appropriate rule template from the prebuilt set supplied with product updates. They can also manually modify the rule added from the template (converting it to a custom rule while keeping the original template intact) or author a rule from scratch using the provided guide.

Upon selecting a template, the analyst can review the rule description and either adjust or leave the default values for the following settings:

• Search depth (the lookback window over which the SQL query will run)
• Schedule (the execution frequency for running the query against the specified search depth)
• Event regeneration period (the timeframe during which identical alerts will be aggregated into a single record rather than displayed as distinct events)

UI for creating a new NAD rule

To ensure the rule functions correctly, we recommend navigating to the “SQL-specific query” tab before deployment to review the variables used within the rule – a description for each variable is available by hovering over the question mark icon.

The variables are lists of IP addresses, dates, strings or numeric values that define the network infrastructure – such as domain controllers, DNS servers, time ranges, critical segments, and other entities. This allows you to tailor each rule to different network environments and incorporate specific infrastructure characteristics without modifying the underlying logic.

In our example, using variables allows you to adjust the “Signs of a Kerberoasting attack” rule as follows without altering the underlying SQL query:

• Exclude the source IP address of the TGS-REQ requests from the scope of detection logic (you can specify a single address, a subnet mask, or a dictionary containing addresses and subnets) as well as the requesting client account (accepts a single value or a dictionary with multiple values).
• Adjust the threshold value required to trigger an alert based on the number of unique SPNs in the TGS-REQ messages.

Query contents and variables used in the new rule

On this same page, you can test if the rule is functional prior to saving it.

Rule execution test results

When this rule triggers, an NDR:NAD alert is generated. In the alert card, the analyst can review basic information: IP addresses, ports, and participating network endpoints.

Alert card for the NAD rule

From there, the analyst can navigate to the associated event, which provides a detailed breakdown of the anomaly alongside links to the affected hosts.

NAD rule triggering event

If needed, the analyst can view and export the network sessions associated with the alert. These sessions can be accessed directly from the alert or within the event card via the “Show related” drop-down list.

Network sessions that triggered the rule

Within an individual session, the analyst can inspect standard details including interacting parties, data volume sent and received, and other fields and metrics. On the “Attributes” tab, the analyst can review the specific events recorded within that session.

Network session attributes

Detecting DNS tunneling in KATA

How DNS tunnels work

DNS tunneling is a technique used to transmit data or control malware through firewalls by encoding information within DNS protocol requests and responses. Instead of performing standard name resolution, an infected host transmits data encoded within subdomain strings and receives response data via DNS records. This covert channel can be leveraged for C2 communication, bypassing network restrictions, or data exfiltration.

One method of implementing DNS tunneling involves utilizing TXT records. In this scenario, the client issues DNS TXT record queries for domain names where the right-hand portion of the domain name (the higher-level domains) remains static, while the left-hand portion (the lowest-level subdomain) carries encoded or encrypted data sent from the client to the server. Under this structure, a sample domain name might look like ZFcABQAIBA[.]testlab[.]local, where testlab[.]local serves as the static right-hand portion and ZFcABQAIBA represents the variable left-hand string containing the data transmitted by the client.

In response to these queries, the server delivers commands or messages inside the data field of the TXT response. Because the right-hand portion of the domain name remains static, all client queries are consistently routed to the same C2 server, even if the intermediate DNS resolvers targeted by the client change.

DNS query (left) and corresponding response (right) during DNS tunneling via TXT records

It is rather challenging to identify this malicious activity within DNS traffic without generating false positives. DNS traffic is permitted across almost all corporate networks, long domain names occur routinely in both internal and external environments, and TXT records are frequently leveraged for legitimate operational purposes.

Suspicion is established through a combination of indicators: a high volume of long, seemingly random subdomains associated with a single top-level domain, high request frequency, an unusually large number of unique names, non-standard record types, and significant data transfer volumes within a single DNS session.

By analyzing DNS traffic for threat detection, we identified three primary fields of interest:

• Requested DNS name
• DNS record type
• TXT data field within the response

As shown in the image above, all of these fields are present in the DNS response. In a real-world scenario, a tunnel of this nature will transmit a volume of data that is abnormally large compared to standard DNS traffic.

Data exchange within a DNS tunnel

Thus, in the context of DNS tunneling, a network anomaly occurs when 1) a single query source host sends data embedded in the variable left-hand portion of domain names (rrname) while 2) maintaining a static right-hand portion (rrname) and 3) receives DNS server responses containing TXT records (rtype) with varying data (rdata), while 4) the total volume of data transmitted in the left-hand portion of the requested domain name together with the TXT data response (rdata + rrname) exceeds a predefined threshold.

Request and response events from DNS session attributes

When detecting DNS tunneling, the following nuances must be considered:

• A single tunnel will not be constrained to a single DNS session; data may be transmitted across multiple sessions with the DNS server, or each individual request may occur within a separate session.
• A client DNS query can contain more than one requested domain name.
• A DNS response can contain multiple TXT records, as well as a large volume of various non-TXT record types.
• Traffic between DNS servers must be excluded, as it duplicates client requests and can trigger false positives.
• Although the factors outlined above (an abnormally large or frequently changing left-hand subdomain alongside a static right-hand domain, or an unusually long string in a TXT record) serve as key indicators of DNS tunneling, they can also occur within legitimate network traffic.

These challenges create a high likelihood of false positives when detecting DNS tunneling, particularly when using IDS-based tools. Writing an accurate IDS rule for this type of activity is practically impossible. With rare exceptions, DNS tunneling tools possess static markers that can be leveraged for signature-based detection. However, in the absence of such markers, signature methods fail to deliver high detection accuracy without generating an overwhelming number of false positives. In these cases, a comprehensive approach combining multiple correlated indicators is essential to improve overall detection quality.

DNS tunneling detection logic

To add a rule for detecting this anomaly, you can use the prebuilt “DNS data tunneling via TXT records” template in the new rule creation interface. The “SQL-specific query” tab will display the list of variables used:

• user_DNS_servers: a list of internal DNS server addresses within the infrastructure, required for the rule to function correctly and minimize potential false positives
• excl_sip: IP addresses to be excluded from the scope of the rule (you can specify a single address, a subnet mask, or a list containing both addresses and subnets)
• traffic_size: the threshold value for the total volume of data (in bytes) transmitted through the tunnel

Variables used in the “DNS data tunneling via TXT records” rule

The detection logic for this network anomaly is structured as follows:

1. From network sessions using the DNS protocol within the timeframe defined by the rule’s search depth, select only those sessions containing at least one TXT response.
   Additionally:
   • The IP address that initiated the session must not be excluded in the excl_sip variable.
   • The source IP address that initiated the session must not belong to the internal DNS servers listed in the user_DNS_servers variable.
   • The DNS names requested by the client must not be excluded within the rule.
2. Split qualifying DNS sessions into individual log lines, each corresponding to an individual request or response. Retain only DNS responses containing TXT data.
3. Extract DNS names and their associated TXT data from these DNS responses. Retain only unique values.
4. Group all resulting records by the session’s source IP address, aggregating all unique DNS names and TXT data blocks.
5. Generate an alert if the combined size (in bytes) of the unique DNS names and TXT response data for a single IP address within the search depth window exceeds the specified threshold (the traffic_size parameter).
6. Within the event regeneration window, group under the initial alert all subsequent alerts associated with the same client IP address. This avoids creating duplicate event records by incrementing the aggregation counter (Total appearances).

“DNS data tunneling via TXT records” rule triggering event

The primary value of NAD technology in this scenario lies in noise reduction – by minimizing false positives – and faster investigation times. A DNS tunnel rarely presents itself as a single, blatantly malicious request. Instead, it leaves behind a behavioral footprint: repetition, length, domain structure, unusual record types, numerous subdomains branching off an unchanging root domain, and anomalous host behavior. KATA consolidates these indicators into a single alert, presenting the analyst with an actionable attack hypothesis rather than a set of fragmented DNS events.

Prebuilt rules for detecting network anomalies in KATA

KATA users should note that Network Anomaly Detection (NAD) rules are not enabled by default. Rules must be added manually using the procedure described in the preceding sections. This design ensures that analysts can fine-tune rules to fit specific network infrastructures using variables.

Analysts have three ways of creating new rules:

1. Adding a rule from a prebuilt template and adjusting custom variables. In this case, the rule is classified as a system rule.
2. Adding a rule from a prebuilt template and modifying its underlying SQL query (which requires enabling the “Unlock all template values” option) to create a custom rule based on the template. When modified this way, the rule transitions from a system rule to a custom rule.
3. Authoring a custom rule from scratch, which requires a basic understanding of ClickHouse SQL queries and familiarity with the product documentation.

As of this publication, the product ships with 59 prebuilt NAD rule templates (with additional templates delivered via product updates). KATA supports running up to 200 active rules simultaneously.

Prebuilt rules are divided into six categories:

• Large Data Transfers: tracking abnormally large network sessions across various protocols during regular hours, at night, or over weekends.
• Suspicious Connections: detecting suspicious connections that may indicate hazardous activity, shadow IT, evasion of attack detection mechanisms, and other threats.
• Domain Attacks: detecting classic attacks targeting domain network infrastructures using offensive tooling.
• Reconnaissance Activity: identifying suspicious activity within domain protocol sessions (Kerberos, DCE/RPC, LDAP, DNS) resembling domain reconnaissance.
• Connections to Suspicious Resources: detects actions that violate security policies, potential data exfiltration beyond the perimeter, and unauthorized internet access originating from secured network segments.
• C2 Communication: identifies network sessions characteristic of a potential C2 communication channel or tunnel.

The table below lists the rule templates for detecting network anomalies in KATA:

Conclusion

The examples of Kerberoasting and DNS tunneling clearly demonstrate why modern security defenses cannot rely solely on looking for known signatures and indicators of compromise. Both attack techniques abuse protocols that operate inside corporate networks every day. At the individual event level, they may look like legitimate activity, yet in behavioral context, they stand out as clear indicators of compromise.

NAD directly addresses this gap. Instead of relying purely on signature matches across Kerberos or DNS traffic, it highlights deviations from established baselines: who initiated the activity, how frequently it recurred, which services or domains were targeted, and why that matters for a specific infrastructure.

As a result, analysts gain a clear, actionable starting point for investigation. This capability is especially valuable for spotting the signs of APT group activity, which runs stealthily and is designed to blend in with legitimate operations. The importance of this capability will only grow: as attack techniques evolve, detecting suspicious activity at its earliest stages – before it escalates into critical service compromise or a data breach – becomes increasingly vital.

Multiple news outlets are reporting on Israel’s hacking of Iranian traffic cameras and how they assisted with the killing of that country’s leadership.

The New York Times has an on the intelligence operation more generally.

The evolution of vulnerability management in the agentic era is characterized by continuous telemetry, contextual prioritization and the ultimate goal of agentic remediation.

The post How to 10x Your Vulnerability Management Program in the Agentic Era appeared first on SecurityWeek.

Palo Alto Networks has not attributed the APT activity to any specific country, but evidence points to China.

The post Cyberspy Group Hacked Governments and Critical Infrastructure in 37 Countries appeared first on SecurityWeek.

Zero Trust is not a thing; it is an idea. It is not a product; it is a concept – it is a destination that has no precise route and may never be reached.

The post Cyber Insights 2026: Zero Trust and Following the Path appeared first on SecurityWeek.

aiFWall is a firewall protection for AI deployments built to use AI to improve its own performance.

The post aiFWall Emerges From Stealth With an AI Firewall appeared first on SecurityWeek.

Under the new rules, measures for 5G cybersecurity would become mandatory.

The post EU Plans Phase Out of High Risk Telecom Suppliers, in Proposals Seen as Targeting China appeared first on SecurityWeek.

Palo Alto’s crosswalk signals were hacked last year. Turns out the city never changed the default passwords.

We don’t have many details:

President Donald Trump suggested Saturday that the U.S. used cyberattacks or other technical capabilities to cut power off in Caracas during strikes on the Venezuelan capital that led to the capture of Venezuelan President Nicolás Maduro.

If true, it would mark one of the most public uses of U.S. cyber power against another nation in recent memory. These operations are typically highly classified, and the U.S. is considered one of the most advanced nations in cyberspace operations globally.

Artificial intelligence is transforming the way we work, learn, and innovate—and it’s doing so at a pace that surpasses every major technology before it. Microsoft’s inaugural AI Diffusion Report offers a comprehensive look at how AI adoption is accelerating worldwide, drawing on data from more than 100 countries. In less than three years, more than 1.2 billion people have used AI tools, a rate of adoption faster than the internet, the personal computer, or even the smartphone. This rapid diffusion underscores AI’s potential as a general-purpose technology but also highlights the urgent need to ensure equitable access.

The report introduces three indices—the AI Frontier Index, the AI Infrastructure Index, and the AI Diffusion Index—to help policymakers, researchers, and industry leaders understand where breakthroughs are happening, where capacity exists to scale, and where AI is being used to improve lives. These insights show that adoption is fastest where connectivity and digital infrastructure are strongest, while nearly four billion people still lack the basics needed to participate in the AI economy. Bridging this gap is essential to avoid deepening global divides.

Beyond the numbers, the report illustrates the need for collaborative action to expand access to digital infrastructure, strengthen skills development, and promote responsible AI policies. By investing in these foundational elements, governments and organizations can unlock AI’s potential for growth and innovation. The data makes clear that speed alone does not guarantee shared prosperity—broad accessibility does.

To explore the full findings and recommendations, read the AI Diffusion Report.

The post Understanding global AI diffusion appeared first on Microsoft On the Issues.

As Abu Dhabi and Dubai kick off a significant week hosting annual energy and technology conferences, we want to share details of our ongoing and planned investments in the United Arab Emirates. Roughly two and a half years ago, we embarked on a new AI initiative with the encouragement and support of both the United States and UAE governments. Much of this progress has involved a new partnership with G42, the UAE’s sovereign AI company, with whom we’re making critical progress.   

All told, Microsoft will invest $15.2 billion USD in the UAE between the start of this initiative in 2023 and the end of this decade, in 2029. This is not money raised in the UAE. It’s money we’re spending in the UAE. And as we do everywhere in the world, we’re focused not just on growing our business but also on contributing to the local economy. This involves bringing together three critical factors – technology, talent, and trust.   

On some days, it feels like the tech sector is gripped in a rhetorical race to announce ever larger, sky-high numbers. We believe in moving fast while staying grounded and being transparent about our investment details. And we want to share our strong conviction that our investments benefit the shareholders of our company, the people of the UAE, and the relationship between our two nations.   

Our investment numbers  

Our $15.2 billion USD investment includes the following:  

• Beginning in 2023 and through the end of this calendar year, Microsoft will have invested and spent just over $7.3 billion in the UAE. This includes our $1.5 billion equity investment in G42, more than $4.6 billion in capital expenses in advanced AI and cloud datacenters in the country, and more than $1.2 billion in local operating expenses and the cost of goods sold.   

• From the start of 2026 to the end of 2029, we will spend more than $7.9 billion in the UAE. This includes more than $5.5 billion in capital expenses for ongoing and planned expansion of our AI and cloud infrastructure, including new steps we will share publicly in Abu Dhabi this week. It also includes almost $2.4 billion in planned local operating expenses and the cost of goods sold.  

An investment in world-leading technology  

Some of our most important work involves exporting world-leading technology from the United States to the UAE. This includes the GPUs essential to power AI in our datacenters across the country that support the UAE’s people and institutions.  

Microsoft was one of the few companies during the previous administration to secure export licenses from the Commerce Department to ship GPUs to the UAE. In no small measure, this is because of the substantial work we did to meet the strong cybersecurity, national security, and other technology conditions required by these licenses. These licenses enabled us to accumulate in the country the equivalent of 21,500 Nvidia A100 GPUs, based on a combination of A100, H100, and H200 chips.  

Microsoft was also the first company this year under the Trump administration to secure export licenses from the Commerce Department to ship GPUs to the UAE. Approved in September, these were based on updated and stringent technology safeguards. These licenses enable us to ship the equivalent of 60,400 additional A100 chips, in this instance involving Nvidia’s even more advanced GB300 GPUs.  

While the chips are powerful and the numbers are large, more important is their positive impact across the UAE. We’re using these GPUs to provide access to advanced AI models from OpenAI, Anthropic, open-source providers, and Microsoft itself. We’re supporting AI-enabled applications, including our Copilot applications, from a wide variety of local and international providers. And we’re partnering with G42 to support public and private sector organizations across the UAE economy, as well as consumers across the country.  

The UAE’s ranking in the Microsoft AI Diffusion Report published last week shows the country leading the world in per capita AI usage. With 59.4 percent of the population using generative AI, the UAE is ahead of Singapore, which is in second place at 58.6 percent. Beyond these two, no other country tops the 50 percent mark. Microsoft’s infrastructure challenge in the UAE is not a risk of getting ahead of demand but keeping pace with it.  

Investing in talent  

Microsoft’s investment in the UAE is not just about technology, it’s also about people. By cultivating AI talent and skilling individuals to develop, deploy, and use AI in a way that reflects the region’s unique needs, Microsoft is helping to ensure that the UAE remains on the leading edge of AI diffusion.  

Today, Microsoft’s presence in the UAE reflects this commitment. Our growing team includes almost 1,000 full-time employees and related staff representing 40 nationalities. Nearly 100 of our employees are engineers, supported by an Emirati partner ecosystem that has grown almost threefold in just two years, now with 1,400 firms employing nearly 45,000 professionals across the country.  

This year, we established the Global Engineering Development Center in Abu Dhabi to attract world-class tech talent to the UAE. Our engineers not only develop new products and services for Microsoft, but support institutions and businesses across the region so they can use AI and cloud technologies to transform their own operations. As we look to the future, we aspire to grow our engineering teams further and add a new focus on domain-specific AI models and applications that will propel advances in key scientific and technological fields.  

We also opened a new center for the Microsoft AI for Good Lab in Abu Dhabi, staffed by PhD level research talent specializing in large-scale AI models, vision-language models, and post training techniques. Backed by Azure compute grants allocated to partner organizations, this team collaborates with nonprofits, start-ups, researchers, academic institutions, and local businesses to address humanitarian challenges across the Middle East and Africa using AI. Already, the Lab has partnered with researchers to train large language models for low-resource languages, including those spoken in Malawi, Tanzania, Kenya, Uganda, and the Democratic Republic of the Congo – helping ensure that AI serves communities that risk being left behind in the AI age.    

As the Microsoft AI Diffusion Report underscores, people need digital proficiency to fully participate in an AI-driven economy. Without the right skills, AI risks deepening inequality rather than broadening opportunity. That’s why skilling is a core pillar of our investment in the UAE.   

Last November, we committed to skill one million people in the UAE by the end of 2027–and we’re well on our way to meet – and exceed–our goal. Last month at GITEX, Microsoft partnered with UAE government entities to launch an initiative to upskill 120,000 government employees across the federal government, Abu Dhabi, Dubai, and Sharjah. We will also skill 175,000 students and 39,000 teachers through collaborations with GEMS, Abu Dhabi Department of Education (ADEK), and the Knowledge and Human Development Authority (KHDA). We will announce new steps in this area on Thursday in Dubai.  

Talent is the engine of AI leadership. Attracting, nurturing, and building AI talent and know-how is essential to the UAE turning its vision of becoming a global leader into a reality.   

Strengthening trust   

Ultimately, the use of AI depends on trust. People and institutions need to trust that AI will be developed and deployed with responsible safeguards. They need to have confidence that the cybersecurity of AI chips, models, and services will be protected. And they rightly expect AI to serve the public broadly, with cause for optimism that AI will reach and support the Global South.  

Given the role of export controls and other trade issues, the flow of advanced GPUs and AI models also requires trust between nations. This in turn requires clear rules and agreements, coupled with effective compliance systems. And as always, trust between nations depends on strong relationships between its people, grounded in mutual respect and appreciation for each other’s cultures.  

We’re focused on supporting all these needs.   

One important part of this is the Responsible AI Future Foundation, or RAIFF. G42, Microsoft, and Mohamed bin Zayed University of Artificial Intelligence (MBZUAI) founded this new foundation in Abu Dhabi in February to promote responsible AI standards and best practices in the Middle East and across the Global South. This foundation is advancing research on the technical and ethical elements of responsible AI and is developing frameworks to ensure ethical development and deployment of AI systems, accounting for cultural diversity.   

A second element comes to life through the first annual Abu Dhabi Global AI Summit, which began Sunday. Hosted by G42, Microsoft, the Responsible AI Future Foundation, and Eurasia Group’s GZERO Media, this Summit brings government ministers, private sector executives, and AI leaders together to discuss what’s needed to drive AI diffusion across the Global South. We meet at a time when there is a growing risk that uneven AI diffusion may widen the economic and societal gaps that divide the world. It’s imperative that governments, businesses, and non-governmental organizations collaborate and take new steps to promote broader access to AI.  

Both these elements build on a third and deeper initiative that Microsoft and G42 have advanced during the past two years. In conjunction with our $1.5 billion investment, Microsoft and G42 created last April a first–of–its–kind binding framework between two private companies. Developed in close consultation with the U.S. and UAE governments, this Intergovernmental Assurance Agreement (IGAA) ensures that both our companies meet or exceed U.S. standards in critical areas such as cybersecurity and physical security, export controls and technology transfer, data protection and responsible AI, and Know Your Customer (KYC) best practices.   

As we drafted the IGAA, we consulted not only leaders from government ministries in our two countries, but with members and staff of both political parties in both houses of Congress in Washington, D.C. We listened to feedback and adapted the IGAA to address their suggestions. And we’ve built a strong compliance infrastructure to implement these requirements based on industry best practices and auditing standards.   

All these steps help bolster mutual confidence and trust between our two governments. But trust between nations also grows through relationships among people. That’s why we’re advancing a fourth and new element this week, traveling to Abu Dhabi with a Seattle delegation of public and private leaders. The group includes a former Governor and local leaders in economic development, higher education, medical research, the non-profit community, and sports. The goal is to deepen understanding, exchange ideas, and explore solutions that can advance both regions.   

Looking to the future  

Microsoft is committed to the future of the UAE and a strong relationship between our two nations. We believe in the UAE’s long-term economic vision and the role the UAE and the U.S. continue to play together to support peace, stability, and growth across the Middle East.  

As we do everywhere we do business, Microsoft is committed to a broad perspective and long-term approach. Our work in the UAE has underscored the importance of connecting technology investments to initiatives to attract and develop the talent needed for a vibrant and self-sustaining tech ecosystem. And work to advance trust, which may seem peripheral to some, is in fact of central importance. From stronger business practices to broader international ties, trust is a critical catalyst for technology success at a local and global level.  

Technology is our business and we’re as excited as anyone by its potential. But we know that ultimately there is only one test that matters. It’s how our technology empowers others to achieve more. Like every public company, our shareholders rightly expect us to deliver value to customers in ways that enable us to continue to grow. But we also judge ourselves by whether we are generating local opportunities and growth that go well beyond ourselves. Across the UAE, we’re committed to passing this test.  

The post Microsoft’s $15.2 billion USD investment in the UAE appeared first on Microsoft On the Issues.

CSRI finds China and Russia may be coordinating ‘grey zone’ tactics against vulnerable western infrastructure

China and Russia are stepping up sabotage operations targeting undersea cables and the UK is unprepared to meet the mounting threat, according to new analysis.

A report by the China Strategic Risks Institute (CSRI) analysed 12 incidents in which national authorities had investigated alleged undersea cable sabotage between January 2021 and April 2025. Of the 10 cases in which a suspect vessel was identified, eight were directly linked to China or Russia through flag-state registration or company ownership.

Kent Ickler & Jordan Drysdale // BHIS Webcast and Podcast This post accompanies BHIS’s webcast recorded on August 7, 2018, Active Directory Best Practices to Frustrate Attackers, which you can view below. […]

The post Active Directory Best Practices to Frustrate Attackers: Webcast & Write-up appeared first on Black Hills Information Security, Inc..

John Strand talks about how BHIS pen tests companies who use the cloud. Want to know how you can defend against attacks in your cloud infrastructure? Keep your eyes peeled for […]

The post PODCAST: Attack Tactics Part 3: No Active Directory? No Problem! appeared first on Black Hills Information Security, Inc..

Lee Kagan* // Expanding upon the previous post in this series, I decided to rewrite C2K (find it here) to change its behavior and options for the user. In this […]

The post How to Build a Command & Control Infrastructure with Digital Ocean: C2K Revamped appeared first on Black Hills Information Security, Inc..

Lee Kagan* // Deploying an offensive infrastructure for red teams and penetration tests can be repetitive and complicated. One of my roles on our team is to build-out and maintain […]

The post How to Build a C2 Infrastructure with Digital Ocean – Part 1 appeared first on Black Hills Information Security, Inc..