Regelmatig vragen we onze medewerkers een blog te schrijven. Deze keer een blog door Frank Clevers, security consultant bij Access42.
In de afgelopen weken was het helaas vaker raak: organisaties die last hadden van ransomware. Nadat dit bekend werd gemaakt, kwamen er veel reacties binnen over hoe dit voorkomen had kunnen worden, bijvoorbeeld door zoals Awareness, EDR, SOC/SIEM, XDR. Deze genoemde oplossingen kunnen inderdaad bijdragen om je cyberrisico te verlagen.
Interessant is om te weten hoe een succesvolle aanval tot stand komt.
Ransomwareaanval
Doordat we steeds meer inzicht krijgen in de actors (aanvallers) en de getroffen organisaties aangeven welke tactieken en technieken door de actors zijn gebruikt, weten we dat de werkwijze van actors in hoofdlijnen uit twee fases bestaat:
Fase 1: Account compromise
In deze fase zijn er verschillende manieren om een account (gebruiker) te compromitteren (overnemen). Dit kan door (spear)phishing e-mails, gelekte accounts van third-party applicaties of brute force technieken op standaard useraccounts. Hiervoor is een aantal oplossingen beschikbaar en soms zijn deze oplossingen al in gebruik, maar mist men de kennis om ze te benutten.
Fase 2: Domain takeover & persistance
Deze fase begint vanaf het moment dat de actor een account heeft overgenomen in een netwerk. De actor verkrijgt inzicht in wat zich in het netwerk begeeft en begint gevoelige/belangrijke data te exfilteren.
Lateral movement is de techniek waarbij een actor over het netwerk gaat bewegen, wat nodig is voor zijn volgende stap: het verhogen van rechten (Escalation of Privilege). Zo probeert de actor naast de data te exfilteren ook het domein over te nemen (Domain Takeover).
Ook in deze fase zijn er oplossingen die inzicht kunnen geven. Die oplossingen werken anomaly based en dat houdt in dat er wordt gekeken naar afwijkend gedrag waar vervolgens een melding van wordt gemaakt.
Voor een compleet overzicht van tactieken en technieken, klik hier.
Hoe nu verder?
Er zijn in een aanval verschillende momenten waarop een actor gedetecteerd kan worden. Vanuit Access42 geloven we in een SIEMless SOC. Uit ervaring weten wij dat het inrichten van een SIEM, het implementeren van de juiste use cases en het koppelen van de juiste log sources lang kan duren. Door gebruik te maken van het ecosysteem van de verschillende vendoren en door API’s op de juiste manier te koppelen, kunnen wij geautomatiseerde responses genereren. Zo kunnen wij een securityincident snel isoleren en mitigeren en is 24/7 eyes on the screen niet noodzakelijk.
Op het moment dat er een (mogelijke) aanval heeft plaats gevonden, is deze geblokkeerd en wordt hier een melding van gemaakt met alle details. Vervolgens kan de IT security verder te geanalyseerd en/of geoptimaliseerd worden.
Zie onderstaand een aantal voorbeelden om een beeld te krijgen hoe SIEMless SOC in de praktijk werkt:
Use case 1
Een gebruiker ontvangt een e-mail met een url. Deze link is op het moment van versturen legitiem, maar na verloop van tijd wordt de destination waar de url naar verwijst aangepast en wordt de url malicious (schadelijk). Op het moment dat de gebruiker op de url klikt, wordt er ingegrepen en wordt er vervolgens een signaal gegeven aan de e-mail security oplossing dat er een malicious url is gedetecteerd. Vervolgens wordt er gekeken welke personen deze mail (met de url) ook hebben ontvangen.
Use case 2
Een gebruiker is gecompromitteerd doordat hij gebruik maakt van een wachtwoord dat hij voor meerdere applicaties gebruikt. Vanuit deze endpoint verkrijgt de actor inzicht in wat zich in het netwerk begeeft en doet de actor een poging om zich verder te begeven op het netwerk (lateral movement). Vanuit de NDR wordt dit opgemerkt en volgt er een actie richting de endpoint om deze in isolatie te zetten, zodat toegang tot het netwerk niet meer mogelijk is.
Use case 3
Binnen een applicatie wordt gebruik gemaakt van verschillende API koppelingen. Binnen deze API koppelingen worden verdachte activiteiten gedetecteerd, deze activiteiten volgen vanuit één IP. Er wordt direct een activiteit uitgevoerd om binnen de Web Application Firewall (WAF) deze IP te blokkeren.
Bovenstaande use cases beschrijven een ‘mogelijk’ incident die automatisch wordt gemitigeerd, zonder dat er een menselijke handeling is vereist. Hierdoor kan tijd en geld worden bespaard op de resources en het analyseren van het incident en kan, waar mogelijk, de IT security geoptimaliseerd worden.
Vanzelfsprekend staan we vanuit Access42 klaar om te adviseren wat het meest praktisch is binnen uw organisatie en welke stappen hierin gemaakt kunnen worden.
