Kerberos-Ticket-Lebensdauer nach Kontodeaktivierung: Eindämmung

Kerberos-Ticket-Lebensdauer nach Kontodeaktivierung: Warum Sitzungen fortbestehen

Die Kerberos-Ticket-Lebensdauer nach Kontodeaktivierung ist relevant, weil eine Änderung des Kontostatus bereits ausgestellte Tickets nicht automatisch ungültig macht. Microsoft dokumentiert, dass gültige Diensttickets, die vor der Deaktivierung ausgestellt wurden, weiterhin Zugriff ermöglichen können. Für die Reaktion auf einen Vorfall sind daher Belege zum Konto, zu den Tickets und zu den Ressourcen erforderlich, die diese akzeptieren. Die Deaktivierung allein belegt keine abgeschlossene Eindämmung. Microsoft Learn: user ticket lifetime

Es gibt eine zweite Grenze: Eine authentifizierte Verbindung kann das Ticket überdauern, mit dem sie aufgebaut wurde. Microsoft erklärt, dass Diensttickets neue Verbindungen authentifizieren; ihr Ablauf unterbricht keine laufenden Vorgänge auf einer bereits authentifizierten Verbindung. Das Abwarten des Ticket-Endzeitpunkts reicht folglich nicht als Nachweis dafür aus, dass der Zugriff beendet wurde. Microsoft Learn: service ticket lifetime

Betrachten Sie bei der Untersuchung drei getrennte Fragen. Kann die Identität ein weiteres Ticket erhalten? Kann ein bereits vorhandenes Ticket eine weitere Verbindung authentifizieren? Ist eine zuvor authentifizierte Verbindung noch aktiv? Diese Untersuchungsfragen ergeben sich aus den dokumentierten Grenzen; sie sind keine drei Phasen, die jeder Vorfall durchläuft. Halten Sie sie in der Vorfallsdokumentation getrennt, damit Belege zu einer Frage nicht versehentlich auch die anderen als erledigt erscheinen lassen.

Dieser Leitfaden behandelt bereits ausgestellte legitime Tickets, einschließlich der Eindämmungsprobleme bei gestohlenem Ticketmaterial. Zur eigenständigen Bedrohung durch gefälschte TGTs auf Grundlage eines kompromittierten krbtgt-Geheimnisses siehe den Golden-Ticket-Angriff und seine krbtgt-Voraussetzung. Unterschiede zwischen dem Fälschen eines Diensttickets und der Wiederverwendung eines gestohlenen Tickets erläutern der Vergleich von Silver Ticket mit Pass-the-Ticket sowie der Vergleich von Pass-the-Hash, Overpass-the-Hash und Pass-the-Ticket. Die dortigen Angriffsbeschreibungen sind von den hier behandelten Entscheidungen zu Lebensdauer und Eindämmung getrennt.

Die drei Zeitgrenzen: TGT, Dienstticket und bestehende Verbindung

Das Ticket-Granting Ticket, kurz TGT, dient dazu, weitere Kerberos-Tickets zu erhalten. Das Dienstticket wird einem bestimmten Dienst vorgelegt. Die aufgebaute Verbindung hat anschließend ihre eigene Lebensdauer, die nicht durch die Dienstticket-Richtlinie definiert wird. Unterscheiden Sie die beiden Ticket-Zeitgrenzen von der Zeitgrenze der Verbindung; das Erneuerungsfenster ist eine zusätzliche Grenze für erneuerbare TGTs. Microsoft Learn: service ticket lifetime, RFC 4120 §2.3

Die folgenden Werte sind von Microsoft dokumentierte Standardwerte und keine Messungen Ihrer Domäne. Schlüssel und Einheiten sind in MS-GPSB §2.2.2, Kerberos Policy festgelegt.

Rechnen Sie Stunden und Minuten um, bevor Sie die Werte vergleichen. MS-GPSB nennt MaxTicketAge als zugehörige Obergrenze für MaxServiceAge; die Learn-Seite zu Diensttickets enthält einen Tippfehler mit einem Vergleich des Werts mit sich selbst, der nicht zur Betriebsregel werden sollte. Die Einstellung von fünf Minuten Zeitabweichung ist eine Toleranz und keine garantierte Verzögerung bei der Eindämmung. MS-GPSB, Microsoft Learn: clock synchronization tolerance

Sieben Tage Erneuerung bedeuten nicht, dass jedes TGT sieben Tage lang ununterbrochen gültig ist. Ein erneuerbares Ticket hat einen eigenen Ablaufzeitpunkt und eine endgültige Erneuerungsgrenze. Eine Verkürzung dieses Fensters hat auch Auswirkungen auf die Verfügbarkeit für Benutzer, die einen Domänencontroller nicht regelmäßig erreichen können. Microsoft Learn: user ticket renewal, RFC 4120 §2.3

Kontoprüfungen begrenzen neue Tickets, ohne ausgestellte Tickets automatisch ungültig zu machen

Windows prüft Konten bei Ticketanforderungen. MS-KILE §5.1.3 verlangt von KDCs in der Kontodomäne eine Kontoprüfung, wenn das vorgelegte TGT älter als 20 Minuten ist. MS-KILE §3.3.5.7.1 nennt die Bedingungen: Die Validierung der Kontorichtlinie muss aktiviert sein, und der KDC muss zur Kontodomäne des Benutzers gehören. Ein KDC in einer anderen Domäne kann diese Kontoprüfung nicht durchführen. Ein deaktiviertes Konto wird unter diesen Bedingungen mit KDC_ERR_CLIENT_REVOKED abgewiesen.

Hier geht es um die Verarbeitung einer Anforderung, nicht um einen Zeitgeber, der in Minute 20 jede Sitzung trennt. Die Prüfung begrenzt die anschließende TGS-Ausstellung und ruft kein bereits erhaltenes Dienstticket zurück. Auch für TGT-Anforderungen sind Kontorichtlinienprüfungen dokumentiert, einschließlich der Ablehnung deaktivierter Konten bei aktivierter Validierungsoption. MS-KILE §3.3.5.6.3

Das Protokoll beschreibt außerdem einen Widerrufsmechanismus. RFC 4120 §3.3.3.1 spezifiziert eine Hot-List, die beim Ticket-Granting Service geprüft wird und verhindert, dass widerrufene Tickets zum Erhalt weiterer Tickets verwendet werden. Davon unterscheidet die Spezifikation bereits erhaltene normale Tickets, die bis zu ihrem regulären Ablauf gültig bleiben. Die Spezifikation definiert keinen universellen Windows-Verwaltungsbefehl, um sämtliche Tickets eines Benutzers global zu widerrufen. RFC 4120 §3.3.3.1

Eine Änderung des Benutzerkennworts ersetzt bereits vorhandene Sitzungsschlüssel und Tickets nicht automatisch. Das ist eine kryptografische Schlussfolgerung aus dem TGS-Austausch: Das TGT wird mit dem Schlüssel des Ticket-Granting Service verarbeitet, und die Antwort verwendet einen Sitzungsschlüssel statt des langfristigen Geheimnisses des Clients. Daraus folgt keine Zusicherung, dass jede spätere Authentifizierung nach einer Zurücksetzung erfolgreich sein wird. RFC 4120 §§3.3.2–3.3.3

Das Entfernen aus Gruppen hat eine weitere Grenze. Die SIDs globaler und universeller Gruppen gelangen bei der erstmaligen TGT-Ausstellung in das PAC und werden in erneuerte TGTs kopiert. Die Erneuerung allein garantiert daher keine aktualisierte Gruppenmitgliedschaft. Domänenlokale Gruppen der Ressourcendomäne werden bei der Dienstticket-Ausstellung hinzugefügt; verallgemeinern Sie nicht, dass jede Gruppe beim ersten TGT festgeschrieben wird. MS-PAC §4.1.2.1, MS-KILE §3.3.5.7.3

Erkennung

1. Eine Zeitleiste aus Konto-, KDC- und Zielsystemprotokollen erstellen

Verwenden Sie die unten dokumentierten Windows-Ereignisse als Beleggrundlage. Die Korrelationsstrategie ist eine analytische Empfehlung auf Grundlage ihrer Felder und der oben beschriebenen Protokollgrenzen; es werden weder Laborergebnisse noch Erkennungsergebnisse aus dem Produktivbetrieb behauptet.

Ereignis 4768 erfasst nicht jeden TGT-Fehler: Microsoft dokumentiert, dass die Ergebniscodes 0x10 und 0x18 stattdessen Ereignis 4771 erzeugen. Beziehen Sie diese Fehler bei der Vorauthentifizierung in die Prüfung erfolgloser Anforderungen ein. Microsoft Learn: 4768 coverage

Verankern Sie den Vorfall am Ziel von 4725 und nicht am Administrator, der es deaktiviert hat. Ordnen Sie diese Identität normalisierten Namen in Kerberos-Ereignissen zu: 4769 bietet nicht dasselbe SID-Feld für den Zielbenutzer wie 4725. Bewahren Sie das Rohereignis und die Zuordnungsentscheidung auf. Verwenden Sie beim Zuordnen von 4624 und 4634 den Zielhost zusammen mit seiner Anmeldekennung; Microsoft dokumentiert, dass Anmelde-IDs nur zwischen Neustarts auf demselben Computer eindeutig sind. 4725 field definitions, 4769 field definitions, 4634 correlation limits

Priorisieren Sie erfolgreiche Ticketanforderungen oder neue Anmeldungen am Zielsystem nach der Deaktivierung, unerwartete Quellhosts und fortgesetzte Aktivität auf bekannten Verbindungen. Prüfen Sie den KDC der Kontodomäne, die Validierungseinstellung, das TGT-Alter und den zeitlichen Ablauf des Vorfalls, bevor Sie eine spätere erfolgreiche TGS-Anforderung interpretieren. Dies sind aus KILE abgeleitete Untersuchungsansätze und kein automatischer Beweis für Ticketdiebstahl. Fehlende Ereignisse hinterlassen eine Sichtbarkeitslücke; sie belegen nicht, dass eine Verbindung beendet wurde. Gleichen Sie die Zeitleiste mit der aktuellen Verbindungsübersicht des Ressourcenverantwortlichen und dem Auditprotokoll der Anwendung ab.

2. Die Richtlinie auf den betreffenden Domänencontrollern messen

Die folgenden Beispiele sind aus der Dokumentation übernommen und keine in einer AD-Umgebung ausgeführten Befehle. Verwenden Sie einen autorisierten Kontext, die erforderlichen Werkzeuge/Module und ein vorhandenes beschreibbares Berichtsverzeichnis. Das lokale gpresult-Beispiel richtet sich an den DC, auf dem es ausgeführt wird. Lesen Sie die Einstellungen der Kerberos Policy im Bericht zusammen mit dem Kontext der angewendeten GPOs. Microsoft Learn: gpresult

gpresult /scope computer /h C:\Temp\Kerberos-RSoP.html

Prüfen Sie die Einstellungen der Default Domain Policy mit dem folgenden Bericht. Ihre bekannte GUID ist auch der Suchschlüssel der Collector-Hilfsfunktion unter helpers/gpo_policy.go:11. Ein Bericht zu einer einzelnen GPO belegt für sich allein nicht die wirksame Richtlinie auf jedem DC. Microsoft Learn: Get-GPOReport

Get-GPOReport -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -ReportType XML

Prüfen Sie weitere GPOs, einschließlich ihrer Verknüpfungen und Filter, mit einem separaten Bericht. Wählen Sie die tatsächliche Domäne und den Server über die dokumentierten Parameter aus, wenn der aktuelle Kontext ungeeignet ist. Get-GPOReport

Get-GPOReport -All -ReportType XML

Get-ADDefaultDomainPasswordPolicy liest keine Kerberos-Richtlinie. Seine Ausgabe ist das Objekt der Standardkennwortrichtlinie der Domäne; verwenden Sie sie nicht als Nachweis dafür, dass MaxTicketAge oder MaxRenewAge geprüft wurden. Microsoft Learn: Get-ADDefaultDomainPasswordPolicy

3. Tatsächlich vorhandene Tickets auf Hosts im Untersuchungsumfang prüfen

Die folgenden getrennten Beispiele stammen aus Microsoft Learn: klist. Lesen Sie den Cache der aktuellen Sitzung:

klist

Prüfen Sie ihr TGT, einschließlich Endzeitpunkt und Erneuerungsgrenze:

klist tgt

Listen Sie lokale Anmeldesitzungen auf, bevor Sie annehmen, dass der Cache des aktuellen Benutzers den gesamten Host abdeckt:

klist sessions

Wählen Sie eine Anmeldesitzung mit -li aus, das den unteren Teil ihrer LUID angibt; verwenden Sie zusätzlich -lh, wenn der obere Teil ungleich null ist. 0x3e7 ist das von Microsoft dokumentierte Beispiel:

klist -li 0x3e7

Dokumentieren Sie Host, Sitzung, Erfassungszeitpunkt und Ticketzeiten. Diese Beobachtungen beziehen sich auf den ausgewählten Cache, nicht auf Ticketkopien auf einem anderen System. Halten Sie diesen Umfang in der Vorfallsdokumentation fest.

Abhilfemaßnahmen (Remediation)

1. Übermäßige Laufzeiten vor einem Vorfall reduzieren

Microsofts Leitfaden für Benutzertickets schlägt 4–10 Stunden vor; häufigere Anforderungen erhöhen die KDC-Last. Testen Sie den gewählten Wert anhand legitimer Arbeitsabläufe. Konfigurieren Sie die Kerberos-Einstellungen der Domäne unter Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Microsoft Learn: user ticket lifetime

Für die gezielte Vorbereitung bei privilegierten Konten prüfen Sie Authentifizierungsrichtlinien und Silos für kürzere Tier-0-TGTs und Gerätebeschränkungen. Trennen Sie diese Bereitstellungsentscheidung von einer Cache-Bereinigung im Notfall.

Die Verkürzung einer GPO-Lebensdauer ist keine rückwirkende Löschung von Tickets. Diese Schlussfolgerung ergibt sich aus den eigenen Gültigkeitszeiten der Tickets und den oben dokumentierten lokalen Cache-Vorgängen. Wenden Sie die Änderung an und prüfen Sie neu ausgestellte Tickets; bewahren Sie Belege zu bestehenden Tickets getrennt auf. RFC 4120, klist

2. Identität und Ressourcen während des Vorfalls eindämmen

Deaktivieren Sie die betroffene Identität und setzen Sie sie gegebenenfalls für künftige Authentifizierungen zurück. Isolieren Sie anschließend kompromittierte Hosts und erfassen Sie die Verbindungen dieser Identität. Isolation und ressourcenseitige Verbindungsbeendigung sind betriebliche Empfehlungen, die aus dem dokumentierten Fortbestehen authentifizierter Verbindungen abgeleitet werden, und keine universelle Microsoft-Wiederherstellungsprozedur. Weisen Sie jedem betroffenen Host und Dienst einen Verantwortlichen zu und dokumentieren Sie, welchen Zugriffsweg jede Maßnahme abdeckt. MS-KILE TGT account checks, Microsoft Learn: service ticket lifetime

Löschen Sie auf einem Host unter Ihrer Kontrolle die Tickets der aktuellen Sitzung mit diesem dokumentierten Befehl:

klist purge

Für eine ausgewählte Sitzung ist Microsofts Beispiel ein separater Vorgang:

klist purge -li 0x3e7

Ohne LUID-Auswahl gilt die Löschung für die aktuell angemeldete Sitzung. Sie erreicht weder andere Caches noch an andere Orte kopierte Tickets. Schließen Sie die betreffenden Verbindungen und veranlassen Sie im Rahmen der Reaktion eine erneute Authentifizierung. Die Löschung allein beweist nicht, dass jede Anwendungsverbindung beendet wurde. klist, service-ticket connection boundary

Der verantwortliche Betreiber kann einen Host oder Dienst neu starten, um lokale Kontexte zu schließen, wenn einzelne Sitzungen nicht kontrolliert werden können. Behandeln Sie dies als lokale betriebliche Entscheidung und nicht als domänenweiten Widerruf oder als Beweis für die vollständige Beseitigung der Bedrohung. Hier wird kein universeller Neustartbefehl vorgeschrieben.

3. krbtgt-Wiederherstellung der Kompromittierung dieses Geheimnisses vorbehalten

Die gewöhnliche Deaktivierung eines Benutzers ist kein Grund, krbtgt zweimal zu rotieren. Ist dieses Geheimnis kompromittiert, folgen Sie der Wiederherstellungsplanung für die Domäne. Microsofts Prozedur zur Gesamtstrukturwiederherstellung verlangt zwei Zurücksetzungen, weil der Kennwortverlauf zwei Kennwörter speichert. Warten Sie bei den Standardwerten 10 Stunden zwischen den Zurücksetzungen; wurden die maximalen Lebensdauern geändert, muss die Mindestwartezeit größer als die konfigurierte Lebensdauer sein. Prüfen Sie Replikation und DC-Umfang, bevor Sie den zweiten Vorgang planen. Die zitierte Prozedur gilt für beschreibbare DCs und nicht für RODC-Konten vom Typ krbtgt_number. Microsoft Learn: reset the krbtgt password

Schließen Sie daraus nicht, dass diese Zurücksetzungen jedes ausgestellte Dienstticket oder jede bestehende Verbindung zerstören. Deren Dienstschlüssel und bestehende Kontexte bilden getrennte Grenzen. Prüfen Sie neue Zugriffsversuche, lokale Caches und zuvor offene Verbindungen unabhängig voneinander; dokumentieren Sie die tatsächlichen Ergebnisse, wenn das Reaktionsteam diese Prüfungen durchführt. RFC 4120 §3.3, Microsoft Learn: service ticket lifetime

Wie EtcSec dies erkennt

Der etc-collector von EtcSec identifiziert übermäßig lange konfigurierte Laufzeiten anhand dreier realer Detektor-IDs. Die folgenden Aussagen stammen aus der statischen Prüfung ihrer Detect()-Implementierungen und nicht aus einem Auditlauf gegen die Domäne eines Kunden. Die folgenden Pfade sind relativ zu public/internal/audit/detectors/ad/ im Collector-Quellcode.

Die Vergleiche sind strikt: 10 Stunden und 7 Tage lösen diese Befunde nicht aus. Die zusammengefasste Prüfung überschneidet sich mit den beiden spezialisierten Prüfungen; es sind zwei Laufzeitprüfungen und eine zusammengefasste Prüfung, keine drei unabhängigen Eindämmungsfunktionen. Sie erkennen keinen Ticketdiebstahl, beenden keine Sitzungen und implementieren keinen Widerruf von Benutzertickets.

Die primären Eingaben sind Kerberos-Einstellungen, die aus SYSVOL GptTmpl.inf unter public/internal/providers/smb/gptmpl_parser.go:221–227 ausgelesen werden. Die Hilfsfunktion public/internal/audit/helpers/gpo_policy.go:42–54 bevorzugt die Default Domain Policy und danach eine andere verfügbare GPO mit Kerberos-Einstellungen. Sie berechnet keine vollständige RSoP-Rangfolge. Vergleichen Sie den Befund mit der wirksamen Richtlinie des betreffenden DC und den beobachteten Tickets, bevor Sie die Abhilfe als abgeschlossen erklären.

Die spezialisierten Detektoren wählen positive Werte aus und enthalten Rückfallmechanismen auf DomainInfo. MaxTicketAge=0 wird vom Laufzeitvergleich nicht gemeldet, obwohl Microsoft diesen Wert als unbegrenzte Gültigkeit dokumentiert. Fehlende Eingaben oder Nullwerte können außerdem zu Count=0 führen. Die zusammengefasste Prüfung gibt sofort Count=0 zurück, wenn DomainInfo nil ist, auch wenn SYSVOL-Richtliniendaten vorliegen (weak-kerberos-policy.go:25–33). Ihre Details hängen von IncludeDetails ab. Keiner dieser drei Vergleiche prüft Dienstticket-Lebensdauer, Zeitabweichung oder das Flag zur Kontovalidierung.

Die abschließende Vorfallsdokumentation sollte konfigurierte Laufzeiten mit Belegen aus Ticket-Caches, Ergebnissen von KDC-Anforderungen und ressourcenseitigen Verbindungsprüfungen verknüpfen. Diese Belege sind erforderlich, um eine korrigierte Richtlinie von tatsächlich beendetem Zugriff zu unterscheiden.