av Nilaa Maharjan, Security Research

Vid intern penetrationstestning brukar säkerhetsspecialister försöka extrahera lösenord från minnet på infekterade maskiner. Om de inhämtade inloggningsuppgifterna är hashade kan testaren använda ”pass-the-hash”-metoden för att förflytta sig lateralt inom nätverket för att uppnå sina mål. Denna teknik användes ofta tidigare och är fortfarande en giltig hotvektor på maskiner som inte är uppdaterade.

Förutsatt att testaren kan extrahera inloggningsuppgifter i klartext från minnet eller knäcka de insamlade hasharna, kommer testar att kunna autentisera sig för åtkomst till ytterligare nätverksresurser och tjänster som bland annat Outlook, affärskritiska webbapplikationer och enhetsportaler.

I denna artikel beskriver vi vad WDigest är, hur det används för att extrahera inloggningsuppgifter i klartext från minnet och analytiker kan använda Logpoint för att identifiera, begränsa och åtgärda WDigest-relaterade intrångsförsök.

Men först lite bakgrund.

Vad är WDigest?

WDigest Authentication är ett inloggnings-/responsprotokoll som primärt används för LDAP– och webbaserad autentisering på Windows Server 2003. Det introducerades för första gången i Windows XP och är aktiverat som standard på Windows-system. Det låter klienter skicka inloggningsuppgifter i klarttext till applikationer som använder HTTP (Hypertext Transfer Protocol) och SASL (Simple Authentication Security Layer).

Microsoft cachelagrar inloggningsuppgifter i klartext i Windows arbetsminne när en användare loggar in på en arbetsstation för att göra inloggningsprocessen smidigare. Arbetsstationer använder dessa cachelagrade inloggningsuppgifter för att autentisera HTTP- och SASL-tjänster utan att användarna behöver ange sina inloggningsuppgifter om och om igen. Inloggningsuppgifterna i klartext autentiseras via HTTP- och SASL-kommunikation.

Om t.ex. en klient begär åtkomst, skickar den autentiserande servern en inloggningsuppmaning till klienten och klienten svarar genom att kryptera sitt svar med en nyckel som härleds från lösenordet. För att säkerställa att användaren använder rätt lösenord jämförs det krypterade svaret med ett tidigare lagrat svar på den autentiserande servern. Det är häri problemet ligger.

Microsoft har en mycket mer detaljerad förklaring av WDigest, hur det fungerar och några av dess tillämpningar här.

Varför är det viktigt?

Alla bör prioritera säkerhetsgranskning av Windows. Att förstå hur dina slutpunkter är konfigurerade och vilka ingångar till systemen de kan exponera för oönskade användare är avgörande för att kunna skydda alla system. Det är här WDigest kommer in. En sak att tänka på med WDigest är att det lagrar lösenord i klartext och i minnet. Om en illasinnad aktör får tillgång till en slutpunkt och kan köra ett program som Mimikatz, kommer de inte bara att kunna få tillgång till de hashar som för närvarande finns lagrade i minnet, utan även lösenord till konton i klartext.

Det är inte bara en grundläggande testrutin för säkerhetsansvariga utan också en taktik som ofta används av angripare som driver ransomware-kampanjer med KNOTWEED eller PHOSPHORUS.

Detta är och ska betraktas som en riskfaktor eftersom angripare nu inte bara kan använda attacker som ”pass-the-hash”, utan de har även tillgång till användarnamn och lösenord för att kunna logga in på tjänster som Exchange, interna webbplatser osv.

Ett typiskt attackscenario

Mimikatz har använts av cyberbrottslingar för att stjäla inloggningsuppgifter under de senaste åren. Som ett resultat av detta har många antiviruslösningar skapat signaturer för att förhindra att detta hjälpprogram exekveras på datorer. Det finns dock flera sätt att undvika dessa antivirussignaturer, bland annat genom att köra programmet i minnet eller maskera det.

När angriparen har fått tillgång till ett internt system inom en organisation kan Mimikatz användas för att hämta inloggningsuppgifter från minnet. Dessa hämtade inloggningsuppgifter kan vara i hashade format, klartext eller båda formaten.

Om angriparen har turen att få tillgång till dessa inloggningsuppgifter i klartext är det inte nödvändigt att knäcka hashen, vilket möjliggör direktåtkomst till interna resurser och tar angriparen ett steg närmare målet.

Det är dock viktigt att observera att angriparen måste ha administrativa behörigheter innan kommandot kan köras.

Här är ett exempel på vad en angripare kan se när de inloggningsuppgifter från minnet dumpas med ett verktyg som Mimikatz. Användaren ”HanSolo” har använt Remote Desktop för att logga in på maskinen och eftersom den specifika konfigurationen för WDigest var konfigurerad på ett osäkert sätt, såg användaren inte bara en NTLM-hash för kontot, utan även lösenordet ”Password99!”.

Exempel på en angripares vy vid dumpning av inloggningsuppgifter från minnet. Mer information finns i snabbguiden för Mimikatz från adsecurity.

Att förstå WDigest-registret är till hjälp för offensiva och defensiva analytiker.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

  • Om värdet UseLogonCredential är inställt på  0 kommer WDigest inte att lagra inloggningsuppgifter i minnet.
  • Om värdet UseLogonCredential är inställt på  1 kommer WDigest att lagra inloggningsuppgifter i minnet.

Liksom DEV-0270:s ransomware-kampanj PHOSPHOROUS kunde hotaktörerna efter att ha gjort intrång i enheten och fått administrativa behörigheter, använde DEV-0270 LOLBINs för att genomföra den initiala stölden av inloggningsuppgifter eftersom detta eliminerar behovet av att ladda upp vanliga verktyg för identitetsstöld som mer sannolikt kan upptäckas och blockeras av antivirus- och EDR-lösningar (Endpoint Detection and Response). En av dessa processer börjar med att aktivera WDigest i registret, vilket gör att lösenord lagras i klartext på enheten och sparar tid för aktören tack vare att ingen lösenordshash behöver knäckas.

Vi har observerat att två varianter av detta kommando används, som båda så småningom ändrar registervärdet UseLogonCredential till 1.

På system där WDigest-registret saknas eller har tagits bort:

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

På system där WDigest-registret är inställt för att inte lagra lösenord i klartext:

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

Aktören använde sedan rundll32.exe och comsvcs.dll med dess inbyggda MiniDump-funktion för att skicka lösenord från LSASS till en dumpfil. Kommandot för att utföra detta specificerar ofta utdata-filen för att spara lösenord från LSASS. Filnamnet genereras även bakvänt för att undkomma upptäckt (ssasl.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

Identifiera användning av WDigest

När det gäller den defensiva sidan bör en ändring av registersökvägen vara en tydlig signal på misstänkta aktiviteter. Även med sysmon måste du ange en sökväg för att börja logga ändringar som görs i registret.

Användning av WDigest kan identifieras på två ställen: dina domänkontrollantloggar eller dina serverloggar (varje server måste kontrolleras).

Logpoint tillhandahåller en skräddarsydd konfigurationsfil för sysmon och exempel på Nxlog. Den här raden är särskilt inriktad på WDigest.

\Control\SecurityProviders\WDigest

När sökvägen eller sysmon-filen har konfigurerats i systemet kan den färdigpaketerade larmregeln LP_Wdigest Registry Modification användas för att övervaka ändringar som görs till registersökvägen.

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

En förkonfigurerad larmregel övervakar ändringar i registrets sökväg.

När det gäller processdumpning kommer LP_Process Dump via Rundll32 och Comsvcs att utlösas när angriparen eller testaren försöker dumpa lösenord från LSASS till en dumpfil.

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

Alla nya och befintliga regler kan laddas ner från Logpoint Service Desk.

Obs! Som standard i Windows 8.1 och Windows ServeR2012 R2 och senare versioner är cachelagring av inloggningsuppgifter i minnet för WDigest inaktiverat (värdet UseLogonCredential är som standard 0 om registerposten saknas).

Den observerade beteendeförändringen när värdet UseLogonCredential är inställt på 0 är att du kanske märker att inloggningsuppgifter krävs oftare när du använder WDigest.

Eftersom detta har varit ett långvarigt problem släppte Microsoft en patch 2014 som effektivt inaktiverade möjligheten att lagra WDigest-lösenord i minnet.

Ett utdrag från Microsoft angående problemet rekommenderar att användare eliminerar lösenord i klartext från minnet.

Borttagning av inloggningsuppgifter i klartext från LSASS

Denna uppdatering hindrar alla Microsoft SSP i LSASS – med undantag för WDigest – från att lagra användarens lösenord. WDigest lagrar fortfarande användarens lösenord i klartext eftersom det inte kan fungera utan användarens lösenord (Microsoft vill inte påverka befintliga inställningar hos kunder med en uppdatering som inaktiverar detta). Microsoft rekommenderar att användare granskar sina domänkontrollantloggar för WDigest-autentiseringsinloggningar (instruktioner finns nedan). Om WDigest-autentisering inte används kan kunder tillämpa FixIt som finns i KB-artikeln för att inaktivera WDigest. Detta eliminerar alla inloggningsuppgifter i klartext från LSASS-minnet.

Det är viktigt att vara medveten om att även om inloggningsuppgifter inte längre kommer att lagras i klartext, kommer NT hash- och Kerberos TGT/sessionsnyckeln att lagras och betraktas som autentiseringsuppgifter (utan motsvarigheter till inloggningsuppgifter lagrade i minnet är universalinloggning omöjligt (Single Sign On, SSO). Dessutom kan en angripare använda andra tekniker som t.ex. en tangentbordslogger för att återställa lösenord i klartext, även om inloggningsuppgifter inte längre lagras i klartext i minnet. Att ta bort lösenord i klartext från minnet är användbart och minskar risken, men är ingen garanti för att stoppa angripare.

For Windows 7, 8, Server 2008 R2 och Server 2012 måste du installera den tidigare nämnda säkerhetsuppdateringen och sedan ställa in följande registernyckel på 0.

Att ställa in registernyckeln på 0 hjälper till att minska riskerna i samband med WDigest.

Sökväg: HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential

Det enklaste sättet att göra detta är genom gruppolicy, men ett snabbt skript fungerar också:

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

När du har skickat säkerhetsuppdateringen och uppdateringen av registernyckeln till alla dina servrar bör du säkerställa att det har gjorts korrekt genom att fråga registret för att se om den existerar och inte är inställd på 1.

reg query
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential

Obs! Båda ovanstående ändringar utlöser även ett larm när en ändring görs i den angivna sökvägen.

Som standard kräver inte senare versioner av Windows (8.1+ och 2012 R2+) säkerhetsuppdateringen eller inställning av värdet 0, eftersom standardvärdet är 0 när sökvägen saknas. Du bör dock se till att det inte har gjorts några manuella ändringar som återställer inställningen till 1.

Använd tabellen för att avgöra om du behöver vidta några åtgärder på dina slutpunkter.

Reparation med hjälp av Logpoint SOAR playbooks

Vid detektering av spår från intrång bör analytiker isolera värden där attacken skett via en playbook och aktivera en playbook för incidenthantering.

Identifiering av intrång är enkelt och smidigt eftersom Logpoint är en enhetlig SIEM+SOAR-lösning som använder larm (SIEM-händelse) för att automatiskt starta en SOAR-playbook. Du kan ange att en playbook ska köras när en ändring har gjorts i registersökvägen för WDigest. Denna playbook tar bort användaren från Active Directory och ändrar användarens lösenord med hjälp av en slumpmässig lösenordsgenerator.

Playbooken aktiveras när en ändring har gjorts i registersökvägen för WDigest och initierar automatiskt ett antal åtgärder för att undersöka och svara på ändringen.

Playbooken initierar en respons som inaktiverar användaren och återställer lösenordet.

Baserat på organisationens policy och incidenthanteringsteamets rutiner kommer en playbook för undersökningar att samla in så mycket data som möjligt och generera en rapport.

Du kan också generera rapporter från playbooken för att dokumentera undersökningsstegen.

Sammanfattning

En konfiguration som är knuten till WDigest kan äventyra säkerheten i din miljö – särskilt på slutpunkter – genom att låta en angripare stjäla inloggningsuppgifter i klartext från minnet. Det finns åtgärder som du kan vidta för att åtgärda detta och säkerställa att dina slutpunkter och inloggningsuppgifter skyddas bättre. Microsofts säkerhetsuppdatering (KB2871997) åtgärdar problemet på äldre versioner av Windows. Nyare versioner bör däremot redan vara säkrade som standard. Att kontrollera registret för WDigest-inställningen på alla dina Windows-slutpunkter bör prioriteras, eftersom stöld av inloggningsuppgifter kan leda till förlust av känslig information. Ett sätt att göra detta är genom kommandoradskommandon på alla värddatorer, men ett snabbare sätt är att automatisera denna typ av granskning på slutpunkterna och få data presenterade i en överskådlig rapport.

Contact Logpoint

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

Contact Logpoint