Ransomware C3RB3R na Synology: Původ, obnova a jak zůstat v bezpečí

Ransomware C3RB3R se začal objevovat na jednotkách Synology NAS kolem 28. října 2026 a během jednoho dne to bylo jediné téma na r/synology. Soubory se vrací přejmenované s L0CK3D příponou (nula, nikoli písmeno O), v každé složce se objeví read-me3.txt výkupné oznámení a portál Tor požaduje Bitcoin. Nejrychlejší a nejužitečnější informace nepocházely z anglických zpravodajských webů. Pocházely z čínsky mluvících fór, kde má Synology obrovskou uživatelskou základnu, a ze tří repozitářů GitHub napsaných oběťmi, které své údaje skutečně získaly zpět, nebo dokázaly, že to nejde. Tento průvodce shromažďuje, co je o ransomware C3RB3R dosud potvrzeno: odkud se vzal, jak se dostane dovnitř, jedinou cestu k obnově, která fungovala, a architekturu zálohování, kterou provozujeme, aby nás takový útok stál jen obnovení místo výkupného.

Aktualizace, 31. října 2026: Společnost Synology nyní vyjasnila vstupní bod. V e-mailu zákazníkům z 30. října potvrdila, že ransomware C3RB3R zneužívá pouze zranitelnost opravenou v Synology-SA-24:20, zapátkovanou v prosinci 2024, a že tato kampaň nesouvisí se zranitelností PHP2Shell opravenou ve stejném měsíci. Přidali jsme vlastní čtyřkrokový kontrolní seznam Synology, náš pohled na to, proč k útokům došlo právě v danou chvíli, a jednu další vrstvu, kterou provozujeme a za kterou většina majitelů již platí: ochranu před ransomwarem v Active Insight.

Bod SynoPower Club：Jedna z obětí v čínské skupině NAS měla na jediném zařízení více než 50 TB a žádné snímky. Šifrovací program byl dostatečně pomalý, takže byly zasaženy pouze jeho fotografie z roku 2024, a ty měly shodou okolností chladnou zálohu na cloudovém disku. Další přišel o pět let privátních repozitářů GitLab, protože RAID 6 i tři zálohy byly na stejném stroji. Ransomware C3RB3R neporazil jejich úložiště, porazil jejich koncepci zálohování. Naše veřejné weby provozujeme jako Docker uvnitř Virtual DSM, děláme snímek celého hosta z hostitelského systému, replikujeme jej na druhý NAS a podle harmonogramu jej exportujeme na USB a do cloudu. Pokud bude hostující systém dnes večer zašifrován, vrátíme jej k poslednímu snímku a útočník nedostane nic.

Co je ransomware C3RB3R?

Ransomware C3RB3R je verze rodiny Cerber pro Linux, což je řada ransomware, která existuje od roku 2016 a již léta se střídavě zaměřuje na zařízení NAS. Společnost 360 jí přisuzuje vlnu na Synology z října 2026. Na infikovaném zařízení DSM běží šifrovací program ransomware C3RB3R jako staticky propojený, UPX-zabalený x86-64 binární soubor s názvem libgldPo spuštění vymaže svůj vlastní soubor, takže běžící proces zobrazuje (smazáno) vedle cesty k proveditelnému souboru.

To, co vidíte jako vlastník zařízení zasaženého ransomwarem C3RB3R, je ve všech hlášeních stejné:

• Soubory přejmenované na name.ext.L0CK3DNěkteré zprávy uvádějí LOCK3D, ale analýzy na GitHubu uvádějí nulu.
• Výkupné oznámení s názvem read-me3.txt v každé zašifrované složce s nadpisem C3RB3R INSTRUCTIONS.
• Stránka na Toru s názvem C3rb3r Decryptor. Jeden snímek obrazovky oběti ukazoval 0,03696 BTC (asi 2 952 USD) při zaplacení do pěti dnů, přičemž poté se částka zdvojnásobila na 0,07392 BTC (asi 5 904 USD) s odpočítávacím časovačem.
• Trvalost zajištěná záznamy cronu odpovídajícími /etc/cron.d/synot*, které se samy znovu vytvářejí a v nejméně jednom případě přežily i aktualizaci DSM.
• Záložní soubory na stejném svazku byly zašifrovány spolu se vším ostatním, včetně cílů Hyper Backup a databázových výpisů.

Kde to začalo: r/synology a čínská fóra

Ransomware C3RB3R se poprvé objevil v angličtině na r/synology, kde oběti přispívaly během jednoho dne kolem 28. a 29. října 2026. Během několika hodin čtenáři říkali, že při každém obnovení subredditu se objevilo nové vlákno. Tři z těchto vláken stojí za přečtení v plném znění, protože každé přidává jinou část mozaiky:

• Forenzní rozbor. Vlastník DS918+ na DSM 7.2.1-69057 Update 5 s webovým rozhraním přístupným z internetu vypnul zařízení a zkontroloval disky v režimu pouze pro čtení na hostiteli Proxmox. Protokol ověřování DSM obsahoval požadavek na přihlášení, jehož pole účtu neslo vložené LD_PRELOAD a LD_DEBUG_OUTPUT řádky plus kódovaný příkaz shellu a soubor v /etc/cron.dTo odpovídá publikované technice CVE-2024-10441. Záloha 3-2-1 znamenala, že útok stál jen obnovení, nikoli výkupné. Přečtěte si to zde: Tak už k tomu konečně došlo. Můj první skutečný incident s ransomwarem..
• Uživatel pouze pro aplikaci Photos. Tento vlastník věřil, že DSM je aktuální, a používal pouze Synology Photos, ale na směrovači byl zapnutý UPnP. Po resetu v režimu 2 se složky pokryté funkcí Snapshot Replication vrátily. Složky bez snímků nikoli a lokální USB disk s Hyper Backup byl zašifrován společně s NAS. Přečtěte si to zde: Dnes ráno zasáhl ransomware c3rb3r.
• Diskuze o službě QuickConnect. Původní přispěvatel si toho všiml až poté, co došlo k degradaci DSM a reinstalace odhalila zašifrované soubory. V odpovědích další čtenář se silným heslem, 2FA a zapnutou službou QuickConnect uvedl, že byl také zasažen, a ostatní upozornili, že uživatelé využívající pouze aplikace mohou přístup k DSM v rozhraní QuickConnect zcela vypnout. Přečtěte si to zde: Zasažen ransomwarem C3RB3R.

Při společném čtení je vzorec jasný. Ransomware C3RB3R potřeboval pouze přihlašovací stránku DSM, ke které se mohl dostat, nic víc. Hesla ani 2FA nepomohly, protože k zneužití dochází ještě před ověřením. Forenzní rozbor to řekl jasně: požadavek se dostal k zranitelné aplikaci a další výzva k zadání hesla by to nespravila.

Hlubší technická práce probíhala v čínštině. Oběti ve skupinách na WeChatu a Xiaohongshu zveřejňovaly žádosti o výkupné, porovnávaly časové osy a navzájem se odkazovaly na repozitáře na GitHubu popsané níže. Tchajwanská komunita Synology na Facebooku shromáždila stejné odkazy pro obnovu pro místní uživatele. To dává smysl: Synology je tchajwanská společnost a její největší uživatelské komunity jsou čínsky mluvící, takže právě odtud pocházela většina případů ransomwaru C3RB3R, a tím pádem i nejrychlejší rozpoznání vzorců.

Sama společnost Synology zveřejnila bezpečnostní oznámení října 2026 s tím, že identifikovala útočníky zneužívající zranitelnost opravenou v prosinci 2024 proti zastaralým verzím DSM, a vyzvala všechny k okamžité aktualizaci.

Jak se ransomware C3RB3R dostane dovnitř

Během prvních dvou dnů existovaly dva možné vstupní body. Synology od té doby potvrdila ten starší. Její e-mail z 30. října uvádí, že útoky zneužívají pouze zranitelnost řešenou v Synology-SA-24:20 a že ransomware C3RB3R nemá nic společného s PHP2Shell. Níže uvedená tabulka zobrazuje oba kandidáty v podobě, v jaké byly diskutovány, protože dvojici 360 se stále vyplatí záplatovat.

	Synology uvádí	360 uvádí
Poradní	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, neautentizované vzdálené spuštění kódu v démonu systémového Zásuvného modulu	CVE-2026-13639 (přihlašovací logika) a CVE-2026-13684 (SCGI), obě CVSS 9.8
Opraveno	Listopad až prosinec 2024	září 2026
Opravená sestavení	DSM 7.2.2-72806 Aktualizace 1, 7.2.1-69057 Aktualizace 6, 7.2-64570 Aktualizace 4, 7.1.1-42962 Aktualizace 7	DSM 7.4-90075, 7.3.2-86009 Aktualizace 4, 7.2.2-72806 Aktualizace 9, 7.2.1-69057 Aktualizace 12

Forenzní důkazy u alespoň části obětí ukazují na starší chybu. Nejpodrobnější rozbor na Redditu shodoval své vlastní dochované protokoly s publikovaným exploitem CVE-2024-10441, přičemž poznamenal, že Synology to nepotvrdilo a že stejné zařízení bylo rovněž pod úrovní opravy SA-26:13. Rozbor uživatele soimy uvádí, že paměťové protokoly z infikovaného hosta ukazují na injektáž proměnných prostředí přes přihlašovací modul DSM, což odpovídá CVE-2024-10441, a veřejný proof of concept zneužívající pole pro přihlašovací jméno se objevil na GitHubu několik dní před propuknutím nákazy. Dva ze tří zdokumentovaných případů záchrany běžely na neoriginálním hardwaru se zaváděčem DS918+, z nichž jeden používal DSM 7.2-64570 Update 3, což je přesně o jednu aktualizaci méně, než je oprava CVE-2024-10441. Klonovaný hardware nemůže snadno přijímat oficiální aktualizace, což z něj dělá nejsnadnější cíl.

Praktický závěr se nezměnil: aktualizujte na sestavení, které pokrývá obě varování, a přestaňte vystavovat DSM do internetu. Jedna otázka však zůstala. Pokud byla trhlina opravena v prosinci 2024, proč tolik zařízení zasáhl ransomware C3RB3R během stejných dvou dnů v říjnu 2026, a to včetně některých, jejichž majitelé se domnívali, že jsou aktuální?

Nasazeno s předstihem, odpáleno na povel

Náš výklad – přičemž jde o naši interpretaci, nikoli o oficiální vyjádření Synology – spočívá v tom, že napadení ransomwarem C3RB3R a samotné šifrování jsou dvě samostatné události. Důkazy tomu nasvědčují:

• Zadní vrátka (backdoor) přišla jako první. V níže uvedeném případě z Xiaohongshu běžela zadní vrátka (backdoor shell) na NAS po dobu 37 dní a zapnula telnet s právy roota dříve, než byl zašifrován jediný soubor.
• Přežije aktualizace. Záznamy v cronu pod /etc/cron.d/synot* se znovu vytvoří a nejméně jedna oběť zjistila, že jsou stále přítomny i po přechodu na nejnovější DSM. Aktualizace sice uzavřela bezpečnostní díru, ale útočníka ponechala uvnitř.
• Odpálení byla synchronizována. Zařízení napadená ransomwarem C3RB3R v různých časech a na různých sestaveních začala šifrovat v rozmezí přibližně 48 hodin od sebe.

Tento vzorec odpovídá útočníkovi, který po celé měsíce instaloval šifrovací škodlivý kód C3RB3R na neaktualizovaná zařízení a poté se rozhodl, kdy vzdáleně stiskne spoušť. Vybral si týden s PHP2Shell, kdy byli všichni správci Synology zaneprázdněni instalací záplat, mnohá zařízení byla právě aktualizována a majitelé se cítili bezpečně. Synology jasně uvádí, že PHP2Shell nebyla cesta dovnitř. Sloužila jen jako krytí. Poučení zní: zařízení, které bylo v minulosti neaktualizované a vystavené internetu, by mělo být považováno za kompromitované, dokud nebude zkontrolováno – což je přesně to, k čemu vás nabádá první krok kontrolního seznamu Synology’s.

První reakce na ransomware C3RB3R ve 4 krocích

Pokud právě teď najdete L0CK3D soubory, pořadí následujících deseti minut rozhodne o tom, zda je obnova vůbec možná. Klíč, který odemkne vaše soubory, existuje pouze uvnitř běžícího procesu ransomwaru C3RB3R. Restart, kill -9 nebo opětovná instalace DSM jej zničí.

Příkazy pro kroky 2 a 3 vypadají takto. Před spuštěním čehokoli si přečtěte repozitáře, protože podrobnosti závisí na tom, jaký binární soubor máte.

# Krok 2: najděte šifrovací proces (jeho spustitelný soubor se zobrazuje jako smazaný)

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

# Zmrazte jej. Zde nikdy nepoužívejte kill -9.

kill -STOP <PID>	grep State /proc/<PID>/status # mělo by zobrazovat T (stopped)	# Hledejte persistenci, která jej vrací zpět	ls -l /etc/cron.d/ | grep synot
Lze to dešifrovat? Tři případy záchrany z GitHubu	Neexistuje žádný univerzální dešifrovač pro ransomware C3RB3R a každý, kdo jej prodává, pouze hádá. Existují tři pečlivé případové studie, které vám přesně řeknou, kdy obnova funguje.	Repozitář	Zařízení
Výsledek	Důvod	Repozitář	soimy/c3rb3r-rescue
DSM ve virtuálním počítači Proxmox VE spouštějící GitLab	Obnoveno	Kopie 16 GiB RAM hosta obsahovala 48bajtový klíč relace. GitLab byl obnoven s 80 projekty a 9 253 objekty LFS.	Šifrovací program se ukončil již přibližně před 30 hodinami. Úplné skeny RAM a odkládacího prostoru (swap) žádný klíč nenašly.

Třetí repozitář je nejdůležitější k přečtení, protože jeho název je zároveň jeho poučením: to, že systém nebyl restartován, neznamená, že je obnovitelný. Důležité je, zda proces ransomware C3RB3R stále běží. Jakmile se ukončí, vynuluje svůj vyrovnávací paměťový prostor pro klíč a klíč je pryč. Klíč obnovený u jedné oběti je také nepoužitelný u jiné, protože každé spuštění generuje nový relační klíč.

Proč je klíč uložen pouze v paměti

Analýza od Benjamin-zlt podrobně popisuje formát souborů ransomware C3RB3R a vysvětluje, proč to funguje a proč to obvykle nefunguje.

• Každý soubor získá svůj vlastní náhodný klíč ChaCha8. Tento klíč je zabalen pomocí hlavního relačního klíče (session master key) za použití AES-256-CBC a uložen v 588bajtové patce na konci souboru.
• Hlavní relační klíč má 48 bajtů: 16bajtový IV plus 32bajtový klíč AES. Nikdy se nezapisuje na disk. Ukazuje na něj globální ukazatel uvnitř běžícího procesu.
• Patka také obsahuje blob zabalený veřejným klíčem útočníka (RSA-2048), takže bez běžícího procesu může relační klíč obnovit pouze útočník.
• Ne každý soubor je plně zašifrován. Ve vzorku 400 souborů používalo přibližně 56 % segmentovaný režim, 31 % mělo zašifrovaný pouze první 1 MiB a 13 % bylo zašifrováno kompletně. Částečně zašifrované soubory stále nelze přečíst, ale analýza zápatí vám řekne, co zbylo.

Slabina ransomware C3RB3R je tedy úzká a časově omezená: šifrovací program uchovává hlavní klíč v paměti po celou dobu relace. Pokud jej zmrazíte během běhu, můžete klíč získat. Pokud toto okno promeškáte, zůstane vám pouze blob s veřejným klíčem, který je navržen jako neprolomitelný.

Příběh oběti: 50 TB a žádné snímky

Podrobný popis zveřejněný na Xiaohongshu dne 29. října 2026 uživatelem 柯基爱好者 sleduje jednoho člena jejich skupiny NAS během noci. Všiml si vzkazu ransomware C3RB3R, potvrdil hlavičku C3RB3R INSTRUCTIONS a byl blízko nákupu Bitcoinů, než ho skupina nasměrovala na případy na GitHubu.

Poté použil AI asistenta pro kódování přes SSH k vyšetření. Ten našel a zmrazil šifrovací program, takže od toho momentu nebylo zašifrováno nic nového. Také zjistil, že na NAS byl pravděpodobně 37 dní aktivní zadní vrátka (backdoor shell), který povolil telnet jako root, což znamená, že počáteční průnik a samotné šifrování dělil více než měsíc. Napsal skript pro sběr důkazů a správně počkal na jeho potvrzení, než cokoli spustil jako root.

Jeho štěstím bylo, že ransomware C3RB3R je pomalý. S více než 50 TB dat ke zpracování dosáhl šifrovací program pouze k jeho fotkám z roku 2024, které měly chladnou zálohu na cloudovém disku. Přesunul pracovní data na menší NAS a zašifrovaný svazek odložil na později. Jeho vlastní shrnutí bylo nekompromisní: neměl žádné snímky (snapshots) a se snímky by to bylo snadné opravit. Druhá oběť na X shrnula stejné poučení z druhé strany: RAID 6 plus tři sady záloh, vše na stejném zařízení, vše zašifrováno společně.

Jak chránit naše zálohy před ransomwarem C3RB3R

Každý z výše uvedených příběhů o ztrátě dat má stejný scénář: zálohy byly dostupné ze stroje, který byl napaden. Ransomware C3RB3R zašifruje cokoli, kam může kompromitovaný systém DSM zapisovat, takže řešením je uchovávat alespoň jednu kopii někde, kam DSM nemůže zapisovat vůbec. Takto to děláme pro weby, které hostujeme, a odpovídá to pravidlu 3-2-1-1-0.

Pravidlo	Význam	Jak to děláme
3	Tři kopie dat	Živá VM, replika na druhém NAS a plánovaný export
2	Dva druhy médií	Svazky NAS plus USB disk a cloudový disk
1	Jedna kopie mimo pracoviště	Exporty synchronizované do Google Drive pomocí Cloud Sync
1	Jedna kopie offline nebo neměnná	Snímky VM na straně hostitele, na které hostující systém nemůže dosáhnout, plus odpojený USB export
0	Nulový počet chyb při obnovení	Při přesunu VM mezi hostiteli skutečně provádíme obnovu a spouštíme systém z replik

Spouštějte Docker uvnitř Virtual DSM, nikoli na hostiteli

Naše kontejnery WordPress neběží na fyzickém NAS. Běží uvnitř hostovaného systému Virtual DSM a tento hostovaný systém je chráněn aplikací Virtual Machine Manager na hostiteli. Pokud ransomware C3RB3R získá oprávnění root uvnitř hosta, ovládne pouze tohoto hosta a nic jiného. Snímky hosta jsou uloženy na úložišti hostitele mimo souborový systém hosta, takže ransomware uvnitř VM je nemůže vidět, natož zašifrovat nebo smazat. Obnova představuje návrat k snímku v řádu minut.

VMM Pro přidává funkce, které z toho dělají skutečné zálohování: plán ochrany, který vytváří snímky VM a replikuje je na druhý NAS v clusteru, takže je pokryt i výpadek hostitele. Náš cluster se skládá z DS1621xs+ a DS1525+, které se navzájem replikují. Samostatně jsme popsali část o plánovaném exportu a Cloud Sync do Google Drive a srovnání bezplatného VMM vs VMM Pro vysvětluje, které části vyžadují licenci.

Pokud spouštíte Docker přímo v DSM, používejte neměnné snímky

Ne každý chce vrstvu VM. Pokud vaše kontejnery běží na hostiteli, obranou proti ransomwaru C3RB3R jsou neměnné snímky. Zapněte je v Snapshot Replication pro sdílenou složku, která obsahuje data vašich kontejnerů. Vyžadují DSM 7.2 nebo novější a svazek Btrfs a během období uzamčení je nemůže nikdo smazat, a to ani účet správce, kterého se útočník zmocnil. Dva detaily rozhodují o úspěchu či neúspěchu:

• Používejte namontování typu bind do sdílené složky jako například /volume1/docker/app. Pojmenované svazky Dockeru se nacházejí pod /volume1/@docker, což není sdílená složka a nelze z ní vůbec vytvářet snímky.
• Před snímkem vyexportujte databáze do souboru. Snímek běžící MariaDB je kopií jako po výpadku proudu. Plánovaný mysqldump do stejné sdílené složky vám poskytne čistý bod obnovení, který snímek následně uzamkne.
• Zvolte dobu uzamčení delší, než jakou dokáže útočník potichu čekat. Výše uvedená oběť měla v systému zadní vrátka 37 dní před zahájením šifrování. Sedm dní neměnných snímků by k dosažení čistého stavu nestačilo.

Naše další vrstva: Active Insight vytvoří snímek (snapshot), jakmile začne šifrování

Zde je vrstva, kterou většina návodů opomíjí. Active Insight, cloudová monitorovací služba společnosti Synology, dokáže sledovat souborovou aktivitu na vašich sdílených složkách, a jakmile vyhodnotí, že jde o ransomware, zareaguje sama. Synology to dokumentuje ve svém průvodci zabezpečením NAS: při zjištění ransomwarové události pošle Active Insight upozornění na událost a automaticky vytvoří snímek sdílené složky; u modelů, které to podporují, je tento snímek neměnný (immutable).

Proč na tom u ransomwaru C3RB3R obzvlášť záleží: šifrovací kód ransomwaru C3RB3R je pomalý. Oběť s více než 50 TB byla teprve u fotek z roku 2024, když si toho všimla. Snímek pořízený v momentě, kdy se poprvé objeví vzorec šifrování, zmrazí vše, co ještě nebylo zasaženo, což může být většina svazku. Zároveň nezáleží na tom, jak se ransomware C3RB3R dovnitř dostal, protože sledována je aktivita se soubory, nikoli přihlašovací stránka. Na našem DS1621xs+ zobrazuje stránka Aktivity se soubory stav ochrany před ransomwarem jako Chráněno.

Než se na to spolehnete, přečtěte si omezení. Pocházejí z dokumentace Synology’s Dokumentace k aktivitě se soubory:

• Monitorování aktivity se soubory je ve výchozím nastavení vypnuté. Zaregistrujte NAS do služby Active Insight v Ovládacím panelu a poté povolte monitorování pro jednotlivé hostitele na portálu Active Insight.
• Vyžaduje Snapshot Replication, DSM 7.2 nebo novější, Active Insight 3.0.2 nebo novější, alespoň 1 GB paměti a licenci Active Insight přiřazenou k danému NAS.
• Maximálně jeden automatický snímek na sdílenou složku za den. Jde o záchrannou síť pořízenou po detekci, nikoli o náhradu plánovaných neměnných snímků (immutable snapshots).
• Nekryto: Složky nahrávek Surveillance Station a sdílené složky na externích jednotkách USB.
• Neměnnost (immutability) závisí na modelu. U modelu bez neměnných snímků může útočník s právy roota automatický snímek stále smazat, proto jej zkombinujte s výše uvedeným plánem neměnných snímků.

Chcete stejné nastavení? SynoPower Club prodává originální licence pro oba stavební kameny: licence pro Virtual DSM (VDSM) pro spuštění vašich služeb Docker v izolovaném hostovaném systému a Licence VMM Pro pro plány ochrany, replikaci mezi NAS a živou migraci. Klíče jsou doručovány e-mailem.

Kde najít další oficiální zdroje

C3RB3R ransomware na Synology je v době psaní tohoto textu veřejně známý teprve dva dny a dosud neexistuje žádné oficiální video, proto tato sekce uvádí primární zdroje namísto návodů.

• Bezpečnostní upozornění Synology z 29. října 2026, které vyzývá uživatele zastaralých verzí DSM k okamžité aktualizaci a k zapnutí automatických aktualizací, po němž 30. října následoval e-mail zákazníkům potvrzující SA-24:20 jako jedinou dotčenou zranitelnost.
• Synology-SA-24:20 a Synology-SA-26:13 jsou tabulky verzí. Zkontrolujte své sestavení v Ovládacím panelu v části Aktualizace a obnovení vůči oběma.
• DSM ve virtuálním počítači Proxmox VE spouštějící GitLab je nejlepším přehledem všech známých případů, včetně těch zde neuvedených, a nejjasnějším vysvětlením, kdy je analýza operační paměti zbytečná.
• Tři výše odkazovaná vlákna na r/synology, zejména forenzní zpráva, která krok za krokem obsahuje příkazy pro prozkoumání disku v režimu pouze pro čtení: No, konečně k tomu došlo.

Vlastní kontrolní seznam Synology’s (30. října 2026)

E-mail od společnosti Synology zákazníkům končí čtyřmi kroky. Jsou krátké a každý z nich má v boji proti ransomwaru C3RB3R smysl:

1. Zkontrolujte přítomnost útočníků. Ransomware C3RB3R po sobě zanechává naplánované zadání pro zajištění trvalého přístupu, proto spusťte kontrolu v aplikaci Security Advisor, poté v Plánovači úloh zkontrolujte skripty, které jste nevytvořili, a v nabídce Uživatel a skupina účty správce, které jste nepřidali. Pokud se vám cokoli nezdá, kontaktujte Synology Support.
2. Vše aktualizujte. Nainstalujte nejnovější DSM v Ovládacím panelu v části Aktualizace a obnovení a poté aktualizujte každý balíček v Centru balíčků.
3. Zapněte automatické aktualizace v části Aktualizace a obnovení, aby se budoucí bezpečnostní opravy nainstalovaly ihned po vydání.
4. Udržujte zálohu mimo pracoviště. Pomocí aplikací Hyper Backup a Snapshot Replication udržujte kopii na jiném místě a pravidelně kontrolujte, zda se zálohovací úlohy skutečně dokončují.

První krok lidé často vynechávají. Pokud bylo vaše zařízení přístupné z internetu před opravou z prosince 2024, ransomware C3RB3R již mohl získat přístup a dnešní aktualizace vám neřekne, zda se uvnitř již někdo nenachází.

Bezplatný nástroj, který provede kontrolu za vás

Pokud vám nedělá problémy terminál, prvním krokem může být jediný příkaz. synology-nas-cli je open-source nástroj pro příkazovou řádku pod licencí MIT, vydaný 30. října 2026 nezávislým vývojářem jménem Akari Sora. Přihlašuje se do DSM prostřednictvím jeho webového API a kontroluje zařízení v souvislosti s touto kampaní. Projekt je na GitHubu: akari-sora/synology-nas-cli.

Před odkazováním jsme si prošli jeho kód. Používá pouze standardní knihovnu Pythonu a nekomunikuje s ničím kromě vašeho NAS, stahovacího serveru Synology, PyPI a záchranné sady soimy. Neodesílá žádnou telemetrii a základní kontrola pouze čte data. Zde je přehled toho, co kontroluje:

• Úroveň oprav. Vaši sestavu DSM vůči Synology-SA-26:13, která pokrývá i starší opravu SA-24:20, a nainstalované balíčky vůči SA-26:14.
• Vystavení do internetu. QuickConnect, přesměrování portů UPnP na routeru, firewall DSM, AutoBlock, SMB1 a vestavěný účet admin.
• Stopy po ransomware C3RB3R. Vstříknuté přihlašovací řetězce v protokolu připojení, /etc/cron.d/synot* záznamy, libgld a qnetd binární soubory, dodatečné účty root, klíče SSH a vzkazy o výkupném ve vašich sdílených složkách.
• Snímky. Sdílené složky, které nemají funkční plán snímků.

Dokáže také většinu zjištěných problémů opravit. Pokud se soubory právě šifrují, jeho příkaz contain zmrazí šifrovací proces pomocí SIGSTOP, což je stejný krok jako druhý krok v našem seznamu první pomoci. Jeho příkaz rescue následně spustí sadu soimy, která zachytí paměť a vyhledá klíč.

nas incident                 # kontrola pouze pro čtení

Než nástroji dovolíte cokoli změnit, přečtěte si tyto poznámky:

• Je zcela nový. Projekt je starý jen několik dní, pochází od jednoho vývojáře, není propojen se společností Synology a má jen malé množství externích recenzí. Začněte kontrolou pouze pro čtení a zkušebním spuštěním (dry run).
• Oprava firewallu vás může odříznout od přístupu. Přepne firewall DSM do režimu zamítnutí všeho kromě sítí, které uvedete. Spusťte jej z počítače ve stejné síti LAN a ujistěte se, že víte, kde je tlačítko RESET.
• Vypne QuickConnect. To je bezpečnější nastavení, ale pokud vaše rodina přistupuje k Synology Photos nebo Surveillance Station přes QuickConnect, nejprve nastavte VPN nebo Tailscale.
• Hloubkové skenování (deep), contain a rescue se spouštějí s právy root. Fungují prostřednictvím dočasné úlohy v Plánovači úloh, protože to je jediný způsob, jak číst protokoly přístupné pouze pro root a zmrazovat procesy.
• Soubor README doporučuje předat úlohu AI agentovi. Pokud tak učiníte, uchovávejte heslo ve správci hesel místo v chatu a opravu potvrďte sami.
• Záchrana paměti funguje pouze tehdy, když je šifrovací proces stále aktivní. Platí stejné pravidlo jako u tří případů na GitHubu.

Pokud jde o zbývající část zabezpečení, naše návody na provozování veřejného webu na Synology NAS a na co Threat Prevention vidí a co ne pokrývají síťovou stránku a průvodce opravou PHP2Shell pokrývá druhý kritický problém, který se objevil ve stejném týdnu.

Omezení C3RB3R Ransomware a bezpečnostní poznámky

Aktualizace neodstraní stávající infekci. Nejméně jedna oběť zjistila, že trvalá přítomnost v cronu zůstala i po upgradu na nejnovější DSM. Pokud jste byli vystaveni riziku bez nainstalovaných oprav, zkontrolujte /etc/cron.d, Plánovač úloh, spouštěcí skripty a povolené služby jako telnet a poté změňte všechny přihlašovací údaje.

Aktuální neznamená čistý. Jedna oběť na Redditu věřila, že DSM je aktuální, a další byla zasažena i přes aktivní 2FA a silné heslo. Zařízení, které bylo napadeno před instalací opravy, si může škodlivý kód nést skrz všechny pozdější aktualizace. Přistupujte ke každé přihlašovací stránce DSM přístupné z internetu jako k cíli, včetně těch, které byly publikovány přes UPnP bez vašeho vědomí. Pro vzdálený přístup používejte VPN nebo Tailscale a na routeru vypněte UPnP.

RAID a lokální zálohy nejsou zálohy proti C3RB3R ransomware. Cokoli, kam napadené DSM může zapisovat, bude zašifrováno, včetně cílů Hyper Backup na stejném zařízení a připojených síťových sdílení.

Neplaťte před přečtením těchto případů. Placení provozovatelům C3RB3R ransomware financuje další vlnu a nic nezaručuje. Pokud šifrovací proces stále běží, vaší nejlepší šancí je cesta přes analýzu volné paměti. Pokud neběží, reálnou cestou jsou vaše vlastní zálohy mimo dané zařízení.

Buďte opatrní, co vkládáte do AI asistenta. Nástroje AI zde pomohly několika obětem, ale nepředávejte jim hesla, obnovené klíče, úplné výpisy paměti ani firemní data. Nechte je navrhnout příkazy a vše, co vyžaduje oprávnění root, spusťte sami.

Klonovaný hardware nese dodatečné riziko. Několik zdokumentovaných obětí provozovalo DSM na neoriginálním hardwaru, kde je použití oficiálních aktualizací obtížné nebo nemožné. Pokud je to váš případ, předpokládejte, že nemáte nainstalované opravy, a zařízení zcela odpojte od internetu.

Reference

• Bezpečnostní upozornění Synology týkající se ransomwarových útoků na DSM, 29. října 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 a opravená sestavení DSM.
• Synology-SA-26:13 DSM, CVE-2026-13639 a CVE-2026-13684, zveřejněno 18. září 2026.
• Benjamin-zlt C3RB3R ransomware bare-metal záchrana, formát souboru, rozvržení klíče a postup se SIGSTOP.
• synology-nas-cli od Akari Sora, open-source nástroj pro kontrolu a reakci na tuto kampaň.
• IT-Connect ke kampani C3RB3R, shrnující atribuci 360 a časovou osu.
• Synology Knowledge Center: zvýšení zabezpečení vašeho Synology NAS, včetně toho, jak Active Insight automaticky vytvoří snímek sdílené složky, když detekuje ransomware.

Často kladené otázky

Zařiďte, aby vás příští útok ransomwaru C3RB3R stál jen obnovu, a ne výkupné. Spouštějte své služby Docker uvnitř Virtual DSM a chraňte celého hosta pomocí plánů ochrany VMM Pro replikovaných na druhý NAS. SynoPower Club prodává originální licence pro obojí, s klíči doručovanými e-mailem.