Suspicious Kerberos Client
Attacker Behaviour / Model purpose
The Suspicious Kerberos client model and detection are based on common attacker behaviour around accessing resources whilst trying to stay hidden. If a password had been compromised for a user account an attacker may use this password out of work hours to avoid raising suspicion, they may access resources outside of the scope of resources they usually access, the account may be used from an unusual host and in line with this, the authentication methods may be different than those normally used.
To support these detection types. Learning is done on the following Kerberos attributes:
- Domain Controller
Quantities of authentication attempts are also learned with respect to some of these authentication attempt attributes to help flag the volumetric anomalies.
The Suspicious Kerberos Client model is designed to alert on unusual Kerberos related authentication activity covering the following scenarios:
Detection Page Reason Description
More Detailed Explanation
Unusual for host to use these accounts
An authentication attempt was made from the host using an account that is not amongst the accounts that Vectra normally sees authenticate from this host.
Unusual for host to access these domain controllers
An authentication attempt was made from the host to a domain controller that is not amongst the domain controllers that Vectra normally sees the host authenticate to.
Unusual for host to access these services
An authentication attempt was made from the host requesting a service ticket that is not amongst the usual body of services that this host requests tickets for.
Unusual number of attempts
A significantly unusual volume of authentication attempts was made from this host.
Unusual number of accounts seen authenticating on this host
A significantly unusual number of accounts were seen authenticating from this host.
Unusual number of services accessed by this host
A significantly unusual volume of service tickets were requested by this host.
The Suspicious Kerberos Client detection leverages unsupervised machine learning to understand normal Kerberos authentication behaviour and distinguish significantly unusual behaviour that may be the result of an active attack. Through this method, the detection is able to covers the following attack behaviours:
- Pass the hash attacks
- Pass the ticket attacks
- Golden ticket attacks
- Shoulder surfing (Insider using some else credentials)
- Host brute forcing a specific account
- Host brute forcing multiple accounts
- Host starting to use resources he has never previously touched
Why is this coverage important?
If an attacker has managed to steal credentials or has a foothold in a network, they will try and use these credentials to reach deeper for further access through the server infrastructure or may just use them to access everything they can. It is common behaviour to do this outside of normal business hours as doing it during office hours may alert the user or security teams. This model also covers insider threat like behaviour, for example shoulder surfing credentials from an administrator and then reusing them on another machine to gain access.
A walkthrough of the detection page
Recent Activity panel
The time frame is represented by the symbol
Attempts at authentication is represented by the symbol
The red exclamation mark shows unusual behaviour, this will be either services, usernames or hosts or a number of events depending on the detection. The link labelled in the upper right of the reason panel shows more detail on the activity at the time of the detection. Learned behaviour which is normal is shown in the lower part of the panel.
How to interpret the detection
This detection algorithm looks for statistically significant discrepancies between normal Kerberos authentication behaviour for the host and the events that is has just observed. The detection page seeks to clearly distinguish the unusual behaviour from the normal (learned) behaviour by showing both to the user. Over time, learning continues and what was once unusual may eventually become learned as normal.
For unusual accounts the detection is rather self-explanatory. The security analyst should be asking, “should these accounts be authenticating from this host ?”
Unusual Domain Controller:
The host may have moved to a part of the network where its authentication attempts are being sent to a different DC. Alternatively, a new DC may have been added to the infrastructure and hosts are now attempting to authenticate to it.
Confusion can arise when investigating an unusual services detection primarily due to the obscurity of some of the service ticket types and names that can be requested. The following, is a list of common services and their meanings. A quick internet search can also help when an unknown service is encountered.
- CIFS: Common Internet File System is the native file sharing system in Windows environments. This is accessed when connecting to another computers shares.
- RPCSS: Remote Procedure Call System Service is the method by which computers can access remote services on another machine. This is accessed usually when a computer performs a WMI query / call.
- ProtectedStorage: This service is linked to authentication. If a user authenticates against a new system this service may be listed. It also involves sensitive data such a passwords and can be seen when password changes are made.
- LDAP: Lightweight Directory Access Protocol is a service used for storing authoritative information about accounts such as their access rights.
- KRBTGT: This service is part of the Kerberos authentication protocol and is used when trying to get a Ticket Granting Ticket.
- DNS: This service is used when clients are accessing the DNS services available for Domain Name Resolution.
The security analyst should be asking, “should the user be accessing these services / SPNs ?” Sometimes there may be a request which results in a Kerberos Error KDC_ERR_S_PRINCIPAL_UNKOWN this error means that the host attempted to connect to an unknown service. Large amounts of errors are sometimes indicative of a malware attack which uses Service enumeration to determine how much damage can be done.
Kerberos error codes can be seen by downloading the PCAP and using a tool such as wireshark to parse out the traffic. Common errors which may spur the need for additional investigation 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.
Observe if there are a large amount of errors of any kind, be especially wary of ones which indicate if an account is disabled or large amount of SPN errors.
This detection can be marked and triaged as benign when you can confirm the following
- The user has a valid account
- They are logging on from a machine they own or have access to
- They are using services which are expected
- They are a new user
- Infrastructure changes have been made that would cause new authentication routes
Because this model is based on usage patterns, a good understanding of the network and the infrastructure is very helpful. It is always best to check with a user than miss a red flag from Cognito.
To confirm the compromise the process is the same for confirming that the detection is benign.
- Check for a valid account or host
- Confirm with the user if they are aware of logging on at that time or from that host
- Ensure the machine is clear of malware
If there is a compromised machine isolate it from the network as soon as possible and start and incident response processes you have in place (forensics, clean up etc)
If an account has been compromised common steps to isolate and remediate include:
- Disabling the account until the user’s machine is confirmed clean
- Isolating the users machine and investigating to confirm that malware hasn’t been loaded
- Reset user’s password and check any privileged access they may have had.
- Look for other detections related to the source host, these will give you a clearer idea of compromise and lateral movement.