Ransomware bij een kleine organisatie: een casus uitgelegd

Kort antwoord: ransomware begint zelden met een spectaculaire hack. In deze casus begon het met een gewone e-mail met een downloadlink. Eén klik gaf criminelen een voet tussen de deur. Ruim twee maanden later waren vrijwel alle systemen van de organisatie versleuteld – de back-up incluis – en lag er een losgeldeis van vijf cijfers op tafel.

Dit artikel reconstrueert zo’n ransomware-aanval van begin tot eind: hoe de aanvaller binnenkwam, waarom niemand het zag, wat de organisatie tijdens de crisis deed en wat ze daarna anders inrichtte. Onderaan vind je een checklist die je vandaag nog kunt gebruiken, ook als je geen eigen IT-afdeling hebt.

Over deze casus: het verhaal is gebaseerd op een uitgewerkt incidentonderzoek. Namen, sector, locatie, data, bedragen, domeinen, IP-adressen en andere herleidbare details zijn weggelaten of gegeneraliseerd. De aanvalstechnieken en de lessen zijn ongewijzigd.

In het kort

De aanval begon met drie phishingmails die zich voordeden als gedeelde documenten via bekende clouddiensten.
Na de eerste klik zat de aanvaller ruim twee maanden onopgemerkt in het netwerk.
De versleuteling sloeg toe vlak voor een vakantieperiode, toen er weinig mensen opletten.
De back-up was bereikbaar vanuit het netwerk en werd mee versleuteld.
De organisatie betaalde losgeld en kreeg de sleutel – maar dat is geluk, geen strategie.
De echte oorzaak was niet de klik, maar het ontbreken van eigenaarschap, updates, gescheiden back-ups en een incidentplan.

De organisatie: kwetsbaar zonder het te weten

Het slachtoffer was een kleine organisatie met een lange geschiedenis, betrokken medewerkers en een netwerk dat in de loop van de jaren was uitgegroeid tot een flink aantal werkplekken, een eigen mailserver, een databaseserver met administratie en klantgegevens, een webserver, een telefooncentrale en een back-upserver. Alles draaide lokaal, in één gebouw.

Op papier was er best wat geregeld. Er draaide antivirus op alle machines, er stonden twee firewalls, het netwerk was in twee delen gesplitst en de gevoelige administratie stond versleuteld opgeslagen. Er was zelfs een beveiligingsbeleid. Maar bij nader inzien:

Niemand was echt verantwoordelijk voor IT. Beheertaken werden verdeeld over medewerkers die eigenlijk een andere functie hadden.
De antivirus was niet bijgewerkt. Updates waren blijven liggen omdat niemand ze bewaakte.
De firewalls stonden op de fabrieksinstellingen. Er waren geen regels die alleen noodzakelijk verkeer toestonden.
De back-up stond online in hetzelfde netwerk. Wie het netwerk had, had ook de back-up.
Het beveiligingsbeleid was één A4’tje zonder afspraken over toegang, incidenten of thuiswerken.
Er was geen incidentresponsplan en geen afspraak over wie je belt als het misgaat.

Dat is geen verwijt. Het is het normale beeld van veel kleine organisaties: de focus ligt op het werk zelf, en IT ‘doet het gewoon’ – tot het dat niet meer doet. Precies dat maakt ze een aantrekkelijk doelwit.

De aanvalstijdlijn: van één klik naar een versleuteld netwerk

Hieronder de aanval in zeven fasen. Bij elke fase staat wat er gebeurde én welke maatregel de keten op dat punt had kunnen breken. Die tweede kolom is de les van dit artikel.

Fase	Wat er gebeurde	Wat het had kunnen stoppen
1. Phishing dag 0	Een medewerker krijgt een mail: “Zoals besproken, hierbij je documenten – graag tekenen en terugsturen.” De link lijkt naar een bekende clouddienst te gaan, maar verwijst naar een nagemaakt domein.	Herkennen van de signalen: onverwachte bijlage, vage afzender, link die niet klopt. Mailfiltering die nagemaakte domeinen blokkeert.
2. Eerste infectie dag 0	De medewerker verwacht toevallig stukken van een externe partij en klikt. Er wordt een document met een macro geopend dat ongemerkt een downloader installeert: een klein programma dat later meer malware binnenhaalt. De medewerker ziet niets bijzonders.	Macro’s in Office-bestanden van internet standaard blokkeren. Werken zonder beheerdersrechten. Bijgewerkte endpointbeveiliging.
3. Tweede mail dag 1	Een dag later volgt een tweede mail (“bedankt dat je dit voor me wilt regelen, hier is het schema”) met een link naar een nep-bestandsdeelsite. Hij wordt ’s avonds laat geopend. De downloader haalt nu een backdoor en meerdere remote access tools binnen.	Meldcultuur: had iemand de eerste mail gemeld, dan was de tweede herkend. Webfilter dat nieuwe en verdachte domeinen blokkeert.
4. Vastzetten (persistentie) dag 2 en verder	De backdoor nestelt zich in het Windows-register en start bij elke herstart opnieuw. Elke vijftien minuten maakt hij contact met een command-and-controlserver van de aanvaller. Zo houdt de aanvaller toegang, ook als de pc uit is geweest.	Netwerkmonitoring: een pc die elk kwartier naar hetzelfde onbekende adres belt, valt op in de logs – als iemand ze bekijkt.
5. Stil wachten ruim twee maanden	Wekenlang gebeurt er zichtbaar niets. De aanvaller heeft toegang, maar wacht op het juiste moment. Dit is de fase waarin de meeste organisaties het verschil hadden kunnen maken.	Periodiek logs en uitgaand verkeer controleren. Een jaarlijkse externe check. Alerts op nieuwe autostart-items en onbekende remote-access-software.
6. Verkenning en verspreiding vlak voor de vakantie	Via de Windows Installer wordt een nieuw pakket geladen dat een verkenningsscript uitvoert: is deze pc lid van het domein, en heeft de gebruiker beheerdersrechten? Die informatie gaat naar de aanvaller, waarna de malware zich over het netwerk verspreidt.	Minimale rechten (geen dagelijks werk met een beheerdersaccount). Netwerksegmentatie die verspreiding tussen werkplekken en servers beperkt. MFA op beheeraccounts.
7. Versleuteling en afpersing dag X	Werkplekken, servers en de back-up worden versleuteld. Op de schermen verschijnt een losgeldbericht: betaal in bitcoin, dan krijg je een sleutel.	Een offline of onveranderbare back-up die buiten bereik van het netwerk staat, en een getest herstelplan.

De aanvalsketen in zeven fasen. In het kader van MITRE ATT&CK gaat het onder meer om phishing (T1566) en versleuteling voor impact (T1486).

De technieken in deze tijdlijn zijn niet exotisch. Ze staan beschreven in het openbare MITRE ATT&CK-overzicht van phishingtechnieken en onder ‘Data Encrypted for Impact’. Het gaat om bekende, al jaren gebruikte middelen van financieel gemotiveerde criminele groepen die op grote schaal phishing versturen en wachten tot iemand bijt.

Waarom de aanvaller zo lang wachtte

Twee maanden stil in een netwerk klinkt gek, maar het is een bewuste keuze. De aanvaller wil eerst weten hoe het netwerk eruitziet, waar de belangrijke systemen staan en waar de back-up is. En hij kiest een moment waarop de organisatie minimaal kan reageren: een avond, een weekend of – zoals hier – vlak voor een vakantieperiode. Dat betekent ook: de periode tussen klik en versleuteling is je grootste kans. Wie in die weken iets opmerkt, voorkomt de crisis.

Waarom de phishingmails werkten

De mails waren kort, in het Engels, en hadden geen spelfouten die opvielen. Ze speelden in op iets wat de ontvanger toch al verwachtte: documenten van een externe partij en een vraag over een planning. De links leken op die van bekende clouddiensten. Dat is precies hoe effectieve phishing werkt: niet door slim te zijn, maar door normaal te lijken. Lees in phishing herkennen: 7 signalen waar je op let.

De crisis: wat de organisatie deed

Toen de schermen op slot gingen, had de organisatie geen draaiboek. Wat wél goed ging: binnen een dag werd een extern incidentresponsteam ingeschakeld. Hun eerste werk was niet herstellen, maar veiligstellen.

1. Bewijs veiligstellen

Van alle getroffen en nog werkende systemen werden schijfkopieën gemaakt. Van elke kopie werd vooraf en achteraf een hashwaarde berekend, zodat aantoonbaar is dat er niets aan veranderd is. Het onderzoek gebeurde op een kopie van die kopie; het origineel bleef verzegeld. Dat klinkt formeel, maar het bepaalt of je later kunt aantonen wat er gebeurd is – richting verzekeraar, toezichthouder of politie.

2. Het spoor terug volgen

Met de logs van de firewall en de mailserver werd de keten teruggerekend: welke mail, welke klik, welk domein, welk programma, en wanneer. Juist de firewalllogs lieten zien dat één pc al weken elk kwartier contact maakte met een server van de aanvaller. De informatie was er dus al die tijd – alleen keek niemand. Wil je zelf leren hoe dit soort sporen eruitziet? De HTB Sherlocks voor blue-team-forensiek en onze Wireshark-gids voor beginners zijn een goed begin.

3. Datalek melden

Omdat systemen met persoonsgegevens versleuteld waren, was er sprake van een datalek in de zin van de AVG. Ook als er niets wordt weggesluisd: om bestanden te kunnen versleutelen moet een aanvaller er toegang toe hebben gehad. Het NCSC zegt dat letterlijk. De organisatie meldde het lek binnen de termijn van 72 uur bij de Autoriteit Persoonsgegevens en informeerde betrokkenen per e-mail. Een eerste melding mag onvolledig zijn; je kunt later een vervolgmelding doen. Ons stappenplan bij een vermoeden van een datalek loopt dit stap voor stap door.

4. De moeilijkste beslissing: betalen of niet

Het bestuur besloot binnen enkele dagen het losgeld te betalen. De aanvaller leverde daarna een sleutel en na een intensieve controle werkten de systemen weer. Dat klinkt als een goede afloop, maar het is belangrijk dit eerlijk te duiden:

Het NCSC adviseert uitdrukkelijk géén losgeld te betalen: er is geen garantie op een werkende sleutel, sommige slachtoffers krijgen daarna een hogere eis, en je financiert het volgende slachtoffer.
Een werkende sleutel betekent niet dat de aanvaller weg is. Backdoors en gestolen inloggegevens blijven bruikbaar als je het netwerk niet volledig schoonmaakt.
Wie betaalt, staat bekend als iemand die betaalt.
Betaal je toch, meld dat dan aan de politie: betaalgegevens zijn waardevol voor opsporing.

De organisatie had in dit geval weinig keus: er was geen bruikbare back-up meer. Het echte moment van beslissen lag dus maanden eerder, bij de vraag waar de back-up stond. Controleer ook altijd eerst bij No More Ransom of er een gratis ontsleutelaar bestaat voor de variant waarmee je te maken hebt.

5. Aangifte

Achteraf deed de organisatie aangifte en droeg het onderzoeksdossier over aan de autoriteiten. Ze wilde bovendien andere organisaties waarschuwen. Dat laatste is precies waarom dit artikel bestaat.

De rekening

De directe schade liep op tot een bedrag van vijf cijfers: ruwweg twee derde losgeld, de rest externe expertise voor onderzoek, crisisbegeleiding en herstel. Daar komen uren van de directie bij, stress bij medewerkers en de vraag of de organisatie dit financieel zou overleven. Dat het incident in een vakantieperiode viel, beperkte de bedrijfsschade – dat was toeval.

Ter vergelijking: het eenmalig goed inrichten van een gescheiden back-up, het aanzetten van MFA en een paar dagen per maand professioneel beheer kosten een fractie daarvan.

Reken het zelf uit

In het onderzoek werd een eenvoudige risicoberekening gebruikt die elke organisatie kan maken:

SLE (schade per incident) = waarde van wat je kwijt kunt raken × hoeveel ervan getroffen wordt.
ALE (verwachte schade per jaar) = SLE × de kans per jaar.

Een rekenvoorbeeld: 100 werkplekken × € 400 hersteltijd en -kosten per plek, volledig getroffen = € 40.000 per incident. Schat je de kans op één keer per vijf jaar, dan is de ALE € 8.000 per jaar. Dat is het bedrag dat je jaarlijks redelijkerwijs aan preventie kunt besteden – en dan heb je losgeld, reputatieschade en stilstand nog niet meegeteld.

Waarom het echt misging: zes structurele oorzaken

Het is verleidelijk om de schuld bij de medewerker te leggen die klikte. Het onderzoek concludeerde terecht dat van nalatigheid geen sprake was: het was een menselijke fout, en die maakt iedereen een keer. De vraag is waarom één fout tot een totale crisis kon leiden.

Oorzaak	Gevolg in deze casus
Geen eigenaar van IT en security	Niemand bewaakte updates, logs of rechten. Taken waren verdeeld, verantwoordelijkheid niet.
Achterstallig onderhoud	Beveiligingssoftware was niet bijgewerkt en miste daardoor detecties.
Firewalls op standaardinstellingen	Uitgaand verkeer naar onbekende servers werd niet beperkt of gesignaleerd.
Back-up in hetzelfde netwerk	De laatste verdedigingslinie viel tegelijk met de rest.
Weinig bewustzijn en geen meldcultuur	De eerste mail werd niet gemeld, waardoor de tweede niet herkend werd.
Geen incidentplan	Onder tijdsdruk moest alles tegelijk worden bedacht: wie belt wie, wat zetten we uit, melden we, betalen we?

Geen van deze punten is technisch ingewikkeld. Het zijn keuzes over organisatie, niet over dure tools. Valt jouw organisatie onder NIS2, dan zijn de meeste van deze punten bovendien geen advies meer maar een verplichting.

De wederopbouw: wat de organisatie veranderde

Na het herstel stelde de organisatie een verbeterplan op langs de lijnen van ISO 27001/27002. De belangrijkste maatregelen:

Een vaste systeembeheerder met een duidelijk takenpakket: updates, accounts en rechten, back-ups en monitoring.
Een nieuwe back-upstrategie: versleuteld, met een offline kopie die alleen periodiek verbinding maakt, en hersteltests op vaste momenten.
Patchmanagement: een vast ritme voor updates van besturingssystemen, software en beveiligingstools.
Herziene firewalls: alleen noodzakelijk verkeer toegestaan, plus detectie en preventie van verdacht verkeer (IDS/IPS).
Een moderner netwerk: mail en administratie naar de cloud, werkplekken vervangen door eenvoudiger te beheren thin clients, minder apparaten in totaal.
Sterke authenticatie: een wachtwoordbeleid en meervoudige authenticatie op accounts die ertoe doen.
Verplichte awarenesstraining voor iedereen, ook het management, met praktijkvoorbeelden en herhaling.
Een volwaardig beveiligingsbeleid, plus afspraken over thuiswerken, mobiele apparaten, clear desk en IT-inventaris.
Een functionaris gegevensbescherming, omdat die voor dit type organisatie verplicht bleek.
Jaarlijks een externe audit en een incidentresponsplan dat ook wordt geoefend.

Het belangrijkste inzicht uit het verbeterplan: een certificaat of een privacyverklaring beschermt je niet. Wat beschermt, is een organisatie die beveiliging blijft onderhouden, meten en verbeteren.

Checklist: zo voorkom je dat dit jou overkomt

Gebruik deze lijst als nulmeting. Elk punt dat je niet met ‘ja’ kunt beantwoorden, is een schakel die een aanvaller kan gebruiken.

Voorkomen

☐ Er is één persoon of partij eindverantwoordelijk voor IT en beveiliging, en iedereen weet wie dat is.
☐ MFA staat aan op e-mail, VPN, cloudomgevingen en alle beheeraccounts. Waarom MFA bijna altijd wint.
☐ Medewerkers werken dagelijks zonder beheerdersrechten.
☐ Macro’s in Office-bestanden van internet zijn standaard geblokkeerd.
☐ Updates van besturingssystemen, software en beveiligingstools worden op een vast ritme geïnstalleerd en gecontroleerd. Lees ook heb je nog antivirus nodig?.
☐ Firewalls staan niet op de fabrieksinstellingen: alleen noodzakelijk verkeer is toegestaan.
☐ Het netwerk is gesegmenteerd: werkplekken kunnen niet zomaar bij servers en back-ups.
☐ Iedereen krijgt herhaalde phishingtraining, inclusief het management. Zie phishing herkennen en ook ClickFix-aanvallen en helpdeskfraude.
☐ Wachtwoorden zijn uniek en sterk, bij voorkeur via een wachtwoordmanager. Zo maak je een sterk wachtwoord.

Detecteren

☐ Er is een laagdrempelige manier om verdachte mails te melden, en melden wordt beloond in plaats van afgestraft.
☐ Logs van firewall, mail en endpoints worden bewaard én bekeken, of er is een dienst die dat voor je doet.
☐ Je krijgt een melding bij onbekende remote-access-software, nieuwe autostart-items of terugkerend verkeer naar onbekende adressen.
☐ Minstens één keer per jaar kijkt een externe partij mee.

Herstellen

☐ Je volgt de 3-2-1-regel voor back-ups: drie kopieën, twee soorten opslag, één offline of onveranderbaar.
☐ Je hebt het afgelopen kwartaal een hersteltest gedaan en weet hoe lang herstel duurt.
☐ Er ligt een incidentresponsplan op papier, ook offline beschikbaar. Het NCSC-incidentresponsplan voor ransomware is een goed sjabloon.
☐ Je weet wie je belt: IT-partij, incidentresponsteam, verzekeraar, juridisch adviseur.
☐ Je weet hoe je een datalek binnen 72 uur meldt en hebt een datalekregister.
☐ Je hebt vooraf besproken hoe je omgaat met een losgeldeis – niet pas als het scherm rood is.

Gebeurt het nu? De eerste vijf stappen

Zie je nu een losgeldbericht of vergrendelde bestanden? Dan in deze volgorde:

Isoleer getroffen apparaten: netwerkkabel eruit, wifi uit. Zet ze niet uit – het geheugen kan bewijs bevatten.
Schakel hulp in: je IT-partij of een incidentresponsteam. Ga niet zelf zitten opruimen.
Leg vast: foto van het losgeldbericht, tijdstippen, wat je hebt gezien en gedaan.
Beoordeel het datalek en meld binnen 72 uur bij de Autoriteit Persoonsgegevens als dat nodig is.
Doe aangifte bij de politie, ook als je niet betaalt.

Uitgebreider: bestanden vergrendeld door ransomware: wat nu? en ransomware uitgelegd.

Veelgestelde vragen

Hoe begint een ransomware-aanval meestal?

Heel vaak met phishing: een mail met een link of bijlage die malware installeert. Andere veelgebruikte ingangen zijn gestolen inloggegevens zonder MFA en niet-gepatchte systemen die vanaf internet bereikbaar zijn. De versleuteling zelf is meestal de laatste stap, niet de eerste.

Hoe lang zit een aanvaller in het netwerk voordat de ransomware toeslaat?

Dat verschilt van uren tot maanden. In deze casus zat er ruim twee maanden tussen de eerste klik en de versleuteling. Die periode is je beste kans om de aanval te ontdekken, bijvoorbeeld via afwijkend netwerkverkeer of onbekende software.

Is ransomware altijd een datalek?

Als er persoonsgegevens zijn versleuteld, is er volgens het NCSC en de AVG sprake van een datalek: de aanvaller heeft toegang gehad en de beschikbaarheid is aangetast. Of je het moet melden bij de Autoriteit Persoonsgegevens, hangt af van het risico voor betrokkenen. Registreren in je datalekregister moet altijd.

Moet je losgeld betalen bij ransomware?

Het advies van het NCSC en de politie is: niet betalen. Er is geen garantie dat je je gegevens terugkrijgt, de aanvaller kan nog in je netwerk zitten en je loopt kans op een tweede afpersing. De beste verzekering tegen die keuze is een offline back-up die je hebt getest.

Waarom is een back-up niet genoeg als die in het netwerk staat?

Omdat ransomware alles versleutelt wat het kan bereiken. Een back-up die altijd verbonden is, wordt gewoon mee versleuteld, zoals in deze casus gebeurde. Minstens één kopie moet offline of onveranderbaar zijn.

Zijn kleine organisaties echt een doelwit?

Ja. Veel aanvallen zijn niet gericht op één organisatie, maar op iedereen die op een phishingmail reageert. Kleine organisaties hebben minder beveiliging en betalen vaker uit nood, wat ze voor criminelen aantrekkelijk maakt. Meer achtergrond in ons overzicht van het cyberdreigingslandschap.

Verder lezen

Bronnen: NCSC – Wat te doen bij een ransomware-aanval; NCSC – Incidentresponsplan ransomware; Autoriteit Persoonsgegevens – Zo meldt u een datalek; No More Ransom; MITRE ATT&CK T1566; MITRE ATT&CK T1486.