C3RB3R-løsepengevirus på Synology: Opprinnelse, gjenoppretting og hvordan holde seg trygg

C3RB3R-løsepengevirus begynte å dukke opp på Synology NAS-enheter rundt 28. oktober 2026, og innen én dag var det det eneste temaet på r/synology. Filer blir omdøpt med en L0CK3D -filendelse (et null, ikke bokstaven O), og hver mappe får en read-me3.txt løsepengefil, og en Tor-portal ber om Bitcoin. Den raskeste og mest nyttige informasjonen kom ikke fra engelske nyhetssider. Den kom fra kinesiskspråklige forumer, hvor Synology har en enorm brukerbase, og fra tre GitHub-repositorier skrevet av ofre som faktisk fikk dataene sine tilbake, eller beviste at de ikke kunne det. Denne guiden samler det som er bekreftet om C3RB3R ransomware så langt: hvor det kom fra, hvordan det kommer seg inn, den ene gjenopprettingsveien som har fungert, og sikkerhetskopieringsdesignet vi kjører slik at et slikt angrep koster oss en gjenoppretting i stedet for løsepenger.

Oppdatering, 31. oktober 2026: Synology har nå fastslått inngangspunktet. I en e-post til kunder 30. oktober bekreftet de at C3RB3R-løsepengevirus kun utnytter sårbarheten som ble utbedret i Synology-SA-24:20, som ble feilrettet i desember 2024, og at kampanjen ikke har noen sammenheng med PHP2Shell-sårbarheten som ble feilrettet samme måned. Vi har lagt til Synologys egen firetrinns sjekkliste, vår tolking av hvorfor angrepene skjedde da de gjorde det, og et ekstra lag vi kjører som de fleste eiere allerede betaler for: Active Insight-beskyttelse mot løsepengevirus.

SynoPower Club-punkt:Et offer i en kinesisk NAS-gruppe hadde mer enn 50 TB på en enkelt enhet og ingen øyeblikksbilder. Krypteringsprogrammet var tregt nok til at bare bildene hans fra 2024 ble rammet, og disse hadde tilfeldigvis en kald kopi på en skytjeneste. En annen mistet fem år med private GitLab-repositorier fordi RAID 6 pluss tre sikkerhetskopier alle lå på samme maskin. C3RB3R ransomware slo ikke lagringen deres, det slo sikkerhetskopieringsdesignet deres. Vi kjører de offentlige nettstedene våre som Docker i Virtual DSM, tar øyeblikksbilde av hele gjesten fra verten, replikerer det til en NAS nummer to, og eksporterer det til USB og skyen etter en tidsplan. Hvis en gjest blir kryptert i kveld, ruller vi den tilbake til det siste øyeblikksbildet, og angriperen får ingenting.

Hva er C3RB3R ransomware?

C3RB3R ransomware er en Linux-versjon av Cerber-familien, en ransomware-linje som har eksistert siden 2016 og fra tid til annen har målrettet NAS-enheter i årevis. 360 tilskriver Synology-bølgen i oktober 2026 til den. På en infisert DSM-enhet kjører C3RB3R ransomware-krypteringen som en statisk lenket, UPX-pakket x86-64-binærfil ved navn libgldDen sletter sin egen fil etter start, så den kjørende prosessen viser (slettet) ved siden av stien til den kjørbare filen.

Det du ser som eier av en enhet rammet av C3RB3R ransomware er konsistent i alle rapporter:

• Filer omdøpt til name.ext.L0CK3DEnkelte rapporter staver det LOCK3D, men GitHub-analysene siterer tallet null.
• En løsepengefil kalt read-me3.txt i hver kryptert mappe, med overskriften C3RB3R INSTRUCTIONS.
• En Tor-side med tittelen C3rb3r Decryptor. Et skjermbilde fra et offer viste 0,03696 BTC (omtrent 2 952 USD) hvis det ble betalt innen fem dager, noe som doblet seg til 0,07392 BTC (omtrent 5 904 USD) etter det, med en nedtellingsfunksjon.
• Vedvarende tilgang gjennom cron-oppføringer som matcher /etc/cron.d/synot*, som gjenoppretter seg selv og overlevde en DSM-oppgradering i hvert fall i ett tilfelle.
• Sikkerhetskopifiler på samme volum kryptert sammen med alt annet, inkludert Hyper Backup-mål og databasedumper.

Hvor det startet: r/synology og de kinesiske forumene

C3RB3R ransomware dukket først opp på engelsk på r/synology, der ofre publiserte innlegg innen omtrent et døgn fra hverandre rundt 28. og 29. oktober 2026. Innen få timer sa leserne at det dukket opp en ny tråd hver gang de oppdaterte subredditen. Tre av disse trådene er verdt å lese i sin helhet, fordi hver av dem bidrar med en ny brikke:

• Den tekniske etterforskningsrapporten. En DS918+-eier på DSM 7.2.1-69057 Update 5, med webgrensesnittet tilgjengelig fra internett, slo av enheten og undersøkte diskene skrivebeskyttet på en Proxmox-vert. DSM-autentiseringsloggen inneholdt en innloggingsforespørsel der kontofeltet hadde injiserte LD_PRELOAD og LD_DEBUG_OUTPUT -linjer pluss en kodet kommandolinjekommando, og en fil under /etc/cron.dDet samsvarer med den publiserte CVE-2024-10441-teknikken. En 3-2-1-sikkerhetskopi betydde at angrepet kostet en gjenoppretting, ikke løsepenger. Les det her: Vel, da skjedde det endelig. Min første ekte løsepengevirus-hendelse.
• Brukeren som bare brukte Photos. Denne eieren trodde DSM var oppdatert og brukte bare Synology Photos, men UPnP på ruteren var på. Etter en modus 2-tilbakestilling kom mapper som var dekket av Snapshot Replication tilbake. Mapper uten øyeblikksbilder gjorde det ikke, og den lokale Hyper Backup USB-stasjonen ble kryptert sammen med NAS-en. Les det her: Rammet av c3rb3r-løsepengevirus i morges.
• QuickConnect-diskusjonen. Den opprinnelige innsenderen merket det først etter at DSM ble degradert, og en reinstallasjon avslørte de krypterte filene. I svarene sa en annen leser med et sterkt passord, 2FA og QuickConnect aktivert at de også hadde blitt rammet, og andre påpekte at brukere som bare bruker apper kan slå av DSM-tilgang i QuickConnect helt. Les det her: Rammet av C3RB3R-løsepengevirus.

Lest i sammenheng er mønsteret tydelig. C3RB3R ransomware trengte bare en DSM-innloggingsside den kunne nå, ingenting mer. Passord og 2FA hjalp ikke, fordi utnyttelsen kjører før autentisering. Den tekniske rapporten uttrykte det klart: forespørselen nådde et sårbart program, og ennå en passordforespørsel ville ikke ha løst det.

Det dypere tekniske arbeidet skjedde på kinesisk. Ofre i WeChat- og Xiaohongshu-grupper la ut løsepengenotater, sammenlignet tidslinjer og henviste hverandre til GitHub-repositoriene som dekkes nedenfor. Et taiwansk Synology-fellesskap på Facebook samlet de samme gjenopprettingslenkene for lokale brukere. Det gir mening: Synology er et taiwansk selskap, og de største brukerfellesskapene deres er kinesisktalende, så det var der omfanget av C3RB3R ransomware-tilfeller, og dermed den raskeste mønstergjenkjenningen, kom fra.

Synology selv publiserte et sikkerhetsvarsel den 29. oktober 2026, og oppga at de hadde identifisert trusselaktører som utnyttet en sårbarhet som ble feilrettet i desember 2024 mot utdaterte DSM-versjoner, og oppfordret alle til å oppdatere umiddelbart.

Slik tar C3RB3R-utpressingsvare seg inn

De to første dagene var det to mulige inngangspunkter. Synology har siden bekreftet det eldste. E-posten fra 30. oktober sier at angrepene kun utnytter sårbarheten som ble håndtert i Synology-SA-24:20, og at C3RB3R-løsepengevirus ikke har noe med PHP2Shell å gjøre. Tabellen nedenfor viser begge kandidatene slik de ble diskutert, fordi 360-paret fortsatt er verdt å sikkerhetsoppdatere.

	Synology sier	360 sier
Rådgivende	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, uautentisert ekstern kjøring av kode i systemets plugin-daemon	CVE-2026-13639 (innloggingslogikk) og CVE-2026-13684 (SCGI), begge CVSS 9.8
Rettet	November til desember 2024	september 2026
Rettede versjoner	DSM 7.2.2-72806 oppdatering 1, 7.2.1-69057 oppdatering 6, 7.2-64570 oppdatering 4, 7.1.1-42962 oppdatering 7	DSM 7.4-90075, 7.3.2-86009 oppdatering 4, 7.2.2-72806 oppdatering 9, 7.2.1-69057 oppdatering 12

De digitale bevisene peker mot den eldre feilen for i det minste enkelte ofre. Den mest detaljerte Reddit-analysen samsvarte med sine egne overlevende logger med den publiserte CVE-2024-10441-utnyttelsen, samtidig som det ble bemerket at Synology ikke hadde bekreftet det, og at samme enhet også var under SA-26:13-rettelsesnivået. Soimy sin analyse sier at minnelogger fra den infiserte gjesten peker mot miljøvariabel-injeksjon via innloggings-pluggen i DSM, noe som stemmer overens med CVE-2024-10441, og et offentlig «proof of concept» som misbruker brukernavn-feltet ved innlogging dukket opp på GitHub dager før utbruddet. To av de tre dokumenterte redningssakene kjørte på ikke-original maskinvare med en DS918+-oppstartslaster, én av dem på DSM 7.2-64570 Update 3, noe som er nøyaktig én oppdatering unna rettelsen for CVE-2024-10441. Klonet maskinvare kan ikke enkelt ta i mot offisielle oppdateringer, noe som gjør den til det enkleste målet i gruppen.

Den praktiske konklusjonen har ikke endret seg: oppdater til en versjon som dekker begge sikkerhetsadvarslene, og slutt å eksponere DSM for internett. Men ett spørsmål gjensto. Hvis hullet ble tettet i desember 2024, hvorfor utløste så mange enheter C3RB3R-løsepengevirus i løpet av de samme to dagene i oktober 2026, inkludert noen der eierne trodde de var oppdaterte?

Plantet tidlig, detonert på tegn

Vår tolking, og det er vår tolkning snarere enn noe Synology har uttalt, er at C3RB3R-løsepengevirus-innbruddet og krypteringen er to separate hendelser. Bevisene peker i den retningen:

• Bakdøren kom først. I Xiaohongshu-saken nedenfor hadde et bakdørsskall ligget på NAS-en i 37 dager og slått på telnet som root før én eneste fil ble kryptert.
• Den overlever oppdateringer. Cron-oppføringene under /etc/cron.d/synot* gjenskaper seg selv, og minst én skadelidende fant dem fortsatt på plass etter oppgradering til nyeste DSM. Oppdateringen lukket hullet, men lot inntrengeren bli igjen på innsiden.
• Detonasjonene var synkronisert. Enheter berørt av C3RB3R-løsepengevirus som hadde blitt kompromittert til ulike tider og på ulike versjoner, startet krypteringen innen omtrent 48 timer fra hverandre.

Mønsteret passer med en aktør som plantet C3RB3R-løsepengevirus-implantater på uoppdaterte enheter over flere måneder, og deretter valgte når avtrekkeren skulle trykkes inn fra avstand. Øyeblikket de valgte var PHP2Shell-uken, da alle Synology-administratorer var opptatt med oppdateringer, mange enheter nettopp var oppdatert, og eiere følte seg trygge fordi de hadde oppdatert. Synology er tydelige på at PHP2Shell ikke var inngangsporten. Det var dekket. Lærdommen er at en enhet som har vært eksponert mens den var uoppdatert bør behandles som kompromittert inntil den er sjekket, noe som er nøyaktig hva trinn én i Synologys sjekkliste ber deg om å gjøre.

Førstehjelp ved C3RB3R-utpressingsvare i 4 trinn

Hvis du finner L0CK3D -filer akkurat nå, vil rekkefølgen på de neste ti minuttene avgjøre om gjenoppretting i det hele tatt er mulig. Nøkkelen som låser opp filene dine finnes bare inne i den kjørende prosessen til C3RB3R-utpressingsvaren. En omstart, en kill -9 eller en ny installasjon av DSM vil ødelegge den.

Kommandoene bak trinn 2 og 3 ser slik ut. Les gjennom arkivene før du kjører noe, fordi detaljene avhenger av hvilken binærfil du har.

# Trinn 2: finn krypteringsprosessen (den kjørebare filen vises som slettet)

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

# Frys den. Bruk aldri kill -9 her.

kill -STOP <PID>	grep State /proc/<PID>/status # skal vise T (stopped)	# Se etter persistens som henter den tilbake	ls -l /etc/cron.d/ | grep synot
Kan du dekryptere det? De tre redningssakene fra GitHub	Det finnes ingen universal dekrypteringsprogramvare for C3RB3R-utpressingsvare, og alle som selger en slik bare gjetter. Det som finnes er tre grundige casestudier som forteller deg nøyaktig når gjenoppretting fungerer.	Arkiv	Maskin
Resultat	Årsak	Arkiv	soimy/c3rb3r-rescue
DSM i en Proxmox VE virtuell maskin som kjører GitLab	Gjenopprettet	En kopi på 16 GiB av gjestens RAM inneholdt den 48-byte lange sesjonsnøkkelen. GitLab ble gjenopprettet med 80 prosjekter og 9 253 LFS-objekter.	Krypteringsprogrammet hadde allerede avsluttet omtrent 30 timer tidligere. Fullstendige RAM- og swap-skann fant ingen nøkkel.

Det tredje arkivet er det viktigste å lese, for tittelen er lærdommen i seg selv: «aldri omstartet» betyr ikke gjenopprettelig. Det som betyr noe er om C3RB3R ransomware-prosessen fortsatt kjører. Når den avslutter, nullstiller den nøkkelbufferen, og nøkkelen er borte. En nøkkel gjenopprettet fra et offer er også ubrukelig for et annet, fordi hver kjøring genererer en ny øktsnøkkel.

Hvorfor nøkkelen kun ligger i minnet

Benjamin-zlt-analysen forklarer C3RB3R ransomware-filformatet i detalj, og forklarer både hvorfor dette fungerer og hvorfor det vanligvis ikke gjør det.

• Hver fil får sin egen tilfeldige ChaCha8-nøkkel. Den nøkkelen pakkes inn med en øktshovednøkkel ved hjelp av AES-256-CBC og lagres i en 588-byte trailer på slutten av filen.
• Øktshovednøkkelen er på 48 byte: en 16-byte IV pluss en 32-byte AES-nøkkel. Den skrives aldri til disk. En global peker i den kjørende prosessen peker på den.
• Traileren inneholder også en blob som er pakket inn med angriperens offentlige nøkkel (RSA-2048), så uten den kjørende prosessen er det bare angriperen som kan gjenopprette øktsnøkkelen.
• Ikke alle filer er fullstendig kryptert. I et utvalg på 400 filer brukte omtrent 56 % segmentert modus, 31 % hadde bare de første 1 MiB kryptert, og 13 % var kryptert fra ende til annen. Delvis krypterte filer er fortsatt ikke lesbare, men analysering av filslutt (footer) forteller deg hva som gjenstår.

Så svakheten i C3RB3R ransomware er smal og tidsbegrenset: krypteringsprogrammet beholder hovednøkkelen i minnet under hele økten. Frys det mens det kjører, og du kan hente ut nøkkelen. Misser du det vinduet, sitter du igjen med den offentlige nøkkel-bloben, som er utformet for å være umulig å knekke.

En offerhistorie: 50 TB og ingen øyeblikksbilder

En detaljert redegjørelse publisert på Xiaohongshu den 29. oktober 2026 av brukeren 柯基爱好者 følger et medlem av deres NAS-gruppe gjennom natten. Han la merke til C3RB3R ransomware-notatet, bekreftet C3RB3R INSTRUCTIONS-overskriften, og var nære ved å kjøpe Bitcoin før gruppen viste ham GitHub-sakene.

Han brukte deretter en AI-kodingsassistent over SSH for å undersøke. Den fant og frøs krypteringsprogrammet, slik at ingenting nytt ble kryptert etter det tidspunktet. Den fant også ut at et sannsynlig bakdørsskjell hadde ligget på NAS-en i 37 dager og hadde aktivert telnet som root, noe som betyr at det opprinnelige innbruddet og krypteringen skjedde med over en måneds mellomrom. Den skrev et bevisinnsamlingsskript og ventet, helt korrekt, på hans bekreftelse før den kjørte noe som root.

Hellet hans var at C3RB3R ransomware er tregt. Med mer enn 50 TB å tygge seg gjennom, hadde krypteringsprogrammet bare nådd bildene hans fra 2024, og de fantes det en kald kopi av på en skystasjon. Han flyttet arbeidsdata til en mindre NAS og parkerte det krypterte volumet til senere. Hans egen oppsummering var kontant: han hadde ingen øyeblikksbilder, og med øyeblikksbilder ville dette vært enkelt å fikse. Et annet offer på X oppsummerte den samme lærdommen fra den andre siden: RAID 6 pluss tre sikkerhetskopisett, alle på samme boks, alle kryptert sammen.

Hvordan vi holder C3RB3R ransomware unna sikkerhetskopiene våre

Hver eneste historie om tapte data ovenfor har samme mønster: sikkerhetskopiene var tilgjengelige fra maskinen som ble overtatt. C3RB3R ransomware krypterer alt den kompromitterte DSM kan skrive til, så løsningen er å oppbevare minst én kopi et sted DSM overhodet ikke kan skrive til. Dette er hvordan vi gjør det for nettstedene vi er vert for, og det følger 3-2-1-1-0-regelen.

Regel	Betydning	Slik gjør vi det
3	Tre kopier av dataene	Den aktive VM-en, en replika på en sekundær NAS, og en planlagt eksport
2	To typer medier	NAS-volumer pluss en USB-stasjon og en skystasjon
1	Én kopi eksternt	Eksporter synkronisert til Google Drive med Cloud Sync
1	Én kopi frakoblet eller uforanderlig	VM-øyeblikksbilder på vertssiden som gjesten ikke kan røre, pluss den frakoblede USB-eksporten
0	Null feil ved gjenoppretting	Vi gjenoppretter og starter fra replikaene i praksis når vi flytter VM-er mellom verter

Kjør Docker i Virtual DSM, ikke på verten

Våre WordPress-containere kjører ikke på den fysiske NAS-en. De kjører i en Virtual DSM-gjest, og gjesten beskyttes av Virtual Machine Manager på verten. Hvis C3RB3R ransomware får root-tilgang i gjesten, overtar de den gjesten og ingenting annet. Øyeblikksbildene av gjesten ligger på vertslagringen, utenfor gjestens filsystem, så ransomware i VM-en kan ikke se dem, enn si kryptere eller slette dem. Gjenoppretting er en tilbakerulling til et øyeblikksbilde som måles i minutter.

VMM Pro legger til delene som gjør dette til en ekte sikkerhetskopi: en beskyttelsesplan som tar øyeblikksbilde av VM-en og replikerer den til en sekundær NAS i klyngen, slik at en nede vert også er dekket. Klyngen vår består av en DS1621xs+ og en DS1525+ som replikerer til hverandre. Vi har beskrevet planlagt eksport og Cloud Sync til Google Drive -delen separat, og sammenligningen av gratis VMM mot VMM Pro forklarer hvilke deler som krever lisensen.

Hvis du kjører Docker direkte på DSM, bør du bruke uforanderlige øyeblikksbilder

Ikke alle ønsker et VM-lag. Hvis containerne dine kjører på verten, er uforanderlige øyeblikksbilder forsvaret mot C3RB3R-løsepengevirus. Slå dem på i Snapshot Replication for den delte mappen som inneholder containerdataene dine. De krever DSM 7.2 eller nyere og et Btrfs-volum, og i låseperioden kan ingen slette dem, inkludert en administratorkonto angriperen har overtatt. To detaljer er helt avgjørende:

• Bruk bind-mounts til en delt mappe som for eksempel /volume1/docker/app. Navngitte Docker-volumer ligger under /volume1/@docker, som ikke er en delt mappe og som overhodet ikke kan tas øyeblikksbilde av.
• Dump databaser til en fil før øyeblikksbildet tas. Et øyeblikksbilde av en kjørende MariaDB er som en kopi tatt ved strømbrudd. Et planlagt mysqldump i den samme delte mappen gir deg et rent gjenopprettingspunkt som øyeblikksbildet deretter låser.
• Velg en låseperiode som er lengre enn en angriper kan sitte stille. Offeret ovenfor hadde en bakdør i 37 dager før krypteringen startet. Syv dager med uforanderlige øyeblikksbilder ville ikke nådd tilbake til en ren tilstand.

Vårt ekstra lag: Active Insight tar et øyeblikksbilde når krypteringen starter

Her er laget de fleste guider overser. Active Insight, Synologys skyovervåkingstjeneste, kan overvåke filaktivitet på de delte mappene dine, og så snart den vurderer at den ser på et løsepengevirus, reagerer den på egen hånd. Synology dokumenterer det i sin NAS-sikkerhetsguide: når en løsepengevirushendelse oppdages, sender Active Insight et hendelsesvarsel og tar automatisk et øyeblikksbilde av den delte mappen, og på modeller som støtter det, er dette øyeblikksbildet uforanderlig.

Hvorfor dette betyr noe for spesielt C3RB3R-løsepengevirus: krypteringsprogrammet til C3RB3R-løsepengevirus er tregt. Offeret med mer enn 50 TB var bare kommet til 2024-bildene sine da han oppdaget det. Et øyeblikksbilde som tas når krypteringsmønsteret først vises, fryser alt som ikke har blitt rørt ennå, noe som kan utgjøre det meste av volumet. Det bryr seg heller ikke om hvordan C3RB3R-løsepengevirus kom seg inn, fordi det overvåker hva som skjer med filene, ikke innloggingssiden. På vår DS1621xs+ viser siden for filaktivitet at beskyttelse mot løsepengevirus står som Beskyttet.

Les begrensningene før du stoler på funksjonen. De kommer fra Synologys dokumentasjon for filaktivitet:

• Overvåking av filaktivitet er slått av som standard. Registrer NAS-en for Active Insight i Control Panel, og aktiver deretter overvåking for hver vert i Active Insight-portalen.
• Den krever Snapshot Replication, DSM 7.2 eller nyere, Active Insight 3.0.2 eller nyere, minst 1 GB minne og en Active Insight-lisens tildelt den aktuelle NAS-en.
• Maksimalt ett automatisk øyeblikksbilde per delt mappe per dag. Det er et sikkerhetsnett som tas etter oppdagelse, ikke en erstatning for planlagte uforanderlige øyeblikksbilder.
• Ikke dekket: Opptaksmapper for Surveillance Station og delte mapper på eksterne USB-stasjoner.
• Uforanderlighet avhenger av modellen. På en modell uten uforanderlige øyeblikksbilder kan en angriper med root-tilgang fortsatt slette det automatiske øyeblikksbildet, så kombiner det med den uforanderlige tidsplanen ovenfor.

Vil du ha det samme oppsettet? SynoPower Club selger ekte lisenser for begge byggesteinene: en Virtual DSM (VDSM)-lisens for å kjøre Docker-tjenestene dine i en isolert gjest, og en VMM Pro-lisens for beskyttelsesplaner, replikering på tvers av NAS og live-migrering. Nøkler leveres via e-post.

Hvor du finner flere offisielle ressurser

C3RB3R-utpressingsvare på Synology er to dager gammel offentlig i skrivende stund, og det finnes ingen offisiell videodekning ennå, så denne seksjonen lister opp primærkilder i stedet for veiledninger.

• Synology sin sikkerhetsadvarsel fra 29. oktober 2026, som ber brukere med utdaterte DSM-versjoner om å oppdatere umiddelbart og aktivere automatiske oppdateringer, fulgt opp 30. oktober av en kundee-post som bekrefter at SA-24:20 var den eneste sårbarheten involvert.
• Synology-SA-24:20 og Synology-SA-26:13 er versjonstabellene. Sjekk din byggversjon i Kontrollpanel, deretter Oppdater og gjenopprett, mot begge.
• DSM i en Proxmox VE virtuell maskin som kjører GitLab er den beste indeksen over alle kjente tilfeller, inkludert de som ikke dekkes her, og den klareste forklaringen på når minneetterforskning er hensiktsløs.
• De tre r/synology-trådene lenket til ovenfor, spesielt den forensiske rapporten, som inneholder trinnvise undersøkelseskommandoer for skrivebeskyttet disk: Vel, det skjedde til slutt.

Synologys egen sjekkliste (30. oktober 2026)

Synologys e-post til kunder avsluttes med fire trinn. De er korte, og hver eneste av dem er viktig mot C3RB3R-ransomware:

1. Sjekk for inntrengere. C3RB3R-ransomware etterlater seg planlagt persistens, så kjør en skanning med Security Advisor, og se deretter i Task Scheduler etter skripter du ikke har opprettet, og i User and Group etter administratorkontoer du ikke har lagt til. Hvis noe ser feil ut, kontakt Synology Support.
2. Oppdater alt. Installer den nyeste DSM i Control Panel, Update and Restore, og oppdater deretter alle pakker i Package Center.
3. Slå på automatiske oppdateringer i Update and Restore, slik at fremtidige sikkerhetsoppdateringer mottas så snart de gis ut.
4. Ha en ekstern sikkerhetskopi. Bruk Hyper Backup og Snapshot Replication til å oppbevare en kopi på et annet sted, og sjekk regelmessig at sikkerhetskopieringsoppgavene faktisk fullføres.

Trinn én er det folk hopper over. Hvis enheten din var tilgjengelig fra internett før feilrettingen i desember 2024, kan C3RB3R-ransomware allerede ha fått et fotfeste, og det å oppdatere i dag forteller deg ikke om noen allerede er på innsiden.

Et gratis verktøy som kjører sjekken for deg

Hvis du er komfortabel med en terminal, kan trinn én nå være én enkelt kommando. synology-nas-cli er et verktøy for kommandolinjen med åpen kildekode under MIT-lisensen, utgitt 30. oktober 2026 av den uavhengige utvikleren Akari Sora. Det logger på DSM via web-API-et og gransker enheten mot denne kampanjen. Prosjektet ligger på GitHub: akari-sora/synology-nas-cli.

Vi leste gjennom koden før vi lenket til den. Det bruker bare Pythons standardbibliotek, og det kommuniserer ikke med noe annet enn din NAS, Synology-nedlastingsserveren, PyPI og soimy-redningsverktøysettet. Det sender ingen telemetri, og den grunnleggende granskingen er skrivebeskyttet. Dette er hva det sjekker:

• Oppdateringsnivå. Din DSM-byggversjon mot Synology-SA-26:13, som også dekker den eldre SA-24:20-fixen, og dine installerte pakker mot SA-26:14.
• Eksponering. QuickConnect, UPnP-portvideresending på ruteren, DSM-brannmuren, AutoBlock, SMB1 og den innebygde admin-kontoen.
• Spor av C3RB3R-ransomware. De innsatte innloggingsstrengene i tilkoblingsloggen, /etc/cron.d/synot* -oppføringer, libgld og qnetd -binærfiler, ekstra root-kontoer, SSH-nøkler og løsepengenotater på delte mapper.
• Øyeblikksbilder. Delte mapper som ikke har noen fungerende tidsplan for øyeblikksbilder.

Det kan også rette opp i det meste av det det finner. Hvis filer blir kryptert akkurat nå, fryser contain-kommandoen kryptereren med SIGSTOP, det samme trekket som trinn to i vår førstehjelpsliste. Rescue-kommandoen styrer deretter soimy-verktøysettet for å fange opp minnet og søke etter nøkkelen.

nas incident                 # skrivebeskyttet gransking

Les disse merknadene før du lar det endre noe:

• Det er helt nytt. Prosjektet er noen dager gammelt, kommer fra én enkelt utvikler, er ikke tilknyttet Synology og har hatt lite ekstern gjennomgang. Start med den skrivebeskyttede granskingen og prøvekjøringen (dry run).
• Brannmur-fixen kan låse deg ute. Det endrer DSM-brannmuren til å avvise alt unntatt nettverkene du oppgir. Kjør det fra en datamaskin på det samme lokalnettverket (LAN), og vit hvor RESET-knappen er.
• Det slår av QuickConnect. Det er den sikreste innstillingen, men hvis familien din bruker Synology Photos eller Surveillance Station via QuickConnect, bør du sette opp VPN eller Tailscale først.
• Dyp-skann (deep scan), contain og rescue kjører som root. De fungerer via en midlertidig oppgave i Oppgaveplanlegger (Task Scheduler), fordi det er den eneste måten å lese logger som krever root-tilgang og fryse prosesser.
• README foreslår å overlate det til en AI-agent. Hvis du gjør det, bør du beholde passordet i en passordbehandler i stedet for i chatten, og bekrefte korrigeringen selv.
• Minneredning (memory rescue) fungerer bare mens kryptereren kjører. Samme regel gjelder som for de tre GitHub-sakene.

For resten av sikringsbildet, våre veiledninger om å kjøre et offentlig nettsted på en Synology NAS og om hva Threat Prevention kan og ikke kan se dekker nettverkssiden, og patch-veiledningen for PHP2Shell dekker det andre kritiske problemet som dukket opp samme uke.

Begrensninger og sikkerhetsmerknader for C3RB3R-utpressingsvare

Oppdatering fjerner ikke en eksisterende infeksjon. Minst ett offer fant ut at cron-perstistensen fortsatt var på plass etter oppgradering til nyeste DSM. Hvis du var utsatt mens du var uoppdatert, sjekk /etc/cron.d, Oppgaveplanlegger, oppstartsskripter og aktiverte tjenester som telnet, og roter deretter alle legitimasjoner.

Oppdatert er ikke det samme som ren. Et Reddit-offer trodde DSM var oppdatert, og et annet ble rammet selv med 2FA og et sterkt passord på plass. En enhet som ble kompromittert før den ble sikkerhetsoppdatert, kan ta med seg skadeprogrammet gjennom hver senere oppdatering. Behandle enhver DSM-innloggingsside som internett kan nå som et mål, inkludert de som er publisert via UPnP som du aldri har satt opp bevisst. Bruk VPN eller Tailscale for fjerntilgang, og slå av UPnP på ruteren.

RAID og lokale sikkerhetskopier er ikke sikkerhetskopier mot C3RB3R-utpressingsvare. Alt den kompromitterte DSM-enheten kan skrive til vil bli kryptert, inkludert Hyper Backup-mål på samme enhet og monterte nettverksdelinger.

Ikke betal før du har lest sakene. Å betale C3RB3R-bakmennene finansierer den neste bølgen og garanterer ingenting. Hvis krypteringen fortsatt kjører, er fritt minne-metoden din beste sjanse. Hvis den ikke gjør det, er de realistiske veiene dine egne eksterne kopier.

Vær forsiktig med hva du limer inn i en AI-assistent. AI-verktøy hjalp flere ofre her, men ikke gi dem passord, gjenopprettede nøkler, fullstendige minnedumper eller bedriftsdata. La dem foreslå kommandoer, og kjør alt som krever root selv.

Klonet maskinvare medfører ekstra risiko. Flere dokumenterte ofre kjørte DSM på uekte maskinvare, hvor offisielle oppdateringer er vanskelige eller umulige å installere. Hvis det er ditt oppsett, må du gå ut fra at du ikke er oppdatert og holde den helt borte fra internett.

Referanser

• Synologys sikkerhetsadvarsel om DSM-utpressingsvareangrep, 29. oktober 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 og de rettede DSM-byggene.
• Synology-SA-26:13 DSM, CVE-2026-13639 og CVE-2026-13684, publisert 18. september 2026.
• Benjamin-zlt C3RB3R-løsepengevirus bare-metal-redning, filformatet, nøkkeloppsettet og SIGSTOP-arbeidsflyten.
• synology-nas-cli av Akari Sora, et verktøy for gransking og hendelseshåndtering med åpen kildekode for denne kampanjen.
• IT-Connect om C3RB3R-kampanjen, oppsummerer 360-attribusjonen og tidslinjen.
• Synology Knowledge Center: forbedre sikkerheten til din Synology NAS, inkludert hvordan Active Insight tar et øyeblikksbilde av en delt mappe når det oppdager ransomware.

Ofte stilte spørsmål

Gjør slik at det neste C3RB3R-ransomwareangrepet koster deg en gjenoppretting, ikke løsepenger. Kjør Docker-tjenestene dine i Virtual DSM og beskytt hele gjesten med VMM Pro-beskyttelsesplaner, replikert til en ekstra NAS. SynoPower Club selger ekte lisenser for begge, med nøkler levert på e-post.