Denne innstillingen i en GPO vil sette krav om signering av SMB for servere, og anbefales å slås på først.Denne innstillingen i en GPO vil sette krav om signering av SMB for klienter, og anbefales å settes på i andre rekke.
Dersom dette knekker en tjeneste kan man eventuelt lage unntak for gitte maskiner, dersom det er helt kritiske tjenester, men bør unngås dersom det er mulig.
NB! Dette bryter gjestekonto-tilgang til fileshares.
Resulterende policyinnstillinger vil se slik ut, dersom man lager en egen SMB policy, slik jeg har gjort i mitt labmiljø.
Konfigurerte innstillinger for SMB i gruppepolicy.
Verifikasjon
Man kan verifisere riktige innstillinger med f.eks powershell
Get-SMBServerConfiguration
Vi ser EnableSMB1Protocol er False, EnableSMB2Protocol er True, og RequireSecuritySignature er True.
I neste innlegg skal jeg vise hvordan man tar i bruk kryptering i forbindelse med SMB fileshares, noe mange forveksler med signering.
Denne artikkelen er første i en serie om herding av SMB-protokollen. Vi sammenligner versjoner og ser på noen av de viktige nyansene og problemstillingene når det kommer til sikkerhet.
SMB-Versjoner
Støtte for signering
Støtte for kryptering
SMB v1.0
Nei
Nei
SMB v2.X
Ja
Nei
SMB v3.X
Ja
Ja
SMBv1 og EternalBlue
I tillegg til at SMBv1 ikke støtter signering eller kryptering er den også svakt designet på flere måter.
Bl.a. kan man opprette en sesjon uten å være autentisert på forhånd. Trusselaktører kan dermed nå SMB-behandlingslogikken direkte over nettverket, og oppnå remote code execution.
Denne svakheten blir kalt MS17-00 også kjent som EternalBlue, og er en av flere exploits i et arsenal av amerikanske cybervåpen, utviklet av en Tailored Access Operations enheten som hører til under National Security Agency (NSA), også kalt The Equation Group.
Denne exploiten ble stjålet av en gruppe som blir kalt The Shadow Brokers, og ble lekket i tidsrommet August 2016 til April 2017, og selv om Microsoft patchet sikkerhetshullet i Mars 2017 ble WannaCry ormen brukt til å infisere store deler av nettet via EternalBlue sårbarheten som mange ikke hadde beskyttet seg mot via patching. Senere i 2017 ble NotPetya sluppet løs, basert på samme sårbarheten.
Fordi SMBv1 er ekstremt sårbar, som ikke er så rart med tanke på at den ble utviklet på sent 80-tall, er det viktig å slå den av i miljøet sitt. Active Directory er skapt for å være kompatibelt langt bakover, og selv nyere installasjoner av Windows Server og Active Directory kan være satt opp til å tillate SMBv1 trafikk.
Dette må eksplisitt nektes i miljøet for å være sikker på at ikke det kan utnyttes.
Kreve Signering
Fra og med SMBv2 og ut ble det mulig å kreve signering av SMB-trafikk. Signeringen gjør det svært vanskelig å utføre relay-angrep dersom både server og klient krever signering.
Her er det viktig å presisere at signering ikke nødvendigvis er påkrevd rett ut av boksen, og må eksplisitt defineres som et krav for å sikre at det håndheves.
Fordi Microsoft har ført en strategi som prioriterer tilgjengelighet over sikkerhet er standardinnstillingene å foretrekke signering, men likevel tillate usignert SMB trafikk dersom motparten ikke støtter det.
Dermed kan en trusselaktør nedgradere sikkerheten ved å si fra sin side at den ikke støtter signering, slik at forhandlingen resulterer i at signering ikke blir brukt.
Slår man på krav om signering vil ikke klient og server kunne bli enige om hvordan de skal kommunisere, med resultat i at sesjonen ikke blir etablert.
Kreve Kryptering
Fra og med versjon 3.0 ble SMB utstyrt med innebygde mekanismer for å kryptere SMB-trafikk. I tidligere versjoner ble trafikken sendt i klartekst, slik at dersom man skulle kryptere trafikken måtte dette gjøres med andre protokoller som innkapslet trafikken, f.eks over IPSec el.l.
Dette er et separat konsept fra signering, og ukryptert trafikk betyr at hele filer – og dermed innholdet i disse filene – kan hentes ut av nettverkstrafikken.
Verktøy som wireshark, tcpdump eller networkminer kan overvåke nettverkstrafikk, og filer kan dras rett ut av pakkestrømmen. Her kan det ligge sensitive filer fra et fileshare ikke alle skal ha tilgang til, eller konfigurasjonsfiler som sendes fra klient til server, og andre ting som ikke må komme på avveie.
Anbefaling
Jeg anbefaler at man skrur av støtte for SMBv1 øyeblikkelig, og at man migrerer over til SMBv2.0 og slår på tvungen signering på kleint og server som et absolutt minstekrav – og aller helst SMB 3.0+ med både tvungen kryptering og signering for å fikse disse sårbarhetene.
Praktiske steg for å gjennomføre dette i Active Directory skal vi se nærmere på i del 2.
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.
