De eerste vier uur: een M365-ransomwaresteltijdlijn
Als SharePoint om 09:47 begint te versleutelen, worden de volgende 240 minuten bepaald door beslissingen van maanden geleden — hier is het runbook, minuut voor minuut.
09:47 op een dinsdag: je monitoring signaleert massale bestandswijzigingen in SharePoint. Om 09:52 melden gebruikers Teams-bestanden die niet openen. Ergens in je tenant versleutelt een gecompromitteerd account op machinesnelheid via legitieme API's. Wat er de komende vier uur gebeurt, hangt vrijwel volledig van één ding af: of de respons een geoefende procedure is of een improvisatie.
Dit artikel ís die procedure — een tijdgebonden runbook van T0 (detectie) tot T+240 minuten, met roltoewijzingen en documentatiemomenten. Het bestaat omdat Microsofts shared responsibility-model het herstel vierkant bij jou legt: Microsoft houdt het platform draaiende terwijl jouw data erop versleuteld wordt, en de 72-uursklok van de AVG plus de 24-uurs vroegtijdige waarschuwing van NIS2 beginnen te tikken, hoe voorbereid je ook was.
De misvatting om als eerste af te voeren: "we zien wel als het zover is." Ransomwarerespons heeft te veel parallelle werkstromen — indamming, forensiek, herstel, communicatie, meldingen — voor realtime uitvinden. Teams die improviseren verliezen uren aan vragen die een runbook in seconden beantwoordt.
T0–T15: detecteren, verklaren, isoleren
De openingsfase heeft één doel: de verspreiding stoppen, op gegrond vermoeden, zonder te wachten op perfecte informatie.
De eerste vijftien minuten, afgebakend
T0–T3 — Verklaren en activeren. De dienstdoende lead bevestigt de indicatoren (massale versleuteling, afwijkende beheeractiviteit, EDR-alerts over laterale beweging), verklaart het incident en roept het responsteam op: M365-/Entra-beheerders, security, juridisch, communicatie. Leg het exacte detectietijdstip vast — het verankert elke melding die volgt.
T3–T8 — Toegang afsnijden. Schakel verdachte accounts uit, trek actieve sessies en refresh tokens in via conditional access, en isoleer betrokken endpoints via je EDR-tooling. Handel op gegrond vermoeden; een false positive kost minuten, aarzeling kost bibliotheken.
T8–T15 — Omvang bepalen. Bevraag de unified audit logs en aanmeldlogs: welke mailboxen, sites, Teams en OneDrives zijn geraakt, vanuit welke accounts, sinds wanneer. Rangschik op bedrijfskritikaliteit en open het gedeelde, getimestampte incidentlog — je latere auditspoor.
T15–T60: intrekken, bewaren, beginnen met herstellen
T15–T25 — Credentialhygiëne in de diepte. Forceer wachtwoordresets op beheerders- en hoogwaardige accounts, trek OAuth-tokens en verdachte app-registraties in, controleer bevoorrechte rollen op onbekende service principals en dwing MFA tenant-breed af waar gaten zitten. Aanvallers planten persistentie; deze stap graaft die uit.
T25–T40 — Bewaren vóór repareren. Exporteer mailboxauditlogs, SharePoint-versiegeschiedenissen en aanmeldrapporten; trigger een immutable snapshot van de gecompromitteerde staat in je back-upplatform. Dit bewijs draagt de verzekeringsclaim, de eventuele aangifte en het NIS2-/AVG-dossier — en hoort onder de AVG binnen de EER te blijven, precies waar een EU-gehoste Microsoft cloudback-up zich dubbel terugverdient.
T40–T60 — Eerste restores. Identificeer de vijf meest kritieke Teams en SharePoint-sites en zet ze terug naar het laatst bekende schone punt via je onafhankelijke back-up. Valideer door echte documenten te openen. Let op wat deze stap veronderstelt: ransomware-operators wissen routinematig eerst prullenbakken en versiegeschiedenissen, dus de native tools zijn meestal al weg — de herstelroute die werkt, is die buiten de tenant.
T60–T240: volledig herstel en verharding
T60–T120 — Breed herstel. Zet de resterende mailboxen en OneDrive-accounts terug in volgorde van bedrijfsprioriteit, en speur onderweg naar aanvallersresten: verborgen inboxregels, doorstuurconfiguraties, onbekende gemachtigden. Verwijder indicators of compromise tijdens het herstellen, niet erna.
T120–T180 — Deuren sluiten. Schakel legacy-authenticatie uit, herzie conditional access en externe deelinstellingen, beperk gasttoegang en activeer geavanceerde dreigingsbescherming waar die ontbreekt. Log elke wijziging — onder de NIS2-richtlijn is dit verhardingsdossier bewijs van zorgplicht, en je incidentrapport zal ernaar verwijzen.
T180–T240 — Valideren en afschalen. Test herstelde workloads end-to-end (authenticatie, rechten, bestandsintegriteit, een live Teams-gesprek), bevestig dat er geen herversleuteling optreedt en plan de evaluatie. Het verschil tussen organisaties die dit punt op uur vier halen versus dag vier is volgens het Cost of a Data Breach Report van IBM in miljoenen te meten — herstelsnelheid is de sterkst beïnvloedbare kostenfactor in het gemiddelde van 4,88 miljoen dollar per datalek in 2024.
Het parallelle spoor: communicatie en meldingen
Terwijl de technische tijdlijn loopt, loopt er een tweede spoor naast. Intern: de eerste vier uur elk uur een bestuursupdate in zakelijke taal (status, verwachte hersteltijd, benodigde acties), daarna dagelijkse samenvattingen. Toezichthouders: NIS2 vereist een vroegtijdige waarschuwing aan je CSIRT/autoriteit binnen 24 uur na kennisname en een incidentmelding binnen 72; de AVG voegt de 72-uursmelding aan de toezichthouder toe wanneer persoonsgegevens risico lopen. Verzekeraar: meld onmiddellijk — de meeste polissen vereisen snelle kennisgeving en veel bieden incidentresponsondersteuning; immutable-back-upbewijs dat herstel zonder losgeldbetaling aantoont, versterkt de claim wezenlijk.
Geen van deze doelgroepen kan wachten tot het technische werk klaar is — precies waarom het runbook communicatie bij T0 aan benoemde niet-technische eigenaren toewijst.
Wat deze tijdlijn veronderstelt — bouw het vóór je het nodig hebt
| Voorwaarde | Waarom de tijdlijn zonder faalt |
|---|---|
| Immutable, onafhankelijke M365-back-up | Herstelpunt op T40 bestaat niet; runbook wordt losgeldonderhandeling |
| Geteste point-in-time restore | Nooit geoefende restores missen de RTO met dagen, niet minuten |
| Benoemde responsrollen | T0–T3 rekt op tot een uur "wie belt wie" |
| Discipline van getimestampt loggen | Geen bewijs voor verzekeraar, NIS2- of AVG-dossier |
| Kwartaallijkse tabletopoefeningen | Elke fase draait de eerste echte keer op halve snelheid |
De eerste twee rijen bouwen is een architectuurbeslissing: een onafhankelijke ransomwarebescherming-laag met immutable, EU-gehoste snapshots, volgens schema restore-getest tot de tijden in dit artikel jouw gemeten cijfers zijn in plaats van ambities.
Conclusie
Een Microsoft 365-ransomware-incident wordt twee keer gewonnen of verloren: één keer in de vier uur na detectie, en één keer in de maanden ervoor — toen je óf immutable onafhankelijke back-ups bouwde, de restores oefende, de rollen toewees en de meldingen voorbereidde, óf niet. De tijdlijn hierboven is bewust onheroïsch: elke stap is gewoon, mits voorbereid. Draai hem dit kwartaal als tabletopoefening, vervang de aangenomen tijden door je gemeten tijden, en de slechtste dinsdag van het jaar wordt een lange maar overleefbare dag. Wil je de herstelgereedheid van jouw tenant tegen deze tijdlijn valideren? We lopen hem graag met je door.
Veelgestelde Vragen
Hoelang duurt het herstel van Microsoft 365 na ransomware?
Met geteste, immutable point-in-time back-ups zijn prioritaire workloads zoals bestuursmailboxen en kritieke SharePoint-sites doorgaans binnen 2–4 uur te herstellen, en een volledige tenant voor een middelgrote organisatie binnen 24–48 uur. Zonder onafhankelijke back-ups — of met back-ups die nooit restore-getest zijn — rekt herstel op tot dagen of weken, en kan het onmogelijk worden als aanvallers native herstelopties zoals prullenbakken en versiegeschiedenis wisten vóór het versleutelen.
Wat moet je als eerste doen als ransomware een Microsoft 365-tenant treft?
Indammen, op gegrond vermoeden: verdachte accounts uitschakelen, actieve sessies en tokens intrekken en betrokken endpoints isoleren — binnen de eerste 15 minuten indien mogelijk. Verklaar tegelijk het incident, activeer het responsteam en start een getimestampt incidentlog, want het detectietijdstip verankert de 72-uursklok van de AVG en de 24-uursklok van NIS2. Bewaar forensisch bewijs (auditlogs, een snapshot van de gecompromitteerde staat) voordat enig herstel begint.
Wat zijn de meldtermijnen na een ransomware-aanval in de EU?
Onder NIS2 moeten entiteiten binnen de reikwijdte binnen 24 uur na kennisname van een significant incident een vroegtijdige waarschuwing indienen bij hun nationale CSIRT of autoriteit, gevolgd door een incidentmelding binnen 72 uur en een eindrapport binnen een maand. Onder de AVG moet een datalek dat risico's voor betrokkenen meebrengt binnen 72 uur bij de toezichthouder worden gemeld. Cyberverzekeringen vereisen doorgaans eveneens onmiddellijke kennisgeving — deze klokken lopen parallel aan het technische herstel, niet erna.