Ausgangslage: Authentifizierung passiert oft zu freizuegig

In vielen Active-Directory-Umgebungen koennen Server, Clients und Dienste noch sehr breit ausgehende Authentifizierung anstossen. Ein System versucht, einen Drucker zu erreichen, eine Dateiablage zu pruefen, ein WebDAV-Ziel zu kontaktieren oder ueber RPC eine entfernte Komponente anzusprechen. Im Normalbetrieb faellt das kaum auf, weil solche Verbindungen historisch gewachsen sind.

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

Das Thema gehoert 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 duerfen.

Zielbild: Authentifizierung hat klare Leitplanken

Ein belastbares Zielbild sieht so aus:

  1. Tier-0-Systeme authentifizieren nicht ungeplant nach aussen. Domain Controller, CA-Server, Admin-Jumphosts und Management-Server haben restriktive ausgehende Pfade.
  2. NTLM ist sichtbar und reduziert. Wo Kerberos moeglich ist, wird NTLM nicht als bequemer Fallback akzeptiert.
  3. Relay-Ziele sind gehaertet. SMB Signing, LDAP Signing, LDAP Channel Binding und Extended Protection werden dort erzwungen, wo sie fachlich passen.
  4. Unnoetige Dienste sind aus. Print Spooler, WebClient und alte RPC-abhaengige Rollen laufen nur dort, wo sie nachweisbar benoetigt werden.
  5. Firewall-Regeln sind absichtlich. Server duerfen nicht pauschal zu beliebigen SMB-, HTTP- oder RPC-Zielen sprechen.
  6. Ausnahmen haben Owner und Ablaufdatum. Keine dauerhaften "nur fuer 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 waeren besonders problematisch, wenn sie ihre Identitaet gegenueber 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 grosser Sensor-Rollout sein. Firewall-Logs, Windows-Eventlogs, NTLM-Auditing und vorhandenes EDR reichen oft fuer die erste Priorisierung.

2) NTLM-Auditing einschalten und Abhaengigkeiten sortieren

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

Praktische Fragen:

  • Welche Server akzeptieren noch NTLM fuer administrative oder fachliche Dienste?
  • Welche Clients oder Applikationen nutzen NTLM, obwohl Kerberos moeglich waere?
  • Welche Ziele bekommen NTLM von Tier-0-Systemen?
  • Gibt es externe, DMZ- oder Partnerziele mit NTLM-Abhaengigkeiten?
  • Welche Systeme wuerden bei einer NTLM-Einschraenkung 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.

Bewaehrte Leitplanken:

  • Domain Controller duerfen nur zu definierten Management-, Backup-, Monitoring- und Replikationszielen sprechen.
  • CA-Server duerfen 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 fuer Tier-0-Systeme nicht Standard, sondern Ausnahme.

Wichtig: Das ist kein "alles blocken"-Projekt. Beginne im Audit- oder Pilotmodus, dokumentiere legitime Ziele und schliesse dann die offensichtlichen Luecken.

4) Dienste reduzieren, die Authentifizierung ausloesen koennen

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

Pruefe besonders:

  • Print Spooler: auf Domain Controllern und den meisten Servern nicht erforderlich.
  • WebClient/WebDAV: auf Servern oft unnoetig und fuer Authentifizierungsumleitungen riskant.
  • Legacy-Datei- und Druckpfade: alte Applikationen erzwingen manchmal unsaubere Ausnahmen.
  • RPC-abhaengige Rollen: nicht pauschal abschalten, aber pro Serverrolle begruenden.
  • AD-CS-Webkomponenten: Enrollment-Webseiten und HTTP-basierte Endpunkte nur betreiben, wenn sie wirklich gebraucht und gehaertet sind.

Der saubere Weg ist eine Rollenbaseline: Welche Dienste gehoeren auf DCs, auf CA-Server, auf Fileserver, auf Jump Hosts? Alles andere braucht eine Begruendung.

5) Relay-Ziele haerten, nicht nur Ausloeser jagen

Coerce-Reduktion funktioniert nur, wenn auch die moeglichen Zielsysteme gehaertet sind. Sonst bleibt der Angriffspfad bestehen, auch wenn einzelne Ausloeser verschwinden.

Wichtige Kontrollen:

  • SMB Signing auf kritischen Serverpfaden verbindlich machen.
  • LDAP Signing und LDAP Channel Binding fuer Domain Controller planen und durchsetzen.
  • Extended Protection fuer geeignete HTTP-basierte Windows- und AD-CS-Dienste pruefen.
  • Unsichere Gastanmeldungen und anonyme Enumeration blockieren.
  • NTLM-Fallbacks nicht unbemerkt wieder einfuehren.
  • 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) Aenderungen in Wellen ausrollen

Ein pragmatischer Ablauf:

  1. Tier-0- und Management-Systeme inventarisieren.
  2. NTLM- und ausgehende Verbindungsdaten sammeln.
  3. Offensichtlich unnoetige Dienste in Pilotgruppen deaktivieren.
  4. Firewall-Allowlists fuer 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 ueberfuehren.

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 fuehrt seltener zu verwertbaren Folgepfaden.
  • Schuetzt Tier 0 besser: DCs, CAs und Admin-Systeme senden weniger ungeplante Authentifizierung an falsche Ziele.
  • Macht Legacy sichtbar: NTLM-, WebDAV-, Druck- und RPC-Abhaengigkeiten werden messbar statt nur vermutet.
  • Verbessert Betriebsarchitektur: Serverrollen bekommen klarere Kommunikationsregeln.
  • Ergaenzt 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-Aenderungen schnell zum Ratespiel.
  • Legacy kann brechen: Alte Applikationen, Druckprozesse, Scans, Backup-Agenten und Appliances nutzen manchmal unerwartete Pfade.
  • Nicht jeder Ausloeser ist abschaltbar: Manche RPC- oder Management-Funktionen werden fachlich benoetigt.
  • 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 Ausfaelle und Rollbacks.
  • WebClient uebersehen: Auf Servern ist WebDAV oft unnoetig, bleibt aber in Baselines unentschieden.
  • AD CS ausklammern: Enrollment-Endpunkte und Webkomponenten sind fuer Relay-Betrachtungen besonders sensibel.
  • Firewall-Regeln ohne Owner: Niemand raeumt Ausnahmen ab, wenn sie nicht dokumentiert sind.
  • Nur eingehend haerten: Ausgehende Authentifizierung ist fuer 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 fuer kritische Systeme erfassen.
  • [ ] Print Spooler, WebClient und unnoetige Rollen pro Serverbaseline pruefen.
  • [ ] SMB Signing, LDAP Signing, LDAP Channel Binding und Extended Protection nach Rolle planen.
  • [ ] AD-CS-Webkomponenten, Templates und Enrollment-Rechte separat pruefen.
  • [ ] Firewall-Allowlists fuer DCs, CAs, Jump Hosts und Management-Server pilotieren.
  • [ ] Ausnahmen mit Owner, fachlichem Grund, Ablaufdatum und Review-Zyklus dokumentieren.
  • [ ] Monitoring fuer neue NTLM-Pfade und unerwartete ausgehende Authentifizierung einrichten.
  • [ ] Baseline in GPO, Endpoint Management und Server-Build-Prozess uebernehmen.