![\"Bug\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2025\/10\/bug05.jpg\" "\\"Bug\\"")
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\u00e4lschlich in Quarant\u00e4ne schickte. Synology hat einiges korrigiert, so dass der Microsoft Defender die Software nun in Ruhe sichern l\u00e4sst.<\/p>\n
<\/p>\n
Es war schon ein fettes Problem, was
Blog-Leser Stefan M. mir Anfang August 2026\u00a0 berichtete. Der Leser hatte mich informiert, dass der von ihm auf Servern verwendete Microsoft Defender eine Verbindungspr\u00fcfung der Synology-Backup-Software (ABB) f\u00fcr einen Trojaner h\u00e4lt. Der Defender hat diese Software auf verschiedenen Servern des Lesers in Quarant\u00e4ne geschoben. Dadurch laufen die Sicherungen nicht mehr durch.<\/p>\n
Ich hatte im Beitrag\u00a0I:\u00a0Microsoft Defender h\u00e4lt Synology-Backups f\u00fcr einen Trojaner<\/a>\u00a0(3.8.2026)<\/em>\u00a0die Details sowie die tiefere Analyse des Blog-Lesers eingestellt. Sp\u00e4ter hat mir der Blog-Leser noch die R\u00fcckmeldungen von Microsoft und Synology auf seine Supportanfragen zukommen lassen (siehe wie ich im Beitrag\u00a0II:\u00a0Nachtrag zum Defender-Fehlalarm: R\u00fcckmeldung von Synology und<\/a><\/em>\u00a0Microsoft)<\/a>.<\/p>\n Synology wollte pr\u00fcfen, wie die Verbindungspr\u00fcfung in der Software so ausgef\u00fchrt 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).<\/p>\n Blog-Leser Stefan M. hatte mir bereits zum 24. August 2026 per Mail weitere Hinweise geschickt, die beschreiben, was Synology ge\u00e4ndert hat, um den Defender-Fehlalarm zu vermeiden. Der Leser schrieb: \"Zu Ihrer dreiteiligen Serie \u00fcber 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\u00e4chlich ge\u00e4ndert hat \u2013 und dabei einen Punkt gefunden, der f\u00fcr alle relevant ist, die ihre Hyper-V-Wirte h\u00e4rten.\" Die Information ist etwas liegen geblieben, wird nun aber nachgetragen.<\/p>\n Der Leser schrieb: \"Synology hat genau einen Aufruf entfernt \u2013 den auff\u00e4lligsten \u2013 und sonst nichts angefasst\".\u00a0Der Base64-verpackte Verbindungstest, den ich in Teil I<\/a> 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.<\/p>\n Der Leser hat dazu vier Defender-Diagnoseprotokolle \u00fcber f\u00fcnf Wochen ausgewertet: Bis zum 11. August 2026 lief dieser Test st\u00fcndlich, danach \u00fcber dreizehn Tage und dutzende Sicherungsl\u00e4ufe null Mal. Entfernt wurde er mit dem manuellen Support-Patch (aus dem Ticket des Lesers. Das regul\u00e4re ABB-Update auf Version 3.2.1-25059 vom 17. August\u00a0 2026 \u00e4ndert am Code nichts mehr, es zieht denselben Fix nur in die Allgemeinversion.<\/p>\n Die drei, rein lokalen PowerShell-Sonden (Laufwerksbuchstaben ermitteln, Ausf\u00fchrbarkeit pr\u00fcfen, Sperrdatei anlegen) in der Synology-Backup-Software laufen unver\u00e4ndert weiter, nach wie vor als Base64-kodierte Kommandozeile. Der Microsoft Defender bewertet diese Scripte bis heute als verd\u00e4chtig (lowfi), blockiert sie aber nicht mehr. Seit dem 2. August 2026 gibt es laut Leser keinen einzigen Commando.A!ml<\/em>-Fund mehr.<\/p>\n Bemerkenswert dabei, schrieb der Leser, dass die ger\u00e4teweite Zulassung, die er damals gesetzt hatte, ist inzwischen von selbst wieder verschwunden (das erw\u00e4hnte Stefan bereits in einem Nachtrag<\/a>) \u2013 die Zulassung verf\u00e4llt nach sieben Tagen). Es wird also nichts mehr durch die Zulassung verdeckt, und trotzdem bleibt es bez\u00fcglich Alarmierungen \"still\". \"Das ist der sauberste denkbare Beleg daf\u00fcr, dass Microsoft das Cloud-Modell zur\u00fcckgedreht hat und nicht etwa meine Zulassung die Erkennung kaschiert.\" schreibt der Leser dazu<\/p>\n Um die verbleibende L\u00fccke zu schlie\u00dfen, hat der Leser einen Prozess-Mitschnitt w\u00e4hrend eines echten VM-Backups gemacht. Das Bild ist eindeutig, schrieb der leser\u00a0 \u2013 ABB arbeitet auf zwei Wegen:<\/p>\n Und jetzt der Punkt, der f\u00fcr Leser wichtig sein d\u00fcrfte. ABB startet die hyperv_helper.exe<\/em> per WMI-Prozesserstellung \u2013 konkret \u00fcber<\/p>\n Das sei exakt das Muster, das eine g\u00e4ngige Angriffsfl\u00e4chenregel (Attack Surface Reduction, ASR \u2013 Microsofts Regelwerk zur Verringerung der Angriffsfl\u00e4che) unterbindet:<\/p>\n Wer diese Regel auf \u201eBlockieren\" stellt, legt sein ABB-Hyper-V-Backup lahm \u2013 lautlos, schreibt der Blog-Leser. Denn ABB meldet dann nur, die VM lasse sich nicht sichern, ohne Hinweis auf die wahre Ursache.<\/p>\n Dieselbe T\u00fccke wie beim urspr\u00fcnglichen 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\u00e4uft die Sicherung.<\/p>\n In seiner eigenen Defender-H\u00e4rtungskonfiguration f\u00fchrt der Leser diese als Regel 16 und l\u00e4sst 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.\u00a0Pr\u00fcfen l\u00e4sst sich der eigene Stand mit einer Zeile:<\/p>\n Steht dort die GUID oben mit Aktion \u201e1\" (Block), und l\u00e4uft auf dem Host ABB f\u00fcr Hyper-V.\u00a0Das Fazit der Nachlese des Lesers f\u00e4llt unspektakul\u00e4r aus: Synology hat den einen Aufruf entfernt, der f\u00fcr den Microsoft Defender am st\u00e4rksten nach Schadsoftware aussah, und den Rest in Ruhe gelassen. Microsoft hat die Fehlerkennung zur\u00fcckgenommen. Die eigentliche Backup-Mechanik war nie das Problem und ist unver\u00e4ndert. Damit sollte das Thema, dass der Defender die Synology-Backup-L\u00f6sung blockiert, vom Tisch sein.<\/p>\n \u00c4hnliche Artikel:<\/strong> 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\u00e4lschlich in Quarant\u00e4ne schickte. Synology hat einiges korrigiert, so dass der Microsoft Defender die Software … Weiterlesen Wie ABB jetzt sichert, und eine H\u00e4rtungsfalle<\/h2>\n
Kritischer Aufruf wurde entfernt<\/h3>\n
Was geblieben ist<\/h3>\n
Wie ABB jetzt tats\u00e4chlich sichert<\/h2>\n
\n
Invoke-WmiMethod -Path win32_process -Name create<\/pre>\n
\n
Get-MpPreference | Select -ExpandProperty AttackSurfaceReductionRules_Ids<\/pre>\n
\nI:\u00a0Microsoft Defender h\u00e4lt Synology-Backups f\u00fcr einen Trojaner<\/a>\u00a0(3.8.2026)
\nII:\u00a0Nachtrag zum Defender-Fehlalarm: R\u00fcckmeldung von Synology und Microsoft<\/a>
\nIII:\u00a0Synology erkl\u00e4rt, warum die zweite Backup-Warnung nie kommt<\/a>
\nIV:\u00a0Microsoft Defender Zulassen-Entscheidung im Defender verf\u00e4llt nach sieben Tagen<\/a>
\nV: Wie Synology Active Backup for Business (ABB) nun Defender-Fehlalarme vermeidet<\/a>
\nIst das Defender Synology-Backup-False-Alarm-Problem gel\u00f6st?<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"