Detecting Attacks Against Kerberos with Network Metadata
By Netography Detection Engineering Team
Netography recently released a new collection of capabilities for detecting attacks on the Kerberos protocol that are often launched against Windows domains during network intrusions. Some of these attacks are difficult to detect with log monitoring, so the internal network visibility provided by the Netography Fusion platform can play an important role in helping you detect them.
Part of our philosophy at Netography is that the details of detection algorithms (what we call Network Detection Models), should be open source whenever possible. This allows our customers to understand why a particular traffic pattern within their network triggered our detection. It also empowers customers to modify our detections and build on top of them to fulfill unique use cases in their environments.
In keeping with that spirit, this blog post provides a deep-dive into different attacks against Kerberos, how our Detection Engineering/Threat Research team modeled those attack patterns, and how our Network Detection Models (NDMs) work to detect them. Our goal by sharing this information is to help our customers better understand these events when they fire and help them investigate the underlying root causes for the traffic patterns involved.
How do attackers target Kerberos?
Kerberos is a cryptographic protocol used for authenticating requests, which is used by Microsoft Active Directory. In the Kerberos protocol, users authenticate to a Ticket Granting Service (TGS), which is typically running on a Domain Controller. The TGS issues a Ticket Granting Ticket (TGT), which is proof of their successful authentication. They can then obtain access to services on the network by presenting this Ticket Granting Ticket back to the Ticket Granting Service and requesting a Service Ticket (ST) for that service, which they can then present to a server for access.
Compromises of enterprise networks always start with an attacker gaining an initial foothold. In some attacks, the first system that is targeted is a device with an externally facing service, such as a VPN gateway appliance with an exploitable security vulnerability. Controlling such a device would give the attacker access to the network, but may not provide them with a valid Windows domain account to start with.
Another common scenario is an attack that starts with an end user on a workstation clicking on a malicious link or opening a malicious attachment. This gives the attacker both an initial foothold within the network and access to the end user’s domain account. However, that initial domain account may be one with only limited access.
Regardless of the attacker’s starting point, their next challenge is to escalate their privileges to obtain broad access across the Windows domain.
Attackers that don’t have access to a domain account may perform User Enumeration against the Kerberos service in order to discover valid account names to target. They may then attempt Login Brute Forcing in hopes of gaining access to a valid account.
Unfortunately, these two attack scenarios can be difficult to detect, because unsuccessful Kerberos authentication attempts don’t show up in any default Windows logs unless the account gets locked out, a scenario that attack tools are designed to avoid. Fortunately, both attacks generate a lot of network activity. Therefore, a network monitoring technology like Netography Fusion with internal network observability can be an important means of detecting them.
Another attack that can be launched against Kerberos is called Kerberoasting. Service Tickets that are issued by Kerberos are encrypted with a hashed version of the service account’s password. In a Kerberoasting attack, an attacker gathers significant volumes of Service Tickets, which are taken offline where those service account passwords can be cracked.
On paper, a Kerberoasting attack involves very little observable network activity – it is totally normal for end-user accounts to request Service Tickets for different service accounts. However, in practice attackers often attempt to collect Service Tickets for a large number of different legitimate services, so they have lots of targets for their offline password cracking efforts. Therefore, they may generate a large volume of transactions that don’t resemble typical, day to day Kerberos traffic.
In addition, there is another related attack scenario called AS-REP Roasting. By default, users are required to pre-authenticate to Kerberos before requesting a Ticket Granting Ticket. However, it is possible to disable the requirement for pre-authentication on an account by account basis. In those cases, anyone can request a Ticket Granting Ticket for that account, and receive a response which is encrypted with the account’s password. That response can then be fed into an offline password cracker.
Attackers may attempt to enumerate accounts that are vulnerable to AS-REP Roasting even if they do not have a valid domain account, but this activity has a very similar network pattern to the User Enumeration attack and we are able to detect it with the same Network Detection Model.
Responses to successful AS-REP requests are also similar to Service Ticket responses (TGS-REP). A large number of successful AS-REP/AS-REQ requests in rapid succession is a potential indicator of AS-REP Roasting. Under normal circumstances a user would not generate large numbers of AS-REP/AS-REQ transactions, but an attacker might do so in order to obtain many AS-REQ responses for offline cracking. This activity looks very similar to Kerberoasting on the wire.
How did Netography investigate Kerberos attack traffic?
The first step in developing effective NDMs is to look at the patterns of network activity that are generated by real world attacks. We studied a variety of popular Kerberos attack tools to isolate the specific patterns of network activity they generated. The tools we investigated included Metasploit’s built-in Kerberoasting and service account enumeration tools, Nmap’s user enumeration, Kerbrute, Impacket, and Crackmapexec.
Distinguishing between legitimate and malicious network activity based on metadata alone can be difficult as metadata doesn’t examine content of the messages. One observation that we made after investigating the various Kerberos attack tools is that while the tools send different requests with different sizes, the responses from the targeted Kerberos server during an attack are largely consistent (with some differences due to different account or domain names). This general consistency provides us with the ability to interpret what sort of network transactions we are observing based on the metadata alone.
Login Brute Forcing involves a lot of failed logins. Based on our investigations, a failed Kerberos login using UDP generates the error message ‘KRB5KDC_ERR_PREAUTH_FAILED’ which shows up in network metadata as a ~1664 bit message. Using TCP, a failed attempt generates the same error message but shows up in network metadata as a ~3300 bit message. In comparison, the response to a successful TCP login comes in as ~15000 bits.
We used the distinction between these error and success response message sizes to develop a Kerberos Brute Force NDM called kerberos_brute_internal_internal.
The NDM logic looks for internal network traffic with source port 88 (that’s the Kerberos port). These are network flows from the Kerberos server back to the client. We examine the exact number of packets and bits to determine whether this traffic looks like a failed authentication response.
dstinternal == true && srcinternal == true && srcport == 88 && (
(protocol == tcp && (bits > 3000 && bits < 4000) && packets == 4) ||
(protocol == udp && (bits < 1800 && bits > 1400)))
The NDM has a medium threshold of count(dstport) >= 80 with a 60 second rollup window. Which means that in order for the NDM to trigger, the client must receive more than 80 responses like this to different requests within 60 seconds. (Each request would be sent on a different port.)
This is a very large number of failed requests that is usually characteristic of a brute force password cracking attempt. It is possible that a system running an automated job with incorrect authentication credentials could produce this volume of requests by attempting over and over again to generate tickets, but this is a misconfiguration that may be worth resolving if you observe it on your network.
User Enumeration is similar to login bruteforcing. A UDP-based attack generates the error message ‘KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN’ which is around 1152 bits. If a user is discovered, under most circumstances a ‘KRB5KDC_ERR_PREAUTH_REQUIRED’ message will be sent, which is much larger (~2040 bits). For TCP the error is the same as with UDP, but creates a flow that is ~2592 bits. The regular response is also significantly larger. Enumerating accounts that are vulnerable to AS-REP Roasting via Kerberos is essentially the same as any other Kerberos user enumeration attack and can be detected with this NDM.
Our user enumeration NDM is called kerberos_user_enumeration. Again we look for traffic flows from the Kerberos server with sizes that suggest the distinctive error messages associated with enumeration.
dstinternal == true && srcinternal == true && srcport == 88 && (
(protocol == tcp && (bits > 2400 && bits < 3000) && packets == 4) ||
(protocol == udp && (bits < 1250 && bits > 1100)))
The NDM has the same thresholds and rollup window that we used to detect brute force, so a very large number of failed requests is required to trigger it. A possible explanation for a benign event is a misconfigured system which is repeatedly attempting to access a domain account that has been removed.
For Kerberoasting, the TCP stream for ticket requests and responses (TGS-REQ/TGS-REP) also has a specific network metadata pattern. The request involves a 5 packet flow and the response is a 4 packet flow of about ~14000 bits. A very large number of ticket responses coming to the same host is a strong indicator of attack, because there are only so many services that a host would typically need to access during a short period of time.
In the AS-REP Roasting attack, a large number of AS-REQ/AS-REP transactions may be issued by the attacker. The responses received in the AS-REP Roasting attack look very similar to Kerberoasting on the wire, so this attack can also be detected with this NDM.
Our Kerberoasting NDM is called kerberosting_internal_internal. It has a medium threshold that requires 10 responses in 60 seconds. In environments where specific hosts (such as an application server) engage in high volume ticket requests, one could customize the NDM by increasing the threshold or by configuring the NDM to discard those IPs.
(dstinternal == true && srcinternal == true) && protocol == tcp && (srcport == 88 && (bits < 14500 && bits > 14000) && (packets == 4))
Conclusion
Today, sophisticated operations target entire organizations with slow, multi-stage attacks that gain footholds on networks and then pivot internally. Kerberos is often targeted as a part of the privilege escalation and lateral movement phases.
Gaining visibility into your internal network environment is critical for detecting attacks in these phases. A strategy that relies on endpoint agents alone for internal network defense cannot see activity involving appliances, IOT devices, and hosts where agents have been removed.
Network metadata is the best way to obtain comprehensive visibility across multiple cloud, on-prem, and datacenter environments with minimal operational overhead. Netography’s Detection Engineering Team is constantly developing new detections like these that maximize the value that can be extracted from metadata.