Entra-Persistenz erkennen: OAuth-Consent, Service Principal, Rollen und Conditional Access

Entra-Persistenz erkennen ist die Cloud-Variante der Frage, die sich jedes Blue Team nach einer Kontoübernahme stellt: Wie sorgt der Angreifer dafür, dass er drinbleibt, auch wenn das gephishte Passwort zurückgesetzt wird? In der klassischen Domäne sind das AD-Hintertüren; in Entra ID und Microsoft 365 verschiebt sich das auf die Identitäts- und Steuerungsebene. Dort braucht Persistenz keine Schadsoftware und keinen Endpunkt, sondern nur einen legitimen API-Aufruf: ein Consent, ein Secret, eine Rollenzuweisung, eine Authentifizierungsmethode, eine Richtlinienänderung. Jeder dieser Vorgänge ist im Entra-Audit-Log sichtbar, und genau dort setzt dieser Beitrag an. Er behandelt nicht allgemeine Entra-Sicherheit, sondern die fünf konkreten Persistenz- und Manipulationsmechanismen, ihre Audit-Operationen, fünf Sigma-Regeln, vier KQL-Abfragen für Microsoft Sentinel, die Lizenzlage, die Härtung und einen Lab-Test. Die übergreifende Cloud-Perspektive steht im Pillar Cloud-Sicherheit für Blue Teams, die Anmelde-Anomalien bei Valid Accounts und MFA-Phishing und Token-Diebstahl.

Was der Angreifer tut

Fünf Mechanismen tragen die Entra-Persistenz. Sie lassen sich einzeln oder kombiniert einsetzen, und jeder hat eine eigene Audit-Spur.

A. OAuth- und App-Consent

Der Angreifer registriert eine eigene Anwendung oder bringt das Opfer per Consent-Phishing dazu, einer App Zugriff zu gewähren. Mit erteiltem Consent hält die App ein Refresh-Token und kommt dauerhaft an Postfach, Dateien oder Verzeichnis, ganz ohne Passwort und oft ohne erneute MFA. Sichtbar sind die neue App-Registrierung oder Enterprise Application, die neuen oder erweiterten OAuth-Berechtigungen, der Admin- oder Benutzer-Consent und die Consent-Grants. Wichtig: App-Consent ist nicht automatisch bösartig, denn das Onboarding jeder legitimen SaaS-Anwendung erzeugt dieselben Vorgänge. Verdächtig machen es der ungewöhnliche Publisher, ein fremder Tenant-Kontext, weitreichende Graph-Berechtigungen und ein ungewöhnlicher erteilender Principal.

B. Service-Principal-Credentials

Statt einer neuen App nutzt der Angreifer eine bestehende: Er hängt an einen Dienstprincipal oder eine App-Registrierung ein neues Client Secret oder ein Zertifikat (Key Credential). Danach meldet er sich jederzeit als diese Identität an. Besonders gefährlich ist die Credential-Erweiterung an einer bestehenden, produktiven App mit hohen Berechtigungen, weil sie im Rauschen der regulären Secret-Rotation untergeht. Die Spur ist die Audit-Operation zum Hinzufügen der Credential, bewertet nach ausführendem Actor, Zielobjekt und Zeitpunkt.

C. Privilegierte Rollen

Der Angreifer weist sich selbst, einem kontrollierten Benutzer oder einem Dienstprincipal eine privilegierte Verzeichnisrolle zu, etwa Global Administrator oder Privileged Role Administrator. Entscheidend ist der Unterschied zwischen einer dauerhaften Zuweisung und einer zeitlich begrenzten Aktivierung über Privileged Identity Management (PIM): Eine dauerhafte Rolle, besonders an einem Dienstprincipal (der weder PIM noch MFA durchläuft), ist ein klares Persistenzsignal. Eine ungewöhnliche privilegierte Rolle an einem unerwarteten Ziel gehört immer geprüft.

D. Authentifizierungsmethoden und MFA

Nach einer Kontoübernahme fügt der Angreifer dem Konto eine eigene MFA-Methode hinzu, einen Authenticator, eine Telefonnummer, einen FIDO2-Schlüssel oder einen Passkey. Danach übersteht sein Zugang einen Passwort-Reset, weil er den zweiten Faktor selbst kontrolliert. Hier ist Zurückhaltung geboten: Die Audit-Telemetrie für Authentifizierungsmethoden unterscheidet sich je nach Tenant und Pipeline, und die Self-Service-Registrierung durch den Benutzer selbst ist der häufige, legitime Normalfall. Es werden nur die Operationen ausgewertet, die die eigene Telemetrie tatsächlich liefert; es werden keine Felder oder OperationNames erfunden.

E. Conditional Access

Conditional Access ist die zentrale Zugriffskontrolle. Wer sie schwächt, öffnet den Zugang dauerhaft: eine Richtlinie wird erstellt, geändert oder deaktiviert, ein Benutzer oder eine Gruppe wird ausgeschlossen, eine MFA-Anforderung entfernt. Häufig folgt darauf eine Anmeldung ohne MFA. Named Locations und Trust Controls sind nur dort auszuwerten, wo die Telemetrie sie hergibt; der Kern ist die Änderung an der Richtlinie selbst mit ihrem alten und neuen Zustand.

Welche Logquellen die Technik zeigen

Voraussetzung. Entra-Audit- und Anmeldeprotokolle sind in jedem Tenant vorhanden, werden im Portal aber nur begrenzt aufbewahrt. Für belastbare Erkennung werden sie über die Diagnoseeinstellungen nach Log Analytics beziehungsweise Microsoft Sentinel exportiert; erst dort stehen sie für Sigma-Übersetzung, KQL und Korrelation zur Verfügung. Dass die Feldnamen je Export- und SIEM-Pipeline unterschiedlich normalisiert werden, ist der Normalfall und wird unten bei den Regeln als Portabilitätsfrage behandelt.

Das Muster im Log: mehrstufig denken

Wie in der ganzen Cloud ist Erkennung hier ein Korrelationsproblem, kein Telemetrieproblem. Ein einzelnes Audit-Event ist selten ein Beweis; die Aussage entsteht aus der Kette:

1. Eine sicherheitsrelevante Konfiguration wird geändert (Consent, Secret, Rolle, MFA-Methode, Conditional Access).
2. Der ausführende Actor oder das Ziel ist ungewöhnlich (ein Benutzer, der nie Apps verwaltet; ein Dienstprincipal als Ziel einer Rolle; ein Konto von neuer IP).
3. Ein Privileg oder eine Credential wird erweitert (weitreichende Graph-Berechtigung, Global Admin, neues Secret).
4. Danach folgt eine Anmeldung oder Token-Nutzung (Dienstprincipal-Sign-in, Anmeldung ohne MFA nach einer CA-Änderung).
5. Gegebenenfalls folgt Aktivität in Exchange, SharePoint oder Azure (Postfachzugriff, Datei-Download, Ressourcenzugriff).

Typische belastbare Ketten: ein neues Secret an einer bestehenden produktiven App, gefolgt von deren erster Dienstprincipal-Anmeldung aus einer neuen Region; ein Admin-Consent an eine unbekannte App mit Mail.ReadWrite; eine privilegierte Rolle an einen Dienstprincipal; eine neue MFA-Methode kurz vor einer ungewöhnlichen Anmeldung; eine deaktivierte CA-Richtlinie, gefolgt von einem Sign-in ohne MFA. Die einzelnen Audit-Events liegen alle im AuditLogs-Strom, aber erst ihre Verknüpfung mit den Sign-in-Logs ergibt die Erkennung. Die Sigma-Regeln unten decken die einzelnen Änderungen ab; die KQL-Abfragen und die Checkliste stellen die Verbindung her.

Fünf Sigma-Regeln

Die Regeln nutzen die Sigma-Azure-Logsource (product azure, service auditlogs) und das Operationsfeld properties.message. Weil Entra-Felder je Backend stark variieren, sind sie defensiv formuliert: Sie matchen auf die Operation, nicht auf fragile Detailfelder, und jede Regel trägt einen Portabilitätshinweis. Die erste Regel erfasst die neue Service-Principal-Credential.

title: Neue Credential an Entra-Dienstprincipal oder App-Registrierung hinzugefuegt
id: 0ea4a8ac-8177-4a6f-9bcc-d17ad11bea26
status: experimental
description: |
  Eintrag im Entra-ID-Auditprotokoll, bei dem einem Dienstprincipal (Enterprise
  Application) oder einer App-Registrierung eine neue Credential hinzugefuegt wird -
  ein Client Secret oder ein Zertifikat/Key Credential. Die kanonische Operation ist
  "Add service principal credentials"; das Hinzufuegen von Secrets oder Zertifikaten an
  einer App-Registrierung erscheint je nach Oberflaeche unter einer eigenen Operation
  zum Zertifikats- und Secret-Management. Eine neue Credential an einer bestehenden,
  produktiven App ist ein klassischer Entra-Persistenzweg (ATT&CK T1098.001): Der
  Angreifer kann sich danach jederzeit ohne Benutzer und ohne MFA als diese Identitaet
  anmelden. Entscheidend ist der Kontext - wer (InitiatedBy) hat die Credential an
  welchem Zielobjekt (TargetResources) wann hinzugefuegt, und folgt darauf eine
  Dienstprincipal-Anmeldung. Portabilitaet: Das Feld fuer die Operation heisst in der
  Sigma-Azure-Taxonomie properties.message; manche Pipelines liefern es als
  OperationName oder ActivityDisplayName. Pro Umgebung pruefen.
references:
  - https://attack.mitre.org/techniques/T1098/001/
author: blue-team.net
date: 2026-10-10
tags:
  - attack.persistence
  - attack.privilege-escalation
  - attack.t1098.001
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    properties.message:
      - 'Add service principal credentials'
      - 'Add application credentials'
  condition: selection
falsepositives:
  - Geplantes App-Onboarding, CI/CD-Automatisierung und regulaere Secret-Rotation bzw. Zertifikatserneuerung durch bekannte Konten - Actor, Ziel-App und Change-Ticket abgleichen; bekannte Automation allowlisten
  - Verwaltungswerkzeuge und Provisioning-Dienste, die Credentials planmaessig setzen
level: medium

Die zweite Regel erfasst den OAuth-Consent und die Vergabe delegierter Berechtigungen.

title: OAuth-Consent oder delegierte Berechtigung an eine Entra-Anwendung erteilt
id: 4a05a238-7fd3-4b8f-bfc0-0018e4d9662b
status: experimental
description: |
  Eintrag im Entra-ID-Auditprotokoll, bei dem einer Anwendung Zugriff gewaehrt wird:
  die Operation "Consent to application" (Benutzer- oder Admin-Consent) oder
  "Add delegated permission grant". Angreifer nutzen Consent-Phishing und selbst
  registrierte Apps, um dauerhaften, token-basierten Zugriff auf Postfaecher, Dateien
  oder das Verzeichnis zu erhalten, ganz ohne Passwort des Opfers. Das Einbinden einer
  OAuth-App als dauerhafter Zugang ist ATT&CK T1671 (Cloud Application Integration); das
  Erlangen oder Nutzen des App-Tokens ist der Folgepfad T1528. Ein
  Admin-Consent, der einer App weitreichende Microsoft-Graph-Berechtigungen gibt (etwa
  Mail.ReadWrite, Files.ReadWrite.All oder Directory-Rollen), ist besonders kritisch.
  Wichtig: App-Consent ist nicht automatisch boesartig - das Onboarding legitimer
  SaaS-Dienste erzeugt dieselbe Operation. Entscheidend sind der erteilende Principal
  (InitiatedBy), die Ziel-App und ihr Publisher (TargetResources) sowie die Frage, ob
  die App und ihr Herausgeber zum Unternehmen gehoeren. Portabilitaet: Operation in der
  Sigma-Azure-Taxonomie als properties.message; manche Pipelines liefern OperationName.
references:
  - https://attack.mitre.org/techniques/T1671/
author: blue-team.net
date: 2026-10-10
tags:
  - attack.persistence
  - attack.t1671
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    properties.message:
      - 'Consent to application'
      - 'Add delegated permission grant'
  condition: selection
falsepositives:
  - Onboarding bekannter SaaS-Anwendungen und genehmigter interner Apps - App-ID und Publisher allowlisten, mit Admin-Consent-Workflow abgleichen
  - Breit ausgerolltes Benutzer-Consent (nur sinnvoll, solange User Consent nicht ohnehin restriktiv gesetzt ist)
level: medium

Die dritte Regel erfasst die dauerhafte Zuweisung einer privilegierten Verzeichnisrolle und nimmt die legitime PIM-Aktivierung aus.

title: Privilegierte Entra-Verzeichnisrolle dauerhaft zugewiesen
id: c5312867-a9e4-41a6-a871-744cb9e7aef5
status: experimental
description: |
  Eintrag im Entra-ID-Auditprotokoll mit der Operation "Add member to role": Einem
  Benutzer oder einem Dienstprincipal wird dauerhaft (nicht ueber eine zeitlich
  begrenzte PIM-Aktivierung) eine Verzeichnisrolle zugewiesen. Kritisch sind
  privilegierte Rollen wie Global Administrator, Privileged Role Administrator,
  Application Administrator, Privileged Authentication Administrator oder
  Hybrid Identity Administrator; die Zuweisung an einen Dienstprincipal ist besonders
  auffaellig, weil Workload-Identitaeten selten eine Verzeichnisrolle brauchen und
  diese zudem nicht von PIM oder MFA gebremst werden (ATT&CK T1098.003). Die
  Rollenzuweisung ueber eine PIM-Aktivierung erscheint als eigene Operation
  ("Add member to role completed (PIM activation)") und ist der legitime Normalfall;
  diese Regel zielt auf die direkte, dauerhafte Zuweisung. Der Rollenname steht in
  TargetResources/ModifiedProperties, der ausloesende Principal in InitiatedBy.
  Portabilitaet: Operation in der Sigma-Azure-Taxonomie als properties.message.
references:
  - https://attack.mitre.org/techniques/T1098/003/
author: blue-team.net
date: 2026-10-10
tags:
  - attack.persistence
  - attack.privilege-escalation
  - attack.t1098.003
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    properties.message: 'Add member to role'
  filter_pim:
    properties.message|contains: 'PIM activation'
  condition: selection and not filter_pim
falsepositives:
  - Geplante Rollenvergabe durch das Identity-Team und PIM-Aktivierungen (dauerhafte Zuweisung sollte die Ausnahme sein) - mit Change-Ticket und Rollenmodell abgleichen
  - Automatisierte Provisioning-Prozesse, die Rollen vergeben; bekannte Konten allowlisten, Vergabe an Dienstprincipals aber scharf halten
level: high

Die vierte Regel erfasst das Registrieren einer Authentifizierungsmethode. Sie steht bewusst auf Stufe mittel, weil die Self-Service-Registrierung der Haupt-Fehlalarm ist, und wertet nur die Operationen aus, die die eigene Telemetrie liefert.

title: Authentifizierungsmethode an einem Entra-Konto registriert
id: c68cde1a-d388-477e-a020-b593dfe7abdc
status: experimental
description: |
  Eintrag im Entra-ID-Auditprotokoll, bei dem einem Konto eine Sicherheitsinformation
  bzw. Authentifizierungsmethode hinzugefuegt wird - die Operationen
  "User registered security info" und "Admin registered security info". Fuegt ein
  Angreifer nach einer Kontouebernahme eine eigene MFA-Methode hinzu (Authenticator,
  Telefonnummer, FIDO2-Schluessel oder Passkey), haelt er den Zugang auch nach einem
  Passwort-Reset (ATT&CK T1556.006). Besonders auffaellig ist die admin-initiierte
  Registrierung an einem fremden Konto und die Registrierung kurz vor oder nach einer
  ungewoehnlichen Anmeldung. Wichtig: Die Self-Service-Registrierung durch den Benutzer
  selbst ist der haeufige, legitime Normalfall und der zu erwartende Haupt-Fehlalarm;
  diese Regel ist nur im Kontext belastbar (ungewoehnlicher Actor, ungewoehnliche IP,
  zeitliche Naehe zu einer verdaechtigen Anmeldung). Nur die Operationen verwenden, die
  die eigene Audit-Telemetrie tatsaechlich liefert - die genauen OperationNames je
  Tenant und Pipeline im Lab pruefen. Portabilitaet: properties.message in der
  Sigma-Azure-Taxonomie; manche Pipelines liefern OperationName/ActivityDisplayName.
references:
  - https://attack.mitre.org/techniques/T1556/006/
author: blue-team.net
date: 2026-10-10
tags:
  - attack.persistence
  - attack.credential-access
  - attack.defense-impairment
  - attack.t1556.006
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    properties.message:
      - 'User registered security info'
      - 'Admin registered security info'
  condition: selection
falsepositives:
  - Self-Service-Registrierung und regulaere MFA-Einrichtung durch den Benutzer selbst (Haupt-Fehlalarm) - nur im Kontext von Actor, IP und zeitlicher Naehe zu auffaelligen Anmeldungen bewerten
  - MFA-Reset und Geraetewechsel durch Helpdesk/Administration im Rahmen eines Tickets
level: medium

Die fünfte Regel erfasst das Erstellen, Ändern oder Löschen einer Conditional-Access-Richtlinie.

title: Conditional-Access-Richtlinie erstellt, geaendert oder geloescht
id: 512e44cd-92e9-4742-bcaa-f49559c858a6
status: experimental
description: |
  Eintrag im Entra-ID-Auditprotokoll mit einer Operation an einer
  Conditional-Access-Richtlinie: "Update conditional access policy",
  "Add conditional access policy" oder "Delete conditional access policy". Conditional
  Access ist die zentrale Zugriffskontrolle in Entra; wer sie schwaecht, oeffnet den
  Zugang dauerhaft (ATT&CK T1556.009). Typische Missbrauchsmuster: eine Richtlinie wird
  deaktiviert oder geloescht, eine MFA-Anforderung entfernt, oder das eigene Konto bzw.
  eine Gruppe wird von einer Richtlinie ausgeschlossen - haeufig gefolgt von einer
  Anmeldung ohne MFA. Der neue und der alte Zustand stehen in ModifiedProperties, der
  ausloesende Principal in InitiatedBy. Welche Richtlinie genau geaendert wurde und ob
  dabei eine Kontrolle (MFA, Geraetekonformitaet) entfernt oder ein Ausschluss
  hinzugefuegt wurde, entscheidet ueber die Kritikalitaet; ein reiner Report-only-Toggle
  ist harmlos. Named Locations und Trust Controls erscheinen als eigene Operationen und
  sind nur dort auszuwerten, wo die Telemetrie sie liefert. Portabilitaet:
  properties.message in der Sigma-Azure-Taxonomie; manche Pipelines liefern OperationName.
references:
  - https://attack.mitre.org/techniques/T1556/009/
author: blue-team.net
date: 2026-10-10
tags:
  - attack.defense-impairment
  - attack.persistence
  - attack.credential-access
  - attack.t1556.009
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    properties.message:
      - 'Update conditional access policy'
      - 'Add conditional access policy'
      - 'Delete conditional access policy'
  condition: selection
falsepositives:
  - Geplanter Conditional-Access-Rollout und regulaere Pflege durch das Identity-Team - mit Change-Ticket abgleichen; den neuen gegen den alten Zustand (ModifiedProperties) vergleichen
  - Automatisierung (Infrastructure as Code, Policy-Deployment-Pipelines) - bekannten Dienstprincipal allowlisten, Aenderungen ausserhalb der Pipeline aber scharf halten
level: medium

Alle fünf Regeln sind mit sigma-cli geprüft. Das heißt: syntaktisch korrekt und gegen das verwendete ATT&CK-Dataset validiert, nicht produktiv getestet. Der entscheidende Punkt ist die Portabilität: properties.message ist die Sigma-Azure-Konvention für den Operationsnamen, aber je nach Export (Diagnoseeinstellungen, Graph API, UAL) und SIEM-Mapping kommt die Operation als OperationName, ActivityDisplayName oder in einem anbieterspezifischen Feld an, und die exakten Zeichenketten der OperationNames unterscheiden sich zwischen Tenants und ändern sich mit der Zeit. Die Regeln sind deshalb als Ausgangspunkt zu verstehen, der gegen die eigene Audit-Telemetrie kalibriert wird; die KQL-Abfragen unten zeigen dieselben Erkennungen direkt auf den Sentinel-Tabellen. Die Übersetzung in andere Backends steht im Beitrag zu Sigma-Regeln.

KQL für die Jagd in Microsoft Sentinel

In Sentinel oder im Log-Analytics-Arbeitsbereich mit angebundenen Entra-Logs lassen sich dieselben Erkennungen direkt abfragen. Alle Abfragen setzen voraus, dass Audit- und Anmeldeprotokolle von Entra ID per Diagnoseeinstellung in den Arbeitsbereich exportiert werden.

1. Neue Service-Principal- oder App-Credential. Zweck: alle neu hinzugefügten Secrets und Zertifikate finden. Voraussetzung: Tabelle AuditLogs. Wichtige Felder: OperationName, TargetResources, InitiatedBy. Tuning: bekannte CI/CD- und Provisioning-Konten in der letzten Zeile ausnehmen.

AuditLogs
| where OperationName in ("Add service principal credentials", "Add application credentials")
| extend TargetApp = tostring(TargetResources[0].displayName)
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| extend ActorApp  = tostring(InitiatedBy.app.displayName)
| project TimeGenerated, OperationName, TargetApp, ActorUser, ActorApp, Result
| sort by TimeGenerated desc

2. Admin- oder Benutzer-Consent an eine Anwendung. Zweck: erteilte Consents samt App und Herausgeber sichten. Voraussetzung: Tabelle AuditLogs. Wichtige Felder: OperationName, TargetResources, InitiatedBy, AdditionalDetails (enthält die eingeräumten Berechtigungen). Tuning: bekannte, genehmigte App-IDs ausnehmen und den Admin-Consent-Workflow als Referenz nehmen.

AuditLogs
| where OperationName in ("Consent to application", "Add delegated permission grant")
| extend TargetApp = tostring(TargetResources[0].displayName)
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, TargetApp, ActorUser, AdditionalDetails, Result
| sort by TimeGenerated desc

3. Dienstprincipal-Anmeldung nach einer neuen Credential. Zweck: die Kette Credential-Zusatz, dann Anmeldung sichtbar machen. Voraussetzung: Tabellen AuditLogs und AADServicePrincipalSignInLogs (Letztere muss als Diagnosekategorie aktiviert sein). Wichtige Felder: ServicePrincipalId, AppId, IPAddress. Tuning: Zeitfenster und erwartete Herkunfts-IPs anpassen.

let NewCreds =
    AuditLogs
    | where OperationName == "Add service principal credentials"
    | extend sp = tostring(TargetResources[0].id)
    | project CredTime = TimeGenerated, sp;
AADServicePrincipalSignInLogs
| join kind=inner NewCreds on $left.ServicePrincipalId == $right.sp
| where TimeGenerated between (CredTime .. (CredTime + 7d))
| project TimeGenerated, ServicePrincipalName, AppId, IPAddress, CredTime

4. Conditional-Access-Richtlinie geändert. Zweck: jede Erstellung, Änderung oder Löschung einer CA-Richtlinie sichten und alten gegen neuen Zustand vergleichen. Voraussetzung: Tabelle AuditLogs. Wichtige Felder: OperationName, TargetResources, InitiatedBy, ModifiedProperties. Tuning: bekannte Policy-Deployment-Pipelines ausnehmen.

AuditLogs
| where OperationName in ("Update conditional access policy", "Add conditional access policy", "Delete conditional access policy")
| extend Policy = tostring(TargetResources[0].displayName)
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, Policy, ActorUser, Result
| sort by TimeGenerated desc

Lizenz- und Datenabhängigkeiten

• Standardmäßig vorhanden. Das Entra-Audit- und das Anmeldeprotokoll gibt es in jedem Tenant, auch ohne kostenpflichtige Lizenz. Die Audit-Operationen für Consent, Service-Principal-Credentials, Rollenzuweisung und Conditional-Access-Änderungen existieren dort ohne Zusatzlizenz. Eine pauschale Aussage "braucht Entra P2" ist also falsch, solange es nur um diese Audit-Events geht.
• Wo P1 oder P2 nötig ist. Conditional Access selbst setzt Entra ID P1 voraus (ohne P1 gibt es keine CA-Richtlinien und damit keine CA-Audit-Events). Privileged Identity Management (PIM) und damit die zeitlich begrenzte, genehmigungspflichtige Rollenaktivierung sowie die risikobasierten Signale der Identity Protection setzen Entra ID P2 voraus. P2 ist also dort zu nennen, wo es um PIM-Workflow oder Risiko geht, nicht für die reine Rollenzuweisung.
• Retention. Die Standardaufbewahrung im Entra-Portal beträgt nach aktueller Microsoft-Dokumentation für Audit- und Anmeldeprotokolle sieben Tage ohne kostenpflichtige Lizenz und dreißig Tage mit Entra ID P1 oder P2 (P1 und P2 sind hier gleich). Längere Aufbewahrung und mehrstufige Korrelation gibt es nur über den Export.
• Export zu Sentinel oder SIEM. Über die Diagnoseeinstellungen gehen AuditLogs, SigninLogs und AADServicePrincipalSignInLogs nach Log Analytics, Microsoft Sentinel, einen Event Hub oder einen Speicher. Erst der Export macht Sigma-Übersetzung, die KQL-Abfragen oben und mehrstufige Korrelation möglich und sichert die Daten vor dem begrenzten Portal-Fenster.

Blindspots

• Bestehende Persistenz. Eine Credential, ein Consent oder eine Rolle, die vor Beginn der Protokollierung oder vor dem Export eingerichtet wurde, erzeugt kein Änderungsereignis. Sie findet nur ein Inventar (App-Registrierungen, Credentials mit Ablaufdatum, Rollenzuweisungen, Enterprise Applications), nicht die Detection.
• Feld- und Namensdrift. OperationNames und Feldstrukturen ändern sich mit der Zeit und je nach Export. Eine Regel, die auf eine exakte Zeichenkette matcht, kann still verfehlen, wenn Microsoft den Namen anpasst. Deshalb die Kalibrierung gegen die eigene Telemetrie und die regelmäßige Kontrolle.
• Legitimer Zugang nach der Änderung. Nutzt der Angreifer die eingerichtete Persistenz unauffällig (Dienstprincipal-Anmeldung aus derselben Region, zu normaler Zeit), ist die Folgeaktivität schwer von legitimem Verkehr zu trennen. Dann trägt nur die Konfigurationsänderung selbst.
• UAL gegen Entra-Audit-Log. Dasselbe Ereignis kann im Microsoft-365-UAL und im Entra-Audit-Log unterschiedlich heißen und andere Felder tragen. Wer nur eine Quelle hat, sieht unter Umständen nur einen Teil.
• Kein Export, kurze Retention. Ohne Export verschwinden die Ereignisse nach dem Portal-Fenster. Eine Persistenz, die Wochen vor ihrer Nutzung eingerichtet wurde, ist dann nicht mehr nachweisbar.

Fehlalarme und Tuning

• App-Onboarding und CI/CD. Das Einrichten neuer Apps und automatisierte Deployments erzeugen Consents und Credentials am laufenden Band. Die bekannten Automations- und Pipeline-Konten kommen namentlich in die Allowlist, mit ihrer App-ID.
• Secret-Rotation und Zertifikatserneuerung. Reguläre Rotation sieht wie das bösartige Hinzufügen einer Credential aus. Der Unterschied liegt im Actor, im Zeitplan und darin, ob danach etwas Ungewöhnliches passiert; die Rotation läuft über bekannte Konten im bekannten Rhythmus.
• Administrator-Changes und PIM-Aktivierung. Geplante Rollenvergaben und PIM-Aktivierungen sind legitim. PIM wird in Regel 3 ausgenommen; die dauerhafte Zuweisung bleibt scharf und wird mit dem Change-Ticket abgeglichen.
• MFA-Reset und Gerätewechsel. Self-Service-Registrierung neuer Methoden und vom Helpdesk ausgelöste Resets sind der Haupt-Fehlalarm der MFA-Regel. Sie wird nur im Kontext bewertet: ungewöhnlicher Actor, ungewöhnliche IP, zeitliche Nähe zu einer auffälligen Anmeldung.
• Conditional-Access-Rollout und Automation. Ein CA-Rollout oder Policy-as-Code erzeugt viele CA-Änderungen. Der Deployment-Dienstprincipal wird allowlistet; Änderungen außerhalb der Pipeline bleiben ein Alarm.
• Der Kontext entscheidet. Für jede Bewertung zählen Actor, Zielobjekt, App-ID, Publisher, IP, Zeitpunkt, Change-Ticket, bekannte Automation und die nachfolgenden Sign-ins. Erst deren Zusammenspiel trennt Betrieb von Angriff.

Härtung

• PIM und zeitlich begrenzte Rollen. Privilegierte Rollen nur über PIM, zeitlich begrenzt und genehmigungspflichtig, statt dauerhaft. Dann ist jede dauerhafte Zuweisung die erklärungsbedürftige Ausnahme.
• Consent einschränken. Benutzer-Consent restriktiv setzen oder abschalten und einen Admin-Consent-Workflow einrichten, damit Berechtigungsanfragen geprüft statt blind erteilt werden.
• Workload Identity Governance. Dienstprincipals und App-Registrierungen wie privilegierte Konten behandeln: regelmäßige Review, kurze Credential-Lebensdauer, Zertifikate statt langlebiger Secrets wo möglich, und keine Verzeichnisrollen ohne klaren Bedarf.
• Authentication Methods Policy. Erlaubte MFA-Methoden zentral steuern, schwache Methoden abschalten und das Registrieren neuer Methoden überwachen.
• Conditional Access schützen und überwachen. CA-Änderungen über Change Management führen, möglichst als Policy-as-Code mit Review, und jede Änderung alarmieren. Getrennte Admin-Konten für die Verwaltung.
• Break-Glass sauber überwachen. Die Notfallkonten von CA ausnehmen, aber jede ihrer Anmeldungen gesondert alarmieren, damit die Ausnahme nicht zur Hintertür wird.

Der Test

Der Test gehört ausschließlich in ein eigenes Test-Tenant, nie in die Produktion und nie mit produktiven Admin- oder Break-Glass-Konten. Er erzeugt die Audit-Events mit ungefährlichen Testobjekten und nimmt die Änderungen wieder zurück.

1. Testobjekte anlegen. Eine Test-App-Registrierung und einen Test-Dienstprincipal im Test-Tenant erstellen, ohne produktive Berechtigungen.
2. Credential hinzufügen. Der Test-App ein ungefährliches Client Secret oder Zertifikat geben. Erwartung: AuditLogs-Eintrag mit der Operation "Add service principal credentials"; Regel 1 und KQL-Abfrage 1 greifen.
3. Consent und Rollenzuweisung kontrolliert. Der Test-App einen harmlosen, delegierten Berechtigungsumfang per Consent geben und einem Testbenutzer eine unkritische Rolle dauerhaft zuweisen. Erwartung: Operationen "Consent to application" und "Add member to role"; Regel 2 und 3 greifen.
4. Auth-Methode und CA. Für einen Testbenutzer eine zusätzliche MFA-Methode registrieren und eine Test-CA-Richtlinie im Report-only-Modus anlegen und wieder deaktivieren. Erwartung: die entsprechenden Audit-Operationen; Regel 4 und 5 greifen. Dabei ablesen, welche OperationNames und Felder der eigene Export tatsächlich liefert.
5. Zurücknehmen und dokumentieren. Credential, Consent, Rolle, Methode und Richtlinie wieder entfernen, die tatsächlichen OperationNames in die Regel- und KQL-Doku übernehmen und Datum und Ergebnis in den Purple-Team-Navigator schreiben.

Analysten-Checkliste

• Wer hat die Änderung ausgelöst? InitiatedBy: ein Benutzer oder ein Dienstprincipal, und von welcher IP? Gehört der Actor zu den Konten, die so etwas dürfen?
• Was wurde geändert, und an welchem Objekt? OperationName und TargetResources: Credential, Consent, Rolle, Methode oder CA-Richtlinie, an welcher App, welchem Konto, welcher Policy.
• Welches neue Privileg oder welche Credential? Welche Graph-Berechtigungen, welche Rolle, welches Secret oder Zertifikat, welche MFA-Methode - und wie weitreichend ist das.
• War das geplant? Abgleich mit Change-Ticket, bekanntem Onboarding, Rotationsplan und bekannter Automation.
• Ist die App bekannt, und gehört der Publisher zum Unternehmen? App-ID und Herausgeber gegen das eigene Inventar und den Admin-Consent-Workflow halten.
• Gab es danach Sign-ins, von welcher IP und welchem Tenant? SigninLogs und AADServicePrincipalSignInLogs nach der Änderung: neue Dienstprincipal-Anmeldung, neues Land, Anmeldung ohne MFA.
• Wurden weitere Rollen, Consents oder Policies geändert? Häufen sich Änderungen in kurzer Zeit auf denselben Actor oder dasselbe Ziel, ist das ein starkes Signal.
• Gibt es parallele Änderungen an MFA oder Conditional Access? Eine neue MFA-Methode plus eine geschwächte CA-Richtlinie beim selben Konto ist die klassische Persistenz-Kombination.
• Reaktion. Bei bestätigter Persistenz: die neue Credential oder Methode entfernen, den Consent widerrufen, die Rolle zurücknehmen, die CA-Richtlinie wiederherstellen, alle Token der betroffenen Identität widerrufen und den auslösenden Actor als kompromittiert behandeln. Dann den Umfang über die Audit- und Sign-in-Logs rekonstruieren, wie im Pillar Cloud-Sicherheit beschrieben.

Fazit

Entra-Persistenz ist leise, weil sie aus legitimen Verwaltungsaktionen besteht: ein Consent, ein Secret, eine Rolle, eine MFA-Methode, eine Richtlinienänderung. Sichtbar wird sie nur im Entra-Audit-Log, und belastbar wird die Erkennung erst, wenn die Logs exportiert, die Operationen gegen die eigene Telemetrie kalibriert und die Konfigurationsänderung mit der nachfolgenden Anmeldung korreliert werden. Wer die fünf Mechanismen kennt, die passenden Audit-Operationen erfasst, die KQL-Abfragen auf den Sentinel-Tabellen laufen lässt und mit PIM, restriktivem Consent, kurzer Credential-Lebensdauer und überwachtem Conditional Access härtet, trennt die seltene bösartige Persistenz vom täglichen Cloud-Betrieb. Die angrenzenden Themen: der Pillar Cloud-Sicherheit für Blue Teams, die Anmelde-Anomalien bei Valid Accounts und MFA-Phishing und Token-Diebstahl, die Postfachübernahme über E-Mail-Weiterleitungsregeln und der Datenabfluss über ein fremdes Cloud-Konto. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Persistence.