Red Teaming en Breach & Attack Simulation

Red Teaming en Breach & Attack Simulation

Auteur: Tiennot van Dilst, CISSP, CEH, CIPP/e, CxCE, CTO / Security Expert

Red Teaming en wat te verwachten?

Bij mijn vorige werkgever heb ik als Head of Delivery meerdere “Red team” opdrachten mogen begeleiden. Ik zal in deze blog kort proberen samen te vatten hoe een dergelijk project in zijn werk gaat en wat er zoal bij komt kijken.

Tijdens een Red team opdracht proberen we een daadwerkelijke hack te simuleren. Eigenlijk is simuleren niet het goede woord om het te beschrijven, omdat we eigenlijk niet simuleren maar uitvoeren. Tijdens een Red team proberen we een organisatie binnen te dringen op een manier zoals een hacker dat zou doen. Tijdens dit project is er vaak slechts een select gezelschap (het White team) in de organisatie op de hoogte dat dit project plaats vindt en gedurende het project dient dit ook geheim te blijven.

Dit omdat we niet alleen willen kijken of de hack geblokkeerd wordt door de maatregelen, maar ook om te kijken of de mensen die verantwoordelijk zijn voor de beveiliging (het Blue team) de aanval welke plaats vindt kunnen detecteren en eventueel blokkeren.

Om de situatie zo echt mogelijk te “simuleren” heeft een red team project, in vergelijking tot een pentest een ander soort scope. Vaker wordt er tijdens een Red team meer gesproken over een doel, maar daarbij wel in ogenschouw genomen dat een aantal zaken niet geoorloofd zijn. Denk hierbij aan Denial of Service, digitale aanvallen op bepaalde afdelingen of data of iets dergelijks.

Daarnaast zal de doorlooptijd van een red team project doorgaan een veelvoud zijn van de doorlooptijd van een pentest, dit omdat in veel gevallen er op voorhand veelal niet zoveel gedeeld wordt over de organisatie welke getest wordt. Wat dus impliceert dat de red teamers hiernaar opzoek moeten!

Een belang van een Red team is dus, het doel te bereiken en terwijl we dit doen mogen we niet gedetecteerd worden door het Blue team. Wat dus een tweede factor is waardoor de looptijd doorgaans erg lang is. Alles wat het red team doet moet zeer voorzichtig gebeuren om niet gedetecteerd te worden. Een van de dingen om dit te doen, is bijvoorbeeld wanneer je intern in een netwerk een scan uitvoert, je de scanner zeker niet voluit om zich heen kan laten schieten, dat is de manier om een alert te triggeren in een SOC of iets dergelijks.

Iets wat je weer wel kan doen (tenzij anders besproken) in een Red team project, is bijvoorbeeld via een medewerker van een organisatie proberen binnen te dringen. Denk hierbij aan een vorm van phishing, of wanneer je een onbekende ingang (bijv. via shadow IT) vindt om deze te gebruiken om toegang te krijgen. Kortom veel dingen die tijdens een normale pentest “off limits” zijn kunnen wel getest worden tijdens een red team activiteit. Paar voorbeelden:

Fysieke beveiliging: Tijdens een red team project kan in sommige gevallen een red teamer proberen fysiek toegang te krijgen tot een pand; kan hij of zij doorlopen zonder dat iemand van de receptie of de bewaking ze stopt.

Vreemde devices in het netwerk plaatsen: In het verleden tijdens de verschillende opdrachten hebben we wel een devices in het netwerk geplaatst. Denk hierbij bijvoorbeeld aan een device wat aan de ene kant connectie maakt met het netwerk, aan de andere kant via een 4G of 5G verbinding benaderbaar is, en op die manier dus zaken zoals firewalls omzeilt. Of denk hierbij aan het installeren van een hardware keylogger.

Gebruik maken van “gevonden” credentials: Credentials kan je op verschillende plaatsen vinden, niet alleen op systemen, maar bijvoorbeeld ook wanneer je in een pand bent en kijkt onder de toetsenborden. Met behulp van deze credentials kan veelal toegang gekregen worden tot verschillende systemen, of een begin te creëren via een ander systeem.

Infecteren van werkstations: Bepaalde exploits installeren op één of meerdere endpoints, welke gebruikt kunnen worden om toegang te krijgen tot het netwerk of bestanden. Dit zouden ook bijvoorbeeld software keyloggers kunnen zijn.

Verzenden van Phishing e-mails: mogelijk met doel om bovenstaand te bereiken.

Gebruikers over halen een device aan hun pc te koppelen: Bijvoorbeeld een aantal USB  sticks in het pand te “verliezen” in de hoop dat een gebruiker deze aan een pc koppelt.

Wifi hacking/ sniffing/ afluisteren: trachten in te breken op het wifi netwerk, met als doel bijvoorbeeld credentials te stelen.

Etc: je zult begrijpen dat ik niet alle technieken kan beschrijven in deze blog maar wees creatief… en ga ervanuit dat een red teamer nog creatiever is.

Uiteraard is het van cruciaal belang, dat de Red teamer zeer goed bijhoudt wat hij doet. Dit dient veelal wekelijks gerapporteerd te worden aan het White team. Mochten er dan ineens bellen en alarmen afgaan, dan kan iemand binnen een organisatie nagaan of het om het Red team ging, of omdat er iets anders aan hand is (een echte hack bijvoorbeeld).

Wanneer eindigt een red team activiteit?

Doorgaans eindigt een red team activiteit officieel vaak wanneer het Blue team ze te pakken heeft, het doel is bereikt, of de afgesproken doorlooptijd is verstreken.

Let op, ik zeg hier vaak want dit is niet altijd het geval. Soms wordt ervoor gekozen om het project door te laten gaan, alleen met aangepaste spelregels.

Eén van de aanpassingen kan zijn dat het Blue team op de hoogte is en op dat moment ieder alarm of gelogde event kan bespreken in de wekelijkse meetings. Een andere aanpassing zou kunnen zijn dat er een zogenaamde Legup wordt toegekend.

Wat is een Legup?

Een legup, is letterlijk een stukje geholpen worden de organisatie in, door de organisatie welke getest wordt. Denk hierbij bijvoorbeeld aan het toestaan van een bepaalde device in het netwerk (fysiek maar ook op het netwerk), of het openen van een bepaalde poort of toegang tot een bepaald werkstation of server. Veelal worden de legups toegekend omdat het Red team voor een heel groot deel succesvol was om ergens te komen, alleen zitten er een of twee dingen dwars om alles in kaart te kunnen brengen. Je kunt begrijpen dat een legup moeten krijgen iets is wat veel Red teamer niet fijn vinden, echter in veel gevallen wel iets wat gebeurt tijdens een red team project.

Maar wat kan ik dan echt verwachten na een red team activiteit?

Zoals ik hierboven al beschreef is een Red team activiteit iets anders dan een pentest. Een pentest is veelal bezig om aan te tonen dat een omgeving of applicatie op een bepaalde manier kwetsbaar is voor aanvallen. Bij een red team gaat het niet zozeer om aan te tonen dat een specifieke applicatie of infrastructuur kwetsbaar is, maar het gaat meer om aan te tonen wat je met die specifieke kwetsbaarheid kunt doen, en kan je bijvoorbeeld deze gebruiken om verder binnen te dringen in de organisatie om uiteindelijk het doel te bereiken. Een doel kan bijvoorbeeld zijn om domain administrator te worden, of toegang te krijgen tot een bepaalde map in het netwerk of server.

De rapportage in een pentest zal dan ook meer beschrijven hoe kwetsbaar iets is en hoe het te verbeteren, de rapportage van een red team zal meer beschrijven, hoe het team bij een bepaald doel is kunnen komen met daarbij adviezen hoe de gebruikte technieken gedetecteerd of geblokkeerd kunnen worden.

Kostbaar!!!

Je kunt begrijpen dat een red team project geen klein project is, en dat daar gebruik gemaakt wordt van zeer specifieke resources. Een red teamer is iemand met een specifieke set of skills en meestal hangt hier een prijskaartje aan. Daarnaast duurt een project veelal lang (reden eerder beschreven).

Ik heb in het verleden red team projecten mogen begeleiden welke meerdere maanden duurde en waarbij meerdere red teamers, volledig of part time ingezet werden.

Red teaming vs. BAS of Red teaming en BAS

Zoals ik in één van de vorige blogs heb beschreven kan BAS een aantal zaken van het red team en de ethical hack automatiseren. Maar los van dat, kan BAS (met de juiste module) ook gebruikt worden door een red teamer om zijn exploits uit te voeren. Zeker in de fase wanneer er een Legup toegekend is kan dit een zeer welkome aanvulling zijn. Daarnaast kan de Recon module van BAS een red team zeer snel (binnen 24 uur, i.p.v. ongeveer 2 maanden) de buitenkant van een organisatie tonen - het zg. aanvalsoppervlak.

Buiten dat het de red teamer zou kunnen helpen, zou BAS ook ingezet kunnen worden om een deel van het red team project te vervangen. Een interne medewerker kan dus zelf een aantal testen starten, en bijvoorbeeld een blue team kan gaan fungeren als een purple team (red and blue = purple).

Vraag ons naar een demonstratie van BAS om te kunnen zien hoe dat in zijn werk gaat.