mdit.no

AD Herding: NTLM Del 1 – Bakgrunn og Teori

Written by

[email protected]

in

,

Dette blir det første innlegget om NTLM hardening – og handler om historikken og teorien bak hvorfor vi ønsker å se på hardening.

Bakgrunn

Lan Manager

På slutten av 1980-tallet begynte lokale nettverk (LAN) å bli vanlige i bedriftsmiljøer, og det oppsto behov for en felles mekanisme for innlogging og ressursdeling mellom maskiner.

LAN Manager (LM) ble utviklet for å tilby en felles standard for autentisering og tilgangsstyring i slike nettverk, spesielt mellom OS/2- og Windows/MS-DOS systemer.

Protokollen var tilpasset datidens maskinvare og nettverkshastigheter, og prioriterte enkel implementasjon fremfor sterk kryptografi – noe som i ettertid gjorde den svært sårbar:

  • Alle passord konverteres til store bokstaver
  • Alle passord var 14 tegn lange. Lengre passord ble kuttet, og kortere passord ble polstret med nuller.
  • Passordet ble delt i to blokker på 7 tegn hver, som kunne knekkes separat.
  • Ingen salting. Når et passord først ble knekt ett sted kunne man dele passord og tilsvarende LM-hash, og man visste at dersom man så den hashen i et annet miljø, hadde man også passordet.
  • Passordblokkene ble brukt til å generere nøkler for å DES-kryptere den samme verdien i alle miljøer: KGS!@#$%

Dette gjør at alle mulige LM-hashede passord uansett lengde i dag knekkes på under et sekund.

Likevel ser vi at LM-hashede passord fortsatt finnes i produksjonsmiljøer i 2025, og at LM-protokollen svært ofte er støttet som autentiseringsmetode.

New Technology Lan Manager

I 1993 lanserte Microsoft Windows NT 3.1, og med dette kom også erstatningen for den gamle LM-protokollen. Arvtageren ble kalt New Technology Lan Manager, eller NTLM. Den implementerte en rekke forbedringer over den gamle LM protokollen.

  • Man sluttet å konvertere passordet til store bokstaver, og man fikk etter hvert større støtte for tegnsett.
  • Passordene ble behandlet som en hel streng, ikke delt opp, og den fikk beholde sin lengde.
  • Man gikk bort fra den gamle 56-bit DES krypteringen i genereringen av passordhashing, og gikk over til å generere en MD4 hash av hele passordet, som resulterte i en såkalt “NT-Hash”.
  • Man etablerte en challenge-response modell som kan bidra til å hindre replay-angrep der man kunne fange opp autentiseringen og spille den av på nytt for å få tilgang. Denne challenge-response utvekslingen benyttet fortsatt DES til en viss grad.
  • Det ble innført støtte for en sesjonsnøkkel for å få signering og/eller kryptering av dataene i sesjonen.

Etter hvert ble svakhetene i NTLMv1 tydelige. Protokollen brukte fortsatt DES-baserte operasjoner, og challenge-response mekanismen var fortsatt sårbar for f.eks “pass-the-hash” angrep.

New Technology LAN Manager v2

I 1996 introduserte Microsoft derfor NTLMv2, som beholdt samme grunnleggende modell, men forbedret den kryptografiske styrken betydelig.

  • NTLMv2 beholdt støtte for eldre systemer, men dette førte også til at mange miljøer fortsatte å være sårbare dersom fallback var aktivert. Dette er fortsatt sant, og et ustrakt problem i 2025.
  • I stedet for å bare bruke serverens 8-bytes challenge, inkluderte NTLMv2 en klient-generert nonce, et tidsstempel og annen kontekstavhengig informasjon i beregningen. Dette gjorde replay-angrep mye vanskeligere, siden hver autentisering ble unik.
  • NTLMv2 bruker ikke lenger DES-protokollen i det hele tatt.
  • Sesjonsnøklene ble generert med protokollen HMAC-MD5, noe som gav økt beskyttelse for “signing” og “sealing” av trafikk i SMB og RPC.

Dog er NTLMv2 heller ikke uten sine svakheter.

  • Bakoverkompatibilitet med LM og NTLMv1 er ofte aktivert, og signing/sealing er som regel støttet, men ikke påkrevd. Resultatet er at mange domener i praksis kan forhandles ned til svakere moduser.
  • NTLMv2 bygger fortsatt på den opprinnelige NT-hashen (MD4), som fungerer som nøkkelmateriale i all videre beregning. Det betyr at dersom en angriper får tilgang til NT-hashen, kan de autentisere seg direkte uten å kjenne passordet – det klassiske “pass-the-hash”-angrepet.
  • Klienten beviser sin identitet overfor serveren, men serveren beviser ikke nødvendigvis sin identitet tilbake. Dette gjør man-in-the-middle-angrep (NTLM relay) mulig.
  • Selv om sesjonsnøkler finnes, er de ikke kryptografisk bundet til spesifikke forbindelser. Dette gjør at NTLM-relay fortsatt fungerer mellom tjenester som SMB, LDAP, HTTP og RPC, så lenge signering ikke er aktivert eller påkrevd.
  • En angriper som fanger opp en NTLMv2 challenge–response-utveksling kan fortsatt utføre offline cracking mot passordet. Protokollen bruker ingen salt utover utfordringen, og passordstyrken blir derfor avgjørende. Fordi salting ikke benyttes er identiske passord hashet identisk i alle miljøer.

Autentiseringsflyt

Autentiseringsprosessen i NTLM protokollen er som følger:

NTLM Autentiseringsprosessen fanget opp med Wireshark.

NTLMSSP_NEGOTIATE

NTLMSSP_NEGOTIATE skjer når en klient ønsker å autentisere seg mot en tjeneste på en tjener. I dette tilfellet over SMBv2.

En TCP pakke (SMBv2) sendes til tjenerens port 445 og spør om å etablere en sesjon. Den henvender seg til “Generic Security Service” APIet og ønsker å forhandle detaljer om autentiseringen.
Vi ser forhandlingsdetaljene spør om å bruke Extended Session Security, signering, etc.

NTLMSSP_CHALLENGE

Tjeneren utfører sin side av forhandlingen, og sender en utfordring tilbake til klienten, for å bevise sin identitet.

Vi ser server sender et svar tilbake til klienten.

Vi ser dette er en NTLMSSP_CHALLENGE, og vi ser enighet om NTLM versjon, samt en server challenge som klienten må svare på.

I detaljene ser vi klart og tydelig at dette er en “NTLMSSP_Challenge” melding som en del av en “Simple Protected Negotiation”. Vi ser endringer i flaggene Negotiate version, Target Type Domain, og vi ser at det følger med en NTLM Server Challenge som i dette tilfellet er 48415c4e32bae70d.

NTLMSSP_AUTH

Til slutt svarer klienten på challenge, vi ser signering er på, men ikke påkrevd. Dette betyr at vi kunne nedgradert sikkerheten noe. Vi ser også at SMB kryptering ikke er påslått, så trafikken over denne kanalen sendes i klartekst og eventuelle filoverføringer el.l. vil potensielt kunne fanges opp, og filer dumpes rett ut av en trafikklogg.
Vi ser dette er en NTLMSSP_AUTH melding, og den inneholder en NTLMv2 response, med tidsstempel, client challenge, etc. Denne informasjonen sammen med kontoens passordhash og server challenge hashes og sendes som svar tilbake til server for å etablere en autentisert sesjon.

More posts