Synology entfernt Auslöser für Defender-Fehlalarm bei Active Backup for Business

Die gefährlichste Störung im Backup ist nicht die, bei der ein Job rot wird, sondern die, bei der es nach der ersten Meldung still bleibt. Genau das ist seit Anfang August 2026 in mehreren Windows-Umgebungen passiert, in denen Synology Active Backup for Business die virtuellen Maschinen von Hyper-V-Wirten sichert: Der Microsoft Defender hielt einen Bestandteil der Backup-Software für einen Trojaner, schob ihn in Quarantäne, und die Sicherungen liefen nicht mehr durch. Synology hat den auslösenden Aufruf inzwischen entfernt. Bei der Nachmessung kam ein zweiter Punkt zum Vorschein, der jeden betrifft, der seine Virtualisierungs-Wirte mit Defender-Regeln härtet.

Wer Active Backup for Business auf Windows-Servern einsetzt, sollte den Vorgang nicht nur als erledigt abhaken. Es gibt drei konkrete Aufgaben: den Agenten-Stand prüfen, damals gesetzte Notfall-Ausnahmen wieder zurücknehmen, und den Sicherungserfolg der letzten Wochen rückwirkend verifizieren. Ein akuter Handlungsdruck im Sinne einer Sicherheitslücke besteht nicht, ein Wartungsfenster reicht.

Was ist passiert?

Anfang August 2026 meldete ein Administrator dem IT-Blog von Günter Born, dass der Microsoft Defender auf mehreren von ihm betreuten Windows-Hypervisoren die Synology-Backup-Software als Trojan:Win32/Commando.A!ml erkannt und entfernt hatte. Der Schweregrad lautete schwerwiegend, der Status entfernt. Als betroffenes Element wies der Schutzverlauf keine Datei aus, sondern eine Kommandozeile der Form cmd.exe /C powershell -encodedcommand <Base64-Block>.

Bemerkenswert ist die Ausgangslage, weil sie den Verdacht auf eine lokale Fehlkonfiguration ausräumt: Der Defender lief auf allen betroffenen Systemen im Auslieferungszustand, also ohne Härtung, ohne erhöhte Cloud-Blockierstufe und ohne zusätzliche Regeln. Betroffen waren verschiedene Standorte, verschiedene Netze und verschiedene Windows-Server-Varianten, zusätzlich eine davon unabhängige Umgebung eines Kollegen. Active Backup for Business war überall aktuell.

Hinter dem Base64-Block steckte laut der Analyse des Administrators kein Schadcode, sondern ein Verbindungstest: eine rohe TCP-Verbindung zum NAS auf Port 5510, das Senden weniger Bytes mit dem Inhalt einer Testanfrage und der Abgleich der Antwort gegen ein gemeinsames Geheimnis. Kein Nachladen von Code, keine Persistenz, keine Registry-Zugriffe. Für eine Machine-Learning-Heuristik sah das Muster aus kodierter PowerShell-Kommandozeile, rohem Socket und stündlicher Wiederholung trotzdem nach Fernsteuerung aus.

Was Synology geändert hat

Der Administrator hat vier Defender-Diagnoseprotokolle über fünf Wochen ausgewertet und die Änderung so datiert: Bis zum 11. August 2026 lief der Verbindungstest stündlich, danach über dreizehn Tage und dutzende Sicherungsläufe kein einziges Mal mehr. Seine Zusammenfassung ist knapp: Synology hat genau einen Aufruf entfernt, nämlich den auffälligsten, und sonst nichts angefasst.

• Entfernt: der Base64-verpackte PowerShell-Verbindungstest zum NAS auf Port 5510. Er war redundant, weil die eigentliche Übertragungskomponente die Verbindung ohnehin selbst aufbaut.
• Geblieben: drei rein lokale PowerShell-Sonden, die Laufwerksbuchstaben ermitteln, die Ausführbarkeit prüfen und eine Sperrdatei anlegen, weiterhin als Base64-kodierte Kommandozeile.
• Neue Bewertung: Diese verbliebenen Skripte stuft der Defender laut den Protokollen weiterhin als verdächtig mit niedriger Konfidenz ein, blockiert sie aber nicht mehr. Seit dem 2. August 2026 gab es keinen Fund von Commando.A!ml mehr.
• Verteilweg: Ausgeliefert wurde die Änderung zunächst als manueller Support-Patch aus dem Ticket des Administrators. Das reguläre Paket-Update auf 3.2.1-25059 zieht denselben Stand laut seiner Auswertung nur in die Allgemeinversion nach.

Ein Detail stützt die Bewertung, dass wirklich beide Seiten nachgebessert haben: Die geräteweite Zulassung, die der Administrator im August als Notmaßnahme gesetzt hatte, ist nach sieben Tagen von selbst verfallen. Trotzdem blieb es still. Damit kann die Zulassung die Erkennung nicht mehr verdecken, die Fehlerkennung auf Microsoft-Seite ist also tatsächlich zurückgenommen worden.

Zur Quellenlage: Synology hat den Fix nach unserer Recherche nicht in einer öffentlich klar zugeordneten Release-Note dokumentiert. Die Release-Notes-Seite zu Active Backup for Business lässt sich ohne JavaScript nicht auslesen, und weder Knowledge Center noch eine Support-Meldung nennen den Defender-Fehlalarm ausdrücklich. Belegbar ist über das Synology-Archiv lediglich, dass das Paket in Version 3.2.1-25059 existiert. Alle technischen Details zum entfernten Aufruf stammen aus der Analyse des betroffenen Administrators, veröffentlicht bei Borns IT- und Windows-Blog. Das ist eine seriöse, aber eben keine Herstellerbestätigung.

Die Härtungsfalle für Hyper-V-Wirte

Für die Nachmessung hat der Administrator einen Prozess-Mitschnitt während eines echten VM-Backups angefertigt. Danach arbeitet Active Backup for Business auf zwei getrennten Wegen:

• Steuerung über WinRM: VMs auflisten, Snapshots verwalten und virtuelle Festplatten prüfen läuft über den PowerShell-Fernkanal. Dabei startet winrshost.exe eine cmd.exe, die wiederum powershell.exe mit kodierter Kommandozeile aufruft. Genau diese Aufrufe sieht der Defender.
• Datenübertragung nativ: Die eigentlichen Daten überträgt ein von Synology signiertes Programm namens hyperv_helper.exe, das sich selbst zum NAS auf Port 5510 verbindet. Deshalb ließ sich der zusätzliche PowerShell-Verbindungstest folgenlos streichen.
• Snapshots sauber gelöst: Die Änderungsverfolgung läuft über die native Hyper-V-Schnittstelle für Reference Points, also die Grundlage von Resilient Change Tracking für inkrementelle Sicherungen, nicht über improvisiertes Hantieren mit Checkpoints.

Der kritische Punkt steckt im Start dieser Übertragungskomponente. Active Backup for Business startet hyperv_helper.exe per WMI-Prozesserstellung:

Invoke-WmiMethod -Path win32_process -Name create

Das ist exakt das Muster, das eine bekannte Regel zur Verringerung der Angriffsfläche unterbindet, im Englischen Block process creations originating from PSExec and WMI commands, im Deutschen Erstellung von Prozessen durch PSExec- und WMI-Befehle blockieren. Die Regel-GUID lautet d1e49aac-8f56-4280-b9ba-993a6d77406c. Microsoft dokumentiert sie in der offiziellen ASR-Regelreferenz und weist dort selbst darauf hin, dass sie nur eingeschränkte Ausnahmen unterstützt.

Wer diese Regel auf Blockieren stellt und auf demselben Wirt Active Backup for Business für Hyper-V betreibt, legt sein Backup lahm, und zwar lautlos. Die Software meldet dann lediglich, die VM lasse sich nicht sichern, ohne einen Hinweis auf die tatsächliche Ursache. Das ist dieselbe Tücke wie beim ursprünglichen Fehlalarm: Die Fehlermeldung zeigt nicht dorthin, wo das Problem sitzt. Auf den Wirten des betroffenen Administrators steht die Regel bewusst nur im Audit-Modus, protokollieren statt blockieren, und genau deshalb laufen die Sicherungen. Den eigenen Stand liefert eine Zeile PowerShell:

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

Steht die genannte GUID in der ersten Liste und an derselben Position der zweiten Liste der Wert 1 für Blockieren, ist die Regel scharf geschaltet. Auf einem Virtualisierungs-Wirt mit Active Backup for Business ist das eine der wenigen ASR-Regeln, die man nicht bedenkenlos aktivieren kann.

Für wen ist das relevant?

• Direkt betroffen: Windows-Server und Hyper-V-Wirte mit installiertem Agenten von Synology Active Backup for Business und aktivem Microsoft Defender Antivirus. Dort trat der Fehlalarm auf, und dort greift auch die ASR-Falle.
• Ebenfalls prüfenswert: Umgebungen, in denen im August 2026 eine Notfall-Ausnahme oder eine geräteweite Zulassung gesetzt wurde. Diese Konfiguration ist heute überflüssig und schwächt den Schutz unnötig.
• Nicht betroffen von der ASR-Falle: Installationen, die nur Dateiserver, physische Windows-Clients oder Dateifreigaben sichern, ohne Hyper-V-Sicherung auf dem Wirt. Die WMI-Prozesserstellung betrifft den Hyper-V-Pfad.
• Nicht betroffen vom Fehlalarm: Umgebungen mit einer anderen Endpoint-Protection als dem Microsoft Defender sowie NAS-seitige Sicherungen ohne Windows-Agenten, etwa reine Dateisynchronisation.
• Indirekt relevant: Alle, die eine Synology als zentrales Backup-Ziel betreiben. Der Fall ist ein Musterbeispiel für den Konflikt zwischen Backup-Software und Endpoint-Schutz.

Wie kritisch ist das?

Sicherheitstechnisch ist der Vorgang harmlos: Es gab keine Schwachstelle, keine CVE, keinen Angriff. Der Defender hat legitime Software falsch bewertet. Betrieblich war die Lage dagegen ernst, weil das Ergebnis ein stiller Ausfall der Datensicherung war. Nach dem ersten fehlgeschlagenen Lauf kam laut der Schilderung des betroffenen Administrators keine weitere Benachrichtigung mehr, obwohl die stündlichen Läufe weiter scheiterten. Eine einzelne Fehlermeldung ist im Alltag Rauschen, drei in Folge wären das Signal gewesen. Genau dieses Signal fehlte.

Das ist die gefährlichste Fehlerklasse im Backup-Betrieb, weil sie erst im Ernstfall sichtbar wird. Ein dauerhafter Fehler erzeugt eine Meldung und danach Stille, was von einer Erholung nicht zu unterscheiden ist. Je ruhiger es wird, desto schlechter steht es tatsächlich. Für die Bewertung im Unternehmen heißt das: Die aktuelle Lage ist entspannt, weil der Auslöser weg ist. Das Restrisiko liegt in den Wochen, in denen möglicherweise unbemerkt nicht gesichert wurde, und in Notfall-Ausnahmen, die niemand zurückgenommen hat.

Was sollten Admins jetzt tun?

• Bestand und Version prüfen: In DSM den Paketstand von Active Backup for Business erfassen und den Windows-Agenten auf allen Wirten auf denselben Stand bringen. Version 3.2.1-25059 oder neuer enthält den bereinigten Aufruf laut der ausgewerteten Protokolle.
• Quarantäne-Verlauf kontrollieren: Im Defender-Schutzverlauf und per PowerShell nachsehen, ob Komponenten der Backup-Software in Quarantäne liegen oder lagen. Dafür eignen sich Get-MpThreatDetection und Get-MpThreat, ergänzend die Ereignisanzeige unter den Windows-Defender-Betriebsprotokollen.
• Alte Ausnahmen zurücknehmen: Prüfen, ob im August gesetzte Pfad-Ausnahmen oder geräteweite Zulassungen noch aktiv sind, und diese jetzt entfernen. Eine breite Ausnahme auf ein Backup-Verzeichnis ist ein bekanntes Angriffsziel, weil Ransomware gezielt nach ausgenommenen Pfaden sucht.
• ASR-Stand auf Hyper-V-Wirten prüfen: Die GUID d1e49aac-8f56-4280-b9ba-993a6d77406c gegen die eigene Konfiguration abgleichen. Wo Active Backup for Business virtuelle Maschinen sichert, gehört die Regel in den Audit-Modus, nicht auf Blockieren.
• Sicherungserfolg rückwirkend verifizieren: Die Job-Historie in Active Backup for Business für den Zeitraum ab Anfang August durchsehen und Lücken dokumentieren, statt sich auf die Abwesenheit von Fehlermeldungen zu verlassen.
• Restore-Test durchführen: Mindestens eine virtuelle Maschine und einen Dateisatz tatsächlich zurückspielen. Ein Sicherungslauf ohne Fehler ist kein Nachweis für eine wiederherstellbare Sicherung.
• Monitoring auf Erfolgsmeldung umstellen: Nicht auf Fehlermeldungen warten, sondern eine aktive Erfolgsmeldung pro Lauf erwarten und alarmieren, wenn sie ausbleibt. Ein Dead-Man-Switch fängt genau den Fall ab, in dem gar nichts mehr gemeldet wird.

Warum pauschale Ausnahmen die falsche Antwort sind

Der schnellste Weg aus einem Fehlalarm ist eine Ausnahme im Virenschutz, und genau deshalb ist er der gefährlichste. Eine Pfad-Ausnahme auf ein Backup-Verzeichnis nimmt dauerhaft genau den Ordner aus der Prüfung, in dem im Ernstfall die Rettung liegt. Angreifer kennen dieses Muster und fragen ausgenommene Pfade gezielt ab. Der Fall zeigt zusätzlich, dass auch die vermeintlich harmlose Zulassen-Schaltfläche im Defender Nebenwirkungen hat: Sie wirkt nicht auf den einzelnen Prozess, sondern schaltet die Erkennungsregel geräteweit ab.

Wenn eine Ausnahme unvermeidbar ist, gelten drei Regeln: so eng wie möglich, also auf die konkrete signierte Binärdatei statt auf ein Verzeichnis. Dokumentiert, mit Datum, Begründung und Ticketnummer. Und befristet, mit einem gesetzten Termin zur Überprüfung, damit die Ausnahme nicht Jahre später als unerklärliche Altlast in der Konfiguration steht. Im vorliegenden Fall wäre Abwarten die bessere Wahl gewesen, denn der Hersteller hat den Auslöser innerhalb weniger Wochen entfernt.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen mit einer Synology als zentralem Backup-Ziel ist dieser Vorgang lehrreicher als die eigentliche Meldung. Backup-Software verhält sich technisch zwangsläufig auffällig: Sie startet Prozesse aus der Ferne, arbeitet mit kodierten Kommandozeilen, legt temporäre Dateien an und öffnet rohe Netzwerkverbindungen. Endpoint-Schutz ist darauf trainiert, genau das zu bemerken. Dieser Konflikt ist strukturell und wird wiederkommen, mit anderen Produkten und anderen Signaturen.

Praktisch bedeutet das dreierlei. Erstens braucht jede Backup-Kette eine Überwachung, die auf ausbleibende Erfolgsmeldungen reagiert, nicht auf eingehende Fehlermeldungen. Zweitens gehört zu jeder Änderung an der Endpoint-Härtung ein Test der Sicherungsläufe, besonders auf Virtualisierungs-Wirten, wo ASR-Regeln legitime Verwaltungsmechanismen treffen können. Drittens ist der Restore-Test die einzige belastbare Kontrolle. Wer im August dieses Jahres wochenlang keine funktionierende Sicherung hatte, hat das nicht am Monitoring gesehen, sondern erst an einer nachträglichen Prüfung der Job-Historie.

Positiv anzumerken bleibt, dass beide Hersteller nachgebessert haben und der Vorgang öffentlich nachvollziehbar dokumentiert ist. Dass die Dokumentation von einem betroffenen Administrator kommt und nicht aus einer Release-Note, ist der schwächste Punkt dieser Geschichte.

Passende Anleitungen auf S-EDV

• Healthchecks auf der Synology für Backup-Monitoring zeigt, wie eine aktive Erfolgsmeldung pro Lauf eingerichtet wird und ein ausbleibendes Signal alarmiert, statt auf Fehlermeldungen zu warten.
• Restore-Test-Routine etablieren beschreibt, wie regelmäßige Wiederherstellungstests geplant und dokumentiert werden, um genau die Lücke zu schließen, die im geschilderten Fall wochenlang unbemerkt blieb.
• Checkmk auf der Synology für IT-Monitoring eignet sich, um Sicherungsläufe und Wirt-Systeme zentral zu überwachen und Ausfälle über mehrere Standorte hinweg sichtbar zu machen.

Quellen

• Borns IT- und Windows-Blog: Wie Synology Active Backup for Business nun Defender-Fehlalarme vermeidet (13.09.2026)
• Borns IT- und Windows-Blog: Microsoft Defender hält Synology-Backups für einen Trojaner (03.08.2026)
• Borns IT- und Windows-Blog: Nachtrag zum Defender-Fehlalarm, Rückmeldung von Synology und Microsoft (04.08.2026)
• Microsoft Learn: Referenz der Regeln zur Verringerung der Angriffsfläche
• Synology Archive: Paketversionen von Active Backup for Business