Lateral Movement op Windows met BitlockMove: Hoe COM Hijacking via BitLocker werkt

Lateral movement is een veelgebruikte techniek bij aanvallen op Windows-netwerken. Je hebt vaak toegang tot één machine en verplaatst je vervolgens naar andere systemen binnen hetzelfde domein. Veel lateral movement methodes draaien om credential theft of token impersonation, maar er bestaat een alternatieve aanpak die subtieler werkt: COM hijacking. In het voorbeeld van BitlockMove gaan we COM-Hijacking uitvoeren in combinatie met BitLocker-componenten. In dit artikel leg ik uit hoe BitlockMove werkt, welke stappen nodig zijn en wat je er uiteindelijk mee kunt.

Wat is BitlockMove?

BitlockMove is een tool waarmee je code kunt uitvoeren op een andere Windows-machine waar dezelfde gebruiker een interactieve sessie heeft. Het bijzondere aan deze aanpak is dat je geen wachtwoorden hoeft te stelen of tokens hoeft te kapen. Je maakt gebruik van een combinatie van:

• DCOM-interacties met BitLocker-gerelateerde componenten
• COM hijacking door het Windows-register op afstand aan te passen

Hierdoor start je een proces in de sessie van de ingelogde gebruiker. Dat proces laadt een kwaadaardige DLL in waar je als aanvaller dus de logica in kunt stoppen welke je nodig hebt.

Het proces waar de BitlockMove POC zich op richt, heet BaaUpdate.exe. Dit is de BitLocker Access Agent Update Utility. Windows gebruikt het voor updates en onderhoudstaken rondom BitLocker. Omdat deze executable draait onder de context van de interactieve gebruiker, kun je ermee werken zodra BitLocker actief is.

Hoe werkt COM hijacking hier precies?

Windows COM (Component Object Model) werkt met CLSIDs (Class Identifiers) die in het register verwijzen naar DLL’s. Wanneer een proces een COM-object aanmaakt, kijkt het welke DLL daarbij hoort en laadt die in zijn procesgeheugen.

BitlockMove maakt gebruik van de CLSID “ab93b6f1-be76-4185-a488-a9001b105b94”, ook bekend als BDEUILauncher. Deze klasse kan processen starten, zoals BaaUpdate.exe. Als je in het register aanpast welke DLL daarbij hoort, kun je je eigen code laten uitvoeren.

De aanval werkt grofweg als volgt:

• Remote registry write: Je verandert de CLSID-registratie op het doelwit zodat jouw kwaadaardige DLL wordt gebruikt.
• DLL beschikbaar maken: Je zet je DLL op de machine. Dit kan bijvoorbeeld via een SMB-share. BitlockMove doet dit automatisch.
• Het COM-proces starten: Je triggert het proces dat de DLL laadt. Hierdoor voert de machine je code uit in de sessie van de ingelogde gebruiker.

Omdat de code draait in de context van die gebruiker, heb je toegang tot al diens bestanden, netwerksessies en tokens. Je hoeft geen extra credentials te bemachtigen.

Welke voorwaarden zijn er?

Deze aanval vereist wel een paar zaken:

• De doelgebruiker moet interactief ingelogd zijn op een andere machine.
• BitLocker moet ingeschakeld zijn, omdat je een BitLocker-component misbruikt. Je kunt ook andere COM-componenten vinden die kwetsbaar zijn, maar BitLocker is in veel bedrijfsnetwerken standaard actief.
• Je moet toegang hebben tot een domain-joined machine waar je de aanval vanuit uitvoert.

In veel omgevingen is dit scenario realistisch. BitLocker wordt vaak verplicht ingesteld, en helpdeskmedewerkers of systeembeheerders hebben op meerdere computers actieve sessies.

Stapsgewijze aanval met BitlockMove

Hieronder voeren we een aanval uit. We hebben in dit scenario al toegang tot client02 en we gebruiken client01 als doelsysteem.

Stap 1: Nagaan of BitLocker actief is.
Als je admin-credentials hebt, kun je via PowerShell controleren of BitLocker aan staat:

$creds = Get-Credential
 
Get-WmiObject -Namespace "Root\CIMV2\Security\MicrosoftVolumeEncryption" -Class Win32_EncryptableVolume -ComputerName client01-win10 -Credential $creds

In veel situaties doe je de aanname dat BitLocker actief is. Zeker als Bitlocker ook op de huidige machine (in dit voorbeeld client02) aanstaat.

Stap 2: Controleren op actieve sessies
Voer de enumeratie uit om te zien of de gebruiker een interactieve sessie heeft op de andere machine, in dit geval client01:

.\BitlockMove.exe mode=enum target=172.16.200.210

Als de gebruiker hier een actieve sessie heeft kunnen we doorgaan. In dit scenario gaan we ervan uit dat dit het geval is.

Stap 3: DLL klaarmaken en aanval uitvoeren
Je kunt een eigen DLL droppen of de standaard-DLL gebruiken. Wij gebruiken de default DLL en starten vervolgens een proces, bijvoorbeeld Notepad, in de sessie van de doelgebruiker:

.\BitlockMove.exe mode=attack target=172.16.200.210 dllpath=C:\Users\User1\Desktop\pwned.dll targetuser=ospathway\user1 command="notepad.exe"

We kunnen ook een commando uitvoeren en de output laten wegschrijven:

.\BitlockMove.exe mode=attack target=172.16.200.210 dllpath=C:\Users\User1\Desktop\pwned.dll targetuser=ospathway\user1 command="cmd.exe /C whoami > C:\Users\User1\Desktop\output.txt"

V.a. een externe machine – Runas voor enumeratie

Als je geen actieve sessie hebt een domain-joined machine, maar wel credentials hebt dan kunnen we via runas ook enumereren op actieve sessies:

runas /netonly /user:ospathway.local\user1 "cmd /c C:\Users\user\Desktop\BitlockMove.exe mode=enum target=172.16.200.210 > C:\Users\user\Desktop\output.txt"

*Let op: we kunnen echter voor de aanval (attack mode) geen externe machine (non domain-joined) gebruiken. We moeten met het gebruik van het /runas commando de flag “netonly” gebruiken. Hiermee impersonaten we alleen netwerk connecties met de opgegeven gebruiker. Het lokale proces draait nog steeds onder de credentials van de currently logged-on user (op de non domain-joined machine). File access werkt (dus het droppen van de DLL werkt ook), echter roept COM – DCOM en RPC interfaces aan op de remote machine. Dit gebeurt onder de huidige gebruiker en niet via de impersonated credentials welke we via de /netonly flag meegeven. DCOM en RPC vallen niet onder “network resource access” en daarom zal de attackmode van BitlockMove falen v.a. een non domain-joined machine.

Wat maakt deze methode interessant?

BitlockMove laat zien hoe je een relatief onopvallende lateral movement kunt uitvoeren:

• Geen credential theft nodig
• Geen token impersonation
• Code draait direct in de sessie van de gebruiker
• Minder detecteerbaar dan traditionele technieken

Deze aanpak kan een waardevol scenario zijn tijdens red team assessments of pentests. Organisaties zouden deze methode kunnen ondekken door monitoring in te richten waarbij getriggerd wordt op ongebruikelijke registry-wijzigingen en COM-activiteit.

Tot slot

BitlockMove is een helder voorbeeld van hoe COM hijacking in de praktijk werkt. Veel beveiligingsteams richten hun aandacht op credential dumps, pass-the-hash en Kerberos-aanvallen. Maar technieken zoals deze verdienen minstens zoveel aandacht, juist omdat ze minder opvallend zijn.

Video

Beelden zeggen meer dan 1000 woorden. Wil je bovenstaande ook gedemonstreerd hebben in een video…? Ook deze heb ik voor je gemaakt! Zie: