Ausgangslage: Authentifizierung passiert oft zu freizügig

In vielen Active-Directory-Umgebungen können Server, Clients und Dienste noch sehr breit ausgehende Authentifizierung anstoßen. Ein System versucht, einen Drucker zu erreichen, eine Dateiablage zu prüfen, ein WebDAV-Ziel zu kontaktieren oder über RPC eine entfernte Komponente anzusprechen. Im Normalbetrieb fällt das kaum auf, weil solche Verbindungen historisch gewachsen sind.

Coerce Attacks nutzen genau diese Eigenschaft defensiv betrachtet aus: Ein System wird dazu gebracht, sich gegenüber einem anderen Ziel zu authentifizieren. Der kritische Punkt ist nicht ein einzelner Exploit, sondern die Kombination aus unkontrollierter ausgehender Authentifizierung, NTLM-Restflächen, Relay-fähigen Diensten und zu wenig Sichtbarkeit.

Das Thema gehört deshalb nicht in die Schublade "Patch einspielen und erledigt". Patches sind wichtig, aber das Ziel ist breiter: Systeme sollen nicht beliebig Authentifizierung in fremde Netze, auf untrusted Server oder zu sensiblen Diensten senden dürfen.

Zielbild: Authentifizierung hat klare Leitplanken

Ein belastbares Zielbild sieht so aus:

  1. Tier-0-Systeme authentifizieren nicht ungeplant nach außen. Domain Controller, CA-Server, Admin-Jumphosts und Management-Server haben restriktive ausgehende Pfade.
  2. NTLM ist sichtbar und reduziert. Wo Kerberos möglich ist, wird NTLM nicht als bequemer Fallback akzeptiert.
  3. Relay-Ziele sind gehärtet. SMB Signing, LDAP Signing, LDAP Channel Binding und Extended Protection werden dort erzwungen, wo sie fachlich passen.
  4. Unnötige Dienste sind aus. Print Spooler, WebClient und alte RPC-abhängige Rollen laufen nur dort, wo sie nachweisbar benötigt werden.
  5. Firewall-Regeln sind absichtlich. Server dürfen nicht pauschal zu beliebigen SMB-, HTTP- oder RPC-Zielen sprechen.
  6. Ausnahmen haben Owner und Ablaufdatum. Keine dauerhaften "nur für Legacy"-Freigaben ohne Review.

Das Ziel ist nicht, jede Windows-Kommunikation zu blockieren. Das Ziel ist, erzwungene Authentifizierung als Risiko einzugrenzen und Betriebspfade bewusst zu machen.

Umsetzung: erst sichtbar machen, dann begrenzen

1) Kritische Systeme und ausgehende Pfade erfassen

Starte mit einer einfachen Frage: Welche Systeme wären besonders problematisch, wenn sie ihre Identität gegenüber einem falschen Ziel preisgeben oder per NTLM ansprechbar werden?

Typischer Scope:

  • Domain Controller
  • AD-CS-Server und Enrollment-Endpunkte
  • Admin-Jumphosts, PAWs und Management-Server
  • Backup-, Deployment- und Monitoring-Systeme
  • Fileserver mit administrativen Freigaben
  • Applikationsserver mit privilegierten Service Accounts

Danach brauchst du Sicht auf ausgehende Verbindungen: SMB, HTTP/HTTPS, WebDAV, RPC, Druckdienste, LDAP und NTLM-Nutzung. Das muss kein großer Sensor-Rollout sein. Firewall-Logs, Windows-Eventlogs, NTLM-Auditing und vorhandenes EDR reichen oft für die erste Priorisierung.

2) NTLM-Auditing einschalten und Abhängigkeiten sortieren

Coerce-Risiko wird deutlich größer, wenn NTLM in kritischen Pfaden noch normal ist. Aktiviere zuerst Auditing, nicht sofort harte Blockaden.

Praktische Fragen:

  • Welche Server akzeptieren noch NTLM für administrative oder fachliche Dienste?
  • Welche Clients oder Applikationen nutzen NTLM, obwohl Kerberos möglich wäre?
  • Welche Ziele bekommen NTLM von Tier-0-Systemen?
  • Gibt es externe, DMZ- oder Partnerziele mit NTLM-Abhängigkeiten?
  • Welche Systeme würden bei einer NTLM-Einschränkung sofort brechen?

Danach kann in Wellen eingegrenzt werden: erst Tier 0 und Management-Pfade, dann kritische Serverrollen, dann breitere Server- und Client-Gruppen. Eine pauschale NTLM-Abschaltung ohne Inventar ist selten sauber. Dauerhafte Duldung ohne Plan ist aber auch keine Option.

3) Ausgehende Authentifizierung von Servern begrenzen

Server brauchen selten beliebigen ausgehenden Zugriff auf SMB, WebDAV oder interne HTTP-Endpunkte. Genau dort lohnt sich ein Firewall-Design.

Bewährte Leitplanken:

  • Domain Controller dürfen nur zu definierten Management-, Backup-, Monitoring- und Replikationszielen sprechen.
  • CA-Server dürfen nur die PKI-relevanten Pfade erreichen, nicht beliebige Fileserver oder WebDAV-Ziele.
  • Admin-Jumphosts bekommen restriktive ausgehende Regeln und keine offenen Legacy-Pfade.
  • Server-to-Server-SMB wird allowlist-basiert behandelt.
  • Ausgehender Zugriff ins Internet ist für Tier-0-Systeme nicht Standard, sondern Ausnahme.

Wichtig: Das ist kein "alles blocken"-Projekt. Beginne im Audit- oder Pilotmodus, dokumentiere legitime Ziele und schließe dann die offensichtlichen Lücken.

4) Dienste reduzieren, die Authentifizierung auslösen können

Viele Coerce-Pfade hängen an Windows-Diensten und Rollen, die in Server-Baselines nie sauber entschieden wurden.

Prüfe besonders:

  • Print Spooler: auf Domain Controllern und den meisten Servern nicht erforderlich.
  • WebClient/WebDAV: auf Servern oft unnötig und für Authentifizierungsumleitungen riskant.
  • Legacy-Datei- und Druckpfade: alte Applikationen erzwingen manchmal unsaubere Ausnahmen.
  • RPC-abhängige Rollen: nicht pauschal abschalten, aber pro Serverrolle begründen.
  • AD-CS-Webkomponenten: Enrollment-Webseiten und HTTP-basierte Endpunkte nur betreiben, wenn sie wirklich gebraucht und gehärtet sind.

Der saubere Weg ist eine Rollenbaseline: Welche Dienste gehören auf DCs, auf CA-Server, auf Fileserver, auf Jump Hosts? Alles andere braucht eine Begründung.

5) Relay-Ziele härten, nicht nur Auslöser jagen

Coerce-Reduktion funktioniert nur, wenn auch die möglichen Zielsysteme gehärtet sind. Sonst bleibt der Angriffspfad bestehen, auch wenn einzelne Auslöser verschwinden.

Wichtige Kontrollen:

  • SMB Signing auf kritischen Serverpfaden verbindlich machen.
  • LDAP Signing und LDAP Channel Binding für Domain Controller planen und durchsetzen.
  • Extended Protection für geeignete HTTP-basierte Windows- und AD-CS-Dienste prüfen.
  • Unsichere Gastanmeldungen und anonyme Enumeration blockieren.
  • NTLM-Fallbacks nicht unbemerkt wieder einführen.
  • AD-CS-Templates, Enrollment-Rechte und Web Enrollment separat bewerten.

Das reduziert nicht jede Form von erzwungener Authentifizierung. Es nimmt aber vielen Relay-Szenarien die Wirkung.

6) Admin-Pfade separat behandeln

Admin-Jumphosts, PAWs, Management-Server und Backup-Systeme sind kein normaler Client-Scope. Wenn diese Systeme ungeplant zu beliebigen Zielen authentifizieren, entsteht schnell Tier-0-Risiko.

Setze hier strenger an:

  • keine normalen Benutzer- oder Server-Admin-Logons auf Tier-0-Systemen,
  • ausgehende Netzwerkpfade dokumentieren und begrenzen,
  • gespeicherte Credentials vermeiden,
  • lokale Adminrechte reduzieren,
  • EDR- und Firewall-Events zentral auswerten,
  • neue Server automatisch in passende Baselines bringen.

Gerade Admin-Systeme brauchen eine kleine, nachvollziehbare Kommunikationsmatrix. Wenn niemand sagen kann, wohin ein Jump Host sprechen muss, ist das ein eigenes Finding.

7) Änderungen in Wellen ausrollen

Ein pragmatischer Ablauf:

  1. Tier-0- und Management-Systeme inventarisieren.
  2. NTLM- und ausgehende Verbindungsdaten sammeln.
  3. Offensichtlich unnötige Dienste in Pilotgruppen deaktivieren.
  4. Firewall-Allowlists für kritische Serverrollen testen.
  5. SMB/LDAP/HTTP-Ziele gegen Relay absichern.
  6. Ausnahmen mit Owner, Grund und Ablaufdatum dokumentieren.
  7. Baseline in GPO, Endpoint Management oder Server-Build-Prozess überführen.

Wichtig ist die Reihenfolge: Nicht erst eine perfekte Architektur malen. Lieber mit den riskantesten Systemen anfangen und dort messbare Leitplanken setzen.

Vorteile (explizit)

  • Reduziert Relay-Wirkung: Erzwungene Authentifizierung führt seltener zu verwertbaren Folgepfaden.
  • Schützt Tier 0 besser: DCs, CAs und Admin-Systeme senden weniger ungeplante Authentifizierung an falsche Ziele.
  • Macht Legacy sichtbar: NTLM-, WebDAV-, Druck- und RPC-Abhängigkeiten werden messbar statt nur vermutet.
  • Verbessert Betriebsarchitektur: Serverrollen bekommen klarere Kommunikationsregeln.
  • Ergänzt bestehende Baselines: SMB Signing, LDAP Signing, NTLM-Reduktion und Spooler-Hardening greifen zusammen.

Nachteile und Grenzen (explizit)

  • Inventar kostet Zeit: Ohne Verbindungsdaten werden Firewall- und NTLM-Änderungen schnell zum Ratespiel.
  • Legacy kann brechen: Alte Applikationen, Druckprozesse, Scans, Backup-Agenten und Appliances nutzen manchmal unerwartete Pfade.
  • Nicht jeder Auslöser ist abschaltbar: Manche RPC- oder Management-Funktionen werden fachlich benötigt.
  • Kontrollen wirken nur gemeinsam: Ein deaktivierter Dienst hilft wenig, wenn Relay-Ziele weiter schwach bleiben.
  • Ausnahmen brauchen Pflege: Eine gute Allowlist veraltet, wenn Serverrollen und Applikationen nicht mitgepflegt werden.

Typische Stolperfallen in Projekten

  • Nur nach bekannten Angriffsnamen suchen: Entscheidend ist der Authentifizierungspfad, nicht der Name des Tools oder der Technik.
  • Tier 0 wie normale Server behandeln: DCs, CAs und Jump Hosts brauchen restriktivere ausgehende Regeln.
  • NTLM direkt blocken: Ohne Auditphase entstehen Ausfälle und Rollbacks.
  • WebClient übersehen: Auf Servern ist WebDAV oft unnötig, bleibt aber in Baselines unentschieden.
  • AD CS ausklammern: Enrollment-Endpunkte und Webkomponenten sind für Relay-Betrachtungen besonders sensibel.
  • Firewall-Regeln ohne Owner: Niemand räumt Ausnahmen ab, wenn sie nicht dokumentiert sind.
  • Nur eingehend härten: Ausgehende Authentifizierung ist für dieses Risiko genauso wichtig.

Projekt-Checkliste

  • [ ] Tier-0-Systeme, Management-Server und kritische Applikationsserver als ersten Scope festlegen.
  • [ ] NTLM-Auditing aktivieren und Ergebnisse zentral auswerten.
  • [ ] Ausgehende SMB-, HTTP/WebDAV-, RPC- und LDAP-Pfade für kritische Systeme erfassen.
  • [ ] Print Spooler, WebClient und unnötige Rollen pro Serverbaseline prüfen.
  • [ ] SMB Signing, LDAP Signing, LDAP Channel Binding und Extended Protection nach Rolle planen.
  • [ ] AD-CS-Webkomponenten, Templates und Enrollment-Rechte separat prüfen.
  • [ ] Firewall-Allowlists für DCs, CAs, Jump Hosts und Management-Server pilotieren.
  • [ ] Ausnahmen mit Owner, fachlichem Grund, Ablaufdatum und Review-Zyklus dokumentieren.
  • [ ] Monitoring für neue NTLM-Pfade und unerwartete ausgehende Authentifizierung einrichten.
  • [ ] Baseline in GPO, Endpoint Management und Server-Build-Prozess übernehmen.