Kerberos Brute Force
Attacker Behavior / Model Purpose
Kerberos brute force can be divided into two distinct attacker behaviors. Brute force attacks against passwords on a single account and brute force attacks against multiple accounts. Both tactics are common for attackers if they are looking to quickly move through a network. Modern encryption schemes makes cracking passwords offline difficult, and there are many improvements to deny the use of Pass the Hash vulnerabilities (Using an encrypted password hash to authenticate against services without having to know the decrypted hash). The Vectra Kerberos Brute Force model covers both scenarios.
In general, Vectra’s Kerberos models perform unsupervised machine learning and anomaly detection on the following Kerberos attributes as seen from the perspective of Kerberos network traffic.
- Source IP address
- Destination IP address
- Realm (Domain Name)
- Message Type (AS Request, AS Reply, Ticket Granting Service Request and Ticket Granting Service Reply)
- Queries for Host / User, service, server or realm against the resources being accessed i.e File Server, Printers, Web apps etc.
Kerberos Brute Force detections will cover scenarios where large and unusual numbers of Kerberos authentication attempts have been made to either one or many KDCs for one or many service types.
Why is this coverage important?
Ensuring that there is sufficient visibility of brute force attempts is vital to ensuring the security posture of an organization. Account lockout policies can be used to enforce security, however the attempts to brute force and the locking of accounts may not happen in business hours and may bypass usual security observations.
Contents of the detection page
Figure 1 A screenshot of the Vectra Kerberos Brute Force detection page. Identifiable information has been redacted.
The Kerberos Brute Force detection page provides important details for Kerberos Auth activity from the time surrounding the Brute Force detection event. The Summary section, highlights the Host that initiated the brute force attempt as well as the account which was being brute forced and the number of Authentication attempts and services which were observed.
The Recent Activity section contains the details from authentication events in the 45 minute time window surrounding the brute force detection event. In the example shown, the first column displays the hosts which attempted to use the account, the next two columns show which servers and services were targeted at the time of detection. The next columns show the number of authentication attempts and the time range in which these attempts happened.
The Kerberos Brute Force detection is associated with the account that is in listed in the identity field of the summary section. The Internal Host column actually tracks the hosts that this account was seen making authentication attempts from. In many cases all hosts in that column may be identical, in other cases there may be a variety of hosts.
How to interpret this detection
Understanding the attack behavior is the most important part of interpreting this detection, brute force activity is something which is usually performed by an attacker using a tool. Because of this the Attempts will be very high and the timeframe very short. It is also best to download the PCAP and look at the timeframe in between the authentication attempts. Using the error codes in the PCAP may also give you information as to whether the detection is benign or not. Some common Kerberos error codes to see in this detection are:
- KDC_ERR_NAME_EXP - Client's entry in KDC database has expired
- Normally happens when a client LoginExpirationTime field has expired.
- KDC_ERR_C_PRINCIPAL_UNKNOWN - Client not found in Kerberos database
- This happens when a client is non-existent in Active Directory or the name is wrong.
- KDC_ERR_S_PRINCIPAL_UNKNOWN - Server not found in Kerberos database
- This happens when a client attempts to access a service / resource which does not exist. This could be indicative of malware attempting to perform reconnaissance on a network or a threat actor performing service scanning.
- KDC_ERR_CLIENT_REVOKED - Client’s credentials have been revoked
- This happens when a client is either locked out or the account is disabled. This is a red flag for many detections as there is normally a good reason as to why an account is disabled.
- KDC_ERR_PREAUTH_FAILED - Pre-authentication information was invalid
- Preauth data is a way for the server to ensure that the client who is requesting to authenticate is a genuine user, this is done by encrypting the current time with the users password. Because Active Directory also stores the password it can decrypt this and validate the time. If there are large amounts of Pre-auth Failures or Pre-auth missing errors this could be indicative of an attacker using a non-supported mechanism to attempt to authenticate.
- KDC_ERR_WRONG_REALM - Incorrect domain or principal.
- This happens when an authentication request has the wrong domain name in the request, this may indicate a machine which is not associated with the corporate domain attempting to authenticate. It may also be a mistyped domain name whilst attempting to authenticate a user.
Scores for this detection are derived from the amount of authentication attempts for the account which was observed and how far this number deviates for previously observed authentication attempts.
Benign Detection Events
Benign detections of a Brute Force attempt would be those which have fired because of configuration error or similar activity. Because the deviation in authentication attempts must be statistically much higher than normal in a relatively short timeframe, it is unlikely that a user would be able to trigger this detection using manual input.
Common causes of this benign activity can include a changed password which has not been updated in a script which has the details hardcoded. Systems which rely on the user being logged in to function may also cause this, as when the user logs out the session will expire and the program may still try to authenticate. Finally, if a system used for Privileged Access Management tries to reconcile a password for a user who has left themselves logged in this may lock out the account and make it irreconcilable causing the errors leading to this detection.
If there is a suspicion of a true positive detection there is a high likelihood that an attacker has compromised a host and is using it to launch an attack against the account in the detection. The host from which the high volume of authentication attempts originated should be quarantined until either a malware scan, or deep forensics, can be performed. The account which has been observed in the detection should also be quarantined and the password changed. The user in question should be queried as to what activity they have been performing and if they have accessed content in an email or if they are aware of any suspicious behavior on their host. There could be a chance the host is unknown that an attacker has brought a machine into the network and is using it to brute force an account. This host should be quarantined from the network as soon as possible. The time at which this detection occurred may be helpful in determining if this is benign or malicious behavior. As a brute force is noisy attackers may tend to do this late at night to avoid detection.