Qilin-ransomware: de aanvalsketen stap voor stap en waar je hem onderbreekt

Ransomware komt zelden binnen als een bestand dat ineens alles versleutelt. Tussen de eerste toegang en het losgeldbericht zitten vaak dagen tot weken waarin een aanvaller rondkijkt, wachtwoorden verzamelt, beveiliging uitschakelt en data wegsluist. Elke stap daarin laat sporen na, en dus ook een kans om in te grijpen.

Qilin is een goed voorbeeld om dat langs te lopen. De groep werkt als ransomware-as-a-service: een kern ontwikkelt de tooling, affiliates voeren de aanvallen uit. Volgens Barracuda claimde Qilin in 2025 meer dan duizend slachtoffers op de leaksite, met in de tweede helft van het jaar meer dan veertig per maand. Het Center for Internet Security noemt de groep in het tweede kwartaal van 2025 de actiefste ransomware tegen Amerikaanse lokale en regionale overheden, met zorg als een van de getroffen sectoren.

Voor de zorg is dat geen abstract risico. Bij Covenant Health hadden aanvallers volgens het onderzoek van 18 tot ongeveer 26 mei 2025 toegang tot de IT-systemen. Het gaat om de gegevens van 478.188 mensen, waaronder dossiernummers, verzekeringsgegevens en behandelinformatie. Op sommige locaties konden laboratoria tijdelijk alleen nog met papieren orders werken. Qilin claimde de aanval uiteindelijk. Hoe de aanvallers binnenkwamen, staat niet in de berichtgeving.

Wat dit artikel wel en niet is

De technische keten hieronder komt uit de analyse van Cisco Talos van 26 oktober 2025, die meerdere Qilin-incidenten naast elkaar legt. Twee kanttekeningen:

• Talos beschrijft meerdere zaken, uitgevoerd door verschillende affiliates. Niet elke stap komt in elke aanval voor, en de volgorde verschilt.
• Wat in de bron staat, markeer ik als feit. De koppeling naar logbronnen en de adviezen verderop zijn mijn eigen analyse en geen bevinding van Talos.

Stap 1: binnenkomen

Talos kon in de onderzochte zaken niet met zekerheid vaststellen hoe de aanvallers binnenkwamen. In sommige gevallen was er, met gematigde zekerheid, sprake van beheerdersgegevens die op het dark web waren gelekt en waarmee werd ingelogd op een VPN. In één zaak zag Talos ongeveer twee weken na het lekken van de gegevens veel NTLM-pogingen tegen de VPN, die geen MFA had. Vanaf de VPN volgden RDP-verbindingen naar de domeincontroller en een eerste host. Het causale verband is niet bewezen, maar het patroon is duidelijk.

Het CIS noemt daarnaast andere routes die bij Qilin-incidenten voorkwamen: phishing, misbruik van publiek bereikbare applicaties (genoemd worden FortiGate, CVE-2024-21762 en CVE-2024-55591, en SAP NetWeaver, CVE-2025-31324), RDP, en in één geval het phishen van ScreenConnect-beheerdersgegevens bij een managed service provider, waarna de klanten van die provider aan de beurt waren.

Stap 2: verkennen

Zodra ze binnen zijn, willen aanvallers weten waar ze zitten. Talos zag onder meer nltest /dclist (welke domeincontrollers zijn er), net user /domain (welke gebruikers), whoami /priv en tasklist. Dit zijn gewone beheercommando’s, en juist daarom zegt één enkele uitvoering weinig. Het signaal zit in de combinatie en in wie het draait: een beheerder doet dit niet op een willekeurige werkplek om drie uur ’s nachts.

Stap 3: wachtwoorden verzamelen

Dit is volgens Talos een uitgebreide stap. Een met een wachtwoord beveiligd archief bevatte Mimikatz, NirSoft-wachtwoordtools en eigen scripts. Een batchbestand zette de registerwaarde UseLogonCredential van WDigest op 1, waardoor wachtwoorden in leesbare vorm in het geheugen blijven staan, en draaide daarna achtereenvolgens verschillende tools om wachtwoorden uit browsers en uit opgeslagen sessies van onder meer WinSCP, FileZilla, TeamViewer en RDCMan te halen. Het resultaat werd gebundeld en via SMTP naar de aanvaller gestuurd.

Dit is de stap waar één opgeslagen RDP- of FTP-wachtwoord op een beheerwerkstation de toegang tot de rest van het netwerk geeft.

Stap 4: blijven en beveiliging uitschakelen

De aanvallers zorgden dat ze konden terugkomen en dat niemand ze zag:

• Persistentie: een geplande taak TVInstallRestore die bij elke aanmelding als SYSTEM draait en zich voordoet als een TeamViewer-installatie, plus een sleutel in HKLM\...\Run.
• Remote-toegang: vóór de uitrol werden remote-managementtools geïnstalleerd, zoals AnyDesk, ScreenConnect, Chrome Remote Desktop en Windows Quick Assist. Talos kan niet bewijzen dat ze voor laterale beweging dienden. Ze geven wel een tweede ingang die niet via de VPN loopt.
• Rechten: een door de aanvaller gekozen account werd aan de lokale Administrators-groep toegevoegd, RDP werd via het register ingeschakeld (fDenyTSConnections op 0) en er werd een netwerkshare van het hele C:-station aangemaakt met Full Control voor iedereen.
• Beveiliging uitschakelen: versleutelde PowerShell zette AMSI uit en DisableRestrictedAdmin op 0. De EDR werd op meerdere manieren uitgeschakeld: via de eigen uninstaller, met sc stop en met open-source tools, waaronder een kernel-driver die als service werd geregistreerd, gestart en later weer verwijderd.
• Sporen wissen: eventlogs werden gewist, zowel met Mimikatz als met PowerShell.

Stap 5: data stelen

Voor de dubbele afpersing wordt data eerst weggehaald. Talos zag WinRAR om bestanden te bundelen en Cyberduck om ze naar een cloudopslagdienst (Backblaze) te uploaden. Verkeer naar een legitieme clouddienst valt in het netwerkverkeer lastig op, zeker als je alleen op bekende kwaadaardige adressen filtert.

Stap 6: versleutelen

De uitrol begon met voorbereiding. PowerShell haalde alle computers uit Active Directory op en alle eventlogs werden nogmaals gewist. Een encryptor verspreidt zich via PsExec, een tweede versleutelt netwerkshares vanaf één systeem. Schaduwkopieën worden verwijderd met vssadmin Delete Shadows /all /quiet. In VMware-omgevingen verbindt het script met vCenter, zet het HA en DRS uit, wijzigt het het root-wachtwoord van de ESXi-hosts, zet het SSH aan en voert een programma uit op alle hosts.

Dat laatste is het verschil tussen een paar versleutelde servers en een platte virtuele omgeving.

Waar je het ziet

Deze koppeling is mijn analyse: per stap een bron die je al hebt of kunt aanzetten. Voor veel van deze events moet auditing ingeschakeld zijn, anders is er niets om naar te kijken.

Een eenvoudige controle die je vandaag kunt doen, is nagaan of WDigest nergens plaintext-wachtwoorden bewaart, en of er recent logs zijn gewist:

# WDigest: 1 betekent dat wachtwoorden leesbaar in het geheugen blijven
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' `
    -Name UseLogonCredential -ErrorAction SilentlyContinue

# Gewiste logs: Security 1102 en System 104 in de afgelopen 30 dagen
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 1102; StartTime = (Get-Date).AddDays(-30) } -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{ LogName = 'System';   Id = 104;  StartTime = (Get-Date).AddDays(-30) } -ErrorAction SilentlyContinue

Een afwezige waarde is hier normaal (de standaard op moderne Windows-versies staat uit). Een gewist log is daarentegen altijd een reden om te kijken wie het deed.

Met Microsoft Defender for Endpoint kun je de losse commando’s uit stap 2 en 6 combineren, zodat je alarm slaat op een reeks en niet op één commando dat ook een beheerder zou kunnen draaien:

DeviceProcessEvents
| where Timestamp > ago(7d)
| extend Techniek = case(
    FileName =~ "nltest.exe" and ProcessCommandLine has "dclist", "dc-verkenning",
    FileName in~ ("net.exe", "net1.exe") and ProcessCommandLine has_all ("user", "/domain"), "domeingebruikers",
    FileName =~ "whoami.exe" and ProcessCommandLine has "/priv", "rechten-verkenning",
    FileName =~ "vssadmin.exe" and ProcessCommandLine has_all ("delete", "shadows"), "schaduwkopieen-wissen",
    FileName =~ "wevtutil.exe" and ProcessCommandLine has_any ("cl", "clear-log"), "logs-wissen",
    "")
| where Techniek != ""
| summarize Technieken = make_set(Techniek), Aantal = dcount(Techniek),
            Eerste = min(Timestamp), Laatste = max(Timestamp)
        by DeviceName, AccountName, Uur = bin(Timestamp, 1h)
| where Aantal >= 2
| sort by Laatste desc

Verwacht ruis van beheerscripts en van je eigen pentesters. Draai de query eerst in een rustige periode en zet bekende beheeraccounts en -machines apart, voordat je er een alert van maakt.

Waar je kunt ingrijpen

Dit is opnieuw mijn analyse, gebaseerd op wat Talos en het CIS beschrijven. In volgorde van de keten:

1. MFA op elke externe toegang, inclusief VPN. In de zaak die Talos noemt, ontbrak MFA op de VPN. Gelekte beheerderswachtwoorden waren daar direct bruikbaar. Dit is de goedkoopste maatregel met het grootste effect.
2. Weet welke inloggegevens zijn uitgelekt. Een gelekt beheerderswachtwoord is zonder monitoring pas zichtbaar als iemand het gebruikt. Roteer wachtwoorden na een lek en kijk naar NTLM-pogingen tegen je VPN, zoals Talos ze zag.
3. Patch alles wat aan het internet hangt, snel. De genoemde FortiGate- en SAP-kwetsbaarheden zijn precies het soort randapparatuur dat ook in mijn artikel over NetScaler terugkomt.
4. Beperk beheerrechten. Het CIS noemt in het voorbeeldincident een zwak wachtwoord en onnodige beheerrechten als zwakke punten. Een beheerdersaccount dat nergens opgeslagen wachtwoorden of sessies achterlaat, geeft mimikatz weinig om te oogsten.
5. Maak je EDR moeilijk uit te zetten. Gebruik tamper protection waar je EDR dat biedt, en let op een service die verdwijnt of een driver die verschijnt.
6. Beperk wat er geïnstalleerd mag worden. Remote-managementtools zijn legitiem, maar je weet welke je zelf gebruikt. Een applicatiecontrole of een lijst met toegestane tools maakt een onbekende AnyDesk of ScreenConnect meteen een afwijking.
7. Stuur logs weg voordat ze gewist worden. Een aanvaller wist de lokale logs. Wat al naar je SIEM is gestuurd, kan hij niet meer wissen.
8. Bescherm de virtualisatielaag en de back-ups. Beheer vCenter en ESXi vanaf een apart beheernetwerk met eigen accounts, en bewaar back-ups offline of onveranderbaar. Test het terugzetten, want een back-up die niet is getest, is een aanname.
9. Oefen het incidentproces. Voor Nederlandse zorgorganisaties hoort daar de meldplicht uit de Cyberbeveiligingswet bij, met een vroegtijdige waarschuwing binnen 24 uur en een incidentmelding binnen 72 uur (zie NCSC), en het contact met Z-CERT. Een ransomware-aanval in volle gang is niet het moment om het eerste telefoonnummer op te zoeken.

Conclusie

De les van deze keten is dat de versleuteling het laatste en meest zichtbare onderdeel is, niet het eerste. Wie alleen op de ransomware zelf let, grijpt te laat in. De dagen daarvoor zijn vol commando’s die op zichzelf onschuldig lijken: verkennen, wachtwoorden verzamelen, beveiliging uitzetten, logs wissen. Elk daarvan is een moment waarop een vraag als “waarom draait dit hier, onder dit account, op dit tijdstip?” de aanval kan stoppen.

Een kanttekening bij alles wat hierboven staat: Qilin-affiliates wisselen van tooling en methode. Gebruik deze keten als lijst met vragen om je eigen detectie langs te lopen en niet als checklist van indicatoren. Wat Talos in 2025 zag, kan er bij de volgende zaak net anders uitzien.

Bronnen

• Cisco Talos: Uncovering Qilin attack methods exposed through multiple cases (26 oktober 2025)
• Center for Internet Security: Qilin, top ransomware threat to SLTTs in Q2 2025 (11 september 2025)
• Barracuda: Qilin ransomware surges into 2026 (15 januari 2026)
• The Record: Nearly 480,000 impacted by Covenant Health data breach (2 januari 2026)
• NCSC: Meld incidenten onder de Cyberbeveiligingswet (meldplicht)