C3RB3R Ransomware på Synology: Ursprung, återställning och hur du skyddar dig

C3RB3R-utpressningsprogram började dyka upp på Synology NAS-enheter omkring den 28 oktober 2026, och inom ett dygn var det det enda ämnet på r/synology. Filer byter namn och får ett L0CK3D -tillägg (en nolla, inte bokstaven O), och varje mapp får en read-me3.txt lösepenningnotering, samt att en Tor-portal kräver Bitcoin. Den snabbaste och mest användbara informationen kom inte från engelskspråkiga nyhetssajter. Den kom från kinesiskspråkiga forum, där Synology har en enorm användarbas, och från tre GitHub-databaser skrivna av offer som faktiskt fick tillbaka sina data eller bevisade att det inte gick. Denna guide samlar vad som är bekräftat om C3RB3R ransomware hittills: varifrån det kom, hur det tar sig in, den enda återställningsväg som har fungerat, och den säkerhetskopieringsdesign vi använder så att en sådan attack kostar oss en återställning i stället för en lösepenning.

Uppdatering, 31 oktober 2026: Synology har nu fastställt ingångspunkten. I ett e-postmeddelande till kunder den 30 oktober bekräftade de att C3RB3R ransomware endast utnyttjar sårbarheten som åtgärdades i Synology-SA-24:20, vilken korrigerades i december 2024, och att kampanjen inte har något att göra med PHP2Shell-sårbarheten som korrigerades samma månad. Vi har lagt till Synologys egen checklista i fyra steg, vår tolkning av varför attackerna utlöstes när de gjorde det, samt ett extra skyddslager vi använder som de flesta ägare redan betalar för: Active Insight ransomware-skydd.

SynoPower Club-punkt:Ett offer i en kinesisk NAS-grupp hade över 50 TB på en enda enhet och inga ögonblicksbilder. Krypteringsprogrammet var tillräckligt långsamt så att endast hans foton från 2024 drabbades, och dessa råkade ha en offline-kopia på en molnenhet. En annan förlorade fem års privata GitLab-databaser eftersom RAID 6 plus tre säkerhetskopior alla fanns på samma maskin. C3RB3R ransomware besegrade inte deras lagring, det besegrade deras säkerhetskopieringsdesign. Vi kör våra offentliga webbplatser som Docker inuti Virtual DSM, tar ögonblicksbilder av hela gästen från värden, replikerar den till en sekundär NAS och exporterar till USB och molnet enligt ett schema. Om en gäst blir krypterad i natt rullar vi tillbaka den till den senaste ögonblicksbilden och angriparen får ingenting.

Vad är C3RB3R ransomware?

C3RB3R ransomware är en Linux-variant av Cerber-familjen, en ransomware-serie som funnits sedan 2016 och till och från har riktat sig mot NAS-enheter i åratal. 360 tillskriver vågen mot Synology i oktober 2026 till denna. På en infekterad DSM-enhet körs krypteraren för C3RB3R ransomware som en statiskt länkad, UPX-packad x86-64-binärfil med namnet libgld. Den raderar sin egen fil efter start, så den igångvarande processen visar (borttagen) bredvid sökvägen till den körbara filen.

Det du ser som ägare till en enhet som drabbats av C3RB3R ransomware är detsamma i alla rapporter:

• Filer omdöpta till name.ext.L0CK3D. Vissa rapporter stavar det LOCK3D, men GitHub-analyserna anger nollan.
• En lösepenningnotering med namnet read-me3.txt i varje krypterad mapp, med rubriken C3RB3R INSTRUCTIONS.
• En Tor-sida med titeln C3rb3r Decryptor. En skärmdump från ett offer visade 0,03696 BTC (cirka 2 952 USD) om det betalades inom fem dagar, vilket fördubblades till 0,07392 BTC (cirka 5 904 USD) därefter, tillsammans med en nedräkningsklocka.
• Beständighet via cron-poster som matchar /etc/cron.d/synot*, vilka skapar om sig själva och överlevde en DSM-uppgradering i minst ett fall.
• Säkerhetskopierade filer på samma volym krypteras tillsammans med allt annat, inklusive Hyper Backup-mål och databasdumpar.

Var det började: r/synology och kinesiska forum

C3RB3R ransomware uppmärksammades först på engelska på r/synology, där offer gjorde inlägg inom cirka ett dygn från varandra omkring den 28 och 29 oktober 2026. Inom några timmar uppgav läsare att en ny tråd dök upp varje gång de uppdaterade subredden. Tre av dessa trådar är värda att läsa i sin helhet, eftersom varje tråd bidrar med en ny pusselbit:

• Den forensiska analysen. En ägare av DS918+ med DSM 7.2.1-69057 Update 5, där webbgränssnittet var nåbart från internet, stängde av enheten och undersökte diskarna i skrivskyddat läge på en Proxmox-värd. DSM-autentiseringsloggen innehöll en inloggningsbegäran vars kontofält innehöll injicerade LD_PRELOAD och LD_DEBUG_OUTPUT -rader plus ett kodat skalkommando, samt en fil under /etc/cron.d. Det matchar den publicerade tekniken för CVE-2024-10441. En 3-2-1-säkerhetskopia innebar att attacken kostade en återställning, inte en lösepenning. Läs den här: Tja, det hände till slut. Min första riktiga utpressningsprogramsincident.
• Användaren som bara använde Photos. Denna ägare trodde att DSM var uppdaterat och använde bara Synology Photos, men UPnP var aktiverat på routern. Efter en återställning i läge 2 kom mappar som omfattades av Snapshot Replication tillbaka. Mappar utan ögonblicksbilder gjorde det inte, och den lokala USB-enheten för Hyper Backup krypterades tillsammans med NAS:en. Läs den här: Drabbades av c3rb3r-utpressningsprogram i morse.
• QuickConnect-diskussionen. Den ursprungliga skribenten märkte det först efter att DSM försämrades och en återinstallation avslöjade de krypterade filerna. I svaren uppgav en annan läsare med ett starkt lösenord, 2FA och QuickConnect aktiverat att även de drabbats, och andra påpekade att användare som enbart använder appar helt kan stänga av DSM-åtkomst i QuickConnect. Läs den här: Drabbades av C3RB3R-utpressningsprogram.

Sammantaget är mönstret tydligt. C3RB3R ransomware behövde bara en DSM-inloggningssida som det kunde nå, inget mer. Lösenord och 2FA hjälpte inte, eftersom exploateringen sker före autentiseringen. Den forensiska analysen uttryckte det tydligt: begäran nådde ett sårbart program, och ytterligare en lösenordsprompt hade inte förhindrat det.

Det djupare tekniska arbetet skedde på kinesiska. Offer i WeChat- och Xiaohongshu-grupper lade upp utpressningsmeddelanden, jämförde tidslinjer och hänvisade varandra till de GitHub-arkiv som behandlas nedan. En taiwanesisk Synology-gemenskap på Facebook samlade in samma återställningslänkar för lokala användare. Det är logiskt: Synology är ett taiwanesiskt företag och dess största användargemenskaper är kinesisktalande, så det var där mängden fall av C3RB3R ransomware, och därmed den snabbaste mönsterigenkänningen, kom ifrån.

Synology själva publicerade ett säkerhetsmeddelande den 29 oktober 2026, där de uppgav att de identifierat hotaktörer som utnyttjar en sårbarhet som korrigerades i december 2024 mot föråldrade DSM-versioner, och uppmanade alla att uppdatera omedelbart.

Hur utpressningsprogrammet C3RB3R tar sig in

Under de två första dagarna fanns det två tänkbara ingångspunkter. Synology har sedan dess bekräftat den äldre. I deras e-postmeddelande från den 30 oktober står det att attackerna endast utnyttjar sårbarheten som hanteras i Synology-SA-24:20 och att C3RB3R ransomware inte har någonting med PHP2Shell att göra. Tabellen nedan visar båda kandidaterna så som de debatterades, eftersom båda två fortfarande är värda att korrigera.

	Synology säger	360 säger
Rådgivande	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, oautentiserad fjärrkörning av kod i systemets tilläggsdaemon	CVE-2026-13639 (inloggningslogik) och CVE-2026-13684 (SCGI), båda CVSS 9.8
Korrigerad	November till december 2024	18 september 2026
Åtgärdade versioner	DSM 7.2.2-72806 Uppdatering 1, 7.2.1-69057 Uppdatering 6, 7.2-64570 Uppdatering 4, 7.1.1-42962 Uppdatering 7	DSM 7.4-90075, 7.3.2-86009 Uppdatering 4, 7.2.2-72806 Uppdatering 9, 7.2.1-69057 Uppdatering 12

De tekniska bevisen lutar åt det äldre felet hos i alla fall några av offren. Den mest detaljerade Reddit-rapporten matchade sina egna bevarade loggar med den publicerade exploateringen för CVE-2024-10441, samtidigt som det noterades att Synology inte hade bekräftat det och att samma enhet också låg under korrigeringsnivån för SA-26:13. soimy-rapporten uppger att minnesloggar från den infekterade gästen pekar på injicering av miljövariabler via DSM-inloggningstillägget, vilket stämmer överens med CVE-2024-10441, och ett offentligt "proof of concept" som utnyttjar inloggningsanvändarnamnsfältet dök upp på GitHub några dagar före utbrottet. Två av de tre dokumenterade räddningsfallen kördes på icke-originalhårdvara med en DS918+-bootloader, varav en på DSM 7.2-64570 Update 3, vilket är exakt en uppdatering ifrån korrigeringen för CVE-2024-10441. Klonad hårdvara kan inte enkelt ta emot officiella uppdateringar, vilket gör den till det enklaste målet i populationen.

Den praktiska slutsatsen har inte ändrats: uppdatera till en version som täcker båda säkerhetsmeddelandena och sluta exponera DSM mot internet. Men en fråga kvarstod. Om hålet täpptes till i december 2024, varför drabbades så många enheter av C3RB3R ransomware inom samma två dagar i oktober 2026, inklusive några där ägarna trodde att de var uppdaterade?

Planterades tidigt, detonerades på signal

Vår tolkning, vilket är vår egen bedömning snarare än något Synology har uttalat, är att inbrottet för C3RB3R ransomware och krypteringen är två separata händelser. Bevisen pekar åt det hållet:

• Bakdörren kom först. I Xiaohongshu-fallet nedan hade ett bakdörrsskal funnits på deras NAS i 37 dagar och aktiverat telnet som root innan en enda fil krypterades.
• Den överlever uppdateringar. Cron-posterna under /etc/cron.d/synot* återskapar sig själva, och minst ett offer fann att de fortfarande fanns kvar efter uppgradering till den senaste DSM-versionen. Uppdateringen täppte till hålet men lämnade inkräktaren kvar på insidan.
• Detonationerna var synkroniserade. Enheter med C3RB3R ransomware som komprometterats vid olika tillfällen och på olika versioner började kryptera inom ungefär 48 timmar från varandra.

Det mönstret passar en aktör som planterat implantat för C3RB3R ransomware på ouppdaterade enheter under flera månader och sedan valt när de ska trycka på avtryckaren på distans. Ögonblicket de valde var PHP2Shell-veckan, när alla Synology-administratörer var upptagna med att patcha, många enheter nyss hade uppdaterats och ägarna kände sig säkra för att de gjort det. Synology är tydliga med att PHP2Shell inte var vägen in. Det var täckmanteln. Lärdomen är att en enhet som en gång exponerats medan den var ouppdaterad bör behandlas som komprometterad tills den har kontrollerats, vilket är exakt vad steg ett i Synologys checklista ber dig att göra.

Första åtgärd vid C3RB3R ransomware i 4 steg

Om du hittar L0CK3D -filer just nu, avgör ordningen under de närmaste tio minuterna om återställning överhuvudtaget är möjlig. Nyckeln som låser upp dina filer finns endast i den aktiva C3RB3R ransomware-processen. En omstart, en kill -9 eller en ominstallation av DSM förstör den.

Kommandona bakom steg 2 och 3 ser ut så här. Läs arkiven innan du kör något, eftersom detaljerna beror på vilken binärfil du har.

# Steg 2: hitta krypteraren (dess körbara fil visas som raderad)

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

# Frys den. Använd aldrig kill -9 här.

kill -STOP <PID>	grep State /proc/<PID>/status # bör visa T (stopped)	# Leta efter den beständighet som hämtar tillbaka den	ls -l /etc/cron.d/ | grep synot
Kan du dekryptera det? De tre räddningsfallen på GitHub	Det finns ingen universell dekrypterare för C3RB3R ransomware, och alla som säljer en gissar bara. Det som finns är tre noggranna fallstudier som visar exakt när en återställning fungerar.	Repository	Maskin
Resultat	Varför	Repository	soimy/c3rb3r-rescue
DSM i en virtuell Proxmox VE-maskin som kör GitLab	Återställd	En kopia på 16 GiB av gästens RAM innehöll sessionsnyckeln på 48 byte. GitLab återställdes med 80 projekt och 9 253 LFS-objekt.	Krypteraren hade redan avslutats cirka 30 timmar tidigare. Fullständiga RAM- och swap-skanningar hittade ingen nyckel.

Det tredje arkivet är det viktigaste att läsa, eftersom dess titel är dess läxa: aldrig omstartad betyder inte återställningsbar. Det som spelar roll är om C3RB3R ransomware-processen fortfarande är igång. När den avslutas nollställer den sin nyckelbuffert, och nyckeln är borta. En nyckel som återställs på ett offer är också oanvändbar på ett annat, eftersom varje körning genererar en ny sessionsnyckel.

Varför nyckeln endast finns i minnet

Benjamin-zlt-analysen förklarar filformatet för C3RB3R ransomware i detalj, och den förklarar både varför detta fungerar och varför det oftast inte gör det.

• Varje fil får sin egen slumpmässiga ChaCha8-nyckel. Den nyckeln paketeras med en sessionshuvudnyckel med AES-256-CBC och lagras i en 588-bytes trailer i slutet av filen.
• Sessionshuvudnyckeln är på 48 byte: en 16-byte IV plus en 32-byte AES-nyckel. Den skrivs aldrig till disken. En global pekare inuti den aktiva processen pekar på den.
• Trailern innehåller också en blob paketerad med angriparens offentliga nyckel (RSA-2048), så utan den aktiva processen kan endast angriparen återställa sessionsnyckeln.
• Inte alla filer är helt krypterade. I ett urval på 400 filer använde cirka 56 % segmenterat läge, 31 % hade bara den första 1 MiB krypterad, och 13 % var krypterade från början till slut. Delvis krypterade filer är fortfarande inte läsbara, men footer-triage talar om vad som är kvar.

Så svagheten i C3RB3R ransomware är smal och tidsbegränsad: krypteraren behåller huvudnyckeln i minnet under hela sessionen. Frys den medan den körs så kan du lyfta ut nyckeln. Missar du det fönstret står du kvar med bloben med den offentliga nyckeln, som är utformad för att vara oknäckbar.

En offerberättelse: 50 TB och inga ögonblicksbilder

Ett detaljerat konto publicerat på Xiaohongshu den 29 oktober 2026 av användaren 柯基爱好者 följer en medlem i deras NAS-grupp under natten. Han lade märke till C3RB3R ransomware-anteckningen, bekräftade C3RB3R INSTRUCTIONS-rubriken och var nära att köpa Bitcoin innan gruppen pekade honom på GitHub-fallen.

Han använde sedan en AI-kodningsassistent över SSH för att undersöka. Den hittade och frös krypteraren, så inget nytt krypterades efter den tidpunkten. Den fann också att ett sannolikt bakdörrsskal hade funnits på NAS:en i 37 dagar och hade aktiverat telnet som root, vilket innebär att det initiala inbrottet och krypteringen skedde med mer än en månads mellanrum. Den skrev ett bevisinsamlingsskript och väntade helt korrekt på att han skulle bekräfta innan den körde något som root.

Hans tur var att C3RB3R ransomware är långsamt. Med mer än 50 TB att tugga sig igenom hade krypteraren bara nått hans foton från 2024, och de hade en kalla kopia på en molnenhet. Han flyttade arbetsdata till en mindre NAS och parkerade den krypterade volymen till senare. Hans egen sammanfattning var rak på sak: han hade inga ögonblicksbilder, och med ögonblicksbilder hade detta varit enkelt att fixa. Ett annat offer på X sammanfattade samma läxa från andra sidan: RAID 6 plus tre säkerhetskopior, alla på samma enhet, alla krypterade tillsammans.

Hur vi håller C3RB3R ransomware borta från våra säkerhetskopior

Varje historia om förlorade data ovan har samma mönster: säkerhetskopiorna var nåbara från maskinen som blev kapad. C3RB3R ransomware krypterar allt som den komprometterade DSM kan skriva till, så lösningen är att hålla minst en kopia någonstans där DSM inte kan skriva alls. Så här gör vi för webbplatserna vi är värd för, och det passar in på 3-2-1-1-0-regeln.

Regel	Betydelse	Hur vi gör det
3	Tre kopior av data	Den aktiva VM-instansen, en replik på en sekundär NAS och en schemalagd export
2	Två typer av media	NAS-volymer plus en USB-enhet och en molnenhet
1	En kopia utanför anläggningen	Exporter synkroniserade till Google Drive med Cloud Sync
1	En kopia offline eller oföränderlig (immutable)	Ögonblicksbilder för VM på värdsidan som gästen inte kan komma åt, plus den urkopplade USB-exporten
0	Noll fel vid återställning	Vi återställer och startar faktiskt från replikerna när vi flyttar VM-instanser mellan värdar

Kör Docker inuti Virtual DSM, inte på värden

Våra WordPress-containrar körs inte på den fysiska NAS:en. De körs inuti en Virtual DSM-gäst, och gästen skyddas av Virtual Machine Manager på värden. Om C3RB3R ransomware får root inuti gästen kommer de bara åt den gästen och inget annat. Ögonblicksbilderna av gästen finns på värdlagringen, utanför gästens filsystem, så ransomware inuti VM kan inte se dem, än mindre kryptera eller radera dem. Återställning är en återgång till en ögonblicksbild som mäts i minuter.

VMM Pro lägger till delarna som gör det till en riktig säkerhetskopia: en skyddsplan som tar ögonblicksbilder av VM och replikerar den till en andra NAS i klustret, så att en urfunktion värd också täcks. Vårt kluster består av en DS1621xs+ och en DS1525+ som replikerar till varandra. Vi beskrev schemalagd export och Cloud Sync till Google Drive -delen separat, och jämförelsen mellan gratis VMM och VMM Pro förklarar vilka delar som kräver licensen.

Om du kör Docker direkt på DSM, använd oföränderliga ögonblicksbilder (immutable snapshots)

Alla vill inte ha ett VM-lager. Om dina containrar körs på värden är försvaret mot C3RB3R ransomware oföränderliga ögonblicksbilder. Aktivera dem i Snapshot Replication för den delade mappen som innehåller dina containerdata. De kräver DSM 7.2 eller senare och en Btrfs-volym, och under låsperioden kan ingen radera dem, inklusive ett administratörskonto som angriparen har tagit över. Två detaljer avgör om detta lyckas eller misslyckas:

• Använd bind-monteringar till en delad mapp såsom /volume1/docker/app. Namngivna Docker-volymer ligger under /volume1/@docker, vilket inte är en delad mapp och det går inte alls att ta ögonblicksbilder av den.
• Dumpa databaser till en fil före ögonblicksbilden. En ögonblicksbild av en igångvarande MariaDB är en strömavbrottskopia. En schemalagd mysqldump till samma delade mapp ger dig en ren återställningspunkt som ögonblicksbilden sedan låser.
• Välj en låsperiod som är längre än vad en angripare kan sitta tyst. Offret ovan hade en bakdörr i 37 dagar innan krypteringen startade. Sju dagars oföränderliga ögonblicksbilder skulle inte ha räckt tillbaka till ett rent tillstånd.

Vårt extra lager: Active Insight tar en ögonblicksbild när krypteringen startar

Här är lagret som de flesta guider missar. Active Insight, Synologys molnövervakningstjänst, kan övervaka filaktivitet i dina delade mappar, och så fort den avgör att den ser ransomware reagerar den på egen hand. Synology dokumenterar det i sin säkerhetsguide för NAS: när en ransomware-händelse upptäcks skickar Active Insight ett händelsemeddelande och tar automatiskt en ögonblicksbild av den delade mappen, och på modeller som stöds är den ögonblicksbilden oföränderlig.

Varför detta har särskild betydelse för C3RB3R ransomware: krypteringen i C3RB3R ransomware är långsam. Offret med mer än 50 TB var bara framme vid sina bilder från 2024 när han upptäckte det. En ögonblicksbild som tas när krypteringsmönstret först upptäcks fryser allt som inte har rörts än, vilket kan vara det mesta av volymen. Den bryr sig inte heller om hur C3RB3R ransomware tog sig in, eftersom den övervakar vad som händer med filerna, inte inloggningssidan. På vår DS1621xs+ visar sidan Filaktivitet att ransomware-skyddet är Skyddad.

Läs begränsningarna innan du litar på funktionen. De kommer från Synologys dokumentation om Filaktivitet:

• Övervakning av filaktivitet är avstängd som standard. Registrera din NAS för Active Insight i Kontrollpanelen och aktivera sedan övervakning för varje värd i Active Insight-portalen.
• Den kräver Snapshot Replication, DSM 7.2 eller senare, Active Insight 3.0.2 eller senare, minst 1 GB minne och en Active Insight-licens tilldelad den enheten.
• Högst en automatisk ögonblicksbild per delad mapp och dag. Det är ett skyddsnät som tas efter att händelsen upptäckts, inte en ersättning för schemalagda oföränderliga ögonblicksbilder.
• Omfattas inte: Surveillance Station-inspelningsmappar och delade mappar på externa USB-enheter.
• Oföränderlighet beror på modellen. På en modell utan oföränderliga ögonblicksbilder kan en angripare med root-behörighet fortfarande radera den automatiska ögonblicksbilden, så kombinera den med det oföränderliga schemat ovan.

Vill du ha samma konfiguration? SynoPower Club säljer äkta licenser för båda byggstenarna: en Virtual DSM (VDSM)-licens för att köra dina Docker-tjänster i en isolerad gäst, och en VMM Pro-licens för skyddsplaner, replikering mellan NAS-enheter och live-migrering. Nycklar levereras via e-post.

Var man hittar fler officiella resurser

C3RB3R ransomware på Synology har bara varit känt offentligt i två dagar i skrivande stund, och det finns ingen officiell videotäckning ännu, så det här avsnittet listar primärkällor istället för genomgångar.

• Synologys säkerhetsmeddelande den 29 oktober 2026, som uppmanar användare med föråldrad DSM att uppdatera omedelbart och aktivera automatiska uppdateringar, följt den 30 oktober av ett e-postmeddelande till kunder som bekräftar SA-24:20 som den enda inblandade sårbarheten.
• Synology-SA-24:20 och Synology-SA-26:13 är versionstabellerna. Kontrollera din version i Kontrollpanelen, sedan Uppdatera och återställ, mot båda.
• DSM i en virtuell Proxmox VE-maskin som kör GitLab är det bästa indexet över alla kända fall, inklusive de som inte täcks här, och den tydligaste förklaringen av när minnesforensik är meningslös.
• De tre r/synology-trådarna som länkats ovan, särskilt den forensiska rapporten, som innehåller undersökningskommandona för skrivskyddade diskar steg för steg: Jaha, nu hände det äntligen.

Synologys egen checklista (30 oktober 2026)

Synologys e-postmeddelande till kunder avslutas med fyra steg. De är korta, och vart och ett av dem är viktigt mot C3RB3R ransomware:

1. Kontrollera om det finns inkräktare. C3RB3R ransomware lämnar efter sig schemalagd persistens, så kör en sökning med Security Advisor, och leta sedan i Task Scheduler efter skript du inte har skapat samt i User and Group efter administratörskonton du inte har lagt till. Om något ser fel ut, kontakta Synology Support.
2. Uppdatera allt. Installera den senaste versionen av DSM i Kontrollpanelen, Uppdatera och återställ, och uppdatera sedan alla paket i Paketcenter.
3. Slå på automatiska uppdateringar i Uppdatera och återställ, så att framtida säkerhetskorrigeringar installeras så snart de släpps.
4. Ha en offsite-säkerhetskopia. Använd Hyper Backup och Snapshot Replication för att spara en kopia på en separat plats, och kontrollera regelbundet att säkerhetskopieringarna faktiskt slutförs.

Steg ett är det steg som folk hoppar över. Om din enhet var nåbar från internet före korrigeringen i december 2024 kan C3RB3R ransomware redan ha fått fäste, och att uppdatera idag talar inte om för dig om någon redan är inne.

Ett gratisverktyg som utför kontrollen åt dig

Om du är bekväm med en terminal kan steg ett nu vara ett enda kommando. synology-nas-cli är ett kommandoradsverktyg med öppen källkod under MIT-licens, släppt den 30 oktober 2026 av den oberoende utvecklaren Akari Sora. Det loggar in i DSM via dess webb-API och granskar enheten mot denna kampanj. Projektet finns på GitHub: akari-sora/synology-nas-cli.

Vi läste igenom dess kod innan vi länkade till den. Det använder endast Pythons standardbibliotek och talar inte med något annat än din NAS, nedladdningsservern för Synology, PyPI och soimy-räddningsverktyget. Det skickar ingen telemetri, och den grundläggande granskningen läser bara. Det här är vad det kontrollerar:

• Korrigeringsnivå. Din DSM-version mot Synology-SA-26:13, vilket också täcker den äldre korrigeringen SA-24:20, och dina installerade paket mot SA-26:14.
• Exponering. QuickConnect, UPnP-portvidarebefordran på routern, DSM-brandväggen, AutoBlock, SMB1 och det inbyggda admin-kontot.
• Spår av utpressningsprogrammet C3RB3R. De injicerade inloggningssträngarna i anslutningsloggen, /etc/cron.d/synot* -poster, libgld och qnetd -binärfiler, extra root-konton, SSH-nycklar och utpressningsmeddelanden på dina utdelade mappar.
• Ögonblicksbilder. Delade mappar som saknar ett fungerande schema för ögonblicksbilder.

Det kan också åtgärda det mesta av vad det hittar. Om filer krypteras just nu fryser dess contain-kommando krypteraren med SIGSTOP, samma åtgärd som steg två i vår lista över första åtgärder. Dess rescue-kommando styr sedan soimy-verktyget för att fånga minne och söka efter nyckeln.

nas incident                 # skrivskyddad granskning

Läs dessa anteckningar innan du låter det ändra något:

• Det är helt nytt. Projektet är bara några dagar gammalt, kommer från en enskild utvecklare, är inte anslutet till Synology och har genomgått liten granskning utifrån. Börja med den skrivskyddade granskningen och en dry-run.
• Brandväggsåtgärden kan låsa dig ute. Det ändrar DSM-brandväggen till att neka allt utom de nätverk du anger. Kör det från en dator på samma lokala nätverk (LAN), och ta reda på var RESET-knappen sitter.
• Det stänger av QuickConnect. Det är den säkrare inställningen, men om din familj når Synology Photos eller Surveillance Station via QuickConnect, konfigurera ett VPN eller Tailscale först.
• Den djupa skanningen, contain och rescue körs som root. De fungerar via en tillfällig Aktivitetsschemaläggare-uppgift, eftersom det är det enda sättet att läsa root-skyddade loggar och frysa processer.
• README-filen föreslår att du lämnar över det till en AI-agent. Om du gör det, förvara lösenordet i en lösenordshanterare istället för i chatten, och bekräfta åtgärden själv.
• Minnesräddning fungerar bara så länge krypteraren är igång. Samma regel som för de tre GitHub-fallen gäller.

För resten av säkringsarbetet täcker våra guider om att köra en offentlig webbplats på en Synology NAS och om vad Threat Prevention kan och inte kan se nätverkssidan, och guiden för PHP2Shell-korrigeringen täcker det andra kritiska problemet som uppstod samma vecka.

Begränsningar och säkerhetsanmärkningar för C3RB3R Ransomware

En uppdatering tar inte bort en befintlig infektion. Minst ett offer fann att cron-beständigheten fortfarande fanns kvar efter uppgradering till senaste DSM. Om du var utsatt när du saknade korrigering, kontrollera /etc/cron.d, Schemaläggaren, uppstartsskript och aktiverade tjänster som telnet, och byt sedan alla inloggningsuppgifter.

Uppdaterad är inte samma sak som ren. Ett offer på Reddit trodde att DSM var uppdaterat, och ett annat drabbades trots att 2FA och ett starkt lösenord var aktiverat. En enhet som har utsatts för intrång innan den säkerhetsuppdaterades kan bära med sig implantatet genom varje senare uppdatering. Behandla alla inloggningssidor för DSM som når internet som ett mål, inklusive sådana som publicerats via UPnP som du aldrig ställt in avsiktligt. Använd ett VPN eller Tailscale för fjärråtkomst och stäng av UPnP på routern.

RAID och lokala säkerhetskopior är inte säkerhetskopior mot C3RB3R ransomware. Allt som det komprometterade DSM kan skriva till kommer att krypteras, inklusive Hyper Backup-mål på samma enhet och monterade nätverksdelningar.

Betala inte innan du har läst fallen. Att betala C3RB3R ransomware-operatörer finansierar nästa våg och garanterar ingenting. Om krypteringsprogrammet fortfarande körs är minnesforensik din bästa chans. Om det inte gör det är de realistiska vägarna dina egna externa kopior.

Var försiktig med vad du klistrar in i en AI-assistent. AI-verktyg hjälpte flera offer här, men ge dem inte lösenord, återställda nycklar, fullständiga minnesdumpar eller affärsdata. Låt dem föreslå kommandon och kör allt som kräver root själv.

Klonad hårdvara medför extra risker. Flera dokumenterade offer körde DSM på icke-äkta hårdvara, där officiella uppdateringar är svåra eller omöjliga att installera. Om det är din konfiguration, utgå från att du saknar säkerhetsuppdateringar och koppla bort den helt från internet.

Referenser

• Synologys säkerhetsmeddelande om DSM-ransomware-attacker, 29 oktober 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 och de korrigerade DSM-versionerna.
• Synology-SA-26:13 DSM, CVE-2026-13639 och CVE-2026-13684, publicerad 18 september 2026.
• Benjamin-zlt C3RB3R ransomware bare-metal-räddning, filformatet, nyckellayouten och SIGSTOP-arbetsflödet.
• synology-nas-cli av Akari Sora, ett verktyg med öppen källkod för granskning och reaktion vid denna kampanj.
• IT-Connect om C3RB3R-kampanjen, som sammanfattar 360-attribueringen och tidslinjen.
• Synology Knowledge Center: förbättra säkerheten för din Synology NAS, inklusive hur Active Insight tar en ögonblicksbild av en delad mapp när det upptäcker ransomware.

Vanliga frågor

Se till att nästa C3RB3R-ransomware-attack bara kostar dig en återställning, inte en lösesumma. Kör dina Docker-tjänster inuti Virtual DSM och skydda hela gästen med VMM Pro-skyddsplaner, replikerade till en andra NAS. SynoPower Club säljer äkta licenser för båda, med nycklar levererade via e-post.