Moin @all.
vielleicht habt ihr den Begriff GoldenTicket ja schon in meiner Videoserie “Anatomie eines Hacks” gesehen, eventuell kam er euch auch schon mal in einem anderen Kontext unter. Aber was ist das eigentlich? Und viel interessanter: Wie und warum funktioniert das? Diese Fragen möchte ich in diesem kleinen Beitrag mit unterhaltsamen Animationen klären.
1) Kerberos – ein Überblick
2) Video 1: eine Clientanmeldung an einem DomainController
3) Video 2: eine Benutzeranmeldung an einem DomainController
4) Video 3: eine Ressourcenanmeldung eines Benutzers an einem Service
Diesen Betrag habe ich in 4 Teile gegliedert. Der erste zeigt, wie ein GoldenTicket erstellt wird. Der zweite veranschaulicht die Verwendung. Im dritten gibt es eine LiveDemo und zuletzt zeige ich die Schutzmöglichkeiten auf. Los gehts!
- Nach einer erfolgreichen Anmeldung an einem DomainController (durch Benutzername und Kennwort) erhält eine Identität einen vom DC verschlüsselten Sitzungsschlüssel. Die Verschlüsselung ist symmetrisch: es kann also der gleiche Schlüssel zum entschlüsseln verwendet werden.
- Diesen Schlüssel haben alle DomainController
- Verwendet ein Benutzer das TGT bei einem TGS-Request, dann kann der angesprochene DomainController den Sitzungsschlüssel nur dann erfolgreich entschlüsseln, wenn das TGT von einem vertrauenswürdigen DomainController zuvor verschlüsselt wurde. Der passende Schlüssel ist also die Echtheitsbestätigung der Identität!
Im TGT steht zusätzlich drin, wer jemand ist und in welchen Sicherheitsgruppen er Mitglied ist. Und da es wohl von einem DomainController ausgestellt wurde, prüft ein anderer DomainController nicht mehr nach, ob die Rechte noch stimmen.
Die Sicherheit im Active Directory steht und fällt also mit dem geheimen Masterkey, den alle DomainController verwenden. Wenn ein Angreifer diesen erbeutet, dann kann er alles fälschen:
Ist der KRBTGT-Masterkey der DomainController einmal kompromittiert, dann kann der Angreifer mit dem GoldenTicket auf alle Services im Active Directory zugreifen:
Soweit zur Theorie…
… kommen wir zur Praxis. Im ersten Video zeige ich, wie man mit der Konsolenanwendung Mimikatz ein GoldenTicket erstellt. Natürlich ist das Szenario dabei schon sehr weit hergeholt: ein Angreifer ist via RDP auf einem DomainController als Administrator angemeldet und startet dort lokal die Anwendung Mimikatz). Dennoch sind die relevanten Komponenten gut sichtbar:
Im 2. Video möchte ich eine realere Variante darstellen:
- Der Angreifer kontrolliert mit einer ReverseShell einen Memberserver, auf dem ein DomainAdmin angemeldet ist.
- Über diesen Server baut er einen PowerShell-Tunnel zu einem DomainController auf und startet Mimikatz dateilos im Arbeitsspeicher.
- Das GoldenTicket wird dann auf einem StandaloneSystem für ein PowerShell-Remoting genutzt.
Schaut genau hin – es ist wirklich nicht schwer:
Nach der brisanten Demonstration stellt sich nun die Frage: Wie schützen wir unser System vor dieser Attacke? Es ist eigentlich recht einfach: verhaltet euch wie beim Umgang mit anderen Passworten:
- Schützt das System, auf dem eurer Passwort gespeichert ist
- Ändert das Passwort regelmäßig
Ihr seid hoffentlich nicht überrascht, aber das ist alles!
Inhaltsverzeichnis
Schützt das System, auf dem eurer Passwort gespeichert ist
Ein Angreifer darf einfach keinen Zugriff auf euren DomainController bekommen. Somit sind natürlich die Benutzerkonten der DomainAdmins selber schutzwürdig. Diese dürfen niemals auf Clients oder anderen Systemen mit Internetzugriff verwendet werden! Eine technische Möglichkeit zur Isolation der DomainController zeige ich in diesem Blogeintrag zum Thema SecurityScopes
Natürlich müssen die DomainController selbst sicher betrieben werden. Dazu gehört auch eine Isolation auf Netzwerkebene. Ebenso sollte ein DomainController keine anderen Rollen ausführen als AD und DNS.
Bitte denkt auch an die Datensicherung. Wenn ein Angreifer euer Backup-System kompromittiert, dann hat er auch Zugriff auf die Daten des ActiveDirectory!
Ändert das Passwort regelmäßig
Das Passwort des Users KRBTGT wird nicht automatisch geändert. Es ist also im WorstCase so alt wie eure Domain! Warum Microsoft das so implementiert hat ist schnell erklärt: haben 2 DomainController unterschiedliche KRBTGT-Passworte, dann werden auch die damit verschlüsselten TGT’s nicht korrekt entschlüsselt. Und damit bricht das Authentifizierungsverfahren Kerberos kurzfristig zusammen. Genau diesen Fall gibt es natürlich bei einer Änderung, da diese wie jede andere auch erst einmal auf alle DomainController repliziert werden muss.
Es gibt aber eine Absicherung: alle DomainController merken sich das aktuelle Kennwort und das vorherige! Ein neues Kennwort wird also keine Probleme verursachen. Wichtig ist nur, dass innerhalb der Gültigkeit der TGT’s (und das sind normalerweise 10 Stunden) keine 2 Kennwortänderungen für den User KRBTGT ausgeführt werden.
Für die Änderung gibt es in der ScriptGallery von Microsoft einen Ansatz: https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51/view/Discussions Das Script hat 3 Phasen:
- Informationen anzeigen
- Änderung und Replikation simulieren
- Änderung durchführen und SofortReplikation startet
Es ist recht einfach anzuwenden. Leider werden die Replikationsergebnisse mit nur auf englisch ausgewertet. Eine Ausführung auf einem deutschen DomainController wird ohne Anpassung nicht funktionieren.
Ein Kennwortwechsel sollte regelmäßig (z.B. alle 90 Tage) 2x im Abstand von 1 Tag durchgeführt werden.
Monitoring
Kann man denn in den Ereignisprotokollen auf den DomainControllern die Erstellung oder die Verwendung der GoldenTickets sehen? Leider nein, denn die TGS-Requests sehen aus wie alle anderen.
Microsoft wirbt zwar beim Produkt “Microsoft ATA (Advanced Thread Analysis)” mit der Erkennung von GoldenTickets…
…aber in keinem meiner Tests hat die Erkennung funktioniert! 🙁
Stay tuned!