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

PS C:\temp> 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 kan 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 kommen Sie dann eh nicht vorbei.

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 hoffen, 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.

Hier hat Microsoft mittlerweile ein Skript bereit gestellt, welches den Wechsel des Tickets in drei Phasen vorbereitet.

Reset the krbtgt account password/keys
https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51

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.

Ich interpretiere das so, dass auch bei Microsoft neben einem Monitoring von Zugriffen diese sensible Funktion vermutlich auch manuell durchgeführt wird.

Weitere Links