C3RB3R zsarolóprogram az Synology eszközökön: Eredete, helyreállítása és a biztonság megőrzése

C3RB3R zsarolóvírus október 28. körül kezdett megjelenni a Synology NAS egységeken, és egy napon belül ez volt az egyetlen téma az r/synology-n. A fájlok átnevezve térnek vissza egy .L0CK3D kiterjesztéssel (nulla, nem az O betű), minden mappa kap egy read-me3.txt váltságdíjkérő üzenetet, és egy Tor-portál Bitcoint kér. A leggyorsabb és leghasznosabb információk nem az angol nyelvű híroldalakról származtak. Kínai nyelvű fórumokról érkeztek, ahol a Synology hatalmas felhasználói bázissal rendelkezik, valamint három olyan GitHub-tárolóból, amelyeket olyan áldozatok hoztak létre, akik valóban visszakapták az adataikat, vagy bebizonyították, hogy nem tudják. Ez az útmutató összegyűjti, amit a C3RB3R zsarolóvírusról eddig megerősítettek: honnan származik, hogyan jut be, az egyetlen működő helyreállítási utat, és a biztonsági mentési architektúrát, amelyet azért használunk, hogy egy ilyen támadás egy helyreállításba kerüljön a váltságdíj helyett.

Frissítés, 2026. október 31.: A Synology most tisztázta a behatolási pontot. Az ügyfeleknek küldött október 30-i e-mailjében megerősítette, hogy a C3RB3R zsarolóprogram kizárólag a Synology-SA-24:20 javításban orvosolt, 2024 decemberében javított sérülékenységet használja ki, és a kampány nem kapcsolódik az ugyanabban a hónapban javított PHP2Shell sérülékenységhez. Hozzáadtuk a Synology saját, négy lépésből álló ellenőrző listáját, a mi értelmezésünket arról, miért pont akkor indultak el a támadások, amikor, valamint egy extra védelmi réteget, amelyet használunk, és amelyért a legtöbb tulajdonos már amúgy is fizet: az Active Insight zsarolóprogram elleni védelmet.

SynoPower Club pont：Egy kínai NAS-csoport egyik áldozatának több mint 50 TB adata volt egyetlen gépen, pillanatképek nélkül. A titkosító elég lassú volt ahhoz, hogy csak a 2024-es fényképeit érintse, és azokról történetesen volt egy másodlagos másolat egy felhőtárhelyen. Egy másik áldozat öt évnyi privát GitLab-tárolót veszített el, mert a RAID 6 plusz három biztonsági mentés mind ugyanazon a gépen volt. A C3RB3R zsarolóvírus nem a tárhelyüket győzte le, hanem a biztonsági mentésük kialakítását. A nyilvános oldalainkat Docker-ként futtatjuk a Virtual DSM-en belül, a teljes vendégről pillanatképet készítünk a gazdagépről, replikáljuk egy második NAS-ra, és ütemezetten exportáljuk USB-re és a felhőbe. Ha egy vendéggépet ma éjjel titkosítanak, visszagörgetjük a legutóbbi pillanatképre, és a támadó nem kap semmit.

Mi az a C3RB3R zsarolóvírus?

A C3RB3R zsarolóprogram a Cerber család linuxos változata, egy olyan zsarolóprogram-családé, amely 2016 óta létezik, és évek óta időről időre NAS-eszközöket vesz célba. A 360 ehhez köti a Synology eszközök elleni 2026. októberi hullámot. Egy fertőzött DSM-gépen a C3RB3R zsarolóprogram titkosítója statikusan linkelt, UPX-szel csomagolt x86-64 binárisként fut, amelynek neve libgld. Indítás után törli a saját fájlját, így a futó folyamat mellett a következő látható: (törölve) a végrehajtható fájljának útvonala mellett.

Amit a C3RB3R zsarolóprogram által megtámadott gép tulajdonosaként tapasztalhat, az minden jelentésben azonos:

• A fájlok át lettek nevezve erre: name.ext.L0CK3D. Néhány jelentésben így írják: .LOCK3D, de a GitHub-elemzések a nullát idézik.
• Egy zsarolóüzenet (ransom note) nevű fájl read-me3.txt minden titkosított mappában, „C3RB3R INSTRUCTIONS” fejléccel.
• Egy Tor-oldal „C3rb3r Decryptor” címmel. Az egyik áldozat képernyőképén 0,03696 BTC (kb. 2952 USD) szerepelt, ha öt napon belül kifizetik, ami ezt követően 0,07392 BTC-re (kb. 5904 USD) duplázódik, egy visszaszámláló időzítővel.
• Rendszerben maradás (persistence) a következőkkel egyező cron-bejegyzéseken keresztül: /etc/cron.d/synot*, amelyek újra létrehozzák önmagukat, és legalább egy esetben túlélték a DSM frissítését is.
• Ugyanazon a köteten található biztonsági mentési fájlok a többivel együtt titkosítva lettek, beleértve a Hyper Backup célpontokat és az adatbázis-mentéseket is.

Honnan indult: r/synology és a kínai fórumok

A C3RB3R zsarolóprogram először angolul az r/synology subredditen bukkant fel, ahol az áldozatok kb. egy napon belül, 2026. október 28. és 29. körül tettek közzé bejegyzéseket. Órákon belül az olvasók már arról számoltak be, hogy minden alkalommal új szál jelent meg, amikor frissítették a subredditet. Ebből három szálat érdemes teljes egészében elolvasni, mert mindegyik más-más részletet tesz hozzá:

• A szakértői elemzés. Egy DSM 7.2.1-69057 Update 5 rendszert futtató, internetről elérhető webes felületű DS918+ tulajdonosa leállította a gépet, és egy Proxmox gazdagépen, csak olvasható módon vizsgálta meg a lemezeket. A DSM hitelesítési naplója tartalmazott egy bejelentkezési kérést, amelynek fiókmezője injektált LD_PRELOAD és LD_DEBUG_OUTPUT sorokat, valamint egy kódolt shell parancsot és egy fájlt tartalmazott a következők alatt: /etc/cron.d. Ez megfelel a közzétett CVE-2024-10441 technikának. A 3-2-1 biztonsági mentés azt jelentette, hogy a támadás csak egy helyreállításba került, nem váltságdíjba. Itt olvasható: Nos, végül megtörtént. Az első igazi zsarolóvírus-incidensem.
• A csak Photos-t használó felhasználó. Ez a tulajdonos azt hitte, a DSM naprakész, és csak a Synology Photos-t használta, de a routeren be volt kapcsolva az UPnP. A 2-es módú reset után a Snapshot Replication által védett mappák visszatértek. A pillanatképek nélküli mappák nem, és a helyi Hyper Backup USB-meghajtó is titkosításra került a NAS-sal együtt. Itt olvasható: Ma reggel c3rb3r zsarolóvírus-támadás ért.
• A QuickConnect beszélgetés. Az eredeti bejegyzés szerzője csak azután vette észre, hogy a DSM állapota leromlott, és az újratelepítés felfedte a titkosított fájlokat. A válaszokban egy másik olvasó, akinél erős jelszó, 2FA és QuickConnect volt engedélyezve, azt mondta, hogy őt is érte támadás, mások pedig rámutattak, hogy a csak alkalmazást használó felhasználók teljesen kikapcsolhatják a DSM-hozzáférést a QuickConnectben. Itt olvasható: C3RB3R zsarolóvírus-támadás ért.

Együtt olvasva a minta egyértelmű. A C3RB3R zsarolóvírusnak mindössze egy elérhető DSM bejelentkezési oldalra volt szüksége, semmi többre. A jelszavak és a 2FA nem segítettek, mert a sérülékenység kihasználása a hitelesítés előtt fut le. A szakértői elemzés tisztázta: a kérés elért egy sérülékeny alkalmazást, és egy újabb jelszóbekérés nem oldotta volna meg a problémát.

A mélyebb technikai elemzés kínaiul zajlott. A WeChat és Xiaohongshu csoportok áldozatai váltságdíjkövető üzeneteket tettek közzé, összehasonlították az idővonalakat, és egymás figyelmébe ajánlották az alább ismertetett GitHub tárolókat. Egy tajvani Synology közösség a Facebookon összegyűjtötte ugyanezeket a helyreállítási linkeket a helyi felhasználók számára. Ez érthető: a Synology egy tajvani vállalat, és a legnagyobb felhasználói közösségei kínai nyelvűek, így a C3RB3R zsarolóvírus-esetek nagy része, és ezáltal a leggyorsabb mintafelismerés is innen származott.

Maga a Synology is közzétett egy biztonsági figyelmeztetést október 29-én kijelentette, hogy azonosította az elavult DSM-verziók ellen egy 2024 decemberében javított sebezhetőséget kihasználó támadókat, és azonnali frissítésre sürgetett mindenkit.

Hogyan jut be a C3RB3R zsarolóprogram

Az első két napban két lehetséges behatolási pont is volt. A Synology azóta megerősítette a régebbit. Az október 30-i e-mailje szerint a támadások kizárólag a Synology-SA-24:20 alatt kezelt sérülékenységet használják ki, és a C3RB3R zsarolóprogramnak semmi köze a PHP2Shell-hez. Az alábbi táblázat mindkét jelöltet mutatja, ahogyan vitatták őket, mert a 360-as pár javítását továbbra is érdemes elvégezni.

	A Synology szerint	A 360 szerint
Tanácsadó	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, hitelesítés nélküli távoli kódfuttatás a rendszer beépülő moduljának démonában	CVE-2026-13639 (bejelentkezési logika) és CVE-2026-13684 (SCGI), mindkettő CVSS 9.8
Javítva	november – december	szeptember 18.
Javított verziók	DSM 7.2.2-72806 1. frissítés, 7.2.1-69057 6. frissítés, 7.2-64570 4. frissítés, 7.1.1-42962 7. frissítés	DSM 7.4-90075, 7.3.2-86009 4. frissítés, 7.2.2-72806 9. frissítés, 7.2.1-69057 12. frissítés

A digitális igazságügyi bizonyítékok legalább az áldozatok egy részénél a régebbi hibára mutatnak. A legrészletesebb Reddit-elemzés a saját megmaradt naplóit a közzétett CVE-2024-10441 exploit hozta összefüggésbe, miközben megjegyezte, hogy a Synology ezt nem erősítette meg, és hogy ugyanaz az eszköz az SA-26:13 javítási szintje alatt volt. A soimy-féle elemzés szerint a fertőzött vendégrendszer memórianaplói környezeti változó injektálására mutatnak a DSM bejelentkezési beépülő modulján keresztül, ami megegyezik a CVE-2024-10441 hibával, és a bejelentkezési felhasználónév mezőt kihasználó nyilvános koncepcióigazolás a járvány kitörése előtt néhány nappal megjelent a GitHubon. A három dokumentált mentési esetből kettő nem eredeti hardveren futott DS918+ bootloaderrel, az egyik DSM 7.2-64570 Update 3 verzión, ami pontosan egy frissítéssel van elmaradva a CVE-2024-10441 javításától. A klónozott hardverek nem tudják egyszerűen fogadni a hivatalos frissítéseket, ami a legsebezhetőbb célponttá teszi őket.

A gyakorlati következtetés nem változott: frissítsen egy olyan verzióra, amely mindkét biztonsági figyelmeztetést lefedi, és ne tegye ki a DSM-et az internetnek. Ám egy kérdés megmaradt: ha a rést 2024 decemberében betömték, miért fertőződött meg annyi eszköz a C3RB3R zsarolóprogrammal ugyanazon a két napon 2026 októberében, beleértve azokat is, amelyek tulajdonosai azt hitték, hogy naprakészek?

Korán elhelyezve, vezényszóra robbanva

A mi olvasatunk – amely a saját értelmezésünk, és nem a Synology hivatalos álláspontja – az, hogy a C3RB3R zsarolóprogram behatolása és a titkosítás két külön esemény. A bizonyítékok erre mutatnak:

• A hátsó ajtó (backdoor) volt az első. Az alábbi Xiaohongshu esetben egy backdoor shell 37 napja élt a NAS-on, és engedélyezte a rootként futó telnetet, mielőtt egyetlen fájlt is titkosítottak volna.
• Túléli a frissítéseket. A cron bejegyzések a következők alatt: /etc/cron.d/synot* újrakészítik magukat, és legalább egy áldozat úgy találta, hogy a legújabb DSM verzióra való frissítés után is ott voltak. A frissítés betömte a rést, de a behatolót bent hagyta.
• A robbanások szinkronizálva voltak. A különböző időpontokban, különböző verziókon kompromittálódott C3RB3R zsarolóprogramos eszközök nagyjából egymástól 48 órán belül kezdték el a titkosítást.

Ez a minta egy olyan támadóra vall, aki hónapokon át telepített C3RB3R zsarolóprogram-implantátumokat a nem frissített eszközökre, majd kiválasztotta a pillanatot a távoli kioldásra. A választott pillanat a PHP2Shell hete volt, amikor minden Synology rendszergazda a frissítésekkel volt elfoglalva, sok eszközt éppen frissítettek, és a tulajdonosok biztonságban érezték magukat, mert megtették. A Synology egyértelművé tette, hogy nem a PHP2Shell volt a behatolási út. Az csak az álcázás volt. A tanulság az, hogy egy olyan eszközt, amely frissítetlenül ki volt téve a hálózatnak, ellenőrzésig kompromittáltnak kell tekinteni – pontosan erre kéri a Synology ellenőrző listájának első lépése.

Első teendők a C3RB3R zsarolóprogram esetén 4 lépésben

Ha most találja meg a .L0CK3D fájlokat, a következő tíz perc sorrendje dönt arról, hogy a helyreállítás egyáltalán lehetséges-e. A fájlokat feloldó kulcs csak a futó C3RB3R zsarolóprogram folyamatán belül létezik. Egy újraindítás, egy kill -9 vagy a DSM újratelepítése megsemmisíti azt.

A 2. és 3. lépés mögötti parancsok így néznek ki. Olvassa el a tárhelyeket (repository), mielőtt bármit futtatna, mert a részletek attól függenek, hogy melyik bináris fájllal rendelkezik.

# 2. lépés: keresse meg a titkosítót (a végrehajtható fájlja töröltként jelenik meg)

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

# Fagyassza le. Soha ne használjon kill -9 parancsot itt.

kill -STOP <PID>	grep State /proc/<PID>/status # T (stopped) értéket kell mutatnia	# Keresse meg a perzisztenciát, ami visszahozza	ls -l /etc/cron.d/ | grep synot
Visszafejthető? A három GitHub mentési eset	Nincs univerzális C3RB3R zsarolóprogram-visszafejtő, és bárki, aki ilyet árul, csak találgat. Ami létezik, az három alapos esettanulmány, amelyek pontosan megmutatják, mikor működik a helyreállítás.	Tárhely (Repository)	Gép
Eredmény	Miért	Tárhely (Repository)	soimy/c3rb3r-rescue
DSM egy Proxmox VE virtuális gépen, amely GitLabot futtat	Helyreállítva	A vendég RAM 16 GiB-os másolata tartalmazta a 48 bájtos munkamenet-kulcsot. A GitLab helyreállítva 80 projekttel és 9 253 LFS objektummal.	A titkosító már körülbelül 30 órával korábban kilépett. A teljes RAM- és swap-vizsgálat nem talált kulcsot.

A harmadik tárolót a legfontosabb elolvasni, mert a címe maga a tanulság: az, hogy soha nem indították újra, még nem jelenti azt, hogy helyreállítható. Az számít, hogy a C3RB3R zsarolóprogram folyamata még fut-e. Amint kilép, nullázza a kulcspufferét, és a kulcs végleg eltűnik. Az egyik áldozatnál helyreállított kulcs egy másiknál is használhatatlan, mert minden futtatás új munkamenet-kulcsot generál.

Miért csak a memóriában létezik a kulcs

A Benjamin-zlt elemzés részletezi a C3RB3R zsarolóprogram fájlformátumát, és elmagyarázza, miért működik ez a módszer, és miért nem szokott általában működni.

• Minden fájl saját, véletlenszerű ChaCha8 kulcsot kap. Ezt a kulcsot a rendszer egy munkamenet-főkulccsal csomagolja be AES-256-CBC használatával, és a fájl végén lévő 588 bájtos záróadatban (trailer) tárolja.
• A munkamenet-főkulcs 48 bájtos: egy 16 bájtos IV plusz egy 32 bájtos AES kulcs. Soha nem íródik lemezre. A futó folyamatban lévő globális mutató mutat rá.
• A trailer tartalmaz egy blob-ot is, amely a támadó nyilvános kulcsával van becsomagolva (RSA-2048), így a futó folyamat nélkül csak a támadó tudja helyreállítani a munkamenet-kulcsot.
• Nem minden fájl van teljesen titkosítva. Egy 400 fájlból álló mintában körülbelül 56% használt szegmentált módot, 31%-nál csak az első 1 MiB volt titkosítva, 13% pedig teljesen titkosítva volt. A részben titkosított fájlok továbbra sem olvashatók, de a lábléc (footer) elemzése megmutatja, mi maradt meg.

Így a C3RB3R zsarolóprogram gyenge pontja szűkös és időhöz kötött: a titkosító a teljes munkamenet alatt a memóriában tartja a főkulcsot. Fagyassza le futás közben, és kinyerheti a kulcsot. Ha lemarad erről az időablakról, csak a nyilvános kulccsal védett blob marad, amelyet feltörhetetlenre terveztek.

Egy áldozat története: 50 TB és nulla pillanatkép

Egy részletes beszámoló, amelyet a 柯基爱好者 nevű felhasználó tett közzé a Xiaohongshu platformon 2026. október 29-én, végigköveti NAS-csoportjuk egyik tagjának éjszakáját. Észrevette a C3RB3R zsarolóprogram üzenetét, megerősítette a C3RB3R INSTRUCTIONS fejlécet, és már majdnem Bitcoint vásárolt, mielőtt a csoport a GitHub-esetekre irányította a figyelmét.

Ezután egy AI kódolási asszisztenst használt SSH-n keresztül a kivizsgáláshoz. Az megtalálta és lefagyasztotta a titkosítót, így attól a ponttól kezdve semmi új nem került titkosításra. Azt is kiderítette, hogy egy valószínűsíthető hátsó ajtó (backdoor shell) már 37 napja jelen volt a NAS-on, és engedélyezte a rootként futó telnetet, ami azt jelenti, hogy a kezdeti behatolás és a titkosítás között több mint egy hónap telt el. Írt egy bizonyítékgyűjtő szkriptet, és helyesen megvárta a megerősítését, mielőtt bármit rootként futtatott volna.

A szerencséje az volt, hogy a C3RB3R zsarolóprogram lassú. A több mint 50 TB feldolgozandó adatból a titkosító csak a 2024-es fényképeiig jutott el, amelyekről volt egy hideg másolat a felhőben. A munkához szükséges adatokat átmozgatta egy kisebb NAS-ra, a titkosított kötetet pedig félretette későbbre. Saját összefoglalója nyers volt: nem voltak pillanatképei, pedig pillanatképekkel ezt könnyű lett volna orvosolni. Egy másik áldozat az X platformon ugyanezt a tanulságot foglalta össze a másik oldalról: RAID 6 plusz három biztonsági mentési készlet, mind ugyanazon a gépen, mind egyszerre titkosítva.

Hogyan tartjuk távol a C3RB3R zsarolóprogramot a biztonsági mentéseinktől

A fenti, adatvesztésről szóló történetek mindegyike ugyanazt a mintát követi: a biztonsági mentések elérhetők voltak arról a gépről, amelyet kompromittáltak. A C3RB3R zsarolóprogram mindent titkosít, amire a feltört DSM írni tud, így a megoldás az, hogy legalább egy másolatot olyan helyen kell tartani, ahová a DSM egyáltalán nem tud írni. Mi így csináljuk az általunk hostolt webhelyeknél, és ez tökéletesen illeszkedik a 3-2-1-1-0 szabályhoz.

Szabály	Jelentés	Hogyan csináljuk mi
3	Az adatok három másolata	Az élő VM, egy replika egy második NAS-on, és egy ütemezett exportálás
2	Kétféle adathordozó	NAS-kötetek plusz egy USB-meghajtó és egy felhőalapú meghajtó
1	Egy másolat telephelyen kívül	Exportált adatok szinkronizálva a Google Drive-ra a Cloud Sync segítségével
1	Egy másolat offline vagy módosíthatatlan	Gazdagép oldali VM-pillanatképek, amelyeket a vendéggép nem érhet el, plusz a kihúzott USB-exportálás
0	Nulla hiba a helyreállítás során	Amikor VM-eket mozgatunk a gazdagépek között, valóban helyreállítjuk és elindítjuk őket a replikákból

Futtasson Docker-t a Virtual DSM-en belül, ne a gazdagépen

A mi WordPress konténereink nem a fizikai NAS-on futnak. Egy Virtual DSM vendéggépen belül futnak, és a vendéggépet a gazdagépen lévő Virtual Machine Manager védi. Ha a C3RB3R zsarolóprogram root hozzáférést szerez a vendéggépen belül, csak azt a vendéggépet keríti hatalmába, semmi mást. A vendéggép pillanatképei a gazdagép tárhelyén élnek, a vendég fájlrendszerén kívül, így a virtuális gépen belüli zsarolóprogram nem láthatja azokat, nemhogy titkosíthatná vagy törölhetné őket. A helyreállítás csupán néhány perces pillanatkép-visszaállítást jelent.

A VMM Pro hozzáadja azokat a funkciókat, amelyek valódi biztonsági mentéssé teszik ezt: egy védelmi tervet, amely pillanatképet készít a virtuális gépről, és replikálja azt a klaszter egy második NAS-ára, így a kieső gazdagép sem jelent problémát. A mi klaszterünk egy DS1621xs+ és egy DS1525+, amelyek egymásra replikálnak. Külön megírtuk a(z) ütemezett exportálást és a Google Drive-ra történő Cloud Sync szinkronizálást részletező útmutatót, a(z) ingyenes VMM és a VMM Pro összehasonlítása pedig elmagyarázza, mely elemekhez szükséges a licenc.

Ha a Docker-t közvetlenül a DSM-en futtatja, használjon módosíthatatlan pillanatképeket

Nem mindenki akar VM-réteget. Ha a konténerei a gazdagépen futnak, a C3RB3R zsarolóprogram elleni védelem a megváltoztathatatlan pillanatképek használata. Kapcsolja be őket a Snapshot Replication segítségével arra a megosztott mappára, amely a konténeradatait tartalmazza. Ehhez DSM 7.2 vagy újabb verzió és Btrfs kötet szükséges, és a zárolási időszak alatt senki sem törölheti őket, beleértve a támadó által átvett rendszergazdai fiókot is. Két részleten múlik a siker:

• Használjon bind mount-okat egy megosztott mappába, mint például /volume1/docker/app. A Docker nevesített kötetei itt találhatók: /volume1/@docker, ami nem megosztott mappa, és egyáltalán nem készíthető róla pillanatkép.
• A pillanatkép készítése előtt mentse az adatbázisokat fájlba. Egy futó MariaDB-ről készült pillanatkép olyan, mint egy áramkimaradás utáni állapot. Egy ütemezett mysqldump Ugyanabba a megosztott mappába mentve egy tiszta helyreállítási pontot kapsz, amelyet a pillanatkép ezután zárol.
• Válassz hosszabb zárolási időszakot, mint ameddig egy támadó csendben meg tud lapulni. A fenti áldozat rendszerében 37 napig volt hátsó kapu a titkosítás megkezdése előtt. A hét napos megváltoztathatatlan pillanatképek nem nyúltak volna vissza egy tiszta állapotig.

Extra rétegünk: az Active Insight pillanatfelvételt (snapshot) készít, amint a titkosítás megkezdődik

Íme a réteg, amely elkerüli a legtöbb útmutató figyelmét. Az Active Insight, a Synology felhőalapú felügyeleti szolgáltatása, képes figyelni a megosztott mappák fájltevékenységét, és amint úgy ítéli meg, hogy zsarolóprogramot észlel, önállóan reagál. A Synology dokumentálja ezt a saját NAS biztonsági útmutatójában: amikor zsarolóprogram-eseményt észlel, az Active Insight eseményértesítést küld, és automatikusan pillanatfelvételt készít a megosztott mappáról, amely a támogatott modelleken megmásíthatatlan (immutable).

Miért számít ez különösen a C3RB3R zsarolóprogram esetében: a C3RB3R zsarolóprogram titkosítója lassú. A több mint 50 TB-tal rendelkező áldozat még csak a 2024-es fényképeinél járt, amikor észrevette. A titkosítási minta első megjelenésekor készített pillanatfelvétel lefagyaszt mindent, amihez még nem nyúltak hozzá, ami a kötet nagy része is lehet. Ráadásul az sem érdekli, hogyan jutott be a C3RB3R zsarolóprogram, mert azt figyeli, mi történik a fájlokkal, nem pedig a bejelentkezési oldalt. A mi DS1621xs+ eszközünkön a Fájltevékenység (File Activity) oldal a zsarolóprogram elleni védelmet Védett (Protected) állapotúnak mutatja.

Olvassa el a korlátozásokat, mielőtt hagyatkozna rá. Ezek a Synology Fájltevékenység (File Activity) dokumentációjából:

• A fájltevékenység-figyelés alapértelmezés szerint ki van kapcsolva. Regisztrálja a NAS-t az Active Insight szolgáltatásra a Vezérlőpultban, majd engedélyezze a figyelést az egyes gazdagépeknél az Active Insight portálon.
• Szüksége van a Snapshot Replication alkalmazásra, DSM 7.2 vagy újabb verzióra, Active Insight 3.0.2 vagy újabb verzióra, legalább 1 GB memóriára és az adott NAS-hoz hozzárendelt Active Insight licencre.
• Megosztott mappánként naponta legfeljebb egy automatikus pillanatfelvétel készíthető. Ez egy észlelés utáni biztonsági háló, nem helyettesíti az ütemezett, megmásíthatatlan pillanatfelvételeket.
• Nem terjed ki a következőkre: A Surveillance Station rögzítési mappái és a külső USB-meghajtókon lévő megosztott mappák.
• A megmásíthatatlanság (immutability) a modelltől függ. Megmásíthatatlan pillanatfelvételeket nem támogató modell esetén egy root jogosultsággal rendelkező támadó továbbra is törölheti az automatikus pillanatfelvételt, ezért kombinálja azt a fenti megmásíthatatlan ütemezéssel.

Ugyanezt a beállítást szeretnéd? A SynoPower Club eredeti licenceket árul mindkét építőelemhez: egy Virtual DSM (VDSM) licenc a Docker-szolgáltatásaid elkülönített vendégrendszerben való futtatásához, valamint egy VMM Pro licenc a védelmi tervekhez, NAS-ok közötti replikációhoz és élő migrációhoz. A kulcsok kézbesítése e-mailben történik.

Hol találhat további hivatalos forrásokat?

A C3RB3R zsarolóprogram a Synology-n a cikk írásakor mindössze két napja ismert nyilvánosan, és még nincs róla hivatalos videós beszámoló, így ez a szakasz a lépésről lépésre útmutatók helyett az elsődleges forrásokat sorolja fel.

• A Synology biztonsági figyelmeztetése október 29-i dátummal, amely felszólítja az elavult DSM-et használókat az azonnali frissítésre és az automatikus frissítések engedélyezésére, amit október 30-án egy ügyfeleknek küldött e-mail követett, megerősítve, hogy az SA-24:20 az egyetlen érintett sérülékenység.
• Synology-SA-24:20 és Synology-SA-26:13 a verziótáblázatok. Ellenőrizd a buildedet a Vezérlőpultban, majd a Frissítés és helyreállítás menüpontban mindkettővel összevetve.
• DSM egy Proxmox VE virtuális gépen, amely GitLabot futtat az összes ismert eset legjobb indexe, beleértve az itt nem említetteket is, és a legvilágosabb magyarázat arra, hogy mikor értelmetlen a memória-forensiker elemzés.
• A fent belinkelt három r/synology téma, különösen a forensiker elemzésről szóló leírás, amely lépésről lépésre tartalmazza a csak olvasható lemezvizsgálati parancsokat: Nos, végül megtörtént.

A Synology saját ellenőrző listája (2026. október 30.)

A Synology ügyfeleknek küldött e-mailje négy lépéssel zárul. Ezek rövidek, és mindegyik számít a C3RB3R zsarolóprogram elleni védekezésben:

1. Ellenőrizze a behatolókat. A C3RB3R zsarolóprogram ütemezett jelenlétet hagy maga után, ezért futtasson egy Security Advisor vizsgálatot, majd keresse meg a Feladatütemezőben azokat a szkripteket, amelyeket nem Ön hozott létre, valamint a Felhasználó és csoport menüpontban azokat az adminisztrátori fiókokat, amelyeket nem Ön adott hozzá. Ha bármi gyanúsnak tűnik, lépjen kapcsolatba a Synology Supporttal.
2. Frissítsen mindent. Telepítse a legújabb DSM rendszert a Vezérlőpult > Frissítés és helyreállítás menüpontban, majd frissítsen minden csomagot a Csomagkezelési központban.
3. Kapcsolja be az automatikus frissítéseket a Frissítés és helyreállítás menüpontban, hogy a jövőbeli biztonsági javítások a megjelenésük pillanatában megérkezzenek.
4. Tartson egy külső helyszíni biztonsági mentést. Használja a Hyper Backup és a Snapshot Replication alkalmazást egy másolat külön helyen való tárolásához, és rendszeresen ellenőrizze, hogy a biztonsági mentési feladatok valóban befejeződnek-e.

Az első lépés az, amit az emberek kihagynak. Ha az Ön eszköze elérhető volt az internetről a 2024. decemberi javítás előtt, a C3RB3R zsarolóprogram már megvethette a lábát, és a mai frissítés nem jelzi, hogy valaki már jelen van-e a rendszerben.

Egy ingyenes eszköz, amely elvégzi az ellenőrzést Ön helyett

Ha magabiztosan használja a terminált, az első lépés mostantól egyetlen parancs is lehet. A synology-nas-cli egy MIT-licenc alatt kibocsátott nyílt forráskódú parancssori eszköz, amelyet 2026. október 30-án adott ki Akari Sora független fejlesztő. A webes API-ján keresztül jelentkezik be a DSM rendszerbe, és ellenőrzi a gépet ezzel a kampánnyal szemben. A projekt megtalálható a GitHubon: akari-sora/synology-nas-cli.

Átnéztük a kódját, mielőtt belinkeltük volna. Kizárólag a Python standard könyvtárát használja, és semmi mással nem kommunikál, csak az Ön NAS-ával, a Synology letöltőszerverével, a PyPI-vel és a soimy mentőkészlettel. Nem küld telemetriát, és az alapvető ellenőrzés csak olvasási műveletet végez. A következőket ellenőrzi:

• Javítócsomag-szint. Az Ön DSM verziója a Synology-SA-26:13-mal szemben (amely a régebbi SA-24:20 javítást is tartalmazza), valamint a telepített csomagjai a SA-26:14-gyel szemben.
• Kitettség. QuickConnect, UPnP porttovábbítás a útválasztón, a DSM tűzfal, AutoBlock, SMB1 és a beépített admin fiók.
• C3RB3R zsarolóvírus nyomai. A kapcsolatnaplóba bejuttatott bejelentkezési karakterláncok, /etc/cron.d/synot* bejegyzések, a libgld és qnetd binárisok, extra root fiókok, SSH-kulcsok és váltságdíj-követelő üzenetek a megosztásokon.
• Pillanatképek. Megosztott mappák, amelyek nem rendelkeznek működő pillanatkép-ütemezéssel.

A talált problémák többségét javítani is tudja. Ha a fájlok titkosítása éppen most zajlik, a contain parancsa lefagyasztja a titkosítót SIGSTOP jellel – ugyanaz a lépés, mint az elsősegély-listánk második lépése. A rescue parancsa ezután a soimy eszközkészletet futtatja a memória rögzítéséhez és a kulcs kereséséhez.

nas incident                 # csak olvasható ellenőrzés

nas incident --deep # keresi az implantátumot is (egy csak olvasható root szkript)

• nas incident fix --dry-run # felsorol minden módosítást, amit tenne, de semmit sem változtat meg. Olvassa el ezeket a megjegyzéseket, mielőtt bármit is hagyna megváltoztatni:.
• Teljesen új. A projekt néhány napos, egyetlen fejlesztőtől származik, nem áll kapcsolatban a Synology céggel, és még kevés külső áttekintést kapott. Kezdje a csak olvasható ellenőrzéssel és a próbaüzemmel (dry run).
• A tűzfal javítása kizárhatja Önt. A DSM tűzfalat úgy állítja át, hogy mindent megtagadjon, kivéve az Ön által felsorolt hálózatokat. Ugyanazon a helyi hálózaton (LAN) lévő számítógépről futtassa, és tudja, hol található a RESET gomb.
• Kikapcsolja a QuickConnect funkciót. Ez a biztonságosabb beállítás, de ha a családja a Synology Photos vagy Surveillance Station szolgáltatást QuickConnecten keresztül éri el, előbb állítson be VPN-t vagy Tailscale-t.
• A deep scan, a contain és a rescue root jogosultsággal futnak. Egy ideiglenes Feladatütemező (Task Scheduler) feladaton keresztül működnek, mert ez az egyetlen módja a csak root által olvasható naplók olvasásának és a folyamatok befagyasztásának.
• A README azt javasolja, hogy adja át egy AI ágensnek. Ha így tesz, a jelszót inkább egy jelszókezelőben tartsa, ne a chatben, és a javítást saját maga hagyja jóvá.

A rendszervédelem többi részéhez az alábbi útmutatóink: nyilvános weboldal futtatása Synology NAS-on és a mit lát és mit nem lát a Threat Prevention lefedik a hálózati oldalt, a PHP2Shell javítási útmutató pedig a másik kritikus problémát tárgyalja, amely ugyanazon a héten érkezett.

C3RB3R zsarolóprogram korlátai és biztonsági megjegyzések

A frissítés nem távolítja el a már meglévő fertőzést. Legalább egy áldozat úgy találta, hogy a cron általi jelenlét a legújabb DSM-re való frissítés után is megmaradt. Ha frissítés nélkül voltál kitéve a veszélynek, ellenőrizd a /etc/cron.d, a Feladatütemezőt, az indítóscriptet és az engedélyezett szolgáltatásokat, mint például a telnetet, majd cserélj le minden hitelesítési adatot.

A naprakész nem ugyanaz, mint a tiszta. Egy Reddit-áldozat azt hitte, hogy a DSM naprakész, egy másikat pedig úgy ért támadás, hogy be volt kapcsolva a 2FA és az erős jelszó. Egy olyan eszköz, amelybe a javítás előtt törtek be, minden későbbi frissítésen át hordozhatja a kártékony kódot. Kezeljen minden, az internetről elérhető DSM bejelentkezési oldalt célpontként, beleértve azokat is, amelyeket az UPnP tett közzé, és amelyeket soha nem állított be szándékosan. Használjon VPN-t vagy Tailscale-t a távoli eléréshez, és kapcsolja ki az UPnP-t a útválasztón.

A RAID és a helyi biztonsági mentések nem jelentenek védelmet a C3RB3R zsarolóprogram ellen. Bármi, amire a kompromittált DSM írni tud, titkosításra kerül, beleértve az ugyanazon az eszközön lévő Hyper Backup célpontokat és a csatlakoztatott hálózati megosztásokat is.

Ne fizess az esetek elolvasása előtt. A C3RB3R zsarolóprogram üzemeltetőinek történő fizetés a következő hullámot finanszírozza, és semmit sem garantál. Ha a titkosító még fut, a szabad memória kinyerési útvonala a legjobb esélyed. Ha nem fut, a reális lehetőséget a saját, eszközön kívüli másolataid jelentik.

Legyél óvatos azzal, amit beillesztesz egy AI-asszisztensbe. Az AI-eszközök több áldozatnak is segítettek itt, de ne adj át nekik jelszavakat, helyreállított kulcsokat, teljes memóriaképeket vagy üzleti adatokat. Hagyd, hogy parancsokat javasoljanak, és futtass mindent magad, aminek root jogosultságra van szüksége.

A klónozott hardver további kockázatot hordoz. Több dokumentált áldozat nem eredeti hardveren futtatott DSM-et, ahol a hivatalos frissítéseket nehéz vagy lehetetlen alkalmazni. Ha ez a te beállításod, tételezd fel, hogy a rendszered nem frissített, és teljesen zárd el az internettől.

Hivatkozások

• Synology biztonsági figyelmeztetés a DSM zsarolóprogram-támadásokról, 2026. október 29.
• Synology-SA-24:20 DSM (Pwn2Own 2024), a CVE-2024-10441 és a javított DSM buildek.
• Synology-SA-26:13 DSM, CVE-2026-13639 és CVE-2026-13684, közzétéve: 2026. szeptember 18.
• Benjamin-zlt C3RB3R ransomware bare-metal mentés, a fájlformátum, a kulcselrendezés és a SIGSTOP munkafolyamat.
• A memóriamentés csak akkor működik, ha a titkosító még fut., Ugyanaz a szabály érvényes, mint a három GitHub-esetben.
• IT-Connect a C3RB3R kampányról, összefoglalva a 360-as tulajdonítást és az idővonalat.
• Synology Tudásközpont: a Synology NAS biztonságának növelése, beleértve azt is, hogyan készít pillanatképet az Active Insight egy megosztott mappáról, amikor zsarolóprogramot észlel.

Gyakran Ismételt Kérdések

Érje el, hogy a következő C3RB3R zsarolóvírus-támadás legfeljebb egy helyreállításba kerüljön, ne pedig váltságdíjba. Futtassa Docker szolgáltatásait a Virtual DSM-en belül, és védje a teljes vendéggépet VMM Pro védelmi tervekkel, egy második NAS-ra replikálva. A SynoPower Club eredeti licenceket árul mindkettőhöz, a licenckulcsokat e-mailben kézbesítve.