Het probleem is zelden dat je niets ziet
In veel securityteams is het beeld herkenbaar: een endpoint wijkt af, identity laat iets vreemds zien, en pas later blijkt dat die signalen bij elkaar hoorden. Tegen die tijd is de aanval al verder dan comfortabel is voor een softwareorganisatie die ook gewoon door moet leveren.
De actuele Microsoft-analyse over Storm-2570 maakt dat patroon concreet. Volgens Microsoft gebruikt deze ransomware-affiliate consistente post-compromise tools en technieken over meerdere ransomware-ecosystemen heen, waaronder Qilin, DragonForce, Anubis en BERT. Niet één unieke campagne dus, maar herhaalbaar gedrag dat terugkomt in verschillende omgevingen.
Dat is precies waarom dit onderwerp ertoe doet. Namen veranderen, affiliaties verschuiven, tooling wordt aangepast. Maar het gedrag na binnenkomst blijft vaak opvallend consistent. En juist dat gedrag is voor verdedigers waardevoller dan de labeltjes eromheen.
Waarom herhaalbaar gedrag zwaarder weegt dan een bekende naam
Leiders praten over ransomware vaak alsof het vooral een eindfase is: encryptie, verstoring, herstel. Operationeel begint het eerder. De echte vraag is of je de eerste signalen kunt verbinden voordat iemand de situatie omzet in een volwaardig incident.
Dat is lastiger dan het klinkt, omdat die signalen bijna altijd verspreid binnenkomen. Een login die niet past bij het normale patroon. Een tool die niet in het beheerprofiel thuishoort. Laterale beweging die op zichzelf nog net plausibel lijkt. Los gelezen zijn het losse afwijkingen. Samen vormen ze een werkhypothese.
Precies daar gaat het vaak mis in volwassen organisaties. Detectie is per domein ingericht, eigenaarschap ook. Endpoint kijkt naar endpoint. Identity kijkt naar identity. Cloud kijkt naar cloud. Iedereen heeft gelijk binnen zijn eigen scherm, maar niemand heeft automatisch het hele verhaal.
Storm-2570 laat zien waarom dat een zwakke inrichting is. Als dezelfde post-compromise tradecraft terugkomt over meerdere ransomware-varianten, dan is de kern niet welke naam er bovenaan het rapport staat. De kern is dat het gedrag herkenbaar is, en dus eerder te koppelen dan het eindresultaat.
Een herkenbaar teammoment: drie kleine signalen, één grote vertraging
Stel je een SaaS-team voor met een volwassen engineeringorganisatie en een compacte securityfunctie. Niet klein genoeg om alles handmatig te doen, niet groot genoeg om overal specialisten op te zetten.
Op een dinsdag ziet iemand op een endpoint een proces dat niet in de baseline past. Geen spectaculaire alarmbel, wel afwijkend. In dezelfde periode verschijnt in identity een login vanuit een ongebruikelijke context, maar zonder harde blokkade. In de cloudlogs volgt later een beweging die op zichzelf nog niet direct alarm slaat.
Drie signalen, drie eigenaren, drie werkstromen. En dus drie plekken waar het verhaal kan verdwijnen.
Dat is de frictie die softwareleiders vaak onderschatten. Niet omdat teams onzorgvuldig zijn, maar omdat de organisatie is ingericht op domeinen, niet op samenhang. Het gevolg is dat het overleg een opsomming van losse feiten wordt. Iedereen heeft een stukje van de waarheid, maar niemand heeft de prioriteit.
Als niemand expliciet verantwoordelijk is voor de eerste koppeling, wordt detectie een administratieve oefening. Tegen de tijd dat de signalen wel samenkomen, is de vraag niet meer of iemand alert was. Dan is de vraag waarom de organisatie geen mechanisme had om vroeg bewijs te bundelen.
Het echte besluit zit vóór de escalatie
De meeste teams investeren terecht in preventie, response en herstel. Maar die drie werken pas goed als iemand ook eigenaar is van de eerste bewijskoppeling.
Niet als extra taak naast “security”. Wel als expliciete keuze: wie mag zeggen dat drie zwakke signalen samen één werkhypothese vormen? Wie trekt de lijn van endpoint naar identity naar cloud? Wie mag prioriteit opeisen voordat de aanval zich bewijst met encryptie of datadiefstal?
Zonder dat eigenaarschap blijf je reageren op symptomen. Met dat eigenaarschap kun je patronen zien terwijl ze nog bezig zijn zich te vormen.
Dat is ook waarom de Microsoft-analyse van Storm-2570 meer is dan een waarschuwing over ransomware. Het laat zien dat veel verdediging nog steeds rond incidenten is georganiseerd, terwijl aanvallers zich gedragen als herhaalbare operateurs. Zij hoeven niet origineel te zijn. Jij wel, in hoe je bewijs samenbrengt.
Wat hier in de praktijk werkt
De kleinste nuttige interventie is meestal niet een extra tool. Het is een duidelijke afspraak over triage over domeinen heen.
Dat kan heel concreet zijn:
- één persoon of rol die de eerste correlatie mag claimen;
- een vaste drempel voor wanneer losse afwijkingen samen een werkhypothese worden;
- een korte route van endpoint naar identity naar cloud, zodat signalen niet in drie aparte queues blijven hangen;
- een terugkoppeling naar engineering en platformteams, zodat je leert welke patronen structureel terugkomen.
Dat klinkt bescheiden, maar het verandert de economie van detectie. Je stopt met wachten tot een aanval zichzelf bewijst en je gaat eerder werken met waarschijnlijkheid, context en samenhang.
Voor softwarebedrijven is dat belangrijker dan het lijkt. Niet omdat elk signaal meteen kritiek is, maar omdat de kosten van te laat koppelen snel oplopen: meer handwerk, meer ruis, meer verstoring voor teams die al onder druk staan om door te leveren.
Wat Fourlab hier scherp aan vindt
De fout is niet dat teams te weinig security hebben. De fout is dat bewijs nog te vaak per silo wordt beoordeeld, alsof een aanval netjes in één systeem blijft.
Wie software en platformen leidt, moet daarom minder denken in losse alerts en meer in eerste koppelingen. Niet elk team hoeft groter. Wel moet duidelijk zijn wie de eerste samenhang mag claimen en wie daarnaar handelt.
Storm-2570 is daarin geen uitzonderlijk verhaal. Het is een herkenbare reminder dat herhaalbaar gedrag verdedigbaar is, zolang je het vroeg genoeg ziet. En vroeg genoeg zien is zelden een kwestie van meer dashboards. Het is een kwestie van wie het verhaal van die dashboards mag samenvoegen voordat het een incident wordt.