Skip to main content

SPNEGO & GSSAPI

Status: Final

SPNEGO and GSSAPI sit between applications and authentication protocols. They are invisible to most practitioners but critical for understanding why Windows sometimes uses Kerberos and sometimes falls back to NTLM — and how attackers exploit that fallback.


GSSAPI — Generic Security Services API

GSSAPI (RFC 2743) is an abstraction layer that allows applications to call security operations (authenticate, sign, encrypt) without knowing which underlying mechanism is being used. Applications call GSSAPI; GSSAPI dispatches to a mechanism plugin.

Application


GSSAPI (RFC 2743)
├── Kerberos 5 mechanism (RFC 1964)
├── NTLM mechanism (NTLMSSP)
├── SPNEGO meta-mechanism (RFC 4178)
└── Other (PKINIT, etc.)

On Windows, the GSSAPI implementation is SSPI (Security Support Provider Interface). The Kerberos SSP is kerberos.dll; NTLM is msv1_0.dll. Applications call SSPI; Windows routes to the right provider.


SPNEGO — Simple and Protected GSSAPI Negotiation

SPNEGO (RFC 4178) is a meta-mechanism that lets client and server negotiate which underlying auth mechanism to use. It wraps the negotiation in ASN.1/DER tokens exchanged at the start of a connection.

Negotiation Flow

Client Server
│── NegTokenInit (proposed mechs) ────>│
│ [Kerberos, NTLM, ...] │
│<─ NegTokenResp (selected mech) ──────│
│ [Kerberos accepted] │
│── NegTokenInit2 (Kerberos AP-REQ) ──>│
│<─ NegTokenResp (success / AP-REP) ───│

The client proposes mechanisms in preference order. The server picks the first one it supports from the list.

Mechlist

On Windows, the default SPNEGO mechlist is:

  1. MS-KRB5 (Microsoft Kerberos extension)
  2. KRB5 (standard Kerberos)
  3. NTLMSSP (NTLM)

Kerberos is always preferred. NTLM is the fallback.


When Does Kerberos Fail → NTLM Fallback?

This fallback is the critical security boundary. Kerberos fails (and NTLM activates) when:

ConditionReasonAttack Relevance
Target specified by IP addressKerberos requires a hostname to look up the SPNForce NTLM by connecting to IP instead of hostname
Target hostname not in DNSCannot resolve SPNNTLM relay opportunity
Target not domain-joinedNo Kerberos SPN registeredNTLM by design
Clock skew > 5 minutesKerberos timestamp validation fails (replay protection)NTP manipulation → NTLM downgrade
KDC unreachableNetwork partition, DC downNTLM fallback during outage
Local account loginNo Kerberos principal in ADNTLM always

Attacker implication: Forcing NTLM is trivially easy — just connect by IP. That is why SMB relay tools like ntlmrelayx specify targets by IP.


Integrated Windows Authentication (IWA)

IWA is the browser/HTTP implementation of SPNEGO. When a web server returns:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

The browser responds with a SPNEGO token (Kerberos if possible, NTLM if not).

IWA Attack Surface

ScenarioAttack
Internal IWA endpointNTLM relay if IP-targeted or Kerberos fails
ADCS Web Enrollment (/certsrv/)ESC8 — NTLM relay → certificate request
Exchange OWA / EWSNTLM relay → mailbox access
SharePoint / IISNTLM capture via Responder or relay

SPNEGO Token Analysis

SPNEGO tokens appear in Wireshark / network captures as GSS-API blobs. Key fields to parse during incident response:

FieldWhat It Tells You
mechTypeWhich protocol was used (KRB5 vs NTLMSSP)
negResultaccept-completed / reject / request-mic
Inner KRB5 AP-REQCan extract the service ticket (Kerberos)
Inner NTLMSSP AUTHENTICATEContains the Net-NTLMv2 hash

Tools: Wireshark (Kerberos + NTLM dissectors), impacket for offline SPNEGO analysis.


GSSAPI on Linux / Unix

Linux MIT Kerberos implements GSSAPI (/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so). Applications (SSH with GSSAPI, Apache with mod_auth_gssapi, curl) use it transparently.

GSSAPI auth in SSH (GSSAPIAuthentication yes) allows a Kerberos-authenticated user to ssh to a remote server with their TGT — no password required, no password in transit.

Attack: steal a TGT (ccache theft) → use KRB5CCNAME to point to it → GSSAPI SSH auth as that user.


Detection Signals

SignalWhat It Indicates
4776 on DC (NTLM) after normal Kerberos baselinePossible downgrade / IP-based connection
Large volume of NTLM auth to a server that normally uses KerberosRelay attempt in progress
SPNEGO negotiation selecting NTLM on a domain-joined host to a domain targetAnomalous — investigate IP vs hostname
Wireshark: NTLMSSP in SPNEGO where KRB5 expectedForced downgrade

TopicLink
Kerberoskerberos
NTLMntlm
Pass-the-Hashpass-the-hash
Linux Kerberoslinux-kerberos