Der Schutz muss vor dem normalen Virenscanner beginnen

Ein Domain Controller startet nach einem Wartungsfenster, der EDR-Agent meldet sich wieder und die Dienste laufen. Das belegt noch nicht, dass die früh gestarteten Kernel-Treiber zuverlässig bewertet wurden. Storage-, Verschlüsselungs-, Backup- und Sicherheitsprodukte bringen Komponenten mit, die bereits vor dem regulären Betrieb des Virenschutzes initialisiert werden. Eine übernommene Altinstallation oder ein schlecht kontrollierter Agentenwechsel kann genau hier eine Lücke hinterlassen.

Early Launch Anti-Malware, kurz ELAM, gibt einem speziell signierten Antimalware-Treiber einen frühen Prüfpunkt im Windows-Start. Er bewertet nachfolgende Boot-Start-Treiber und deren abhängige DLLs. Der Kernel entscheidet anhand dieser Klassifizierung und der Startpolicy, welche Komponenten initialisiert werden dürfen. Bei Microsoft Defender Antivirus übernimmt Wdboot.sys diese Aufgabe.

Für AD-Härtung ist das besonders auf Domain Controllern, Identitätsservern und privilegierten Admin-Workstations relevant: Ihre Vertrauenswürdigkeit hängt auch vom Betriebssystemstart ab. ELAM ändert keine AD-Berechtigungen und löst kein Kennwortproblem. Es stärkt eine darunterliegende Schutzschicht.

Zielbild: geprüfter Start mit planbarer Wiederherstellung

Ein tragfähiger Zielzustand umfasst fünf Punkte:

  • Der ELAM-Anbieter ist bekannt und funktionsfähig. Das installierte Sicherheitsprodukt, seine Startkomponente und sein Updatepfad sind dokumentiert.
  • Die Startregel ist je Geräteklasse bewusst gewählt. Standardclients, Storage-Server, virtuelle DCs und physische Admin-Geräte erhalten keine ungeprüfte Pauschaländerung.
  • Die Vertrauenskette ist mitbetrachtet. Unterstützte Windows-Versionen, aktuelle Firmware, Secure Boot und geschütztes Endpoint-Management gehören zur Basis.
  • Jede Änderung endet mit einem nachgewiesenen Neustart und Funktionstest. Eine angewendete GPO allein ist keine Abnahme.
  • Recovery funktioniert ohne die normale Windows-Anmeldung. Konsole, Wiederherstellungsumgebung, BitLocker-Schlüssel und freigegebene Ersatzversionen sind erreichbar.

Secure Boot schützt den Übergang von der UEFI-Firmware zum vertrauenswürdigen Bootloader. Trusted Boot führt Integritätsprüfungen für Windows-Startkomponenten fort. ELAM ergänzt diese Kette um die Antimalware-Bewertung von Boot-Start-Treibern. Die Vulnerable Driver Blocklist und HVCI decken andere Aspekte der Treiberausführung ab; sie ersetzen diesen Prüfpunkt ebenso wenig wie ELAM eine laufende AV-/EDR-Kontrolle ersetzt.

Welche Startregel welchen Preis hat

Die englische GPO heißt Boot-Start Driver Initialization Policy. Sie liegt unter Computer Configuration > Policies > Administrative Templates > System > Early Launch Antimalware. In deutschen Verwaltungsvorlagen lautet der Pfad Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Antischadsoftware-Frühstart > Richtlinie für Bootstarttreiber-Initialisierung.

Die Auswahl beschreibt zulässige ELAM-Klassen, keine Liste genehmigter Hersteller:

  • Gut, unbekannt und schlecht, aber erforderlich — Wert 3: Windows lässt auch als schädlich bewertete, für den Start erforderliche Treiber zu. Andere als schädlich bewertete Treiber werden nicht initialisiert. Das ist der Standard und zunächst eine dokumentierbare Bestandsbaseline.
  • Gut und unbekannt — Wert 1: Auch als schädlich bewertete bootkritische Treiber werden ausgeschlossen. Das ist eine strengere Entscheidung, kann aber den Systemstart verhindern.
  • Nur gut — Wert 8: Zusätzlich werden unbekannte Komponenten ausgeschlossen. Schon ein legitimer, vom Anbieter nicht klassifizierter Treiber kann dadurch zum Ausfall führen. Diese Auswahl braucht eine eng kontrollierte und vollständig getestete Plattform.
  • Alle — Wert 7: Die ELAM-Klassifizierung führt zu keiner Sperre. Das ist kein geeignetes dauerhaftes Härtungsziel.

„Deaktiviert“ und „Nicht konfiguriert“ verwenden die Standardauswahl; sie schalten ELAM selbst nicht ab. Umgekehrt erzeugt eine aktivierte GPO ohne funktionsfähigen ELAM-Treiber keine entsprechende Schutzwirkung. Ein Wechsel vom unveränderten Standard zur expliziten Auswahl 3 verbessert die Nachvollziehbarkeit, verschärft aber die Sperrentscheidung nicht.

„Schlecht, aber erforderlich“ ist außerdem kein harmloser Kompatibilitätshinweis. Es bleibt ein Malwarebefund. Wenn die Startpolicy Verfügbarkeit bevorzugt und den Start erlaubt, muss dieser Befund trotzdem in die Incident-Bearbeitung gehen. Ein erreichbarer DC ist deshalb noch kein vertrauenswürdiger DC.

1. Anbieter, Treiber und bisherigen Zustand aufnehmen

Erfasse pro Pilotgruppe mindestens Windows-Build, Hardware oder VM-Plattform, Firmware, Sicherheitsprodukt, Plattformversion, Boot-Start-Treiber, Secure-Boot-Zustand und verantwortlichen Betrieb. ELAM wurde mit Windows 8 beziehungsweise Windows Server 2012 eingeführt; daraus folgt keine heutige Supportfreigabe für diese alten Betriebssysteme.

Bei Microsoft Defender wird der ELAM-Treiber über Plattformupdates gepflegt. Aktuelle Security Intelligence allein belegt daher keinen aktuellen Plattformstand. Bei Fremdprodukten müssen der Hersteller und die eingesetzte Produktversion den ELAM-Pfad bestätigen. Eine EDR-Lizenz oder ein laufender Sensor ist dafür kein ausreichender Ersatznachweis.

Die folgende Abfrage liest in einer erhöhten PowerShell die explizite administrative Startpolicy. Sie verändert keine Einstellungen:

Set-StrictMode -Version Latest

$policyPath = 'HKLM:\SYSTEM\CurrentControlSet\Policies\EarlyLaunch'
$policyValue = $null

try {
  if (Test-Path -LiteralPath $policyPath -ErrorAction Stop) {
    $policyKey = Get-Item -LiteralPath $policyPath -ErrorAction Stop
    $policyValue = $policyKey.GetValue('DriverLoadPolicy', $null)
  }

  [pscustomobject]@{
    ComputerName = [Environment]::MachineName
    ExplicitDriverLoadPolicy = if ($null -eq $policyValue) {
      'Not configured'
    } else {
      $policyValue
    }
  }

} catch {
  throw 'ELAM policy query failed. Check elevation and local registry access.'
}

Führe das Boot-Treiberinventar anschließend als eigene Abfrage aus, damit die unterschiedlichen Objektspalten in PowerShell getrennt dargestellt werden:

Get-CimInstance -ClassName Win32_SystemDriver `
  -Filter "StartMode = 'Boot'" -ErrorAction Stop |
  Select-Object Name, DisplayName, State, PathName |
  Sort-Object Name

Der administrative Wert liegt unter Policies\EarlyLaunch. Den daneben existierenden Bereich Control\EarlyLaunch nicht mit diesem GPO-Nachweis verwechseln. Auch interne Treiberwerte aus Entwicklerdokumentation sind keine verlässliche Vorlage für die administrative Auswahl; bei dieser GPO entspricht „Nur gut“ dem Wert 8.

Das Inventar zeigt keine ELAM-Klassifizierung. Ein fehlender Policywert bedeutet lediglich, dass hier keine explizite Auswahl nachgewiesen wurde. Lesefehler bleiben Fehler und dürfen im Compliance-Bericht nicht als Standard oder als Schutz gewertet werden.

2. Eine eigene Pilot-GPO mit klaren Abbruchkriterien anlegen

Sichere die bisherige Konfiguration und verwende eine gesonderte Computer-GPO mit kleinem, überprüfbarem Scope. Prüfe Verknüpfung, Sicherheitsfilter und mögliche konkurrierende Verwaltung durch MDM. Die GPO muss die beabsichtigte Einstellung am Zielsystem tatsächlich gewinnen.

Dokumentiere zunächst die vorhandene Regel. Prüfe anschließend, ob Gut und unbekannt für die jeweilige Plattform tragfähig ist: Damit darf ein als schädlich bewerteter Treiber auch dann nicht initialisiert werden, wenn er bootkritisch ist. Die Verfügbarkeitsfolge muss vor der Änderung akzeptiert und technisch beherrscht sein. Nur gut ist eine weitere Verschärfung und benötigt einen separaten Testentscheid.

Die ELAM-GPO bietet keinen eigenen Audit-Modus wie App Control. Eine erlaubende Startregel ist kein Audit-Modus einer strengeren Regel. Der Pilot muss daher die tatsächlich geplante Auswahl testen, bevor sie produktive Gerätegruppen erreicht.

Als Abbruchkriterien eignen sich ein fehlgeschlagener Start, unerwartete BitLocker-Recovery, ein ausgefallener Storage- oder Netzwerkpfad, fehlender Endpoint-Schutz oder ein nicht mehr erreichbares Management. Sicherheitsbefunde werden parallel untersucht; sie verschwinden nicht durch Rücknahme der strengeren Policy.

3. Neustarts über die tatsächlichen Betriebsfälle testen

Die Startregel greift beim nächsten Systemstart. Ein erfolgreiches gpupdate initialisiert bereits laufende Treiber nicht erneut. Plane einen echten Neustart im Change-Fenster ein und teste zusätzlich den für die Plattform relevanten Kaltstart. Auf Clients kann Schnellstart dazu führen, dass normales Herunterfahren und anschließendes Einschalten keinen gleichwertigen vollständigen Start ergeben.

Der Testumfang sollte mindestens enthalten:

  • Neustart, Anmeldung und Erreichbarkeit über den vorgesehenen Adminpfad;
  • Storage, Verschlüsselung, Netzwerk, Backup und AV-/EDR-Funktion;
  • reguläres Plattform-, Treiber- und Windows-Update mit anschließendem Neustart;
  • Recovery über den vorgesehenen Konsolen- und Wiederherstellungsweg;
  • bei virtuellen Systemen die tatsächlich verwendete virtuelle Hardware und Sicherheitskonfiguration.

Domain Controller folgen erst nach repräsentativen Tests und nacheinander. Vor jedem Neustart müssen verbleibende DCs Authentifizierung und DNS tragen können. Danach gehören AD-Replikation, DNS, SYSVOL/NETLOGON und das Betriebsmonitoring zur Abnahme. Ein VM-Snapshot ersetzt dabei kein unterstütztes AD-Wiederherstellungsverfahren.

4. Konfiguration und tatsächlichen Start getrennt nachweisen

gpresult /scope computer /r zeigt die angewendeten Computer-GPOs. Für die einzelne Startregel nutze zusätzlich den Gruppenrichtlinien-Ergebnisbericht oder RSoP und den gelesenen Policywert. Confirm-SecureBootUEFI prüft auf unterstützten UEFI-Systemen den Secure-Boot-Zustand; dafür sind erhöhte Rechte erforderlich. Ein Fehler oder ein nicht verfügbares Cmdlet ist kein positiver Nachweis.

Der ELAM-Treiber wird nach seiner frühen Startphase wieder entladen. Ein nach der Anmeldung gestoppter WdBoot-Treiber beweist deshalb keinen Ausfall. Ein vorhandener BackupPath unter Control\EarlyLaunch ist ebenfalls nur ein Konfigurationsindiz. Keines dieser einzelnen Signale ersetzt die Prüfung des tatsächlichen Startablaufs.

Vereinbare mit dem Endpoint-Betrieb einen zur Produktversion passenden Nachweis: erwartete Startkomponente, aktuelle Plattform, erfolgreiche Neustarts, Herstellerdiagnostik und zugehörige Erkennungstelemetrie. Bei Defender erscheinen ELAM-Erkennungen im Defender-Erkennungspfad, beispielsweise als Ereignis 1006; dieses Ereignis ist kein allgemeines „ELAM erfolgreich gestartet“-Signal.

Führe Policyzustand, Plattformstand, Neustartzeitpunkt und Prüfergebnis zusammen. Fehlende Meldungen können auch einen ausgefallenen Sensor oder einen unterbrochenen Sammelweg bedeuten. Für die Abnahme braucht es positive Betriebsnachweise und einen getesteten Weg für Sicherheitsmeldungen.

5. Wiederherstellung vor dem breiten Rollout üben

Ein nicht startendes System erhält keine reparierende GPO. Deshalb gehören erreichbare Out-of-Band-Konsole oder VM-Konsole, WinRE, freigegebene Ersatzpakete und eine dokumentierte Rücknahme der Pilotkonfiguration vor die erste produktive Verschärfung. Bei BitLocker müssen die zugehörigen Recovery-Schlüssel auch bei gestörtem AD-Zugriff kontrolliert verfügbar sein; Schlüssel gehören weder in Tickets noch in Diagnoseausgaben.

Unterscheide einen legitimen Treiber, der als unbekannt blockiert wurde, von einem tatsächlichen Malwarebefund. Im ersten Fall stehen Herstellerklärung, kompatibles Update oder Rücknahme der Pilotregel im Vordergrund. Im zweiten Fall kommen Isolation, Beweissicherung und gegebenenfalls sauberer Wiederaufbau hinzu. Bloßes Entsperren behebt die Kompromittierung nicht.

Windows bietet eine temporäre Deaktivierung des Antimalware-Frühstarts in den Starteinstellungen zur Wiederherstellung. Dieser Weg gehört ausschließlich in ein freigegebenes, begrenztes Recovery-Verfahren mit anschließender Ursachenbehebung und erneuter Schutzprüfung. Er ist keine dauerhafte Baseline. Secure Boot oder weitere Schutzschichten pauschal abzuschalten ist ebenfalls keine saubere Fehlerbehebung.

Vorteile im AD-Betrieb

  • Früher Prüfpunkt: Klassifizierte schädliche Boot-Treiber können vor ihrer Initialisierung gestoppt werden, bevor reguläre Schutzdienste übernehmen.
  • Bewusste Risikoentscheidung: Die Organisation legt fest, ob ein Malwarebefund auf einem bootkritischen Treiber den Start verhindern soll.
  • Weniger blinde Flecken bei Agentenwechseln: Anbieter, Startkomponente und Updatepfad werden überprüfbar.
  • Bessere Change-Qualität: Treiberabhängigkeiten und Wiederanlauf werden auch für besonders sensible AD-Systeme praktisch getestet.
  • Ergänzende Schutzschicht: ELAM stärkt die Startkette zusammen mit Secure Boot, Code Integrity und laufendem Endpoint-Schutz.

Nachteile und Grenzen

  • Verfügbarkeit kann sinken: Eine strengere Auswahl kann den Start legitimer Systeme verhindern, insbesondere bei unbekannten oder bootkritischen Komponenten.
  • Klassifizierung bleibt anbieterabhängig: „Gut“ ist keine Garantie für Fehlerfreiheit; fehlende oder ungültige Bewertungsdaten können zu „Unbekannt“ führen.
  • Die Standardregel toleriert ein Restrisiko: Bootkritische Malware kann zugelassen werden, damit das System startet. Dieser Fall braucht Incident Response.
  • Keine vollständige Treiberkontrolle: Später geladene Treiber, Firmware-Risiken und gewöhnliche Anwendungsausführung benötigen zusätzliche Kontrollen.
  • Kein GPO-Audit-Modus: Reale Pilotstarts und geeignete Diagnostik verursachen Betriebsaufwand.
  • Keine Reparatur kompromittierter Systeme: ELAM ersetzt weder Ursachenanalyse noch vertrauenswürdigen Wiederaufbau.

Typische Stolperfallen

  • GPO „Aktiviert“ mit zusätzlicher Härtung gleichsetzen: Erst die gewählte Klasse bestimmt, ob gegenüber dem Standard mehr blockiert wird.
  • „Nur gut“ ungeprüft auf alle DCs verteilen: Eine gleiche GPO trifft auf unterschiedliche Storage-, Backup- und Sicherheitskomponenten.
  • WdBoot nach der Anmeldung als normalen Dauerdienst prüfen: Sein vorgesehenes Entladen produziert sonst falsche Alarme.
  • Registry-Indizien als Startnachweis verkaufen: Policy, installierter Anbieter und erfolgreicher Schutzablauf sind verschiedene Prüfpunkte.
  • Ein AV-Signaturupdate mit einem Plattformupdate verwechseln: Beide müssen zum gewählten Produktstand passen.
  • Erfolgreichen Start trotz Malwarebefund abhaken: Verfügbarkeit und Vertrauenswürdigkeit sind getrennte Entscheidungen.
  • Rollback nur per GPO planen: Der Offline-Recovery-Weg muss vor dem Ausfall funktionieren.

Projekt-Checkliste

  • [ ] Geräteklassen und sensible AD-Rollen getrennt festlegen.
  • [ ] ELAM-Anbieter, Startkomponente, Plattformversion und Updatepfad dokumentieren.
  • [ ] Windows-Supportstand, Firmware und Secure Boot prüfen.
  • [ ] Boot-Treiber und Abhängigkeiten mit Produktverantwortlichen erfassen.
  • [ ] Bisherige GPO und den expliziten administrativen Policywert sichern.
  • [ ] Standardbaseline und tatsächliche Verschärfung klar unterscheiden.
  • [ ] Separate Pilot-GPO, Zuständigkeit und Abbruchkriterien festlegen.
  • [ ] Die geplante Auswahl auf repräsentativer Hardware und virtuellen Plattformen testen.
  • [ ] Neustart, relevante Kaltstarts und reguläre Updates in den Test aufnehmen.
  • [ ] DCs nacheinander ändern und AD-/DNS-Funktion jeweils abnehmen.
  • [ ] Anbieterdiagnostik und Erkennungsmeldungen zentral auswertbar machen.
  • [ ] Konsole, WinRE und geschützten Zugriff auf BitLocker-Recovery praktisch prüfen.
  • [ ] Malwarebefunde unabhängig vom erfolgreichen Start bearbeiten.
  • [ ] Ausnahmen mit betroffenen Geräten, Owner, Frist und Rückkehrplan dokumentieren.
  • [ ] Nach Agentenwechseln und wesentlichen Treiberänderungen erneut validieren.