10
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 441338
Url: https://administrator.de/contentid/441338
Printed on: April 19, 2024 at 10:04 o'clock
10 Comments
Latest comment
Moin,
meiner Meinung nach gibt es nur ein Szenario:
https://itworldjd.wordpress.com/tag/krbtgt-password-reset/
https://social.technet.microsoft.com/Forums/windows/en-US/53033b4d-766b- ...
https://social.technet.microsoft.com/Forums/en-US/465e13d8-dc8b-4cf4-9bd ...
Gruß,
Dani
meiner Meinung nach gibt es nur ein Szenario:
https://itworldjd.wordpress.com/tag/krbtgt-password-reset/
https://social.technet.microsoft.com/Forums/windows/en-US/53033b4d-766b- ...
https://social.technet.microsoft.com/Forums/en-US/465e13d8-dc8b-4cf4-9bd ...
Gruß,
Dani
Okay, dann wird es die slow variante
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.
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.
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...
Damit der Angreifer sein Golden Ticket erneuert, muss er erstmal mitbekommen, dass das Krbtgt-Passwort geändert wurde...
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.
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?
"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?
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.
Zitat von @DerWoWusste:
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.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.
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.
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.
1
Besten Dank für testen und den Erfahrungsbericht!
