Blueteaming – mdit.no

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.