Crack DPAPI met CQure CQTools

In de vorige post hebben we ingezoomd op DPAPI. Welke service biedt DPAPI aan Windows, hoe werkt DPAPI en waarom is het kraken van DPAPI potentieel zo waardevol. In deze post gaan we de proef op de som nemen en gaan we de DPAPI veiligheid testen met de CQTools toolkit van CQure. CQure biedt diverse tools om dit mogelijk te maken. Laten we van start gaan.

In vogelvlucht gaan we de volgende hack uitvoeren.

• 1. Log in als gewone user en maak gebruik van DPAPI (b.v. door gegevens op te slaan in Google Chrome)
• 2. Zoek de domain public key op
• 3. Exporteer de domain private key
• 4. Het wachtwoord van de gebruiker veranderen
• 5. Inloggen als die gebruiker
• 6. Zien dat we niet bij de credentials kunnen
• 7. De juiste master key container vinden van Chrome
• 8. “exported.pfx” gebruiken om deze master key container opnieuw te overschrijven met mijn huidige user password
• 9. De Chrome wachtwoorden uitlezen.

Om te laten zien dat we iets met DPAPI kunnen is het zaak om eerst data te laten versleutelen door DPAPI. Gelukkig maken veel applicaties gebruik van DPAPI, zo ook Google Chrome. Dus laten we gaan inloggen op LinkedIn. Nadat we ingelogd zijn kiezen we ervoor om het wachtwoord op te slaan in de Chrome browser. Chrome gebruikt nu DPAPI om de hash te genereren. Als het wachtwoord is opgeslagen kunnen we met Chromepass het wachtwoord zien:

Ok. Het wachtwoord is dus “BlaBlaPapa2019@@”. Nice. Laten we eens een kijkje nemen in de “%appdata%/Microsoft/Protect” folder, de plaats waar DPAPI zijn DPAPI sleutel bewaard. In eerste instantie lijkt de folder leeg. Om de content te kunnen zien moet je de “Hide protected operating system files” optie uitvinken:

De folder ziet er dan als volgt uit:

In deze folder bevinden zich 1 of meerdere folders met een SSID. Wanneer je de folder opent van jou user SSID bevinden zich in deze folder de DPAPI sleutels (Master Key Containers) van jou user:

Elke Master Key Container bestaat uit 2 losse master key containers waarvan er 1 versleuteld is met het wachtwoord van de gebruiker en de 2e master key is versleuteld met de publieke sleutel van het domein (als een computer lid is van een domein, in dit voorbeeld gaan we hier wel vanuit). De publieke sleutel van het domein is aanwezig in deze folder en draagt de naam “BK-%domeinnaam%”:

Nogmaals (en dat is eigenlijk best grappig), iedere normale domeingebruiker beschikt dus over de publieke sleutel van het domein welke verantwoordelijk is voor de encryptie van iedereens wachtwoorden!!! En aangezien het domein maar 1 publieke sleutel heeft worden de wachtwoorden van iedere domeingebruiker versleuteld met dezelfde publieke sleutel. Hmmmm….

Maar …. We zijn opzoek naar het volledige key-pair. Dus, waar is de private key? Want als we dat sleutelsetje compleet hebben dan zijn we “heer en meester” van het complete domein. We kunnen dan iedere container openen en de inhoud veranderen of bekijken. Owned… right!!

Laten we beginnen met de CQLsassSecretsDumper tool van de CQTools suite om de DPAPI Golden Key (backup key) van LSASS naar PFX bestand om te zetten. Als dit proces slaagt heb je een copy van de private domain key in PFX formaat. CQLsassSecretsDumper bestaat op de achtergrond uit 41 mini-tools welke deze actie mogelijk maken. Dit is de moeilijkste fase van de hack want de tool werkt alleen op een aantal voorwaarden:

• Je bent een domain admin. – OF
• Je hebt toegang tot een backup van de DC. – OF
• Je hebt als gebruiker toegang in het domain om directory replications uit te voeren (Sharepoint service accounts voor profile replication). – OF
• Als je als domain admin kunt inloggen op een read-only DC.

Het makkelijkste is om het wachtwoord van een Sharepoint service account te achterhalen (tools aanwezig in de CQTools toolkit) en om hiermee de private key te exporteren. Laten we dit doen:

CQLsassSecretsDumper.exe /file exported.pfx

En nu hebben we de private key van het domein en kunnen we elk wachtwoord van elke user achterhalen door de master key containers van die gebruikers opnieuw kunnen versleutelen met het wachtwoord van onze eigen user en zodoende kunnen inlezen.

Om dit concept aan te tonen gaan we inloggen met dezelfde gebruiker maar met een ander wachtwoord op basis van “cached logon data”. Meestal noemen we deze data ook wel “cached credentials” maar feitelijk zijn het geen credentials omdat je er niet mee in kunt loggen. We hebben het hier over de non-reversable PBKDF2 (Password-Based Key Derivation Function 2) cryptografische functies. Let op, dit is een zijstap die niet essentieel noodzakelijk is voor de hele proces maar die wel mooi aantoont dat wachtwoorden via DPAPI niet meer te zien zijn als het gebruikers wachtwoord anders is.

We kunnen de volgende aanpak op 2 manieren uitvoeren. Online en offline. De offline methode is lineair en dus gemakkelijker. We kiezen in deze demo voor de “offline” aanpak.

Om het wachtwoord van de cached credentials te veranderen maken we gebruik van de “Mimikatz” tool https://jarnobaselier.nl/mimikatz/. Dus zorg dat je deze voorhanden hebt.

We rebooten de PC in recovery mode, en starten vervolgens de “Command Prompt”. Vanuit hier starten we Mimikatz met het volgende commando:

privilege::debug
token::elevate
lsadump::cache /user:regular /password:mypassword d:\windows\system32\config\SYSTEM d:\windows\system32\config\SECURITY /kiwi

Als we de commando’s ontleden:

• privilege::debug – “debug-privilege” maakt het mogelijk om een proces te debuggen waar men normaliter geen toegang toe heeft zoals een SYSTEM proces.
• token::elevate – Dit is een “impersonation” commando. V.a. dat moment doe je jezelf voor als System.

• lsadump::cache – Gebruik de MimiKatz cached credentials optie
• /user:regular – Specificeer de gebruiker waarvoor we de cached credentials gaan vervangen.
• /password:mypassword – Specificeer het nieuwe wachtwoord van de cached credentials.
• d:\windows\system32\config\SYSTEM – Dit is de locatie waar de “bootkey” zich bevind welke verantwoordelijk is om cached credentials te decrypten.
• d:\windows\system32\config\SECURITY – De locatie waar de cached credential wachtwoorden zich bevinden.
• /kiwi – De /kiwi switch is verantwoordelijk voor het overschrijven van de bootkey en vervolgens de cached credentials op basis van de bootkey. De wachtwoorden zijn nu gereset naar “mypassword”. Als je geen wachtwoord opgeeft is het default wachtwoord “mimikatz”.

Let op, tijdens het herstarten van Windows moeten we de netwerkverbinding verbreken om te voorkomen dat er opnieuw contact met het domain gemaakt kan worden om credentials te verifiëren. Als het contact verbroken is kunnen we inloggen met de zojuist gegenereerde cached credentials.

Nu we ingelogd zijn met de overschreven credentials zul je zien dat DPAPI het opgeslagen wachtwoord niet meer kan decrypten omdat het wachtwoord anders is dan het wachtwoord welke we gebruikt hebben op het te encrypten:

Nu berekenen we de hash van de huidige gebruiker met:

CQHashesCalc.exe

“a991ae45aa987a1a48c8bdc1209ff0e7” is dus de hash van het huidige wachtwoord.

Nu hebben we alle informatie compleet. We gaan nu de geëxporteerde domain primary key gebruiken om een master container te decrypten en opnieuw te versleutelen met ons wachtwoord. Lees, we krijgen dus toegang tot alle wachtwoorden.

Maar eerste moeten we de juiste master container vinden. Ik een productieomgeving bevat %appdata%\Microsoft\Protect\%SID% namelijk ontzettend veel master containers.

De juiste mastercontainer vinden is niet zo lastig. Hiervoor gebruiken we de CQDPAPIBlobSearcher tool als volgt:

CQDPAPIBlobSearcher.exe /d c:\Users\regular\AppData\Local /r /o c:\Users\regular\Desktop\Output

We laten de tool hier zoeken naar de secrets van de gebruiker in “c:\Users\regular\AppData\Local” omdat Chrome hier zijn secrets in opslaat. Dit doen we recursive (/r) en we specificeren als output directory en file (/o): “c:\Users\regular\Desktop\ > blob.txt”.

Dit commando doorzoekt elk bestand (in de opgegeven destination (/d) directory) en kijkt hier naar de headers welke karakteristiek zijn voor DPAPI. Als het commando klaar is ziet blob.txt er als volgt uit:

Als we verder in het bestand kijken vinden we de directory en de encryptiemethode Google Chrome gebruikt om data op te slaan.

De master key GUID is “506fe1d2-a160-4efb-9517-2504639b42d5”. En op die manier kunnen we de DPAPI master key container terugvinden:

Nu we de juiste master key container weten kunnen we de inhoud van deze (en alle andere) containers openbreken. Dit doen we met het volgende commando:

Let op de “CQMasterKeyAD.exe” tool is standaard niet aanwezig in de CQTools toolkit. Deze kun je downloaden via: https://cqureacademy.com/tools-from-dpapi-and-dpapi-ng-decryption-toolkit-black-hat-conference-session.

CQMasterKeyAD.exe /pfx exported.pfx /newhash a991ae45aa987a1a48c8bdc1209ff0e7 
/file "C:\Users\regular\AppData\Roaming\Microsoft\Protect\S-1-5-21-981398395-3307400729-2552561543-1608\506fe1d2-a160-4efb-9517-2504639b42d5"

• /pfx exported.pfx – Definieer de primary key van het domein (de geexporteerde PFX) waarmee we een master key container kunnen decrypten.
• /newhash a991ae45aa987a1a48c8bdc1209ff0e7 – Definieer de nieuwe hash waarmee we willen gaan versleutelen.
• /file “C:\Users\regular\AppData\Roaming\Microsoft\Protect\S-1-5-21-981398395-3307400729-2552561543-1608\506fe1d2-a160-4efb-9517-2504639b42d5” – De locatie van de master key container.

Als we terugkijken in de master key container folder dan zien we dat we een origineel bestand hebben en een .admodified (zojuist gecreëerd) bestand.

Deze 2 wisselen we qua naam zodat ons nieuwe bestand ook het actieve bestand wordt.

Zoals je ziet heeft het nieuwe bestand geen “radar icoontje” omdat het geen “system” bestand is. We moeten hier een “system” attribute op plaatsen met het volgende commando:

attrib "C:\Users\regular\AppData\Roaming\Microsoft\Protect\
S-1-5-21-981398395-3307400729-2552561543-1608\506fe1d2-a160-4efb-9517-2504639b42d5" +S +H

Nu we de master key container opnieuw hebben kunnen versleutelen met ons eigen wachtwoord kunnen we de Chrome content weer lezen:

Zoals je ziet is het misbruiken van DPAPI mogelijk en werkt het in elke versie van Windows. CQure heeft DPAPI volledig ge-reversed engineerd en daarmee mogelijkheden gecreëerd om niet de wachtwoorden van 1 gebruiker te achterhalen maar van alle gebruikers op een volledig domein. Dit is potentieel een zeer gevaarlijk scenario. Een hacker maar zelfs een malafide domein administrator kan op die manier alle prive wachtwoorden van gebruikers inzichtelijk maken welke ze op de domein computers gebruiken. Uiteraard is het achterhalen van de domain private key wat minder gemakkelijk maar als die hobbel genomen is dan staat er niets meer in de weg om alle secrets op het domein te decrypten.

De beste manier om jezelf te beschermen is om wachtwoorden nooit op te slaan en om altijd een password manager te gebruiken. Maar niet KeePass… want ook KeePass gebruikt DPAPI en is met de CQDPAPIKeePassDecryptor tool te kraken.

De opvolger van DPAPI is DPAPI-NG ofwel CNG DPAPI en wordt gebruikt om secrets te beveiligen tussen meerdere computers en cloud elementen. En ook DPAPI-NG is door CQure gekraakt. Maar dat is stof voor een volgende post.

Hartelijk dank voor het lezen van deze post. Ik hoop hiermee meer inzicht te hebben gegeven in het DPAPI proces en voornamelijk het kraken van DPAPI. Heb je iets aan deze post gehad? Vond je het interessant? Show me some love… ik vind het leuk om kennis te delen maar ik vind het ook erg leuk om er vervolgens iets leuks op te horen. Dus geef die like, deel mijn bericht of geef een reactie. Dankjewel en tot de volgende post!