Beveiligingsteams zijn goed geworden in het controleren van wat hen kan schaden. Werkt een EDR-agent een bepaald payload tegen? Valt een SIEM-regel op een specifieke techniek? En lukt een phishing-simulatie om medewerkers te laten reageren?
Toch zit er een structureel probleem achter die manier van testen. Het grootste deel van de validatie richt zich op losse onderdelen. Maar echte aanvallers—steeds vaker met AI-ondersteunde tooling—opereren zelden via één enkele stap. Ze bouwen een keten van acties waarbij elke vervolgstap meebeweegt op wat eerder is gelukt.
Daarom wordt attack chains testen steeds belangrijker: niet alleen beoordelen of een techniek ‘werkt’ tegen een controle, maar nagaan of een volledige aanvalspad end-to-end wordt opgemerkt en gestopt.
Waarom losse techniektests vaak te optimistisch zijn
Veel breach- en aanvalssimulatieprogramma’s werken met een bibliotheek aan individuele technieken. Vaak koppelen ze die aan bekende taxonomieën, zoals MITRE ATT&CK. Vervolgens voer je techniek A uit, kijk je of die gedetecteerd wordt, techniek B erna, en zo verder. Daarna komt er een score of lijst met resultaten.
Dat geeft inzicht, maar het antwoord op de kernvraag ontbreekt: zou een tegenstander een reeks technieken achter elkaar kunnen plakken en daarbij continu aanpassen op wat er in jouw omgeving gebeurt? Juist die aanpassing is cruciaal. Een stap die op zichzelf “niet erg” lijkt, kan in combinatie met een volgende techniek ineens een bruikbaar aanvalspad worden.
Zelfs als je 90% van je controles afvangt, kan de resterende 10% het “gebroken schakeltje” zijn dat de keten compleet maakt. En wanneer die schakels zich bevinden tussen teams, systemen of alerts die niet met elkaar samenwerken, wordt het risico extra lastig zichtbaar.
Het exposure gap: wat er misgaat tussen tools
Een vaak gehoorde conclusie na incidenten is niet dat beveiliging faalde op één concreet punt. De realiteit is dat een aanval kon landen doordat verschillende delen van de verdediging niet als één geheel werkten. Met andere woorden: de organisatie had wel geteste onderdelen, maar niet het volledige pad als samenhangende keten.
In een rapport van Filigran werd aangegeven dat veel organisaties ondanks eerdere validaties toch een cyberaanval met bedrijfsimpact hebben meegemaakt. Ook wordt daar genoemd dat AI de snelheid waarmee aanvallen zich ontwikkelen binnen de omgeving kan vergroten, en dat silo’s en ongekoppelde testaanpak een belangrijke oorzaak zijn dat kwetsbaarheden niet tijdig opvallen.
Dat sluit aan bij wat je in de praktijk ziet: je kunt ‘veilig’ lijken op dashboards, maar als de verbinding tussen detectiepunten ontbreekt, blijft de aanval onopgemerkt tot het te laat is.
Attack chains testen sluit aan bij hoe aanvallen echt verlopen
Attack chaining pakt precies dat probleem aan. Het idee is simpel maar krachtig: verbind technieken in de volgorde waarin een aanvaller ze zou inzetten, inclusief de logica om door te pakken op basis van live resultaten.
Een realistische aanval start meestal met initiële toegang. Daarna volgt bijvoorbeeld credential abuse, vervolgens laterale beweging, daarna het verzamelen of voorbereiden van data en ten slotte exfiltratie. In een keten werkt elke stap door in de volgende stap:
- Een phishingmail levert een verzamelde inlog op.
- Die inlog geeft toegang tot een eerste foothold.
- Vanuit dat punt ontstaat ruimte voor privilege escalation.
- Daarna volgen de paden naar andere systemen, token- of padberekeningen en het veiligstellen van gegevens voordat er wordt uitgenomen.
Attack chains testen draait daarom niet om het afvinken van ‘ techniek X is geblokkeerd’, maar om de vraag: komt de hele volgorde door de verdediging heen?
Hoe attack chains testen in de praktijk wordt opgebouwd
Een ketentest is pas waardevol als hij kan reageren op wat er tijdens het uitvoeren gebeurt. In plaats van een vast script wil je conditional chaining logic: voorwaarden die bepalen wat de volgende stap is.
Voorwaardelijke ketenlogica
Bij attack chaining wordt de multi-stage logica opgebouwd zodat acties en gebeurtenissen elkaar opvolgen op basis van echte output. Denk aan situaties als: als een credential geldig blijkt, ga door naar het pivot-stap; als een controle de actie blokkeert, stop dan of kies een alternatieve route.
Belangrijk is dat die ketenlogica inspecteerbaar blijft. Daarmee kunnen securityteams de keten later herzien of uitbreiden zodra nieuwe technieken opduiken.
Live mapping van aanvalspaden
Een tweede pijler is live aanvalspad mapping. In plaats van achteraf een rapport met “dit was het eindresultaat” te krijgen, wil je zien hoe het pad zich tijdens de run vormt. Elke stap en pivot verschijnt dan in een interactieve weergave van start tot doel.
Zo ontdek je sneller waar een aanval daadwerkelijk kan doorzetten—en waar een bottleneck zit.
Vindplaatsen die ook echt iets opleveren
Attack chains testen levert meer op dan een algemene conclusie. Elke ketenstap kan worden vertaald naar een gestructureerde bevinding: wat werd geprobeerd, wat kwam eruit, en hoe leidde die uitkomst tot de volgende actie?
Die traceerbaarheid maakt het gemakkelijker om chokepoints te identificeren: dat zijn de punten in het pad waar één correctie downstream veel tegenhoudt. Zonder keteninzicht krijg je vaak lange remediation-lijsten zonder prioritering.
Scope en veiligheid vooraf regelen
Omdat ketentesten ingrijpend kunnen zijn, is scope control essentieel. Je definieert vooraf welke assets en doelen binnen bereik vallen en hoe ver de keten mag escaleren. Ook stel je grenzen aan welke acties geoorloofd zijn.
Daardoor kun je de simulatie autonoom uitvoeren binnen afgesproken guardrails, zonder verlies van grip op het proces.
Social engineering als volwaardige ketenstap
Een realistische aanval begint niet altijd met malware of exploitatie. Vaak start het met een menselijk moment. Daarom behandelen ketens phishing, sms-lures en nep-landingpages als een normaal onderdeel van het pad.
Een klik of een ingediende credential wordt dan een resultaat dat direct doorstroomt naar vervolgstappen, net zoals een geabuseerde wachtwoordprompt of een gevonden open poort in een technisch deel van het pad.
Zo test je niet alleen “reageren medewerkers op een lure?”, maar ook hoe die respons doorwerkt richting privilege escalation en uiteindelijk exfiltratie.
Operator-led versus (AI-)autonoom keten testen
Attack chaining kan in twee werkvormen worden uitgevoerd.
Operator-led mode
In operator-led testing bouwt een securityprofessional de conditional logic en stuurt de uitvoering. Dat is sterk als je deterministische, transparante en herhaalbare pentesting wilt schalen. Je stuurt dan heel gericht op wat je wil testen en wanneer.
Autonomous attack chaining
In autonome ketentest wordt een AI-agent gebruikt om de keten zelf te plannen en uit te voeren. Daarbij leg jij doel en scope vast, waarna een orchestrator-agent het pad kiest, vervolgstappen aanpast op basis van de gevonden resultaten en—als het doel dat vraagt—ook social engineeringonderdelen kan genereren.
Volgens de bron kan zo’n orchestrator bovendien specialisten inschakelen voor recon, exploitation en het ontwikkelen van payloads, afhankelijk van de behoeften van de keten.
In beide varianten draait het uiteindelijke doel om hetzelfde: een geloofwaardige end-to-end simulatie die snel herhaald kan worden terwijl je omgeving verandert, en die leidt tot inzichten die niet blijven hangen in een geïsoleerd rapport.
Wat je als organisatie echt moet willen meten
De “real takeaway” is dat organisaties vaak niet falen op individuele controles. Ze falen op de ketentest die ze nooit hebben gedraaid—precies omdat die keten tussen systemen, teams en alerts doorloopt.
Als aanvallers sneller bewegen, mede door AI-ondersteunde tooling, wordt het verschil tussen losse techniekchecks en echte ketenweerbaarheid groter. Daarom verschuift de focus: attack surfaces bestaan uit zwaktes, maar aanvallen zijn ketens. Je moet testen op het niveau waarop je verdediging daadwerkelijk moet werken.
Concreet betekent dat: kijk niet alleen of je EDR een payload detecteert of of je SIEM op een specifieke techniek reageert. Kijk of de volgorde van initiële toegang tot doel automatisch door je eigen verdedigingsgaten heen kan.
Gerelateerd: van “melding” naar “ingreep” in de keten
Een ketenbrede blik helpt ook om eerdere incidentinzichten beter te vertalen naar actie. Als je wilt zien hoe aanvallen soms uitgroeien tot een bredere exploitketen, kan je bijvoorbeeld ook de analyse rondom Chrome-Windows zero-day keten GRIMWEDGE erbij pakken. Dat soort ketendenken helpt om te begrijpen waar detectie per component niet genoeg is.
Daarnaast is het waardevol om te kijken naar het bredere thema van het testen van menselijke factoren en misbruik. Een voorbeeld is HBO Max Reddit-malvertising: ClickFix uitgelegd, waar je ziet hoe een schijnbaar “los” onderdeel in een campagne kan bijdragen aan een grotere aanval.
Conclusie: test op ketens, niet alleen op stukjes
Securityteams kunnen veel controleren en veel verbeteren. Maar de grootste risico’s zitten vaak niet in afzonderlijke technieken; ze zitten in de manier waarop die technieken samen een pad vormen. Daardoor kan een organisatie “geslaagd” zijn op validaties, terwijl een echte aanval toch door de verdediging heen loopt.
Attack chains testen helpt om die mismatch te verkleinen: je bouwt een scenario waarin elke stap doorleeft op basis van wat echt wordt gevonden, je krijgt live inzicht in de route en je ziet waar een fix de hele downstream keten kan inperken.
Als je alleen losse onderdelen test, blijf je blind voor de gaten tussen tools. Als je ketens test, leer je waar je verdediging daadwerkelijk weerstand biedt—en waar je nog moet schakelen.
Bron: https://thehackernews.com/2026/09/attack-chains-not-just-attack-surfaces.html
