C3RB3R Ransomware op Synology: Oorsprong, herstel en hoe u veilig blijft

C3RB3R-ransomware begon rond 28 oktober 2026 op te duiken op Synology NAS-apparaten, en binnen een dag was het het enige onderwerp op r/synology. Bestanden worden hernoemd met een L0CK3D -extensie (een nul, niet de letter O), en elke map krijgt een read-me3.txt losgeldbericht, en een Tor-portaal vraagt om Bitcoin. De snelste en meest nuttige informatie kwam niet van Engelstalige nieuwssites. Het kwam van Chineestalige fora, waar Synology een enorm gebruikersbestand heeft, en van drie GitHub-repositories geschreven door slachtoffers die hun gegevens daadwerkelijk terugkregen, of bewezen dat het niet kon. Deze gids verzamelt wat er tot nu toe bevestigd is over C3RB3R-ransomware: waar het vandaan kwam, hoe het binnenkomt, het enige herstelpad dat heeft gewerkt, en het back-upontwerp dat wij hanteren zodat een aanval als deze ons een herstel kost in plaats van losgeld.

Update, 31 oktober 2026: Synology heeft het toegangspunt nu definitief vastgesteld. In een e-mail aan klanten op 30 oktober is bevestigd dat C3RB3R ransomware uitsluitend misbruik maakt van de kwetsbaarheid die is verholpen in Synology-SA-24:20, gepatcht in december 2024, en dat de campagne geen verband houdt met de PHP2Shell-kwetsbaarheid die in dezelfde maand is gepatcht. We hebben de eigen vierstappen-checklist van Synology’s toegevoegd, onze interpretatie van waarom de aanvallen precies op dat moment plaatsvonden, en één extra laag die wij gebruiken en waar de meeste eigenaren toch al voor betalen: ransomware-bescherming in Active Insight.

SynoPower Club-punt:Eén slachtoffer in een Chinese NAS-groep had meer dan 50 TB op één apparaat en geen snapshots. De versleutelaar was traag genoeg dat alleen zijn foto's uit 2024 worden getroffen, en die hadden toevallig een koude kopie op een cloudschijf. Een ander verloor vijf jaar aan privé GitLab-repositories, omdat RAID 6 plus drie back-ups zich allemaal op dezelfde machine bevonden. C3RB3R-ransomware versloeg niet hun opslag, het versloeg hun back-upontwerp. Wij draaien onze openbare sites als Docker in Virtual DSM, maken een snapshot van de hele guest vanaf de host, repliceren deze naar een tweede NAS en exporteren deze volgens een schema naar USB en de cloud. Als een guest vanavond wordt versleuteld, rollen we deze terug naar de laatste snapshot en krijgt de aanvaller niets.

Wat is C3RB3R-ransomware?

C3RB3R-ransomware is een Linux-versie van de Cerber-familie, een ransomwarelijn die al sinds 2016 bestaat en al jaren af en toe NAS-apparaten als doelwit heeft. 360 schrijft de golf van oktober 2026 op Synology hieraan toe. Op een geïnfecteerd DSM-apparaat draait de C3RB3R-ransomware-encryptor als een statisch gekoppeld, UPX-gepakt x86-64 binair bestand genaamd libgldHet verwijdert zijn eigen bestand na het starten, dus het actieve proces toont (verwijderd) naast het pad van het uitvoerbare bestand.

Wat u ziet als eigenaar van een apparaat dat is getroffen door C3RB3R-ransomware is consistent in elk rapport:

• Bestanden hernoemd naar naam.ext.L0CK3DSommige rapporten spellen het als LOCK3D, maar de GitHub-analyses vermelden de nul.
• Een losgeldbericht genaamd read-me3.txt in elke versleutelde map, met de kop C3RB3R INSTRUCTIONS.
• Een Tor-pagina met de titel C3rb3r Decryptor. Een screenshot van een slachtoffer toonde 0,03696 BTC (ongeveer US$ 2.952) indien betaald binnen vijf dagen, wat daarna verdubbelt naar 0,07392 BTC (ongeveer US$ 5.904), met een afteller.
• Persistentie via cron-vermeldingen die overeenkomen met /etc/cron.d/synot*, die zichzelf opnieuw aanmaken en in ten minste één geval een DSM-upgrade hebben overleefd.
• Back-upbestanden op hetzelfde volume worden samen met al het andere versleuteld, inclusief Hyper Backup-doelen en databasedumps.

Waar het begon: r/synology en de Chinese fora

C3RB3R-ransomware dook voor het eerst in het Engels op op r/synology, waar slachtoffers rond 28 en 29 oktober 2026 binnen ongeveer een dag van elkaar berichten plaatsten. Binnen enkele uren zeiden lezers dat er elke keer dat ze de subreddit herlaadden een nieuwe thread verscheen. Drie van die threads zijn het waard om volledig te lezen, omdat elke thread een ander onderdeel toevoegt:

• De forensische beschrijving. Een DS918+-eigenaar op DSM 7.2.1-69057 Update 5, met de webinterface bereikbaar vanaf het internet, schakelde het apparaat uit en onderzocht de schijven alleen-lezen op een Proxmox-host. Het DSM-authenticatielogboek bevatte een inlogverzoek waarvan het accountveld geïnjecteerde LD_PRELOAD en LD_DEBUG_OUTPUT -regels plus een gecodeerd shell-commando bevatte, en een bestand onder /etc/cron.dDat komt overeen met de gepubliceerde techniek van CVE-2024-10441. Een 3-2-1-back-up betekende dat de aanval een herstel kostte, geen losgeld. Lees het hier: Nou, het is eindelijk gebeurd. Mijn eerste echte ransomware-incident.
• De gebruiker van alleen Photos. Deze eigenaar geloofde dat DSM up-to-date was en gebruikte alleen Synology Photos, maar UPnP op de router stond aan. Na een modus 2-reset kwamen mappen die onder Snapshot Replication vielen terug. Mappen zonder snapshots niet, en de lokale Hyper Backup USB-schijf werd samen met de NAS versleuteld. Lees het hier: Vanochtend getroffen door c3rb3r-ransomware.
• De QuickConnect-discussie. De oorspronkelijke poster merkte het pas op nadat DSM gedegradeerd was en een herinstallatie de versleutelde bestanden aan het licht bracht. In de reacties zei een andere lezer met een sterk wachtwoord, 2FA en QuickConnect ingeschakeld dat zij ook getroffen waren, en anderen wezen erop dat gebruikers die alleen apps gebruiken de DSM-toegang in QuickConnect volledig kunnen uitschakelen. Lees het hier: Getroffen door C3RB3R-ransomware.

Samen gelezen is het patroon duidelijk. C3RB3R-ransomware had alleen een DSM-inlogpagina nodig die het kon bereiken, niets meer. Wachtwoorden en 2FA hielpen niet, omdat de exploit wordt uitgevoerd vóór de authenticatie. De forensische beschrijving verwoordde het duidelijk: het verzoek bereikte een kwetsbare applicatie, en nog een wachtwoordprompt zou dat niet hebben opgelost.

Het diepere technische werk vond plaats in het Chinees. Slachtoffers in WeChat- en Xiaohongshu-groepen plaatsten losgeldbrieven, vergeleken tijdlijnen en verwezen elkaar naar de GitHub-repositories die hieronder worden behandeld. Een Taiwanese Synology-community op Facebook verzamelde dezelfde herstellinks voor lokale gebruikers. Dat is logisch: Synology is een Taiwanees bedrijf en de grootste gebruikerscommunities zijn Chineestalig, dus dat is waar het grote aantal C3RB3R-ransomwaregevallen, en daarom de snelste patroonherkenning, vandaan kwam.

Synology zelf publiceerde een beveiligingsadvies op 29 oktober 2026, waarin het meldde dat het dreigingsactoren had geïdentificeerd die misbruik maken van een kwetsbaarheid die in december 2024 is gedicht voor verouderde DSM-versies, en iedereen opriep om onmiddellijk bij te werken.

Hoe C3RB3R Ransomware binnendringt

De eerste twee dagen waren er twee mogelijke toegangspunten. Synology heeft sindsdien de oudere bevestigd. In de e-mail van 30 oktober staat dat de aanvallen uitsluitend misbruik maken van de kwetsbaarheid die wordt aangepakt in Synology-SA-24:20, en dat C3RB3R ransomware niets te maken heeft met PHP2Shell. De onderstaande tabel toont beide kandidaten zoals ze werden bediscussieerd, omdat het 360-paar nog steeds het patchen waard is.

	Synology zegt	360 zegt
Advies	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, ongeauthenticeerde remote code execution in de system plugin daemon	CVE-2026-13639 (inloglogica) en CVE-2026-13684 (SCGI), beide CVSS 9.8
Gecorrigeerd	November tot december 2024	18 september 2026
Opgeloste builds	DSM 7.2.2-72806 Update 1, 7.2.1-69057 Update 6, 7.2-64570 Update 4, 7.1.1-42962 Update 7	DSM 7.4-90075, 7.3.2-86009 Update 4, 7.2.2-72806 Update 9, 7.2.1-69057 Update 12

Het forensisch bewijs wijst bij ten minste enkele slachtoffers in de richting van het oudere lek. Het meest gedetailleerde Reddit-verslag koppelde de eigen behouden logs aan de gepubliceerde CVE-2024-10441-exploit, waarbij werd opgemerkt dat Synology dit niet had bevestigd en dat hetzelfde apparaat zich ook onder het SA-26:13-oplossingsniveau bevond. Het soimy-verslag vermeldt dat geheugenlogs van de geïnfecteerde guest wijzen op omgevingsvariabele-injectie via de DSM-inlogplugin, wat overeenkomt met CVE-2024-10441, en dat er enkele dagen voor de uitbraak een openbaar proof of concept op GitHub verscheen dat het inloggebruikersnaamveld misbruikt. Twee van de drie gedocumenteerde reddingsgevallen draaiden op niet-originele hardware met een DS918+-bootloader, waarvan één op DSM 7.2-64570 Update 3, wat precies één update te weinig is voor de CVE-2024-10441-fix. Kloon-hardware kan niet eenvoudig officiële updates uitvoeren, wat het de meest kwetsbare doelgroep maakt.

De praktische conclusie is niet veranderd: update naar een build die beide beveiligingsadviezen dekt, en stop met het blootstellen van DSM aan het internet. Maar één vraag bleef over. Als het lek in december 2024 werd gepatcht, waarom gingen er in oktober 2026 dan binnen twee dagen zo veel systemen af met C3RB3R ransomware, waaronder van eigenaren die dachten dat ze up-to-date waren?

Vroeg geplaatst, op commando afgegaan

Onze lezing, en het is onze eigen interpretatie en niet iets wat Synology officieel heeft verklaard, is dat de inbraak door C3RB3R ransomware en de versleuteling twee afzonderlijke gebeurtenissen zijn. Het bewijs wijst in die richting:

• De backdoor kwam eerst. In het Xiaohongshu-geval hieronder stond er al 37 dagen een backdoor-shell op de NAS en was telnet als root ingeschakeld voordat er ook maar één bestand werd versleuteld.
• Het overleeft updates. De cron-vermeldingen onder /etc/cron.d/synot* herstellen zichzelf, en minstens één slachtoffer vond ze nog steeds aanwezig na een upgrade naar de nieuwste DSM. Updaten dichtte het lek, maar liet de indringer binnen.
• De ontploffingen waren gesynchroniseerd. Met C3RB3R ransomware geïnfecteerde systemen die op verschillende tijdstippen en op verschillende builds waren gecompromitteerd, begonnen binnen ongeveer 48 uur na elkaar te versleutelen.

Dat patroon past bij een kwaadwillende die gedurende maanden C3RB3R ransomware-implantaten op ongepatchte systemen heeft geplaatst en vervolgens op afstand koos wanneer de trekker over te halen. Het moment dat ze kozen was de PHP2Shell-week, toen elke Synology-beheerder druk bezig was met patchen, veel systemen net waren bijgewerkt, en eigenaren zich veilig waanden omdat ze dat hadden gedaan. Synology is er duidelijk over dat PHP2Shell niet de ingang was. Het was de dekking. De les is dat een systeem dat eenmaal ongepatcht is blootgesteld, als gecompromitteerd moet worden beschouwd totdat het gecontroleerd is – precies wat stap één van de checklist van Synology’s u vraagt te doen.

Eerste reactie op C3RB3R Ransomware in 4 stappen

Als u L0CK3D bestanden op dit moment vindt, bepaalt de volgorde van de komende tien minuten of herstel überhaupt mogelijk is. De sleutel die uw bestanden ontgrendelt, bestaat alleen in het actief draaiende C3RB3R ransomware-proces. Een herstart, een kill -9 of een herinstallatie van DSM vernietigt deze.

De opdrachten achter stap 2 en 3 zien er als volgt uit. Lees de repositories alvorens iets uit te voeren, omdat de details afhangen van het binary dat u heeft.

# Stap 2: zoek de encryptor (het uitvoerbare bestand wordt getoond als deleted)

ls -l /proc/*/exe 2>/dev/null | grep deleted

# Bevries het. Gebruik hier nooit kill -9.

kill -STOP <PID>	grep State /proc/<PID>/status # zou T (stopped) moeten tonen	# Zoek naar de persistentie die het terugbrengt	ls -l /etc/cron.d/ | grep synot
Kunt u het ontsleutelen? De drie GitHub-reddingsgevallen	Er bestaat geen universele C3RB3R ransomware-decryptor, en iedereen die er een verkoopt gokt maar wat. Wat wel bestaat zijn drie zorgvuldige casestudies die u precies vertellen wanneer herstel werkt.	Repository	Machine
Resultaat	Waarom	Repository	soimy/c3rb3r-rescue
DSM in een Proxmox VE virtuele machine die GitLab draait	Hersteld	Een kopie van 16 GiB van het guest-RAM bevatte de 48-byte sessiesleutel. GitLab hersteld met 80 projecten en 9.253 LFS-objecten.	De encryptor was ongeveer 30 uur eerder al afgesloten. Volledige RAM- en swap-scans vonden geen sleutel.

De derde repository is de belangrijkste om te lezen, omdat de titel ook de les is: nooit opnieuw opgestart betekent niet dat het herstelbaar is. Waar het om gaat is of het C3RB3R-ransomwareproces nog actief is. Zodra het wordt afgesloten, wist het de sleutelbuffer en is de sleutel verdwenen. Een sleutel die op het ene slachtoffer is hersteld, is bovendien nutteloos op het andere, omdat elke uitvoering een nieuwe sessiesleutel genereert.

Waarom de sleutel alleen in het geheugen aanwezig is

De Benjamin-zlt-analyse legt de bestandsindeling van de C3RB3R-ransomware uit en verklaart zowel waarom dit werkt als waarom het meestal niet werkt.

• Elk bestand krijgt zijn eigen willekeurige ChaCha8-sleutel. Die sleutel is verpakt met een sessiemastersleutel met behulp van AES-256-CBC en opgeslagen in een trailer van 588 bytes aan het einde van het bestand.
• De sessiemastersleutel is 48 bytes: een IV van 16 bytes plus een AES-sleutel van 32 bytes. Deze wordt nooit naar de schijf geschreven. Een globale pointer in het actieve proces wijst ernaar.
• De trailer bevat ook een blob die is verpakt met de openbare sleutel van de aanvaller (RSA-2048), dus zonder het actieve proces kan alleen de aanvaller de sessiesleutel herstellen.
• Niet elk bestand is volledig versleuteld. In een steekproef van 400 bestanden gebruikte ongeveer 56% de gesegmenteerde modus, had 31% alleen de eerste 1 MiB versleuteld en was 13% van begin tot eind versleuteld. Gedeeltelijk versleutelde bestanden zijn nog steeds niet leesbaar, maar een analyse van de footer laat zien wat er over is.

De zwakke plek in C3RB3R-ransomware is dus beperkt en tijdsgebonden: de encryptor bewaart de mastersleutel gedurende de hele sessie in het geheugen. Bevries het terwijl het actief is en u kunt de sleutel eruit halen. Mist u dat venster, dan blijft u over met de blob met de openbare sleutel, die ontworpen is om onbreekbaar te zijn.

Het verhaal van een slachtoffer: 50 TB en geen snapshots

Een gedetailleerd verslag dat op 29 oktober 2026 door de gebruiker 柯基爱好者 op Xiaohongshu is geplaatst, volgt een lid van hun NAS-groep gedurende de nacht. Hij opmerkte het C3RB3R-ransomwarebericht, bevestigde de header C3RB3R INSTRUCTIONS en stond op het punt Bitcoin te kopen voordat de groep hem op de GitHub-cases wees.

Hij gebruikte vervolgens een AI-coderingsassistent via SSH om onderzoek te doen. Deze vond en bevroor de encryptor, waardoor vanaf dat moment niets nieuws meer werd versleuteld. Ook ontdekte het dat een waarschijnlijke backdoor-shell al 37 dagen op de NAS aanwezig was en telnet als root had ingeschakeld, wat betekent dat er meer dan een maand zat tussen de initiële inbraak en de versleuteling. Het schreef een script voor het verzamelen van bewijsmateriaal en wachtte terecht op zijn bevestiging voordat er iets als root werd uitgevoerd.

Zijn geluk was dat C3RB3R-ransomware traag is. Met meer dan 50 TB om te verwerken, had de encryptor pas zijn foto's uit 2024 bereikt, en daarvan stond een externe kopie op een cloudschijf. Hij verplaatste de werkgegevens naar een kleinere NAS en parkeerde het versleutelde volume voor later. Zijn eigen samenvatting was duidelijk: hij had geen snapshots, en met snapshots zou dit eenvoudig op te lossen zijn geweest. Een tweede slachtoffer op X vatte dezelfde les vanaf de andere kant samen: RAID 6 plus drie back-upsets, allemaal op hetzelfde apparaat, allemaal samen versleuteld.

Hoe wij C3RB3R-ransomware uit de buurt van onze back-ups houden

Elk van de bovenstaande verhalen over gegevensverlies heeft dezelfde structuur: de back-ups waren bereikbaar vanaf de gecompromitteerde machine. C3RB3R-ransomware versleutelt alles waar de gecompromitteerde DSM naar kan schrijven, dus de oplossing is om ten minste één kopie te bewaren op een plek waar DSM helemaal niet naar kan schrijven. Dit is hoe wij het doen voor de sites die we hosten, en het sluit aan bij de 3-2-1-1-0-regel.

Regel	Betekenis	Hoe wij het doen
3	Drie kopieën van de gegevens	De actieve VM, een replica op een tweede NAS en een geplande export
2	Twee soorten media	NAS-volumes plus een USB-station en een cloudstation
1	Eén kopie op een externe locatie	Exports gesynchroniseerd naar Google Drive met Cloud Sync
1	Eén kopie offline of onveranderbaar (immutable)	VM-snapshots aan de hostzijde waar de guest niet bij kan, plus de losgekoppelde USB-export
0	Nul fouten bij het herstellen	We herstellen en starten daadwerkelijk op vanaf de replica's wanneer we VM's tussen hosts verplaatsen

Voer Docker uit binnen Virtual DSM, niet op de host

Onze WordPress-containers draaien niet op de fysieke NAS. Ze draaien binnen een Virtual DSM-guest, en de guest wordt beschermd door Virtual Machine Manager op de host. Als C3RB3R-ransomware root-toegang krijgt binnen de guest, hebben ze alleen die guest overgenomen en niets anders. De snapshots van de guest staan op de hostopslag, buiten het bestandssysteem van de guest, zodat ransomware binnen de VM ze niet kan zien, laat staan versleutelen of verwijderen. Herstel is een snapshot-rollback die slechts enkele minuten duurt.

VMM Pro voegt de onderdelen toe die er een echte back-up van maken: een beveiligingsplan dat een snapshot maakt van de VM en deze repliceert naar een tweede NAS in het cluster, zodat een uitgevallen host ook gedekt is. Ons cluster bestaat uit een DS1621xs+ en een DS1525+ die naar elkaar repliceren. We hebben de geplande export en Cloud Sync naar Google Drive apart beschreven, en de vergelijking tussen de gratis VMM en VMM Pro legt uit voor welke onderdelen de licentie nodig is.

Als u Docker rechtstreeks op DSM uitvoert, gebruik dan onveranderbare (immutable) snapshots

Niet iedereen wil een VM-laag. Als uw containers op de host draaien, is de verdediging tegen C3RB3R-ransomware onveranderbare snapshots. Schakel ze in Snapshot Replication in voor de gedeelde map die uw containergegevens bevat. Ze vereisen DSM 7.2 of hoger en een Btrfs-volume, en tijdens de vergrendelingsperiode kan niemand ze verwijderen, inclusief een beheerdersaccount dat door de aanvaller is overgenomen. Twee details maken of breken dit:

• Gebruik bind mounts naar een gedeelde map zoals /volume1/docker/app. Docker named volumes bevinden zich onder /volume1/@docker, wat geen gedeelde map is en waarvan helemaal geen snapshot gemaakt kan worden.
• Dump databases naar een bestand vóór de snapshot. Een snapshot van een actieve MariaDB is een stroomuitvalkopie. Een geplande mysqldump in dezelfde gedeelde map geeft u een schoon herstelpunt dat vervolgens door de snapshot wordt vergrendeld.
• Kies een vergrendelingsperiode die langer is dan een aanvaller stil kan blijven zitten. Het slachtoffer hierboven had 37 dagen een backdoor voordat de versleuteling begon. Zeven dagen onveranderlijke snapshots zouden niet ver genoeg zijn teruggegaan naar een schone staat.

Onze extra laag: Active Insight maakt een snapshot zodra de versleuteling begint

Hier is de laag die de meeste handleidingen over het hoofd zien. Active Insight, de cloudbewakingsdienst van Synology, kan bestandsactiviteit in uw gedeelde mappen in de gaten houden, en zodra het concludeert dat het om ransomware gaat, reageert het zelfstandig. Synology documenteert dit in haar NAS-beveiligingsgids: wanneer er een ransomware-gebeurtenis wordt gedetecteerd, verstuurt Active Insight een gebeurtenismelding en maakt het automatisch een snapshot van de gedeelde map, en op modellen die dit ondersteunen is dat snapshot onveranderbaar (immutable).

Waarom dit in het bijzonder voor C3RB3R ransomware van belang is: de versleutelaar van C3RB3R ransomware is traag. Het slachtoffer met meer dan 50 TB was pas bij zijn foto's uit 2024 toen hij het opmerkte. Een snapshot gemaakt wanneer het versleutelingspatroon voor het eerst verschijnt, bevriest alles wat nog niet is aangeraakt, wat het grootste deel van het volume kan zijn. Het maakt ook niet uit hoe C3RB3R ransomware binnenkwam, want het let op wat er met de bestanden gebeurt, niet op de inlogpagina. Op onze DS1621xs+ toont de pagina Bestandsactiviteit de ransomware-bescherming als Beveiligd.

Lees de beperkingen voordat u erop vertrouwt. Ze zijn afkomstig uit Synology’s Bestandsactiviteit-documentatie:

• Bewaking van bestandsactiviteit staat standaard uit. Registreer de NAS voor Active Insight in het Configuratiescherm en schakel vervolgens de bewaking in voor elke host in het Active Insight-portaal.
• Het heeft Snapshot Replication nodig, DSM 7.2 of hoger, Active Insight 3.0.2 of hoger, ten minste 1 GB geheugen en een Active Insight-licentie toegewezen aan die NAS.
• Maximaal één automatisch snapshot per gedeelde map per dag. Het is een vangnet dat wordt ingezet na detectie, geen vervanging voor geplande onveranderbare snapshots.
• Niet gedekt: Surveillance Station-opnamemappen en gedeelde mappen op externe USB-schijven.
• Onveranderbaarheid is afhankelijk van het model. Op een model zonder onveranderbare snapshots kan een aanvaller met root-rechten het automatische snapshot alsnog verwijderen; combineer dit dus met het bovenstaande schema voor onveranderbare snapshots.

Wilt u dezelfde configuratie? SynoPower Club verkoopt officiële licenties voor beide bouwstenen: een Virtual DSM (VDSM)-licentie om uw Docker-services uit te voeren in een geïsoleerde guest, en een VMM Pro-licentie voor beveiligingsplannen, cross-NAS-replicatie en live migratie. Licentiesleutels worden per e-mail geleverd.

Waar vind je meer officiële bronnen?

C3RB3R-ransomware op Synology is op het moment van schrijven pas twee dagen openbaar bekend en er is nog geen officiële videodekking, dus deze sectie vermeldt primaire bronnen in plaats van handleidingen.

• De Synology-beveiligingswaarschuwing van 29 oktober 2026, waarin gebruikers van verouderde DSM-versies wordt opgeroepen om onmiddellijk te updaten en automatische updates in te schakelen, op 30 oktober gevolgd door een e-mail aan klanten waarin SA-24:20 werd bevestigd als de enige betrokken kwetsbaarheid.
• Synology-SA-24:20 en Synology-SA-26:13 zijn de versietabellen. Controleer uw build in Configuratiescherm, en vervolgens Bijwerken en herstellen, vergelijkend met beide.
• DSM in een Proxmox VE virtuele machine die GitLab draait is de beste index van alle bekende gevallen, inclusief gevallen die hier niet worden behandeld, en de duidelijkste uitleg over wanneer geheugenforensisch onderzoek zinloos is.
• De drie r/synology-threads die hierboven zijn gelinkt, vooral het forensische verslag, dat de stapsgewijze opdrachten voor alleen-lezen schijfonderzoek bevat: Tja, het is eindelijk gebeurd.

De eigen checklist van Synology (30 oktober 2026)

De e-mail van Synology aan klanten eindigt met vier stappen. Ze zijn kort, en elke stap is van belang tegen C3RB3R-ransomware:

1. Controleer op indringers. C3RB3R-ransomware laat geplande persistentie achter, dus voer een Security Advisor-scan uit en zoek vervolgens in Taakplanner naar scripts die u niet zelf hebt gemaakt en in Gebruiker en groep naar beheerdersaccounts die u niet hebt toegevoegd. Als er iets niet klopt, neem dan contact op met Synology Support.
2. Werk alles bij. Installeer de nieuwste DSM via Configuratiescherm, Bijwerken en herstellen, en werk vervolgens elk pakket in het Package Center bij.
3. Schakel automatische updates in in Bijwerken en herstellen, zodat toekomstige beveiligingsoplossingen direct worden toegepast zodra ze uitkomen.
4. Bewaar een off-site back-up. Gebruik Hyper Backup en Snapshot Replication om een kopie op een afzonderlijke locatie te bewaren en controleer regelmatig of de back-uptaken daadwerkelijk worden voltooid.

Stap één is de stap die mensen overslaan. Als uw NAS bereikbaar was vanaf het internet vóór de oplossing van december 2024, heeft C3RB3R-ransomware mogelijk al voet aan de grond, en vandaag bijwerken vertelt u niet of er al iemand binnen is.

Een gratis tool die de controle voor u uitvoert

Als u bekend bent met een terminal, kan stap één nu een enkel commando zijn. synology-nas-cli is een open-source command-line tool onder de MIT-licentie, uitgebracht op 30 oktober 2026 door onafhankelijke ontwikkelaar Akari Sora. Het meldt zich aan bij DSM via de web-API en controleert het systeem op deze campagne. Het project staat op GitHub: akari-sora/synology-nas-cli.

We hebben de code doorgenomen voordat we ernaar linkten. Het gebruikt alleen de standaard Python-bibliotheek en communiceert met niets anders dan uw NAS, de Synology-downloadserver, PyPI en de soimy rescue toolkit. Het verzendt geen telemetrie en de basiscontrole leest alleen. Dit is wat het controleert:

• Patchniveau. Uw DSM-build vergeleken met Synology-SA-26:13, wat ook de oudere SA-24:20-fix omvat, en uw geïnstalleerde pakketten vergeleken met SA-26:14.
• Blootstelling. QuickConnect, UPnP-poortdoorsturing op de router, de DSM-firewall, Automatisch blokkeren, SMB1 en het ingebouwde admin-account.
• Sporen van C3RB3R-ransomware. De geïnjecteerde inlogstrings in het verbindingslogboek, /etc/cron.d/synot* vermeldingen, de libgld en qnetd binaire bestanden, extra root-accounts, SSH-sleutels en losgeldeisen op uw gedeelde mappen.
• Momentopnamen. Gedeelde mappen die geen werkend snapshot-schema hebben.

Het kan ook de meeste dingen die het vindt herstellen. Als er op dit moment bestanden worden versleuteld, bevriest de contain-opdracht de versleutelaar met SIGSTOP, dezelfde actie als stap twee van onze eerste-hulp-lijst. De rescue-opdracht stuurt vervolgens de soimy toolkit aan om het geheugen vast te leggen en te zoeken naar de sleutel.

nas incident                 # alleen-lezen audit

Lees deze opmerkingen voordat u het iets laat wijzigen:

• Het is gloednieuw. Het project is enkele dagen oud, is afkomstig van één enkele ontwikkelaar, is niet gelieerd aan Synology en heeft weinig externe beoordeling gehad. Begin met de alleen-lezen audit en de dry-run.
• De firewall-fix kan u buitensluiten. Het schakelt de DSM-firewall om alles te weigeren behalve de netwerken die u vermeldt. Voer het uit vanaf een computer op hetzelfde LAN en zorg dat u weet waar de RESET-knop zit.
• Het schakelt QuickConnect uit. Dat is de veiligere instelling, maar als uw familie Synology Photos of Surveillance Station bereikt via QuickConnect, stel dan eerst een VPN of Tailscale in.
• De deep scan, contain en rescue worden uitgevoerd als root. Ze werken via een tijdelijke Taakplanner-taak, omdat dat de enige manier is om root-only logboeken te lezen en processen te bevriezen.
• De README suggereert om het over te dragen aan een AI-agent. Als u dat doet, bewaar het wachtwoord dan in een wachtwoordbeheerder in plaats van in de chat, en bevestig de herstelactie zelf.
• Geheugenredding werkt alleen zolang de versleutelaar actief is. Dezelfde regel als bij de drie GitHub-gevallen is van toepassing.

Voor de rest van het beveiligen, onze gidsen over het hosten van een openbare website op een Synology NAS en over wat Threat Prevention wel en niet kan zien behandelen de netwerkzijde, en de PHP2Shell-patchgids behandelt het andere kritieke probleem dat in dezelfde week naar buiten kwam.

C3RB3R Ransomware Beperkingen en Beveiligingsopmerkingen

Updaten verwijdert een bestaande infectie niet. Ten minste één slachtoffer ontdekte dat de cron-persistentie nog steeds aanwezig was na de upgrade naar de nieuwste DSM. Als u bent blootgesteld terwijl u niet was gepatcht, controleer dan /etc/cron.d, de Taakplanner, opstartscripts en ingeschakelde services zoals telnet, en wijzig vervolgens alle inloggegevens.

Up-to-date is niet hetzelfde als schoon. Eén Reddit-slachtoffer dacht dat DSM up-to-date was, en een ander werd getroffen terwijl 2FA en een sterk wachtwoord waren ingesteld. Een NAS die is gecompromitteerd voordat hij werd gepatcht, kan het implantaat meenemen via elke latere update. Beschouw elke DSM-inlogpagina die vanaf het internet bereikbaar is als een doelwit, inclusief pagina's die via UPnP zijn gepubliceerd zonder dat u dit bewust hebt ingesteld. Gebruik een VPN of Tailscale voor toegang op afstand en schakel UPnP uit op de router.

RAID en lokale back-ups zijn geen back-ups tegen C3RB3R-ransomware. Alles waar de gecompromitteerde DSM naar kan schrijven zal worden versleuteld, inclusief Hyper Backup-doelen op hetzelfde apparaat en gekoppelde netwerkschijven.

Betaal niet voordat u de gevallen heeft gelezen. Het betalen van C3RB3R-ransomware-exploitanten financiert de volgende golf en garandeert niets. Als de encryptor nog actief is, is het vrije geheugen uw beste kans. Als dat niet zo is, zijn uw eigen externe back-ups de enige realistische optie.

Wees voorzichtig met wat u in een AI-assistent plakt. AI-tools hebben hier verschillende slachtoffers geholpen, maar geef ze geen wachtwoorden, herstelde sleutels, volledige geheugendumps of bedrijfsgegevens. Laat ze commando's voorstellen en voer alles wat root-rechten vereist zelf uit.

Kloonhardware brengt extra risico met zich mee. Verschillende gedocumenteerde slachtoffers draaiden DSM op niet-officiële hardware, waar officiële updates moeilijk of onmogelijk toe te passen zijn. Als dat uw configuratie is, ga er dan van uit dat u niet bent gepatcht en houd het volledig van het internet.

Referenties

• Synology-beveiligingswaarschuwing over DSM ransomware-aanvallen, 29 oktober 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 en de herstelde DSM-builds.
• Synology-SA-26:13 DSM, CVE-2026-13639 en CVE-2026-13684, gepubliceerd op 18 september 2026.
• Benjamin-zlt C3RB3R ransomware bare-metal herstel, het bestandsformaat, de sleutellay-out en de SIGSTOP-workflow.
• synology-nas-cli door Akari Sora, een open-source audit- en responstool voor deze campagne.
• IT-Connect over de C3RB3R-campagne, met een samenvatting van de 360-attributie en de tijdlijn.
• Synology Knowledge Center: de beveiliging van uw Synology NAS verbeteren, inclusief hoe Active Insight een momentopname van een gedeelde map maakt wanneer het ransomware detecteert.

Veelgestelde vragen

Zorg ervoor dat de volgende C3RB3R-ransomware-aanval u alleen een herstelactie kost, geen losgeld. Voer uw Docker-services uit binnen Virtual DSM en bescherm de gehele guest met VMM Pro-beveiligingsplannen, gerepliceerd naar een tweede NAS. SynoPower Club verkoopt officiële licenties voor beide, met sleutels per e-mail geleverd.