Ransomware C3RB3R su Synology: origini, ripristino e come rimanere al sicuro

Ransomware C3RB3R ha iniziato a comparire sulle unità NAS Synology intorno al 28 ottobre 2026 e nel giro di un giorno è diventato l'unico argomento su r/synology. I file vengono rinominati con una L0CK3D estensione (uno zero, non la lettera O), ogni cartella riceve un read-me3.txt riscatto in un file di nota, e un portale Tor richiede Bitcoin. Le informazioni più rapide e utili non sono arrivate da siti di notizie in inglese. Sono giunte da forum di lingua cinese, dove Synology ha un'ampia base di utenti, e da tre repository GitHub scritti da vittime che sono riuscite a recuperare i propri dati, o che hanno dimostrato di non poterlo fare. Questa guida raccoglie ciò che è confermato finora sul ransomware C3RB3R: da dove proviene, come riesce a penetrare, l'unico percorso di ripristino che ha funzionato e la struttura di backup che utilizziamo affinché un attacco del genere ci costi solo un ripristino anziché un riscatto.

Aggiornamento, 31 ottobre 2026: Synology ha ora chiarito il punto di ingresso. In un'e-mail inviata ai clienti il 30 ottobre, ha confermato che il ransomware C3RB3R sfrutta solo la vulnerabilità corretta in Synology-SA-24:20, risolta a dicembre 2024, e che la campagna non è correlata alla vulnerabilità PHP2Shell corretta nello stesso mese. Abbiamo aggiunto la checklist in quattro punti di Synology, la nostra interpretazione del perché gli attacchi siano scattati quando si sono verificati e un livello aggiuntivo che utilizziamo e che la maggior parte dei proprietari paga già: la protezione ransomware di Active Insight.

Punto SynoPower Club:Una vittima in un gruppo NAS cinese aveva più di 50 TB su un singolo dispositivo e nessuna snapshot. Il malware di crittografia era abbastanza lento che solo le sue foto del 2024 sono state colpite, e quelle per caso avevano una copia a freddo su un drive cloud. Un altro ha perso cinque anni di repository GitLab privati, perché il RAID 6 più tre backup risiedevano tutti sulla stessa macchina. Il ransomware C3RB3R non ha sconfitto il loro storage, ha sconfitto la loro struttura di backup. Eseguiamo i nostri siti pubblici come Docker all'interno di Virtual DSM, creiamo una snapshot dell'intero guest dall'host, la replichiamo su un secondo NAS e la esportiamo programmata su USB e sul cloud. Se un guest viene crittografato stasera, lo ripristiniamo all'ultima snapshot e l'aggressore non ottiene nulla.

Cos'è il ransomware C3RB3R?

Il ransomware C3RB3R è una build Linux della famiglia Cerber, una linea di ransomware presente dal 2016 che da anni prende di mira a intermittenza i dispositivi NAS. 360 le attribuisce l'ondata di ottobre 2026 su Synology. Su un sistema DSM infetto, l'eseguibile di crittografia del ransomware C3RB3R viene eseguito come un binario x86-64 collegato staticamente e compresso con UPX, chiamato libgldElimina il proprio file dopo l'avvio, quindi il processo in esecuzione mostra (eliminato) accanto al percorso del suo eseguibile.

Ciò che si vede come proprietario di un dispositivo colpito dal ransomware C3RB3R è coerente in tutti i report:

• File rinominati in name.ext.L0CK3DAlcune segnalazioni indicano LOCK3D, ma le analisi su GitHub citano lo zero.
• Una nota di riscatto denominata read-me3.txt in ogni cartella crittografata, con l'intestazione C3RB3R INSTRUCTIONS.
• Una pagina Tor intitolata C3rb3r Decryptor. Lo screenshot di una vittima mostrava 0,03696 BTC (circa 2.952 USD) se pagati entro cinque giorni, che raddoppiavano a 0,07392 BTC (circa 5.904 USD) dopo tale termine, con un timer a conto alla rovescia.
• Persistenza tramite voci cron corrispondenti a /etc/cron.d/synot*, che si ricreano automaticamente e che in almeno un caso sono sopravvissute a un aggiornamento di DSM.
• File di backup sullo stesso volume crittografati insieme a tutto il resto, comprese le destinazioni di Hyper Backup e i dump dei database.

Dove è iniziato: r/synology e i forum cinesi

Il ransomware C3RB3R è emerso per la prima volta in inglese su r/synology, dove le vittime hanno pubblicato post nel giro di un giorno l'una dall'altra intorno al 28 e 29 ottobre 2026. Nel giro di poche ore gli utenti riferivano che compariva un nuovo thread ogni volta che aggiornavano il subreddit. Tre di questi thread meritano di essere letti integralmente, poiché ognuno aggiunge un elemento diverso:

• L'analisi forense. Un proprietario di DS918+ con DSM 7.2.1-69057 Update 5, con l'interfaccia web raggiungibile da Internet, ha spento il dispositivo e ha esaminato i dischi in modalità di sola lettura su un host Proxmox. Il log di autenticazione di DSM conteneva una richiesta di accesso il cui campo account riportava righe iniettate di LD_PRELOAD e LD_DEBUG_OUTPUT oltre a un comando shell codificato e un file sotto /etc/cron.dQuesto corrisponde alla tecnica pubblicata nella CVE-2024-10441. Un backup 3-2-1 ha fatto sì che l'attacco sia costato un ripristino, non un riscatto. Leggilo qui: Beh, alla fine è successo. Il mio primo vero incidente da ransomware.
• L'utente solo Synology Photos. Questo proprietario credeva che DSM fosse aggiornato e utilizzava solo Synology Photos, ma UPnP sul router era attivo. Dopo un reset di modalità 2, le cartelle protette da Snapshot Replication sono state recuperate. Le cartelle senza snapshot no, e l'unità USB locale di Hyper Backup è stata crittografata insieme al NAS. Leggilo qui: Colpito dal ransomware c3rb3r questa mattina.
• La discussione su QuickConnect. L'autore del post originale se ne è accorto solo dopo che DSM è andato in stato degradato e una reinstallazione ha rivelato i file crittografati. Nelle risposte, un altro lettore con una password robusta, 2FA e QuickConnect abilitato ha dichiarato di essere stato colpito a sua volta, e altri hanno evidenziato che gli utenti che usano solo specifiche app possono disattivare completamente l'accesso a DSM in QuickConnect. Leggilo qui: Colpito dal ransomware C3RB3R.

Letti insieme, il modello è chiaro. Al ransomware C3RB3R bastava una pagina di login di DSM raggiungibile, niente di più. Password e 2FA non hanno aiutato, perché l'exploit viene eseguito prima dell'autenticazione. L'analisi forense lo ha spiegato chiaramente: la richiesta ha raggiunto un'applicazione vulnerabile e una richiesta di password aggiuntiva non avrebbe risolto il problema.

Il lavoro tecnico più approfondito è avvenuto in cinese. Le vittime nei gruppi WeChat e Xiaohongshu hanno pubblicato note di riscatto, confrontato le tempistiche e si sono segnalate a vicenda i repository GitHub trattati di seguito. Una community Synology taiwanese su Facebook ha raccolto gli stessi link di ripristino per gli utenti locali. Ha senso: Synology è un'azienda taiwanese e le sue principali community di utenti sono di lingua cinese, ed è da lì che proviene il maggior volume di casi di ransomware C3RB3R e, di conseguenza, l'individuazione più rapida degli schemi di attacco.

La stessa Synology ha pubblicato un avviso di sicurezza il 29 ottobre 2026, affermando di aver identificato attori di minaccia che sfruttavano una vulnerabilità corretta a dicembre 2024 contro versioni di DSM obsolete, e sollecitando tutti ad aggiornare immediatamente.

Come penetra il ransomware C3RB3R

Per i primi due giorni ci sono stati due candidati come punti di ingresso. Da allora Synology ha confermato quello più datato. La sua e-mail del 30 ottobre afferma che gli attacchi sfruttano solo la vulnerabilità affrontata in Synology-SA-24:20 e che il ransomware C3RB3R non ha nulla a che fare con PHP2Shell. La tabella seguente mostra entrambi i candidati così come sono stati discussi, poiché vale comunque la pena applicare la patch alla coppia 360.

	Synology afferma	360 afferma
Consultivo	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, esecuzione di codice remoto non autenticata nel demone dei plugin di sistema	CVE-2026-13639 (logica di login) e CVE-2026-13684 (SCGI), entrambi CVSS 9.8
Corretto	Da novembre a dicembre 2024	18 settembre 2026
Build corrette	DSM 7.2.2-72806 Aggiornamento 1, 7.2.1-69057 Aggiornamento 6, 7.2-64570 Aggiornamento 4, 7.1.1-42962 Aggiornamento 7	DSM 7.4-90075, 7.3.2-86009 Aggiornamento 4, 7.2.2-72806 Aggiornamento 9, 7.2.1-69057 Aggiornamento 12

Le prove forensi pendono a favore del bug più vecchio per almeno alcune vittime. Il report più dettagliato su Reddit ha fatto corrispondere i propri log superstiti all'exploit pubblicato per la CVE-2024-10441, pur notando che Synology non lo aveva confermato e che lo stesso dispositivo si trovava anche al di sotto del livello di correzione per la SA-26:13. La relazione di soimy afferma che i log di memoria del guest infetto indicano un'iniezione di variabili d'ambiente tramite il plugin di login di DSM, coerentemente con la CVE-2024-10441, e una proof of concept pubblica che sfrutta il campo nome utente di login è apparsa su GitHub giorni prima dell'attacco. Due dei tre casi di ripristino documentati venivano eseguiti su hardware non originale con bootloader per DS918+, uno dei quali su DSM 7.2-64570 Update 3, che si trova esattamente a un aggiornamento di distanza dalla correzione per la CVE-2024-10441. L'hardware clone non può ricevere facilmente gli aggiornamenti ufficiali, il che lo rende il bersaglio più vulnerabile dell'intera popolazione.

La conclusione pratica non è cambiata: aggiornare a una build che copra entrambi gli avvisi di sicurezza e smettere di esporre DSM a Internet. Ma rimaneva una domanda: se la falla è stata corretta a dicembre 2024, perché così tanti dispositivi sono stati colpiti dal ransomware C3RB3R entro gli stessi due giorni di ottobre 2026, compresi alcuni i cui proprietari credevano di essere aggiornati?

Piazzato in anticipo, fatto esplodere a comando

La nostra lettura, ed è una nostra interpretazione piuttosto che una dichiarazione ufficiale di Synology, è che l'intrusione del ransomware C3RB3R e la crittografia siano due eventi distinti. Le prove indicano questo:

• La backdoor è arrivata per prima. Nel caso Xiaohongshu descritto di seguito, una shell backdoor era presente sul NAS da 37 giorni e aveva attivato telnet come root prima che venisse crittografato anche un solo file.
• Sopravvive agli aggiornamenti. Le voci cron sotto /etc/cron.d/synot* si ricreano da sole e almeno una vittima le ha trovate ancora presenti dopo l'aggiornamento all'ultima versione di DSM. L'aggiornamento ha chiuso la falla, ma ha lasciato l'intruso all'interno.
• Le attivazioni sono state sincronizzate. I dispositivi colpiti dal ransomware C3RB3R compromessi in momenti diversi, su build diverse, hanno iniziato la crittografia entro circa 48 ore l'uno dall'altro.

Questo modello corrisponde a quello di un malintenzionato che ha piazzato gli impianti del ransomware C3RB3R su dispositivi non aggiornati per mesi, per poi scegliere quando premere il grilletto da remoto. Il momento scelto è stato la settimana di PHP2Shell, quando ogni amministratore Synology era occupato ad applicare le patch, molti dispositivi erano stati appena aggiornati e i proprietari si sentivano al sicuro per questo motivo. Synology ha chiarito che PHP2Shell non è stato la via d'accesso: è stata la copertura. La lezione è che un dispositivo esposto mentre non è aggiornato deve essere considerato compromesso fino a quando non viene controllato, che è esattamente ciò che il primo punto della checklist di Synology vi chiede di fare.

Prima risposta al ransomware C3RB3R in 4 passaggi

Se trovi L0CK3D file in questo momento, l'ordine delle azioni nei prossimi dieci minuti determina se il recupero sia del tutto possibile. La chiave che sblocca i tuoi file esiste solo all'interno del processo del ransomware C3RB3R in esecuzione. Un riavvio, un kill -9 o una reinstallazione di DSM la distruggerà.

I comandi relativi ai passaggi 2 e 3 si presentano così. Leggi i repository prima di eseguire qualsiasi cosa, poiché i dettagli dipendono dal binario in tuo possesso.

# Passaggio 2: trova il processo di crittografia (il suo eseguibile risulta eliminato)

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

# Congelalo. Non usare mai kill -9 qui.

kill -STOP <PID>	grep State /proc/<PID>/status # dovrebbe mostrare T (stopped)	# Cerca la persistenza che lo riattiva	ls -l /etc/cron.d/ | grep synot
Puoi decrittografarlo? I tre casi di recupero su GitHub	Non esiste un decrittore universale per il ransomware C3RB3R, e chiunque ne venda uno sta solo tirando a indovinare. Ciò che esiste sono tre accurati casi di studio che ti mostrano esattamente quando il recupero funziona.	Repository	Macchina
Risultato	Motivo	Repository	soimy/c3rb3r-rescue
DSM in una macchina virtuale Proxmox VE con GitLab	Recuperato	Una copia da 16 GiB di RAM del guest conteneva la chiave di sessione da 48 byte. GitLab ripristinato con 80 progetti e 9.253 oggetti LFS.	Il programma di crittografia era già uscito circa 30 ore prima. La scansione completa della RAM e dello swap non ha trovato alcuna chiave.

Il terzo repository è il più importante da leggere, perché il suo titolo è la sua lezione: non essere mai riavviato non significa che sia recuperabile. Ciò che conta è se il processo del ransomware C3RB3R è ancora attivo. Una volta terminato, azzera il proprio buffer della chiave e la chiave scompare. Una chiave recuperata su una vittima è inoltre inutile su un'altra, poiché ogni esecuzione genera una nuova chiave di sessione.

Perché la chiave risiede solo in memoria

L'analisi di Benjamin-zlt spiega nel dettaglio il formato di file del ransomware C3RB3R e illustra sia perché questo metodo funziona sia perché di solito non funziona.

• Ogni file riceve la propria chiave ChaCha8 casuale. Tale chiave viene incapsulata con una chiave master di sessione utilizzando AES-256-CBC e memorizzata in un trailer di 588 byte alla fine del file.
• La chiave master di sessione è di 48 byte: un IV da 16 byte più una chiave AES da 32 byte. Non viene mai scritta su disco. Un puntatore globale all'interno del processo in esecuzione punta ad essa.
• Il trailer contiene anche un blob incapsulato con la chiave pubblica dell'attaccante (RSA-2048), quindi senza il processo in esecuzione, solo l'attaccante può recuperare la chiave di sessione.
• Non tutti i file sono completamente crittografati. In un campione di 400 file, circa il 56% utilizzava la modalità segmentata, il 31% aveva solo il primo 1 MiB crittografato e il 13% era crittografato da un'estremità all'altra. I file parzialmente crittografati non sono comunque leggibili, ma l'analisi del piè di pagina (footer) mostra ciò che rimane.

Quindi la vulnerabilità del ransomware C3RB3R è limitata e circoscritta nel tempo: il programma di crittografia mantiene la chiave master in memoria per l'intera sessione. Congelandolo mentre è in esecuzione, è possibile estrarre la chiave. Persa quella finestra temporale, rimane solo il blob con la chiave pubblica, progettato per essere inviolabile.

La storia di una vittima: 50 TB e nessuno snapshot

Un resoconto dettagliato pubblicato su Xiaohongshu il 29 ottobre 2026 dall'utente 柯基爱好者 segue un membro del loro gruppo NAS durante la notte. Ha notato la nota del ransomware C3RB3R, ha confermato l'intestazione C3RB3R INSTRUCTIONS ed era vicino all'acquisto di Bitcoin prima che il gruppo gli segnalasse i casi su GitHub.

Ha quindi utilizzato un assistente di codifica AI tramite SSH per indagare. Questo ha individuato e congelato il programma di crittografia, impedendo l'ulteriore crittografia di altri file da quel momento in poi. Ha inoltre scoperto che una probabile backdoor shell era presente sul NAS da 37 giorni e aveva abilitato il telnet come root, il che significa che l'intrusione iniziale e la crittografia sono avvenute a oltre un mese di distanza. Ha scritto uno script per la raccolta delle prove e, correttamente, ha atteso la sua conferma prima di eseguire qualsiasi cosa come root.

La sua fortuna è stata che il ransomware C3RB3R è lento. Con oltre 50 TB da elaborare, il programma di crittografia aveva raggiunto solo le sue foto del 2024, delle quali esisteva una copia fredda su un drive cloud. Ha spostato i dati di lavoro su un NAS più piccolo e ha messo da parte il volume crittografato per dopo. La sua conclusione è stata schietta: non aveva snapshot, e con gli snapshot la situazione sarebbe stata facile da risolvere. Una seconda vittima su X ha riassunto la stessa lezione dall'altro punto di vista: RAID 6 più tre set di backup, tutti sullo stesso dispositivo, tutti crittografati insieme.

Come teniamo il ransomware C3RB3R lontano dai nostri backup

Ogni storia di perdita dati sopra descritta ha lo stesso schema: i backup erano raggiungibili dalla macchina compromessa. Il ransomware C3RB3R crittografa qualsiasi elemento su cui il DSM compromesso può scrivere, quindi la soluzione consiste nel conservare almeno una copia in un luogo in cui il DSM non possa scrivere affatto. È così che facciamo per i siti che ospitiamo, adattandoci alla regola 3-2-1-1-0.

Regola	Significato	Come lo facciamo
3	Tre copie dei dati	La VM attiva, una replica su un secondo NAS e un'esportazione pianificata
2	Due tipi di supporto	Volumi NAS più un'unità USB e un'unità cloud
1	Una copia fuori sede	Esportazioni sincronizzate su Google Drive tramite Cloud Sync
1	Una copia offline o immutabile	Snapshot della VM lato host che il guest non può toccare, più l'esportazione USB scollegata
0	Zero errori durante il ripristino	Eseguiamo effettivamente il ripristino e l'avvio dalle repliche quando spostiamo le VM tra gli host

Eseguire Docker all'interno di Virtual DSM, non sull'host

I nostri container WordPress non vengono eseguiti sul NAS fisico. Vengono eseguiti all'interno di un guest Virtual DSM e il guest è protetto da Virtual Machine Manager sull'host. Se il ransomware C3RB3R ottiene i privilegi di root all'interno del guest, compromette solo quel guest e niente altro. Gli snapshot del guest risiedono nello storage dell'host, all'esterno del file system del guest, quindi il ransomware all'interno della VM non può vederli, tanto meno crittografarli o eliminarli. Il ripristino è un rollback dello snapshot che richiede solo pochi minuti.

VMM Pro aggiunge le parti che lo trasformano in un vero e proprio backup: un piano di protezione che esegue lo snapshot della VM e la replica su un secondo NAS nel cluster, coprendo così anche l'eventuale guasto di un host. Il nostro cluster è composto da un DS1621xs+ e un DS1525+ che si replicano a vicenda. Abbiamo descritto la parte relativa all' esportazione pianificata e Cloud Sync su Google Drive separatamente, e il confronto tra VMM gratuito e VMM Pro spiega quali componenti richiedono la licenza.

Se si esegue Docker direttamente su DSM, utilizzare snapshot immutabili

Non tutti vogliono un livello VM. Se i tuoi container vengono eseguiti sull'host, la difesa contro il ransomware C3RB3R sono gli snapshot immutabili. Attivali in Snapshot Replication per la cartella condivisa che contiene i dati dei container. Richiedono DSM 7.2 o successivo e un volume Btrfs e, durante il periodo di blocco, nessuno può eliminarli, incluso un account amministratore di cui l'attaccante si è impossessato. Due dettagli determinano il successo di questa soluzione:

• Usa i bind mount in una cartella condivisa come ad esempio /volume1/docker/app. I volumi con nome Docker risiedono sotto /volume1/@docker, che non è una cartella condivisa e non può essere sottoposta ad alcun snapshot.
• Esegui il dump dei database su un file prima dello snapshot. Uno snapshot di un MariaDB in esecuzione equivale a una copia da interruzione di corrente. Un'operazione pianificata mysqldump nella stessa cartella condivisa offre un punto di ripristino pulito che la snapshot provvederà poi a bloccare.
• Scegli un periodo di blocco più lungo del tempo in cui un utente malintenzionato può rimanere inattivo. La vittima citata sopra ha avuto una backdoor per 37 giorni prima che iniziasse la crittografia. Sette giorni di snapshot immutabili non sarebbero bastati per risalire a uno stato pulito.

Il nostro livello aggiuntivo: Active Insight scatta una snapshot all'avvio della crittografia

Ecco il livello che la maggior parte delle guide trascura. Active Insight, il servizio di monitoraggio cloud di Synology, può monitorare l'attività dei file nelle cartelle condivise e, una volta rilevata la presenza di un ransomware, reagisce autonomamente. Synology lo documenta nella sua guida alla sicurezza del NAS: quando viene rilevato un evento ransomware, Active Insight invia una notifica di evento e scatta automaticamente una snapshot della cartella condivisa; sui modelli supportati, tale snapshot è immutabile.

Perché questo è importante in particolare per il ransomware C3RB3R: l'algoritmo di crittografia del ransomware C3RB3R è lento. La vittima con più di 50 TB si è accorta dell'attacco quando il ransomware era arrivato solo alle sue foto del 2024. Una snapshot scattata alla prima comparsa del pattern di crittografia blocca tutto ciò che non è stato ancora toccato, che può rappresentare la maggior parte del volume. Inoltre, non importa come il ransomware C3RB3R sia entrato, perché monitora ciò che accade ai file, non la pagina di login. Sul nostro DS1621xs+, la pagina File Activity mostra la protezione ransomware come Protected.

Leggete i limiti prima di fare affidamento su di essa. Provengono dalla documentazione sull'Attività file:

• Il monitoraggio dell'attività file è disattivato per impostazione predefinita. Registrare il NAS per Active Insight nel Pannello di controllo, quindi abilitare il monitoraggio per ciascun host nel portale Active Insight.
• Richiede Snapshot Replication, DSM 7.2 o successivo, Active Insight 3.0.2 o successivo, almeno 1 GB di memoria e una licenza Active Insight assegnata a quel NAS.
• Al massimo una snapshot automatica per cartella condivisa al giorno. Si tratta di una rete di sicurezza creata dopo il rilevamento, non di un sostituto per le snapshot immutabili pianificate.
• Non coperto: Cartelle di registrazione di Surveillance Station e cartelle condivise su unità USB esterne.
• L'immutabilità dipende dal modello. Su un modello senza snapshot immutabili, un utente malintenzionato con accesso root può comunque eliminare la snapshot automatica, quindi abbinatela alla pianificazione di snapshot immutabili menzionata sopra.

Vuoi la stessa configurazione? SynoPower Club vende licenze autentiche per entrambi i componenti fondamentali: una licenza per Virtual DSM (VDSM) per eseguire i tuoi servizi Docker in un guest isolato e una Licenza VMM Pro per piani di protezione, replicazione tra NAS e migrazione live. Le chiavi vengono consegnate via e-mail.

Dove trovare ulteriori risorse ufficiali

Il ransomware C3RB3R su Synology è pubblico da soli due giorni al momento della stesura, e non ci sono ancora video esplicativi ufficiali, quindi questa sezione elenca fonti primarie invece di guide passo-passo.

• L'avviso di sicurezza Synology del 29 ottobre 2026, che invita gli utenti con versioni DSM non aggiornate ad aggiornare immediatamente e ad abilitare gli aggiornamenti automatici, seguita il 30 ottobre da un'e-mail ai clienti che conferma SA-24:20 come l'unica vulnerabilità coinvolta.
• Synology-SA-24:20 e Synology-SA-26:13 sono le tabelle delle versioni. Confronta la tua build in Pannello di controllo, quindi Aggiorna e Ripristina, con entrambe.
• DSM in una macchina virtuale Proxmox VE con GitLab è il miglior indice di tutti i casi noti, compresi quelli non trattati qui, nonché la spiegazione più chiara di quando l'analisi forense della memoria sia inutile.
• I tre thread di r/synology collegati sopra, in particolare il report forense, che include passo dopo passo i comandi di indagine sui dischi in sola lettura: Beh, alla fine è successo.

Checklist di Synology (30 ottobre 2026)

L’email di Synology ai clienti si conclude con quattro passaggi. Sono brevi e ognuno di essi è importante contro il ransomware C3RB3R:

1. Verifica la presenza di intrusi. Il ransomware C3RB3R lascia una persistenza pianificata, quindi esegui una scansione di Security Advisor, poi controlla in Utilità di pianificazione gli script che non hai creato e in Utente e Gruppo gli account amministratore che non hai aggiunto. Se qualcosa sembra anomalo, contatta il supporto Synology.
2. Aggiorna tutto. Installa l'ultimo DSM in Pannello di controllo, Aggiorna e Ripristina, quindi aggiorna ogni pacchetto nel Centro pacchetti.
3. Attiva gli aggiornamenti automatici in Aggiorna e Ripristina, in modo che le future correzioni di sicurezza vengano applicate non appena rilasciate.
4. Conserva un backup off-site. Usa Hyper Backup e Snapshot Replication per mantenere una copia in una posizione separata e verifica regolarmente che le attività di backup vengano effettivamente completate.

Il primo passaggio è quello che le persone saltano. Se il tuo dispositivo era raggiungibile da Internet prima della correzione di dicembre 2024, il ransomware C3RB3R potrebbe essersi già insediato, e l'aggiornamento effettuato oggi non ti dice se qualcuno è già all'interno.

Uno strumento gratuito che esegue la verifica per te

Se ti senti a tuo agio con il terminale, il primo passaggio ora può essere un singolo comando. synology-nas-cli è uno strumento a riga di comando open source con licenza MIT, rilasciato il 30 ottobre 2026 dallo sviluppatore indipendente Akari Sora. Effettua l'accesso a DSM tramite le sue API web ed effettua un audit del sistema rispetto a questa campagna. Il progetto si trova su GitHub: akari-sora/synology-nas-cli.

Abbiamo letto il suo codice prima di inserire il link. Utilizza solo la libreria standard di Python e comunica esclusivamente con il tuo NAS, il server di download Synology, PyPI e il toolkit di soccorso soimy. Non invia alcuna telemetria e l'audit di base esegue solo letture. Ecco cosa controlla:

• Livello di patch. La tua build di DSM rispetto a Synology-SA-26:13, che copre anche la precedente correzione SA-24:20, e i pacchetti installati rispetto a SA-26:14.
• Esposizione. QuickConnect, port forwarding UPnP sul router, il firewall di DSM, AutoBlock, SMB1 e l'account admin integrato.
• Tracce del ransomware C3RB3R. Le stringhe di login iniettate nel log delle connessioni, /etc/cron.d/synot* voci, i libgld e qnetd file binari, account root aggiuntivi, chiavi SSH e note di riscatto sulle tue condivisioni.
• Snapshot. Cartelle condivise che non hanno una pianificazione di snapshot funzionante.

Può anche correggere la maggior parte di ciò che trova. Se i file vengono crittografati in questo momento, il suo comando contain blocca il processo di crittografia con SIGSTOP, la stessa mossa del secondo passaggio del nostro elenco di prima risposta. Il suo comando rescue aziona quindi il toolkit soimy per acquisire la memoria e cercare la chiave.

nas incident                 # audit in sola lettura

nas incident --deep # cerca anche l'impianto (uno script root in sola lettura)

• nas incident fix --dry-run # elenca ogni modifica che apporterebbe, non modifica nulla. Leggi queste note prima di consentirgli di modificare qualsiasi cosa:.
• È nuovissimo. Il progetto ha solo pochi giorni, proviene da un unico sviluppatore, non è affiliato con Synology e ha ricevuto poche revisioni esterne. Inizia con l'audit in sola lettura e la simulazione (dry run).
• La correzione del firewall può bloccarti fuori. Imposta il firewall di DSM in modo da rifiutare tutto tranne le reti elencate. Eseguilo da un computer sulla stessa LAN e accertati di sapere dove si trova il pulsante RESET.
• Disattiva QuickConnect. Questa è l'impostazione più sicura, ma se la tua famiglia accede a Synology Photos o Surveillance Station tramite QuickConnect, configura prima una VPN o Tailscale.
• La scansione approfondita, contain e rescue vengono eseguiti come root. Funzionano tramite un'attività temporanea dell'Utilità di pianificazione, poiché è l'unico modo per leggere i log riservati a root e bloccare i processi.
• Il file README suggerisce di affidarlo a un agente IA. Se lo fai, conserva la password in un password manager piuttosto che nella chat e conferma tu stesso la correzione.

Per il resto del quadro di protezione, le nostre guide su eseguire un sito web pubblico su un NAS Synology e su cosa Threat Prevention può e non può vedere coprono il lato rete, mentre la guida alla patch PHP2Shell copre l'altro problema critico emerso nella stessa settimana.

Limiti del ransomware C3RB3R e note sulla sicurezza

L'aggiornamento non rimuove un'infezione esistente. Almeno una vittima ha riscontrato che la persistenza tramite cron era ancora presente dopo l'aggiornamento all'ultima versione di DSM. Se eri esposto prima di applicare la patch, controlla /etc/cron.d, Utilità di pianificazione, gli script di avvio e i servizi abilitati come telnet, quindi modifica tutte le credenziali.

Aggiornato non significa pulito. Una vittima su Reddit credeva che DSM fosse aggiornato e un'altra è stata colpita nonostante la 2FA e una password robusta attive. Un dispositivo violato prima di essere patchato può mantenere l'impianto attraverso ogni successivo aggiornamento. Tratta qualsiasi pagina di login DSM raggiungibile da Internet come un bersaglio, comprese quelle pubblicate tramite UPnP che non hai mai configurato intenzionalmente. Usa una VPN o Tailscale per l'accesso remoto e disattiva l'UPnP sul router.

Il RAID e i backup locali non costituiscono una protezione contro il ransomware C3RB3R. Tutto ciò su cui il sistema DSM compromesso può scrivere verrà crittografato, comprese le destinazioni di Hyper Backup sullo stesso dispositivo e le cartelle di rete montate.

Non pagare prima di aver letto i casi. Pagare gli operatori del ransomware C3RB3R finanzia la rondata successiva e non garantisce nulla. Se il programma di crittografia è ancora in esecuzione, l'estrazione dalla memoria è la tua migliore possibilità. In caso contrario, le uniche opzioni realistiche sono le tue copie salvate all'esterno del dispositivo.

Presta attenzione a ciò che incolli in un assistente IA. Gli strumenti IA hanno aiutato diverse vittime in questo caso, ma non fornire loro password, chiavi recuperate, dump di memoria completi o dati aziendali. Lascia che propongano i comandi ed esegui personalmente qualsiasi operazione che richieda i permessi di root.

L'hardware clone comporta rischi aggiuntivi. Diverse vittime documentate eseguivano DSM su hardware non originale, dove gli aggiornamenti ufficiali sono difficili o impossibili da applicare. Se questa è la tua configurazione, presupponi di non avere le patch e scollegalo completamente da Internet.

Riferimenti

• Avviso di sicurezza Synology sugli attacchi ransomware a DSM, 29 ottobre 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 e le build di DSM corrette.
• Synology-SA-26:13 DSM, CVE-2026-13639 e CVE-2026-13684, pubblicato il 18 settembre 2026.
• Salvataggio bare-metal dal ransomware C3RB3R di Benjamin-zlt, il formato dei file, il layout delle chiavi e il flusso di lavoro con SIGSTOP.
• Il recupero dalla memoria funziona solo finché il processo di crittografia è attivo., Vale la stessa regola dei tre casi su GitHub.
• IT-Connect sulla campagna C3RB3R, riassumendo l'attribuzione di 360 e la cronologia.
• Synology Knowledge Center: migliorare la sicurezza del tuo NAS Synology, incluso come Active Insight crea uno snapshot di una cartella condivisa quando rileva un ransomware.

Domande frequenti

Fai in modo che il prossimo attacco ransomware C3RB3R ti costi un ripristino, non un riscatto. Esegui i tuoi servizi Docker all'interno di Virtual DSM e proteggi l'intero guest con i piani di protezione VMM Pro, replicati su un secondo NAS. SynoPower Club vende licenze originali per entrambi, con chiavi consegnate via e-mail.