Azure App-Registrierungen: Sicherheitsrisiken

Was sind Azure App-Registrierungen und warum sind sie riskant?

Azure App-Registrierungen in Microsoft Entra ID geben Anwendungen eine Identität, damit sie sich gegenüber Microsoft Graph, Azure-Ressourcen und anderen APIs authentifizieren können. Jede interne Anwendung, jedes Automatisierungsskript, jede CI/CD-Integration und viele Drittanbieter-SaaS-Verbindungen im Tenant basieren am Ende auf genau solchen App-Registrierungen.

Azure App-Registrierungen sammeln sich im Laufe der Zeit wie Benutzerkonten an. Entwicklungsteams legen sie für Tests an und löschen sie nie wieder. Integrationen erhalten mehr Berechtigungen als nötig. Client-Secrets bleiben jahrelang gültig. Das Ergebnis ist ein Tenant mit Anwendungen, die Zugriff auf Postfächer, SharePoint, Teams-Daten oder Verzeichnisobjekte haben, ohne dass jemand den tatsächlichen Bedarf oder die Nutzung regelmäßig überprüft.

Wird eine App-Registrierung mit weitreichenden Microsoft-Graph-Berechtigungen kompromittiert, entspricht das häufig einer Kompromittierung eines privilegierten Benutzerkontos, nur mit weniger offensichtlichen Detection-Signalen.

Wie Azure App-Registrierungen funktionieren

Azure App-Registrierungen authentifizieren sich in Entra ID typischerweise auf zwei Arten:

Client-Secrets — Kennwörter für die Anwendung, häufig mit langen Laufzeiten
Zertifikate — X.509-Zertifikate für die App-Authentifizierung

Nach der Anmeldung handelt die Anwendung entsprechend ihrer API-Berechtigungen. Dabei gibt es zwei grundlegende Typen:

Delegated permissions — die App handelt im Kontext eines angemeldeten Benutzers
Application permissions — die App handelt ohne Benutzerkontext als eigene Identität

Gerade Application permissions sind kritisch. Eine App mit Mail.ReadWrite als Application Permission kann auf alle Postfächer im Tenant zugreifen. Eine App mit Directory.ReadWrite.All kann Verzeichnisobjekte ändern und je nach Konfiguration indirekt neue privilegierte Zugänge vorbereiten. Wenn diese Rechte an vergessene oder schlecht abgesicherte Anwendungen vergeben werden, reicht ein kompromittiertes Secret für dauerhaften API-Zugriff auf sensible Daten und Verwaltungsfunktionen.

Der Angriffsablauf

Schritt 1 - App-Registrierungen und Berechtigungen inventarisieren

Connect-MgGraph -Scopes "Application.Read.All"

Get-MgApplication -All | ForEach-Object {
    $app = $_
    $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
    $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

    [PSCustomObject]@{
        AppName      = $app.DisplayName
        AppId        = $app.AppId
        Created      = $app.CreatedDateTime
        SecretExpiry = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
        Permissions  = ($appRoles.AppRoleId | ForEach-Object { $_.ToString() }) -join ", "
    }
} | Where-Object {$_.Permissions -ne ""}

Schritt 2 - Anwendungen mit hohen Rechten und schwachen Secrets priorisieren

Priorität haben insbesondere:

Apps mit Mail.ReadWrite, Files.ReadWrite.All oder Directory.ReadWrite.All als Application Permission
Apps mit Client-Secrets, die sehr lange gültig sind
Apps, deren Secrets seit mehr als 12 Monaten nicht rotiert wurden
Apps ohne klaren Owner oder ohne dokumentierten Geschäftsbedarf

Schritt 3 - Secret-Leaks oder unsichere Ablage ausnutzen

Client-Secrets tauchen regelmäßig in Repositories, CI/CD-Variablen, Konfigurationsdateien oder auf Entwicklergeräten auf. Angreifer suchen gezielt nach geleakten Azure-Anwendungskennungen und kombinieren sie mit Tenant-Informationen, um Tokens für Microsoft Graph zu erhalten.

# Typisches Suchmuster in Repositories:
# "client_secret" oder "clientSecret" zusammen mit tenant IDs, app IDs oder login.microsoftonline.com

Schritt 4 - Als App authentifizieren und Daten oder Rechte missbrauchen

import msal

app = msal.ConfidentialClientApplication(
    client_id="APP_CLIENT_ID",
    client_credential="STOLEN_SECRET",
    authority="https://login.microsoftonline.com/TENANT_ID"
)
result = app.acquire_token_for_client(scopes=["https://graph.microsoft.com/.default"])
token = result["access_token"]

Mit einem gültigen Token hängen die nächsten Schritte von den vergebenen Rechten ab: Postfachzugriff, SharePoint-Exfiltration, Verzeichnisabfragen oder missbräuchliche Automatisierung gegen Entra- oder Azure-Ressourcen.

Erkennung

Microsoft Entra Audit-Logs

Ereignis	Wofür es wichtig ist
Add application	Neue App-Registrierungen außerhalb normaler Change-Fenster
Add password credential	Neues Client-Secret an bestehender App
Add service principal	Neue Enterprise App im Tenant
Consent to application	Benutzer- oder Admin-Consent für weitreichende Rechte

SIEM-Erkennung (Elastic KQL)

azure.auditlogs.operation_name: "Add password credential to service principal" AND
NOT azure.auditlogs.properties.initiated_by.user.roles: "*Admin*"

azure.signinlogs.properties.app_display_name: (* AND NOT "Microsoft*") AND
azure.signinlogs.properties.user_type: "servicePrincipal" AND
azure.signinlogs.properties.risk_level_during_sign_in: ("high" OR "medium")

💡 Hinweis: Route Microsoft-Graph- und Entra-Audit-Logs in das SIEM. Ungewohnlicher API-Zugriff durch Service Principals ist oft das früheste belastbare Signal für Missbrauch einer App-Registrierung.

Remediation

💡 Quick Win: Prüfen Sie zuerst alle Anwendungen mit Directory.ReadWrite.All, Mail.ReadWrite oder ähnlich breiten Application Permissions. Jede davon ist ein möglicher Tenant-weitriger Missbrauchspfad.

1. Ungenutzte oder verwaiste App-Registrierungen entfernen

Connect-MgGraph -Scopes "Application.Read.All"

Get-MgApplication -All | Select-Object DisplayName, AppId, CreatedDateTime,
    @{N="SecretCount";E={$_.PasswordCredentials.Count}},
    @{N="LatestSecretExpiry";E={($_.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime}}

Kombinieren Sie diese Inventarisierung mit den Service-Principal-Sign-ins und Audit-Logs im Entra Admin Center, um Apps ohne aktuelle Nutzung oder ohne verantwortlichen Owner zu identifizieren.

2. Alte oder bald ablaufende Secrets rotieren

Get-MgApplication -All | ForEach-Object {
    $_.PasswordCredentials | Where-Object {$_.EndDateTime -lt (Get-Date).AddDays(30)} |
        Select-Object @{N="App";E={$_.DisplayName}}, EndDateTime
}

3. Hochprivilegierte Apps auf Zertifikate umstellen

Client-Secrets sind leichter zu leaken als Zertifikate. Für privilegierte Anwendungen sollte daher bevorzugt zertifikatsbasierte Authentifizierung genutzt werden.

$cert = New-SelfSignedCertificate -Subject "CN=AppName" -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyExportPolicy Exportable -KeySpec Signature -NotAfter (Get-Date).AddYears(2)

4. Berechtigungen auf Least Privilege zurückführen

Prüfen Sie jede App-Registrierung darauf, ob breite Rechte durch kleinere Scopes ersetzt werden können:

Mail.ReadWrite nur behalten, wenn Schreibzugriff wirklich nötig ist
Directory.ReadWrite.All nur in eng begründeten Ausnahmefällen zulassen
wo möglich Delegated permissions statt Application permissions verwenden
Owner, Ablaufdaten und Ausnahmefreigaben verbindlich dokumentieren

Wie EtcSec das erkennt

EtcSec auditiert alle App-Registrierungen und Service Principals im Azure-Tenant.

Die Prüfungen in der Kategorie Applications erkennen insbesondere:

Apps mit zu breiten Application Permissions wie Directory.ReadWrite.All, Mail.ReadWrite.All oder Files.ReadWrite.All
Apps mit abgelaufenen oder bald ablaufenden Secrets
Apps ohne aktuelle Nutzung oder ohne dokumentierte Eigentümerschaft
riskante Consent-Vorgänge und Anwendungen ohne saubere Governance

ℹ️ Hinweis: EtcSec prüft Azure App-Registrierungen und Berechtigungen automatisch im Tenant-Audit. Ein kostenloser Audit zeigt, welche Anwendungen zu breit berechtigt oder operativ verwaist sind.

Prufprioritaten

Azure App-Registrierungen: Die Überprivilegierten Anwendungen in Ihrem Tenant sollte als reale Exposition in Ihren Entra-ID- und Azure-Tenant behandelt werden und nicht als einzelner isolierter Fehler. Zuerst muss der tatsachliche Prufumfang definiert werden: welche Admins, Gastkonten, Service Principals, App Registrations, Policy-Ausnahmen und Break-Glass-Konten betroffen sind, welche Geschaftsprozesse davon abhangen, welche Privilegien freigelegt werden und welche Notfallausnahmen sich mit der Zeit angesammelt haben. Diese Einordnung verhindert oberflachliche Remediation, weil das technische Symptom oft kleiner ist als der operative Blast Radius. Wenn der gesamte Pfad von Konfiguration uber Berechtigung bis zur Nutzung dokumentiert ist, kann das Team Anderungen priorisieren, die Risiko schnell reduzieren, ohne den Betrieb zu blockieren.

Benachbarte Kontrollen Mitprufen

Sobald Angreifer in Ihren Entra-ID- und Azure-Tenant angekommen sind, bleiben sie selten beim ersten Schwachpunkt stehen. Rund um Azure App-Registrierungen: Die Überprivilegierten Anwendungen in Ihrem Tenant testen sie meist, ob sich der Zugang mit Legacy-Auth, schwache Gast-Governance, zu breite App-Consents, veraltete Notfallkonten und nie geprufte Rollen verketten lasst. Deshalb muss die Verteidigung nicht nur die Hauptschwache, sondern auch jede benachbarte Abhangigkeit prufen, die initialen Zugriff in Persistenz oder Eskalation verwandeln kann. Klarheit uber Identitaten, Rollen, Rechte und Vertrauensannahmen ist hier entscheidend. Wenn ein Fix nur ein einzelnes Objekt schliesst, wahrend benachbarte Privilegpfade offen bleiben, verandert sich das reale Risiko kaum. Eine saubere Kettenanalyse ist daher zentral fur eine belastbare Härtung.

Belege und Telemetrie sammeln

Eine belastbare Reaktion auf Azure App-Registrierungen: Die Überprivilegierten Anwendungen in Ihrem Tenant braucht Belege, die Technik, Detection und Governance gemeinsam auswerten konnen. Ziehen Sie Anmeldeprotokolle, Audit-Logs, Rollenanderungen, Consent-Ereignisse, Secret-Rotation und Risk-Signale, vergleichen Sie frische Anderungen mit geplanten Wartungsfenstern und isolieren Sie Konten oder Objekte mit Verhalten ohne klare Geschaftsbegrundung. Diese Belege sollten drei Fragen beantworten: wann die Exposition entstanden ist, wer sie noch nutzen kann, und ob gleichartige Pfade an anderer Stelle in Ihren Entra-ID- und Azure-Tenant existieren. Gute Telemetrie trennt ausserdem alte technische Schuld von aktiv ausnutzbarem Verhalten. Diese Trennung ist wichtig, weil die Remediation fur Altlasten anders gesteuert wird als fur eine Schwache mit deutlichen Missbrauchssignalen.

Benachbarte Schwachen mitprufen

Kaum eine Umgebung enthalt Azure App-Registrierungen: Die Überprivilegierten Anwendungen in Ihrem Tenant allein. In der Praxis finden sich in derselben Tenant- oder AD-Zone oft auch Legacy-Auth, schwache Gast-Governance, zu breite App-Consents, veraltete Notfallkonten und nie geprufte Rollen, und genau diese Nachbarschwachen entscheiden, ob der Pfad nur unsauber oder wirklich kritisch ist. Prufen Sie gemeinsame Owner, geerbte Rechte, doppelte Ausnahmen und administrative Abkurzungen, die nie zuruckgebaut wurden. Wenn dieselbe risikoreiche Entscheidung an mehreren Stellen auftaucht, liegt meist ein Prozessproblem und nicht nur ein Einzelfehler vor. Diese erweiterte Sicht verbessert die Chance, den gesamten Angriffspfad zu entfernen statt nur eine sichtbare Stelle zu glatten.

Remediation in sinnvoller Reihenfolge

Bei Azure App-Registrierungen: Die Überprivilegierten Anwendungen in Ihrem Tenant sollte die Remediation zuerst dort ansetzen, wo Risiko am schnellsten sinkt. Entfernen Sie zunachast die Pfade mit dem hochsten Eskalationswert, harten Sie danach die wichtigsten Identitaten oder Objekte, und bereinigen Sie erst anschliessend sekundare Hygieneprobleme. Nutzen Sie Conditional Access, PIM, Least Privilege, Access Reviews, App-Owner-Prufungen, Genehmigungsablaufe und starkes MFA als Zielbild. Jede Anderung braucht einen Verantwortlichen, eine Rollback-Notiz und einen klaren Validierungsschritt. So verhindert man, dass ein Verbesserungsprojekt nach dem ersten technischen Erfolg stehen bleibt. Wenn ein kompletter Umbau heute nicht realistisch ist, definieren Sie Zwischenkontrollen und planen Sie die strukturelle Arbeit in den nachsten wochentliche Betriebsprufung und monatliche Härtungsprufung.

Validierung im Betrieb

Vor dem Abschluss der Massnahme sollten dieselben Prufschritte erneut ausgefuhrt werden, die das Risiko ursprunglich sichtbar gemacht haben. Bestatigen Sie, dass der problematische Pfad aus Sicht eines Angreifers verschwunden ist, dass zugehorige Rechte, Gruppen, Ausnahmen und Abhangigkeiten sauber dokumentiert sind und dass die neue Konfiguration im laufenden Betrieb tragfahig bleibt. Diese Schlussprufung trennt eine formale Anderung von einer echten Risikoreduktion.

Validierung der App-Governance

Nach der Bereinigung von App-Registrierungen sollte das Team prufen, welche Anwendungen weiterhin weitreichende API-Berechtigungen behalten, welche Administratoren neue Einwilligungen erteilen durfen und wie Ausnahmegenehmigungen dokumentiert werden. Entscheidend ist nicht nur die Berechtigungsliste, sondern auch, ob Eigentumer, Ablaufdaten und Uberwachungsregeln fur riskante Anwendungen klar festgelegt sind. Erst diese Governance verhindert, dass uberprivilegierte Apps kurz nach der Bereinigung erneut entstehen.

Einwilligungen und Ausnahmeprozesse Prufen

Zusatzlich sollte das Team regelmassig prufen, wer Tenant-weite Einwilligungen erteilen darf, wie Ausnahmen fur riskante Anwendungen freigegeben werden und ob verwaiste App-Registrierungen noch nachvollziehbare Eigentumer haben. Diese Governance-Fragen entscheiden oft daruber, ob uberprivilegierte Anwendungen dauerhaft verschwinden oder in kurzer Zeit erneut entstehen.

Kontinuierliche Kontrolle nach der Bereinigung

Nach der ersten Bereinigung sollte das Team fortlaufend prufen, welche neuen App-Registrierungen entstehen, welche Berechtigungen besonders haufig angefordert werden und ob auffallige Consent-Vorgange schnell untersucht werden. Diese laufende Kontrolle macht sichtbar, ob die Tenant-Governance tatsachlich verbessert wurde oder ob riskante Muster nur kurzzeitig verschwunden sind.