Sicheren Netlogon-Kanal nach ZeroLogon härten

Jeder in die Domäne eingebundene Computer und jede Vertrauensstellung unterhält über das Netlogon Remote Protocol (MS-NRPC) einen sicheren Kanal zu einem Domänencontroller. Er transportiert NTLM-Pass-Through-Authentifizierung, Kennwortänderungen von Computerkonten und die Validierung von Vertrauensstellungen. ZeroLogon (CVE-2020-1472) hat gezeigt, wie gravierend ein schwacher sicherer Kanal sein kann: Ein Fehler im AES-CFB8-Handshake erlaubte es einem nicht authentifizierten Angreifer im Netz, das Kennwort des Computerkontos eines DC auf leer zu setzen und die Domäne binnen Sekunden zu übernehmen.

Der Patch ist alt, doch die begleitende Härtung ist oft nicht abgeschlossen. Während des Rollouts 2020 angelegte Ausnahme-GPOs gewähren weiterhin Ausnahmen. Die nachfolgende Sealing-Anforderung aus CVE-2022-38023 wurde nie überprüft, und einige NAS-Appliances oder alte Samba-Hosts protokollieren still jeden Tag Ablehnungen. Dieser Leitfaden geht über die einzeilige Prüfung in der DC-Baseline hinaus. Er zeigt, wie Sie messen, was noch schwaches Netlogon verwendet, jede Ebene durchsetzen und das nachweisen.

Die Ebenen der Härtung

Die Netlogon-Härtung kam in Etappen. Jede Etappe hat ihre eigene Kontrolle und ihre eigenen Ereignisse:

Bedeutung der ZeroLogon-Ereignisse:

• 5827: Der DC hat eine verwundbare Netlogon-Verbindung von einem Computerkonto abgelehnt.
• 5828: Der DC hat eine verwundbare Netlogon-Verbindung von einem Vertrauensstellungskonto abgelehnt.
• 5829: Der DC hat eine verwundbare Computerverbindung zugelassen. Das sehen Sie nur in der Phase vor der Erzwingung – auf einem heute gepatchten DC bedeutet es also, dass etwas nicht stimmt.
• 5830: Der DC hat eine verwundbare Computerverbindung aufgrund der Ausnahme-GPO zugelassen.
• 5831: Der DC hat eine verwundbare Vertrauensstellungsverbindung aufgrund der Ausnahme-GPO zugelassen.

Die Ereignisse 5838 und 5839 bedeuten, dass ein Computer- bzw. Vertrauensstellungskonto RPC-Signierung verwendet hat, wo Sealing erwartet wurde. Auf einem vollständig aktualisierten DC nach dem Erzwingungsdatum werden diese Clients abgelehnt, nicht nur gewarnt.

Messen: Ereignisse von allen DCs sammeln

Ziehen Sie in einem Durchlauf die Netlogon-Ereignisse eines Monats von jedem DC. Wenn Sie Systemprotokolle an ein SIEM weiterleiten, führen Sie dort die entsprechende Abfrage aus. Ziel ist es zu wissen, welche Geräte und Vertrauensstellungen noch auf der Kippe stehen.

$ids = 5827,5828,5829,5830,5831,5838,5839
$since = (Get-Date).AddDays(-30)

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'System'; ProviderName = 'NETLOGON'; Id = $ids; StartTime = $since
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, Id, TimeCreated,
    @{ n = 'Detail'; e = { ($_.Message -split "`n" | Select-String 'Machine|Account|Domain|OS' ) -join ' | ' } } |
    Sort-Object Id, TimeCreated |
    Export-Csv C:\Reports\netlogon-events.csv -NoTypeInformation

Jedes Ereignis enthält den Computer- oder Vertrauensstellungsnamen, dessen Domäne und – sofern bekannt – die Betriebssystemversion. Typische Funde sind Speicher-Appliances, Drucker und Scanner, die sich an der Domäne authentifizieren, alte Samba-Versionen und eingebettete Linux-Systeme, die mit veralteten Werkzeugen eingebunden wurden.

Prüfen Sie als Nächstes, ob jemals jemand die Ausnahmeliste befüllt hat. Sie ist ein in einer GPO gespeicherter Sicherheitsdeskriptor – lesen Sie sie also aus der resultierenden Richtlinie auf jedem DC:

Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    $p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
    Get-ItemProperty $p | Select-Object PSComputerName,
        FullSecureChannelProtection, RequireSeal, VulnerableChannelAllowList,
        RequireSignOrSeal, SealSecureChannel, SignSecureChannel, RequireStrongKey
}

VulnerableChannelAllowList ist der Registrierungswert hinter der GPO. Hat er Inhalt, dekodieren Sie die SDDL (ConvertFrom-SddlString), um zu sehen, welche Konten oder Gruppen ausgenommen sind.

Auditieren: jedes Gerät klären, bevor Sie verschärfen

Arbeiten Sie die CSV Gerät für Gerät ab:

1. Ermitteln Sie den Verantwortlichen für jedes Computerkonto in den Ereignissen 5827, 5829, 5830 und 5838. Verwenden Sie Get-ADComputer <name> -Properties operatingSystem, whenChanged, ManagedBy, Description.
2. Aktualisieren oder ersetzen. Hersteller-Firmware oder ein aktuelles Samba-Release behebt fast alle Fälle. Samba verlangt seit Jahren standardmäßig einen sicheren Schannel, alte Appliance-Builds können aber auf eine ältere Version festgelegt sein.
3. Prüfen Sie Vertrauensstellungen bei 5828, 5831 und 5839. Das sind externe oder Gesamtstruktur-Vertrauensstellungen, deren Gegenseite ungepatchte DCs hat – oft ein Partner oder eine übernommene Domäne. Die DCs dieser Domäne müssen gepatcht werden. Einen sicheren lokalen Workaround gibt es nicht.
4. Löschen Sie Totes. Ein überraschend großer Teil der abgelehnten Computerkonten gehört zu Geräten, die nicht mehr existieren. Deaktivieren und entfernen Sie sie entsprechend Ihrem Prozess für veraltete Objekte.

Lassen Sie den Durchlauf nach diesem ersten Durchgang weiterlaufen. Neue Geräte werden eingebunden, Partner bauen ihre DCs neu, und Appliances werden aus alten Images wiederhergestellt. Ein monatlicher Bericht über alle Netlogon-Ereignisse im Bereich 5827–5839, der an das für Domänenbeitritte zuständige Team geht, erkennt diese Fälle lange bevor eine Erzwingungsänderung sie in einen Ausfall verwandelt.

Durchsetzen

Die Ausnahmeliste für verwundbare Verbindungen leeren

Öffnen Sie die GPO, die sie setzt (meist die Default Domain Controllers Policy oder eine GPO aus der ZeroLogon-Zeit), und navigieren Sie zu:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections

Setzen Sie die Einstellung auf Not Defined, sobald jedes aufgeführte Gerät behoben ist. Kann ein geschäftskritisches Gerät wirklich noch nicht behoben werden, behalten Sie eine einzige dedizierte Gruppe im Deskriptor, dokumentieren Sie Verantwortlichen und Enddatum und alarmieren Sie bei jedem Ereignis 5830. Gewähren Sie die Ausnahme niemals einer breiten Gruppe wie Domain Computers.

Sealing-Erzwingung bestätigen

Auf aktuellen, unterstützten Windows-Server-Builds hat Microsofts Zeitplan für CVE-2022-38023 Sealing bereits verpflichtend gemacht: Seit den Updates vom Juli 2023 lässt sich RequireSeal nicht mehr auf 0 (deaktiviert) oder 1 (Kompatibilität) setzen, sodass der Wert auf einem aktualisierten DC das Verhalten nicht mehr ändert. Ihn auf 2 zu setzen, schadet nicht und wirkt sich nur auf einem DC aus, der auf einem Update-Stand zwischen November 2022 und Juni 2023 stehen geblieben ist. Setzen Sie den Wert trotzdem explizit, damit ein aus einer alten Sicherung wiederhergestellter oder selten gepatchter DC im Abweichungsbericht auftaucht:

$p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
Set-ItemProperty -Path $p -Name RequireSeal -Value 2 -Type DWord
Set-ItemProperty -Path $p -Name FullSecureChannelProtection -Value 1 -Type DWord

Verteilen Sie diese Werte als Registrierungselemente der Gruppenrichtlinien-Einstellungen (Preferences) in einer reinen DC-GPO, nicht von Hand, damit sie bei jeder Aktualisierung erneut angewendet werden.

Die klassischen Optionen des sicheren Kanals festziehen

Diese Sicherheitsoptionen gibt es seit Windows 2000; sie sollten auf jedem Domänenmitglied und jedem DC aktiviert sein. Die Sicherheits-Baselines von Microsoft setzen die meisten bereits:

• Domain member: Digitally encrypt or sign secure channel data (always) = Enabled
• Domain member: Digitally encrypt secure channel data (when possible) = Enabled
• Domain member: Digitally sign secure channel data (when possible) = Enabled
• Domain member: Require strong (Windows 2000 or later) session key = Enabled
• Domain member: Disable machine account password changes = Disabled
• Domain member: Maximum machine account password age = 30 Tage
• Domain controller: Refuse machine account password changes = Disabled

Die regelmäßige Rotation der Computerkennwörter begrenzt, wie lange ein gestohlenes Computergeheimnis nutzbar ist. Stoppen Sie jeden Imaging- oder VDI-Prozess, der die Rotation deaktiviert, um „die Vertrauensstellung stabil zu halten“. Korrigieren Sie stattdessen das Image.

Überprüfen

Prüfen Sie zuerst an einer Stichprobe von Mitgliedern – mindestens eines pro Betriebssystemfamilie –, dass der sichere Kanal weiterhin funktioniert:

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:corp.example.com

Wiederholen Sie dann den Ereignisdurchlauf und bestätigen Sie, dass es keine Ereignisse 5829, 5830 oder 5831 gibt und dass 5827, 5828, 5838 und 5839 nur Geräte nennen, deren Außerbetriebnahme Sie bereits beschlossen haben. Wiederholen Sie die Registrierungsabfrage und bestätigen Sie, dass VulnerableChannelAllowList auf keinem DC vorhanden ist.

Richten Sie schließlich Erkennungen ein, die auf Rückschritte und Ausnutzung achten:

• Jedes Ereignis 5829, 5830 oder 5831 ist ein Konfigurationsrückschritt. Eröffnen Sie ein Ticket.
• Eine Häufung von 5827 aus einer einzigen Quelle kann ein Scan nach schwachem Netlogon sein.
• Ereignis 4742 (Computerkonto geändert) am eigenen Konto eines Domänencontrollers, bei dem der Antragsteller ANONYMOUS LOGON ist und das Kennwort geändert wurde, ist das klassische Artefakt einer ZeroLogon-Ausnutzung. Legitim kommt das nie vor. Alarmieren Sie mit hoher Priorität. Die weiterzuleitenden Ereignis-IDs stehen in der Referenz der AD-Ereignis-IDs.

Was dabei kaputtgeht

• Nicht-Windows-Geräte mit altem Netlogon-Stack. NAS-Appliances, Multifunktionsdrucker, alte Samba-Dateiserver und einige Linux-Agenten für den Domänenbeitritt können sich nach der Ablehnung nicht mehr authentifizieren oder ihr Computerkennwort nicht ändern. Benutzer sehen auf diesen Geräten „Vertrauensstellung fehlgeschlagen“ oder NTLM-Anmeldefehler.
• Vertrauensstellungen zu ungepatchten Domänen. Eine Gesamtstruktur- oder externe Vertrauensstellung, deren entfernte DCs kein Sealing beherrschen, wird abgelehnt. Die Authentifizierung über diese Vertrauensstellung schlägt fehl, bis der Partner patcht.
• Eingefrorene VDI- und Labor-Images. Images mit deaktivierten Computerkennwortänderungen laufen aus der Synchronisierung und verlieren ihren sicheren Kanal, sobald die Rotation wieder einsetzt. Bauen Sie sie mit aktivierter Rotation neu auf oder nutzen Sie die vom VDI-Hersteller unterstützte Behandlung von Computerkennwörtern.
• Wiederhergestellte DCs. Ein DC, der aus einer Sicherung wiederhergestellt wird, die älter als Ihre Update-Baseline ist, kommt ohne Erzwingung zurück, bis er gepatcht ist. Nehmen Sie diese Werte in die Prüfungen Ihres Plans zur Gesamtstruktur-Wiederherstellung auf.

Weiterführende Lektüre: die DC-Baseline für die umgebende Konfiguration, Authentication Coercion blockieren für die andere RPC-basierte Angriffsklasse gegen DCs und NTLM einschränken, um die Abhängigkeit von Netlogon-Pass-Through insgesamt zu verringern.