II: Nachtrag zum Defender-Fehlalarm: Rückmeldung von Synology und Microsoft

Der Microsoft Defender hält Synology-Backups auf den Servern der Betroffenen für einen Trojaner und schiebt diese Software in Quarantäne, was einige Probleme bringt. Nun hat mir der Leser weitere Informationen in Form von Rückmeldungen von Synology und Microsoft zukommen lassen.

Rückblick auf das Microsoft Defender-Problem

Das Problem ist schnell beschrieben: Der Microsoft Defender hält oder hielt Synology-Backups auf verschiedenen Servern für einen Trojaner. Dadurch laufen die Sicherungen nicht mehr durch. Zum echten Problem für Administratoren wird das Ganze, weil die Defender-Option "Zulassen" für den in Quarantäne geschobenen Prozess die ganze Erkennungsregel abschaltet.

Detaillierte Analyse und Beschreibung in Teil 1

Das Problem, welches mir von Blog-Leser Stefan M. zugetragen wurde, hat einige weitere Administratoren betroffen. Ich hatte im Beitrag I: Microsoft Defender hält Synology-Backups für einen Trojaner (3.8.2026) die Details sowie die tiefere Analyse des Blog-Lesers bereits eingestellt.

Zwei Nachträge zur ersten Mail

Der Blog-Leser schrieb mir in einer Nachtrags-Mail: Aus dem Diagnosepaket eines betroffenen Servers lässt sich das Rollout-Fenster präzise datieren: Die Erkennungen laufen von 01.08.2026, 04:01:56 bis 02.08.2026, 05:00:50, 32 Ereignisse im Stundentakt, Signaturstand 1.455.482.0.

Und Active Backup for Business feuert nicht nur den Verbindungstest, sondern zusätzlich eine Ausführbarkeits-Sonde: Sie legt eine leere Datei:

%TEMP%\ActiveBackup-[zufall].ps1

an, führt sie aus und löscht sie sofort wieder. Blog-Leser Stefan M. meint dazu:

Inhaltlich nichts. Als Verhaltensmuster gelesen aber "Skript in TEMP schreiben, starten, Spuren beseitigen" – womit sich die Frage, warum eine ML-Heuristik anschlägt, weitgehend von selbst beantwortet.

Das Problem der fehlenden Alarmierung bei Problemen

Zum Schluss der Befund, der den Leser am meisten beschäftigt und den er für den eigentlich gefährlichen hält. Der Befund hat mit dem Defender gar nichts zu tun, sondern liegt im grundsätzlichen Konzept. Es geht um die Frage: "Bekommt der Administrator überhaupt mit, dass es Probleme bei der Sicherung gibt und kann er dies erkennen?".

Zum Hintergrund: Die Hypervisoren des Blog-Lesers sichern die virtuellen Maschinen zu Arbeitszeiten stündlich. Als die Sicherungen ausfielen, kam zwar eine Benachrichtigung: Allerdings nur für den ersten Fehlschlag. Danach gab es keine Benachrichtigungen mehr. Stunde um Stunde schlugen weitere Läufe fehl, die Benachrichtigung erfolgte nicht mehr.

Das klingt nach einer Kleinigkeit, ist aber das Gegenteil, argumentiert der Leser. Eine fehlgeschlagene Sicherung ist Alltag für die IT-Abteilungen: Es gibt Netzhänger, es treten Neustarts auf, es gibt ein Wartungsfenster und andere Ursachen, so dass eine Sicherung nicht ausgeführt werden kann.

Kein vernünftiger Administrator eskaliert deswegen, denn in einer Stunde läuft der nächste Versuch. Blog-Leser Stefan M. schrieb dazu: "Eine Meldung ist Rauschen. Drei Meldungen in Folge wären das Signal [das etwas schief läuft]. Genau dieses Signal kommt nicht."

Beim Leser blieb der Ausfall deshalb stundenlang unbemerkt – nicht weil die Alarmierung aus war, sondern weil der Administrator exakt die eine Nachricht bekam, die man, so Stefan M.,  gelernt hat als unauffällig einzuordnen. Und es gab keine der Art von Nachrichten, die dem widersprochen hätten. Das Perfide ist das Timing, argumentiert der Leser: "Ein vorübergehender Fehler erzeugt eine Meldung und 'löst sich auf'. Ein dauerhafter Fehler erzeugt ebenfalls eine Meldung – und dann Stille, ununterscheidbar von Erholung. Je ruhiger es wird, desto schlimmer steht es."

Die Benachrichtigungen sind auf allen betroffenen Geräten korrekt konfiguriert, Testmeldungen kommen an; ein Konfigurationsfehler ist es nicht. Synology hat laut Blog-Leser inzwischen zugesagt, dem Punkt als eigenständigem Problem nachzugehen.

Den Blog-Leser beschäftigt daran vor allem, dass diese Lücke bei jeder Ursache auftritt, die eine Agent-Verbindung hängen lässt. "Der Defender hat diese Lücke nicht gebaut, er hat sie nur sichtbar gemacht." schrieb mir der Leser.

Rückmeldungen von Microsoft und Synology

Blog-Leser Stefan M. hat sich zum 4. August 2026 dann per E-Mail mit dem Betreff "Nachtrag zum Defender-Fehlalarm: Synology räumt ein, Microsoft winkt ab – und der Kunde sitzt im Patt" zurückgemeldet. Dazu merkte er an, dass er sich deutlich schneller als erwartet zurückmelden können. Denn er hatte zum 3. August 2026 bereits zwei Antworten von Synology und eine von Microsoft bekommen hat.

Der ursprüngliche Tenor aus Teil 1 (Microsoft Defender hält Synology-Backups für einen Trojaner) mit dem Tenor "Virenscanner erkennt Backup falsch" hat sich laut Leser zum "Patt, in den der Kunde gerät" gemausert. In Teil 1 wurde ja gezeigt, dass der Microsoft Defender eine Kommandozeile von Synology Active Backup for Business als Trojan:Win32/Commando.A!ml erkennt und entfernt. Die Sicherungen über die Software bleiben stehen und der Administrator hat ein Problem.

Der  naheliegende Klick auf die Defender-Option Zulassen schaltet dabei die komplette Erkennungssignatur geräteweit ab. Und dies gilt unbefristet und für für Audits unsichtbar. Der Sachverhalt ist ausführlich im verlinkten Teil 1 analysiert und besprochen worden.

Runde eins: Der Synology-Support empfiehlt …

Blog-Leser Stefan M. hatte den in Teil 1 beschriebenen Fall bei Synology als Ticket eingereicht. Die erste Antwort des technischen Supports nannte zwei Schritte. Schritt 1 lautete wörtlich: "Klicken Sie auf Aktionen und wählen Sie Auf Gerät zulassen." Das wurde ausdrücklich als vorübergehende Maßnahme bezeichnet.

War natürlich ein "Schuss in den Ofen", der dem Leser nicht half. Denn er hatte ja vorher in der Analyse die Implikationen gesehen und ich habe diese in Teil 1 (Microsoft Defender hält Synology-Backups für einen Trojaner) ausführlich beschrieben.

Martin schrieb dazu: "Das ist, mit Verlaub, genau der Klick, dessen Nebenwirkung ich tags zuvor beschrieben hatte. Der Hersteller empfiehlt seinen Kunden also aktiv, auf ihren Hypervisoren eine Erkennungsregel gegen kodierte PowerShell mit Netzwerkverbindung abzuschalten – ausgerechnet auf den Maschinen, auf denen sämtliche virtuellen Server eines Unternehmens liegen."

Schritt 2 empfahl Ordner- und Prozessausschlüsse, unter anderem für hyperv_helper.exe. Blog-Leser Stefan M. hat habe daraufhin Einspruch gegen die Antwort bzw. Anweisung des Synology-Supports eingelegt: Denn Schritt 1 ist keine Ausnahme, sondern eine Abschaltung der Erkennung. Das Ereignis 5007 hält den Registry-Wert fest:

ThreatIDDefaultAction\2147840094 = 0x6

Und Schritt 2 kann gar nicht greifen, weil die Erkennung dateilos (file less) ist. Beim Ressourcentyp CmdLine:_… ist ja keine Datei beteiligt. Ein Prozessausschluss überspringt laut Microsofts eigener Dokumentation nur die Dateien, die ein Prozess öffnet – keine Kindprozesse und keine Kommandozeilen.

Runde zwei: Sauberes Einlenken des Synology-Supports

Der Leser hat dann auf seine Kritik eine zweite Antwort des Synology-Supports mit einer "sauberen" Lösung erhalten. Dazu schrieb er: "Die zweite Antwort hat mich positiv überrascht, deshalb zitiere ich sie etwas ausführlicher." Vom Synology-Support heißt es:

"Sie haben in beiden Punkten recht, und wir werden nicht versuchen, dies anders darzustellen. Diese Maßnahme muss dauerhaft in Kraft bleiben — und nicht nur als einmaliger ‚vorübergehender' Schritt —, da Active Backup for Business auch bei jeder zukünftigen Sicherung auf dieselbe PowerShell-basierte Kommunikation angewiesen ist. […] Sie haben auch recht, dass die Erkennung dateilos und Befehlszeilen-basiert ist. Aus diesem Grund greifen die Ordner-/Prozessausschlüsse in Schritt 2 nicht zuverlässig — Schritt 1 ist in der Praxis derzeit die einzige Möglichkeit, diesen Sicherungspfad funktionsfähig zu halten."

Dazu die Bestätigung, dass hyperv_helper.exe eine legitime Komponente ist, die PowerShell zur Kommunikation mit der NAS nutzt, und dass die Blockade selbst die Fehlerursache ist – nicht etwa eine unzulängliche Konfiguration. Synology sagte außerdem zu, den Fehlalarm als Hersteller an Microsoft zu melden und zu prüfen, ob der Verbindungstest anders implementiert werden muss. Beides allerdings ohne Zeitplan, bis wann das umgesetzt sein soll (was in der aktuellen Situation nachvollziehbar ist).

Blog-Leser Stefan M. merkt dazu an: "Das ist eine offene Antwort, wie man sie selten bekommt, und ich möchte das ausdrücklich anerkennen. Sie bedeutet allerdings auch: Der Hersteller räumt ein, dass seine einzige verfügbare Empfehlung darin besteht, dauerhaft eine Schutzfunktion abzuschalten."

Runde drei: Microsoft schließt den Kreis

Parallel hatte der Leser den Fehlalarm des Defender bei Microsoft eingereicht. Wie in Teil 1 erwähnt geht dies nur über die "Fileless-Route" mit dem Diagnosepaket MpSupportFiles.cab, da es ja keine Datei zum Hochladen gibt. Der Vorgang ist inzwischen abgeschlossen. Das Urteil des Analysten:

"The submitted files have been analyzed and confirmed to be benign and harmless. However, they contain patterns that match our detection logic and may trigger detection. […] If detection on these files is not desired, users are advised to carefully evaluate the use of exclusions."

Microsoft WDSI-Ergebnis (2026-08-04), zum Vergrößern klicken

Microsoft bestätigt also die Harmlosigkeit, schrieb der Leser, und teilt mit, dass man die Erkennung nicht ändert. Als Abhilfe wird auf Ausschlüsse verwiesen. Auf genau das Mittel, von dem Synology und der Leser inzwischen beide festgestellt haben, dass es bei dieser Erkennungsart nicht funktioniert.

Die Antwort der Microsoft-Analysten spricht durchgehend von „the submitted files" und verlinkt Anleitungen für Datei-Ausschlüsse. Der Leser vermutet, der dateilose Charakter der Meldung ist dort schlicht nicht angekommen. Böse Zungen täten sagen: "Wenn der kein Video eingereicht hat, verstehen die das bei Microsoft nicht", aber das wäre billige Polemik.

Damit herrscht ein Patt, Nutzer steht im Regen

Blog-Leser Stefan M. bringt das Dilemma für Administratoren bei dieser Konstellation auf den Punkt:

• Ausschlüsse von Ordnern oder Prozessen im Microsoft Defender greifen nicht.
• Die Zulassung der in Quarantäne geschobenen Anweisung ist keine Ausnahme, sondern eine unbefristete, unsichtbare Abschaltung einer generischen Signatur.
• Microsoft hält den Code für harmlos, lässt die Erkennung aber stehen.
• Synology kann das Problem derzeit im Agenten nicht umgehen und nennt keinen Termin, wann das behoben wird.

Damit herrscht ein Patt und der Administrator sitzt mitten drin. Blog-Leser Stefan M. schrieb dazu:

Wer in dieser Lage seine virtuellen Maschinen weiter gesichert haben will, hat genau eine Option – und die steht anschließend als Registry-Wert auf seinem Hypervisor, den kein Audit-Skript findet.

Der Leser hat sich für diesen Weg entschieden, weil ungesicherte Server das größere Risiko wären. Aber die Zulassung der Ausnahme ist in diesem Fall eine dokumentierte, befristete Abweichung mit Wiedervorlage, nicht ein stiller Dauerzustand. Das sei der Unterschied zwischen einer bekannten und einer unbekannten Ausnahme, und es ist auch schon der ganze Trost, merkt der Leser an.

An dieser Stelle mein Dank an den Leser für die ausführliche Analyse des Sachverhalts aus Teil I sowie die obigen Ergänzungen, die er mit der Leserschaft teilt.

Artikelreihe
I: Microsoft Defender hält Synology-Backups für einen Trojaner (3.8.2026)
II: Nachtrag zum Defender-Fehlalarm: Rückmeldung von Synology und Microsoft
III: Synology erklärt, warum die zweite Backup-Warnung nie kommt