The Secure One Is Silent: Kerberos Stays Quiet, NTLM Tells

The Importance of NTLM Packets in Analysis Processes

In authentication processes, it is known that the Kerberos protocol is much more reliable and advanced compared to the NTLM protocol. However, because the security logs generated by the NTLM protocol contain more information, it can be more functional for analysts during incident response and log analysis processes.

The Kerberos protocol uses separate tickets for different session processes such as TGT and TGS, which makes authentication processes more optimized and secure. However, in the Kerberos tickets that are sent and received, detailed information about the client that initiated the request (for example, device name / workstation name) is not always clearly included. It is not guaranteed that Domain Controllers will map the information in 4768 and 4769 events to the 4624 log.

In contrast, in the NTLM protocol, the authentication packets sent by the client contain the client’s device name information, and this information is reflected in Windows security logs.

“Network logons with Kerberos likely have no workstation information.”

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624

Windows Security Event ID Distribution

Before continuing with the topic, it will be useful to examine the Event IDs generated by the Kerberos and NTLM protocols.

Event IDs in the 4768–4773 range represent authentication and ticket request processes belonging to the Kerberos protocol. These events only cover authentication requests and ticket operations. They do not directly represent a successful or failed logon session.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia

Event IDs in the 4624–4648 range, on the other hand, are events that can be generated by both Kerberos and NTLM protocols. Unlike the events in the 4768–4773 range, these events show that a logon process on the system has occurred successfully or unsuccessfully.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia

Authentication Package Information

When any log with Event ID 4624 is examined, it is seen that the “Authentication Package” field usually takes three different values: NTLM, Kerberos, and Negotiate. The Negotiate value is a mechanism that determines which protocol will be used depending on the environment conditions. For example, if there is no Domain Controller in the environment, access is made via IP address, or the required SPN/DNS conditions for Kerberos are not met, the NTLM protocol is preferred. If the architecture is suitable, the Kerberos protocol is used. For this reason, NTLM usage is encountered more frequently in logon types such as Logon Type 3 (Network), 8 (NetworkClearText), and 9 (NewCredentials), while Kerberos is mostly used in other logon types.

In logs generated during logon processes, when the “Authentication Package” value is Kerberos or Negotiate, workstation information belonging to the client that logged on is often not included. IP address information may only be seen in some scenarios. The IP and workstation information seen in these fields mostly represents the information of the target system where the logon occurred, and this can be misleading for the analyst.

In contrast, when the “Authentication Package” value is NTLM, both the device name and source IP address information belonging to the client making the request are generally clearly included in the log. This makes it possible, especially during the detection of brute force attacks, to quickly and accurately analyze whether the attempts are coming from a single source or from a distributed structure. In this way, the distinction between false positives and true positives can be made more easily.

Approaching Brute Force Detection from a SOC Perspective

In the detection of brute force attacks, NTLM’s ability to clearly reflect client information into logs provides an important advantage. With this advantage, the queries to be made will be more targeted.

Step 1:

EventID = 4624 OR EventID = 4625 AND AuthenticationPackage = “NTLM” AND UserName = “Jason” | STATS count() AS attempts BY SourceIpAddress, WorkstationName

This query lists NTLM-based successful or failed authentication attempts targeting a specific user account (Jason), while also listing which IP address and workstation information the attempts were made from.

Step 2:

EventID = 4625 AND (WorkstationName = “AttackerNB” OR SourceIpAddress = 192.168.1.1) | STATS TargetUserName AS unique_users, count() AS total_attempts | SORT unique_users DESC

This query is aimed at detecting whether multiple different user accounts are being tried from the same source IP or workstation. Seeing NTLM attempts against many different users within a short period of time may indicate brute force or password spraying activity.

In summary, although Kerberos is architecturally a more secure authentication protocol, the source IP and device name visibility provided by NTLM during incident response makes it easier to detect attacks such as brute force and password spraying quickly and accurately. This provides SOC teams with an important operational advantage.

Sources:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624

https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia