Silver-Ticket-Angriff in AD: Erkennung und Remediation

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 wertvoll. Der Angreifer bittet keinen Domain Controller, das Service-Ticket in Echtzeit auszustellen. Er fälscht das Service-Ticket offline und präsentiert es anschließend dem Zielservice.

Dieser Artikel behandelt Windows Active Directory Kerberos-Umgebungen. Der Fokus liegt auf der echten Voraussetzungskette, dem Protokollverhalten, das den Angriff von Golden Tickets unterscheidet, und den Dienstkonto-Härtungsschritten, die die Gelegenheit tatsächlich beseitigen.

Wie der Silver-Ticket-Angriff funktioniert

Kerberos verlässt sich normalerweise darauf, dass der Key Distribution Center ein Service-Ticket ausstellt, nachdem ein Client ein gültiges TGT präsentiert hat. Ein Silver Ticket bricht diesen erwarteten Ablauf, indem es das Service-Ticket direkt fälscht.

MITREs Silver-Ticket-Techniken-Seite besagt, dass Angreifer mit dem Passwort-Hash eines Ziel-Dienstkontos Kerberos Ticket Granting Service Tickets, auch Service-Tickets genannt, fälschen können. Im Gegensatz zu Golden Tickets sind diese Tickets auf eine bestimmte Ressource und das System begrenzt, das diese Ressource hostet. Aber im Gegensatz zu einem Golden Ticket kann der Angreifer das Ticket ohne Interaktion mit dem KDC erstellen.

Dieser Designunterschied hat zwei direkte Folgen:

das gefälschte Ticket ist auf einen einzelnen Service Principal beschränkt statt auf die gesamte Domäne
die Erkennung ist oft schwieriger, weil der normale Ausstellungspfad über den Domain Controller fehlt

Warum das Dienstkonto-Secret entscheidend ist

Ein Silver Ticket funktioniert, weil der Angreifer den Schlüssel kennt, den das Ziel-Dienstkonto verwendet. Dieses Secret kann stammen aus:

direktem Credential Dumping nach einer Kompromittierung
der Extraktion eines Dienstkonto-Passwort-Hashes von einem Server, auf dem der Dienst läuft
Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken, was MITRE explizit als einen Weg zum Erlangen des Ziel-Service-Hashes nennt

Wenn der Angreifer das Secret des Zieldienstes nicht erlangen kann, kann er kein brauchbares Silver Ticket für diesen Dienst fälschen.

Warum manche gefälschten Tickets trotzdem den Servicepfad erreichen

Microsofts Kerberos-Dokumentation zeigt, dass die PAC-Verarbeitung vom Anwendungsmodell und von Trust-Annahmen abhängt. Insbesondere weist Microsoft darauf hin, dass die PAC-Validierung für eine eigenständige Anwendung optional sein kann.

Diese Nuance ist wichtig, sollte aber nicht überbewertet werden. Die zentrale Silver-Ticket-Voraussetzung bleibt der Besitz des Secrets des Ziel-Dienstkontos und ein Zielservicepfad, der bereit ist, das gefälschte Ticket zu akzeptieren. Das PAC-Verhalten ist ein Teil des serviceseitigen Verarbeitungsmodells, keine vollständige Erklärung für jeden erfolgreichen Fall eines gefälschten Tickets.

Silver Ticket vs. Golden Ticket, Kerberoasting und Pass-the-Ticket

Diese Begriffe werden häufig vermischt. Das sollten sie nicht.

Silver Ticket: gefälschtes Service-Ticket für einen bestimmten Dienst nach Erlangen des Dienstkonto-Secrets
Golden Ticket: gefälschtes TGT auf Basis des krbtgt-Secrets, das einen deutlich breiteren, domänenweiten Impact hat. Siehe Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain
Kerberoasting: legitime Service-Tickets vom KDC anfordern und sie offline knacken, um Dienstkonto-Secrets zu gewinnen. Siehe Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken
Pass-the-Ticket: ein echtes Kerberos-Ticket, das gestohlen statt gefälscht wurde, wiedergeben oder wiederverwenden

Silver Ticket steht oft nach einer anderen Voraussetzungsattacke. Kerberoasting oder Credential Dumping liefert das Dienstkonto-Secret. Silver Ticket macht aus diesem Secret nicht autorisierten Servicezugriff.

Warum Silver Tickets weiterhin zählen

Silver Tickets sind weniger bekannt als Golden Tickets, bleiben aber wichtig, weil sie eine häufige Enterprise-Schwäche treffen: schlecht verwaltete Dienstkonto-Secrets.

Dienstkonten sind oft breiter und älter, als Teams denken

Dienstkonten überleben oft jahrelang, bedienen mehrere Anwendungen und sammeln SPNs, lokale Rechte und operative Ausnahmen an. Genau das erzeugt die Art von langlebigem Secret, die ein Angreifer sucht.

Der Angriff ist leiser als ein normaler, vom KDC ausgestellter Serviceablauf

MITRE hebt das wichtigste Erkennungsproblem direkt hervor: gefälschte Silver Tickets können ohne Interaktion mit dem KDC erstellt werden. Das bedeutet, dass ein Teil der üblichen Domain-Controller-Sichtbarkeit, auf die sich Defender verlassen, ab dem Moment der Ticket-Fälschung fehlt.

Schwache Dienstkonto-Hygiene existiert weiterhin

Microsofts Leitfaden zu Managed Service Accounts existiert, weil manuelle Verwaltung von Dienstkonto-Passwörtern fehleranfällig ist. Ein normales Benutzerkonto, das einen Dienst ausführt, ist weiterhin einer der einfachsten Orte, um alte Schlüssel, schwache Rotation und inkonsistente Verschlüsselungseinstellungen anzuhäufen.

Legacy-Kerberos-Verschlüsselung erhöht das Risiko weiterhin

Microsoft ist inzwischen über das bloße schrittweise Auslaufen von RC4 hinausgegangen. Im Rahmen des CVE-2026-20833-Rollouts fügten Updates ab dem 13. Januar 2026 Audit-Events hinzu, änderten Updates ab dem 14. April 2026 den KDC-Standardwert für DefaultDomainSupportedEncTypes auf ausschließlich AES-SHA1 (0x18), und entfernten Updates, die ab Juli 2026 veröffentlicht wurden, den Registry-Subkey RC4DefaultDisablementPhase, der ein Rollback erlaubte. Ein Domain Controller ohne explizite Konfiguration geht jetzt von ausschließlich AES aus. Das ist relevant, weil Dienstkonten mit alter Verschlüsselungs-Posture oft dieselben Konten sind, die operativ schlecht verwaltet bleiben, und genau diese Konten entweder brechen oder stillschweigend einen RC4-Schlüssel behalten, sobald der Standardwert umschaltet.

Voraussetzungen für einen erfolgreichen Silver-Ticket-Angriff

Ein Silver Ticket ist kein Kerberos-Trick mit einem Klick. Mehrere Bedingungen müssen zusammenkommen.

1. Der Angreifer muss das Secret des Ziel-Dienstkontos erlangen

Das ist die nicht verhandelbare Voraussetzung. MITRE sagt explizit, dass der Angreifer den Passwort-Hash des Ziel-Dienstkontos benötigt. Übliche Beschaffungswege sind Credential Dumping und Kerberoasting.

2. Der Zielservice muss sich auf diesen Service Principal verlassen

Das gefälschte Ticket muss zu einer echten Serviceidentität passen, die der Host akzeptiert. Der Scope ist daher enger als bei einem Golden Ticket.

3. Das gefälschte Ticket muss vom angegriffenen Servicepfad akzeptiert werden

Microsofts PAC-Dokumentation zeigt, warum die serviceseitige Verarbeitung je nach Anwendungsdesign variieren kann. Diese Nuance ist nützlich, um das Protokoll zu verstehen, beseitigt aber nicht die Notwendigkeit, dass der Angreifer den richtigen Service Principal mit dem richtigen Secret trifft.

4. Das Dienstkonto muss wertvoll genug sein, um zu zählen

Ein gefälschtes Ticket für einen wenig wertvollen Dienst ist immer noch ein Problem, aber die eigentliche Sorge gilt einem Dienstkonto, das mit einer sensiblen Anwendung, einem administrativen Workflow oder einem privilegierten Host verknüpft ist.

5. Die Umgebung weist weiterhin schwache Dienstkonto-Hygiene auf

Langlebige, benutzerbasierte Dienstkonten, fehlende gMSA-Adoption, schwache Rotation, überprivilegierte Dienstkonten oder alte, nur RC4-fähige Schlüssel machen die Silver-Ticket-Voraussetzungen realistischer, als sie sein sollten.

Die Angriffskette

Eine praktische Silver-Ticket-Intrusionskette sieht meist so aus.

Schritt 1 - Ein angriffswertes Dienstkonto identifizieren

Der Angreifer kartiert SPNs, Dienste und Systeme, um einen Service Principal zu finden, der bei Kompromittierung nützlichen Zugriff geben würde.

Schritt 2 - Den Hash oder Schlüssel des Dienstkontos erlangen

Der Angreifer erlangt das Secret durch Dumping, Offline-Cracking nach Kerberoasting oder einen anderen Credential-Access-Pfad.

Schritt 3 - Das Service-Ticket offline fälschen

Mit dem Dienstsecret erstellt der Angreifer ein Kerberos-Service-Ticket für den gewählten Service Principal.

Schritt 4 - Das gefälschte Ticket direkt dem Dienst präsentieren

Hier weicht Silver Ticket vom normalen Kerberos-Pfad ab. MITRE weist darauf hin, dass das gefälschte Ticket ohne Interaktion mit dem KDC verwendet werden kann.

Schritt 5 - Den resultierenden Zugriff innerhalb des Servicescopes nutzen

Der Zugriff ist enger als bei einem Golden Ticket, kann aber operativ dennoch schwerwiegend sein, wenn der Dienst auf einem sensiblen Host läuft, administrative Funktionen bereitstellt oder laterale Bewegung ermöglicht.

Deshalb gehört Silver Ticket auch in dieselbe Betrachtung wie AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen. Selbst ein begrenztes Service-Ticket kann Teil einer viel größeren Kette werden.

Erkennung

Die Erkennung von Silver Tickets ist aus einem einfachen Grund schwierig: Der Angreifer muss den KDC möglicherweise nie nach dem Service-Ticket fragen, das er verwendet.

Das richtige Modell ist daher Anomalieerkennung plus Voraussetzungserkennung, nicht ein einzelnes Event, das den Fall auf magische Weise beweist.

Nach Service-Ticket-Nutzung suchen, die nicht zur erwarteten KDC-Aktivität passt

MITREs Silver-Ticket-Detection-Strategy (DET0241) beschreibt einen der besten übergeordneten Ansätze: nach anomaler Kerberos-Service-Ticket-Aktivität suchen, einschließlich fehlerhafter Felder in Logon-Ereignissen und TGS-Anfragen ohne Interaktion mit dem KDC.

Operativ bedeutet das, Fälle zu untersuchen, in denen:

ein Dienstkonto auf einem Host oder einer Ressource außerhalb seines normalen Scopes verwendet wird
der Zielservice Kerberos-authentifizierte Aktivität sieht, die nicht sauber zu den erwarteten, KDC-seitigen Ausstellungsmustern für Service-Tickets passt
fehlerhafte oder ungewöhnliche Felder in Logon- oder Ticketverarbeitungsdaten auftauchen

Das ist keine triviale Regel, die man implementieren kann. Sie erfordert eine Baseline dafür, welche Hosts und Ressourcen jedes Dienstkonto tatsächlich berühren sollte.

Die Voraussetzungsangriffe überwachen, nicht nur das gefälschte Ticket selbst

MITREs Detection Strategy weist auch direkt auf verdächtigen LSASS-Zugriff und Credential Dumping als nützliche Datenquellen hin. Das ist relevant, weil das Dienstkonto-Secret meist gestohlen werden muss, bevor das Silver Ticket existiert.

Wenn Sie bereits Folgendes überwachen:

verdächtigen Zugriff auf LSASS
Credential-Dumping-Verhalten
Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken
ungewöhnliche Authentifizierungsmuster von Dienstkonten

dann sind Sie der echten Angriffskette deutlich näher, als wenn Sie nur nach einem einzigen finalen Indikator für das gefälschte Ticket suchen.

Kerberos-Eventkontext mit Vorsicht nutzen

Microsofts Kerberos-Leitfaden zu Event 4769 ist weiterhin nützlich, weil er dokumentiert, dass eine normale Service-Ticket-Anforderung am KDC als Service-Ticket-Ereignis sichtbar ist. Das macht 4769 zu wertvollem Kontext für normale Kerberos-Aktivität.

Für Silver-Ticket-Untersuchungen geht es nicht darum, abstrakt zu alarmieren, wenn 4769 fehlt. Der Punkt ist zu verstehen, dass ein gefälschtes Service-Ticket möglicherweise nicht demselben KDC-Ausstellungspfad folgt wie ein legitimes Service-Ticket. Jede darauf basierende Erkennung braucht Baseline-Kontext, keine simplistische Ein-Event-Regel.

Auf Dienstkonten außerhalb ihres erwarteten Blast Radius achten

MITREs Silver-Ticket-Detection-Strategy nennt speziell Zugriffsversuche mit Dienstkonten außerhalb erwarteter Hosts oder Ressourcen. Das ist eine der operativ nützlichsten Erkennungen, weil sie für Defender verständlich und an den echten Dienstkonto-Scope gebunden ist.

Mit privilegierter Folgeaktivität korrelieren

Wenn das gefälschte Ticket einen Dienst mit administrativem Impact erreicht, können die nächsten Signale sich zeigen als:

ungewöhnlicher Zugriff auf Admin-Funktionen der Zielanwendung
Logons auf den Servicehost von Identitäten, die dort nicht auftauchen sollten
privilegierte Folgeaktionen, nachdem das Ticket akzeptiert wurde
umliegende Anomalien, die bereits in AD Sicherheitsüberwachung: Event IDs und SIEM behandelt werden

Behebung

Silver-Ticket-Mitigation ist vor allem Dienstkonto-Härtung. Wenn der Angreifer kein wiederverwendbares Dienstkonto-Secret erlangen kann, kann er das Ticket nicht fälschen.

1. Geeignete Dienste auf gMSAs migrieren

Microsofts Leitfaden zu group Managed Service Accounts ist hier die klarste Primärquellen-Mitigation.

Microsoft dokumentiert, dass gMSAs:

Windows die Passwortverwaltung für Dienstkonten übernehmen lassen
die für das Konto verwendeten Schlüssel periodisch ändern
Mitgliedshosts erlauben, aktuelle und vorherige Passwortwerte vom Domain Controller zu erhalten
den Bedarf reduzieren, dass Administratoren die Passwortsynchronisierung manuell verwalten müssen

Das adressiert direkt eine der größten Silver-Ticket-Voraussetzungen: statische oder schlecht verwaltete Dienstkonto-Secrets.

2. AES-Unterstützung für Managed Service Accounts konfigurieren

Microsofts gMSA-Dokumentation ist explizit: Managed Service Accounts hängen von den unterstützten Kerberos-Verschlüsselungstypen ab, und Sie sollten AES für MSAs immer konfigurieren. Der Domain Controller liest das Attribut msDS-SupportedEncryptionTypes des Kontos, um zu entscheiden, was der Server unterstützt, und wenn dieses Attribut nicht gesetzt ist, behandelt er das Konto so, als unterstütze es die stärkeren Typen nicht. Wenn Sie also den Host gehärtet haben, um RC4 abzulehnen, während das Attribut weiterhin undefiniert ist, schlägt die Authentifizierung immer fehl. Genau deshalb muss die Verschlüsselungs-Posture explizit sein statt vorausgesetzt zu werden.

3. Alte Dienstkonto-Passwörter zurücksetzen, um AES-Schlüssel zu erzeugen

Microsofts Kerberos-RC4-Remediation-Leitfaden erklärt, dass Konten, die vor der AES-Unterstützung erstellt wurden, AES-Schlüssel fehlen können, wenn ihre Passwörter nach Einführung der AES-Unterstützung nie zurückgesetzt wurden. Microsoft macht explizit deutlich, dass das Ändern des Kontopassworts diese Schlüssel erzeugt.

Das ist relevant, weil viele Legacy-Dienstkonten alt genug sind, um genau dieses Problem zu tragen.

4. Verbleibende RC4-Abhängigkeit beseitigen

Das ist auf Microsoft-Seite nicht mehr optional: Seit den Updates vom Juli 2026 geht der KDC standardmäßig nur noch von AES-SHA1 aus, wenn kein expliziter Verschlüsselungstyp konfiguriert ist, und der temporäre Rollback-Registry-Subkey existiert nicht mehr. Microsofts RC4-Leitfaden liefert die Audit- und Remediation-Schritte, um Konten zu finden, die RC4 noch verwenden, einschließlich der Skripte List-AccountKeys.ps1 und Get-KerbEncryptionUsage.ps1 sowie der Events 4768 und 4769. Das macht Silver Ticket für sich genommen nicht unmöglich, entfernt aber eine weitere Legacy-Schwäche aus der Kerberos-Verarbeitung von Dienstkonten und verbessert die gesamte Kerberos-Baseline. Es ergänzt sich zudem direkt mit AS-REP Roasting: Hashes Ohne Anmeldedaten Sammeln und weiteren Kerberos-Härtungsmaßnahmen.

5. Rechte und Scope der Dienstkonten minimieren

Ein gefälschtes Ticket ist nur so nützlich wie das Dienstkonto dahinter. Auch wenn das Dienstkonto existieren muss, sollte es keine unnötigen lokalen Adminrechte, keine Mitgliedschaft in privilegierten Gruppen und keinen breiten Zugriff auf nicht verwandte Systeme tragen.

6. SPNs und Dienstkonto-Ownership inventarisieren

Sie können Dienstkonto-Secrets nicht verteidigen, die Sie nicht verstehen. Ein echtes Härtungsprogramm sollte wissen:

welche SPNs welchen Konten zugeordnet sind
welche Hosts diese Konten voraussichtlich nutzen
wer jedes Dienstkonto operativ besitzt
ob das Konto zu gMSA migriert werden kann
ob das Konto noch von RC4 oder Legacy-Einstellungen abhängt

Deshalb gehört Active Directory-Sicherheit auditieren: praktische Checkliste für interne Teams direkt neben dieses Thema. Wenn Sie diese Prüfung über den gesamten Bestand skalieren, ist auch Vergleich von Active-Directory-Sicherheitsaudit-Tools relevant.

7. Credential Dumping und Kerberoasting als direkte Silver-Ticket-Vorstufen behandeln

Wenn ein Angreifer ein Dienstkonto-Secret dumpen oder offline knacken kann, ist der Silver-Ticket-Pfad jetzt offen. Deshalb sollte dieser Artikel zusammen mit Kerberoasting: Wie Angreifer Dienstkonto-Passwörter Knacken, Kerberos-Delegation: unkontrolliert bis RBCD-Missbrauch und Golden Ticket Angriff: Die Schlüssel zu Ihrer Domain gelesen werden.

Validierung nach der Härtung

Schließen Sie das Silver-Ticket-Risiko nicht ab, nur weil Sie einmal ein Passwort geändert haben. Validieren Sie das Dienstkonto-Modell direkt.

bestätigen, welche Service Principals noch traditionelle Benutzerkonten statt gMSAs verwenden
prüfen, ob jedes Dienstkonto AES-Schlüssel besitzt und ob RC4 noch verwendet wird
msDS-SupportedEncryptionTypes dort verifizieren, wo relevant, und mit der tatsächlich auf Domain Controllern beobachteten Kerberos-Nutzung vergleichen
Event-4769-Daten auf KDCs überprüfen, um zu verstehen, welche Dienstkonten noch Service-Tickets anfordern und welche Verschlüsselungstypen sie verwenden
verifizieren, dass sensible Dienste nicht auf veralteten, geteilten oder undokumentierten Serviceidentitäten basieren
bestätigen, dass Dienstkonten keine breiteren Rechte erhalten, als der Dienst tatsächlich benötigt

Der eigentliche Erfolgsfall ist nicht nur bessere Kerberos-Policy. Er besteht darin, dass die Kompromittierung eines Dienstkontos nicht länger ein stabiles, wiederverwendbares Secret mit breitem operativem Wert liefert.

Wie EtcSec verwandte Exposition erkennt

Es gibt keinen exakten Silver-Ticket-Vulnerability-Type im aktuellen Katalog, daher sind die nützlichsten Findings die Voraussetzungen und umliegenden Kerberos-Schwächen, die die Technik praktisch machen.

Die relevantesten Findings sind:

KERBEROASTING_RISK, weil die Offline-Wiederherstellung eines Dienstkonto-Secrets einer der klarsten Silver-Ticket-Vorläufer ist
KERBEROS_RC4_FALLBACK, weil eine veraltete Kerberos-Verschlüsselungs-Posture oft mit derselben schlecht verwalteten Dienstkonto-Population überlappt
privilegierte oder zu breit angelegte Dienstkonten, die ein gefälschtes Service-Ticket weit schädlicher machen
umliegende Attack-Path-Bedingungen, die bereits in AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen erfasst sind

Das ist das richtige Denkmodell: Silver Ticket ist eine Forged-Ticket-Technik, aber die echte Fix-Oberfläche ist Dienstkonto-Hygiene.