netzwerkdude
Goto Top

Krbtgt-Kennwort zurücksetzen in real life szenario

Abend,

Falls man den Verdacht hat das sich jemand ein Kerberos Golden Ticket vom Domaincontroller gezogen hat, wird Empfohlen das man das Kennwort des Krbtgt users 2x ändert.
Soweit sogut - wie macht man das aber in der Praxis?

Szenario1: slow variante
Ich ändere das Kennwort 1x am Tag 1 und warte bis Tag 2 (bis sich alle Konten ein neuen TGT gezogen haben das vom neuen Kennwort beglaubigt ist) - und an Tag 2 ändere ich es ein zweites mal.
Gefahr: Das Golden ticket ist bis zur Änderung an Tag 2 ebenfalls gültig - und es könnte in dieser Zeitspanne zw. Tag1 und Tag2 ein neuen Goldenes Ticket gezogen werden.

Szenario2: schnell und schmerzvoll
Ich ändere das Kennwort schnell 2x hintereinander - und alle TGTs aller Konten werden instant ungültig - die Frage ist: Sind alle beteiligten Systeme schlau genug das festzustellen und sich ein neues anzufodern? Also wie reagiert W7, W10, irgendwelche embedded Sachen wie Netzwerkscanner die ScanToSMB machen oder sonstige Linuxe?

MFG
N-Dude

Content-Key: 441338

Url: https://administrator.de/contentid/441338

Ausgedruckt am: 02.10.2022 um 06:10 Uhr

Mitglied: Dani
Lösung Dani 17.04.2019 um 20:27:40 Uhr
Goto Top
Mitglied: NetzwerkDude
NetzwerkDude 18.04.2019 um 08:14:28 Uhr
Goto Top
Okay, dann wird es die slow variante
Mitglied: DerWoWusste
DerWoWusste 18.04.2019 um 10:12:21 Uhr
Goto Top
Hi.

Nimm dieses Skript und lies dir die Hinweise durch: https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
Dann teste es aus. Ich meine, du kannst es gleich nach dem ersten Mal ein zweites Mal ändern, nachdem Dir angezeigt wurde, dass die Replikation zwischen den DCs nach dem ersten ändern stattgefunden hat.
Mitglied: 1st1
1st1 18.04.2019 aktualisiert um 10:20:43 Uhr
Goto Top
Wenn du das Krbtgt-Passwort 2x schnell hintereinander änderst, verlieren alle gerade aktive Server-Verbindungen ihre Gültigkeit, das betrifft Shares, RDP-Sitzungen usw. Bis die Nutzer diese wieder aufbauen können, müssen sie die maximale Ticketgültigkeit (Default 10 Stunden) abwarten oder man muss die betroffenen Server rebooten, evtl. auch die betroffenen Clients (zumindestens ab und wieder anmelden). Ich denke, damit tut man sich keinen Gefallen. Die Empfehlung besagt, für den 2. Passwortwechsel die Zeit der in der Domäne eingestellten Ticketgültigkeit plus etwas Zeit, um sicher zu sein, dass die AD-Replikation komplett durch ist, zu warten. Sprich mindestens 10+2=12 Stunden. Ich habe gelesen, dass in manchen Umgebungen der doppelte Krbtgt-PW-Reset einmal monatlich automatisch durchgeführt wird, habe aber noch nicht rausgefunden, wie man das von MS dafür zum PW-Reset gestellte Script dafür verwendet, das funktioniert nur interaktiv. Dann würde ich das hier auch implementieren.

Damit der Angreifer sein Golden Ticket erneuert, muss er erstmal mitbekommen, dass das Krbtgt-Passwort geändert wurde...
Mitglied: DerWoWusste
DerWoWusste 18.04.2019 um 10:26:27 Uhr
Goto Top
Bis die Nutzer diese wieder aufbauen können, müssen sie die maximale Ticketgültigkeit (Default 10 Stunden) abwarten
Das glaube ich kaum. Aber ich werde es gern über die Ostertage einmal (gefahrlos) ausprobieren und berichten.
Mitglied: NetzwerkDude
NetzwerkDude 18.04.2019 um 10:30:17 Uhr
Goto Top
Die Frage ist was der Autor meint mit
"IMPORTANT NOTE: This script currently only supports running in English language. Thanks for your patience and understanding."
Gehts um das Skript selbst das die Hinweise in Englisch sind, oder darum das es nur auf englischen OSen läuft?
Mitglied: DerWoWusste
DerWoWusste 18.04.2019 um 10:42:31 Uhr
Goto Top
Unsere DCs sind englisch, aber dennoch sehe ich keinen Grund, dass es nicht auf einem deutschen alles tut, was es soll. Der Author meint vermutlich nur die Hinweise, welche er nicht für alle Sprachen übersetzt hat.
Mitglied: 139374
139374 18.04.2019 um 14:27:11 Uhr
Goto Top
Zitat von @DerWoWusste:

Bis die Nutzer diese wieder aufbauen können, müssen sie die maximale Ticketgültigkeit (Default 10 Stunden) abwarten
Das glaube ich kaum. Aber ich werde es gern über die Ostertage einmal (gefahrlos) ausprobieren und berichten.
Ich auch nicht. Testweise hier nachgestellt und in Wireshark kontrolliert. Nach einem Kerberos-Error Paket das der Server dem Client schickt, wie es die Spezifikation vorsieht wenn das Ticket ungültig ist, fragt der Client automatisch ein neues Ticket an.
Mitglied: DerWoWusste
Lösung DerWoWusste 19.04.2019 aktualisiert um 11:29:34 Uhr
Goto Top
So, Test durchgeführt, 2x das Kennwort innerhalb von 2 Minuten geändert (vorher Replikationsdauer getestet, sie ist sehr kurz).

Resultat: zunächst kommt mal eine Warnung, dies zu tun - quasi das, was @1st1 geschrieben hat: wenn man nicht die Kerberos Ticket Lifetime (default: 10 Stunden) vor der zweiten Änderung abwartet, dann kann es zu "major disruptions" kommen. Und die sehen dann so aus:

Outlook mit Exchange: kein Problem.
Filesharezugriff: kein Problem
Sharepointzugriff (Kerberos-gesichert): Problem. Lösung: Bildschirm sperren und wieder entsperren für ein neues Kerberos Ticket
RDP-Zugriff: Problem. Lösung: wenn man nicht 10 Stunden warten möchte, muss der Zielserver neu gebootet werden, dieses Shutdown -f -r -t 0 Kommando abzusetzen, funktionierte via psexec problemlos. Alternativlösung: Zugriff via IP, denn dann wird Kerberos nicht benutzt.

Frohe Ostern.
Mitglied: NetzwerkDude
NetzwerkDude 20.04.2019 um 11:12:54 Uhr
Goto Top
Besten Dank für testen und den Erfahrungsbericht!