C3RB3R Ransomware auf Synology: Ursprünge, Wiederherstellung und wie Sie geschützt bleiben

C3RB3R-Ransomware tauchte um den 28. Oktober 2026 auf Synology NAS-Geräten auf, und innerhalb eines Tages war es das einzige Thema auf r/synology. Dateinamen werden umbenannt mit einer L0CK3D -Dateiendung (eine Null, nicht der Buchstabe O), und jeder Ordner erhält eine read-me3.txt Lösegeldforderungs-Datei, und ein Tor-Portal fordert Bitcoin. Die schnellsten und nützlichsten Informationen stammten nicht von englischsprachigen Nachrichtenseiten. Sie kamen aus chinesischsprachigen Foren, in denen Synology eine riesige Benutzerbasis hat, und aus drei GitHub-Repositories von Opfern, die ihre Daten tatsächlich zurückerhalten haben oder bewiesen haben, dass dies nicht möglich war. Dieser Leitfaden fasst zusammen, was bisher über die C3RB3R-Ransomware bestätigt ist: woher sie kam, wie sie eindringt, der eine Wiederherstellungsweg, der funktioniert hat, und das Backup-Konzept, das wir ausführen, damit ein solcher Angriff uns eine Wiederherstellung statt eines Lösegelds kostet.

Update, 31. Oktober 2026: Synology hat nun den Einfallspunkt geklärt. In einer E-Mail an Kunden vom 30. Oktober bestätigte das Unternehmen, dass die C3RB3R-Ransomware nur die in Synology-SA-24:20 behobene Schwachstelle ausnutzt, die im Dezember 2024 gepatcht wurde, und dass die Kampagne nicht mit der im selben Monat gepatchten PHP2Shell-Schwachstelle zusammenhängt. Wir haben Synology’s eigene Vier-Schritte-Checkliste hinzugefügt, unsere Einschätzung dazu, warum die Angriffe zu diesem Zeitpunkt stattfanden, sowie eine zusätzliche Schutzschicht, die wir nutzen und für die die meisten Besitzer bereits bezahlen: den Active Insight Ransomware-Schutz.

SynoPower Club-Punkt:Ein Opfer in einer chinesischen NAS-Gruppe hatte mehr als 50 TB auf einem einzigen Gerät und keine Snapshots. Der Verschlüsselungsprozess war langsam genug, sodass nur seine Fotos aus dem Jahr 2024 betroffen waren, von denen zufällig eine Cold-Copy auf einem Cloud-Laufwerk lag. Ein anderer verlor fünf Jahre privater GitLab-Repositories, weil RAID 6 plus drei Backups alle auf demselben Gerät lagen. Die C3RB3R-Ransomware hat nicht ihren Speicher besiegt, sondern ihr Backup-Konzept. Wir betreiben unsere öffentlichen Websites als Docker innerhalb von Virtual DSM, erstellen vom Host aus Snapshots des gesamten Guests, replizieren sie auf ein zweites NAS und exportieren sie nach Zeitplan auf USB und in die Cloud. Wenn ein Guest heute Nacht verschlüsselt wird, setzen wir ihn auf den letzten Snapshot zurück und der Angreifer geht leer aus.

Was ist die C3RB3R-Ransomware?

Die C3RB3R-Ransomware ist ein Linux-Build der Cerber-Familie, einer Ransomware-Reihe, die seit 2016 existiert und seit Jahren immer wieder NAS-Geräte angreift. 360 führt die Welle vom Oktober 2026 auf Synology darauf zurück. Auf einem infizierten DSM-Gerät läuft der Verschlüsseler der C3RB3R-Ransomware als statisch verlinkte, UPX-gepackte x86-64-Binärdatei namens libgldSie löscht ihre eigene Datei nach dem Start, sodass der laufende Prozess (gelöscht) neben seinem ausführbaren Pfad anzeigt.

Was Sie als Besitzer eines von der C3RB3R-Ransomware betroffenen Geräts sehen, ist in allen Berichten einheitlich:

• Dateinamen wurden umbenannt in name.ext.L0CK3DIn einigen Berichten wird es als LOCK3Dgeschrieben, aber die GitHub-Analysen nennen die Null.
• Eine Lösegeldforderung namens read-me3.txt in jedem verschlüsselten Ordner mit der Überschrift C3RB3R INSTRUCTIONS.
• Eine Tor-Seite mit dem Titel C3rb3r Decryptor. Der Screenshot eines Opfers zeigte 0,03696 BTC (ca. 2.952 US-Dollar) bei Zahlung innerhalb von fünf Tagen, was sich danach auf 0,07392 BTC (ca. 5.904 US-Dollar) verdoppelte, zusammen mit einem Countdown-Timer.
• Persistenz durch Cron-Einträge, die mit /etc/cron.d/synot*übereinstimmen, die sich selbst neu erstellen und in mindestens einem Fall ein DSM-Upgrade überstanden haben.
• Backup-Dateien auf demselben Volume wurden zusammen mit allen anderen Daten verschlüsselt, einschließlich Hyper Backup-Zielen und Datenbank-Dumps.

Wo es begann: r/synology und die chinesischen Foren

C3RB3R-Ransomware tauchte erstmals auf Englisch auf r/synology auf, wo Opfer um den 28. und 29. Oktober 2026 innerhalb eines Tages Beiträge veröffentlichten. Innerhalb von Stunden berichteten Leser, dass bei jedem Neuladen des Subreddits ein neuer Thread erschien. Drei dieser Threads sind es wert, vollständig gelesen zu werden, da jeder ein anderes Puzzleteil hinzufügt:

• Der forensische Bericht. Ein Besitzer einer DS918+ mit DSM 7.2.1-69057 Update 5, dessen Weboberfläche aus dem Internet erreichbar war, fuhr das Gerät herunter und untersuchte die Festplatten schreibgeschützt auf einem Proxmox-Host. Das DSM-Authentifizierungsprotokoll enthielt eine Anmeldeanfrage, deren Kontofeld injizierte LD_PRELOAD und LD_DEBUG_OUTPUT -Zeilen sowie einen kodierten Shell-Befehl und eine Datei unter /etc/cron.denthielt. Das entspricht der veröffentlichten CVE-2024-10441-Technik. Ein 3-2-1-Backup bedeutete, dass der Angriff eine Wiederherstellung kostete, kein Lösegeld. Lesen Sie es hier: Nun, es ist endlich passiert. Mein erster echter Ransomware-Vorfall.
• Der reine Photos-Nutzer. Dieser Besitzer glaubte, DSM sei auf dem neuesten Stand, und nutzte nur Synology Photos, aber UPnP am Router war aktiviert. Nach einem Modus-2-Reset kehrten die von Snapshot Replication abgedeckten Ordner zurück. Ordner ohne Snapshots nicht, und das lokale Hyper Backup-USB-Laufwerk wurde zusammen mit dem NAS verschlüsselt. Lesen Sie es hier: Heute Morgen von c3rb3r-Ransomware getroffen.
• Die QuickConnect-Diskussion. Der ursprüngliche Autor bemerkte es erst, als DSM den Zustand "Fehlerhaft" anzeigte und eine Neuinstallation die verschlüsselten Dateien ans Licht brachte. In den Antworten gab ein anderer Leser mit starkem Passwort, 2FA und aktiviertem QuickConnect an, ebenfalls betroffen zu sein, während andere darauf hinwiesen, dass Nutzer reiner Apps den DSM-Zugriff in QuickConnect vollständig deaktivieren können. Lesen Sie es hier: Von C3RB3R-Ransomware getroffen.

Zusammen betrachtet ist das Muster eindeutig. Die C3RB3R-Ransomware benötigte lediglich eine erreichbare DSM-Anmeldeseite, sonst nichts. Passwörter und 2FA halfen nicht, da der Exploit vor der Authentifizierung ausgeführt wird. Der forensische Bericht brachte es auf den Punkt: Die Anfrage erreichte eine schwachstellenbehaftete Anwendung, und eine weitere Passwortabfrage hätte daran nichts geändert.

Die tiefgehendere technische Analyse fand auf Chinesisch statt. Opfer in WeChat- und Xiaohongshu-Gruppen posteten Lösegeldschreiben, verglichen Zeitabläufe und wiesen sich gegenseitig auf die unten behandelten GitHub-Repositories hin. Eine taiwanische Synology-Community auf Facebook sammelte dieselben Wiederherstellungs-Links für lokale Benutzer. Das ergibt Sinn: Synology ist ein taiwanisches Unternehmen und seine größten Benutzer-Communitys sind chinesischsprachig, weshalb von dort das Hauptaufkommen an C3RB3R-Ransomware-Fällen und somit die schnellste Mustererkennung stammten.

Synology selbst veröffentlichte einen Sicherheitshinweis am 29. Oktober 2026 und erklärte, es habe Bedrohungsakteure identifiziert, die eine im Dezember 2024 behobene Schwachstelle bei veralteten DSM-Versionen ausnutzen, und forderte alle dringend auf, sofort zu aktualisieren.

Wie C3RB3R-Ransomware eindringt

In den ersten beiden Tagen gab es zwei mögliche Einfallspunkte. Synology hat seitdem den älteren bestätigt. In der E-Mail vom 30. Oktober heißt es, dass die Angriffe nur die in Synology-SA-24:20 behandelte Schwachstelle ausnutzen und dass die C3RB3R-Ransomware nichts mit PHP2Shell zu tun hat. Die folgende Tabelle zeigt beide Kandidaten im Zustand der bisherigen Diskussion, da das 360er-Paar nach wie vor gepatcht werden sollte.

	Synology sagt	360 sagt
Beratung	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, unauthentifizierte Remote-Code-Ausführung im System-Plugin-Daemon	CVE-2026-13639 (Login-Logik) und CVE-2026-13684 (SCGI), beide CVSS 9.8
Behoben	November bis Dezember 2024	September 2026
Korrigierte Versionen	DSM 7.2.2-72806 Update 1, 7.2.1-69057 Update 6, 7.2-64570 Update 4, 7.1.1-42962 Update 7	DSM 7.4-90075, 7.3.2-86009 Update 4, 7.2.2-72806 Update 9, 7.2.1-69057 Update 12

Die forensischen Beweise deuten zumindest bei einigen Opfern auf den älteren Fehler hin. Der detaillierteste Reddit-Bericht stimmte mit seinen eigenen verbliebenen Protokollen mit dem veröffentlichten CVE-2024-10441-Exploit überein, wobei angemerkt wurde, dass Synology dies nicht bestätigt hatte und dass dasselbe Gerät auch unter dem SA-26:13-Fix-Level lag. Der Bericht von soimy besagt, dass Speicherprotokolle des infizierten Guests auf eine Umgebungsvariablen-Injection über das DSM-Login-Plugin hindeuten, was mit CVE-2024-10441 übereinstimmt, und ein öffentlicher Proof of Concept, der das Login-Benutzername-Feld missbraucht, erschien wenige Tage vor dem Ausbruch auf GitHub. Zwei der drei dokumentierten Rettungsfälle liefen auf inoffizieller Hardware mit einem DS918+-Bootloader, einer davon auf DSM 7.2-64570 Update 3, was genau ein Update vor der Behebung von CVE-2024-10441 liegt. Klon-Hardware kann offizielle Updates nicht ohne Weiteres übernehmen, was sie zum einfachsten Ziel in der Gesamtheit macht.

Die praktische Schlussfolgerung hat sich nicht geändert: Aktualisieren Sie auf einen Build, der beide Sicherheitshinweise abdeckt, und machen Sie DSM nicht mehr im Internet verfügbar. Eine Frage blieb jedoch offen. Wenn die Lücke im Dezember 2024 gepatcht wurde, warum wurden dann im Oktober 2026 innerhalb derselben zwei Tage so viele Systeme mit C3RB3R-Ransomware befallen, darunter auch solche, deren Besitzer glaubten, auf dem neuesten Stand zu sein?

Früh platziert, auf Signal gezündet

Unsere Einschätzung – und dies ist unsere eigene Interpretation und keine Aussage von Synology – ist, dass das Eindringen der C3RB3R-Ransomware und die Verschlüsselung zwei getrennte Ereignisse sind. Die Beweise weisen in diese Richtung:

• Die Backdoor kam zuerst. Im unten stehenden Xiaohongshu-Fall war eine Backdoor-Shell 37 Tage lang auf dem NAS aktiv und hatte Telnet als root aktiviert, bevor auch nur eine einzige Datei verschlüsselt wurde.
• Sie übersteht Updates. Die Cron-Einträge unter /etc/cron.d/synot* erneuern sich von selbst, und mindestens ein Opfer stellte fest, dass sie nach dem Upgrade auf das neueste DSM immer noch vorhanden waren. Das Update schloss zwar die Lücke, ließ aber den Eindringling im System zurück.
• Die Zündungen erfolgten synchronisiert. Systeme mit C3RB3R-Ransomware, die zu unterschiedlichen Zeiten und auf unterschiedlichen Builds kompromittiert worden waren, begannen innerhalb von etwa 48 Stunden nacheinander mit der Verschlüsselung.

Dieses Muster passt zu einem Angreifer, der über Monate hinweg C3RB3R-Ransomware-Implantate auf ungepatchten Systemen platzierte und dann entschied, wann er den Auslöser aus der Ferne betätigen würde. Der gewählte Zeitpunkt war die PHP2Shell-Woche, in der jeder Synology-Administrator mit Patchen beschäftigt war, viele Systeme gerade aktualisiert worden waren und sich die Besitzer genau deshalb sicher fühlten. Synology stellt klar, dass PHP2Shell nicht der Einfallsweg war. Es war die Tarnung. Die Lektion daraus ist, dass ein System, das ungepatcht dem Internet ausgesetzt war, als kompromittiert betrachtet werden sollte, bis es überprüft wurde – was genau dem ersten Schritt der Checkliste von Synology entspricht.

Erste Reaktion auf C3RB3R-Ransomware in 4 Schritten

Wenn Sie jetzt L0CK3D -Dateien vorfinden, entscheidet die Reihenfolge der nächsten zehn Minuten darüber, ob eine Wiederherstellung überhaupt möglich ist. Der Schlüssel, der Ihre Dateien entsperrt, existiert nur innerhalb des laufenden C3RB3R-Ransomware-Prozesses. Ein Neustart, ein kill -9 oder eine Neuinstallation von DSM zerstört ihn.

Die Befehle hinter den Schritten 2 und 3 sehen wie folgt aus. Lesen Sie die Repositories, bevor Sie etwas ausführen, da die Details davon abhängen, welche Binärdatei Sie haben.

# Schritt 2: Verschlüsselungsprozess finden (seine ausführbare Datei wird als gelöscht angezeigt)

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

# Einfrieren. Hier niemals kill -9 verwenden.

kill -STOP <PID>	grep State /proc/<PID>/status # sollte T (stopped) anzeigen	# Nach der Persistenz suchen, die ihn zurückbringt	ls -l /etc/cron.d/ | grep synot
Können Sie es entschlüsseln? Die drei GitHub-Rettungsfälle	Es gibt keinen universellen Entschlüsseler für C3RB3R-Ransomware, und jeder, der einen verkauft, rät nur. Was es gibt, sind drei sorgfältige Fallstudien, die Ihnen genau zeigen, wann eine Wiederherstellung funktioniert.	Repository	Maschine
Ergebnis	Grund	Repository	soimy/c3rb3r-rescue
DSM in einer virtuellen Maschine unter Proxmox VE mit GitLab	Wiederhergestellt	Eine 16-GiB-Kopie des Guest-RAM enthielt den 48-Byte-Sitzungsschlüssel. GitLab mit 80 Projekten und 9.253 LFS-Objekten wiederhergestellt.	Der Verschlüsseler war bereits etwa 30 Stunden zuvor beendet worden. Vollständige RAM- und Swap-Scans fanden keinen Schlüssel.

Das dritte Repository ist das wichtigste zu lesen, denn sein Titel ist seine Lektion: Niemals neu gestartet bedeutet nicht wiederherstellbar. Was zählt, ist, ob der Prozess der C3RB3R Ransomware noch aktiv ist. Sobald er beendet wird, überschreibt er seinen Schlüsselpuffer mit Nullen, und der Schlüssel ist weg. Ein bei einem Opfer wiederhergestellter Schlüssel ist auch bei einem anderen nutzlos, da jeder Durchlauf einen neuen Sitzungsschlüssel generiert.

Warum der Schlüssel nur im Arbeitsspeicher liegt

Die Analyse von Benjamin-zlt erklärt das Dateiformat der C3RB3R Ransomware im Detail und erläutert sowohl, warum dies funktioniert, als auch, warum es das normalerweise nicht tut.

• Jede Datei erhält ihren eigenen zufälligen ChaCha8-Schlüssel. Dieser Schlüssel wird mit einem Sitzungs-Hauptschlüssel unter Verwendung von AES-256-CBC verschlüsselt und in einem 588-Byte-Trailer am Ende der Datei gespeichert.
• Der Sitzungs-Hauptschlüssel ist 48 Bytes groß: ein 16-Byte-IV plus ein 32-Byte-AES-Schlüssel. Er wird niemals auf die Festplatte geschrieben. Ein globaler Zeiger innerhalb des laufenden Prozesses weist darauf hin.
• Der Trailer enthält außerdem einen Blob, der mit dem öffentlichen Schlüssel des Angreifers verschlüsselt ist (RSA-2048), sodass ohne den laufenden Prozess nur der Angreifer den Sitzungsschlüssel wiederherstellen kann.
• Nicht jede Datei ist vollständig verschlüsselt. In einer Stichprobe von 400 Dateien nutzten etwa 56 % den segmentierten Modus, bei 31 % war nur das erste 1 MiB verschlüsselt und 13 % waren durchgehend verschlüsselt. Teilweise verschlüsselte Dateien sind zwar immer noch nicht lesbar, aber eine Footer-Triage verrät Ihnen, was übrig ist.

Die Schwachstelle der C3RB3R Ransomware ist also eng begrenzt und zeitlich limitiert: Der Verschlüsseler behält den Hauptschlüssel während der gesamten Sitzung im Arbeitsspeicher. Friert man ihn ein, während er läuft, kann man den Schlüssel extrahieren. Verpasst man dieses Fenster, bleibt nur der Blob mit dem öffentlichen Schlüssel, der als unknackbar konzipiert ist.

Die Geschichte eines Opfers: 50 TB und keine Snapshots

Ein detaillierter Bericht, der am 29. Oktober 2026 vom Benutzer 柯基爱好者 auf Xiaohongshu veröffentlicht wurde, begleitet ein Mitglied seiner NAS-Gruppe durch die Nacht. Er bemerkte die Erpressernachricht der C3RB3R Ransomware, bestätigte die Kopfzeile C3RB3R INSTRUCTIONS und stand kurz davor, Bitcoins zu kaufen, bevor die Gruppe ihn auf die GitHub-Fälle aufmerksam machte.

Daraufhin nutzte er einen KI-Programmierassistenten über SSH zur Untersuchung. Dieser fand und fror den Verschlüsseler ein, sodass ab diesem Zeitpunkt nichts Neues mehr verschlüsselt wurde. Er fand auch heraus, dass sich vermutlich seit 37 Tagen eine Backdoor-Shell auf der NAS befand und Telnet als Root aktiviert hatte, was bedeutet, dass der erste Einbruch und die Verschlüsselung mehr als einen Monat auseinanderlagen. Er schrieb ein Skript zur Beweissicherung und wartete korrekterweise auf seine Bestätigung, bevor er etwas als Root ausführte.

Sein Glück war, dass C3RB3R Ransomware langsam ist. Bei mehr als 50 TB Daten, die verarbeitet werden mussten, hatte der Verschlüsseler erst seine Fotos von 2024 erreicht, und für diese gab es ein Cold Backup auf einem Cloud-Laufwerk. Er verschob Arbeitsdaten auf ein kleineres NAS und parkte das verschlüsselte Volume für später. Seine eigene Zusammenfassung war gewohnt direkt: Er hatte keine Snapshots, und mit Snapshots wäre dies leicht zu beheben gewesen. Ein zweites Opfer auf X fasste dieselbe Lektion von der anderen Seite zusammen: RAID 6 plus drei Backup-Sätze, alle auf demselben Gerät, alle zusammen verschlüsselt.

Wie wir C3RB3R Ransomware von unseren Backups fernhalten

Jede oben genannte Geschichte über Datenverlust hat das gleiche Muster: Die Backups waren von dem kompromittierten Gerät aus erreichbar. C3RB3R Ransomware verschlüsselt alles, worauf das kompromittierte DSM schreiben kann. Die Lösung besteht also darin, mindestens eine Kopie an einem Ort aufzubewahren, auf den DSM überhaupt nicht schreiben kann. So machen wir es für die von uns gehosteten Websites, und das entspricht der 3-2-1-1-0-Regel.

Regel	Bedeutung	Wie wir es machen
3	Drei Kopien der Daten	Die Live-VM, eine Replik auf einem zweiten NAS und ein geplanter Export
2	Zwei Arten von Medien	NAS-Volumes plus ein USB-Laufwerk und ein Cloud-Laufwerk
1	Eine Kopie an einem externen Standort	Exporte, die mit Cloud Sync mit Google Drive synchronisiert werden
1	Eine Kopie offline oder unveränderlich	Hostseitige VM-Snapshots, die der Guest nicht verändern kann, plus der getrennte USB-Export
0	Null Fehler bei der Wiederherstellung	Wir stellen tatsächlich von den Repliken wieder her und starten von ihnen, wenn wir VMs zwischen Hosts verschieben

Führen Sie Docker innerhalb von Virtual DSM aus, nicht auf dem Host

Unsere WordPress-Container laufen nicht auf dem physischen NAS. Sie laufen innerhalb eines Virtual DSM-Guests, und der Guest wird durch den Virtual Machine Manager auf dem Host geschützt. Wenn C3RB3R Ransomware Root-Rechte innerhalb des Guests erlangt, übernimmt sie nur diesen Guest und sonst nichts. Die Snapshots des Guests befinden sich auf dem Host-Speicher, außerhalb des Guest-Dateisystems, sodass die Ransomware innerhalb der VM sie weder sehen noch verschlüsseln oder löschen kann. Die Wiederherstellung ist ein Snapshot-Rollback, das nur wenige Minuten dauert.

VMM Pro fügt die Komponenten hinzu, die daraus ein echtes Backup machen: einen Schutzplan, der Snapshots der VM erstellt und sie auf ein zweites NAS im Cluster repliziert, sodass auch ein ausgefallener Host abgedeckt ist. Unser Cluster besteht aus einer DS1621xs+ und einer DS1525+, die gegenseitig replizieren. Wir haben den Teil mit dem geplanten Export und Cloud Sync zu Google Drive separat beschrieben, und der Vergleich zwischen dem kostenlosen VMM und VMM Pro erklärt, welche Teile die Lizenz benötigen.

Wenn Sie Docker direkt auf DSM ausführen, verwenden Sie unveränderliche Snapshots

Nicht jeder möchte eine VM-Ebene. Wenn Ihre Container auf dem Host laufen, sind unveränderliche Snapshots der Schutz gegen C3RB3R-Ransomware. Aktivieren Sie diese in Snapshot Replication für den gemeinsamen Ordner, der Ihre Containerdaten enthält. Sie benötigen DSM 7.2 oder neuer sowie ein Btrfs-Volume, und während des Sperrzeitraums kann sie niemand löschen, auch kein von einem Angreifer übernommenes Administratorkonto. Zwei Details sind hierbei entscheidend:

• Verwenden Sie Bind-Mounts in einen gemeinsamen Ordner wie zum Beispiel /volume1/docker/app. Benannte Docker-Volumes befinden sich unter /volume1/@docker, was kein gemeinsamer Ordner ist und überhaupt nicht per Snapshot gesichert werden kann.
• Exportieren Sie Datenbanken vor dem Snapshot in eine Datei. Ein Snapshot einer laufenden MariaDB entspricht einer Kopie nach einem Stromausfall. Ein geplanter mysqldump in denselben gemeinsamen Ordner liefert Ihnen einen sauberen Wiederherstellungspunkt, den der Snapshot anschließend sperrt.
• Wählen Sie einen Sperrzeitraum, der länger ist, als ein Angreifer unbemerkt verweilen kann. Das oben genannte Opfer hatte 37 Tage lang eine Hintertür im System, bevor die Verschlüsselung begann. Sieben Tage unveränderlicher Snapshots hätten nicht ausgereicht, um zu einem sauberen Zustand zurückzukehren.

Unsere zusätzliche Schutzschicht: Active Insight erstellt einen Snapshot, wenn die Verschlüsselung beginnt

Hier ist die Schutzschicht, die die meisten Anleitungen übersehen. Active Insight, der Cloud-Überwachungsdienst von Synology, kann die Dateiaktivität in Ihren freigegebenen Ordnern überwachen und reagiert selbstständig, sobald festgestellt wird, dass es sich um Ransomware handelt. Synology dokumentiert dies in seinem NAS-Sicherheitsleitfaden: Wenn ein Ransomware-Ereignis erkannt wird, sendet Active Insight eine Ereignisbenachrichtigung und erstellt automatisch einen Snapshot des freigegebenen Ordners. Auf Modellen, die dies unterstützen, ist dieser Snapshot unveränderlich (immutable).

Warum dies insbesondere für C3RB3R-Ransomware wichtig ist: Die Verschlüsselungskomponente der C3RB3R-Ransomware arbeitet langsam. Das Opfer mit mehr als 50 TB Daten war erst bei seinen Fotos aus dem Jahr 2024, als er es bemerkte. Ein Snapshot, der bei den ersten Anzeichen eines Verschlüsselungsmusters erstellt wird, friert alles ein, was noch nicht angetastet wurde – was der Großteil des Volumes sein kann. Es spielt auch keine Rolle, wie die C3RB3R-Ransomware eingedrungen ist, da der Dienst überwacht, was mit den Dateien geschieht, und nicht die Anmeldeseite. Auf unserer DS1621xs+ zeigt die Seite „Dateiaktivität“ den Ransomware-Schutz als „Geschützt“ an.

Lesen Sie die Einschränkungen, bevor Sie sich darauf verlassen. Diese stammen aus Synology’s Dateiaktivitäts-Dokumentation:

• Die Überwachung der Dateiaktivität ist standardmäßig deaktiviert. Registrieren Sie das NAS in der Systemsteuerung für Active Insight und aktivieren Sie anschließend die Überwachung für jeden Host im Active Insight-Portal.
• Es erfordert Snapshot Replication, DSM 7.2 oder höher, Active Insight 3.0.2 oder höher, mindestens 1 GB Arbeitsspeicher und eine diesem NAS zugewiesene Active Insight-Lizenz.
• Maximal ein automatischer Snapshot pro freigegebenem Ordner und Tag. Es ist ein Sicherheitsnetz, das nach der Erkennung greift, und kein Ersatz für geplante unveränderliche Snapshots.
• Nicht abgedeckt: Aufnahmeordner von Surveillance Station und freigegebene Ordner auf externen USB-Laufwerken.
• Die Unveränderlichkeit hängt vom Modell ab. Auf einem Modell ohne unveränderliche Snapshots kann ein Angreifer mit root-Rechten den automatischen Snapshot dennoch löschen; kombinieren Sie ihn daher mit dem oben beschriebenen Zeitplan für unveränderliche Snapshots.

Möchten Sie dasselbe Setup? SynoPower Club verkauft originale Lizenzen für beide Bausteine: eine Virtual DSM (VDSM)-Lizenz um Ihre Docker-Dienste in einem isolierten Guest auszuführen, und eine VMM Pro-Lizenz für Schutzpläne, NAS-übergreifende Replikation und Live-Migration. Lizenzschlüssel werden per E-Mail geliefert.

Wo finde ich weitere offizielle Ressourcen?

Die C3RB3R-Ransomware auf Synology ist zum Zeitpunkt der Erstellung dieses Textes seit zwei Tagen öffentlich bekannt, und es gibt noch keine offizielle Videoberichterstattung. Daher führt dieser Abschnitt Primärquellen anstelle von Anleitungen auf.

• Der Synology-Sicherheitshinweis vom 29. Oktober 2026, der Benutzern veralteter DSM-Versionen rät, sofort zu aktualisieren und automatische Updates zu aktivieren, gefolgt von einer Kunden-E-Mail am 30. Oktober, die SA-24:20 als die einzige betroffene Schwachstelle bestätigt.
• Synology-SA-24:20 und Synology-SA-26:13 sind die Versionstabellen. Überprüfen Sie Ihre Build-Nummer in der Systemsteuerung unter „Aktualisieren & Wiederherst.“ mit beiden.
• DSM in einer virtuellen Maschine unter Proxmox VE mit GitLab ist der beste Index aller bekannten Fälle, einschließlich derer, die hier nicht behandelt werden, und die klarste Erklärung dafür, wann Speicherforensik zwecklos ist.
• Die drei oben verlinkten r/synology-Threads, insbesondere der forensische Bericht, der die Befehle zur Festplattenuntersuchung im schreibgeschützten Modus Schritt für Schritt enthält: Nun, es ist schließlich passiert.

Synology’s eigene Checkliste (30. Oktober 2026)

Die E-Mail von Synology an Kunden endet mit vier Schritten. Sie sind kurz, und jeder einzelne von ihnen ist wichtig gegen C3RB3R-Ransomware:

1. Auf Eindringlinge prüfen. C3RB3R-Ransomware hinterlässt geplante Persistenz. Führen Sie daher einen Scan mit dem Security Advisor aus und suchen Sie anschließend im Aufgabenplaner nach Skripten, die Sie nicht erstellt haben, sowie unter Benutzer und Gruppe nach Administratorkonten, die Sie nicht hinzugefügt haben. Wenn etwas verdächtig aussieht, wenden Sie sich an den Synology Support.
2. Alles aktualisieren. Installieren Sie das neueste DSM in der Systemsteuerung unter „Aktualisieren und Wiederherstellen“ und aktualisieren Sie anschließend jedes Paket im Paket-Zentrum.
3. Automatische Updates aktivieren unter „Aktualisieren und Wiederherstellen“, damit zukünftige Sicherheitskorrekturen sofort nach ihrer Veröffentlichung angewendet werden.
4. Ein externes Backup aufbewahren. Verwenden Sie Hyper Backup und Snapshot Replication, um eine Kopie an einem separaten Ort aufzubewahren, und überprüfen Sie regelmäßig, ob die Sicherungsaufgaben tatsächlich abgeschlossen werden.

Schritt eins ist derjenige, den die Leute überspringen. Wenn Ihr Gerät vor der Behebung im Dezember 2024 aus dem Internet erreichbar war, hat sich die C3RB3R-Ransomware möglicherweise bereits eingenistet, und ein heutiges Update verrät Ihnen nicht, ob bereits jemand im System ist.

Ein kostenloses Tool, das die Überprüfung für Sie durchführt

Wenn Sie sich im Terminal auskennen, kann Schritt eins jetzt ein einzelner Befehl sein. synology-nas-cli ist ein Open-Source-Befehlszeilentool unter der MIT-Lizenz, das am 30. Oktober 2026 vom unabhängigen Entwickler Akari Sora veröffentlicht wurde. Es meldet sich über seine Web-API bei DSM an und prüft das Gerät hinsichtlich dieser Kampagne. Das Projekt befindet sich auf GitHub: akari-sora/synology-nas-cli.

Wir haben den Code durchgesehen, bevor wir ihn verlinkt haben. Es nutzt ausschließlich die Python-Standardbibliothek und kommuniziert mit nichts außer Ihrem NAS, dem Synology-Download-Server, PyPI und dem soimy-Rettungs-Toolkit. Es sendet keine Telemetriedaten, und das grundlegende Audit liest nur. Folgendes wird überprüft:

• Patch-Stand. Ihr DSM-Build im Vergleich zu Synology-SA-26:13, was auch den älteren SA-24:20-Fix abdeckt, sowie Ihre installierten Pakete im Vergleich zu SA-26:14.
• Angriffsfläche. QuickConnect, UPnP-Portweiterleitung auf dem Router, die DSM-Firewall, Automatische Blockierung, SMB1 und das integrierte Admin-Konto.
• Spuren von C3RB3R-Ransomware. Die injizierten Anmeldezeichenfolgen im Verbindungsprotokoll, /etc/cron.d/synot* -Einträge, die libgld und qnetd -Binärdateien, zusätzliche Root-Konten, SSH-Schlüssel und Lösegeldschreiben auf Ihren Freigaben.
• Schnappschüsse. Freigegebene Ordner, die keinen funktionierenden Snapshot-Zeitplan haben.

Es kann auch das meiste von dem beheben, was es findet. Wenn Dateien gerade verschlüsselt werden, friert sein contain-Befehl den Verschlüsseler mit SIGSTOP ein – derselbe Schritt wie Schritt zwei unserer Erstreaktionsliste. Sein rescue-Befehl steuert dann das soimy-Toolkit an, um den Arbeitsspeicher zu erfassen und nach dem Schlüssel zu suchen.

nas incident                 # Nur-Lese-Audit

nas incident --deep # auch nach dem Implantat suchen (ein Nur-Lese-Root-Skript)

• nas incident fix --dry-run # alle Änderungen auflisten, die vorgenommen würden, nichts ändern. Lesen Sie diese Hinweise, bevor Sie Änderungen zulassen:.
• Es ist brandneu. Das Projekt ist erst wenige Tage alt, stammt von einem einzelnen Entwickler, steht in keiner Verbindung zu Synology und wurde bisher kaum extern überprüft. Beginnen Sie mit dem Nur-Lese-Audit und dem Testlauf.
• Die Firewall-Korrektur kann Sie aussperren. Es stellt die DSM-Firewall so ein, dass alles verweigert wird, außer den von Ihnen aufgelisteten Netzwerken. Führen Sie es von einem Computer im selben LAN aus und wissen Sie, wo sich die RESET-Taste befindet.
• Es schaltet QuickConnect aus. Das ist die sicherere Einstellung. Wenn Ihre Familie jedoch über QuickConnect auf Synology Photos oder Surveillance Station zugreift, richten Sie zuerst ein VPN oder Tailscale ein.
• Der Deep Scan, contain und rescue werden als root ausgeführt. Sie arbeiten über eine temporäre Aufgabe im Aufgabenplaner, da dies die einzige Möglichkeit ist, Protokolle mit Nur-Root-Zugriff zu lesen und Prozesse einzufrieren.
• Die README schlägt vor, die Ausführung an einen KI-Agenten zu übergeben. Wenn Sie das tun, bewahren Sie das Passwort in einem Passwort-Manager auf statt im Chat und bestätigen Sie die Korrektur selbst.

Für den Rest des Härtungsschemas decken unsere Anleitungen zu dem Betreiben einer öffentlichen Website auf einem Synology NAS und zu dem, was Threat Prevention sehen kann und was nicht, die Netzwerkseite ab, und die PHP2Shell-Patch-Anleitung deckt das andere kritische Problem ab, das in derselben Woche auftauchte.

C3RB3R-Ransomware: Einschränkungen und Sicherheitshinweise

Ein Update entfernt eine bestehende Infektion nicht. Mindestens ein Opfer stellte fest, dass die Cron-Persistenz nach dem Upgrade auf das neueste DSM immer noch vorhanden war. Wenn Sie ohne Patch gefährdet waren, überprüfen Sie /etc/cron.d, den Aufgabenplaner, Startskripte und aktivierte Dienste wie Telnet, und ändern Sie anschließend alle Zugangsdaten.

Auf dem neuesten Stand ist nicht dasselbe wie sauber. Ein Reddit-Opfer glaubte, DSM sei aktuell, und ein anderes wurde trotz 2FA und eines starken Passworts getroffen. Ein Gerät, das vor dem Patchen kompromittiert wurde, kann das Implantat durch jedes spätere Update weitertragen. Betrachten Sie jede DSM-Anmeldeseite, die aus dem Internet erreichbar ist, als Ziel – einschließlich derer, die über UPnP veröffentlich wurden und die Sie nie bewusst eingerichtet haben. Verwenden Sie ein VPN oder Tailscale für den Fernzugriff und schalten Sie UPnP am Router aus.

RAID und lokale Backups sind keine Backups gegen C3RB3R-Ransomware. Alles, worauf das kompromittierte DSM zugreifen und schreiben kann, wird verschlüsselt, einschließlich Hyper Backup-Zielen auf demselben Gerät und eingebundener Netzwerkfreigaben.

Zahlen Sie nicht, bevor Sie die Fälle gelesen haben. Das Bezahlen von C3RB3R-Ransomware-Betreibern finanziert die nächste Welle und garantiert nichts. Wenn der Verschlüsseler noch läuft, ist die Methode über den freien Arbeitsspeicher Ihre beste Chance. Falls nicht, sind eigene externe Kopien der einzige realistische Weg.

Seien Sie vorsichtig mit dem, was Sie in einen KI-Assistenten einfügen. KI-Tools haben hier mehreren Opfern geholfen, aber geben Sie ihnen keine Passwörter, wiederhergestellten Schlüssel, vollständigen Speicherabbilder oder Geschäftsdaten. Lassen Sie sich Befehle vorschlagen und führen Sie alles, was Root-Rechte erfordert, selbst aus.

Klon-Hardware birgt ein zusätzliches Risiko. Mehrere dokumentierte Opfer führten DSM auf inoffizieller Hardware aus, wo offizielle Updates nur schwer oder gar nicht angewendet werden können. Wenn das Ihr Setup ist, gehen Sie davon aus, dass kein Patch installiert ist, und trennen Sie das Gerät vollständig vom Internet.

Verweise

• Synology-Sicherheitshinweis zu DSM-Ransomware-Angriffen, 29. Oktober 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 und die behobenen DSM-Builds.
• Synology-SA-26:13 DSM, CVE-2026-13639 und CVE-2026-13684, veröffentlicht am 18. September 2026.
• Benjamin-zlt C3RB3R Ransomware Bare-Metal-Rettung, das Dateiformat, das Schlüssel-Layout und der SIGSTOP-Ablauf.
• Die Speicherrettung funktioniert nur, solange der Verschlüsseler aktiv ist., Es gilt dieselbe Regel wie bei den drei GitHub-Fällen.
• IT-Connect über die C3RB3R-Kampagne, fasst die 360-Zuordnung und den Zeitverlauf zusammen.
• Synology Knowledge Center: Erhöhung der Sicherheit Ihres Synology NAS, einschließlich der Information, wie Active Insight automatisch einen Snapshot eines gemeinsamen Ordners erstellt, wenn Ransomware erkannt wird.

Häufig gestellte Fragen

Sorgen Sie dafür, dass Sie der nächste C3RB3R-Ransomware-Angriff nur eine Wiederherstellung kostet – und kein Lösegeld. Führen Sie Ihre Docker-Dienste innerhalb von Virtual DSM aus und schützen Sie den gesamten Guest mit VMM Pro-Schutzplänen, die auf ein zweites NAS repliziert werden. SynoPower Club verkauft originale Lizenzen für beides, wobei die Lizenzschlüssel per E-Mail geliefert werden.