C3RB3R Ransomware på Synology: Oprindelse, genoprettelse og hvordan du forbliver sikker

C3RB3R-ransomware begyndte at dukke op på Synology NAS-enheder omkring den 28. oktober 2026, og inden for et døgn var det det eneste emne på r/synology. Filer bliver omdøbt med en L0CK3D -filtype (et nul, ikke bogstavet O), og hver mappe får en read-me3.txt løsepengenota, og en Tor-portal beder om Bitcoin. Den hurtigste og mest nyttige information kom ikke fra engelske nyhedssider. Den kom fra kinesisktalende fora, hvor Synology har en kæmpe brugerbase, og fra tre GitHub-repositories skrevet af ofre, der faktisk fik deres data tilbage, eller beviste, at de ikke kunne. Denne guide samler, hvad der er bekræftet om C3RB3R ransomware indtil videre: hvor det kom fra, hvordan det kommer ind, den ene gendannelsesvej, der har fungeret, og det backupdesign, vi kører, så et angreb som dette koster os en gendannelse i stedet for løsepenge.

Opdatering, 31. oktober 2026: Synology har nu fastlagt adgangspunktet. I en e-mail til kunder den 30. oktober bekræftede det, at C3RB3R-ransomware kun udnytter sårbarheden rettet i Synology-SA-24:20, som blev patchet i december 2024, og at kampagnen ikke er relateret til PHP2Shell-sårbarheden, der blev patchet i samme måned. Vi har tilføjet Synology’s egen fire-trins tjekliste, vores fortolkning af, hvorfor angrebene fandt sted, da de gjorde, og et ekstra lag, vi kører, som de fleste ejere allerede betaler for: Active Insight-ransomwarebeskyttelse.

SynoPower Club-punkt:Et offer i en kinesisk NAS-gruppe havde mere end 50 TB på en enkelt enhed og ingen snapshots. Krypteringsprogrammet var langsomt nok til, at kun hans billeder fra 2024 blev ramt, og de havde tilfældigvis en kold kopi på et sky-drev. En anden mistede fem års private GitLab-repositories, fordi RAID 6 plus tre sikkerhedskopier alle lå på den samme maskine. C3RB3R ransomware besejrede ikke deres lagerplads, det besejrede deres backupdesign. Vi kører vores offentlige websteder som Docker i Virtual DSM, tager snapshot af hele gæsten fra værten, replikerer det til en anden NAS og eksporterer det til USB og skyen efter en tidsplan. Hvis en gæst bliver krypteret i nat, ruller vi den tilbage til det seneste snapshot, og angriberen får intet.

Hvad er C3RB3R ransomware?

C3RB3R ransomware er en Linux-version af Cerber-familien, en ransomware-linje, der har eksisteret siden 2016, og som af og til har målrettet sig mod NAS-enheder i årevis. 360 tilskriver bølgen i oktober 2026 på Synology til den. På en inficeret DSM-enhed kører C3RB3R ransomware-krypteringsprogrammet som en statisk linket, UPX-pakket x86-64-binær fil ved navn libgldDet sletter sin egen fil efter start, så den kørende proces viser (slettet) ved siden af sin sti til den eksekverbare fil.

Hvad du ser som ejer af en enhed, der er ramt af C3RB3R ransomware, er ensartet i alle rapporter:

• Filer omdøbt til name.ext.L0CK3DNogle rapporter staver det LOCK3D, men GitHub-analyserne citerer nullet.
• En løsepengenota ved navn read-me3.txt i hver krypterede mappe, med overskriften C3RB3R INSTRUCTIONS.
• En Tor-side med titlen C3rb3r Decryptor. Et screenshot fra et offer viste 0,03696 BTC (ca. 2.952 US$) ved betaling inden for fem dage, som fordobledes til 0,07392 BTC (ca. 5.904 US$) derefter, med en nedtællings-timer.
• Persistens via cron-poster, der matcher /etc/cron.d/synot*, som genopretter sig selv og i mindst ét tilfælde overlevede en DSM-opgradering.
• Backupfiler på samme volumen krypteres sammen med alt andet, herunder Hyper Backup-destinationer og databasedumps.

Hvor det startede: r/synology og de kinesiske fora

C3RB3R ransomware dukkede først op på engelsk på r/synology, hvor ofre opslog inden for ca. et døgn af hinanden omkring den 28. og 29. oktober 2026. Inden for få timer sagde læsere, at der dukkede en ny tråd op, hver gang de genindlæste subredditten. Tre af disse tråde er værd at læse i deres helhed, fordi hver især tilføjer en ny brik:

• Den forensiske gennemgang. En DS918+-ejer på DSM 7.2.1-69057 Update 5, med webgrænsefladen tilgængelig fra internettet, slukkede enheden og undersøgte diskene skrivebeskyttet på en Proxmox-vært. DSM-godkendelsesloggen indeholdt en loginanmodning, hvis kontofelt indeholdt injicerede LD_PRELOAD og LD_DEBUG_OUTPUT -linjer plus en kodet shell-kommando og en fil under /etc/cron.dDet matcher den offentliggjorte CVE-2024-10441-teknik. En 3-2-1-backup betød, at angrebet kostede en gendannelse, ikke løsepenge. Læs det her: Nå, så skete det endelig. Min første rigtige ransomware-hændelse.
• Brugeren, der kun brugte Photos. Denne ejer troede, at DSM var opdateret, og brugte kun Synology Photos, men UPnP på routeren var slået til. Efter en tilstand 2-nulstilling kom mapper dækket af Snapshot Replication tilbage. Mapper uden snapshots gjorde ikke, og det lokale Hyper Backup USB-drev blev krypteret sammen med NAS'en. Læs det her: Ramt af c3rb3r ransomware i morges.
• QuickConnect-diskussionen. Den oprindelige forfatter opdagede det først, efter at DSM blev forringet, og en geninstallation afslørede de krypterede filer. I svarene sagde en anden læser med en stærk adgangskode, 2FA og QuickConnect aktiveret, at de også var blevet ramt, og andre påpegede, at brugere, der kun bruger apps, helt kan slå DSM-adgang fra i QuickConnect. Læs det her: Ramt af C3RB3R ransomware.

Læst i sammenhæng er mønsteret klart. C3RB3R ransomware havde kun brug for en DSM-login-side, den kunne nå, intet andet. Adgangskoder og 2FA hjalp ikke, fordi exploit'en kører før godkendelse. Den forensiske gennemgang udtrykte det helt klart: anmodningen nåede et sårbart program, og endnu en adgangskode-prompt ville ikke have løst det.

Det dybere tekniske arbejde foregik på kinesisk. Ofre i WeChat- og Xiaohongshu-grupper opslog løsesumssedler, sammenlignede tidslinjer og henviste hinanden til de GitHub-repositories, der er dækket nedenfor. Et taiwansk Synology-fællesskab på Facebook indsamlede de samme genoprettelseslinks til lokale brugere. Det giver mening: Synology er en taiwansk virksomhed, og dens største brugerfællesskaber er kinesisktalende, så det var derfra mængden af C3RB3R ransomware-sager – og dermed den hurtigste mønstergenkendelse – kom.

Synology offentliggjorde selv en sikkerhedsmeddelelse den 29. oktober 2026, med meddelelse om, at det havde identificeret trusselsaktører, der udnyttede en sårbarhed, som blev rettet i december 2024, mod forældede DSM-versioner, og opfordrede alle til at opdatere med det samme.

Sådan trænger C3RB3R Ransomware ind

I de første to dage var der to mulige adgangspunkter. Synology har siden bekræftet det ældre af dem. Dets e-mail fra 30. oktober angiver, at angrebene kun udnytter den sårbarhed, der blev håndteret i Synology-SA-24:20, og at C3RB3R-ransomware intet har at gøre med PHP2Shell. Tabellen nedenfor viser begge kandidater, som de blev debatteret, da 360-parret stadig er værd at patche.

	Synology siger	360 siger
Rådgivende	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, uautentificeret fjernafvikling af kode i systemets plugin-dæmon	CVE-2026-13639 (loginlogik) og CVE-2026-13684 (SCGI), begge CVSS 9.8
Rettet	November til december 2024	september 2026
Rettede builds	DSM 7.2.2-72806 Opdatering 1, 7.2.1-69057 Opdatering 6, 7.2-64570 Opdatering 4, 7.1.1-42962 Opdatering 7	DSM 7.4-90075, 7.3.2-86009 Opdatering 4, 7.2.2-72806 Opdatering 9, 7.2.1-69057 Opdatering 12

De retstekniske beviser peger mod den ældre fejl på i det mindste nogle af ofrene. Den mest detaljerede Reddit-gennemgang matchede sine egne overlevende logfiler med det offentliggjorte CVE-2024-10441-exploit, mens det blev bemærket, at Synology ikke havde bekræftet det, og at den samme enhed også var under SA-26:13-rettelsesniveauet. soimy-gennemgangen siger, at hukommelseslogfiler fra den inficerede gæst peger på miljøvariabel-injection gennem DSM-login-pluginet, hvilket stemmer overens med CVE-2024-10441, og et offentligt proof of concept, der misbruger login-brugernavnefeltet, dukkede op på GitHub dage før udbruddet. To af de tre dokumenterede redningssager kørte på uoriginal hardware med en DS918+-bootloader, den ene af dem på DSM 7.2-64570 Update 3, hvilket er præcis én opdatering fra CVE-2024-10441-rettelsen. Klon-hardware kan ikke nemt modtage officielle opdateringer, hvilket gør det til det nemmeste mål i gruppen.

Den praktiske konklusion har ikke ændret sig: opdater til en version, der dækker begge sikkerhedsadvarsler, og stop med at eksponere DSM mod internettet. Men ét spørgsmål stod tilbage. Hvis hullet blev patchet i december 2024, hvorfor udløste så mange enheder C3RB3R-ransomware inden for de samme to dage i oktober 2026, herunder nogle, hvor ejerne troede, at de var fuldt opdaterede?

Placeret tidligt, detoneret på kommando

Vores vurdering, og det er vores egen fortolkning snarere end noget Synology har udtalt, er, at C3RB3R-ransomware-indbruddet og krypteringen er to adskilte hændelser. Beviserne peger i den retning:

• Bagdøren kom først. I Xiaohongshu-sagen nedenfor havde en bagdørsshell ligget på NAS'en i 37 dage og slået telnet til som root, før en eneste fil blev krypteret.
• Den overlever opdateringer. Cron-posterne under /etc/cron.d/synot* genopretter sig selv, og mindst et offer fandt dem stadig til stede efter opgradering til den nyeste DSM. Opdateringen lukkede hullet, men efterlod indtrængeren indenfor.
• Detonationerne var synkroniserede. C3RB3R-ransomware-enheder, der var blevet kompromitteret på forskellige tidspunkter og på forskellige build-versioner, begyndte at kryptere inden for ca. 48 timer af hinanden.

Det mønster passer på en aktør, der har placeret C3RB3R-ransomware-implantater på u-patched enheder over flere måneder og derefter valgte, hvornår aftrækkeren skulle aktiveres fjernstyret. Det øjeblik, de valgte, var PHP2Shell-ugen, hvor enhver Synology-administrator havde travlt med at patche, mange enheder lige var blevet opdateret, og ejerne følte sig trygge, fordi de havde opdateret. Synology gør det klart, at PHP2Shell ikke var vejen ind. Det var dækket. Læren er, at en enhed, der har været eksponeret, mens den var u-patched, bør behandles som kompromitteret, indtil den er kontrolleret, hvilket er præcis, hvad trin ét i Synology’s tjekliste beder dig om at gøre.

Førstehjælp ved C3RB3R Ransomware i 4 trin

Hvis du finder L0CK3D -filer lige nu, afgør rækkefølgen af de næste ti minutter, om gendannelse overhovedet er mulig. Nøglen, der låser dine filer op, findes kun i den kørende C3RB3R ransomware-proces. En genstart, et kill -9 eller en geninstallation af DSM ødelægger den.

Kommandoerne bag trin 2 og 3 ser således ud. Læs repositoryerne igennem før du kører noget, da detaljerne afhænger af, hvilken binær fil du har.

# Trin 2: Find krypteringsprogrammet (dets eksekverbare fil vises som slettet)

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

# Frys det. Brug aldrig kill -9 her.

kill -STOP <PID>	grep State /proc/<PID>/status # bør vise T (stopped)	# Søg efter den vedholdenhed (persistence), der bringer det tilbage	ls -l /etc/cron.d/ | grep synot
Kan du dekryptere det? De tre redningssager fra GitHub	Der findes intet universelt C3RB3R ransomware-dekrypteringsværktøj, og alle, der sælger et, gætter bare. Hvad der findes, er tre omhyggelige casestudier, der fortæller dig præcis, hvornår gendannelse fungerer.	Repository	Maskine
Resultat	Hvorfor	Repository	soimy/c3rb3r-rescue
DSM i en Proxmox VE virtuel maskine, der kører GitLab	Gendannet	En kopi på 16 GiB af gæste-RAM indeholdt sessionsnøglen på 48 byte. GitLab blev gendannet med 80 projekter og 9.253 LFS-objekter.	Krypteringsprogrammet var allerede lukket omkring 30 timer tidligere. Fuldstændige RAM- og swap-scanninger fandt ingen nøgle.

Det tredje repository er det vigtigste at læse, fordi dets titel er dets lektie: aldrig genstartet betyder ikke genoprettelig. Det, der betyder noget, er, om C3RB3R-ransomware-processen stadig kører. Når den først afsluttes, nulstiller den sin nøglebuffer, og nøglen er væk. En nøgle gendannet hos ét offer er også ubrugelig hos et andet, fordi hver kørsel genererer en ny sessionsnøgle.

Hvorfor nøglen kun findes i hukommelsen

Benjamin-zlt-analysen udpensler C3RB3R-ransomwarens filformat, og den forklarer både, hvorfor dette virker, og hvorfor det normalt ikke gør.

• Hver fil får sin egen tilfældige ChaCha8-nøgle. Den nøgle pakkes ind med en sessions-hovednøgle ved hjælp af AES-256-CBC og gemmes i en 588-byte trailer i slutningen af filen.
• Sessions-hovednøglen er på 48 bytes: en 16-byte IV plus en 32-byte AES-nøgle. Den skrives aldrig til disken. En global pointer inde i den kørende proces peger på den.
• Traileren indeholder også en blob indpakket med angriberens offentlige nøgle (RSA-2048), så uden den kørende proces kan kun angriberen genoprette sessionsnøglen.
• Ikke alle filer krypteres fuldstændigt. I en stikprøve på 400 filer brugte ca. 56% segmenteret tilstand, 31% havde kun den første 1 MiB krypteret, og 13% var krypteret fra ende til anden. Delvist krypterede filer er stadig ikke læsbare, men triage af footeren fortæller dig, hvad der er tilbage.

Så svagheden i C3RB3R-ransomware er snæver og tidsbegrænset: krypteringsprogrammet beholder hovednøglen i hukommelsen under hele sessionen. Frys det, mens det kører, og du kan trække nøglen ud. Misser du det vindue, står du tilbage med den offentlige nøgle-blob, som er designet til at være ubrydelig.

En historie fra et offer: 50 TB og ingen snapshots

En detaljeret beretning slået op på Xiaohongshu den 29. oktober 2026 af brugeren 柯基爱好者 følger et medlem af deres NAS-gruppe gennem natten. Han bemærkede C3RB3R-ransomware-noten, bekræftede C3RB3R INSTRUCTIONS-overskriften og var tæt på at købe Bitcoin, før gruppen henviste ham til GitHub-sagerne.

Han brugte derefter en AI-kodningsassistent over SSH til at undersøge sagen. Den fandt og frossede krypteringsprogrammet, så intet nyt blev krypteret efter dette tidspunkt. Den fandt også ud af, at en sandsynlig bagdørs-shell havde ligget på NAS'en i 37 dage og havde aktiveret telnet som root, hvilket betyder, at det indledende indbrud og krypteringen skete med mere end en måneds mellemrum. Den skrev et bevisindsamlingsscript og ventede korrekt på, at han bekræftede, før den kørte noget som root.

Hans held var, at C3RB3R-ransomware er langsom. Med mere end 50 TB at tygge igennem var krypteringsprogrammet kun nået til hans 2024-fotos, og dem havde han en kold kopi af på et cloud-drev. Han flyttede arbejdsdata til en mindre NAS og parkerede den krypterede volumen til senere. Hans egen konklusion var kontant: han havde ingen snapshots, og med snapshots ville dette have været nemt at rette. Et andet offer på X opsummerede den samme lektie fra den anden side: RAID 6 plus tre sikkerhedskopisæt, alle på den samme boks, alle krypteret sammen.

Hvordan vi holder C3RB3R-ransomware væk fra vores sikkerhedskopier

Enhver historie om tabte data ovenfor har samme mønster: sikkerhedskopierne var tilgængelige fra den maskine, der blev kompromitteret. C3RB3R-ransomware krypterer alt, hvad den kompromitterede DSM kan skrive til, så løsningen er at opbevare mindst én kopi et sted, hvor DSM overhovedet ikke kan skrive. Dette er måden, vi gør det på for de websteder, vi hoster, og det passer med 3-2-1-1-0-reglen.

Regel	Betydning	Hvordan vi gør det
3	Tre kopier af dataene	Den aktive VM, en replika på en anden NAS og en planlagt eksport
2	To slags medier	NAS-volumener plus et USB-drev og et cloud-drev
1	Én kopi off-site	Eksporter synkroniseret til Google Drive med Cloud Sync
1	Én kopi offline eller uforanderlig	VM-snapshots på værtssiden, som gæsten ikke kan røre, plus den frakoblede USB-eksport
0	Nul fejl ved genopretning	Vi genopretter og starter faktisk fra replikaerne, når vi flytter VM'er mellem værter

Kør Docker inde i Virtual DSM, ikke på værten

Vores WordPress-containere kører ikke på den fysiske NAS. De kører inde i en Virtual DSM-gæst, og gæsten er beskyttet af Virtual Machine Manager på værten. Hvis C3RB3R-ransomware får root inde i gæsten, ejer de den gæst og intet andet. Snapshots af gæsten ligger på værtens lagerplads, uden for gæstefilsystemet, så ransomware inde i VM'en kan ikke se dem, end sige kryptere eller slette dem. Genopretning er et snapshot-rollback målt i minutter.

VMM Pro tilføjer de dele, der gør det til en rigtig sikkerhedskopi: en beskyttelsesplan, der tager snapshot af VM'en og replikerer den til en anden NAS i klynget, så en død vært også er dækket. Vores klynge er en DS1621xs+ og en DS1525+, der replikerer til hinanden. Vi har beskrevet planlagt eksport og Cloud Sync til Google Drive -delen separat, og sammenligningen mellem gratis VMM og VMM Pro forklarer, hvilke dele der kræver licensen.

Hvis du kører Docker direkte på DSM, skal du bruge uforanderlige snapshots

Ikke alle ønsker et VM-lag. Hvis dine containere kører på hosten, er uforanderlige snapshots forsvaret mod C3RB3R-ransomware. Slå dem til i Snapshot Replication for den delte mappe, der indeholder dine containerdata. De kræver DSM 7.2 eller nyere og en Btrfs-volumen, og i låseperioden kan ingen slette dem, heller ikke en administratorkonto, som angriberen har overtaget. To detaljer er helt afgørende:

• Brug bind-mounts i en delt mappe såsom /volume1/docker/app. Navngivne Docker-volumes ligger under /volume1/@docker, som ikke er en delt mappe, og som der slet ikke kan tages snapshot af.
• Dump databaser til en fil før snapshottet. Et snapshot af en kørende MariaDB er som en kopi ved strømsvigt. Et planlagt mysqldump i den samme delte mappe giver dig et rent genoprettelsespunkt, som øjebliksbilledet derefter låser.
• Vælg en låseperiode, der er længere end den tid, en angriber kan sidde stille. Offeret ovenfor havde en bagdør i 37 dage, før krypteringen startede. Syv dages uforanderlige øjebliksbilleder ville ikke have rækket tilbage til en ren tilstand.

Vores ekstra lag: Active Insight tager et snapshot, når krypteringen starter

Her er det lag, de fleste guides overser. Active Insight, Synology skyovervågningstjenesten, kan overvåge filaktivitet på dine delte mapper, og når den vurderer, at den ser ransomware, reagerer den af sig selv. Synology dokumenterer det i sin NAS-sikkerhedsguide: når der registreres en ransomware-hændelse, sender Active Insight en hændelsesmeddelelse og tager automatisk et snapshot af den delte mappe, og på modeller, der understøtter det, er det snapshot uforanderligt.

Hvorfor dette har særlig betydning for C3RB3R-ransomware: C3RB3R-ransomware-krypteringen er langsom. Offeret med mere end 50 TB var kun nået til sine 2024-billeder, da han opdagede det. Et snapshot taget, når krypteringsmønsteret første gang vises, fastfryser alt, der endnu ikke er berørt, hvilket kan være størstedelen af diskenheden. Det er også ligeglad med, hvordan C3RB3R-ransomware kom ind, fordi det overvåger, hvad der sker med filerne, ikke login-siden. På vores DS1621xs+ viser siden Filaktivitet ransomware-beskyttelsen som Beskyttet.

Læs begrænsningerne, før du forlader dig på det. De stammer fra Synology’s dokumentation til Filaktivitet:

• Overvågning af filaktivitet er som standard slået fra. Registrer NAS'en til Active Insight i Kontrolpanel, og aktiver derefter overvågning for hver vært i Active Insight-portalen.
• Det kræver Snapshot Replication, DSM 7.2 eller nyere, Active Insight 3.0.2 eller nyere, mindst 1 GB hukommelse og en Active Insight-licens tildelt den pågældende NAS.
• Højst ét automatisk snapshot pr. delt mappe pr. dag. Det er et sikkerhedsnet taget efter registrering, ikke en erstatning for planlagte uforanderlige snapshots.
• Ikke dækket: Surveillance Station-optagelsesmapper og delte mapper på eksterne USB-drev.
• Uforanderlighed afhænger af modellen. På en model uden uforanderlige snapshots kan en angriber med root-rettigheder stadig slette det automatiske snapshot, så kombiner det med den uforanderlige tidsplan ovenfor.

Vil du have den samme opsætning? SynoPower Club sælger ægte licenser til begge byggesten: en Virtual DSM (VDSM)-licens til at køre dine Docker-tjenester i en isoleret gæst, og en VMM Pro licens til beskyttelsesplaner, replikering på tværs af NAS og live migration. Nøgler leveres via e-mail.

Hvor finder man flere officielle ressourcer

C3RB3R-ransomware på Synology har været offentligt kendt i to dage i skrivende stund, og der er endnu ingen officiel videodækning, så dette afsnit lister primære kilder i stedet for gennemgange.

• Synologys sikkerhedsmeddelelse af 29. oktober 2026, som opfordrer brugere af forældede DSM-versioner til at opdatere med det samme og aktivere automatiske opdateringer, fulgt op den 30. oktober af en e-mail til kunder, der bekræfter SA-24:20 som den eneste berørte sårbarhed.
• Synology-SA-24:20 og Synology-SA-26:13 er versionstabellerne. Tjek din build i Kontrolpanel, derefter Opdatering og genoprettelse, i forhold til begge.
• DSM i en Proxmox VE virtuel maskine, der kører GitLab er det bedste indeks over alle kendte tilfælde, herunder dem der ikke er dækket her, og den klareste forklaring på, hvornår hukommelsesefterforskning er formålsløs.
• De tre r/synology-tråde, der er linket til ovenfor, især den retsmedicinske gennemgang, som indeholder kommandoerne til undersøgelse af skrivebeskyttede diske trin for trin: Tja, det skete endelig.

Synology’s egen tjekliste (30. oktober 2026)

Synology’s e-mail til kunder slutter med fire trin. De er korte, og hver eneste af dem har betydning i forhold til C3RB3R-ransomware:

1. Tjek for indtrængere. C3RB3R-ransomware efterlader planlagt persistens, så kør en Security Advisor-scanning, og se derefter i Task Scheduler efter scripts, du ikke selv har oprettet, og i Bruger og Gruppe efter administratorkonti, du ikke selv har tilføjet. Hvis noget ser forkert ud, skal du kontakte Synology Support.
2. Opdater alt. Installer den nyeste DSM i Kontrolpanel, Opdatering og genoprettelse, og opdater derefter alle pakker i Pakkecenter.
3. Slå automatiske opdateringer til i Opdatering og genoprettelse, så fremtidige sikkerhedsrettelser træder i kraft, så snart de udgives.
4. Bevar en off-site-backup. Brug Hyper Backup og Snapshot Replication til at opbevare en kopi på en separat placering, og kontroller regelmæssigt, at backup-opgaverne reelt gennemføres.

Trin et er det, folk springer over. Hvis din enhed kunne nås fra internettet før rettelsen i december 2024, har C3RB3R-ransomware muligvis allerede fået fodfæste, og opdatering i dag fortæller dig ikke, om nogen allerede er inde.

Et gratis værktøj, der kører tjekket for dig

Hvis du er fortrolig med en terminal, kan trin et nu være en enkelt kommando. synology-nas-cli er et open source-kommandolinjeværktøj under MIT-licensen, udgivet den 30. oktober 2026 af den uafhængige udvikler Akari Sora. Det logger ind på DSM via dets web-API og reviderer enheden mod denne kampagne. Projektet findes på GitHub: akari-sora/synology-nas-cli.

Vi gennemlæste dets kode, før vi linkede til det. Det bruger kun Pythons standardbibliotek, og det taler ikke med andet end din NAS, Synology-downloadserveren, PyPI og soimy-redningsværktøjssættet. Det sender ingen telemetri, og den grundlæggende revision læser kun. Dette er, hvad det tjekker:

• Patch-niveau. Din DSM-build mod Synology-SA-26:13, som også dækker den ældre SA-24:20-rettelse, og dine installerede pakker mod SA-26:14.
• Eksponering. QuickConnect, UPnP-port-forwarding på routeren, DSM-firewallen, AutoBlock, SMB1 og den indbyggede admin-konto.
• Spor af C3RB3R ransomware. De indsprøjtede login-strenge i forbindelsesloggen, /etc/cron.d/synot* -poster, libgld og qnetd -binære filer, ekstra root-konti, SSH-nøgler og løsesumsnoter på dine delte mapper.
• Øjebliksbilleder. Delte mapper, der ikke har en fungerende snapshot-tidsplan.

Det kan også rette det meste af det, det finder. Hvis filer krypteres lige nu, fryser dets contain-kommando krypteringen med SIGSTOP, hvilket er det samme træk som trin to på vores førstehjælpsliste. Dets rescue-kommando driver derefter soimy-værktøjssættet til at fange hukommelsen og søge efter nøglen.

nas incident                 # skrivebeskyttet revision

nas incident --deep # søg også efter implantatet (et skrivebeskyttet root-script)

• nas incident fix --dry-run # vis alle ændringer det ville foretage, ændr intet. Læs disse bemærkninger, før du lader det ændre noget:.
• Det er helt nyt. Projektet er et par dage gammelt, kommer fra en enkelt udvikler, er ikke tilknyttet Synology og har kun haft lidt ekstern gennemgang. Start med den skrivebeskyttede revision og prøvekørslen.
• Firewall-rettelsen kan låse dig ude. Det skifter DSM-firewallen til at afvise alt undtagen de netværk, du angiver. Kør det fra en computer på det samme LAN, og vid, hvor RESET-knappen sidder.
• Det slår QuickConnect fra. Det er den sikrere indstilling, men hvis din familie tilgår Synology Photos eller Surveillance Station via QuickConnect, bør du oprette en VPN eller Tailscale først.
• Det dybe scan, contain og rescue køres som root. De fungerer via en midlertidig Opgavestyring-opgave (Task Scheduler), da det er den eneste måde at læse root-begrænsede logfiler og fryse processer på.
• README foreslår at overdrage det til en AI-agent. Hvis du gør det, så gem adgangskoden i en adgangskodeadministrator i stedet for i chatten, og bekræft selv rettelsen.

For resten af sikkerhedshærdningen dækker vores vejledninger om at køre et offentligt websted på en Synology NAS og om hvad Threat Prevention kan og ikke kan se netværkssiden, og patch-vejledningen til PHP2Shell dækker det andet kritiske problem, der opstod i samme uge.

Begrænsninger og sikkerhedsbemærkninger for C3RB3R-ransomware

Opdatering fjerner ikke en eksisterende infektion. Mindst ét offer fandt ud af, at cron-persistensen stadig var til stede efter opgradering til den nyeste DSM. Hvis du var udsat, mens du ikke var patchet, skal du tjekke /etc/cron.d, Opgavestyring, opstartsskripter og aktiverede tjenester som telnet, og derefter udskifte alle adgangsoplysninger.

Opdateret er ikke det samme som ren. Et Reddit-offer troede, at DSM var opdateret, og et andet blev ramt selv med 2FA og en stærk adgangskode aktiveret. En enhed, der blev kompromitteret, før den blev patched, kan bære implantatet med sig gennem enhver senere opdatering. Betragt enhver DSM-login-side, som internettet kan nå, som et mål, herunder dem, der er offentliggjort via UPnP, som du aldrig bevidst har konfigureret. Brug en VPN eller Tailscale til fjernadgang, og slå UPnP fra på routeren.

RAID og lokale sikkerhedskopier er ikke sikkerhedskopier mod C3RB3R-ransomware. Alt, hvad den kompromitterede DSM kan skrive til, vil blive krypteret, inklusive Hyper Backup-destinationer på samme enhed og monterede netværksdelinger.

Betal ikke før du har læst sagerne. Betaling til bagmændene bag C3RB3R-ransomware finansierer den næste bølge og garanterer intet. Hvis krypteringsprogrammet stadig kører, er metoden med ledig hukommelse din bedste chance. Hvis det ikke kører, er de realistiske muligheder dine egne eksterne kopier.

Vær forsigtig med, hvad du indsætter i en AI-assistent. AI-værktøjer hjalp flere ofre her, men giv dem ikke adgangskoder, genoprettede nøgler, komplette hukommelsesdumps eller virksomhedsdata. Lad dem foreslå kommandoer, og kør selv alt, der kræver root.

Klonet hardware medfører ekstra risiko. Flere dokumenterede ofre kørte DSM på uægte hardware, hvor officielle opdateringer er svære eller umulige at installere. Hvis det er din opsætning, må du antage, at du er uopdateret, og holde den helt væk fra internettet.

Referencer

• Synologys sikkerhedsmeddelelse om DSM-ransomware-angreb, 29. oktober 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 og de rettede DSM-builds.
• Synology-SA-26:13 DSM, CVE-2026-13639 og CVE-2026-13684, offentliggjort 18. september 2026.
• Benjamin-zlt C3RB3R-ransomware bare-metal genoprettelse, filformatet, nøglelayoutet og SIGSTOP-arbejdsgangen.
• Hukommelsesredning virker kun, mens krypteringsprogrammet er aktivt., Den samme regel som i de tre GitHub-sager gælder.
• IT-Connect om C3RB3R-kampagnen, der opsummerer 360-tilskrivningen og tidslinjen.
• Synology Knowledge Center: forbedring af sikkerheden på din Synology NAS, herunder hvordan Active Insight tager et snapshot af en delt mappe, når den opdager ransomware.

Ofte stillede spørgsmål

Gør det næste C3RB3R ransomware-angreb til et spørgsmål om genoprettelse, ikke løsesum. Kør dine Docker-tjenester inde i Virtual DSM og beskyt hele gæsten med VMM Pro-beskyttelsesplaner, replikeret til en anden NAS. SynoPower Club sælger ægte licenser til begge med nøgler leveret via e-mail.