Veel organisaties denken bij een cyberaanval aan het moment waarop iemand binnenkomt. Een kwetsbaarheid wordt misbruikt, een wachtwoord wordt gestolen of een medewerker klikt op een phishinglink.
Dat moment krijgt vaak de meeste aandacht.
Maar in de praktijk is de initiële toegang meestal niet het einddoel. Het is het beginpunt.
Zodra een aanvaller toegang heeft tot één account, werkplek, server of cloudresource, begint een nieuwe fase: ontdekken wat er nog meer bereikbaar is. Binnen cybersecurity noemen we dat laterale beweging. In het artikel over wat er tijdens een pentest gebeurt leggen we breder uit hoe zulke aanvalsscenario’s worden onderzocht.
De initiële toegang bepaalt zelden de volledige impact. De echte impact ontstaat door wat een aanvaller daarna kan bereiken.
Wat betekent laterale beweging?
Laterale beweging is het proces waarbij een aanvaller zich na de initiële toegang verder door een omgeving verplaatst.
Niet van buiten naar binnen, maar van binnen naar verder binnen.
Een aanvaller begint bijvoorbeeld met een normaal gebruikersaccount, maar probeert daarna toegang te krijgen tot gedeelde mappen, interne applicaties, beheerinterfaces, cloudresources of systemen met gevoelige data.
Het doel is meestal niet om op één systeem te blijven. Het doel is om meer inzicht, meer rechten en uiteindelijk meer controle te krijgen.
Daarom is laterale beweging zo belangrijk. Het laat zien wat er gebeurt nadat de eerste verdedigingslaag is gepasseerd.
Binnenkomen is vaak niet het moeilijkste deel
Bij veel incidenten begint de aanval met beperkte toegang.
Een medewerker gebruikt een zwak wachtwoord. Een account is gelekt. Een VPN-configuratie staat te ruim open. Een testaccount is vergeten. Een API-token heeft meer rechten dan nodig. Een werkplek mist een belangrijke beveiligingsmaatregel.
Dat soort ingangen zijn vervelend, maar op zichzelf niet altijd direct rampzalig.
De vraag is vooral wat daarna mogelijk is.
Kan een aanvaller vanaf dat account andere systemen bereiken? Zijn er gedeelde locaties met gevoelige bestanden? Kunnen rechten worden uitgebreid? Is er toegang tot beheerinterfaces? Zijn cloudrollen of serviceaccounts te ruim ingericht?
Een klein beginpunt kan pas echt gevaarlijk worden wanneer de omgeving daarachter onvoldoende is afgeschermd.
Hoe aanvallers zich oriënteren
Na de initiële toegang probeert een aanvaller meestal eerst te begrijpen waar hij is.
Welke systemen zijn bereikbaar? Welke gebruikers zijn er? Welke rechten heeft dit account? Welke interne applicaties zijn er? Welke data is toegankelijk? Welke configuratiebestanden, tokens of sleutels zijn er te vinden?
Dat klinkt minder spectaculair dan een directe aanval, maar deze fase is cruciaal.
Een aanvaller zoekt naar aanknopingspunten. Een gedeelde map met exportbestanden. Een configuratiebestand met databasegegevens. Een intern portaal zonder extra bescherming. Een serviceaccount dat meer rechten heeft dan nodig. Een cloudresource die vanuit deze omgeving bereikbaar is.
Vaak ontstaat het risico niet door één groot lek, maar door kleine observaties die samen een route vormen.
Rechten uitbreiden: van beperkte toegang naar meer controle
Met beperkte rechten komt een aanvaller vaak niet ver genoeg. Daarom zoekt hij naar manieren om toegang uit te breiden.
Dat kan via een technische kwetsbaarheid, maar veel vaker gaat het om inrichting en rechten.
Een gebruiker blijkt lid te zijn van een groep met te ruime toegang. Een serviceaccount mag meer dan nodig is. Een applicatie draait met hoge rechten. Een beheerfunctie is bereikbaar vanaf een systeem waar dat niet de bedoeling was.
Soms is er geen sprake van een “hack” in de klassieke zin. De rechten bestaan al. Ze worden alleen misbruikt.
Dat maakt dit soort risico’s lastig. Vanuit beheerperspectief lijkt alles te werken zoals ingericht. Vanuit securityperspectief is de vraag of die inrichting logisch en veilig is.
Een pentest maakt dit verschil zichtbaar door niet alleen te kijken welke toegangswegen er zijn, maar ook wat iemand met die toegang kan bereiken.
Van één systeem naar de rest van de omgeving
Laterale beweging wordt vooral gevaarlijk wanneer systemen te makkelijk met elkaar kunnen communiceren.
Een werkplek kan bijvoorbeeld bij interne shares. Een applicatieserver kan een database bereiken. Een testomgeving heeft toegang tot productiegegevens. Een intern portaal is bereikbaar vanaf een netwerksegment waar dat niet nodig is.
Los van elkaar lijken dat soms praktische keuzes. Samen kunnen ze een aanvalspad vormen.
Een aanvaller hoeft dan niet elk systeem afzonderlijk te breken. Hij gebruikt de bestaande verbindingen, rechten en vertrouwensrelaties binnen de omgeving.
Dat is precies waarom netwerksegmentatie zo belangrijk is. Niet om systemen moeilijker te beheren te maken, maar om te voorkomen dat één ingang automatisch toegang geeft tot veel meer.
Waarom laterale beweging vaak lang onzichtbaar blijft
Laterale beweging veroorzaakt niet altijd direct opvallende signalen.
Een aanvaller gebruikt soms normale accounts, bestaande verbindingen en toegestane protocollen. Vanuit technisch perspectief lijkt het verkeer dan legitiem. Er wordt ingelogd, er worden bestanden geopend, er wordt verbinding gemaakt met interne systemen.
Alleen de bedoeling klopt niet.
Dat maakt detectie lastig. Zeker wanneer logging beperkt is, alerts niet goed zijn ingericht of normale beheertaken veel lijken op ‘verdacht’ gedrag.
Daarom is het niet genoeg om alleen de buitenkant van een omgeving te beveiligen. Organisaties moeten ook begrijpen wat er gebeurt als iemand al binnen is.
Welke bewegingen zouden dan mogelijk zijn? Welke systemen zijn bereikbaar? Welke rechten kunnen worden misbruikt? Waar zou je het merken als iemand zich door het interne netwerk beweegt?
Die vragen zijn vaak belangrijker dan de vraag hoe de eerste toegang precies ontstond.
De rol van netwerksegmentatie
Zwakke netwerksegmentatie is een van de belangrijkste oorzaken waardoor laterale beweging makkelijker wordt.
Wanneer systemen vrij met elkaar kunnen communiceren, geldt dat ook voor een aanvaller die toegang krijgt tot één van die systemen.
Een systeem dat eigenlijk geïsoleerd had moeten zijn, blijkt toch andere systemen te kunnen bereiken. Een account dat alleen bedoeld was voor één taak, blijkt toegang te hebben tot meerdere omgevingen. Een intern portaal blijkt bereikbaar vanaf een plek waar dat niet nodig is.
Op die manier wordt één configuratiefout onderdeel van een groter aanvalspad.
Segmentatie hoeft niet te betekenen dat alles volledig wordt afgesloten. Het gaat erom dat toegang bewust wordt ingericht. Systemen moeten kunnen communiceren waar dat nodig is, maar niet standaard overal bij kunnen.
Dat onderscheid maakt in de praktijk veel verschil.
Laterale beweging in cloudomgevingen
Laterale beweging speelt niet alleen in traditionele netwerken. Ook in cloudomgevingen kan een aanvaller zich stap voor stap lateraal bewegen.
De vorm is anders, maar het principe blijft hetzelfde.
In plaats van een werkplek, fileserver of domain controller gaat het dan bijvoorbeeld om cloudrollen, serviceaccounts, storage buckets, secrets, metadata services en beheertoegang tot resources.
Een aanvaller die toegang krijgt tot één cloudresource kijkt welke rechten daaraan gekoppeld zijn. Kan deze rol andere resources lezen? Zijn er secrets aanwezig? Kan een andere rol worden aangenomen? Is er toegang tot logging, storage of deploymentprocessen?
Het risico ontstaat vaak door combinaties van bovenstaande.
Een resource heeft op zichzelf beperkte rechten, maar kan een andere rol gebruiken. Een serviceaccount is bedoeld voor één taak, maar heeft brede toegang. Een opslaglocatie is niet publiek, maar wel bereikbaar vanuit een omgeving waar een aanvaller al toegang toe heeft.
Daarom moet een cloud pentest niet alleen kijken naar losse instellingen, maar naar wat die instellingen samen mogelijk maken.
Waarom vulnerability scans dit vaak niet goed laten zien
Vulnerability scans kunnen nuttig zijn om bekende kwetsbaarheden en zichtbare configuratieproblemen te vinden.
Maar laterale beweging draait om samenhang.
Een scan kan zien dat een poort openstaat. Een scan kan een bekende kwetsbaarheid herkennen. Een scan kan soms een configuratiefout signaleren.
Maar een scan begrijpt meestal niet wat er gebeurt wanneer een account, een netwerkroute, een service en een cloudrol samen een aanvalspad vormen.
Daarvoor is context nodig.
Welke toegang hoort dit account te hebben? Welke systemen mogen met elkaar communiceren? Is deze route logisch voor normaal gebruik? Wat wordt mogelijk als een aanvaller deze rechten combineert?
Dat zijn vragen die verder gaan dan een standaard scan.
Daarom is het verschil tussen een vulnerability scan en een pentest belangrijk. Een vulnerability scan geeft overzicht. Een pentest onderzoekt wat iemand in de praktijk kan uitbuiten.
Wat een pentest zichtbaar maakt
Een goede pentester kijkt niet alleen naar kwetsbaarheden, maar vooral naar de mogelijke aanvalsscenario’s die daar uit voortvloeien.
Wat gebeurt er als een aanvaller toegang krijgt tot één account? Hoe ver komt hij dan? Welke systemen kunnen dan worden benaderd? Welke rechten kunnen worden misbruikt? Welke data komt in beeld?
Dat betekent niet dat een pentest altijd “alles” moet proberen, maar wel dat de test realistische aanvalspaden onderzoekt.
Bij een netwerk pentest kan dan worden gedacht aan bereikbaarheid, segmentatie, welke interne services allemaal zijn te benaderen en rechtenstructuren. Bij een cloud pentest ligt de nadruk eerder op identity, rollen, cloudresources en de samenhang tussen diensten.
Het doel is hetzelfde: zichtbaar maken of een beperkte ingang kan uitgroeien tot een groter risico.
Dat is vaak waardevoller dan alleen weten dat er ergens een losse kwetsbaarheid aanwezig is.
Wat organisaties zichzelf moeten afvragen
Laterale beweging dwingt organisaties om anders naar risico’s te kijken.
Niet alleen:
“Kunnen we voorkomen dat iemand binnenkomt?”
Maar ook:
“Wat gebeurt er als iemand tóch binnenkomt?”
Die tweede vraag is vaak ongemakkelijker, maar veel realistischer.
Geen enkele omgeving is volledig foutloos. Accounts kunnen worden misbruikt, systemen kunnen verkeerd zijn ingericht en gebruikers kunnen fouten maken. De vraag is hoe ver een aanvaller daarna kan komen.
Daarom zijn vragen als deze belangrijk:
Welke systemen zijn bereikbaar vanaf een gewone werkplek?
Welke accounts hebben meer rechten dan nodig?
Zijn test- en productieomgevingen voldoende gescheiden?
Kunnen interne portalen of beheerinterfaces vanaf te veel plekken worden benaderd?
Wordt verdacht intern gedrag gelogd en opgemerkt?
De antwoorden op die vragen bepalen vaak de echte impact van een incident.
Van eerste toegang naar werkelijke impact
De meeste ernstige security-incidenten ontstaan niet door één losse kwetsbaarheid. Ze ontstaan doordat een initiële ingang kan worden uitgebouwd.
Phishing leidt tot toegang tot interne bestanden. Een kwetsbare server wordt een opstap naar andere systemen. Een verkeerd ingestelde cloudrol veroorzaakt toegang tot gevoelige data. Een slecht gesegmenteerd netwerk maakt beweging door de omgeving mogelijk.
Laterale beweging laat zien waarom de impact van een incident vaak groter is dan de eerste kwetsbaarheid doet vermoeden.
Wie alleen kijkt naar preventie, mist het vervolg.
Wie begrijpt wat er na de initiële toegang mogelijk is, kan gerichter maatregelen nemen: betere segmentatie, strakkere rechten, betere logging en realistischer testen.
Wil je weten hoe ver een aanvaller binnen jouw omgeving zou kunnen komen na het vinden van een eerste ingang? Dan kan een gerichte pentest helpen om realistische aanvalspaden binnen netwerk- en cloudomgevingen zichtbaar te maken.