In modernen Cloud-Angriffsszenarien weicht plumpe Datenexfiltration zunehmend lautloser Persistenz. Sobald ein Angreifer ein administratives Konto für das Anwendungsmanagement in Microsoft Entra ID kompromittiert (z. B. Application Administrator oder Cloud Application Administrator), wird sofort ein dauerhafter Zugang verankert. Die MITRE ATT&CK-Technik T1098.003 (Add OAuth App Credentials) ist hierbei das bevorzugte Mittel: das Einschleusen eines neuen Client-Secrets oder x509-Zertifikats in bestehende, vertrauenswürdige Unternehmensanwendungen oder Service Principals.
Anatomie des Angriffs: Die unsichtbare Hintertür
Im Gegensatz zum Anlegen eines neuen Administrators, was in Zugriffsüberprüfungen rasch auffällt, erbt die manipulierte Anwendung alle bereits genehmigten Microsoft Graph-Berechtigungen (wie Mail.ReadWrite, Directory.ReadWrite.All oder Files.ReadWrite.All). Der Angreifer benötigt keine interaktive Entra ID-Anmeldung mehr: Über den OAuth 2.0 Client Credentials Grant greift er direkt von seinen C2-Servern auf die Cloud-Umgebung zu – unter vollständiger Umgehung von MFA und Conditional Access-Richtlinien.
Der native Blindspot in Entra ID
Microsoft 365 protokolliert diese Vorgänge in den Überwachungsprotokollen als Add service principal credentials oder Update application – Certificates and secrets management. Im alltäglichen Betriebsrauschen aus CI/CD-Pipelines und routinemäßigen Zertifikatswechseln gehen diese Meldungen jedoch unter. Ohne gezielte Korrelation von Quell-IP, Identitätstyp (menschlicher Benutzer vs. Workload Identity) und auffälligen Gültigkeitszeiträumen (z. B. Ablaufdaten in 99 Jahren) bleibt die Hintertür monatelang unentdeckt.
Erkennung via Advanced Hunting (KQL)
Mit der folgenden KQL-Abfrage isolieren Sie verdächtige Secret-Zuweisungen und schließen autorisierte DevOps-Prozesse präzise aus:
CloudAppEvents
| where ActionType in~ (
"Add service principal credentials.",
"Update application – Certificates and secrets management ")
| extend ActorUPN = tostring(RawEventData.InitiatedBy.user.userPrincipalName),
ActorIP = coalesce(IPAddress, tostring(RawEventData.InitiatedBy.user.ipAddress)),
AppId = tostring(RawEventData.TargetResources[0].id),
AppName = tostring(RawEventData.TargetResources[0].displayName)
| mv-expand Property = RawEventData.TargetResources[0].modifiedProperties
| where Property.displayName =~ "KeyDescription"
| extend KeyData = parse_json(tostring(Property.newValue))
| extend KeyType = tostring(KeyData[0].KeyType), EndUtc = todatetime(KeyData[0].EndDateTime)
| where not(ActorUPN endswith "svc-devops@akuity.eu" and ActorIP in ("51.144.0.0/14"))
| project Timestamp, ActorUPN, ActorIP, AppName, AppId, KeyType, EndUtc, ReportIdAutomatisierte Behebung mit Akuity SOC
Bei einem Treffer ist unmittelbare Reaktion gefragt. Die agentenlose SOAR-Plattform von Akuity SOC schließt die Persistenz in Sekundenschnelle:
- Fokus ohne Reibung: Der In-App-KI-Assistent von Akuity SOC dekodiert Graph-API-Ereignisse in unter 2 Sekunden im zentralen Ticket Panel – ohne Risiko von Datenabflüssen an ungesicherte externe Online-Parser.
- Präzise SOAR-Intervention: 1-Klick-Ausführung der Aktion
revokeOAuthApp()direkt aus dem Evidenzinventar, um das injizierte Secret sofort zu löschen und Service-Principal-Rechte zu entziehen. - Governance & Compliance: Pflichtmäßige Freigabe unter MFA-AAL2-Authentifizierung und lückenlose, unveränderbare Audit-Protokollierung gemäß NIS 2 und SOC 2 Type II.
Überwachen Sie Service-Principal-Secrets lückenlos und widerrufen Sie schädliche API-Zugriffe mit einem Klick über unsere Cloud-SOAR.
Starten Sie Ihre 14-tägige Testphase (ohne Kreditkarte) →Technische Mini-FAQ
Warum greift Conditional Access bei diesem Angriff nicht?
Der durch App-Secrets genutzte OAuth 2.0 Client Credentials-Ablauf agiert rein anwendungsbezogen ohne Benutzerkontext. Standardmäßige Conditional Access-Regeln greifen nur bei Benutzeranmeldungen, es sei denn, es werden separate Entra Workload Identities-Richtlinien erzwungen.
Wie unterscheidet man bösartige Injektionen von legitimen Terraform-Runs?
Die Differenzierung erfolgt über die initiierende Identität (interaktives Administratorkonto vs. definierter CI/CD-Service-Principal), Quell-IP-Adressen und das Fehlen verknüpfter Bereitstellungstickets im SOAR-Workflow.