Golden SAML ermöglicht das Fälschen beliebiger Cloud-Identitäten — ein einzelnes gestohlenes Zertifikat kompromittiert die gesamte Cloud-Infrastruktur.
Golden SAML & ADFS Exploitation — vom Zertifikat zur totalen Cloud-Kontrolle
Golden SAML basiert auf einer fundamentalen Eigenschaft föderierter Authentifizierung: Der Cloud-Identity-Provider (Azure AD/Entra ID) vertraut dem on-premises AD FS implizit — er validiert lediglich die digitale Signatur der SAML-Assertion. Wer das Token-Signing-Zertifikat besitzt, kann SAML-Assertions für jeden beliebigen Benutzer erstellen — einschließlich Global Admins — ohne deren Passwort zu kennen und ohne MFA auszulösen, da die Authentifizierung aus Sicht von Entra ID bereits am on-premises AD FS stattgefunden hat.
- Token-Signing-Zertifikat-Extraktion — der Schlüssel zum Königreich: Das Token-Signing-Zertifikat wird in AD FS in einer Windows Internal Database (WID) oder SQL Server-Datenbank gespeichert, verschlüsselt mit dem DKM (Distributed Key Management)-Schlüssel aus dem AD. Der Angriffspfad: Zuerst wird der DKM-Container im Active Directory lokalisiert (typischerweise unter
CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com). Der DKM-Master-Key wird extrahiert — dafür reichen DC-Sync-Rechte oder lesender Zugriff auf das AD-Objekt. Mit dem DKM-Key wird die AD FS-Konfigurationsdatenbank entschlüsselt und das Token-Signing-Zertifikat (PFX mit privatem Schlüssel) exportiert. Tools wie ADFSDump automatisieren diesen gesamten Prozess in einem einzigen Befehl:ADFSDump.exe /domain:corp.local. - SAML-Assertion-Fälschung — Impersonation ohne Grenzen: Mit dem extrahierten Zertifikat kann der Angreifer SAML-Assertions für jeden Benutzer erstellen — AADInternals bietet dafür das Cmdlet
New-AADIntSAMLToken. Die gefälschte Assertion enthält: NameID (UPN des Zielbenutzers), ImmutableID (Base64-kodierte ObjectGUID aus dem on-prem AD), Claims (Gruppenmitgliedschaften, Rollen), signiert mit dem gestohlenen Zertifikat. Der Token wird an den Azure AD Token-Endpunkt (login.microsoftonline.com) gesendet, der die Signatur validiert und ein OAuth 2.0 Access Token sowie ein Refresh Token ausstellt. Entscheidend: Die gefälschte Assertion umgeht Conditional Access Policies und MFA, da AD FS den MFA-Claim bereits gesetzt hat. - Silver SAML — der externe Angriffsvektor: Während Golden SAML das AD FS Token-Signing-Zertifikat (on-premises) kompromittiert, zielt Silver SAML auf extern konfigurierte SAML-Identity-Provider. In Entra ID können Organisationen externe IdPs für föderierte Authentifizierung konfigurieren (z. B. Okta, PingFederate). Der Angreifer kompromittiert das Signing-Zertifikat des externen IdP — oft einfacher als AD FS, da externe IdPs häufig in der Cloud gehostet werden und weniger streng überwacht sind. Der Unterschied: Golden SAML erfordert Domain-Admin-Rechte im on-prem AD, Silver SAML erfordert nur Zugriff auf den externen IdP. Beide ermöglichen dieselbe Impersonation, aber Silver SAML ist in rein cloud-basierten Umgebungen ohne AD FS relevant.
- Backdoor-Persistenz via Federation Trust: Die tückischste Variante: Der Angreifer erstellt einen neuen Federation Trust in Azure AD/Entra ID — per
Set-MsolDomainAuthenticationoder Microsoft Graph API — und konfiguriert einen von ihm kontrollierten IdP als vertrauenswürdigen SAML-Provider. Von diesem Punkt an kann der Angreifer jederzeit gültige SAML-Assertions für jeden Benutzer der Organisation ausstellen, ohne jemals das on-premises Netzwerk berühren zu müssen. Nobelium nutzte genau diese Technik: Nach der initialen Kompromittierung über SolarWinds wurde ein zusätzlicher Federation Trust konfiguriert, der Monate nach der Bereinigung des on-prem Netzwerks noch aktiv war. Erkennung:AuditLogs | where OperationName == "Set domain authentication"in Azure AD Audit Logs.
Token Forgery & PRT Abuse — Persistenz jenseits von SAML
SAML ist nur ein Angriffsvektor — moderne Cloud-Umgebungen nutzen hauptsächlich OAuth 2.0 und OIDC für die Authentifizierung. Der Primary Refresh Token (PRT) ist dabei das wertvollste Artefakt: Er ist das Äquivalent eines Kerberos TGT für Azure AD und ermöglicht Single Sign-On (SSO) zu allen Microsoft 365-Diensten und Azure-Ressourcen. Ein gestohlener PRT gewährt den gleichen Zugriff wie der legitime Benutzer — einschließlich aller Conditional Access-berechtigten Anwendungen.
- PRT-Extraktion & Replay — der Cloud-TGT-Diebstahl: Der PRT wird auf Azure AD-verbundenen Geräten im CloudAP-Plugin gespeichert und durch den TPM (Trusted Platform Module) geschützt — theoretisch. In der Praxis: Mimikatz kann den PRT über
sekurlsa::cloudapextrahieren, wenn der Angreifer SYSTEM-Rechte hat. Der PRT enthält einen Session Key, der für die Signed JWT-Erstellung benötigt wird. Mit PRT und Session Key kann der Angreifer über ROADtools oder AADInternals neue Access Tokens für beliebige Ressourcen anfordern:Get-AADIntAccessTokenWithPRT -BPRT $prt -SessionKey $key -Resource "https://graph.microsoft.com". TPM-Schutz umgehen: Auf Geräten ohne TPM 2.0 oder mit deaktiviertem TPM-Schutz liegt der Session Key ungeschützt im Speicher. - Device Code Phishing — PRT ohne Endpunkt-Kompromittierung: Der OAuth 2.0 Device Code Flow (RFC 8628) ist für gerätelose Szenarien gedacht (Smart-TVs, IoT), wird aber als Phishing-Vektor missbraucht. Der Angreifer initiiert einen Device Code Flow gegen
login.microsoftonline.com/common/oauth2/devicecodeund erhält einen User Code. Dieser Code wird per Phishing-E-Mail an das Opfer gesendet: „Geben Sie den Code ABCD-EFGH auf microsoft.com/devicelogin ein“. Das Opfer authentifiziert sich — einschließlich MFA — und der Angreifer erhält ein Refresh Token mit den Berechtigungen des Opfers. Der Vorteil gegenüber klassischem Phishing: Kein gefälschter Login-Screen, die Authentifizierung erfolgt auf der echten Microsoft-Seite. Erkennung:SignInLogs | where AuthenticationProtocol == "deviceCode"in Entra ID. - Continuous Access Evaluation (CAE) Bypass — Token Lifetime Exploitation: Microsoft hat CAE eingeführt, um gestohlene Tokens zu entwerten — bei kritischen Events (Passwortänderung, Account-Deaktivierung) werden Tokens in Echtzeit widerrufen. Der Bypass: CAE funktioniert nur für CAE-fähige Anwendungen (Exchange Online, SharePoint, Teams, Graph API). Nicht-CAE-fähige Anwendungen nutzen weiterhin die Standard-Token-Lifetime (1 Stunde für Access Tokens). Der Angreifer wählt gezielt nicht-CAE-fähige Ressourcen als Ziel — oder fordert Tokens mit dem
xms_cc-Claim ohnecp1-Capability an, um CAE zu umgehen. Zusätzlich: Refresh Tokens haben eine Lifetime von bis zu 90 Tagen und werden von CAE nicht in Echtzeit widerrufen — sie sind nur bei der nächsten Verwendung ungültig. - Managed Identity & Service Principal Token Theft: In Azure-Umgebungen nutzen Managed Identities den IMDS-Endpunkt (
169.254.169.254) für Token-Anfragen — ohne Credentials. Ein Angreifer mit Code-Execution auf einer Azure VM kann percurl http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.azure.com&api-version=2018-02-01 -H "Metadata:true"ein Access Token für Azure Resource Manager erhalten. Gefährlicher: Service Principal Secrets und Zertifikate in Azure AD können über die Graph API exportiert werden, wenn der Angreifer Application.ReadWrite.All-Rechte hat. Diese Secrets haben Lifetimes von bis zu 2 Jahren und werden selten rotiert. Erkennung: Workload Identity Protection in Entra ID P2 erkennt anomale Service-Principal-Anmeldungen.
Cloud Token Detection & Hardening — Erkennung und Abhärtung
Die Erkennung von Token-Forgery-Angriffen ist eine der größten Herausforderungen in der Cloud-Security, weil gefälschte Tokens kryptografisch gültig sind — sie unterscheiden sich auf den ersten Blick nicht von legitimen Tokens. Die Erkennung muss daher auf Verhaltensanomalien, Token-Metadaten und Federation-Konfigurationsänderungen setzen. Microsoft hat nach SolarWinds erheblich in die Erkennungsfähigkeiten investiert — Sentinel und Defender for Cloud Apps bieten heute spezialisierte Detection Rules für diese Angriffsklasse.
- Token Lifetime & Issuer Anomalien: Golden-SAML-Tokens haben oft ungewöhnliche Lifetimes — Angreifer setzen lange Gültigkeitszeiträume, um seltener neue Tokens generieren zu müssen. Detection Rule: Vergleichen Sie die
NotBefore- undNotOnOrAfter-Werte in SAML-Assertions mit der konfigurierten Token-Lifetime-Policy in AD FS (Standard: 60 Minuten). Assertions mit Lifetimes über 120 Minuten sind verdächtig. Zusätzlich: Impossible Travel Detection — wenn ein Benutzer sich innerhalb von Minuten aus Frankfurt und Moskau anmeldet, ist das ein starkes Signal. Sentinel-KQL:SignInLogs | where ResultType == 0 | summarize locations=make_set(Location) by UserPrincipalName, bin(TimeGenerated, 10m) | where array_length(locations) > 1. - ADFS-Audit-Log-Korrelation — der fehlende Login: Die stärkste Erkennung für Golden SAML: Eine erfolgreiche Azure AD-Anmeldung via Federation (Sign-in Log zeigt
wsTrust/SAML), aber kein korrespondierender Authentifizierungseintrag im AD FS-Audit-Log (Event ID 1200/1202). Dies bedeutet: Der SAML-Token wurde außerhalb von AD FS generiert — ein klares Indiz für Golden SAML. Voraussetzung: AD FS Audit Logging muss aktiviert sein (Set-AdfsProperties -AuditLevel Verbose) und die AD FS-Logs müssen an das SIEM weitergeleitet werden. Sentinel Analytic Rule:AADSignInLogs | where AuthenticationProtocol == "wsFederation" | join kind=leftanti (ADFSAuditLogs | where EventID == 1200) on CorrelationId. - Certificate Rotation & Key Material Monitoring: Präventive Härtung: Token-Signing-Zertifikate alle 30 Tage rotieren (statt der Standard-Lifetime von 1 Jahr). Jede Rotation invalidiert alle mit dem alten Zertifikat signierten SAML-Tokens — der Angreifer muss das neue Zertifikat erneut stehlen. Automatisierung: AD FS unterstützt AutoCertificateRollover — aktivieren Sie es via
Set-AdfsProperties -AutoCertificateRollover $trueund setzen SieCertificateGenerationThresholdauf 20 Tage. Zusätzlich: Überwachen Sie den Zugriff auf den DKM-Container im AD — jeder Lesezugriff auf den DKM-Key sollte einen Alert auslösen (AD Audit Policy: „Audit Directory Service Access“ auf dem DKM-Objekt). Für maximale Sicherheit: Migrieren Sie von AD FS zu Cloud-nativer Authentifizierung (Password Hash Sync + Seamless SSO) — ohne AD FS gibt es kein Token-Signing-Zertifikat, das gestohlen werden kann. - Entra ID Token Protection & Conditional Access Härtung: Token Protection (ehemals Token Binding) in Entra ID bindet Tokens kryptografisch an das Gerät — ein gestohlener Token ist auf einem anderen Gerät wertlos. Aktivierung: Conditional Access Policy mit Require token protection for sign-in sessions (aktuell in Preview für Windows-Geräte). Conditional Access Hardening: Erstellen Sie Policies, die Compliant Device oder Hybrid Azure AD Join für alle Anwendungen erfordern — gefälschte SAML-Tokens erfüllen diese Bedingung nicht, da kein korrespondierendes Geräteobjekt existiert. Workload Identity Premium: Überwachen Sie Service Principals mit Risk-Based Conditional Access — anomale Anmeldemuster (neuer Standort, unbekannte IP) werden automatisch blockiert. Microsoft Sentinel Fusion: Korreliert automatisch Golden-SAML-Indikatoren aus verschiedenen Quellen (Sign-in Logs, AD FS Audit, Azure AD Audit) zu einem einzelnen High-Severity-Incident.
Sie benötigen Unterstützung?
Golden SAML und Cloud Token Forgery gehören zu den gefährlichsten Angriffsvektoren auf Cloud-Infrastrukturen. Wir implementieren AD FS-Härtung, konfigurieren Token Protection in Entra ID, erstellen Sentinel Detection Rules und führen Red-Team-Assessments für Ihre Federation-Architektur durch.
Security & Firewall ansehen →
