Ransomware C3RB3R na Synology: Pochodzenie, odzyskiwanie danych i jak zadbać o bezpieczeństwo

Ransomware C3RB3R zaczął pojawiać się na urządzeniach Synology NAS około 28 października 2026 r., a w ciągu jednego dnia stał się jedynym tematem na r/synology. Pliki zostają zmienione i otrzymują L0CK3D rozszerzenie (zero, nie litera O), a każdy folder otrzymuje read-me3.txt żądanie okupu w pliku tekstowym, a portal w sieci Tor żąda opłaty w Bitcoinach. Najszybsze i najbardziej przydatne informacje nie pochodziły z anglojęzycznych serwisów informacyjnych. Pochodziły z chińskojęzycznych forów, gdzie Synology ma ogromną bazę użytkowników, oraz z trzech repozytoriów GitHub stworzonych przez ofiary, które faktycznie odzyskały swoje dane lub udowodniły, że nie jest to możliwe. Ten przewodnik zbiera to, co do tej pory potwierdzono na temat ransomware C3RB3R: skąd się wziął, jak się przedostaje, jedyną ścieżkę odzyskiwania danych, która zadziałała, oraz koncepcję kopii zapasowych, którą stosujemy, aby taki atak kosztował nas jedynie przywrócenie danych, a nie okup.

Aktualizacja, 31 października 2026 r.: Firma Synology ustaliła już punkt wejścia. W wiadomości e-mail do klientów z 30 października potwierdziła, że ransomware C3RB3R wykorzystuje wyłącznie lukę naprawioną w Synology-SA-24:20, załataną w grudniu 2024 roku, a kampania ta nie jest powiązana z luką PHP2Shell załataną w tym samym miesiącu. Dodaliśmy własną czteroetapową listę kontrolną Synology, naszą interpretację, dlaczego ataki nastąpiły w tym konkretnym momencie, oraz jedną dodatkową warstwę, z której korzystamy, a za którą większość właścicieli już płaci: ochronę przed ransomware w Active Insight.

Punkt SynoPower Club:Jedna z ofiar na chińskiej grupie NAS miała ponad 50 TB na jednym urządzeniu i brak migawek. Proces szyfrowania był na tyle wolny, że dotknął tylko jej zdjęcia z 2024 roku, a te akurat miały zimną kopię w chmurze. Inna osoba straciła pięć lat prywatnych repozytoriów GitLab, ponieważ RAID 6 i trzy kopie zapasowe znajdowały się na tej samej maszynie. Ransomware C3RB3R nie pokonał ich pamięci masowej, pokonał ich architekturę kopii zapasowych. Nasze publiczne witryny uruchamiamy jako Docker wewnątrz Virtual DSM, robimy migawkę całego systemu gościa z poziomu hosta, replikujemy ją na drugi NAS i harmonogramowo eksportujemy na USB oraz do chmury. Jeśli system gościa zostanie dziś w nocy zaszyfrowany, przywracamy go do ostatniej migawki, a atakujący nic nie zyskuje.

Czym jest ransomware C3RB3R?

Ransomware C3RB3R to wersja dla systemu Linux z rodziny Cerber – linii oprogramowania ransomware istniejącej od 2016 roku, która od lat z przerwami atakuje urządzenia NAS. Firma 360 przypisuje mu falę ataków na Synology z października 2026 roku. Na zainfekowanym urządzeniu DSM proces szyfrujący ransomware C3RB3R działa jako statycznie zlinkowany, spakowany programem UPX plik binarny x86-64 o nazwie libgld. Po uruchomieniu usuwa własny plik, więc uruchomiony proces wyświetla (usunięto) obok ścieżki pliku wykonywalnego.

To, co widzisz jako właściciel serwera zaatakowanego przez ransomware C3RB3R, jest spójne we wszystkich zgłoszeniach:

• Pliki ze zmienioną nazwą na name.ext.L0CK3D. Niektóre raporty podają pisownię LOCK3D, ale analizy na GitHubie cytują wersję z zerem.
• Plik z żądaniem okupu o nazwie read-me3.txt w każdym zaszyfrowanym folderze, z nagłówkiem C3RB3R INSTRUCTIONS.
• Strona w sieci Tor zatytułowana C3rb3r Decryptor. Zrzut ekranu jednej z ofiar pokazywał kwotę 0,03696 BTC (około 2952 USD) w przypadku wpłaty w ciągu pięciu dni, wzrastającą dwukrotnie do 0,07392 BTC (około 5904 USD) po tym czasie, wraz z odliczającym zegarem.
• Utrzymywanie się w systemie poprzez wpisy cron pasujące do /etc/cron.d/synot*, które odtwarzają się same i w co najmniej jednym przypadku przetrwały aktualizację DSM.
• Pliki kopii zapasowych na tym samym wolumenie zaszyfrowane wraz ze wszystkim innym, w tym miejsca docelowe Hyper Backup i zrzuty baz danych.

Gdzie to się zaczęło: r/synology i chińskie fora

Ransomware C3RB3R po raz pierwszy pojawił się w języku angielskim na r/synology, gdzie ofiary publikowały wpisy w odstępie około jednego dnia, w dniach 28 i 29 października 2026 r. W ciągu kilku godzin czytelnicy zgłaszali, że nowy wątek pojawiał się przy każdym odświeżeniu subreddita. Trzy z tych wątków warto przeczytać w całości, ponieważ każdy z nich wnosi inny element:

• Analiza śledcza. Właściciel DS918+ z systemem DSM 7.2.1-69057 Update 5, z interfejsem sieciowym dostępnym z Internetu, wyłączył serwer i zbadał dyski w trybie tylko do odczytu na hoście Proxmox. Dziennik uwierzytelniania DSM zawierał żądanie logowania, którego pole konta zawierało wstrzyknięte linie LD_PRELOAD i LD_DEBUG_OUTPUT oraz zakodowane polecenie powłoki, a także plik w /etc/cron.d. Odpowiada to opublikowanej technice CVE-2024-10441. Kopia zapasowa 3-2-1 sprawiła, że atak kosztował jedynie przywrócenie danych, a nie okup. Przeczytaj o tym tutaj: Cóż, w końcu to się stało. Mój pierwszy prawdziwy incydent z ransomware.
• Użytkownik korzystający tylko z Photos. Ten właściciel wierzył, że DSM jest aktualny i używał tylko Synology Photos, ale funkcja UPnP w routerze była włączona. Po zresetowaniu w trybie 2 foldery objęte funkcją Snapshot Replication powróciły. Foldery bez migawek – nie, a lokalny dysk USB z Hyper Backup został zaszyfrowany razem z NAS. Przeczytaj o tym tutaj: Zaatakowany przez ransomware c3rb3r dziś rano.
• Dyskusja na temat QuickConnect. Autor wpisu zauważył problem dopiero po awarii DSM, gdy ponowna instalacja ujawniła zaszyfrowane pliki. W odpowiedziach inny czytelnik ze silnym hasłem, 2FA i włączonym QuickConnect napisał, że również został zaatakowany, a inni zwrócili uwagę, że użytkownicy korzystający tylko z aplikacji mogą całkowicie wyłączyć dostęp do DSM w QuickConnect. Przeczytaj o tym tutaj: Zaatakowany przez ransomware C3RB3R.

Analizując te przypadki razem, schemat jest jasny. Ransomware C3RB3R potrzebował jedynie dostępnej dla niego strony logowania DSM, niczego więcej. Hasła i 2FA nie pomogły, ponieważ exploit uruchamia się przed uwierzytelnieniem. W analizie śledczej ujęto to wprost: żądanie dotarło do podatnej aplikacji i kolejne zapytanie o hasło niczego by nie zmieniło.

Głębsze prace techniczne odbywały się w języku chińskim. Ofiary w grupach na WeChat i Xiaohongshu publikowały żądania okupu, porównywały linie czasowe i odsyłały się nawzajem do repozytoriów na GitHubie opisanych poniżej. Tajwańska społeczność Synology na Facebooku zebrała te same linki do odzyskiwania danych dla lokalnych użytkowników. Ma to sens: Synology to tajwańska firma, a jej największe społeczności użytkowników są chińskojęzyczne, stąd też wzięła się tam największa liczba przypadków ransomware C3RB3R, a co za tym idzie – najszybsze rozpoznawanie wzorców.

Sama firma Synology opublikowała komunikat bezpieczeństwa 29 października 2026 r., informując o zidentyfikowaniu podmiotów zagrażających wykorzystujących lukę załataną w grudniu 2024 r. w nieaktualnych wersjach DSM, i wzywając wszystkich do natychmiastowej aktualizacji.

Jak ransomware C3RB3R przedostaje się do systemu

Przez pierwsze dwa dni istniały dwa potencjalne punkty wejścia. Synology od tego czasu potwierdziło ten starszy. E-mail z 30 października wyjaśnia, że ataki wykorzystują tylko lukę załataną w Synology-SA-24:20, a ransomware C3RB3R nie ma nic wspólnego z PHP2Shell. Poniższa tabela przedstawia oba warianty tak, jak były omawiane, ponieważ parę 360 nadal warto załatać.

	Synology twierdzi	360 twierdzi
Doradczy	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, zdalne wykonanie kodu bez uwierzytelnienia w demonie wtyczki systemowej	CVE-2026-13639 (logika logowania) i CVE-2026-13684 (SCGI), oba CVSS 9.8
Załatane	Listopad do grudnia 2024 r.	18 września 2026 r.
Poprawione kompilacje	DSM 7.2.2-72806 Aktualizacja 1, 7.2.1-69057 Aktualizacja 6, 7.2-64570 Aktualizacja 4, 7.1.1-42962 Aktualizacja 7	DSM 7.4-90075, 7.3.2-86009 Aktualizacja 4, 7.2.2-72806 Aktualizacja 9, 7.2.1-69057 Aktualizacja 12

Dowody śledcze wskazują na starszy błąd u przynajmniej części ofiar. Najbardziej szczegółowy opis na Reddicie dopasował własne zachowane logi do opublikowanego exploita CVE-2024-10441, zauważając jednocześnie, że Synology tego nie potwierdziło, a ten sam serwer był również poniżej poziomu poprawki SA-26:13. W opisie użytkownika soimy podano, że logi pamięci zainfekowanej maszyny wirtualnej wskazują na wstrzyknięcie zmiennych środowiskowych przez wtyczkę logowania DSM, co jest zgodne z CVE-2024-10441, a publiczny dowód koncepcji (PoC) wykorzystujący pole nazwy użytkownika pojawił się na GitHubie na kilka dni przed atakiem. Dwa z trzech udokumentowanych przypadków ratunkowych działały na nieoryginalnym sprzęcie z bootloaderem DS918+, z czego jeden na DSM 7.2-64570 Update 3, czyli dokładnie o jedną aktualizację przed poprawką CVE-2024-10441. Sprzęt typu klon nie może łatwo przyjmować oficjalnych aktualizacji, co czyni go najłatwiejszym celem.

Praktyczny wniosek się nie zmienił: zaktualizuj system do kompilacji obejmującej oba ostrzeżenia i przestań wystawiać DSM na działanie Internetu. Ale jedno pytanie pozostało. Jeśli luka została załatana w grudniu 2024 roku, dlaczego tak wiele urządzeń zostało zainfekowanych ransomware C3RB3R w ciągu tych samych dwóch dni w październiku 2026 roku, w tym niektóre, których właściciele byli przekonani, że mają aktualny system?

Umieszczony wcześniej, zdetonowany na zawołanie

Nasza interpretacja – będąca naszym własnym wnioskiem, a nie oficjalnym oświadczeniem Synology – wskazuje, że włamanie ransomware C3RB3R i samo szyfrowanie to dwa osobne zdarzenia. Dowody na to wskazują:

• Backdoor pojawił się jako pierwszy. W opisanym poniżej przypadku z Xiaohongshu powłoka backdoor znajdowała się na serwerze NAS przez 37 dni i włączyła telnet jako root, zanim chociaż jeden plik został zaszyfrowany.
• Przetrwa aktualizacje. Wpisy cron w /etc/cron.d/synot* odtwarzają się same, a przynajmniej jedna poszkodowana osoba znalazła je wciąż aktywne po aktualizacji do najnowszej wersji DSM. Aktualizacja zamknęła lukę, ale pozostawiła intruza wewnątrz.
• Detonacje były zsynchronizowane. Urządzenia z zainstalowanym ransomware C3RB3R, które zostały zainfekowane w różnym czasie i na różnych kompilacjach, rozpoczęły szyfrowanie w odstępie około 48 godzin od siebie.

Ten wzorzec pasuje do atakującego, który miesiącami umieszczał infekcje ransomware C3RB3R na niezałatanych urządzeniach, a następnie zdalnie ustalił moment ataku. Wybranym momentem był tydzień PHP2Shell, kiedy każdy administrator Synology był zajęty łataniem, wiele urządzeń zostało właśnie zaktualizowanych, a właściciele czuli się bezpiecznie. Synology jednoznacznie twierdzi, że PHP2Shell nie był drogą wejścia. Służył jako przykrywka. Wniosek jest taki, że urządzenie, które było wystawione na atak przed instalacją poprawek, należy traktować jako zainfekowane do czasu przeprowadzenia weryfikacji – czyli dokładnie tego, do czego zachęca pierwszy krok listy kontrolnej Synology.

Pierwsza reakcja na ransomware C3RB3R w 4 krokach

Jeśli znajdziesz L0CK3D pliki w tej chwili, kolejność działań w ciągu najbliższych dziesięciu minut decyduje o tym, czy odzyskanie jest w ogóle możliwe. Klucz odblokowujący Twoje pliki istnieje tylko wewnątrz uruchomionego procesu ransomware C3RB3R. Ponowne uruchomienie, kill -9 lub ponowna instalacja DSM go zniszczy.

Polecenia dla kroków 2 i 3 wyglądają następująco. Przeczytaj instrukcje w repozytoriach przed uruchomieniem czegokolwiek, ponieważ szczegóły zależą od posiadanego pliku binarnego.

# Krok 2: znajdź proces szyfrujący (jego plik wykonywalny wyświetla się jako usunięty)

Czy możesz to odszyfrować? Trzy przypadki ratunkowe z GitHuba

Nie istnieje uniwersalne narzędzie do odszyfrowywania C3RB3R ransomware, a każdy, kto takie sprzedaje, zgaduje. Istnieją natomiast trzy szczegółowe studia przypadków, które dokładnie pokazują, kiedy odzyskanie danych jest możliwe.

Repozytorium	Maszyna	Wynik	Dlaczego
soimy/c3rb3r-rescue	DSM w maszynie wirtualnej Proxmox VE uruchamiającej GitLab	Odzyskano	Kopia pamięci RAM gościa o rozmiarze 16 GiB zawierała 48-bajtowy klucz sesyjny. GitLab został przywrócony wraz z 80 projektami i 9253 obiektami LFS.
Benjamin-zlt/c3rb3r-baremetal-rescue	Klon DS918+ na sprzęcie fizycznym (bare-metal), DSM 7.2	Odzyskano	Zamrożono działający proces szyfrujący za pomocą SIGSTOP i zrzucono około 2 GB jego pamięci. Odszyfrowano 84 500 plików (ok. 940 GB) w 2,5 godziny.
lllong1377/c3rb3r-never-rebooted-still-no-key	Klon DS918+, DSM 7.2-64570 Update 3, 149 dni czasu pracy (uptime)	Nie odzyskano	Program szyfrujący zakończył działanie około 30 godzin wcześniej. Pełne skanowanie pamięci RAM i przestrzeni swap nie wykazało żadnego klucza.

Trzecie repozytorium jest najważniejsze do przeczytania, ponieważ jego tytuł zawiera lekcję: brak ponownego uruchomienia nie oznacza możliwości odzyskania danych. Liczy się to, czy proces ransomware C3RB3R nadal działa. Gdy się zakończy, zeruje bufor klucza i klucz przepada. Klucz odzyskany u jednej ofiary jest bezużyteczny u innej, ponieważ każde uruchomienie generuje nowy klucz sesji.

Dlaczego klucz istnieje tylko w pamięci

Analiza zrobiona przez Benjamin-zlt szczegółowo opisuje format plików ransomware C3RB3R i wyjaśnia zarówno, dlaczego to działa, jak i dlaczego zazwyczaj nie przynosi efektu.

• Każdy plik otrzymuje własny, losowy klucz ChaCha8. Klucz ten jest szyfrowany głównym kluczem sesji przy użyciu algorytmu AES-256-CBC i przechowywany w 588-bajtowej stopce na końcu pliku.
• Główny klucz sesji ma 48 bajtów: 16-bajtowy IV plus 32-bajtowy klucz AES. Nigdy nie jest zapisywany na dysku. Wskazuje na niego globalny wskaźnik wewnątrz działającego procesu.
• Stopka zawiera również obiekt blob zaszyfrowany kluczem publicznym napastnika (RSA-2048), więc bez działającego procesu tylko napastnik może odzyskać klucz sesji.
• Nie każdy plik jest w pełni zaszyfrowany. W próbie 400 plików około 56% używało trybu segmentowego, 31% miało zaszyfrowany tylko pierwszy 1 MiB, a 13% było zaszyfrowanych od początku do końca. Częściowo zaszyfrowane pliki nadal nie są czytelne, ale analiza stopki pozwala ustalić, co pozostało.

Słabość ransomware C3RB3R jest więc wąska i ograniczona czasowo: program szyfrujący trzyma klucz główny w pamięci przez całą sesję. Zamroź go, gdy działa, a będziesz mógł wyciągnąć klucz. Przegap to okno, a zostaniesz z obiektem blob zaszyfrowanym kluczem publicznym, który został zaprojektowany tak, aby był niemożliwy do złamania.

Historia ofiary: 50 TB i brak migawek

Szczegółowa relacja opublikowana na platformie Xiaohongshu 29 października 2026 r. przez użytkownika 柯基爱好者 opisuje nocne zmagania jednego z członków ich grupy NAS. Zauważył on informację od ransomware C3RB3R, potwierdził nagłówek C3RB3R INSTRUCTIONS i był bliski zakupu bitcoinów, zanim grupa przekierowała go do przypadków opisanych na GitHubie.

Następnie użył asystenta programistycznego AI przez SSH do przeprowadzenia dochodzenia. Wykrył on i zamroził program szyfrujący, dzięki czemu od tego momentu żaden nowy plik nie został zaszyfrowany. Ustalił również, że prawdopodobny tylny połączony shell (backdoor) znajdował się na serwerze NAS od 37 dni i włączył telnet jako root, co oznacza, że pierwsze włamanie i szyfrowanie dzielił ponad miesiąc. Napisał skrypt do zbierania dowodów i, prawidłowo, czekał na jego potwierdzenie przed uruchomieniem czegokolwiek jako root.

Jego szczęście polegało na tym, że ransomware C3RB3R działa wolno. Mając do przetworzenia ponad 50 TB, program szyfrujący dotarł jedynie do jego zdjęć z 2024 roku, a te miały zimną kopię zapasową w chmurze. Przeniósł robocze dane na mniejszy NAS i odłożył zaszyfrowany wolumen na później. Jego własne podsumowanie było dosadne: nie miał migawek, a dzięki migawkom problem ten byłby łatwy do naprawienia. Druga ofiara w serwisie X podsumowała tę samą lekcję z drugiej strony: RAID 6 plus trzy zestawy kopii zapasowych, wszystkie na tym samym urządzeniu, wszystkie zaszyfrowane razem.

Jak chronimy nasze kopie zapasowe przed ransomware C3RB3R

Każda powyższa historia utraty danych ma ten sam schemat: kopie zapasowe były dostępne z poziomu przejętego urządzenia. Ransomware C3RB3R szyfruje wszystko, do czego przejęty DSM ma dostęp do zapisu, więc rozwiązaniem jest przechowywanie co najmniej jednej kopii tam, gdzie DSM w ogóle nie może nic zapisać. Tak właśnie robimy w przypadku hostowanych przez nas witryn, co odpowiada zasadzie 3-2-1-1-0.

Zasada	Znaczenie	Jak to robimy
3	Trzy kopie danych	Działająca maszyna wirtualna VM, replika na drugim serwerze NAS i zaplanowany eksport
2	Dwa rodzaje nośników	Wolumeny NAS oraz dysk USB i dysk w chmurze
1	Jedna kopia poza siedzibą firmy	Eksporty zsynchronizowane z Google Drive za pomocą Cloud Sync
1	Jedna kopia offline lub niezmienna	Migawki maszyn wirtualnych po stronie hosta, których system-gość nie może modyfikować, plus odłączony eksport USB
0	Zero błędów podczas odzyskiwania	Faktycznie przywracamy i uruchamiamy dane z replik podczas przenoszenia maszyn wirtualnych między hostami

Uruchamiaj Docker wewnątrz Virtual DSM, a nie na hoście

Nasze kontenery WordPress nie działają bezpośrednio na fizycznym serwerze NAS. Działają wewnątrz gościa Virtual DSM, a gość jest chroniony przez Virtual Machine Manager na hoście. Jeśli ransomware C3RB3R uzyska dostęp root wewnątrz gościa, przejmuje tylko tego gościa i nic więcej. Migawki gościa znajdują się w pamięci masowej hosta, poza systemem plików gościa, więc ransomware wewnątrz maszyny wirtualnej nie może ich zobaczyć, a tym bardziej zaszyfrować ani usunąć. Odzyskiwanie polega na przywróceniu migawki, co zajmuje zaledwie kilka minut.

VMM Pro dodaje elementy, które zmieniają to w prawdziwą kopię zapasową: plan ochrony, który tworzy migawkę maszyny wirtualnej i replikuje ją do drugiego serwera NAS w klastrze, dzięki czemu uszkodzenie hosta jest również zabezpieczone. Nasz klaster składa się z urządzeń DS1621xs+ oraz DS1525+, które replikują dane między sobą. Opisaliśmy zaplanowany eksport i Cloud Sync do Google Drive osobno, a porównanie bezpłatnego VMM z VMM Pro wyjaśnia, które elementy wymagają licencji.

Jeśli uruchamiasz Docker bezpośrednio na DSM, używaj niezmiennych migawek

Nie każdy chce warstwę maszyn wirtualnych. Jeśli Twoje kontenery działają na hoście, obroną przed ransomware C3RB3R są niezmienne migawki. Włącz je w Snapshot Replication dla folderu współdzielonego, który zawiera dane Twoich kontenerów. Wymagają one DSM 7.2 lub nowszego oraz wolumenu Btrfs, a w okresie blokady nikt nie może ich usunąć, w tym przejęte przez atakującego konto administratora. O sukcesie lub porażce decydują dwa szczegóły:

• Używaj montowania typu bind do folderu współdzielonego takiego jak /volume1/docker/app. Nazwane wolumeny Docker znajdują się w /volume1/@docker, który nie jest folderem współdzielonym i nie można dla niego w ogóle tworzyć migawek.
• Wykonaj zrzut baz danych do pliku przed utworzeniem migawki. Migawka uruchomionej bazy MariaDB to kopia z momentu nagłego zaniku zasilania. Zaplanowany mysqldump do tego samego folderu współdzielonego daje czysty punkt przywracania, który migawka następnie blokuje.
• Wybierz okres blokady dłuższy niż czas, przez który atakujący może działać po cichu. Powyższa ofiara miała tylną furtkę przez 37 dni przed rozpoczęciem szyfrowania. Siedem dni niezmiennych migawek nie sięgałoby do czystego stanu.

Nasza dodatkowa warstwa: Active Insight wykonuje migawkę po rozpoczęciu szyfrowania

Oto warstwa, którą pomija większość poradników. Active Insight, usługa monitorowania w chmurze Synology, może obserwować aktywność plików w folderach współdzielonych i gdy uzna, że ma do czynienia z ransomware, reaguje samoczynnie. Synology opisuje to w swoim przewodniku po bezpieczeństwie NAS: po wykryciu incydentu ransomware Active Insight wysyła powiadomienie o zdarzeniu i automatycznie tworzy migawkę folderu współdzielonego, a w modelach obsługujących tę funkcję migawka ta jest niezmienna.

Dlaczego ma to kluczowe znaczenie w przypadku ransomware C3RB3R: moduł szyfrujący ransomware C3RB3R działa wolno. Poszkodowany użytkownik z ponad 50 TB danych zauważył problem dopiero wtedy, gdy proces doszedł do jego zdjęć z 2024 roku. Migawka wykonana w momencie pojawienia się pierwszych oznak szyfrowania zamraża wszystko, co nie zostało jeszcze naruszone, co może stanowić większość wolumenu. Nie ma również znaczenia, w jaki sposób ransomware C3RB3R dostał się do systemu, ponieważ usługa obserwuje to, co dzieje się z plikami, a nie stronę logowania. Na naszym DS1621xs+ strona Aktywność plików pokazuje ochronę przed ransomware jako Chronione.

Zapoznaj się z ograniczeniami, zanim na nim polegniesz. Pochodzą one z dokumentacji Synology Dokumentacja aktywności plików:

• Monitorowanie aktywności plików jest domyślnie wyłączone. Zarejestruj serwer NAS w usłudze Active Insight w Panelu sterowania, a następnie włącz monitorowanie dla każdego hosta w portalu Active Insight.
• Wymaga Snapshot Replication, DSM 7.2 lub nowszego, Active Insight 3.0.2 lub nowszego, co najmniej 1 GB pamięci RAM oraz licencji Active Insight przypisanej do tego serwera NAS.
• Maksymalnie jedna automatyczna migawka na folder współdzielony dziennie. Jest to siatka bezpieczeństwa tworzona po wykryciu zagrożenia, a nie zastępstwo dla zaplanowanych niezmiennych migawek.
• Nie obejmuje: folderów nagrań Surveillance Station oraz folderów współdzielonych na zewnętrznych dyskach USB.
• Niezmienność zależy od modelu. W przypadku modelu bez niezmiennych migawek napastnik z uprawnieniami root nadal może usunąć automatyczną migawkę, dlatego warto połączyć tę funkcję z powyższym harmonogramem niezmiennych migawek.

Chcesz mieć taką samą konfigurację? SynoPower Club sprzedaje oryginalne licencje dla obu elementów: Licencja Virtual DSM (VDSM) aby uruchamiać usługi Docker w wyizolowanym systemie gościa, oraz Licencja VMM Pro do planów ochrony, replikacji między serwerami NAS i migracji na żywo. Klucze są dostarczane pocztą e-mail.

Gdzie znaleźć więcej oficjalnych zasobów

Ransomware C3RB3R na Synology ma publicznie zaledwie dwa dni w momencie pisania tego tekstu i nie ma jeszcze oficjalnych materiałów wideo, więc ta sekcja wymienia źródła pierwotne zamiast poradników krok po kroku.

• Ogłoszenie o bezpieczeństwie Synology z dnia 29 października 2026 r., zalecający użytkownikom nieaktualnych wersji DSM natychmiastową aktualizację i włączenie automatycznych aktualizacji, a następnie e-mail do klientów z 30 października potwierdzający, że jedyną luką była SA-24:20.
• Synology-SA-24:20 i Synology-SA-26:13 to tabele wersji. Sprawdź swoją kompilację w Panelu sterowania, a następnie w zakładce Aktualizacja i przywracanie, porównując ją z obiema.
• lllong1377/c3rb3r-never-rebooted-still-no-key to najlepszy indeks wszystkich znanych przypadków, w tym nieopisanych tutaj, oraz najjaśniejsze wyjaśnienie, kiedy analiza śledcza pamięci RAM nie ma sensu.
• Trzy wątki na r/synology podlinkowane powyżej, a w szczególności raport śledczy, który zawiera polecenia do badania dysku w trybie tylko do odczytu krok po kroku: Cóż, w końcu do tego doszło.

Własna lista kontrolna Synology (30 października 2026 r.)

Wiadomość e-mail od Synology do klientów kończy się czterema krokami. Są one krótkie i każdy z nich ma znaczenie w walce z oprogramowaniem ransomware C3RB3R:

1. Sprawdź obecność intruzów. Oprogramowanie ransomware C3RB3R pozostawia po sobie zaplanowane elementy utrzymania dostępu, więc uruchom skanowanie w Security Advisor, a następnie sprawdź w Harmonogramie zadań skrypty, których nie utworzyłeś, oraz w zakładce Użytkownik i grupa konta administratorów, których nie dodałeś. Jeśli cokolwiek wygląda niepokojąco, skontaktuj się z Synology Support.
2. Zaktualizuj wszystko. Zainstaluj najnowszą wersję DSM w Panelu sterowania
3. Włącz automatyczne aktualizacje w sekcji Aktualizacja i przywracanie, aby przyszłe poprawki bezpieczeństwa były instalowane zaraz po ich wydaniu.
4. Przechowuj kopię zapasową w zewnętrznej lokalizacji. Używaj aplikacji Hyper Backup i Snapshot Replication, aby przechowywać kopię w osobnej lokalizacji, oraz regularnie sprawdzaj, czy zadania tworzenia kopii zapasowych faktycznie się kończą.

Krok pierwszy to ten, który ludzie zazwyczaj pomijają. Jeśli Twoje urządzenie było dostępne z Internetu przed poprawką z grudnia 2024 r., ransomware C3RB3R mogło już uzyskać dostęp, a dzisiejsza aktualizacja nie powie Ci, czy ktoś nie znajduje się już wewnątrz.

Bezpłatne narzędzie, które wykona sprawdzanie za Ciebie

Jeśli sprawnie posługujesz się terminalem, krok pierwszy może teraz sprowadzać się do jednego polecenia. synology-nas-cli to narzędzie wiersza poleceń typu open-source na licencji MIT, wydane 30 października 2026 r. przez niezależnego dewelopera Akari Sora. Loguje się do DSM poprzez jego interfejs web API i przeprowadza audyt urządzenia pod kątem tej kampanii. Projekt znajduje się na GitHubie: akari-sora/synology-nas-cli.

Przejrzeliśmy jego kod przed umieszczeniem linku. Używa wyłącznie standardowej biblioteki Pythona i nie łączy się z niczym poza Twoim NAS, serwerem pobierania Synology, PyPI oraz zestawem ratunkowym soimy. Nie wysyła żadnej telemetrii, a podstawowy audyt wykonuje wyłącznie odczyt. Oto co sprawdza:

• Poziom poprawek. Twoją kompilację DSM pod kątem Synology-SA-26:13 (co obejmuje również starszą poprawkę SA-24:20) oraz zainstalowane pakiety pod kątem SA-26:14.
• Ekspozycję. QuickConnect, przekierowanie portów UPnP na routerze, zaporę sieciową DSM, AutoBlock, SMB1 oraz wbudowane konto administratora.
• Ślady oprogramowania ransomware C3RB3R. Wstrzyknięte ciągi logowania w dzienniku połączeń, /etc/cron.d/synot* wpisy, libgld i qnetd pliki binarne, dodatkowe konta root, klucze SSH i żądania okupu w Twoich udziałach.
• Migawki. Foldery udostępnione, które nie mają działającego harmonogramu migawek.

Może również naprawić większość znalezionych problemów. Jeśli pliki są właśnie szyfrowane, jego polecenie contain zamraża proces szyfrujący za pomocą SIGSTOP — to ten sam krok, co w punkcie drugim naszej listy pierwszej reakcji. Polecenie rescue uruchamia następnie zestaw narzędzi soimy, aby przechwycić pamięć i poszukać klucza.

nas incident                 # audyt tylko do odczytu

nas incident --deep # szukaj również implantów (jeden skrypt root tylko do odczytu)

• nas incident fix --dry-run # wypisz każdą zmianę, którą by wprowadził, nie zmieniaj niczego. Przeczytaj te uwagi, zanim pozwolisz mu cokolwiek zmienić:.
• Jest zupełnie nowe. Projekt ma zaledwie kilka dni, pochodzi od jednego dewelopera, nie jest powiązany z Synology i przeszedł niewielką zewnętrzną weryfikację. Zacznij od audytu tylko do odczytu oraz przebiegu próbnego (dry run).
• Naprawa zapory sieciowej może Cię zablokować. Przełącza zaporę DSM w tryb odmowy wszystkiego z wyjątkiem wymienionych przez Ciebie sieci. Uruchom je z komputera w tej samej sieci LAN i upewnij się, że wiesz, gdzie znajduje się przycisk RESET.
• Wyłącza QuickConnect. To bezpieczniejsze ustawienie, ale jeśli Twoja rodzina korzysta z Synology Photos lub Surveillance Station przez QuickConnect, najpierw skonfiguruj VPN lub Tailscale.
• Głębokie skanowanie (deep), zamrażanie (contain) i odzyskiwanie (rescue) działają z uprawnieniami root. Działają poprzez tymczasowe zadanie w Harmonogramie zadań, ponieważ jest to jedyny sposób na odczytanie dzienników dostępnych tylko dla użytkownika root i zamrożenie procesów.
• Plik README sugeruje przekazanie go agentowi AI. Jeśli to zrobisz, przechowuj hasło w menedżerze haseł, a nie na czacie, i samodzielnie potwierdź naprawę.

W kwestii pozostałych aspektów zabezpieczania systemu, nasze przewodniki dotyczące prowadzenia publicznej witryny internetowej na Synology NAS oraz dotyczące tego, co Threat Prevention widzi, a czego nie widzi obejmują stronę sieciową, a przewodnik po łatce PHP2Shell opisuje drugi krytyczny problem, który pojawił się w tym samym tygodniu.

Ograniczenia ransomware C3RB3R i uwagi dotyczące bezpieczeństwa

Aktualizacja nie usuwa istniejącej infekcji. Co najmniej jedna ofiara stwierdziła, że złośliwy wpis w cronie nadal pozostał po aktualizacji do najnowszego DSM. Jeśli Twój system był narażony bez zainstalowanej łatki, sprawdź /etc/cron.d, Harmonogram zadań, skrypty startowe oraz włączone usługi, takie jak telnet, a następnie zmień wszystkie dane dostępowe.

Aktualny to nie to samo co czysty. Jedna z ofiar na Reddicie była przekonana, że system DSM jest aktualny, a inna została zaatakowana mimo włączonego 2FA i silnego hasła. Urządzenie, w którym doszło do naruszenia przed zainstalowaniem poprawki, może przenieść złośliwe oprogramowanie przez każdą późniejszą aktualizację. Traktuj każdą stronę logowania DSM dostępną z Internetu jako cel ataku, w tym te opublikowane przez UPnP, których nigdy świadomie nie konfigurowano. Używaj VPN lub Tailscale do dostępu zdalnego i wyłącz UPnP w routerze.

RAID i lokalne kopie zapasowe nie stanowią ochrony przed ransomware C3RB3R. Wszystko, do czego zainfekowany DSM ma prawa zapisu, zostanie zaszyfrowane, w tym miejsca docelowe Hyper Backup na tym samym urządzeniu oraz zamontowane udziały sieciowe.

Nie płać przed zapoznaniem się z opisami przypadków. Płacenie operatorom ransomware C3RB3R finansuje kolejną falę i niczego nie gwarantuje. Jeśli proces szyfrujący nadal działa, najlepszą szansą jest odzyskanie klucza z pamięci RAM. Jeśli nie, jedyną realną drogą są własne kopie zapasowe przechowywane poza tym urządzeniem.

Uważaj, co wklejasz do asystenta AI. Narzędzia AI pomogły tutaj kilku ofiarom, ale nie przekazuj im haseł, odzyskanych kluczy, pełnych zrzutów pamięci ani danych firmowych. Pozwól im proponować polecenia, a wszystko, co wymaga uprawnień roota, uruchamiaj samodzielnie.

Klony sprzętowe niosą dodatkowe ryzyko. Kilka udokumentowanych ofiar uruchamiało DSM na nieoryginalnym sprzęcie, na którym oficjalne aktualizacje są trudne lub niemożliwe do zastosowania. Jeśli to Twoja konfiguracja, załóż, że nie masz poprawek i całkowicie odłącz urządzenie od Internetu.

Odniesienia

• Ogłoszenie o bezpieczeństwie Synology dotyczące ataków ransomware na DSM, 29 października 2026 r.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 oraz naprawione kompilacje DSM.
• Synology-SA-26:13 DSM, CVE-2026-13639 oraz CVE-2026-13684, opublikowane 18 września 2026 r.
• Ratowanie złośliwego oprogramowania C3RB3R ransomware firmy Benjamin-zlt na sprzęcie fizycznym, format plików, układ kluczy i procedura SIGSTOP.
• Odzyskiwanie z pamięci działa tylko wtedy, gdy proces szyfrujący wciąż działa., Obowiązuje ta sama zasada, co w trzech przypadkach na GitHubie.
• IT-Connect o kampanii C3RB3R, podsumowujący przypisanie ataku przez 360 oraz harmonogram wydarzeń.
• Centrum wiedzy Synology: zwiększanie bezpieczeństwa serwera Synology NAS, w tym informację, jak usługa Active Insight tworzy migawkę folderu współdzielonego po wykryciu oprogramowania ransomware.

Często zadawane pytania

Spraw, aby kolejny atak ransomware C3RB3R kosztował Cię jedynie przywrócenie danych, a nie okup. Uruchamiaj swoje usługi Docker wewnątrz Virtual DSM i chroń całego gościa za pomocą planów ochrony VMM Pro, replikowanych na drugi NAS. SynoPower Club sprzedaje oryginalne licencje na oba te rozwiązania, z kluczami dostarczanymi pocztą e-mail.