af Nilaa Maharjan, Security Research

Intern penetrationstest kræver ofte, at sikkerhedsspecialister forsøger at udtrække adgangskoder fra hukommelsen på inficerede maskiner. Hvis de erhvervede legitimationsoplysninger haster, kan testeren bruge pass-the-hash-metoden til at rejse lateralt inden for netværket for at nå sine mål. Denne teknik blev ofte brugt tidligere og er stadig en gyldig trusselsvektor i ikke-opdaterede maskiner.

Hvis testeren imidlertid er i stand til at udtrække cleartext-legitimationsoplysninger fra hukommelsen eller knække de indsamlede hashes, vil de kunne autentificere på tværs af yderligere netværksressourcer og tjenester som f.eks. Outlook, forretningskritiske webapplikationer og enhedsportaler, blandt mange andre.

I denne artikel gennemgår vi, hvad WDigest er, hvordan det bruges til at udtrække cleartext-legitimationsoplysninger fra hukommelsen, og hvordan en analytiker kan bruge LogPoint til at registrere, afbøde og reagere på ethvert WDigest-relateret angrebsforsøg.

Men først lidt baggrundshistorie.

Hvad er WDigest?

WDigest Authentication er en udfordrings-/svarprotokol, der primært blev brugt til LDAP og webbaseret godkendelse i Windows Server 2003. Den blev introduceret for første gang i Windows XP og blev som standard aktiveret på Windows-systemer. Det giver klienter mulighed for at kommunikere klartekstlegitimationsoplysninger til Hypertext Transfer Protocol (HTTP) og Simple Authentication Security Layer (SASL) applikationer.

Microsoft cachelagrede klartekstoplysningerne i Windows RAM, når brugerne loggede ind på deres arbejdsstationer, for at gøre godkendelsesproceduren mere bekvem for slutbrugerne. Arbejdsstationer brugte disse cachelagrede akkreditiver til at autentificere HTTP- og SASL-tjenester uden at kræve, at brugerne indtaster deres legitimationsoplysninger igen og igen. Klartekstoplysningerne godkendes via HTTP- og SASL-udvekslinger.

En klient anmoder f.eks. om adgang, godkendelsesserveren udfordrer klienten, og klienten svarer ved at kryptere svaret med en nøgle, der er afledt af adgangskoden. For at finde ud af, om brugeren har den rigtige adgangskode, sammenlignes det krypterede svar med et tidligere gemt svar på godkendelsesserveren. Det er her, problemet opstår.

Microsoft har en meget mere detaljeret forklaring på WDigest, hvordan det fungerer, og nogle af dets applikationer her.

Hvorfor er det vigtigt?

Alle bør prioritere Windows sikkerhedsrevision. At forstå, hvordan dine slutpunkter er sat op, og hvilke indgange de kan udsætte for uønskede brugere, er afgørende for at forsvare ethvert system. Her kommer WDigest ind i billedet. En ting, du skal huske på ved WDigest, er, at det gemmer adgangskoder i klartekst og i hukommelsen. Hvis en ondsindet person får adgang til et slutpunkt og er i stand til at køre et program som Mimikatz, vil vedkommende ikke kun kunne få adgang til de hashes, der i øjeblikket er gemt i hukommelsen, men også til cleartext-adgangskoderne til kontiene.

Det er ikke kun en testpraksis for baseline red team, men også en taktik, der ofte bruges af modstandere som KNOTWEED- eller PHOSPHORUS ransomwarekampagner.

Dette er og bør være et problem, fordi modstandere nu ikke kun kan anlægge et angreb som pass-the-hash, men også har brugernavnet og adgangskoden til at forsøge at logge på ting som Exchange, interne hjemmesider osv.

Et typisk angrebsscenarie

Mimikatz er blevet brugt til at stjæle legitimationsoplysninger fra hukommelsen i de seneste par år. Derfor har flere antivirusløsninger oprettet signaturer for at forhindre dette værktøj i at køre på pc’er. Der er dog flere måder at undgå disse antivirussignaturer på, herunder at køre programmet i hukommelsen eller udelade programmet.

Når angriberen har fået adgang til et internt system i en organisation, kan Mimikatz bruges til at hente legitimationsoplysninger fra hukommelsen. Disse hentede legitimationsoplysninger kan være i hashed, klartekst eller begge formater.

Hvis angriberen er så heldig at få disse legitimationsoplysninger i klartekst, er det ikke nødvendigt at knække hashes, og det vil give direkte adgang til interne ressourcer, hvilket bringer angriberne tættere på at nå deres mål.

Det er dog vigtigt at bemærke, at før kommandoen kan køres, skal angriberen have administrative rettigheder.

Her er et eksempel på, hvad en angriber ville se, når vedkommende dumper legitimationsoplysninger i hukommelsen med et værktøj som Mimikatz. Brugeren “HanSolo” brugte et remote desktop til at logge på maskinen, og fordi den specifikke konfiguration omkring WDigest er konfigureret på en usikker måde, ser de ikke kun en NTLM hash for kontoen, men også klartekst-adgangskoden “Password99!”.

Eksempel på en angribers visning, når legitimationsoplysninger dumpes i hukommelsen. Du kan finde flere oplysninger i lynvejledningen om brug af Mimikatz via adsecurity.

At forstå WDigest-registret er nyttigt for offensive og defensive analytikere.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

  • Hvis værdien UseLogonCredential er indstillet til 0, vil WDigest ikke gemme legitimationsoplysninger i hukommelsen.
  • Hvis værdien UseLogonCredential er indstillet til 1, vil WDigest gemme legitimationsoplysninger i hukommelsen.

Som det var tilfældet med DEV-0270’s PHOSPHOROUS ransomware-kampagne, brugte DEV-0270, efter trusselaktørerne havde kompromitteret enheden og fået administratorrettigheder, LOLBINs til at udføre deres legitimationstyveri, da dette fjerner behovet for at droppe almindelige legitimationstyveriværktøjer, der med større sandsynlighed vil blive opdaget og blokeret af antivirus- og slutpunktsdetektions- og reaktionsløsninger (EDR). En af disse processer starter med at aktivere WDigest i registreringsdatabasen, hvilket resulterer i adgangskoder gemt i klartekst på enheden og sparer tid, da man ikke skal knække et adgangskodehash.

Vi har bemærket, at der anvendes to variationer af denne kommando, som begge til sidst sætter registerværdien for UseLogonCredential til 1.

I systemer, hvor WDigest-registret mangler eller er fjernet.

"Set-ItemProperty -Force
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
-Name "UseLogonCredential"
-Value '1'"

I systemer, hvor WDigest-registret er indstillet til ikke at gemme klare adgangskoder.

"reg" add 
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v 
UseLogonCredential /t REG_DWORD /d 1 /f

Man bruger derefter rundll32.exe og comsvcs.dll med den indbyggede MiniDump-funktion til at dumpe adgangskoder fra LSASS til en dump-fil. Kommandoen til at opnå dette angiver ofte outputtet til at gemme adgangskoderne fra LSASS. Filnavnet er også vendt om for at undgå registreringer (sssasl.dmp):

powershell.exe" /c Remove-Item -Path C:\windows\temp\ssasl.pmd 
-Force -ErrorAction Ignore; 
rundll32.exe C:\windows\System32\comsvcs.dll, 
MiniDump (Get-Process lsass).id C:\windows\temp\ssasl.pmd full | out-host; 
Compress-Archive C:\windows\temp\ssasl.pmd C:\windows\temp\[name].zip

Identificering af brug af WDigest

Hvad angår den defensive side, bør overvågning af ændringen i registreringsstien give et tegn på, at noget ondsindet er på vej. Selv med en sysmon skal du angive en overvågningssti, før den kan begynde at logge ændringer i registreringsdatabasen.

WDigest-brug kan identificeres to steder: dine domænecontrollerlogfiler eller dine serverlogfiler (hver server skal kontrolleres).

Med Logpoint leverer vi en brugerdefineret sysmon-konfigurationsfil og Nxlog-prøve. Denne linje er især rettet mod WDigest.

\Control\SecurityProviders\WDigest

Når stien eller sysmon-filen er konfigureret i systemet, kan en ud-af-boksen-advarselsregel LP_Wdigest Registry Modification bruges til at overvåge de ændringer, der er foretaget i registreringsstien.

norm_id=WindowsSysmon event_id=13 
target_object="*WDigest\UseLogonCredential" -user IN EXCLUDED_USERS

En forudkonfigureret advarselsregel overvåger ændringerne i registreringsstien.

Hvad angår procesdump, udløses LP_Process Dump via Rundll32 og Comsvcs, når angriberen eller testeren forsøger at dumpe adgangskoderne fra LSASS til en dumpfil.

label="Process" label=Create 
"process"="*\rundll32.exe" 
command IN ["*comsvcs.dll*#24*", "*comsvcs.dll*MiniDump*" ] -user IN EXCLUDED_USERS

Alle nye opdaterede og eksisterende regler kan downloades fra Logpoint Service Desk.

BEMÆRK: Som standard i Windows 8.1 og Windows Server 2012 R2 og senere versioner er caching-legitimationsoplysninger i hukommelsen for WDigest deaktiveret (værdien UseLogonCredential er som standard 0, når registreringsdatabaseposten ikke er til stede).

Den observerede adfærdsændring, når UseLogonCredential-værdien er indstillet til 0, er, at du måske bemærker, at legitimationsoplysninger er påkrævet oftere, når du bruger WDigest.

Eftersom dette har været et længevarende problem, og da det var et meget gammelt problem, udgav Microsoft en programrettelse tilbage i 2014, som effektivt forhindrede WDigest-adgangskoder i at blive gemt i hukommelsen

Et uddrag fra Microsoft, der behandler problemet, anbefaler også, at brugerne fjerner klartekst-adgangskoder fra hukommelsen.

Fjernelse af klartekstoplysninger fra LSASS

Denne opdatering forhindrer enhver Microsoft SSP i LSASS, udover WDigest, i at lagre brugerens klartekst-password. WDigest gemmer stadig brugerens klartekst-adgangskode, fordi den ikke kan fungere uden brugerens adgangskode (Microsoft ønsker ikke at bryde eksisterende kundeopsætninger ved at sende en opdatering for at deaktivere denne). Microsoft anbefaler, at brugerne gennemser deres domænecontrollerlogfiler for WDigest-godkendelseslogin (instruktioner nedenfor). Hvis WDigest-godkendelse ikke anvendes, kan kunderne anvende FixIt, der findes på KB-artiklen, til at deaktivere WDigest. Dette vil fjerne alle klartekst-legitimationsoplysninger fra LSASS-hukommelsen.

Det er vigtigt at indse, at selvom klartekstlegitimationsoplysninger ikke længere vil blive gemt, vil NT-hash og Kerberos TGT/Session-nøglen stadig blive gemt og betragtes som legitimationsoplysninger (uden legitimationsækvivalenter gemt i hukommelsen ville enkeltlogon være umulig). Selvom klartekst-legitimationsoplysninger ikke længere gemmes i hukommelsen, kan en angriber bruge andre teknikker såsom nøgleloggere til at gendanne klartekst-adgangskoder. Det er nyttigt at eliminere klartekst-adgangskoder fra hukommelsen, og det reducerer risikoen, men det kan ikke garanteres, at det stopper angribere.

For Windows 7, 8, Server 2008 R2 og Server 2012 skal du installere ovennævnte sikkerhedsopdatering, og derefter skal du indstille følgende registreringsdatabasenøgle til 0.

Indstilling af registernøglen til 0 hjælper med at reducere risikoen fra WDigest.

Sti: HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential

Den nemmeste måde at gøre det på er ved hjælp via en gruppepolitik, men en hurtig script fungerer også:

reg add
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential /t REG_DWORD /d 0

Når du har skubbet sikkerhedsopdateringen og registreringsdatabasens nøgleopdatering til alle dine servere, kan du sikre dig, at du har gjort det korrekt ved at forespørge registreringsdatabasen for at se, at den eksisterer og ikke er indstillet til 1.

reg query
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential

BEMÆRK: Begge ovenstående ændringer vil også udløse alarmen, når der foretages en ændring af den angivne sti.

Som standard kræver nyere versioner af Windows (8.1+ og 2012 R2+) ikke sikkerhedsopdatering eller indstilling af værdien til 0, da standarden er 0, når den ikke er til stede. Du skal dog sikre dig, at der ikke er foretaget manuelle ændringer, der sætter den tilbage til 1.

Brug skemaet som en hjælp til at afgøre, om du har brug for at handle på dine slutpunkter.

Afhjælpning med Logpoint SOAR playbooks

Når analytikerne opdager spor af udnyttelse, skal de isolere værten, hvor angrebet finder sted, via en playbook og indlede en playbook for hændelsesrespons.

Det er nemt og problemfrit at detektere udnyttelse, fordi Logpoint er en samlet SIEM+SOAR-løsning, der bruger en alarm (SIEM-hændelse) til automatisk at udløse en SOAR-playbook. Du kan indstille en playbook til at køre, når der er foretaget en ændring af WDigest-registerstien. Playbook’en fjerner brugeren fra Active Directory og ændrer brugeradgangskoden ved hjælp af en tilfældig adgangskodegenerator.

.

Playbook’en udløses, når der er foretaget en ændring af WDigest-registerstien, og igangsætter automatisk et sæt handlinger for at undersøge og reagere på ændringen.

Playbook’en igangsætter et svar, der deaktiverer brugeren og nulstiller adgangskoden.

På baggrund af organisationens politik og hændelsesresponsteamets procedurer vil en playbook for undersøgelser indsamle så mange data som muligt og generere en rapport.

Du kan også generere rapporter fra playbook’en for at dokumentere trinnene i undersøgelsen.

Konklusion

En konfiguration, der er relateret til WDigest, kan forhindre sikkerheden i dit miljø, især på slutpunktet, ved at lade en angriber stjæle klartekst-legitimationsoplysninger fra hukommelsen. Der er foranstaltninger, du kan træffe for at afhjælpe dette og sikre, at dine slutpunkter og legitimationsoplysninger er mere sikre. Microsofts sikkerhedsopdatering (KB2871997) tager hånd om problemet med ældre versioner af Windows, hvorimod nyere versioner bør sikres som standard. Kontrol af registreringsdatabasen for alle dine Windows-slutpunkter for WDigest-indstillingen bør være en prioritet, da tab af legitimationsoplysninger kan føre til tab af følsomme oplysninger. En måde at gøre dette på er gennem kommandolinje-forespørgsler mod alle dine værter, men en hurtigere måde er at automatisere denne type revision i forhold til dit slutpunkt og få data præsenteret for dig i en brugervenlig rapport.

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint:

Contact Logpoint