Defender blockiert EulandaXtools
Zuletzt geändert: 07.05.2026 05:51

AE-X-13 Defender blockiert EulandaXtools #

EN16931 – ZUGFeRD – XRechnung – PEPPOL – EULANDA® Warenwirtschaft

Microsoft Defender hat seit Anfang Mai 2026 begonnen, das PowerShell-Modul EulandaXtools in bestimmten Versionen als schädlich einzustufen und beim Laden zu blockieren. Da Xfacture intern auf EulandaXtools aufsetzt, kann auch Xfacture dadurch nicht mehr starten.

Hintergrund zur Vertrauensstufe: Das Modul ist mit einem EV-Zertifikat (Extended Validation) der EULANDA Software GmbH signiert – der höchsten verfügbaren Sicherheitsstufe für Code-Signaturen, da die privaten Schlüssel auf einer eigenen Hardware verwaltet werden. Trotz dieser Signatur greift der Schutzmechanismus von Defender (AMSI), weil dieser den Skript-Inhalt unabhängig von der Signatur prüft. Wir haben Microsoft am 06.05.2026 offiziell über das Defender-Portal informiert. Wann und in welcher Form Microsoft eine Korrektur am Erkennungsmodell vornimmt, ist derzeit nicht abschätzbar.

Bin ich betroffen? #

Sie sind betroffen, wenn beim Start von EULANDA® oder beim Aufruf einer Anwendung, die EulandaXtools verwendet (z. B. Xfacture), eine der folgenden Situationen eintritt:

  • Eine Fehlermeldung erscheint, die mit folgendem Text beginnt:

    In C:\Users\<Benutzer>\Documents\WindowsPowerShell\Modules\EulandaXtools\<Version>\EulandaXtools.psm1:1 Zeichen:1
+ # ---------------------------------------------------------------------
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Das Skript enthält schädliche Daten und wurde von Ihrer Antivirensoftware blockiert.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : ScriptContainedMaliciousContent

import-module : Das im Modulmanifest
"C:\Users\<Benutzer>\Documents\WindowsPowerShell\Modules\EulandaXtools\<Version>\EulandaXtools.psd1" im Feld
"ModuleToProcess/RootModule" aufgeführte zu verarbeitende Modul "EulandaXtools.psm1" wurde nicht verarbeitet, ...

  • Die Anwendung startet scheinbar ohne Meldung, beendet sich aber sofort wieder (typisch bei Headless-Aufrufen, etwa aus Scheduled Tasks oder dem EULANDA®-Server-Modul).

  • Im Defender-Schutzverlauf erscheint ein Eintrag mit der Bezeichnung Trojan:HTML/FakeLogin.AL!atmn (ThreatID 2147968467) auf einer EulandaXtools-Datei.

Was kann ich tun? #

Es gibt zwei Wege. Bevorzugt ist immer das Update auf die korrigierte Version.

Option 1: Update auf EulandaXtools 1.0.72 oder neuer (empfohlen) #

Mit Release 1.0.72 haben wir die Auslöser des Defender-Treffers im Modul selbst beseitigt. Eine Defender-Ausnahme ist dann nicht mehr nötig.

  • Aktualisieren Sie das Xfacture-Plugin nach der Anleitung in AE-X-09. Dabei wird automatisch die zum Plugin passende EulandaXtools-Version mitinstalliert.

  • Prüfen Sie nach der Installation in einer normalen PowerShell, dass das Modul wieder geladen werden kann:

    Import-Module EulandaXtools
Get-Module EulandaXtools | Select-Object Name, Version
Ob 1.0.72 mit Ihrer eingesetzten Anwendung vollständig kompatibel ist, hängt vom konkreten Anwendungsfall ab und sollte einzeln geprüft werden. Garantiert kompatibel ist 1.0.72 mit der neuen EULANDA® 2026.5.113.x in Verbindung mit der Vorabversion von Xfacture.

Option 2: Defender-Ausnahme setzen (Workaround) #

Wenn ein Update kurzfristig nicht möglich ist, kann der Modulordner oder der PowerShell-Prozess von der Defender-Prüfung ausgenommen werden. Beide Befehle erfordern eine PowerShell mit Administrationsrechten.

A) Modulordner ausnehmen (zu bevorzugen, da am engsten gefasst):

# Admin-PowerShell:
$modulRoot = "$env:USERPROFILE\Documents\WindowsPowerShell\Modules\EulandaXtools"
Add-MpPreference -ExclusionPath $modulRoot
(Get-MpPreference).ExclusionPath   # Kontrolle
In manchen Konstellationen prüft der Defender Skript-Inhalte über die AMSI-Schnittstelle zusätzlich zur Datei-Prüfung. In diesen Fällen reicht eine reine Pfad-Ausnahme nicht aus, und Sie müssen Option B wählen.

B) PowerShell-Prozess ausnehmen (wirkt zuverlässig, aber breiter):

# Admin-PowerShell:
Add-MpPreference -ExclusionProcess "powershell.exe"
Add-MpPreference -ExclusionProcess "pwsh.exe"   # PowerShell 7

Eine Prozess-Ausnahme für powershell.exe ist sicherheitstechnisch bedenklich, weil damit jedes PowerShell-Skript auf diesem Rechner von der Defender-Prüfung ausgenommen wird – nicht nur EulandaXtools. Setzen Sie diese Variante nur ein, wenn Option 1 (Update) und die Pfad-Ausnahme aus Option A nicht in Frage kommen, und entfernen Sie die Ausnahme wieder, sobald 1.0.72 oder neuer installiert ist:

Remove-MpPreference -ExclusionProcess "powershell.exe"
Remove-MpPreference -ExclusionProcess "pwsh.exe"

Warum greift der Defender hier? #

Wir sind dem Verhalten nachgegangen und konnten zwei Bereiche eingrenzen, die das Erkennungsmodell des Defender bei EulandaXtools sensibilisiert haben:

  1. Eingebettete Kryptographie-Funktionen. Diese werden ausschließlich zum Entschlüsseln eigener, signierter EULANDA®-Objekte benutzt – sie sind aber nur in wenigen Anwendungen tatsächlich erforderlich.
  2. Eingebetteter Mini-Webserver mit integrierten Ressourcen. Der bisherige Webserver hatte JavaScript, Icons, HTML-Templates und CSS direkt als Zeichenketten innerhalb des Skripts eingebettet. Das Maschinenlern-Modell des Defender hat dieses Muster aus großen, eingebetteten HTML-Blöcken fälschlich als Phishing-Seiten-ähnlich klassifiziert.

Was wurde in 1.0.72 geändert? #

  • Die Kryptographie-Funktionen sind in ein eigenes, separates Modul ausgelagert. Anwendungen, die sie nicht benötigen, laden sie auch nicht mehr mit.
  • Der Mini-Webserver wurde so umgebaut, dass er seine Ressourcen von der Festplatte lädt, statt sie als Text in das Skript einzubetten. Defender prüft Datendateien dieser Art nicht mit AMSI.

Diese beiden Änderungen genügten in unseren Tests, um den Defender-Block vollständig aufzulösen. Der dazugehörige interne Vorgang ist im EulandaXtools-Repository als geschlossenes Issue dokumentiert.

Eine Code-Signatur – auch ein EV-Zertifikat – schützt nicht vor AMSI-Treffern. AMSI prüft den Skript-Inhalt zur Laufzeit unabhängig von der Signatur. Die PowerShell-Execution-Policy prüft die Signatur, AMSI nicht. Das ist ein wichtiger Unterschied, der in der Praxis oft übersehen wird.