KRBTGT Key Rollover

Wir nutzen wie selbstverständlich verschiedene Dienstkonten im Active Directory und wissen auch, dass wir die Zugriffe darauf eigentlich überwachen sollten. Das BSI ist zwar mittlerweile davon abgekommen, regelmäßige Kennwortänderungen für Anwender zu fordern, weil dies die Sicherheit nicht wirklich verbessert. Aber bei Dienstkonten müssen wir schon noch genauer hinschauen, insbesondere wenn die Dienstkonten sehr umfangreiche Berechtigungen haben. Exchange 2007 und neuer nutzt gar kein Dienstkonto mehr aber viele andere Dienste und auch das "Kerberos Distribution Center (KDC)" nutzen Dienstkonten.

Dieses Konto ist sehr sensibel und wenn es bekannt würde, könnte jemand sich ein "Golden Ticket" ausstellen, mit der jede andere Rolle einnehmen kann.

Hinweis
Verwechseln Sie das KRBTGT-Konto auf dieser Seite nicht mit dem Konto AZUREADSSOACC, welches bei Office 365 mit Seamless Single Sign On genutzt und ebenfalls zyklisch geändert werden sollte.

Weckruf - Golden Ticket

Die meisten Firmen merken aber gar nicht, dass das KRBTGT-Konto vielleicht kompromittiert wurde. Ein Angreifer mit diesem Kennwort sich auch schön verborgen bleiben, denn er hat den Master-Key für ihre Active Directory. Insofern ist die Empfehlung von Microsoft hier schon ernst zu nehmen, dieses Kennwort ab und an zu ändern.

Angriffe können aber auch über schwache Verschlüsselungsverfahren erfolgen. Hier ist eine Überwachung der Zugriffe und "Versuche" wichtig. Wenn Sie z.B. Defender ATP einsetzen, dann protokolliert diese Komponenten die verwendeten Verfahren und alarmiert, wenn ein Downgrade versucht wird.

So einen Event sollten Sie dann schon etwas genauer untersuchen, welche Benutzer auf welchem System davon betroffen sind.

Mitigating Pass-the-Hash and Other Credential Theft, version 2
http://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf

Protection from Kerberos Golden Ticket - Mitigating pass the ticket on Active Directory
http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf

KRBTGT-Konto

Das KRBTGT-Konto gibt es in jeder Active Directory-Domäne und liegt normalerweise in der OU "Users". Per PowerShell können Sie schnell sehen, wann das Kennwort das letzte Mal aktualisiert wurde:

Get-ADUser  krbtgt -Properties PasswordLastSet,*creat*

DistinguishedName : CN=krbtgt,CN=Users,DC=msxfaq,DC=de
Enabled           : False
GivenName         :
Name              : krbtgt
ObjectClass       : user
PasswordLastSet   : 21.07.2019 15:10:43
SamAccountName    : krbtgt
SID               : S-1-5-21-12345678-12345678-12345678-502
Surname           :
UserPrincipalName :

Durch den Wechsel des Forest Functional Level auf Windows 2008 wird das Kennwort einmal geändert, damit es AES-verschlüsselt gespeichert wird. Mein Forest gab es natürlich schon länger.

The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory. KRBTGT is also the security principal name used by the KDC for a Windows Server domain ...

...The TGT password of the KRBTGT account is known only by the Kerberos service. ..

Quelle: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#krbtgt-account

Alle KDCs nutzen also dieses Konto um Tickets auszustellen und zu verifizieren. Wenn ich also als Angreifer dieses Kennwort kenne, dann kann ich mir selbst entsprechende Tickets ausstellen, die von allen KDCs als "gültig" angesehen werden.

KRBTGT-Kontenpflege

Auf der gleichen Seite gibt es aber auch weitere Hinweise zur Pflege dieses Kontos:

A strong password is assigned to the KRBTGT account automatically. Be sure that you change the password on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. 

On occasion, the KRBTGT account password requires a reset, for example, when an attempt to change the password on the KRBTGT account fails. In order to resolve this issue, you reset the KRBTGT user account password twice by using Active Directory Users and Computers. You must reset the password twice because the KRBTGT account stores only two of the most recent passwords in the password history.

Resetting the password requires you either to be a member of the Domain Admins group, or to have been delegated with the appropriate authority. 

Quelle: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#krbtgt-account

Nur gibt es keinen Automatismus und die wenigsten Administratoren habe das Kennwort schon je geändert. Es könnte ja auch nach hintern losgehen und die Funktion stören. Und vielleicht ist das alles ja gar nicht so schlimm.

Key Rollover

Ich habe mich natürlich aufgrund der Meldung des Defender ATP noch mal mit dem Thema beschäftigt und einige Fakten zusammen getragen:

  • Der KDC prüft Tickets anhand des aktuellen und des vorherigen Kennworts
    Wenn ich das Kennwort also einmalig ändere, dann funktioniert alles weiter, da neue Tickets mit dem neuen Kennwort signiert werden und früher ausgestellte Tickets weiterhin gültig sind, bis die Tickets ablaufen. (ca. 2-12 Stunden)
  • Wenn alles Tickets abgelaufen sind, dann kann ich nochmal das Kennwort ändern
    Die Clients haben ja mittlerweile schon neue Tickets mit dem neuen Kennwort und ich kann noch mal ein Rollover machen damit das vorvorherige Kennwort verschwunden ist. Damit hätte dann auch ein Angreifer keinen Eingang mehr, da das aktuelle und das vorherige Kennwort geändert sind. Das Problem ist dabei aber die Zeit dazwischen, wenn ich ein neues Kennwort habe aber das alte eben auch noch gilt. Ein Angreifer könnte sich dann auch als "Domain Controller" ausgeben und sie so auch das neue Kennwort beschaffen.
  • Einbruch bedeutet 2x ändern
    Wenn ich also den Verdacht habe, dass jemand das KRBTGT-Kennwort erhalten hat, dann darf ich nicht warten, sondern muss das Kennwort zweimal kurz hintereinander ändern und hoffen, dass der Angreifer keine Hintertür hat, z.B. ein Admin-Konto oder ein privilegiertes Computerkonto o.ä. Auch der erste Weg das Kennwort überhaupt zu erhalten, muss natürlich geschlossen worden sein. Also ist das eher ein Shutdown des Netzwerks und kontrolliertes Starten. Wobei die Clients nach einem zweimaligen Kennwortwechsel mit ihren noch zeitlich gültigen Tickets dennoch keinen Zugriff mehr erhalten. Um einen Neustart der Clients bzw. der Dienste oder ein Purge der Kerberos Tickets für alle angemeldeten Benutzer kommen Sie dann eh nicht vorbei. Für das "Local System"-Kkonto hilft ein "klist -li 0x3e7 purge" als Admin

Es ist aber unkritisch, das Kennwort ab und an zu ändern. Sie können das ganz einfach über "Active Directory Benutzer und Computer" machen und prüfen, dass die AD-Replikation funktioniert und alle KDCs das neue Kennwort möglichst schnell erhalten. Sonst könnte es ja passieren, dass ein Client von einem schon aktualisierten DC ein Ticket bekommt, um damit auf einen Server zugreifen zu können, der noch mit einem DC mit dem alten Kennwort kommuniziert. Dann wäre das Ticket ungültig.

Details aus einem Forum

Auf https://docs.microsoft.com/en-us/answers/questions/87978/reset-krbtgt-password.html gibt es eine ausführliche Antwort von "FanFan-MSFT" (https://docs.microsoft.com/en-us/users/fanfan-msft/), die ich als Archiv hier ausnahmeweise komplett zitiere:

FanFan-MSFT answered · Sep 08 2020 at 3:44 AM BEST ANSWERACCEPTED ANSWER
Hi,

Before going further, i would like to explain why we need to reset the password 2 times :
The Kerberos TGT is encrypted and signed by the KRBTGT account. This means that anyone can create a valid Kerberos TGT if they have the KRBTGT password hash. Furthermore, despite the Active Directory domain policy for Kerberos ticket lifetime, the KDC trusts the TGT, so the custom ticket can include a custom ticket lifetime.
If the krbtgt account is compromised, attackers can create valid Kerberos Ticket Granting Tickets (TGT).It attempts to decrypt with the current password and if that fails, it attempts again with the previous one (assuming it has it).So the password must be changed twice to effectively remove the password history. Changing once, waiting for replication to complete and changing again reduces the risk of issues. Changing twice in rapid succession forces clients to re-authenticate (including application services) but is desired if a compromise is suspected.

For your questions:
1,There is no need to wait 10 hours, only need to wait for the replication.There are Two Change Scenarios as following for different situations (both you mentioned):

If there are any chance that the KRBTGT account is compromised.
Breach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

Maintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).

2, For your second question:From my personal understanding, if it is a regular maintenance it is totally ok to reset the password at the nest day to wait for the replication if you have multi-sites.

3, As mentioned above,changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs.
Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

So before changing the password, i would recommend you to check the replication status before perform this task, to be sure that the new passwords will be replicated on all domain controllers.Following command :
Repadmin /showrepl >C:\repl.txt
Repadmin /showreps *
Repadmin /syncall /APeD

Kerberos Skript

Microsoft hat für die Unterstützung der Umstellung ein Skript bereit gestellt, welches den Wechsel des Tickets in drei Phasen vorbereitet.

Frühere Version
TechNet Gallery wurde abgeschaltet. https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
Sie finden das Skript auf dem GIT https://gist.GitHub.com/mubix/fd0c89ec021f70023695
Ich habe mir hier (Reset-KrbtgtKeyInteractive.ps1) die Version 1.4 gesichert. Der Verlust der TechNet Gallery zeigt doch immer mal wieder, wie schnell wichtige Tools verloren gehen könnten.

New-KrbtgtKeys.ps1
https://github.com/microsoft/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1
Neuere und deutlich umfangreichere Version

Das Skript "Reset-KrbtgtKeyInteractive.ps1" prüft "Strings" und funktioniert daher nur auf englischen Servern. Für Deutsch sind zwei Änderungen erforderlich:
Zeile 32: If ($RpcPingResult -like "*abgeschlossen*")
Zeile 54: If ($RepAdminResult -like "*erfolgreich*")

Schritt Phase Beschreibung

1

Information

Das Skript liest und prüft nur, ob alle Voraussetzungen erfüllt sind.

2

Simulation

Das Skript führt neben den Schritten aus Phase 1 zusätzlich noch eine einmalige Replikation aus. Es weist also alle DCs an, die vom PDC-Emulator nun das aktuelle, aber immer noch unveränderte Kennwort zu replizieren.

3

Reset

Erst hier wird das Kennwort des KDC-Service auf dem PDC-Emulator geändert und dann die Replikation ausgeführt.

Das Skript akzeptiert keine Parameter o.ä. sondern fordert Sie als Administrator zur Auswahl auf.

Das Skript macht ein Update des KRBTGT-Konto-Kennworts sicherer, da es die Replikation forciert und verschiedene Voraussetzungen prüft. Aber es ist kein "Schutz" gegen "Golden Ticket"-Angriffe.

Hinweis:
Das PowerShell-Script startet Programme wie "RPCPING" und "REPAMIN" und wertet die Bildschirmausgabe aus. Dies funktioniert nur mit englischen Servers. Wenn ihr Server eine andere Sprache hat, dann müssen Sie das PS1-Skript anpassen.

Weitere Links