Security lapse leaves sensitive information and contact details of 51 government officials exposed for 40 hours
The public body in charge of the UK’s state investments has been pushed to improve its internal security after a data breach left “high-level management information” publicly accessible for nearly two days.
UK Government Investments (UKGI), the agency that manages the taxpayers’ interest in a swathe of companies including Channel 4 and the Post Office, said the security failure also left more than 50 government officials’ personal details exposed for nearly 40 hours.
Continue reading...
© Photograph: Marina Demidiuk/Alamy
© Photograph: Marina Demidiuk/Alamy
© Photograph: Marina Demidiuk/Alamy
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.
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:
Login
excl_sip variable.cname) must not be included in the excluded users list (excl_users variable).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.cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.cname), while aggregating sessions with unique SPNs.count_spns.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.
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:
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:
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
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:
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:
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.
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 positivesexcl_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:
excl_sip variable.user_DNS_servers variable.traffic_size parameter).
“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.
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:
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:
The table below lists the rule templates for detecting network anomalies in KATA:
| Rule category | Rule name | Protocols used |
| Large Data Transfers | Data tunneling in DNS traffic | DNS |
| ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic (6 rules) | ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule) | |
| ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic at nighttime (6 rules) | ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule) | |
| ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic on non-working days (6 rules) | ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule) | |
| Suspicious Connections | Queries to unknown DNS servers | DNS |
| Use of unauthorized routes | TCP, UDP | |
| Use of suspicious ports for connections to external addresses | TCP, UDP | |
| Use of non-typical protocols for connections | TCP, UDP, HTTP, HTTPS, DNS, SMTP | |
| Inconsistencies with firewall configuration | TCP, UDP | |
| Use of unauthorized ports for RDP or SSH sessions (2 rules) | RDP or SSH (depends on selected rule) | |
| Interactions with external IP addresses over the RDP or SSH protocol (2 rules) | RDP or SSH (depends on selected rule) | |
| Suspicious RDP sessions with domain controllers | RDP | |
| Connection to an unknown server via Kaspersky Security Center ports | TCP, UDP | |
| Domain Attacks | Signs of a DCSync attack | DCE/RPC |
| Signs of a DCShadow attack | DCE/RPC | |
| Signs of DHCP spoofing | DHCP | |
| DNS queries to Canarytoken domains | DNS | |
| Signs of a Kerberoasting attack | Kerberos | |
| Signs of an AS-REP Roasting attack | Kerberos | |
| Signs of a brute-force password attack on SSH | SSH | |
| Signs of SOAPHound usage | LDAP | |
| Large-volume Active Directory object data collection via LDAP queries | LDAP | |
| Reconnaissance Activity | Getting information about a task in the Task Scheduler | DCE/RPC |
| Getting a list of Kerberos users | Kerberos | |
| LDAP queries to rights delegation attribute | LDAP | |
| LDAP queries to attribute for getting administrator passwords | LDAP | |
| Signs of an internal horizontal port scan | TCP, UDP | |
| Signs of an internal vertical port scan | TCP, UDP | |
| DNS zone data replication requests sent from sources other than DNS servers | DNS | |
| Successfully completed requests for DNS zone data replication sent from sources other than DNS servers | DNS | |
| LDAP query targeting a critical attribute of insecure credentials | LDAP | |
| Enumeration of domain accounts via LDAP queries | LDAP | |
| Exceeding the threshold for requested critical attributes in LDAP queries | LDAP | |
| LDAP search queries containing a high number of critical attributes | LDAP | |
| Connections to Suspicious Resources | Queries to unauthorized domain names | DNS |
| Transmission of large data volumes to cloud storages | TCP, UDP, DNS | |
| Connections to cloud storages or file transfer services | TCP, DNS | |
| Connections to public repositories | TCP, DNS | |
| Connections to resources of programs for traffic tunneling | TCP, DNS | |
| С2 Communication | Possible queries to DGA domains | DNS |
| DNS data tunneling via TXT records | DNS | |
| Numerous blocked connections to external addresses | TCP, UDP |
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.
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.
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:
excl_sip variable.cname) must not be included in the excluded users list (excl_users variable).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.cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.cname), while aggregating sessions with unique SPNs.count_spns.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.
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:
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:
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
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:
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:
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.
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 positivesexcl_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 tunnelVariables used in the “DNS data tunneling via TXT records” rule
The detection logic for this network anomaly is structured as follows:
excl_sip variable.user_DNS_servers variable.traffic_size parameter).“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.
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:
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:
The table below lists the rule templates for detecting network anomalies in KATA:
| Rule category | Rule name | Protocols used |
| Large Data Transfers | Data tunneling in DNS traffic | DNS |
| ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic (6 rules) | ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule) | |
| ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic at nighttime (6 rules) | ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule) | |
| ICMP, TCP, UDP, RDP, SSH or LDAP sessions with a large volume of traffic on non-working days (6 rules) | ICMP, TCP, UDP, RDP, SSH, or LDAP (depends on selected rule) | |
| Suspicious Connections | Queries to unknown DNS servers | DNS |
| Use of unauthorized routes | TCP, UDP | |
| Use of suspicious ports for connections to external addresses | TCP, UDP | |
| Use of non-typical protocols for connections | TCP, UDP, HTTP, HTTPS, DNS, SMTP | |
| Inconsistencies with firewall configuration | TCP, UDP | |
| Use of unauthorized ports for RDP or SSH sessions (2 rules) | RDP or SSH (depends on selected rule) | |
| Interactions with external IP addresses over the RDP or SSH protocol (2 rules) | RDP or SSH (depends on selected rule) | |
| Suspicious RDP sessions with domain controllers | RDP | |
| Connection to an unknown server via Kaspersky Security Center ports | TCP, UDP | |
| Domain Attacks | Signs of a DCSync attack | DCE/RPC |
| Signs of a DCShadow attack | DCE/RPC | |
| Signs of DHCP spoofing | DHCP | |
| DNS queries to Canarytoken domains | DNS | |
| Signs of a Kerberoasting attack | Kerberos | |
| Signs of an AS-REP Roasting attack | Kerberos | |
| Signs of a brute-force password attack on SSH | SSH | |
| Signs of SOAPHound usage | LDAP | |
| Large-volume Active Directory object data collection via LDAP queries | LDAP | |
| Reconnaissance Activity | Getting information about a task in the Task Scheduler | DCE/RPC |
| Getting a list of Kerberos users | Kerberos | |
| LDAP queries to rights delegation attribute | LDAP | |
| LDAP queries to attribute for getting administrator passwords | LDAP | |
| Signs of an internal horizontal port scan | TCP, UDP | |
| Signs of an internal vertical port scan | TCP, UDP | |
| DNS zone data replication requests sent from sources other than DNS servers | DNS | |
| Successfully completed requests for DNS zone data replication sent from sources other than DNS servers | DNS | |
| LDAP query targeting a critical attribute of insecure credentials | LDAP | |
| Enumeration of domain accounts via LDAP queries | LDAP | |
| Exceeding the threshold for requested critical attributes in LDAP queries | LDAP | |
| LDAP search queries containing a high number of critical attributes | LDAP | |
| Connections to Suspicious Resources | Queries to unauthorized domain names | DNS |
| Transmission of large data volumes to cloud storages | TCP, UDP, DNS | |
| Connections to cloud storages or file transfer services | TCP, DNS | |
| Connections to public repositories | TCP, DNS | |
| Connections to resources of programs for traffic tunneling | TCP, DNS | |
| С2 Communication | Possible queries to DGA domains | DNS |
| DNS data tunneling via TXT records | DNS | |
| Numerous blocked connections to external addresses | TCP, UDP |
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.
Virtually every website selling products or services features a live chat widget. It usually appears as a small window in the corner of your screen, complete with an agent’s name and picture.
Sometimes these chats simply collect tickets for tech support or sales to process. But often there’s a real person on the other end of the screen. And here’s where many users get an unwelcome surprise: agents can see absolutely everything you type into the chat box, even if you have no intention of sending it. In this article, we break down why this happens and what you can do about it.
It’s all thanks to a feature known as live typing preview, or real-time typing view, which exists under one name or another in almost every popular customer chat platform. Here’s how the developer of LiveAgent, a customer support system used by more than 40 000 companies, describes it in its blog: “This live chat typing preview allows agents to anticipate questions and deliver faster responses. Additionally, real-time chat monitoring enables supervisors to oversee chat interactions, ensuring quality and timeliness.”
While that might sound helpful and harmless to some, having their unsent messages watched without their permission can trigger outright panic for others. To make matters worse, it’s almost impossible to tell whether the website uses the feature. That is, unless the chat agent admits it to you directly… or replies to a message you decided not to send.
As an alternative, you can run a quick test: type out a message in the chat box, wait 15 seconds, and see if the agent starts typing a response. If they do, you’re almost certainly dealing with real-time typing view. Whether to continue that conversation is up to you. Most importantly, never type personal information into a chat box — even if you are doing so from a Kaspersky Premium device.
Real-time typing view is just the tip of the iceberg. In reality, websites collect far more information than you might think. You’re likely already familiar with cookies, and have probably asked yourself at least once, “Should I accept these or not?” We answer that and other questions in our post Taking the biscuit: why hackers like cookies so much.
Tracking techniques that use web beacons and tracking pixels are not as widely known. To learn why they’re a concern and how to turn them off, check out our post Who is tracking you on the web and how.
Another technology that remains largely unknown to the general public is session replay scripts. These tools allow website owners to watch a recording of your visit: how fast you moved your cursor, where you clicked, which pages you browsed, and what you added to your shopping cart.
Of course, the primary goal of session replay is the same as real-time typing view: improving customer and user experience. It helps companies analyze your behavior, identify friction points, and make improvements. If a customer fails to complete a checkout or encounters a technical issue, developers can review the recording of their session to pinpoint what went wrong.
In theory, it sounds helpful enough: “We will collect a small amount of data about you to make the site better for you.” In practice, however, this approach comes with significant risks for users.
The primary risk here lies in whether websites collect this data legally, how they store it, and whether they share it with anyone. While you can usually gauge legality by reading their privacy policy, the terms of data storage and sharing are often described vaguely.
On top of that, users rarely realize an agent can read their message before it’s actually sent. If you change your mind about asking a question, edit a sentence, or delete your text entirely, that doesn’t mean no one saw the draft. Unlike cookies, opting out of this technology is practically impossible. Most chat widgets simply don’t offer a setting to disable typing previews.
As for tracking pixels, web beacons, and session replays, they’re essentially a form of digital surveillance. Beyond collecting vast amounts of data, they can also slow down your device’s performance. Even worse, if attackers compromise a website’s analytics system, they can gain access to this data, reconstruct your path through the site, and uncover details that can be leveraged in future attacks. To learn more about how scammers pull off these tricks and how social engineering works, check out our post They’re reading you like a book: scammers’ favorite tricks.
While you can’t prevent a potential breach on a third-party website, you can — and should — take steps to secure your own browsing session.
First and foremost, pay close attention to what you type in a chat box. It’s critical never to share personal data, credit card numbers, logins, passwords, or any other sensitive information with live chat agents.
Beyond that, there’s always a risk of landing on a phishing site and entering your account credentials there. To prevent this, we recommend using our security solutions, which block visits to malicious and suspicious websites. We also suggest storing your credentials in Kaspersky Password Manager — our password manager won’t let you auto-fill saved logins and passwords on a fake site.
Users of Kaspersky Standard, Kaspersky Plus, and Kaspersky Premium have access to our Private Browsing feature (on Windows and macOS). It prevents third-party services from tracking your online activity and collecting real-time information about what you do on websites.
To minimize the risk of data leaks, keep these tips in mind:
Tired of endless digital tracking? Here’s how you can protect yourself and your data:
- How to shrink your digital footprint
- Why data brokers build dossiers on you, and how to stop them doing so
- Turning purple: how visited links threaten your privacy
- How smartphones build a dossier on you
- The incognito myth: how private browsing really works
- Advertisers sharing data about you with… intelligence agencies
Hackers access Australian customers’ names, addresses, dates of birth, phone numbers and some bank account details, company says
Get our breaking news email, free app or daily news podcast
Origin Energy customers’ addresses, phone numbers and partial bank account data have been accessed in a hack, the company has confirmed.
The firm has 4.8m customer accounts in Australia, providing electricity, fossil gas, LPG and internet services to homes and businesses.
Continue reading...
© Photograph: Jason Reed/Reuters
© Photograph: Jason Reed/Reuters
© Photograph: Jason Reed/Reuters
A new report from the Government Accounting Office reveals that the Department of Homeland Security (DHS) plans to nearly triple the number of surveillance towers along U.S. borders, from the current 830 to 2,300 by 2034.
DHS expects to expend $1 billion in taxpayer dollars for this dangerous expansion of a surveillance network indiscriminately trained on towns, school playgrounds, backyards, and vehicles—threatening the privacy and civil liberties of everyone in the border regions.
The towers are planned as part of DHS component Customs and Border Protection’s (CBP) Integrated Surveillance Tower (IST) program, which captures images of people and vehicles. The IST program operates autonomous surveillance towers, consisting of autonomous surveillance towers, consisting of AI-based systems using radar, thermal infrared and optical systems to track targets over long distances; integrated fixed towers, optimized for surveilling foot traffic and vehicles; and remote video surveillance systems, which can often be found very close to the border fence in Arizona, including residential neighborhoods where cameras are capable of spying on homes on both sides of the border. (For a description and photos of these technologies, see EFF’s updated guide to surveillance at the U.S.-Mexico Border.)
DHS expects to purchase more long-range autonomous towers and to upgrade existing towers with autonomous capabilities. The $1 billion comes from the so-called One Big Beautiful Act—a massive tax and spending law that President Trump signed in 2025, the report says.
The explosive expansion of border surveillance is a digital dumpster fire for human rights and civil liberties. It’s not just surveillance towers; drones, aerostats, surveillance vehicles, ground sensors, game cameras, and license plate readers are also part of the vast taxpayer-funded infrastructure that threatens all those who live, work, or seek refuge in the borderlands. This technology isn’t exclusive to U.S. federal agencies: it’s also deployed by state and local law enforcement, and even by governments on the Mexican side.
Since 2022, EFF has studied and mapped surveillance technology along the U.S.-Mexico border using public records research, open-source intelligence, and fact-finding trips, and created a handy interactive map to provide researchers and journalists with the tools they need to analyze the impact of U.S. border security policy. We have also documented the different types of surveillance technology in a zine, "Surveillance Technology at the U.S.-Mexico Border." We updated the publication earlier this year to help people identify the machinery of homeland security by adding more models of surveillance towers, newly deployed military tech, and a gallery of disguised trail cams and automated license plate readers.
EFF’s work includes defending the rights of individuals whose devices have been searched or seized upon entering the country; pushing back on the collection of biometric and social media identifiers; and developing digital security guidance for people crossing borders.
With the web of surveillance tech at the borders about to explode, EFF will continue to investigate and expose it and find ways to fight back with the communities that live in the shadow of this technological threat to human rights.
When targeting an organization to steal information, maintaining a low profile is critical for attackers. They typically aim for long-term persistence, which requires avoiding security alerts while preserving access in case they’re detected and the organization initiates incident response or routine password resets. Malware such as infostealers or ostensibly legitimate remote monitoring and management (RMM) tools fail the first requirement: their use triggers EDR and generates suspicious events in SIEM consoles. Relying on stolen credentials conflicts with the second requirement: the moment the security team suspects a compromise, passwords can be changed immediately — terminating access. If attackers attempt to steal browser cookies instead of passwords, they face a different challenge: many online services now correlate device characteristics with the expected session cookie and block access if the cookie is used on an unrecognized device. Furthermore, cookie theft protection mechanisms implemented in Chromium-based browsers (such as Chrome, Edge, and Opera) this year have made this approach significantly more difficult.
To address this persistence challenge, the ToddyCat APT — whose main game is spying — developed a novel technique. Kaspersky experts discovered this method during an incident investigation and named it Shadow Token via Remote Debug (STRD). This technique allows the attackers to establish reliable, persistent access to a victim’s mailbox and other resources in Google Workspace. With minor adjustments, the same approach could potentially be adapted to target other services that grant third-party application access via OAuth 2.0 authentication.
First, the attackers must compromise the victim’s system with malware. In past campaigns, ToddyCat gained initial access to organizations by exploiting known vulnerabilities in server software and distributing malicious loaders via messaging apps. The specific employee targeted by the attackers might not notice the intrusion at all. This can occur, for example, if the adversary first obtains privileged administrative credentials and uses them to deploy the malware onto targeted machines remotely. Crucially, the deployment and execution of this malware mustn’t trigger immediate security alerts.
Once active, the malware executes an STRD attack, connecting the attackers’ remote service to the victim’s mailbox using the OAuth 2.0 protocol. This process requires no user interaction and shows no visible activity on the screen. To the cloud environment (Google Workspace, in the case at hand), the activity appears as if the user has legitimately authorized a third-party app for email access or data backup.
After that, the malware can terminate its operations and even delete itself from the system. The adversary retains direct access to the mailbox using the acquired OAuth token — and they need no connection to the victim’s endpoint or to the corporate network for that. Depending on the organization’s Google Workspace configuration, this access can persist for an extended period and survive subsequent password resets.
At the heart of this attack is a connection to Google Workspace services via OAuth 2.0. This is a legitimate workflow used whenever a third-party application requests access to calendar data, emails, or Google Drive files. For example, to display calendar meetings in Zoom and automatically generate conference links, a user must authorize Zoom to access Google services. Similarly, configuring a third-party email client or calendar app requires granting permission. During this authorization process, the service requesting access opens a new browser window. In this window, Google Workspace first prompts the user to select the appropriate account. Once the account is chosen, the subsequent screen displays the specific permissions requested by the third-party app, allowing the user to either approve or deny access. For this scenario to proceed seamlessly, the user must already be authenticated to Google services in their browser — which is typically the case in organizations using Google Workspace. If the user isn’t authenticated, additional steps for entering credentials and completing multi-factor authentication are introduced into the sequence.
The ToddyCat hackers developed a malicious tool called Umbrij to facilitate a two-step covert authorization process when the user is already authenticated in Google. First, the malware identifies the browsers installed on the system, and locates the specific folder storing the user’s active profile for each. The attackers target Chrome and Edge, as these are the browsers most likely serving as the primary ones within the organization.
Next, Umbrij copies the entire user profile folder to a different directory on the machine. It then launches an instance of the browser, specifying the path to the duplicated profile via the command line. Because this duplicate profile contains the user’s session cookies, websites with saved credentials won’t prompt for re-authentication. Furthermore, since this occurs on the exact same computer where the primary browser is running, online services detect no anomalies. The browsing history for this newly launched instance is isolated within the new folder, keeping it hidden from the user’s main account activity.
Crucially, the browser is launched in a dedicated debugging mode typically reserved for web development. The browser window and user interface don’t appear on the screen at all (headless mode). Instead, the browser can be controlled through a debugging port using the DevTools protocol, allowing the malware to issue commands and read the state of the screen. To orchestrate these actions, Umbrij leverages Puppeteer, a legitimate automation library.
After verifying that the debugging browser instance has launched successfully, Umbrij opens a legitimate Google Workspace OAuth screen within it. The request sent to Google is engineered to bypass additional security checks while requesting maximum access privileges. For the application ID — the identity supposedly requesting these extensive permissions — the malware impersonates one of two legitimate tools: Google Workspace Migration for Microsoft Outlook (GWMMO), or Google Workspace Sync for Microsoft Outlook (GWSMO).
When Google opens the window within the headless browser, Umbrij uses debugging tools to programmatically click on the corporate account name and the confirmation buttons. As a result, Google generates an authorization code for the app. Umbrij extracts and saves this code, subsequently forwarding it to the attackers’ command-and-control server. Finally, operating entirely within their own infrastructure rather than on the victim’s computer, the attackers exchange this authorization code for an OAuth access token. This single token is all they need to maintain long-term unrestricted access to the mailbox.
If a Google Workspace account is compromised, incident response measures must include the following steps after collecting the necessary logs and other forensic data for investigation:
In addition, security and IT teams must systematically audit issued OAuth permissions, revoke unjustifiable access rights, and restrict capabilities that allow excessive or unauthorized permission grants. We covered this topic in detail in our article on blocking unwanted AI assistants.
While Kaspersky users are protected against the Umbrij tool, security teams should proactively implement policies that prevent standard users from launching browsers in debugging mode. This functionality is intended exclusively for website and web app developers. This restriction can be enforced through the DeveloperToolsAvailability group policy (available for both Chrome and Edge).
Additionally, configure monitoring within your SIEM/XDR to track the launch of browser instances with an active debugging port. This event serves as a strong indicator of this specific attack technique.
Thalha Jubair, 20, and Owen Flowers, 19, sentenced to five and a half years each for cyber-attack that cost Transport for London £39m
The data of millions of commuters was stolen, Londoners were left out of pocket and 27,000 Transport for London staff were forced to reset their passwords.
Over four days in 2024 a pair of teenage hackers had London’s transport network at their mercy. Thalha Jubair and Owen Flowers had burrowed into the heart of Transport for London’s IT systems and held the “keys to the kingdom”.
Continue reading...
© Photograph: William Barton/Alamy
© Photograph: William Barton/Alamy
© Photograph: William Barton/Alamy
Signal agencies in Australia, the US, the UK, New Zealand and Canada sound alarm after Trump blocks foreign nationals from Anthropic’s Fable AI model
Powerful AI models capable of devastating new cyber attacks on governments and businesses are mere months away, intelligence agencies for the Five Eyes have warned in a rare joint statement, urging leaders to “act now”.
The surprising public intervention by signals agencies for Australia, the US, the UK, New Zealand and Canada comes after the Trump administration earlier this month decided to block “foreign nationals” from using a much-hyped AI model built by tech company Anthropic, called Fable.
Continue reading...
© Photograph: Andre M Chang/ZUMA Press Wire/Shutterstock
© Photograph: Andre M Chang/ZUMA Press Wire/Shutterstock
© Photograph: Andre M Chang/ZUMA Press Wire/Shutterstock
