Silver Ticket (Kerberos-Angriff)

Ein Silver Ticket ist ein gefälschtes Ticket Granting Service (TGS)-Ticket im Kerberos-Protokoll. Im Gegensatz zum Golden Ticket, das das gesamte Domänenvertrauen untergräbt, ist ein Silver Ticket auf einen einzigen Dienst beschränkt — etwa eine Dateifreigabe, einen SQL-Server oder einen Webdienst. Seine eigentliche Gefahr liegt nicht in der Reichweite, sondern in der Unauffälligkeit: Der Angreifer kommuniziert bei der Verwendung des gefälschten Tickets nie mit dem Key Distribution Center (KDC), sodass auf den Domain Controllern keine Spuren entstehen.

Wie funktioniert der Angriff?

Kerberos unterscheidet zwei Ticket-Typen: Das Ticket Granting Ticket (TGT) legitimiert einen Benutzer gegenüber dem KDC und wird mit dem krbtgt-Hash verschlüsselt. Das Service Ticket (TGS) legitimiert einen Benutzer gegenüber einem bestimmten Dienst und wird mit dem Passwort-Hash des jeweiligen Service Accounts verschlüsselt. Genau hier setzt der Silver-Ticket-Angriff an.

Gelangt ein Angreifer an den NTLM-Hash eines Service Accounts — etwa durch Kerberoasting, durch Extraktion aus dem LSASS-Prozess oder über eine Credential-Dump-Technik — kann er ein TGS für den zugehörigen Dienst vollständig selbst fälschen. Das gefälschte Ticket enthält frei wählbare Benutzerinformationen: Benutzername, Gruppen-SIDs, Berechtigungen und Gültigkeitsdauer. Da das Ticket korrekt mit dem Service-Account-Hash signiert ist, akzeptiert der Zieldienst es als authentisch — ohne je das KDC zu befragen.

Der Ablauf in der Praxis sieht typischerweise so aus: Der Angreifer extrahiert zunächst den Passwort-Hash des Ziel-Service-Accounts, ermittelt den vollqualifizierten Dienstnamen (Service Principal Name, SPN) sowie die Domänen-SID aus dem Active Directory. Mit Tools wie Mimikatz (kerberos::golden /ptt mit Service-Hash statt KRBTGT), Rubeus (silver) oder Impacket (ticketer.py) erstellt er anschließend das gefälschte TGS und übergibt es direkt an den Zieldienst — ohne Netzwerkverkehr zum Domain Controller.

Abgrenzung zum Golden Ticket

Der Unterschied zwischen Silver Ticket und Golden Ticket ist strukturell: Ein Golden Ticket fälscht das TGT mit dem krbtgt-Hash und gewährt damit Zugriff auf beliebige Dienste der gesamten Domäne. Ein Silver Ticket fälscht das TGS mit dem Hash eines einzelnen Service Accounts und beschränkt sich auf den Dienst, für den dieser Account zuständig ist.

Diese Einschränkung hat jedoch eine Kehrseite, die in der Praxis oft unterschätzt wird: Ein einzelnes Silver Ticket kann durchaus ausreichend sein, um kritische Angriffsziele zu erreichen. Ein gefälschtes CIFS-Ticket für den Fileserver eines Domain Controllers erlaubt es, das gesamte Dateisystem dieses Systems zu durchsuchen. Ein SQL-Ticket für einen zentralen Datenbankserver ermöglicht vollständigen Datenzugriff. Entscheidend ist zudem, dass Silver Tickets keine KDC-Kommunikation erfordern — während ein Golden Ticket immer noch Anfragen erzeugt, die ein SIEM potentiell erkennen kann, hinterlässt ein Silver Ticket auf den Domain Controllern schlicht keine Spuren.

Typische Angriffsziele

Die Wahl des Zieldienstes bestimmt die Schadwirkung eines Silver Tickets. In der Praxis werden vor allem folgende Service-Typen missbraucht:

CIFS (Common Internet File System) ist das häufigste Ziel: Alle Windows-Dateifreigaben nutzen dieses Protokoll. Ein CIFS-Silver-Ticket erlaubt nicht nur lesenden Zugriff auf Dateifreigaben, sondern kann — je nach Konfiguration — auch zur Ausführung von Dateien auf Remote-Systemen genutzt werden.

MSSQL-Dienste sind besonders attraktiv, da SQL-Server-Dienstkonten in vielen Umgebungen mit Domain-Admin-Rechten konfiguriert sind oder über umfangreiche Datenbankzugänge verfügen. Ein Silver Ticket für den SPN MSSQLSvc gewährt direkten Datenbankzugriff.

HTTP/WWW-Dienste ermöglichen den Zugriff auf interne Webanwendungen, SharePoint-Umgebungen oder Exchange-Dienste. Ein gefälschtes HTTP-Ticket kann unter Umständen genutzt werden, um sich als privilegierter Benutzer in Webanwendungen anzumelden.

LDAP ist ein besonders sensitives Ziel: Wer LDAP-Zugriff auf einen Domain Controller imitieren kann, kann Verzeichnisinformationen abfragen und — unter bestimmten Bedingungen — Attributänderungen vornehmen.

HOST und WSMAN ermöglichen Fernverwaltungsoperationen über WMI, PowerShell Remoting oder Remote Desktop, sofern die Konfiguration dies zulässt.

Voraussetzungen: Wie kommt der Angreifer an den Service-Account-Hash?

Das zentrale Erfordernis für einen Silver-Ticket-Angriff ist der NTLM-Hash oder — in Umgebungen, die ausschließlich AES-Verschlüsselung erzwingen — der AES-Schlüssel des Ziel-Service-Accounts. Der häufigste Weg ist Kerberoasting: Jeder authentifizierte Domänenbenutzer kann TGS-Tickets für Dienste mit registrierten SPNs anfordern. Diese Tickets sind mit dem Service-Account-Hash verschlüsselt und können offline geknackt werden. Ein erfolgreicher Kerberoasting-Angriff liefert damit direkt den für das Silver Ticket benötigten Hash.

Alternativ kann der Hash über LSASS-Dumps von Systemen extrahiert werden, auf denen der Service Account interaktiv angemeldet war — etwa über kompromittierte Administratoren-Sitzungen, über Schwachstellen in Anwendungen mit LocalSystem-Kontext oder durch Ausnutzen von Pass-the-Hash-Schwachstellen in Vorstufen des Angriffs. In einigen Szenarien liefern auch unsichere Credential-Stores wie Konfigurationsdateien, Registry-Einträge oder gespeicherte Credentials in GPO-Dateien den benötigten Hash.

Warum Silver Tickets schwer zu erkennen sind

Die charakteristische Eigenschaft von Silver Tickets ist das vollständige Fehlen von KDC-Kommunikation. In einem normalen Kerberos-Authentifizierungsfluss erzeugt die TGS-Anfrage ein Event ID 4769 auf dem Domain Controller. Bei einem Silver Ticket entfällt diese Anfrage komplett — der gefälschte TGS wird direkt beim Zieldienst präsentiert, ohne dass der Domain Controller jemals einbezogen wird.

Auf dem Zielsystem selbst ist ein Silver Ticket kaum von einer legitimen Authentifizierung zu unterscheiden. Event ID 4624 (erfolgreiche Anmeldung) wird normal protokolliert. Die Anomalie liegt im Fehlen der korrespondierenden TGS-Anfrage auf dem DC — ein Muster, das nur durch Korrelation von DC-Logs und Service-Logs erkennbar ist, was in der Praxis selten implementiert ist.

Eine weitere Schwierigkeit ergibt sich aus dem Privileged Attribute Certificate (PAC). Das PAC ist eine Microsoft-Erweiterung des Kerberos-Protokolls, die Gruppen-SIDs und Berechtigungen des authentifizierten Benutzers enthält. In einem gefälschten Silver Ticket kann der Angreifer das PAC mit beliebigen Berechtigungen befüllen. Die PAC-Validierung durch den Zieldienst beim KDC ist optional und standardmäßig in vielen Diensten nicht aktiviert, sodass diese Manipulation oft unentdeckt bleibt.

Erkennung

Indikator	Beschreibung
Fehlende Event ID 4769	Anmeldeereignisse (4624) auf dem Zieldienst ohne vorherige TGS-Anfrage auf dem DC
PAC-Validierungs-Anomalien	Event ID 4769 mit Fehler-Code 0x1F (PAC-Validierung fehlgeschlagen)
Ticket-Lebensdauer	Ungewöhnlich lange Gültigkeitsdauer des Service Tickets (Standard: max. 10 Stunden)
SID-Anomalien	Service-Tickets mit SIDs, die nicht dem Benutzerkonto im AD entsprechen
Kerberoasting-Vorstufe	Häufung von 4769-Events mit RC4-Verschlüsselung vor dem Angriff

Die zuverlässigste Erkennungsmethode ist die Aktivierung der PAC-Validierung auf Dienstseite in Verbindung mit einer SIEM-Regel, die Anmeldungen ohne korrespondierende TGS-Anfrage auf dem KDC markiert. Diese Korrelation erfordert jedoch eine lückenlose Protokollierung sowohl auf den Domain Controllern als auch auf den betroffenen Diensten.

Gegenmaßnahmen

Die wichtigste strukturelle Gegenmaßnahme ist der Einsatz von Group Managed Service Accounts (gMSA). Diese verwenden automatisch rotierte, 240 Byte lange Passwörter (1920 Bit), die alle 30 Tage gewechselt werden und niemals im Klartext zugänglich sind. Ein Kerberoasting-Angriff gegen einen gMSA liefert einen Hash, der in der Praxis nicht knackbar ist. Die Migration von klassischen Service Accounts auf gMSA ist eine der wirkungsvollsten Einzelmaßnahmen gegen diese Angriffskategorie.

Wo gMSA nicht unmittelbar eingesetzt werden kann, sollten Service-Account-Passwörter mindestens 30 Zeichen lang und vollständig zufällig generiert sein. Regelmäßige Rotation — mindestens alle 90 Tage, idealerweise automatisiert über eine PAM-Lösung — reduziert das Zeitfenster, in dem ein kompromittierter Hash nutzbar ist.

Die Aktivierung der PAC-Validierung auf kritischen Diensten zwingt den Dienst, das PAC beim KDC zu verifizieren, und schließt damit die Möglichkeit, beliebige Berechtigungen in ein gefälschtes Ticket einzutragen. Dies erhöht die Erkennbarkeit und schränkt die Schadenswirkung ein.

Die Gruppe Protected Users erzwingt AES-Verschlüsselung und unterbindet bestimmte Credential-Caching-Mechanismen, die zur Hash-Extraktion genutzt werden können. Wichtig: Microsoft empfiehlt ausdrücklich, Service Accounts nicht in die Protected Users-Gruppe aufzunehmen, da die Einschränkungen (kein NTLM, keine Delegierung, 4-Stunden-TGT-Limit) den Betrieb typischer Dienstkonten stören. Protected Users eignet sich für administrative Benutzerkonten, nicht für Service Accounts. Credential Guard schützt LSASS-gespeicherte Credentials und erschwert damit die Hash-Extraktion über direkte LSASS-Zugriffe.

Ein sauberes Tiering-Modell stellt sicher, dass Service Accounts nur auf Systemen ihrer eigenen Tier-Ebene eingesetzt werden, was die laterale Ausbreitung nach einem erfolgreichen Silver-Ticket-Angriff einschränkt.

Zusammenhang mit Kerberoasting

Kerberoasting und Silver Ticket bilden in der Angriffspraxis häufig eine natürliche Kette: Kerberoasting liefert den NTLM-Hash des Service Accounts, Silver Ticket nutzt diesen Hash zum persistenten Zugriff auf den zugehörigen Dienst. In Penetrationstests zeigt diese Kombination besonders deutlich, welche Risiken von Service Accounts mit schwachen Passwörtern ausgehen — der initiale Kerberoasting-Angriff benötigt nur einen normalen Domänenbenutzer, und das resultierende Silver Ticket gewährt dauerhaften Zugriff ohne weitere Interaktion mit dem KDC.

Relevanz für KMUs

In mittelständischen Umgebungen sind die Voraussetzungen für Silver-Ticket-Angriffe häufig gegeben: Service Accounts werden selten überwacht, haben Passwörter, die seit Jahren unverändert sind, und verfügen in vielen Fällen über weitreichendere Berechtigungen als technisch notwendig. Gleichzeitig fehlt die SIEM-Korrelation, die eine Erkennung ohne KDC-Interaktion überhaupt erst ermöglichen würde. Eine Inventarisierung aller Service Accounts mit SPNs, die Migration der kritischsten Konten auf gMSA und die Aktivierung der PAC-Validierung auf zentralen Diensten sind Maßnahmen mit hoher Wirkung, die keine zusätzliche Infrastruktur erfordern.