Was ist ein Silver-Ticket-Angriff?
Ein Silver-Ticket-Angriff ist ein gefälschtes Kerberos-Service-Ticket (TGS), das mit dem Secret eines Ziel-Dienstkontos erzeugt wird. MITRE führt die Technik als T1558.002, Silver Ticket.
Der Scope ist enger als bei einem Golden Ticket, aber der Mechanismus ist sicherheitsrelevant. Ein Angreifer, der den Passwort-Hash oder Kerberos-Schlüssel eines Dienstkontos kennt, kann ein Ticket für diesen Dienst fälschen und es direkt dem Host präsentieren, auf dem der Dienst läuft. MITRE macht drei Punkte deutlich:
- der Angreifer benötigt den Passwort-Hash des Ziel-Dienstkontos
- das gefälschte Ticket ist ein Service-Ticket, kein TGT
- das Ticket kann ohne Interaktion mit dem KDC erstellt werden
Genau dieser letzte Punkt macht Silver Tickets interessant. Der Angreifer bittet keinen Domain Controller, das Service-Ticket live auszustellen. Er fälscht es offline und präsentiert es anschließend dem Zielservice.
Dieser Artikel behandelt Windows Active Directory Kerberos. Der Fokus liegt auf den echten Voraussetzungen, dem Unterschied zu Golden Tickets und den Dienstkonto-Härtungen, die die Gelegenheit tatsächlich reduzieren.
Wie der Silver-Ticket-Angriff funktioniert
In einem normalen Kerberos-Ablauf stellt der Key Distribution Center ein Service-Ticket aus, nachdem ein Client ein gültiges TGT präsentiert hat. Beim Silver Ticket wird dieser erwartete Ablauf umgangen, indem das Service-Ticket direkt gefälscht wird.
MITRE beschreibt, dass Angreifer mit dem Passwort-Hash eines Ziel-Dienstkontos Kerberos Ticket Granting Service Tickets, also Service-Tickets, fälschen können. Im Gegensatz zu Golden Tickets sind diese Tickets auf eine bestimmte Ressource und das System begrenzt, das diese Ressource hostet. Gleichzeitig kann das Ticket ohne KDC-Interaktion erzeugt werden.
Das hat zwei Folgen:
- das Ticket ist auf einen konkreten Service Principal beschränkt
- Erkennung ist schwieriger, weil der normale Ausstellungspfad über den Domain Controller fehlt
Warum das Dienstkonto-Secret entscheidend ist
Ein Silver Ticket funktioniert nur, weil der Angreifer den Schlüssel des Ziel-Dienstkontos kennt. Das Secret kann stammen aus:
- Credential Dumping nach Serverkompromittierung
- Extraktion eines Dienstkonto-Hashes auf einem Host, auf dem der Dienst läuft
- Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken, das MITRE als möglichen Weg zum Zielhash nennt
Ohne das Secret des Dienstkontos kann kein brauchbares Silver Ticket für diesen Dienst gefälscht werden.
PAC-Verhalten vorsichtig einordnen
Microsofts Kerberos-PAC-Dokumentation zeigt, dass PAC-Verarbeitung vom Anwendungsmodell und Trust-Annahmen abhängen kann. Microsoft erwähnt unter anderem, dass PAC-Validierung für eine eigenständige Anwendung optional sein kann.
Diese Nuance ist wichtig, sollte aber nicht überdehnt werden. Die zentrale Voraussetzung bleibt das Secret des Dienstkontos plus ein Servicepfad, der das präsentierte Ticket akzeptiert. PAC-Verhalten ist ein Teil der Serviceverarbeitung, nicht die universelle Erklärung für jedes erfolgreiche Silver Ticket.
Silver Ticket vs. Golden Ticket, Kerberoasting und Pass-the-Ticket
Diese Begriffe werden oft vermischt, beschreiben aber unterschiedliche Techniken.
- Silver Ticket: gefälschtes Service-Ticket für einen bestimmten Dienst nach Kompromittierung des Dienstkonto-Secrets
- Golden Ticket: gefälschtes TGT auf Basis des
krbtgt-Secrets mit deutlich breiterem Domänenimpact. Siehe Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain - Kerberoasting: legitime Service-Tickets vom KDC anfordern und offline knacken, um Dienstkonto-Secrets zu gewinnen
- Pass-the-Ticket: Wiederverwendung eines echten gestohlenen Kerberos-Tickets statt eines gefälschten Tickets
Silver Ticket liegt häufig nach einer anderen Attacke. Kerberoasting oder Credential Dumping liefert das Secret; Silver Ticket macht daraus nicht autorisierten Servicezugriff.
Warum Silver Tickets weiterhin zählen
Silver Tickets sind weniger bekannt als Golden Tickets, treffen aber ein häufiges Enterprise-Problem: schlecht verwaltete Dienstkonto-Secrets.
Dienstkonten leben oft zu lange
Dienstkonten bleiben oft jahrelang bestehen, bedienen mehrere Anwendungen und sammeln SPNs, lokale Rechte und Ausnahmen. Genau diese langlebigen Secrets sind für Angreifer wertvoll.
Der Angriff ist leiser als ein normaler KDC-Fluss
MITRE hebt das wichtigste Erkennungsproblem hervor: Silver Tickets können ohne Interaktion mit dem KDC erzeugt werden. Ein Teil der üblichen Domain-Controller-Sichtbarkeit fehlt deshalb im Moment der Ticket-Fälschung.
Dienstkonto-Hygiene ist oft schwach
Microsofts Dokumentation zu Managed Service Accounts existiert, weil manuelle Passwortverwaltung für Dienste fehleranfällig ist. Ein normales Benutzerkonto als Dienstkonto ist weiterhin ein häufiger Ort für alte Secrets, schwache Rotation und inkonsistente Verschlüsselung.
Legacy-Kerberos-Verschlüsselung erhöht das Risiko
Microsofts aktuelle Kerberos-Härtung drängt weiterhin zur Auditierung und Reduktion von RC4. Das ist relevant, weil alte Dienstkonten mit Legacy-Verschlüsselung oft zur gleichen schlecht verwalteten Population gehören.
Voraussetzungen für einen erfolgreichen Silver-Ticket-Angriff
Ein Silver Ticket ist kein Kerberos-Trick ohne Voraussetzungen.
1. Der Angreifer muss das Dienstkonto-Secret besitzen
Das ist nicht verhandelbar. MITRE sagt explizit, dass der Passwort-Hash des Ziel-Dienstkontos benötigt wird. Typische Wege sind Credential Dumping und Kerberoasting.
2. Der Zielservice muss diesem Service Principal entsprechen
Das gefälschte Ticket muss zu einer echten Serviceidentität passen, die der Host akzeptiert. Der Scope ist daher enger als bei Golden Tickets.
3. Der Servicepfad muss das Ticket akzeptieren
Microsofts PAC-Dokumentation zeigt, warum Serviceverarbeitung je nach Anwendung variieren kann. Diese Nuance ersetzt aber nicht die Notwendigkeit, den richtigen Service Principal mit dem richtigen Secret zu treffen.
4. Das Dienstkonto muss wertvoll sein
Ein gefälschtes Ticket für einen irrelevanten Dienst ist immer noch ein Problem. Kritisch wird es bei sensiblen Anwendungen, administrativen Workflows oder privilegierten Hosts.
5. Die Dienstkonto-Hygiene ist schwach
Benutzerbasierte Dienstkonten, fehlende gMSA-Nutzung, alte Passwörter, übermäßige Rechte oder RC4-Abhängigkeit machen Silver-Ticket-Voraussetzungen realistischer.
Angriffskette
Eine praktische Silver-Ticket-Kette sieht häufig so aus.
Schritt 1 - Wertvolles Dienstkonto identifizieren
Der Angreifer kartiert SPNs, Services und Systeme, um einen nützlichen Service Principal zu finden.
Schritt 2 - Hash oder Schlüssel des Dienstkontos erlangen
Das Secret stammt aus Dumping, Offline-Cracking nach Kerberoasting oder einem anderen Credential-Access-Pfad.
Schritt 3 - Service-Ticket offline fälschen
Mit dem Secret erstellt der Angreifer ein Kerberos-Service-Ticket für den gewählten Service Principal.
Schritt 4 - Ticket direkt dem Service präsentieren
Hier unterscheidet sich Silver Ticket vom normalen Kerberos-Weg. MITRE weist darauf hin, dass das gefälschte Ticket ohne KDC-Interaktion verwendet werden kann.
Schritt 5 - Zugriff im Servicescope nutzen
Der Zugriff ist enger als bei Golden Tickets, kann aber schwerwiegend sein, wenn der Dienst auf einem sensiblen Host läuft, administrative Funktionen bietet oder laterale Bewegung unterstützt.
Deshalb gehört Silver Ticket zu AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen.
Erkennung
Silver Tickets sind schwer zu erkennen, weil der Angreifer das verwendete Service-Ticket möglicherweise nie beim KDC anfordert.
Das richtige Modell ist Anomalieerkennung plus Präreq-Erkennung, nicht ein einzelnes Event, das alles beweist.
Service-Ticket-Nutzung gegen KDC-Kontext prüfen
MITREs Detection Strategy DET0241 empfiehlt, anomale Service-Ticket-Aktivität zu suchen, darunter Aktivität ohne erwartete KDC-Validierungs- oder Ausstellungsmuster.
Praktisch sollten Fälle untersucht werden, in denen:
- ein Dienstkonto auf Hosts oder Ressourcen außerhalb seines erwarteten Scopes verwendet wird
- ein Zielservice Kerberos-Aktivität sieht, die nicht sauber zu erwarteter TGS-Ausstellung am KDC passt
- ungewöhnliche oder malformed Felder in Logon- oder Ticketdaten erscheinen
Das ist keine einfache Regel. Es erfordert eine Baseline, welche Hosts und Ressourcen jedes Dienstkonto wirklich berühren soll.
Präreq-Angriffe überwachen
MITRE nennt verdächtigen LSASS-Zugriff und Credential Dumping als hilfreiche Datenquellen. Das ist logisch, weil das Dienstkonto-Secret meist vor dem Silver Ticket gestohlen werden muss.
Überwachen Sie daher:
- verdächtigen Zugriff auf LSASS
- Credential-Dumping-Verhalten
- Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken
- Dienstkonto-Authentifizierung außerhalb des erwarteten Scopes
Die echte Angriffskette wird oft früher erkannt als das gefälschte Ticket selbst.
Kerberos-Eventkontext vorsichtig verwenden
Event 4769 ist nützlich, weil es normale Service-Ticket-Anforderungen am KDC beschreibt. Für Silver Ticket ist der Punkt nicht, pauschal auf „fehlendes 4769“ zu alerten. Der Punkt ist, dass ein gefälschtes Service-Ticket nicht dem normalen KDC-Ausstellungspfad folgen muss. Dafür braucht man Baseline-Kontext.
Dienstkonten außerhalb ihres Blast Radius erkennen
MITRE nennt explizit Zugriffsversuche mit Dienstkonten außerhalb erwarteter Hosts oder Ressourcen. Das ist für Defender oft greifbarer als reine Protokollsignale.
Mit privilegierter Folgeaktivität korrelieren
Wenn das Ticket einen administrativ relevanten Dienst erreicht, können folgende Signale folgen:
- ungewöhnlicher Zugriff auf Admin-Funktionen der Anwendung
- Logons oder Zugriffe auf dem Servicehost durch unerwartete Identitäten
- privilegierte Aktionen downstream
- Anomalien aus AD Sicherheitsüberwachung: Event IDs und SIEM
Remediation
Silver-Ticket-Mitigation ist vor allem Dienstkonto-Härtung. Ohne wiederverwendbares Dienstkonto-Secret kann der Angreifer kein Ticket fälschen.
1. Geeignete Dienste auf gMSA migrieren
Microsofts Dokumentation zu group Managed Service Accounts ist hier die klarste Primärquelle. gMSAs lassen Windows Dienstkonto-Passwörter verwalten, Schlüssel rotieren und reduzieren manuelle Synchronisierung. Das adressiert direkt statische oder schlecht verwaltete Secrets.
2. AES für Managed Service Accounts konfigurieren
Microsoft sagt, dass Managed Service Accounts von Kerberos Supported Encryption Types abhängen und dass AES für MSAs immer konfiguriert werden sollte. Ohne passende AES-Posture können Authentifizierungen scheitern, wenn RC4 nicht unterstützt wird.
3. Alte Dienstkonto-Passwörter zurücksetzen
Microsofts RC4-Remediation erklärt, dass alte Konten ohne Passwortwechsel nach Einführung von AES möglicherweise keine AES-Schlüssel besitzen. Das Ändern des Kontopassworts erzeugt diese Schlüssel.
4. RC4-Abhängigkeit reduzieren
Microsoft stellt aktuelle Audit- und Remediation-Schritte für RC4 in Kerberos bereit. Das macht Silver Ticket nicht allein unmöglich, entfernt aber eine Legacy-Schwäche aus derselben Dienstkonto-Population. Es ergänzt AS-REP Roasting: Hashes Ohne Anmeldedaten Sammeln.
5. Rechte und Scope der Dienstkonten minimieren
Ein gefälschtes Ticket ist nur so nützlich wie das Dienstkonto dahinter. Dienstkonten sollten keine unnötigen lokalen Adminrechte, privilegierten Gruppen oder breiten Zugriffe tragen.
6. SPNs und Ownership inventarisieren
Ein gutes Programm kennt:
- welche SPNs zu welchen Konten gehören
- welche Hosts diese Konten nutzen dürfen
- wer operativ verantwortlich ist
- ob das Konto zu gMSA migrieren kann
- ob RC4 oder Legacy-Einstellungen noch nötig sind
Das gehört in Active Directory-Sicherheit auditieren: praktische Checkliste für interne Teams.
7. Kerberoasting und Credential Dumping als direkte Vorstufen behandeln
Wenn ein Angreifer ein Dienstkonto-Secret dumpen oder offline knacken kann, ist der Silver-Ticket-Pfad offen. Lesen Sie dazu Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken, Kerberos-Delegation: unkontrolliert bis RBCD und Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain.
Validierung nach der Härtung
Schließen Sie das Risiko nicht nach einem einzelnen Passwortwechsel.
- feststellen, welche Services noch normale Benutzerkonten statt gMSAs nutzen
- prüfen, ob Dienstkonten AES-Schlüssel besitzen und ob RC4 noch verwendet wird
msDS-SupportedEncryptionTypesdort prüfen, wo es relevant ist- Konfiguration mit tatsächlicher Kerberos-Nutzung auf Domain Controllern vergleichen
- Event
4769auswerten, um Service-Tickets und Verschlüsselungstypen zu verstehen - sicherstellen, dass sensible Dienste nicht auf geteilte, alte oder undokumentierte Identitäten bauen
- übermäßige Rechte entfernen
Erfolg ist nicht nur bessere Kerberos-Policy. Erfolg ist, dass ein kompromittiertes Dienstkonto kein stabiles, breit nützliches Secret mehr liefert.
Wie EtcSec verwandte Exposition erkennt
Es gibt derzeit keinen exakten Silver-Ticket-Vulnerability-Type im Katalog. Die nützlichsten Findings sind daher die Voraussetzungen und Kerberos-Schwächen, die die Technik praktisch machen.
Relevant sind:
KERBEROASTING_RISK, weil Offline-Wiederherstellung eines Dienstkonto-Secrets ein klarer Vorläufer istKERBEROS_RC4_FALLBACK, weil Legacy-Kerberos-Posture oft dieselbe schlecht verwaltete Dienstkonto-Population betrifft- überprivilegierte oder zu breit eingesetzte Dienstkonten
- Attack-Path-Bedingungen aus AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen
Das richtige Modell: Silver Ticket ist eine Forged-Ticket-Technik, aber die echte Fix-Oberfläche ist Dienstkonto-Hygiene.
Verwandte Kontrollen
Wenn Sie Silver-Ticket-Risiko prüfen, prüfen Sie auch Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain, Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken, AS-REP Roasting: Hashes Ohne Anmeldedaten Sammeln, Kerberos-Delegation: unkontrolliert bis RBCD, AD Sicherheitsüberwachung: Event IDs und SIEM, AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen, Active Directory-Sicherheit auditieren: praktische Checkliste für interne Teams und Vergleich von Active-Directory-Sicherheitsaudit-Tools.
