V: Wie Synology Active Backup for Business (ABB) nun Defender-Fehlalarme vermeidet

Noch ein Nachtrag zum Thema, dass der auf allen Windows-Systemen mitgelieferte Microsoft Defender Probleme mit Synology Active Backup for Business (ABB) machte und das Programm fälschlich in Quarantäne schickte. Synology hat einiges korrigiert, so dass der Microsoft Defender die Software nun in Ruhe sichern lässt.

Rückblick auf das Backup- und Defender-Problem

Es war schon ein fettes Problem, was Blog-Leser Stefan M. mir Anfang August 2026  berichtete. Der Leser hatte mich informiert, dass der von ihm auf Servern verwendete Microsoft Defender eine Verbindungsprüfung der Synology-Backup-Software (ABB) für einen Trojaner hält. Der Defender hat diese Software auf verschiedenen Servern des Lesers in Quarantäne geschoben. Dadurch laufen die Sicherungen nicht mehr durch.

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 eingestellt. Später hat mir der Blog-Leser noch die Rückmeldungen von Microsoft und Synology auf seine Supportanfragen zukommen lassen (siehe wie ich im Beitrag II: Nachtrag zum Defender-Fehlalarm: Rückmeldung von Synology und Microsoft).

Synology wollte prüfen, wie die Verbindungsprüfung in der Software so ausgeführt werden kann, dass dies die Erkennung einer Schadfunktion durch den Microsoft Defender nicht mehr triggert. Inzwischen ist ein entsprechender Fix bereitgestellt worden (siehe auch die Links am Artikelende).

Wie ABB jetzt sichert, und eine Härtungsfalle

Blog-Leser Stefan M. hatte mir bereits zum 24. August 2026 per Mail weitere Hinweise geschickt, die beschreiben, was Synology geändert hat, um den Defender-Fehlalarm zu vermeiden. Der Leser schrieb: "Zu Ihrer dreiteiligen Serie über den Defender-Fehlalarm bei Synology Active Backup for Business (ABB) habe ich eine Nachlese. Nach den Synology-Updates der letzten Wochen habe ich anhand der Defender-Protokolle von einem der betroffenen Hypervisoren nachgemessen, was der Hersteller tatsächlich geändert hat – und dabei einen Punkt gefunden, der für alle relevant ist, die ihre Hyper-V-Wirte härten." Die Information ist etwas liegen geblieben, wird nun aber nachgetragen.

Kritischer Aufruf wurde entfernt

Der Leser schrieb: "Synology hat genau einen Aufruf entfernt – den auffälligsten – und sonst nichts angefasst". Der Base64-verpackte Verbindungstest, den ich in Teil I der Artikelreihe beschrieben habe (roher Socket zur NAS auf Port 5510, Vergleich gegen ein Shared Secret), taucht laut Leser seit dem 11. August 2026 in keinem Protokoll mehr auf.

Der Leser hat dazu vier Defender-Diagnoseprotokolle über fünf Wochen ausgewertet: Bis zum 11. August 2026 lief dieser Test stündlich, danach über dreizehn Tage und dutzende Sicherungsläufe null Mal. Entfernt wurde er mit dem manuellen Support-Patch (aus dem Ticket des Lesers. Das reguläre ABB-Update auf Version 3.2.1-25059 vom 17. August  2026 ändert am Code nichts mehr, es zieht denselben Fix nur in die Allgemeinversion.

Was geblieben ist

Die drei, rein lokalen PowerShell-Sonden (Laufwerksbuchstaben ermitteln, Ausführbarkeit prüfen, Sperrdatei anlegen) in der Synology-Backup-Software laufen unverändert weiter, nach wie vor als Base64-kodierte Kommandozeile. Der Microsoft Defender bewertet diese Scripte bis heute als verdächtig (lowfi), blockiert sie aber nicht mehr. Seit dem 2. August 2026 gibt es laut Leser keinen einzigen Commando.A!ml-Fund mehr.

Bemerkenswert dabei, schrieb der Leser, dass die geräteweite Zulassung, die er damals gesetzt hatte, ist inzwischen von selbst wieder verschwunden (das erwähnte Stefan bereits in einem Nachtrag) – die Zulassung verfällt nach sieben Tagen). Es wird also nichts mehr durch die Zulassung verdeckt, und trotzdem bleibt es bezüglich Alarmierungen "still". "Das ist der sauberste denkbare Beleg dafür, dass Microsoft das Cloud-Modell zurückgedreht hat und nicht etwa meine Zulassung die Erkennung kaschiert." schreibt der Leser dazu

Wie ABB jetzt tatsächlich sichert

Um die verbleibende Lücke zu schließen, hat der Leser einen Prozess-Mitschnitt während eines echten VM-Backups gemacht. Das Bild ist eindeutig, schrieb der leser  – ABB arbeitet auf zwei Wegen:

• Die Steuerung (VMs auflisten, Snapshots verwalten, VHDs prüfen) läuft über WinRM, den PowerShell-Fernkanal: winrshost.exe startet cmd.exe, das wiederum powershell.exe mit kodierter Kommandozeile. Das sind die Aufrufe, die der Defender sieht.
• Die eigentliche Datenübertragung erledigt ein natives, von Synology signiertes Programm namens hyperv_helper.exe. Es verbindet sich selbst zur NAS auf Port 5510 – dorthin, wohin früher zusätzlich der PowerShell-Verbindungstest ging. Der war schlicht redundant, deshalb ließ er sich folgenlos streichen.
• Das Snapshot-Handling ist sauber gelöst, über die native Hyper-V-Schnittstelle für Reference Points (die Basis von Resilient Change Tracking, RCT, also der Änderungsverfolgung für inkrementelle Sicherungen). Kein grobes Herumfummeln an Checkpoints.

Und jetzt der Punkt, der für Leser wichtig sein dürfte. ABB startet die hyperv_helper.exe per WMI-Prozesserstellung – konkret über

Invoke-WmiMethod -Path win32_process -Name create

Das sei exakt das Muster, das eine gängige Angriffsflächenregel (Attack Surface Reduction, ASR – Microsofts Regelwerk zur Verringerung der Angriffsfläche) unterbindet:

• Englisch: Block process creations originating from PSExec and WMI commands
• Deutsch: Erstellung von Prozessen durch PSExec- und WMI-Befehle blockieren
• Regel-GUID: d1e49aac-8f56-4280-b9ba-993a6d77406c

Wer diese Regel auf „Blockieren" stellt, legt sein ABB-Hyper-V-Backup lahm – lautlos, schreibt der Blog-Leser. Denn ABB meldet dann nur, die VM lasse sich nicht sichern, ohne Hinweis auf die wahre Ursache.

Dieselbe Tücke wie beim ursprünglichen Fehlalarm: Die Fehlermeldung zeigt nicht dorthin, wo das Problem sitzt. Auf den Host-Betriebssystemen des Lesers steht die Regel bewusst nur im Audit-Modus (protokollieren, nicht blockieren). Genau deshalb läuft die Sicherung.

In seiner eigenen Defender-Härtungskonfiguration führt der Leser diese als Regel 16 und lässt sie aus genau diesem Grund im Audit-Modus. Es sei ine der wenigen ASR-Regeln, die man auf einem Virtualisierungs-Host nicht bedenkenlos scharf schalten kann. Prüfen lässt sich der eigene Stand mit einer Zeile:

Get-MpPreference | Select -ExpandProperty AttackSurfaceReductionRules_Ids

Steht dort die GUID oben mit Aktion „1" (Block), und läuft auf dem Host ABB für Hyper-V. Das Fazit der Nachlese des Lesers fällt unspektakulär aus: Synology hat den einen Aufruf entfernt, der für den Microsoft Defender am stärksten nach Schadsoftware aussah, und den Rest in Ruhe gelassen. Microsoft hat die Fehlerkennung zurückgenommen. Die eigentliche Backup-Mechanik war nie das Problem und ist unverändert. Damit sollte das Thema, dass der Defender die Synology-Backup-Lösung blockiert, vom Tisch sein.

Ähnliche Artikel:
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
IV: Microsoft Defender Zulassen-Entscheidung im Defender verfällt nach sieben Tagen
V: Wie Synology Active Backup for Business (ABB) nun Defender-Fehlalarme vermeidet
Ist das Defender Synology-Backup-False-Alarm-Problem gelöst?