Kerberos or NTLM? Negotiate and the conditions that influence protocol selection

1. Core mechanism

The application selects an SSPI security suite (Kerberos, NTLM or Negotiate); This package choice is an application decision, so it would be wrong to say 'protocol choice is never an application's decision'. However, when the application chooses Negotiate, which concrete protocol to use (Kerberos or NTLM) is determined by a SPNEGO negotiation (RFC 4178 / MS-SPNG). The client side generates a NegTokenInit; This token carries a mechTypes field that lists the mechanisms the initiator offers in order of preference (typically Kerberos first, NTLM second). This list of preferences is not fixed or inexhaustible; modern Windows may offer additional mechanisms/extensions. The acceptor indicates a mechanism it supports; token exchange continues until the parties succeed or negotiation fails. Fallback to NTLM depends on the error, application, and policy; not every Kerberos failure triggers an automatic fallback. The limit of this course is the question 'Which protocol was chosen when Negotiate was chosen and why?': NTLM's message structure is in 07.01, NTLMv2 response/key material is in 07.02, signing/EPA/channel binding protections are in 07.04. The focus here is on the conditions that determine the choice and the trace it leaves in the telemetry (4624 AuthenticationPackageName) and the ways in which it is misread.

Interfaces and specifications

• RFC 4178: mechTypes is an OID list in initiator preference order. The acceptor can choose an offered, acceptable mechanism or reject the list; it need not always choose the first common entry.
• RFC 4178 §4.2.1 / §5: mechListMIC is a MIC protected by the chosen mechanism and serves to detect whether the mechTypes list has been downgraded by a middle party.
• In this fixture, SPNEGO OID 1.3.6.1.5.5.2 identifies the wrapper. The standard Kerberos V5 OID 1.2.840.113554.1.2.2 and legacy Windows truncated Kerberos V5 OID 1.2.840.48018.1.2.2 represent the same mechanism (RFC 4178 Appendix C). NTLM SSP uses 1.3.6.1.4.1.311.2.2.10. Three offered OIDs do not mean three independent protocols.
• Microsoft Negotiate SSP: an application can select the Negotiate package through SSPI; the package prefers Kerberos when it can be used and the caller supplies sufficient target identity information, such as an SPN, UPN, or NetBIOS account name. The selected package appears in Event 4624 AuthenticationPackageName.
• Microsoft 4624 (Field Descriptions): LogonType 3 (Network) is a network session; LogonProcessName 'NtLmSsp' distinguishes a session processed by NTLM SSP, while AuthenticationPackageName distinguishes the packet actually used (Kerberos / NTLM / Negotiate).
• Microsoft 4624: The LmPackageName field indicates the minor version ('NTLM V1' / 'NTLM V2' / 'LM') used in NTLM sessions; Kerberos sessions have '-'. KeyLength carries the key length (e.g. 128); It is 0 for Kerberos sessions.
• Microsoft NTLM overview / Restrict NTLM: 'Network security: Restrict NTLM' policy family can manage outgoing/incoming NTLM traffic as Allow / Audit / Deny; Deny may fail to fallback to NTLM, so fallback is not guaranteed in all environments.

The application chooses a package; Negotiate selects a mechanism

On Windows, when a client authenticates to a server with 'Negotiate' (SSPI's Negotiate package), which protocol to use is determined by SPNEGO negotiation, not individual application code. The client generates a NegTokenInit, and its mechTypes list lists the mechanisms it supports in order of preference: first Kerberos, then NTLM.

The acceptor can accept the first preference, choose another offered mechanism or reject them all. The list shows choices, not an established context or successful logon. Direct application choice of Kerberos/NTLM and negotiation through Negotiate are also different paths.

The synthetic record below shows only the NegTokenInit mechTypes list. The two Kerberos OIDs are standard and legacy identifiers for the same mechanism; NTLM is offered by the third OID. This record has no outcome, established context or mechListMIC, so it cannot provide evidence of those results.

When Kerberos can't be used: No SPN available

Suitable SPN/target identity is one Kerberos precondition, not a success guarantee. The ticket path, acceptor key context and application/policy conditions also matter. Windows does not try Kerberos for IP-literal targets by default; TryIPSPN with an appropriate IP-SPN registration can change that default. NTLM fallback still depends on application behavior and policy.

The most common conditions are: connecting to the target by IP address (there is no corresponding SPN for an IP-literal in the default path, so it does not resolve to Kerberos unless there is special IP-SPN support/configuration), the SPN of the target service is not registered at all or is registered in both accounts (duplicate), the client cannot reach the KDC when it lacks a valid cached service ticket for the target, the client or server is in the context of a workgroup/local account (no domain KDC), and the application directly NTLM packet calling.

Reaching the KDC and using an existing ticket are different operations. A client with a suitable, still-valid cached service ticket can present it directly to the target. A KDC outage blocks obtaining or renewing tickets; it does not instantly invalidate an existing ticket. A cached TGT alone is insufficient when the target service ticket is missing: obtaining it still requires the KDC. An outage can also affect the connection if the service needs DC contact, for example for PAC validation.

Not all of these conditions automatically mean 'fall to NTLM': Negotiate can fall to NTLM when conditions allow, but if one of the SPN/KDC/policy/application conditions fails in some other way (e.g. Restrict NTLM Deny, application calling Kerberos directly) an error may be returned instead of falling. The common denominator is that Kerberos failure is often not an attack but a naming/access/configuration situation, the outcome of which depends on the policy of the environment; so 'NTLM seen' is not an event in itself, but the result of a condition (if allowed).

mechListMIC: so that downgrade is not silent

The risk that comes to mind when presented with a list and choosing the best common mechanism is: could a party in the middle truncate the list and 'downgrade' the parties to a weaker mechanism (e.g. NTLM instead of Kerberos)? SPNEGO defines the mechListMIC field against this.

mechListMIC protects mechTypes through the mechanism context. RFC 4178 §5 makes its use conditional: no MIC is used when the selected mechanism lacks integrity support; exchange is optional when both parties’ most preferred mechanism is selected; other integrity-capable cases require MIC exchange after context establishment. A MIC therefore cannot be assumed in every NegTokenInit or every exchange.

The practical implication of this is that the choice of mechanism is not completely 'blind'. However, this protection targets the integrity of the negotiation; The internal protections of the selected mechanism (e.g. NTLM signing, channel binding) are a separate topic and are covered in 07.04.

Fallback is not a recovery, but the result of a condition

A common assumption is 'Without Kerberos, NTLM takes over and the connection always survives'. This is wrong on two points. First: falling to NTLM is not a solution, it is a sign that Kerberos prerequisites (SPN/KDC) are not met; The root cause is still there.

Second: fallback is not possible in every environment. If the 'Network security: Restrict NTLM' policies set outgoing or incoming NTLM to Deny, the NTLM attempt will fail and the connection may not be established at all. So the existence of NTLM is not a 'guarantee', but a possibility depending on policy and configuration.

This is also important from an attacker's perspective: while being able to downgrade to NTLM seems like a capability, mechListMIC can detect the downgrade, Restrict NTLM can block the attempt, and some applications already call a particular package directly. 'I always downgrade to NTLM' is not a rule, but a possibility depending on the environment.

How to read proof of election in 4624

The protocol with which a session was established appears in the 4624 record in the successful logon. The AuthenticationPackageName field returns the package actually used (Kerberos, NTLM, or Negotiate). LogonType 3 is a network session; LogonProcessName 'NtLmSsp' Points to a session processed by NTLM SSP.

In NTLM sessions, LmPackageName indicates the minor version ('NTLM V2' expected; 'NTLM V1'/'LM' obsolete/weak) and KeyLength key length (e.g. 128); In Kerberos sessions, LmPackageName is '-' and KeyLength is 0. So a single 4624 record tells both which protocol was selected and, if NTLM, which minor version was used.

However, reading these fields as a 'good/bad' label alone is misleading: NTLM V2 network logon is the expected result in many legitimate situations (IP-literal target, missing SPN, workgroup). To read the evidence correctly, AuthenticationPackageName and the target naming and SPN status are evaluated together — this co-reading exercise is the artifact of this lesson.

State and data flow

1. tunahan wants to connect to a shared resource (FS01) from WKS17 with 'Negotiate'; SSPI generates a SPNEGO NegTokenInit and presents Kerberos first, then NTLM in the mechTypes list.
2. Suitable target identity/SPN is a Kerberos prerequisite, assessed with the ticket, acceptor key and application/policy conditions. An offered list proves neither selection nor success.
3. The client considers whether it has a valid service ticket for the target. A suitable cached ticket can be presented even when the KDC is unreachable, subject to target validation requirements. When a new ticket is needed, a missing SPN or KDC outage can prevent issuance. Application behavior and policy determine whether NTLM fallback occurs; Restrict NTLM Deny can cause the connection to fail.
4. If NTLM is selected, SSPI executes the NTLM challenge-response flow (07.01); The successful network session is recorded in 4624 as LogonType=3, LogonProcessName='NtLmSsp', AuthenticationPackageName=NTLM, LmPackageName='NTLM V2', KeyLength=128.
5. If 'Restrict NTLM: Deny' is enabled in the environment, the NTLM attempt will fail; the connection will not be established and without Kerberos there may be no way out — fallback is not guaranteed.
6. mechListMIC protects list integrity under RFC 4178 §5 conditions. Modification can be detected where it is used and validated; do not assume a MIC in every exchange.
7. When reading 4624, the analyst does not consider AuthenticationPackageName=NTLM as an alarm by itself; comments along with whether the target is IP or FQDN, whether the relevant SPN is registered, and whether the LmPackageName is V2.

2. Exploitation

Broken trust assumption

The broken assumption is: 'NTLM always kicks in if Kerberos fails, so downgrade to NTLM is a reliable lever in my hands.' In reality, the choice of protocol depends on the SPNEGO negotiation and the conditions of the environment: fallback to NTLM may be possible when Kerberos cannot be used or the caller lacks sufficient target information; an SPN/KDC condition alone does not prove that fallback occurred; mechListMIC can detect list tampering; and 'Restrict NTLM' policies may block the attempt altogether. So 'I always downgrade to NTLM' is not a rule but a possibility depending on the environment. Likewise, on the defense side, 'I saw NTLM means there is an attack' is wrong; NTLM is the natural outcome of many legitimate conditions.

Technical prerequisites

• By default, Windows does not attempt Kerberos for an IP-literal target; enabling TryIPSPN on the client and registering the corresponding IP-based SPN changes that exception. A missing or duplicate SPN can also break ticket acquisition; NTLM fallback depends on application behavior, failure type, and policy.
• Workgroup or local-account contexts do not use domain Kerberos in the same way; a domain client unable to reach a DC may fail outright rather than fall back to NTLM, depending on the application and failure type.
• Outgoing/incoming NTLM in the environment is not blocked with 'Restrict NTLM: Deny' — if it is blocked, fallback fails.
• The application does not directly call a specific package; An application that calls Kerberos directly will not silently switch to NTLM but will return an error if the conditions are not met.

Exploitation mechanism

The flawed assumption is “if Kerberos cannot be used, NTLM always succeeds.” Target name/SPN, ticket availability, application package choice and Restrict NTLM policy jointly determine the outcome. Separate an offered list from a selected mechanism and check the conditions for mechListMIC. NTLM selection does not show that signing or channel binding is disabled. These examples explain the boundaries; they do not execute a downgrade or relay.

Downgrading to NTLM is a condition, not a capability

The phrase 'I disable Kerberos and force NTLM' is not sufficient by itself. If the application can provide Kerberos target information, Negotiate may try Kerberos; an SPN error, IP literal, or KDC reachability problem does not guarantee an automatic or uniform NTLM fallback across applications.

So 'downgrade to NTLM' is not a universal lever; depends on how the target is named and the SPN/KDC status of the environment. This means that both the attack plan and the defensive expectation cannot be established without knowing the environment.

Downgrade is not silent

Where mechListMIC is required or supplied and validated under RFC 4178 §5, it checks the offered list’s integrity. An unchanged initial token does not establish that this later check occurred.

This does not mean that downgrading is impossible; Depends on mechanism and version combinations, whether the application enforces MIC or not. But the 'I silently change the list and no one notices' assumption is unreliable when mechListMIC is in effect.

Limit: choice ≠ protection

This lesson explains the condition under which the protocol is chosen; not how resistant the chosen protocol is to relaying or eavesdropping. The session is not automatically vulnerable just because NTLM is selected: If signing/sealing and channel binding are enabled, the relay is broken (07.04).

That's why the output of this layer is not an 'exploit', but a reading frame: The question 'why was NTLM chosen' and the question 'how protected is the chosen NTLM' are separate, and the second is in the next lesson.

3. Defense & Detection

Telemetry scope

• Audit Logon (Success) — 4624: AuthenticationPackageName gives the selected package (Kerberos / NTLM / Negotiate) on successful sessions; This field is the primary evidence of protocol selection and is generated on the endpoint/server side.
• In NTLM sessions, LogonProcessName 'NtLmSsp', LmPackageName minor version (expected 'NTLM V2') and KeyLength are read together; In Kerberos sessions, LmPackageName is '-' and KeyLength is 0, which makes the distinction clear.
• NTLM authentication on the DC also appears with 4776 (The computer attempted to validate the credentials for an account); This is the record of NTLM credential validation from the server to the DC and is a different observation point than endpoint 4624.
• 'Restrict NTLM: Audit' policies and the NTLM Operational log are used to inventory where NTLM is used; these indicate which connections are dependent on NTLM before switching to 'Deny'.
• A single 4624 record does not make a 'good/bad' decision; AuthenticationPackageName should be evaluated along with the naming of the destination (IP or FQDN), whether the relevant SPN is registered, and the source/destination context.
• During a KDC outage, distinguish a valid cached service ticket for the target from a need to obtain a new ticket. 4624 records the selected package; that field alone does not establish cache state or the cause of fallback.

Events and relevant fields

• 4624 / AuthenticationPackageName: the package actually used — 'Kerberos', 'NTLM' or 'Negotiate'; direct evidence of choice.
• 4624 / LogonType: 3 (Network) network session; Protocol selection makes sense in network authentication.
• 4624 / LogonProcessName: 'NtLmSsp' points to the session that NTLM SSP processes, 'Kerberos'/'Negotiate' points to other streams.
• 4624 / LmPackageName: NTLM minor version — 'NTLM V2' (expected), 'NTLM V1' / 'LM' (legacy/thin); '-' in Kerberos sessions.
• 4624 / KeyLength: session key length (e.g. 128); 0 for Kerberos sessions. IpAddress/IpPort for NTLM sessions is often '-' because NTLM network sessions may not carry TCP/IP details.
• 4776 / (DC) Package/TargetUserName/Workstation/Status: DC's NTLM credential validation record; It is a second NTLM pointer independent of endpoint 4624.

Which area says what?

The first step in reading the protocol selection is to see the three fields together in the 4624: AuthenticationPackageName (which package), LogonProcessName (is it NtLmSsp), and LmPackageName/KeyLength (the minor version and key if it is NTLM). This trio answers the question 'Kerberos or NTLM, and if so, how old is NTLM?'

The second step is to map this record to the context: was it called with the target IP, is the corresponding SPN registered, is the source host an expected client. Taking the field out of context and saying 'NTLM = bad' turns most legitimate conditions into false positives.

Alan                         Kerberos oturumu   NTLM oturumu
---------------------------  -----------------  ------------------
AuthenticationPackageName    Kerberos           NTLM
LogonProcessName             Kerberos/Negotiate NtLmSsp
LmPackageName                -                  NTLM V2 (beklenen)
KeyLength                    0                  128 (ornek)
IpAddress/IpPort             genelde dolu       cogu zaman -

Same symptom, different condition

'NTLM appeared' does not point to a single root cause. The root cause could be an IP-literal target, missing/duplicated SPN, unreachable KDC or workgroup context; All four produce the same 4624 NTLM record. The correct question is 'Why was NTLM chosen', not 'Why is NTLM bad'?

The detection therefore treats the selection as a condition indicator: a sudden increase in the rate of NTLM, the appearance of older subversions (LM/NTLM V1) or NTLM from unexpected sources are signals worth examining; A single NTLM logon is often routine.

Detection logic · XPath

<!-- Ornek 4624 belgesi icinde NTLM ile kurulmus network logon'lari secer. -->
<!-- Tek bir Event XML belgesi uzerinde secim yapar; korelasyon/temel cizgi yoktur. -->
<!-- NTLM network logon cogu ortamda mesrudur; bu secim bir kapsam, kanit degildir. -->
//*[local-name()='Event']
  [*[local-name()='System']/*[local-name()='EventID']='4624']
  [*[local-name()='EventData']/*[local-name()='Data'][@Name='LogonType']='3']
  [*[local-name()='EventData']/*[local-name()='Data'][@Name='AuthenticationPackageName']='NTLM']

Query assumptions

• XPath only selects on a single given Event XML document; does not correlate across multiple hosts, sessions, or time windows.
• AuthenticationPackageName and LogonType are compared as text ('NTLM', '3'); If a backend stores values ​​of different types, the match must be adapted.
• This statement was evaluated only on sample document 4624 in this session; has not been run on a live system and has not been benchmarked against a baseline.

False positives

• NTLM V2 network logon is expected in many legitimate situations: access to target by IP, relevant SPN not registered, workgroup/local account, applications calling NTLM directly. This election captures these, too.
• Connecting a management tool or backup agent via IP-literal can produce routine NTLM; This is a configuration choice, not an attack.
• Access that actually selected Kerberos with a suitable SPN does not match this NTLM selector. The SPN’s presence alone does not establish the selected package.

Hardening

• Register service SPNs correctly and uniquely; under default Windows behavior, prefer FQDNs over IP literals. Inventory the TryIPSPN/IP-based-SPN exception if configured.
• Inventory and deduplicate duplicate SPNs (see 06.03); duplicate SPN breaks Kerberos and indirectly leads to shift to NTLM.
• Measure the 'Network security: Restrict NTLM' family with Audit first, see which connections depend on NTLM; then gradually switch to Deny — direct Deny can break legitimate flows.
• Disable LM and NTLMv1 with 'Network security: LAN Manager authentication level' (NTLMv2 only); They should be targeted to appear 'LM'/'NTLM V1' in the LmPackageName telemetry.
• Enforce 07.04 protections (signing, EPA/channel binding) for applications that must rely on NTLM; Even if the selection is NTLM, the relay surface should be narrowed.
• In controlled validation compare FQDN/SPN and IP-literal access and actually observe the selected package. Do not infer Kerberos or NTLM solely from target naming; record cache, TryIPSPN, application and policy conditions.

Read the examples

60 32 06 06 2b 06 01 05 05 02 a0 28 30 26 a0 24
30 22 06 09 2a 86 48 86 f7 12 01 02 02 06 09 2a
86 48 82 f7 12 01 02 02 06 0a 2b 06 01 04 01 82
37 02 02 0a

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4624</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:12.6180000Z" />
    <EventRecordID>884213</EventRecordID>
    <Correlation />
    <Execution ProcessID="784" ThreadID="9044" />
    <Channel>Security</Channel>
    <Computer>FS01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-5-21-3623811015-3361044348-30300820-1462</Data>
    <Data Name="TargetUserName">tunahan</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetLogonId">0x2a9f1c3</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">NtLmSsp </Data>
    <Data Name="AuthenticationPackageName">NTLM</Data>
    <Data Name="WorkstationName">WKS17</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">NTLM V2</Data>
    <Data Name="KeyLength">128</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">-</Data>
    <Data Name="IpPort">-</Data>
    <Data Name="ImpersonationLevel">%%1833</Data>
  </EventData>
</Event>

Two reality checks

Assumption: If Kerberos fails, NTLM always takes over and the connection is saved.

In fact: No. Fallback to NTLM may be possible when Kerberos cannot be used or the application lacks sufficient target identity information; not every Kerberos failure triggers automatic fallback. Windows' default IP-literal behavior and the TryIPSPN exception also show why target naming matters. A Restrict NTLM Deny policy can block an NTLM attempt; a verified SPNEGO mechListMIC is intended to detect tampering with the mechanism list.

Assumption: Seeing AuthenticationPackageName=NTLM at 4624 alone is evidence of relay/attack.

In fact: No. NTLM V2 network logon is the natural result of many legitimate conditions: access by IP literal under the default Windows setting (TryIPSPN plus a registered IP-based SPN is an exception), the relevant SPN is unregistered or duplicate, workgroup/local account context, and applications that call NTLM directly. So a single NTLM record is an indication of condition, not evidence of malicious intent. Significant signal appears with the context of NTLM: old minor versions (LmPackageName 'LM'/'NTLM V1'), NTLM or rate changes from unexpected sources are examined; For proof, AuthenticationPackageName is not read alone, but together with the target name and SPN status.

Sources

• IETF · RFC 4178 — The SPNEGO Negotiation Mechanism
  §4.2 NegTokenInit (mechTypes preference list); §4.2.1 / §5 mechListMIC and downgrade detection.
• Microsoft Open Specifications · [MS-SPNG] Simple and Protected GSS-API Negotiation
  Negotiate mechanism OIDs: Kerberos V5 1.2.840.113554.1.2.2, MS Kerberos 1.2.840.48018.1.2.2, NTLM SSP 1.3.6.1.4.1.311.2.2.10; mechanism list and preference order.
• Microsoft · 4624(S) An account was successfully logged on
  Field Descriptions: AuthenticationPackageName (Negotiate selection sentence), LogonProcessName (NtLmSsp), LmPackageName (NTLM V1/V2/LM), KeyLength; Logon Types (3=Network); lack of IP details in NTLM sessions.
• Microsoft · Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
  Outgoing NTLM Allow all / Audit all / Deny all; sender-side NTLM Operational log, remote-server exceptions and compatibility impact.
• Microsoft · Network security: Restrict NTLM: Incoming NTLM traffic
  Allow all / Deny all domain accounts / Deny all accounts. Incoming blocking policy; auditing is a separate policy.
• Microsoft · Network security: Restrict NTLM: Audit incoming NTLM traffic
  Disable / Enable auditing for domain accounts / Enable auditing for all accounts; receiver-side NTLM Operational log. This policy does not block traffic.
• Microsoft · 4776(S, F) The computer attempted to validate the credentials for an account
  NTLM credential validation record on the DC: Authentication Package (MICROSOFT_AUTHENTICATION_PACKAGE_V1_0), Logon Account, Source Workstation, Error Code fields.
• Microsoft · NTLM overview (authentication and mitigation context)
  NTLM's position relative to Kerberos and recommendations to reduce NTLM usage; protocol selection context.
• Microsoft Learn · Configuring Kerberos for IP Address
  Default Windows behavior does not attempt Kerberos for IP-address hostnames; TryIPSPN plus a registered IP-address SPN enables the exception.
• Microsoft Learn · Microsoft Negotiate SSP
  Negotiate selects Kerberos unless it cannot be used or the calling application lacks sufficient target identity information; supported target identifiers include SPN, UPN, or NetBIOS account name.
• Microsoft Learn · Kerberos authentication overview
  More efficient authentication to servers: reuse of service tickets and possible DC contact for PAC validation.