![\"Bug\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2025\/10\/bug05.jpg\" "\\"Bug\\"")
Ich stelle mal eine Beobachtung eines Blog-Lesers hier ein, die mich heute erreicht hat. Der Microsoft Defender h\u00e4lt Synology-Backups auf den Server des Betroffenen f\u00fcr einen Trojaner. Dadurch laufen die Sicherungen nicht mehr durch. Diesen Prozess \"Zulassen\" schaltet die ganze Erkennungsregel ab, schrieb mir der Leser. Und noch krasser ist die Analyse des Lesers, was den Microsoft Defender reagieren l\u00e4sst<\/p>\n
<\/p>\n
Blog-Leser Stefan M. hat mich am heutigen 3. August 2026 per E-Mail unter dem Betreff \"Defender h\u00e4lt Synology-Backups f\u00fcr einen Trojaner \u2013 und \u201eZulassen\" schaltet die ganze Erkennungsregel ab\" kontaktiert (danke daf\u00fcr). Der Leser setzt den Microsoft Defender auf seinen Windows Servern ein und verwendet Synology-Backups zur Sicherung.<\/p>\n
Stefan schrieb mir, dass\u00a0der Microsoft Defender auf seinen Servern zuverl\u00e4ssig verhindert hat, dass die Sicherungen durchlaufen. Nicht wegen eines Fehlers im Backup, sondern der Defender das Synology-Sicherungsprogramm f\u00fcr einen Trojaner gehalten und entfernt. Seitdem sind die virtuellen Maschinen des Lesers vor allem eines: ungesichert.<\/p>\n
Betroffen ist Synology Active Backup for Business (ABB). Zur ersten Einordnung beschrieb mir der Leser folgendes Fehlerbild:<\/p>\n
Lokale Konfiguration, eine bestimmte Server-Version, ein bestimmter ABB-Stand und Zufall scheiden damit laut Leser aus. \"Es lag ausnahmsweise nicht an mir \u2013 in unserem Beruf ein so seltener Moment, dass ich ihn hiermit aktenkundig mache\", merkte der Leser in seiner Mai an.<\/p>\n
Stefan schrieb mir, dass der Defender einen Fund: \"Trojan:Win32\/Commando.A!ml\" erkannt haben will. Der Schweregrad ist \"Schwerwiegend\", der Status \"Entfernt\". Sprich: Das Synology-Backup-Programm wurde in Quarant\u00e4ne geschoben.<\/p>\n
Dazu die Einsch\u00e4tzung des Defenders, die der Leser w\u00f6rtlich \u00fcbermittelt hat, weil sie im sp\u00e4teren Kontext noch komisch wird:<\/p>\n \"Dieses Programm ist gef\u00e4hrlich. Es f\u00fchrt Befehle eines Angreifers aus.\"<\/p><\/blockquote>\n Als betroffenes Element nennt der Schutzverlauf eine Kommandozeile, keine Datei sondern diesen Befehl:<\/p>\n Auf einem der betroffenen Server liefen laut Leser so binnen zwei Tagen 15 Meldungen in das Protokoll, und das im Stundentakt. Denn der Verbindungstest l\u00e4uft als geplante Aufgabe. Der \"Angreifer\", den er Defender erkannt haben will, sei vor allem eines: p\u00fcnktlich, schrieb der Leser.<\/p>\n Der Blog-Leser hat dann eine Analyse gestartet und schrieb: \"Der wirklich interessante Teil kommt allerdings erst, wenn man den Fehlalarm auf dem naheliegenden Weg abstellt\".<\/p>\n Der Leser hat den vom Defender gemeldeten Base64-Block genauer angeschaut und schrieb: \"Dekodiert man den Base64-Block (UTF-16LE), entpuppt sich der Angriff als Verbindungstest\":<\/p>\n Der innere Base64-String ergibt 29 Byte, die im Klartext { action: \"test_connection\" } bedeuten. Das ist der komplette Schadcode:<\/p>\n Kein Nachladen von Code, kein Invoke-Expression, keine Persistenz, keine Datei- oder Registry-Zugriffe, schrieb der Leser. Ziel sei eine private Adresse im selben Netz (\"der Angreifer sitzt also im Serverschrank nebenan\" unkte der Leser in seiner Mail).<\/p>\n Und dann ist da noch diese Zeile in der Analyse aufgefallen, wo es dann arg kryptisch wird:<\/p>\n Denn \"raise\" ist eine Anweisung in Python. In der PowerShell-Syntax gibt es das nicht, dort hei\u00dft es \"throw\". Die PowerShell sucht also gewissenhaft nach einem Befehl namens \"raise\", findet keinen und wirft eine CommandNotFoundException.<\/em> Die landet im umgebenden Catch und liefert am Ende {\"Connected\": false}. Der Fehlerpfad tut damit exakt das Richtige \u2013 allerdings nicht, weil dort ein Fehler geworfen wird, sondern weil die Zeile schlicht kaputt ist.<\/p>\n Damit kommt der Leser zur\u00fcck zum Defender und seiner Einsch\u00e4tzung, dieses Programm f\u00fchre Befehle eines Angreifers aus. \"Ein Angreifer, der seinen R\u00fcckkanal in der falschen Programmiersprache abbricht, w\u00e4re mir neu. F\u00fcr maschinell erzeugten Hersteller-Klebe-Code ist es dagegen ein vertrauter Anblick.\"<\/p>\n Der Leser schrieb dann in seiner Analyse: \"Derselbe Erkennungsname \u2013 intern ThreatID 2147840094 \u2013 hat auf meiner Arbeitsstation bereits am 27.07.2026 zugeschlagen, gegen ein v\u00f6llig unbeteiligtes, selbst geschriebenes PowerShell-Skript. Anderer Rechner, anderer Code, kein Synology in Sichtweite. Gemeinsam war beiden F\u00e4llen nur der Parameter -EncodedCommand\". Auf einem betroffenen Server l\u00f6sten laut Leser sogar drei verschiedene Programme dieselbe Signatur aus: cmd.exe, powershell.exe<\/em> und pwsh.exe<\/em>.<\/p>\n Die Signatur erkennt also kein Programm, sondern ein Verhaltensmuster: kodierter Befehl, Netzwerkverbindung, Base64-Nutzlast. Synology f\u00e4llt laut Analyse des Lesers nur deshalb so auf, weil dort ein produktiver Backup-Dienst daran h\u00e4ngt.<\/p>\n Vergleichbare Fehlalarme sind derzeit auch bei anderen Werkzeugen dokumentiert, die ihre PowerShell-Aufrufe maschinell zusammenbauen, etwa in den Issues 15423 und 26218 des OpenAI-Codex-Projekts.<\/p>\n Nach der f\u00fcnfzehnten Meldung in den logs hat der Nutzer das getan, was Administratoren um diese Uhrzeit tun: Er hat im Schutzverlauf des Microsoft Defender auf \"Zulassen\" geklickt. Die Meldungen h\u00f6rten auf, der Administrator war im ersten Augenblick zufrieden.<\/p>\n Der Fehler war dann, mal nachzusehen, was dieser Klick eigentlich bewirkt.\u00a0Das Ergebnis hat den Leser dann deutlich mehr beunruhigt als der Fehlalarm. Der Klickt auf \"Zulassen\" bewirkt, dass der Defender einen einzigen Registry-Wert schreibt. DasEreignis 5007 h\u00e4lt ihn fest:<\/p>\n Der Wert 2147840094 ist die Signaturnummer, 0x6 bedeutet Allow.<\/em> Nicht der Pfad des Werkzeugs, nicht sein Hash, nicht die Kommandozeile, sondern die Erkennungsregel selbst <\/em>wird stummgeschaltet. Ger\u00e4teweit, f\u00fcr jedes Programm, das dieses Muster k\u00fcnftig zeigt. Der Leser merkt dazu an, dass man nicht \"mein Skript\" erlaubt, sondern der Nutzer erlaubt \"kodierte PowerShell mit Netzwerkverbindung\". Das !ml<\/em> im Namen steht f\u00fcr Machine Learning gibt der Leser an. Solche Signaturen seien absichtlich gro\u00dfz\u00fcgig gefasst, merkt Stefan an. Beim Zulassen sei diese Gro\u00dfz\u00fcgigkeit dann leider inbegriffen.<\/p>\n Aus Sicht des Blog-Lesers machen drei Eigenschaften diesen gesamten Ansatz \u00e4u\u00dferst heikel. Er beschrieb diese folgenderma\u00dfen:<\/p>\n Die Oberfl\u00e4che des Microsoft Defender beg\u00fcnstigt den Denkfehler nach Kr\u00e4ften, merkt der Leser an. Denn der Defender-Dialog zeigt eine konkrete Kommandozeile mit einem konkreten Zeitstempel. Der Administrator entscheidet also gef\u00fchlt \u00fcber einen Einzelfall. Und die Schaltfl\u00e4che hei\u00dft \"Zulassen\", nicht \"Diese Erkennungsregel dauerhaft abschalten\" \u2013 was insofern bedauerlich ist, als Letzteres die zutreffendere Beschriftung w\u00e4re.<\/p>\n \"Damit ABB wieder sichert, braucht es zwei Schritte, und der zweite wird gern \u00fcbersehen\", teilte mir der Leser mit: Erstens gilt es, den Fund zu entsch\u00e4rfen. Und zweitens muss man auf dem Windows-Host den Dienst \"Synology Active Backup for Business Service\" <\/em>neu starten.<\/p>\n Ohne den zweiten Schritt passiert n\u00e4mlich gar nichts. Der Dienst hat den abgeschossenen Verbindungstest als \"NAS nicht erreichbar\" verbucht und beharrt darauf. Skalieren l\u00e4sst sich das schlecht, beides muss lokal am jeweiligen Host erledigt werden \u2013 bei mehreren Kundenumgebungen ist das ein Vormittag, merkt der Leser an.<\/p>\n Stefan erg\u00e4nzte in seiner Mail: \"F\u00fcr den ersten Schritt halte ich inzwischen einen engen Pfad- oder Prozess-Ausschluss f\u00fcr den besseren Weg als die Signatur-Zulassung. Er bleibt sichtbar und beim n\u00e4chsten Audit auffindbar. Sauberer w\u00e4re allerdings, wenn Synology den Verbindungstest nicht als Base64-verpackte Kommandozeile abfeuern w\u00fcrde. Ein Skript als signierte Datei auf der Platte l\u00f6st die Signatur gar nicht erst aus \u2013 und sieht nebenbei auch weniger nach L\u00f6segeldforderung aus.\"<\/p>\n Melden l\u00e4sst sich der Fehlalarm laut Leser \u00fcbrigens nur umst\u00e4ndlich: Es gibt keine Datei zum Einreichen bei Microsoft. Und eine Datei mit exakt dieser oben aufgef\u00fchrten bzw. bem\u00e4ngelten Kommandozeile wird bei einem Suchlauf nicht beanstandet. Der Leser hat dies ausprobiert.<\/p>\n Microsoft sieht f\u00fcr solche F\u00e4lle die Route \"Submit a fileless detection for analysis\" mit dem Diagnosepaket MpSupportFiles.cab<\/em> vor, schrieb Stefan. Dokumentiert ist das durchaus, allerdings an einer Stelle, die man ebenfalls nur findet, wenn man schon wei\u00df, dass es sie gibt. Der Leser vermutet, dass die meisten Betroffenen den Fund wegklicken und ihn nie an Microsoft melden.<\/p>\n Der Blog-Leser hat mir das dekodierte Skript als Textdatei samt Analyse der Nutzlast zukommen lassen. Hier der betreffende Quellcode des Scripts:<\/p>\n Es handelt sich um Kundenumgebungen, deshalb sind NAS-Adresse und Shared Secret in obigem Code ersetzt. Alles \u00dcbrige ist im Original. Danke an den Leser – und die Frage an Mitleser: Noch jemand davon betroffen?<\/p>\n","protected":false},"excerpt":{"rendered":" Ich stelle mal eine Beobachtung eines Blog-Lesers hier ein, die mich heute erreicht hat. Der Microsoft Defender h\u00e4lt Synology-Backups auf den Server des Betroffenen f\u00fcr einen Trojaner. Dadurch laufen die Sicherungen nicht mehr durch. Diesen Prozess \"Zulassen\" schaltet die ganze … Weiterlesen ![\"Defender](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2026\/08\/Defender-Schutzverlauf-1024x466.jpg\")
<\/a>
\nMeldung des Defender, zum Vergr\u00f6\u00dfern klicken<\/a><\/p>\nC:\\Windows\\System32\\cmd.exe \/C powershell -encodedcommand <langer Base64-Block><\/pre>\n
Analyse: Was der \"Angreifer\" tats\u00e4chlich tut<\/h2>\n
Ein Verbindungstest als Ursache<\/h3>\n
$ip = '<NAS-IP>'\r\n$port = 5510\r\n$secret = '<Token>'\r\n$b64 = \"QhAABmFjdGlvbhAAD3Rlc3RfY29ubmVjdGlvbkA=\"\r\n$data = [System.Convert]::FromBase64String($b64)\r\n$client = New-Object System.Net.Sockets.TcpClient\r\n$client.Connect($ip, $port)\r\n$stream = $client.GetStream()\r\n$stream.Write($data, 0, $data.Length)\r\n...\r\nif ([System.Text.Encoding]::ASCII.GetString($response) -eq $secret) {\r\n@{Connected = $true}\r\n}<\/pre>\n\n
raise \"fail\"<\/pre>\n
Es geht vermutlich gar nicht um Synology<\/h3>\n
Und jetzt der eigentliche Punkt: Zulassen f\u00fchrt ins Desaster<\/h3>\n
HKLM\\SOFTWARE\\Microsoft\\Windows Defender\\Threats\\ThreatIDDefaultAction\\2147840094 = 0x6<\/pre>\n
\n
Was funktioniert<\/h2>\n
Kaum m\u00f6glich, das Problem zu melden<\/h3>\n
Noch einige Informationen<\/h3>\n
# ============================================================================\r\n# Synology Active Backup for Business - interner Verbindungstest\r\n# Dekodierter Klartext des von Windows Defender als\r\n#\r\n# Trojan:Win32\/Commando.A!ml\r\n#\r\n# gemeldeten Befehls. Fund vom 02.08.2026, 07:20 Uhr, auf einem\r\n# Windows-Server mit Hyper-V. Defender im Auslieferungszustand\r\n# (keine Haertung, keine erhoehte Cloud-Blockstufe).\r\n#\r\n# Original-Aufruf laut Defender-Schutzverlauf:\r\n# C:\\Windows\\System32\\cmd.exe \/C powershell -encodedcommand \r\n#\r\n# Dekodiert mit: base64 -d | iconv -f UTF-16LE\r\n# Der Code wurde zur Analyse NICHT ausgefuehrt, nur dekodiert.\r\n#\r\n# ANONYMISIERT: Es handelt sich um eine Kundenumgebung. Die NAS-Adresse\r\n# und das Shared Secret wurden durch bzw. ersetzt.\r\n# Alles Uebrige ist unveraendert.\r\n# ============================================================================\r\n\r\n$ErrorActionPreference = \"Stop\"\r\nTry {\r\n$(try{\r\n$ip = ''\r\n$port = 5510\r\n$secret = ''\r\n$b64 = \"QhAABmFjdGlvbhAAD3Rlc3RfY29ubmVjdGlvbkA=\"\r\n$data = [System.Convert]::FromBase64String($b64)\r\n$client = New-Object System.Net.Sockets.TcpClient\r\n$client.ReceiveTimeout = 30000\r\n$client.Connect($ip, $port)\r\nif (-not $client.Connected) {\r\nraise \"fail\"\r\n}\r\n$stream = $client.GetStream()\r\n$stream.Write($data, 0, $data.Length)\r\n$buffer = New-Object byte[] 128\r\n$bytesRead = $stream.Read($buffer, 0, $buffer.Length)\r\n$response = $buffer[0..($bytesRead-1)]\r\nif ([System.Text.Encoding]::ASCII.GetString($response) -eq $secret) {\r\n@{Connected = $true}\r\n} else {\r\nraise \"fail\"\r\n}\r\n} Catch {\r\n@{Connected = $false}\r\n})| ConvertTo-Json -Depth 10\r\n} Catch {\r\n$host.ui.WriteErrorLine(($_ | Select CategoryInfo,FullyQualifiedErrorId,@{N=\"Exception\";E={,@($_.Exception | Select Message)}} |ConvertTo-Json))\r\nexit 1\r\n}\r\n\r\n# ============================================================================\r\n# ANALYSE\r\n# ============================================================================\r\n#\r\n# 1) DER INNERE BASE64-PAYLOAD\r\n#\r\n# QhAABmFjdGlvbhAAD3Rlc3RfY29ubmVjdGlvbkA=\r\n#\r\n# HEX : 42 10 00 06 61 63 74 69 6f 6e 10 00 0f 74 65 73 74 5f 63 6f 6e\r\n# 6e 65 63 74 69 6f 6e 40\r\n# ASCII: B...action...test_connection@\r\n# Laenge: 29 Byte\r\n#\r\n# Struktur (schlichtes TLV-Format, Type-Length-Value):\r\n# 0x42 'B' = Start-Marker\r\n# 0x10 0x0006 = Typ String, Laenge 6 -> \"action\"\r\n# 0x10 0x000F = Typ String, Laenge 15 -> \"test_connection\"\r\n# 0x40 '@' = End-Marker\r\n#\r\n# Im Klartext also: { action: \"test_connection\" }\r\n#\r\n#\r\n# 2) WAS DAS SKRIPT TUT\r\n#\r\n# - baut eine TCP-Verbindung zur NAS auf Port 5510 auf\r\n# (Kommunikationsport zwischen ABB-Agent und ABB-Server)\r\n# - sendet die 29 Byte oben\r\n# - vergleicht die Antwort mit einem Shared Secret\r\n# - gibt {\"Connected\": true} bzw. false als JSON zurueck\r\n#\r\n# NICHT enthalten: Nachladen von Code, Invoke-Expression, Persistenz,\r\n# Datei- oder Registry-Zugriffe, Verschluesselung, Exfiltration.\r\n# Ziel ist eine private RFC1918-Adresse im selben LAN.\r\n#\r\n#\r\n# 3) WARUM DER DEFENDER TROTZDEM ANSCHLAEGT\r\n#\r\n# Vier Merkmale eines C2-Beacons treffen zusammen:\r\n# a) cmd.exe \/C powershell -encodedcommand (Base64-verschleierter Befehl)\r\n# b) roher Socket ueber System.Net.Sockets.TcpClient statt HTTP\r\n# c) fest hinterlegtes Shared Secret zur Pruefung der Antwort\r\n# d) weiterer Base64-Blob, zur Laufzeit dekodiert und verschickt\r\n#\r\n# Das Suffix !ml kennzeichnet einen Machine-Learning-Treffer,\r\n# keinen Signaturtreffer.\r\n#\r\n#\r\n# 4) NEBENBEFUND\r\n#\r\n# 'raise \"fail\"' ist kein gueltiges PowerShell, sondern Python-Syntax.\r\n# In PowerShell laeuft es ins Leere und wird vom umgebenden Catch\r\n# eingefangen - der Fehlerpfad funktioniert eher zufaellig.\r\n# Deutet auf maschinell erzeugten Klebe-Code hin.\r\n#\r\n#\r\n# 5) LOESUNG\r\n#\r\n# a) Defender -> Schutzverlauf -> Fund aufklappen -> \"Zulassen\"\r\n# b) Auf dem Windows-Host den Dienst neu starten:\r\n# Restart-Service \"Synology Active Backup for Business Service\"\r\n#\r\n# Ohne Schritt b) bleibt es beim fehlgeschlagenen Backup: Der Dienst hat\r\n# den abgeschossenen Verbindungstest als \"NAS nicht erreichbar\" verbucht\r\n# und verharrt in diesem Zustand.\r\n# ============================================================================<\/pre>\n