Just finished the Checkpoint machine on Hack The Box (Medium difficulty) and it was a really enjoyable Active Directory box with some modern and creative attack paths.
I started with the provided credentials for `alex.turner`. After some enumeration I discovered that a previously deleted account (`mark.davies`) could be restored and that this account had write access to a share called DevDrop. This share was used by the organisation to stage VS Code extensions.
By creating a malicious VSIX extension targeting VS Code engine version 1.118.0 and dropping it on the share, a scheduled task automatically installed the extension and gave me a reverse shell as `ryan.brooks`. This was a really clean example of abusing enterprise software deployment processes.
From the `ryan.brooks` foothold I used Rubeus to obtain a TGT, then leveraged bloodyAD to create a malicious dMSA under a writable OU and impersonated a higher-privileged account. This eventually granted access to a VMBackups share containing a Windows Server memory dump. Using Volatility I extracted the local Administrator NTLM hash from the dump, authenticated with Evil-WinRM, and captured the root flag.
Overall, Checkpoint does a great job of chaining together several current techniques: writable shares for extension abuse, deleted object restoration, dMSA abuse, and memory forensics. It’s a solid Medium box that feels realistic and rewards careful enumeration.
Would recommend it to anyone working on modern Windows / Active Directory attack paths.
Most of you are used to working with tools on your Linux machine. A lot of these tools are built for it. WSL exists, but some of them can also run right inside your Chrome browser. NXC, SharpHound, LDAP-shell, Evil-WinRM and five more are bundled into one signed IWA with multi-protocol support.
Before we go any further, don’t use these tools against systems you’re not authorized to test, and don’t use your daily Chrome browser for this either.
Let’s take a closer look at the bundle and see how it works.
Setting Up
We’ll follow the manual on the website. The setup is quick and just needs a few adjustments to Chrome. The first step is enabling Chrome flags. Paste each of these links and change the status.
Then relaunch Chrome and open web-dev. Recent Chrome updates moved this from web-app-internals.
Here we install a new tool. Paste this link:
https://iwa-tools.pkilla.pw/iwa/update.json
Chrome will fetch the version. Press Install. In apps, you’ll see the iwa-tools console appear. That’s what you need to open.
Working with Tools
The first thing to do is list the help menu, which has all the commands you can run. Each command has its own help menu with the syntax.
iwa > help
iwa > command -h
Let’s do a quick port scan and find out what’s open on our Windows machine in the lab.
iwa > portscan IP 88,389,445,5985,9389 --timeout 2000
Source: Github
If Kerberos and LDAP are open, that means this host is a domain controller. We also have WinRM open. It may give us remote access on the DC with a valid admin account.
iwa > evil-winrm -H IP -u user -p password
Let’s list the DNS zones that our domain has available.
iwa > adidns -H IP -u user -d domain -p password --auth kerberos --tls --list
Source: Github
Finally, let’s see if we can escalate our privileges with ADCS. Certipy is used here.
iwa > certipy find -H IP -u user -d domain -p password --tls -enabled
Source: Github
If you get the same results showing ESC1 is vulnerable, that’s a quick win. There are plenty of write-ups out there on abusing it to get domain admin privileges in the tested domain.
Summary
Creativity has always been one of the most important skills for hackers. Turns out our favorite tools can run inside a browser and reach systems locally. You might still prefer the classic way, which is totally fine, but it’s good to know they work just as well from a browser tab.
If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.
PowerView is one of those tools that has become almost legendary in the world of Windows security. Originally it existed as PowerView.ps1, a script built to enumerate and understand Active Directory environments from the inside. It is used to ask the domain controller all kinds of questions and get detailed answers about users, computers, groups, privileges, relationships and sometimes even weaknesses.
The problem with the original script is that it only runs on Windows and every AV detects it. That’s why powerview.py was created.
OTW always stresses that recon is everything. Active Directory was not really designed to hide internal structure. Any authenticated domain users can enumerate almost everything inside the domain. Many junior pentesters feel lost when they first land inside a domain and aren’t sure what to do next. If that sounds familiar, this article is for you.
What If?
There are two issues you may encounter when working with powerview.py.
The first problem is credentials. Powerview.py requires valid domain credentials. So what happens if you do not have them? This is where MAQ, or Machine Account Quota, becomes important. By default, every user in Active Directory is allowed to create up to ten machine accounts. These machine accounts can authenticate to the domain and can therefore be used for enumeration. So if you have a shell or an RCE you simply create a machine account with a password and then use that account with powerview.py to log in. Some Active Directory setups are misconfigured and allow you to enumerate things anonymously.
The second problem is platform compatibility. Sometimes the machine you compromise is running Windows with no Python and a centrally managed antivirus you can’t disable. Other times you land on a sensitive Linux production box where installing tools isn’t an option. In those cases a reverse proxy tunnel is often the best solution. You can create one on Windows or Linux with this command:
ssh -R 1080 user@vps -Nf
Then you route traffic through port 1080 on your server using proxychains.
Setting Up
Let us prepare the environment for powerview.py. There are several ways, but this method works on most Linux systems:
kali > python3 -m venv venvs/powerview
kali > source venvs/powerview/bin/activate
kali > pip3 install powerview
Once you complete installation, you can connect to the domain controller.
Connection
Connecting to the domain controller is very flexible. You can authenticate using a password, an NTLM hash or even a PFX certificate:
With a password:
kali > powerview domain.local/lowpriv:Password123@192.168.1.12
With an NTLM hash:
kali > powerview domain.local/lowpriv@192.168.86.192 -H NTLM
With a pfx file:
kali > powerview 10.10.10.10 --pfx administrator.pfx
Capabilities
At this point you can explore everything powerview.py can do. Pressing Tab twice lists the available commands. If you’ve used PowerView.ps1 before, you’ll recognize a lot of the names and patterns, though some commands are different. Powerview.py doesn’t include every feature from the original script, but there’s more than enough to fully map a domain.
Every command contains a help section that explains available flags.
PV > Get-DomainComputer -h
Computers
In Active Directory, computers are objects just like users. Each one can have different permissions or roles. Certain misconfigurations can make certain computers valuable to attacks. Here’s how to list all enabled computers vulnerable to unconstrained delegation:
PV > Get-DomainComputer -Enabled -Unconstrained
Even small organizations usually have complex internal structures. You can count all enabled computers like this:
PV > Get-DomainComputer -Enabled -Count
Just 11 computers in our lab. Hackers usually export the names of all those computers and then ping them to get their IPs. That way they get a list of real computers rather than a mix with computer accounts. Exporting computer names looks like this:
PV > Get-DomainComputer -Enabled -Properties name -OutFile /root/computers.txt
You can also pull detailed information about a specific computer:
PV > Get-NetComputerInfo -Computer NAME
Older Windows versions are especially valuable since they often lack modern protections and are still running as critical production systems.
Users
We can enumerate users too. This command shows users with SPNs configured, meaning they’re vulnerable to Kerberoasting:
Exchange remains a high value target. It has certain privileges that can help hackers abuse it and escalate in the domain. On top of that, it has a long history of vulnerabilities like ProxyShell, which let hackers get in without valid credentials.
Vulnerabilities
PowerView also finds certain vulnerabilities automatically in its output, so you can quickly spot misconfigurations.
Summary
These examples are only a small part of what powerview.py can do. The tool also supports DFSCoerce, PrinterBug, and several Kerberos related attacks. The amount of information you can pull with just a low privileged account is enormous. That’s why we strongly recommend powerview.py for both defenders and red teamers.
Recon might not feel exciting at first, but it’s the true foundation of effective security work. When you learn to listen to what the domain is already telling you, the path forward becomes a lot clearer.
If you want to advance your Linux skills in a penetration testing environment, or you’re planning to take the OSCP exam, you need to get creative with how you use your Linux machine. We offer our Advanced Linux for Hackers training.
Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.
Initial access
In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.
GhostContainer on Microsoft Exchange
Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.
We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.
The backdoor is a .NET assembly containing three classes that implement its core functionality:
Stub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.
App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.
App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.
Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.
GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis
Traffic redirection
Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.
The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:
One of the repositories used for storing network tools
The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:
adobe_32.exe;
AdobeSync.exe;
trueconf.exe;
1cbroker.exe;
1c-office-plugin.exe;
trueconf-broker.exe.
Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.
Microsoft dev tunnels
This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
Execution graph of adobe_32.exe in Kaspersky Research Sandbox
rdp2tcp
This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attacker’s side.
When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.
When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.
Creation event for a channel named rdp2tcp (server component startup)
The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.
The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:
To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.
In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.
Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit
The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.
Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victim’s entire Active Directory infrastructure.
Takeaways
To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the group’s efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagle’s presence on the network.
Detection by Kaspersky solutions
Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kaspersky’s collection.
The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:
Backdoor analysis with KTAE
However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.
This malicious activity is detected by the following rules, available in the repository:
Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events
Completed the Hack The Box “Pirate” machine, a hard-difficulty Active Directory challenge that required chaining multiple attack paths rather than relying on a single vulnerability.
The enumeration phase uncovered domain users, pre-created computer accounts, GMSAs, delegation relationships, and an exposed internal network. Access to gMSA_ADFS_prod$ led to DC01 and enabled an internal pivot to WEB01. From there, the attack chain involved GMSA credential retrieval, NTLM relay, authentication coercion, shadow credentials, certificate-based authentication, and Kerberos ticket abuse.
The privilege escalation path continued through constrained delegation and resource-based constrained delegation. Kerberos ticket manipulation ultimately provided Administrator access to the domain controller, followed by a SYSTEM-level shell and extraction of domain credentials from NTDS.dit. Both the user and root flags were successfully obtained.
Another challenging AD machine completed and another deep dive into Windows authentication, delegation, and privilege escalation.
During a pentest, you often end up repeating the same things. You usually start with the same set of checks. You want to know if SMB shares are exposed, whether you can reach LDAP on the DC and find out how strong the password policies are. You also want to find misconfigured privileged accounts, roastable accounts and go through ADCS for potential escalation paths. These are the checks that always come up in Active Directory pentests.
Because of that, a lot of pentesters end up writing their own scripts and use tools that reduce the repetitive work. Today we’ll look at two tools that help here. It’s ADScan and ADPulse. ADScan is built for active enumeration and attack, while ADPulse is for read only auditing and reporting.
ADScan
We’ll start with ADScan. It automates Active Directory pentesting and does enumeration across DNS, LDAP, SMB and Kerberos, collecting data that can be fed into BloodHound for analysis. Later you’ll see you don’t even have to use BloodHound to process that data, since ADScan uses Python libraries to parse the JSON files and give you the output itself. You can act on findings right away, with Kerberoasting, AS-REP roasting, DCSync or just password spraying.
Sometimes you might start with no credentials at all or you might be handed a low-privileged account. ADScan works well in both cases.
Setting Up
The installation process requires some patience. Before starting, you need to have Docker installed on your Kali.
kali > sudo apt install docker.io
kali > sudo apt install docker-compose
kali > sudo service docker start
kali > sudo systemctl enable docker
Once Docker is ready, you can install ADScan.
kali > pipx install adscan
kali > adscan install
A stable internet connection is important here.
After installation completes, you will receive credentials for BloodHound. At this point, everything is ready and you can start the tool.
kali > adscan start
Inside the interface, you can see a help menu that keeps commands in logical sections.
Each section has its own subcommands.
Exploitation
As mentioned earlier, you can work with or without a domain user account. We’ll give it the credentials anyway.
start_auth
After running this command, give it the credentials and some details about the domain that you know.
From here, ADScan will run a few automated checks. It pulls in BloodHound data, looks for Kerberoastable and AS-REP roastable accounts and tries to find potential escalation paths in Active Directory Certificate Services.
In our case, the tool found that our lowpriv user has GenericAll permissions over sensitive groups. This comes from SDProp manipulation, where permissions are assigned in ways that aren’t easy to find using standard administrative tools (RSAT).
When enumeration’s done, ADScan gives you two different attack path engines. The first works with BloodHound, organizing findings into attack paths. This includes password spraying, Kerberos attacks, NTLM hash capture and other steps that gradually build toward higher levels of access.
The second engine uses a local Python based search that finds permission abuse through DACL misconfigurations. In our example, it showed that the user can directly modify membership in Domain Admins.
As the process continues, ADScan may also check for known vulnerabilities affecting domain controllers. It’s not unusual to find older systems still in use, which can be vulnerable to Zerologon or NoPac.
ADScan does not replace understanding, but it significantly improves efficiency and consistency.
ADPulse
ADPulse takes a different angle. It’s built as a read only auditing tool that evaluates the overall security posture of an Active Directory environment. ADPulse connects to a domain controller over LDAP or LDAPS and runs a defined set of security checks. These checks look for common misconfigurations, weak policies, and potential attack paths. The results come out in several formats (CLI, JSON, and HTML).
Setting Up
Compared to ADScan, setting up ADPulse is straightforward.
kali > git clone https://github.com/yourorg/adpulse.git
kali > cd adpulse
kali > python -m venv venv
kali > source venv/bin/activate
kali > pip install -r requirements.txt
Once the environment is ready, you can start it.
kali > python ADPulse.py –domain sekvoya.local –user lowpriv –password 'P@ssw0rd123!'
As it runs, ADPulse shows summaries right in the terminal, so you get a sense of what’s going on in the domain as it works. When the scan finishes, it generates both JSON and HTML reports. The HTML version looks good and lays out findings in a hierarchical structure with recommendations attached.
You can share these reports with sysadmins and defenders to help them understand what needs fixing and why it matters.
Summary
Active Directory pentesting starts with discovery and often moves toward exploitation, but it doesn’t always end with full domain compromise. Success isn’t measured by whether you get Domain Admin privileges, it’s measured by how well you identify and communicate the risks that could actually impact the organization. Sometimes the most critical findings are exposed data, weak configurations and small mistakes that could later get chained into bigger attacks.
If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.
Over the past few months, we’ve been covering different ways to use PowerShell to survive, wreck and hack systems. We’ve also covered different scripts stored in our repository for you to use. All of them come in handy during pentests.
Today we want to cover another tool called PsMapExec.
PsMapExec
It was developed by The-Viper-One and inspired by CrackMapExec/NetExec. PsMapExec doesn’t have identical features, but it’s got some stealth since it can load directly into memory without ever touching disk. It uses the current session to execute commands, so you don’t always need to know the victim’s password.
The script’s been around for a while but hasn’t gotten much attention, which is one of the reasons we decided to cover it here. Like most publicly available offensive tools, it’ll get flagged by AV if you load it directly. Sometimes hackers rewrite scripts, keeping the core functions intact, just to slip past the AV. On the other hand, finding a machine with no active antivirus isn’t always easy, but it’s almost always possible.
Loading in Memory
It’s best to execute the script directly in memory:
One of the first things you do on a compromised host is dump hashes. There are two kinds. SAM gives you local user account hashes, while LSASS holds the hashes of all connected users.
To dump local accounts from a single machine:
PS > PsMapExec smb -Targets MANAGER-1 -Module SAM -ShowOutput
To dump local accounts from all machines in a domain:
PS > PsMapExec smb -Targets all -Module SAM -ShowOutput
The output is clean and only includes valid local accounts. But keep in mind, the less noise you make the better.
Dumping LSASS Hashes
LSASS credentials get stored temporarily and hold domain user accounts you need to test Active Directory. In some organizations, critical users may belong to the Protected Users Group. That prevents their credentials from being cached in memory. It’s not something you see everywhere, but it’s worth noting.
You can also dump LSASS on a remote host, as you can see above.
Remote Command Execution
Every network is different. Some companies segment it to prevent lateral movement. That adds complexity. In that case, you need to pivot. A pivot host will either have the network interface you need or be able to ping hosts on another subnet.
To view network interfaces on all domain machines:
Another module is Kerbdump. It dumps Kerberos tickets from remote hosts and those tickets can be used for Pass the Ticket attacks. Some domains disable NTLM for security reasons and that’s when you’ll need these Kerberos tickets instead. Kerberos traffic is a normal and frequent part of AD traffic, so if you’ve got a choice between NTLM and Kerberos, go with Kerberos.
The script parses the output and assigns these tickets to variables that you can use for lateral movement.
Kerberoasting
Kerberoasting is a different kind of attack. Unlike KerbDump, it doesn’t give you reusable tickets, these need to be cracked to recover the password. Every once in a while you’ll find domain admins or service accounts with an SPN assigned to them. That SPN is what makes them vulnerable to Kerberoasting. Sometimes hackers intentionally assign an SPN to a user just to crack their password, but that requires privileges. Kerberoasting itself doesn’t, so you can get a hashed admin password using just a regular low privileged domain user.
Set an SPN for a user:
PS > PsMapExec ldap -Targets DC -Module AddSPN -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”
Kerberos tickets are encrypted using special encryption keys and you can extract those keys to decrypt or even forge tickets. That can be useful for persistence and lateral movement.
PS > PsMapExec wmi -Targets all -Module ekeys -ShowOutput
Timeroasting
This attack exploits how AD machines sync their clocks using the Network Time Protocol (NTP). Hackers can get the hashes for computer accounts this way.
Computer passwords are big strings of random characters, you can’t really crack them, unless the password matches the computer name. That happens when a computer’s configured as a pre-Windows 2000 computer. In that case, the password is a lowercase computer name without the trailing $. Otherwise, passwords are randomly generated.
This attack doesn’t really happen that often, but some computer accounts may have privileges over other objects in Active Directory that your user doesn’t have, so compromising them makes sense. You’ll see this more in bigger companies.
PS > PsMapExec ldap -Targets DC -Module timeroast -ShowOutput
With domain admin privileges, you can turn a domain user into a domain computer, get the hash and then revert the change. That’s a very stealthy way to get crackable hashes. We covered this attack in our article.
Finding Files
Some users just store credentials in text files on their Desktop. The Files module will find non-default files within user directories.
PS > PsMapExec wmi -Targets all -Module Files -ShowOutput
ACL Persistence
Hackers make mistakes and defenders take measures to evict them. Once credentials get changed, there’s not much you can do, unless you have ACL persistence.
You’ll often see DCSync privileges granted as one of them. With a DCSync attack, your computer impersonates a domain controller and requests password hashes from the domain. Another common one is granting GenericAll over AdminSDHolder to a user or computer. That lets you add new members to Domain Admins and change the passwords of its members.
Assign DCSync privileges:
PS > PsMapExec ldap -Target DC -Module Elevate -TargetDN “CN=username,DC=SEKVOYA,DC=LOCAL”
NTDS Dump
The NTDS dump is the final stage once domain admin privileges are obtained. PsMapExec will get the NTDS.dit and extract all NTLM hashes from it.
NTDS has all accounts that have existed in the domain.
Summary
PsMapExec is a great tool if you’re into hacking with PowerShell. It’s practical and has some features NetExec doesn’t. We’ve only covered some of them here, so give it a try and see what else it has under the hood.
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:
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.
Extract the cname (the name of the client requesting the TGS-REQ) and sname (SPN itself) from these qualifying sessions.
Group the sessions by the source IP address and client account name (cname), while aggregating sessions with unique SPNs.
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.
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:
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.
Split qualifying DNS sessions into individual log lines, each corresponding to an individual request or response. Retain only DNS responses containing TXT data.
Extract DNS names and their associated TXT data from these DNS responses. Retain only unique values.
Group all resulting records by the session’s source IP address, aggregating all unique DNS names and TXT data blocks.
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).
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:
Adding a rule from a prebuilt template and adjusting custom variables. In this case, the rule is classified as a system rule.
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.
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.
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:
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
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.
Completed another Hack The Box machine focused on Active Directory exploitation and privilege escalation.
The attack involved SMB enumeration, credential discovery through log analysis, Kerberos authentication, Shadow Credentials abuse, and DLL hijacking to gain user-level access. Further enumeration revealed a WSUS infrastructure weakness, allowing exploitation through Kerberos delegation abuse, certificate-based authentication, and a WSUS machine-in-the-middle attack to achieve Domain Admin privileges. This challenge strengthened my understanding of modern AD attack paths, Kerberos abuse techniques, and enterprise infrastructure security.
Login
