• Administrative Kontrolle über den Tenant bewahren oder zurückgewinnen
• Aktiven Angreiferzugriff stoppen, ohne Beweise zu vernichten
• Logs sichern, bevor sie ablaufen oder manipuliert werden
• Persistenz in Identitäten, Anwendungen, Richtlinien und Workloads finden und entfernen
• Entscheiden, ob dem Tenant nach der Bereinigung noch zu trauen ist
• Dienste kontrolliert und in der richtigen Reihenfolge wiederherstellen

1. Administrative Kontrolle sichern oder zurückgewinnen.
2. Logs und Beweise sichern, bevor sie ablaufen oder verändert werden.
3. Aktiven Angreiferzugriff und laufenden Schaden stoppen.
4. Erstzugang, Rechte, Persistenz und betroffene Daten bestimmen.
5. Entscheiden, ob der Tenant bereinigt oder in einer sauberen Umgebung neu aufgebaut wird.
6. Dienste kontrolliert wiederherstellen und ein erneutes Eindringen früh erkennen.

• Nicht im Kontrollraum des Angreifers verhandeln. Koordination über einen Kanal, der nicht vom kompromittierten Tenant abhängt; Administration nur von sauberen Admin-Geräten.
• Logs zuerst. Viele Cloud-Logs sind ohne Export nur Tage oder wenige Wochen verfügbar. Fehlende Logs sind kein negativer Befund.
• Deaktivieren vor Löschen. Angreiferobjekte erst nach Sicherung von Konfiguration, Credentials, Berechtigungen und Audit-Spuren entfernen, außer sie richten aktiv Schaden an.
• Passwort-Reset ist keine Eindämmung. Sitzungen, Refresh Tokens, App-Secrets, Zertifikate, Schlüssel und Vertrauensstellungen müssen eigens behandelt werden.
• MFA ist kein Sauberkeitsnachweis. Gestohlene Sitzungen, OAuth-Grants und Workload-Identitäten umgehen MFA.
• Nie nur ein Recovery-Zugang. Mindestens zwei unabhängige, geprüfte Break-Glass-Zugänge sichern, bevor weitreichende Änderungen erfolgen.
• Lesend erfassen, mit Freigabe ändern. Eindämmende Änderungen erst nach Beweissicherung und dokumentierter Entscheidung, im Vier-Augen-Prinzip.
• Zeit konsistent erfassen. Timeline, Log-Exporte und Entscheidungen in UTC dokumentieren.

Ein Neuaufbau wird gestaffelt geplant: Identität, Logging, Sicherheit und Backup zuerst. Der kompromittierte Tenant bleibt für die Untersuchung erhalten, soweit möglich. Bei der Migration keine Identitäten, Berechtigungen, Apps oder Secrets ungeprüft übernehmen.

Vor dem Abschalten einen Ersatz-Anmeldeweg für Administratoren sicherstellen, etwa Cloud-only-Notfallkonten.

• Identitätskompromittierung parallel für betroffene Einzelkonten und deren Sitzungen.
• Datenpanne parallel, wenn personenbezogene, regulierte oder vertrauliche Daten abgerufen, exportiert oder offengelegt worden sein könnten.
• Ransomware-Playbook führend, wenn Daten oder Ressourcen in großem Umfang verschlüsselt oder gelöscht werden.
• Lieferkette parallel, wenn der Zugang über einen Dienstleister, eine Drittanbieter-App oder eine CI/CD-Integration erfolgte.
• Insider-Vorfall, wenn eine berechtigte Person ihre Rechte vorsätzlich missbraucht hat.

• Neue oder veränderte Admin-Konten, Rollenzuweisungen und privilegierte Gruppenmitgliedschaften
• Neue Service Principals, App-Registrierungen und Workload-Identitäten
• Zusätzliche Client-Secrets, Zertifikate, API-Keys oder Access Keys an bestehenden Identitäten
• Bösartige OAuth-Grants und Admin-Consents
• Ausnahmen in Conditional Access, deaktivierte MFA-Anforderungen, neue Authentisierungsmethoden
• Veränderte Föderationsvertrauensstellungen, SSO-Konfigurationen oder Identity-Provider-Routing
• Neue Gastkonten und externe Identitäten
• Automatisierung: Runbooks, Funktionen, geplante Jobs, CI/CD-Credentials, Hooks und Workflows
• Postfach-Weiterleitungen, Transport- und Posteingangsregeln, Delegationen
• Veränderte Logging-, Aufbewahrungs-, Backup- oder Löschschutz-Einstellungen

1. Kommunikation außerhalb des Tenants und Koordination der Reaktion
2. Vertrauenswürdiger administrativer Zugang und Break-Glass-Konten
3. Identity Provider und privilegierter Zugriff
4. Logging, Audit-Aufbewahrung und SIEM-Anbindung
5. Sicherheitskontrollen und Alarmierung
6. Backup- und Recovery-Schutz
7. Mail, Kollaboration und zentrale SaaS-Dienste
8. Geschäftskritische Anwendungen und Datenbestände
9. Cloud-Workloads und Infrastruktur
10. Drittintegrationen und Automatisierung
11. Nicht kritische Dienste

• Ersten Alarm, Entdeckungszeit und den frühesten bekannten verdächtigen Vorgang dokumentieren.
• Betroffene Tenants, Subscriptions, Accounts, Projekte, Workspaces und SaaS-Instanzen bestimmen.
• Anmeldungen privilegierter Konten prüfen: Ort, Gerät, Client, Anonymisierungsdienste, ungewöhnliche User-Agents.
• MFA-Aufforderungen, MFA-Methodenänderungen und neue Geräteregistrierungen prüfen.
• Änderungen an Conditional Access, SSO, Föderation, Rollen und Gruppen prüfen.
• Neue Apps, Service Principals, Workload-Identitäten, OAuth-Grants, Secrets, Zertifikate und Keys prüfen.
• Postfachzugriffe, Weiterleitungen, eDiscovery- und Exportaktivität prüfen.
• Speicherzugriffe, Freigabelinks, öffentliche Zugriffe und Massendownloads prüfen.
• Änderungen an Compute, Netzwerk, IAM, Logging, Aufbewahrung, Backup und Sicherheitswerkzeugen prüfen.
• Abrechnungs- und Ressourcenspitzen sowie ungewöhnliche Regionen prüfen.
• Vollständigkeit und Vertrauenswürdigkeit der Logs bewerten.

• Break-Glass-Konten prüfen, absichern und mindestens zwei unabhängige Admin-Zugänge sicherstellen.
• Sitzungen und Refresh Tokens betroffener Konten widerrufen, Konten sperren; Umfang nach Regel 4.
• Unerlaubte Rollen und Gruppenmitgliedschaften entfernen.
• Unerlaubte Konten, Gäste, Service Principals, Workload-Identitäten und Apps deaktivieren.
• Bösartige OAuth-Grants und App-Consents widerrufen.
• Offengelegte Credentials, Keys, Zertifikate und Secrets deaktivieren und anschließend kontrolliert rotieren.
• Manipulierte MFA- und Conditional-Access-Richtlinien wiederherstellen, riskante Ausnahmen entfernen.
• Öffentlichen Zugriff auf exponierte Speicher und Anwendungen sperren.
• Verdächtige Automatisierung, Skripte, Runbooks, Funktionen und Pipelines pausieren.
• Audit-Logs, Aufbewahrung, SIEM-Anbindung und Alarmierung schützen.
• Backups, Snapshots und Recovery-Vaults vor Löschung schützen.
• Bei Kontrollverlust den Cloud-Anbieter nach Regel 2 einschalten.

• Alle administrativen Aktionen im Kompromittierungszeitraum rekonstruieren.
• Erstellung und Änderung von Benutzern, Gruppen, Rollen, Richtlinien und Anwendungen prüfen.
• Management-API-Aktivität, auch von Service Principals und Workload-Identitäten, auswerten.
• Postfach-, Datei-, Speicher- und Datenbankzugriffe sowie Exporte prüfen.
• Änderungen an Netzwerk, Firewalls, DNS, Routing und Private Endpoints prüfen.
• Key Vault, KMS, Secrets Manager, Backup, Snapshots und Aufbewahrung prüfen.
• CI/CD, Automatisierungskonten, Runbooks und Serverless-Funktionen prüfen.
• Gastkonten, externe Identitäten und Föderationsvertrauensstellungen prüfen.
• Admin-Aktivität in MDM, EDR und anderen Sicherheitswerkzeugen prüfen.
• Vom Angreifer erzeugte Ressourcen und Abrechnungsanomalien identifizieren.
• Nach der Persistenzliste oben systematisch suchen.

• Unerlaubte Benutzer, Gäste, Gruppen, Rollen, Service Principals, Apps und Workload-Identitäten nach Sicherung entfernen.
• Bösartige OAuth-Grants und delegierte Berechtigungen entfernen.
• Unerlaubte Secrets, Zertifikate und Keys entfernen; alle offengelegten Credentials rotieren.
• Sitzungen, Refresh Tokens und Anwendungs-Tokens erneut widerrufen.
• Sichere MFA-, Conditional-Access-, Föderations- und SSO-Konfiguration wiederherstellen; nicht freigegebene Ausnahmen entfernen.
• Logging, Audit, Aufbewahrung, Alarmierung und SIEM-Anbindung wiederherstellen.
• Sicherheitswerkzeuge erneut aktivieren und ihre Funktion prüfen.
• Schädliche Automatisierung, Deployment-Artefakte und vom Angreifer erzeugte Ressourcen entfernen.
• Ausgenutzte Workloads patchen; für die Administration genutzte, kompromittierte Endpunkte neu aufsetzen.
• Bei Entscheidung für den Neuaufbau: gestaffelt nach der Wiederherstellungspriorität in die saubere Umgebung migrieren.

• Dienste in der Reihenfolge der Wiederherstellungspriorität freigeben.
• Bestätigen, dass administrative Kontrolle gesichert und Break-Glass-Konten überwacht sind.
• Bestätigen, dass Conditional Access, MFA, Logging, Aufbewahrung, Sicherheitswerkzeuge und Backup-Schutz aktiv sind.
• Betroffene Workloads nur aus vertrauenswürdigen Quellen wiederherstellen.
• Prüfen, ob Drittintegrationen weiterhin benötigt werden und sicher sind.
• Verstärkte Überwachung für 30 bis 90 Tage, je nach Schweregrad.

• Nachbesprechung innerhalb von zehn Geschäftstagen durchführen.
• Timeline, Erstzugang, Persistenz, betroffene Daten und getroffene Entscheidungen dokumentieren.
• Modell für Identität und privilegierten Zugriff überprüfen.
• OAuth-Consent und Application Governance überprüfen.
• Rechte von Service Principals und Workload-Identitäten überprüfen.
• Logging, Aufbewahrung und Monitoring-Abdeckung überprüfen.
• Backup- und Recovery-Resilienz überprüfen und testen.
• Zugänge von Dienstleistern und Drittanbietern überprüfen.
• Erkennungsregeln, Playbooks und Härtungsbaselines aktualisieren.

Orientierung, keine Rechtsberatung (Stand: Oktober 2026). Ob eine Pflicht greift, hängt von Land, Sektor, Größe und Rolle der Organisation ab. Fristen, Meldewege und Ansprechpartner sollten vorab festgelegt sein und im Ernstfall mit Recht und Datenschutz bestätigt werden.

Meldepflichten für Cybersicherheitsvorfälle

• Deutschland — NIS2 (§ 32 BSIG, seit 6. Dezember 2025): Besonders wichtige und wichtige Einrichtungen melden erhebliche Sicherheitsvorfälle an das BSI: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats.
• Österreich — NISG 2026 (seit 1. Oktober 2026): Wesentliche und wichtige Einrichtungen melden erhebliche Sicherheitsvorfälle an das zuständige CSIRT: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden.
• Schweiz — Informationssicherheitsgesetz (ISG, seit 1. April 2025): Betreiber kritischer Infrastrukturen melden Cyberangriffe binnen 24 Stunden an das Bundesamt für Cybersicherheit (BACS).

Datenschutz

• Deutschland und Österreich — DSGVO Art. 33/34: Verletzungen des Schutzes personenbezogener Daten binnen 72 Stunden ab Kenntnis an die Aufsichtsbehörde melden, sofern ein Risiko für die Betroffenen nicht unwahrscheinlich ist; bei hohem Risiko auch die Betroffenen benachrichtigen.
• Schweiz — DSG Art. 24: Meldung an den EDÖB so rasch als möglich, wenn die Verletzung voraussichtlich zu einem hohen Risiko für die Betroffenen führt.

Alle Fristen laufen ab Kenntnis des Vorfalls, nicht erst ab Abschluss der technischen Untersuchung. Eine unvollständige Frühwarnung innerhalb der Frist ist besser als eine vollständige Meldung danach.

Für dieses Szenario

• Die Kompromittierung eines Cloud-Tenants mit Mail, Dateien oder Kundendaten betrifft fast immer personenbezogene Daten. Die Datenschutzbewertung früh beginnen, nicht erst nach Abschluss der Analyse.
• Der Cloud-Anbieter ist in der Regel Auftragsverarbeiter (Art. 28 DSGVO). Liegt die Ursache bei ihm, muss er Sie nach Art. 33 Abs. 2 DSGVO unverzüglich informieren; die Meldepflicht gegenüber der Aufsichtsbehörde bleibt bei Ihnen.
• Ein Kontrollverlust über zentrale Identitäts- und Kollaborationsdienste ist häufig ein erheblicher Sicherheitsvorfall im Sinne von NIS2 und ISG.
• Verträge mit Kunden und Partnern sowie die Cyberversicherung enthalten oft eigene, kürzere Meldefristen.

• NIST SP 800-61 Rev. 3
• CISA: Microsoft Expanded Cloud Logs Implementation Playbook
• CISA Advisory AA21-008A: Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments
• Microsoft Entra ID: Revoke user access in an emergency
• MITRE ATT&CK: T1078.004, T1098.001, T1528, T1538, T1619, T1567.002
• CIS Critical Security Controls und CIS Benchmarks für Cloud-Anbieter
• Cloud Security Alliance: Cloud Controls Matrix

Dieses Playbook ist eine praktische Community-Ressource. Es ersetzt keine Rechtsberatung, forensische Expertise, Anforderungen der Cyberversicherung, Unterstützung durch den Cloud-Anbieter oder organisationsspezifische Incident-Response-Planung. Die Befehle in den Anhängen sind Beispiele; Syntax und Verfügbarkeit ändern sich mit den Plattformen und sind vor dem Einsatz zu prüfen.

Befehle enthalten Platzhalter. Aus einer sauberen Admin-Workstation und mit einem geprüften Response-Konto ausführen. Zeiten als UTC im Format 2026-10-01T00:00:00Z einsetzen.

• Vor Änderungen Zeitfenster, Tenant-ID, ausführendes Konto und Begründung dokumentieren.
• Sign-in-, Directory-Audit-, Unified-Audit- und Azure-Activity-Daten so früh wie möglich exportieren.
• Benutzer-, Service-Principal- und Managed-Identity-Aktivität getrennt prüfen.
• Ein Passwort-Reset ersetzt weder Session-Widerruf noch die Rotation von App-Secrets, Zertifikaten oder föderierten Vertrauensstellungen.
• Gastkonten werden in ihrem Heimat-Tenant authentisiert; revokeSignInSessions im eigenen Tenant beendet deren Sitzungen im Heimat-Tenant nicht.

Aufbewahrung ohne Export: Entra-Anmelde- und Audit-Logs 7 Tage ohne Lizenz, 30 Tage mit Entra ID P1/P2; Unified Audit Log 180 Tage mit Audit Standard; Azure Activity Log 90 Tage. Der Abruf von Anmeldelogs über Microsoft Graph setzt Entra ID P1/P2 voraus, sonst Export im Portal. Fehlende Daten sind kein negativer Befund.

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All","Policy.Read.All","Application.Read.All","RoleManagement.Read.Directory"
Get-MgContext
Get-MgOrganization | Select-Object Id,DisplayName,VerifiedDomains

$Start = [datetime]"<START_UTC>"
$End   = [datetime]"<END_UTC>"
$User  = "user@example.com"

$From = $Start.ToString('yyyy-MM-ddTHH:mm:ssZ')
$To   = $End.ToString('yyyy-MM-ddTHH:mm:ssZ')

Get-MgAuditLogSignIn -All -Filter "createdDateTime ge $From and createdDateTime le $To" |
  ConvertTo-Json -Depth 20 |
  Set-Content -Encoding utf8 "entra-signins.json"

Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge $From and activityDateTime le $To" |
  ConvertTo-Json -Depth 20 |
  Set-Content -Encoding utf8 "entra-directory-audit.json"

Microsoft Graph paginiert große Ergebnisse. -All bewusst verwenden und den Export auf Vollständigkeit, Fehler und Dateigröße prüfen.

Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty principal,roleDefinition |
  Select-Object Id,PrincipalId,RoleDefinitionId,DirectoryScopeId |
  Export-Csv -NoTypeInformation "entra-role-assignments.csv"

Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,CreatedDateTime,AccountEnabled,ServicePrincipalType,KeyCredentials,PasswordCredentials |
  ConvertTo-Json -Depth 20 |
  Set-Content -Encoding utf8 "entra-service-principals.json"

Get-MgApplication -All -Property Id,AppId,DisplayName,CreatedDateTime,KeyCredentials,PasswordCredentials,RequiredResourceAccess |
  ConvertTo-Json -Depth 20 |
  Set-Content -Encoding utf8 "entra-applications.json"

Get-MgOauth2PermissionGrant -All |
  Export-Csv -NoTypeInformation "entra-oauth2-permission-grants.csv"

Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId "<SERVICE_PRINCIPAL_OBJECT_ID>" -All |
  Export-Csv -NoTypeInformation "entra-app-role-assignments.csv"

Besonders prüfen: kürzlich erstellte Apps, neue Credentials, tenantweiter Admin-Consent, ungewöhnliche Redirect-URIs, nicht verifizierte Herausgeber und Rechte wie Mail.Read, Files.Read.All, Directory.ReadWrite.All oder RoleManagement.ReadWrite.Directory.

Get-MgIdentityConditionalAccessPolicy -All |
  ConvertTo-Json -Depth 30 |
  Set-Content -Encoding utf8 "entra-conditional-access.json"

Get-MgDomainFederationConfiguration -DomainId "example.com" |
  ConvertTo-Json -Depth 20 |
  Set-Content -Encoding utf8 "entra-federation-example.com.json"

Zusätzlich Authentication Methods Policy, Named Locations, Cross-Tenant Access, PIM-Konfiguration, Break-Glass-Konten und Verzeichnissynchronisierung dokumentieren.

Connect-ExchangeOnline

$Session = "IR-$(Get-Date -Format yyyyMMddHHmmss)"
Search-UnifiedAuditLog -StartDate $Start -EndDate $End `
  -SessionId $Session -SessionCommand ReturnLargeSet -ResultSize 5000 |
  Export-Csv -NoTypeInformation "m365-unified-audit-part-01.csv"

Search-UnifiedAuditLog -StartDate $Start -EndDate $End `
  -UserIds $User -SessionId "$Session-user" -SessionCommand ReturnLargeSet -ResultSize 5000 |
  Export-Csv -NoTypeInformation "m365-unified-audit-user.csv"

ReturnLargeSet liefert unsortiert und ist pro Session begrenzt. In Zeitfenster aufteilen, wiederholt abrufen und Anzahl sowie Duplikate kontrollieren. Für große Untersuchungen die Audit-Suche in Purview verwenden.

Get-InboxRule -Mailbox $User -IncludeHidden |
  Format-List * | Out-File "exchange-inbox-rules.txt"

Get-Mailbox -Identity $User |
  Select-Object DisplayName,PrimarySmtpAddress,ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward |
  Export-Csv -NoTypeInformation "exchange-forwarding.csv"

Get-MailboxPermission -Identity $User |
  Export-Csv -NoTypeInformation "exchange-mailbox-permissions.csv"

Get-RecipientPermission -Identity $User |
  Export-Csv -NoTypeInformation "exchange-recipient-permissions.csv"

Get-MessageTraceV2 -SenderAddress $User -StartDate $Start -EndDate $End |
  Export-Csv -NoTypeInformation "exchange-message-trace.csv"

Auch Transportregeln, Connectoren, Remote Domains, Journaling, Delegationen, eDiscovery-Exporte und neue Postfächer prüfen.

az account tenant list --output json > azure-tenants.json
az account list --all --output json > azure-subscriptions.json

az monitor activity-log list \
  --subscription "<SUBSCRIPTION_ID>" \
  --start-time "<START_UTC>" \
  --end-time "<END_UTC>" \
  --output json > azure-activity-log.json

az role assignment list --all --include-inherited \
  --subscription "<SUBSCRIPTION_ID>" \
  --output json > azure-role-assignments.json

az resource list --subscription "<SUBSCRIPTION_ID>" \
  --output json > azure-resources.json

Resource Logs liegen je nach Diagnostic Setting in Log Analytics, Storage oder Event Hub. Für Key Vault, Storage und Datenbanken prüfen, ob Data-Plane-Logging im relevanten Zeitraum überhaupt aktiv war.

Sitzungen eines Benutzers widerrufen

Revoke-MgUserSignInSession -UserId $User

Die Wirkung kann verzögert eintreten. Danach das Konto sperren, Authentisierungsmethoden prüfen und je nach Befund Passwort und registrierte Methoden kontrolliert zurücksetzen.

Konto vorübergehend sperren

Update-MgUser -UserId $User -AccountEnabled:$false

Verdächtigen Service Principal deaktivieren

Update-MgServicePrincipal -ServicePrincipalId "<OBJECT_ID>" -AccountEnabled:$false

Nicht löschen, bevor Konfiguration, Credentials, Besitzer, Grants, App-Role-Zuweisungen und Audit-Spuren gesichert sind.

• Rollenaktivierung und dauerhafte Rollenzuweisungen
• Änderung oder Ausnahmen von Conditional-Access-Richtlinien
• Neue oder geänderte Authentisierungsmethoden
• Domain-Föderation, Cross-Tenant Access und Verzeichnissynchronisierung
• App-Registrierungen, Service Principals, Consent und neue Credentials
• Postfachregeln, Weiterleitungen, Delegationen und eDiscovery-Exporte
• Änderungen an Audit, Aufbewahrung, Defender, Sentinel und Diagnostic Settings
• Key-Vault-Zugriffe, Secret-Abrufe, Storage-Downloads und SAS-Erstellung
• Deployments, VM Extensions, Automation Accounts und Runbooks

• Microsoft Graph: Entra Audit Logs
• Microsoft Graph: Anmeldesitzungen widerrufen
• Entra-Aktivitätslogs mit Microsoft Graph analysieren
• Search-UnifiedAuditLog
• Azure Activity Log
• Microsoft Incident Response Playbooks

AWS-Abfragen sind meist Account- und Region-spezifisch. Globale Dienste schreiben ihre Ereignisse dennoch in bestimmte Regionen. Alle relevanten Accounts und aktivierten Regionen prüfen. Zeiten als UTC im Format 2026-10-01T00:00:00Z einsetzen.

• Die Reaktion bevorzugt aus einem dedizierten Security- oder Log-Archive-Account durchführen.
• Management Account, delegierte Administratoren und Mitgliedskonten getrennt betrachten.
• CloudTrail-Konfiguration und zentrale Logkopien schützen, bevor verdächtige Principals verändert werden.
• Bei temporären Credentials (ASIA…) den ausstellenden STS-Vorgang und den sessionIssuer ermitteln; nur nach dem sichtbaren Access Key zu suchen reicht nicht.
• Access Keys zunächst deaktivieren und erst nach der Beweissicherung löschen. Rollen-Sitzungen erfordern andere Maßnahmen als langlebige Keys von IAM-Benutzern.

aws sts get-caller-identity > aws-caller-identity.json
aws organizations describe-organization > aws-organization.json
aws organizations list-accounts --output json > aws-accounts.json
aws organizations list-delegated-administrators --output json > aws-delegated-admins.json
aws organizations list-policies --filter SERVICE_CONTROL_POLICY --output json > aws-scps.json

Für jeden Account dokumentieren: ID, Name, OU, Status, verantwortliche Person, Break-Glass-Weg, zentrale Logziele und aktivierte Regionen.

aws cloudtrail describe-trails --include-shadow-trails --region <REGION> > cloudtrail-trails-<REGION>.json
aws cloudtrail get-trail-status --name <TRAIL_ARN_OR_NAME> --region <REGION> > cloudtrail-status.json
aws cloudtrail get-event-selectors --trail-name <TRAIL_ARN_OR_NAME> --region <REGION> > cloudtrail-event-selectors.json
aws cloudtrail list-event-data-stores --region <REGION> > cloudtrail-lake-stores.json

Prüfen: Multi-Region, Organization Trail, Log File Validation, KMS, Ziel-Bucket, Object Lock, Lifecycle, Data-Event-Selektoren sowie Änderungen an Trail oder Bucket Policy.

aws cloudtrail lookup-events \
  --start-time "<START_UTC>" --end-time "<END_UTC>" \
  --region <REGION> \
  --output json > cloudtrail-events-<ACCOUNT>-<REGION>.json

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<ACCESS_KEY_ID> \
  --start-time "<START_UTC>" --end-time "<END_UTC>" \
  --region <REGION> \
  --output json > cloudtrail-access-key.json

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<IAM_USER_OR_SESSION_NAME> \
  --start-time "<START_UTC>" --end-time "<END_UTC>" \
  --region <REGION> \
  --output json > cloudtrail-principal.json

Die CLI paginiert automatisch, solange --no-paginate nicht gesetzt ist. Dateigröße, Zeitraum und Fehler trotzdem prüfen.

QUERY_ID=$(aws cloudtrail start-query \
  --query-statement "SELECT eventTime,eventSource,eventName,awsRegion,sourceIPAddress,userAgent,userIdentity FROM <EVENT_DATA_STORE_ID> WHERE eventTime >= '<START>' AND eventTime <= '<END>'" \
  --region <REGION> \
  --query 'QueryId' --output text)

aws cloudtrail get-query-results --query-id "$QUERY_ID" --region <REGION> > cloudtrail-lake-results.json

Zeiten hier im Format 2026-10-01 00:00:00. Syntax, verfügbare Felder und Kosten vor breiten Abfragen prüfen. Ergebnisse paginieren und Original-Logs unverändert aufbewahren.

aws iam get-account-summary > iam-account-summary.json
aws iam get-account-authorization-details > iam-authorization-details.json
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > iam-credential-report.csv
aws iam list-saml-providers > iam-saml-providers.json
aws iam list-open-id-connect-providers > iam-oidc-providers.json

Der Credential Report enthält keine service-spezifischen Credentials. Für jeden verdächtigen Benutzer zusätzlich:

aws iam list-access-keys --user-name <USER> > iam-user-access-keys.json
aws iam list-service-specific-credentials --user-name <USER> > iam-service-credentials.json
aws iam list-mfa-devices --user-name <USER> > iam-user-mfa.json
aws iam list-signing-certificates --user-name <USER> > iam-user-signing-certificates.json

aws iam list-roles --output json > iam-roles.json
aws iam get-role --role-name <ROLE_NAME> > iam-role-<ROLE_NAME>.json
aws iam list-attached-role-policies --role-name <ROLE_NAME> > iam-role-attached-policies.json
aws iam list-role-policies --role-name <ROLE_NAME> > iam-role-inline-policies.json

Besonders prüfen: neue Trust Principals, fremde Account-IDs, fehlende ExternalId, Wildcards, Web-Identity- und OIDC-Provider (etwa GitHub), Session Tags und ungewöhnlich lange Session-Dauer.

aws guardduty list-detectors --region <REGION> > guardduty-detectors.json
aws guardduty list-findings --detector-id <DETECTOR_ID> --region <REGION> > guardduty-finding-ids.json
aws guardduty get-findings --detector-id <DETECTOR_ID> --finding-ids <ID1> <ID2> --region <REGION> > guardduty-findings.json

aws configservice describe-configuration-recorder-status --region <REGION> > config-recorder-status.json
aws resourcegroupstaggingapi get-resources --region <REGION> > tagged-resources.json

Ergänzend EC2, Lambda, KMS, Secrets Manager, SSM, ECR, ECS/EKS, S3, CloudFormation und Billing auf neu erstellte oder geänderte Ressourcen prüfen.

• ConsoleLogin, CreateAccessKey, UpdateAccessKey, DeleteAccessKey
• CreateUser, CreateRole, UpdateAssumeRolePolicy
• Attach*Policy, Put*Policy, CreatePolicyVersion, SetDefaultPolicyVersion
• AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, AssumeRoot
• DeactivateMFADevice, DeleteVirtualMFADevice und jede Root-Aktivität
• StopLogging, DeleteTrail, UpdateTrail, Änderungen an Event Selectors
• PutBucketPolicy, PutBucketAcl, PutBucketLogging, PutBucketVersioning
• DisableKey, ScheduleKeyDeletion, Änderungen an Key Policies und Grants
• GetSecretValue, GetParameter, SendCommand, StartSession
• CreateFunction, UpdateFunctionCode, RunInstances, CreateStack, ExecuteChangeSet
• Änderungen an Organizations, SCPs und delegierten Administratoren

Access Key eines IAM-Benutzers deaktivieren

aws iam update-access-key \
  --user-name <USER> \
  --access-key-id <ACCESS_KEY_ID> \
  --status Inactive

Explizites Deny als kurzfristige Quarantäne

Eine Quarantäne-Policy stoppt einen Principal schneller als das unkoordinierte Entfernen vieler Berechtigungen. Policy vorab testen, Break-Glass ausschließen und den Rückweg dokumentieren.

aws iam put-user-policy \
  --user-name <USER> \
  --policy-name IR-Quarantine-DenyAll \
  --policy-document file://deny-all.json

deny-all.json:

{
  "Version": "2012-10-17",
  "Statement": [{"Effect": "Deny", "Action": "*", "Resource": "*"}]
}

Aktive Sitzungen einer Rolle widerrufen

Bereits ausgestellte STS-Credentials bleiben bis zu ihrem Ablauf gültig. Die Konsole bietet dafür „Revoke active sessions“ (fügt die Policy AWSRevokeOlderSessions an); per CLI dieselbe Wirkung mit einem Deny für alle vor dem Zeitpunkt ausgestellten Tokens:

aws iam put-role-policy \
  --role-name <ROLE_NAME> \
  --policy-name AWSRevokeOlderSessions \
  --policy-document file://revoke-older-sessions.json

revoke-older-sessions.json (Zeitpunkt = jetzt, UTC):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {"DateLessThan": {"aws:TokenIssueTime": "<NOW_UTC>"}}
  }]
}

Danach die Ursache behandeln: Trust Policy, Permission Policies, Session Policies, SCPs und Resource Policies gemeinsam bewerten, sonst holt sich der Angreifer neue Sitzungen.

• Root-E-Mail, MFA, Telefonnummer und alternative Kontakte prüfen.
• Unerwartete Root-Aktivität über CloudTrail und GuardDuty untersuchen.
• AWS Support über den vereinbarten Notfall- bzw. Enterprise-Support-Weg einschalten.
• In AWS Organizations prüfen, ob Root-Credentials zentral verwaltet werden oder kurzlebiger Root-Zugriff genutzt wurde; AssumeRoot und die Folgeaktivität korrelieren.

• CloudTrail Event History und Einschränkungen
• IAM Credential Report
• Temporäre Credentials einer Rolle widerrufen
• Kompromittierte AWS-Credentials behandeln
• Privilegierte Root-Sitzungen in CloudTrail verfolgen
• AWS Security Incident Response Guide

Google Workspace und Google Cloud teilen Identitäten, haben aber unterschiedliche Audit- und Administrationsflächen. Beide Seiten untersuchen. Zeiten als UTC im Format 2026-10-01T00:00:00Z einsetzen.

• Super-Admin-Konten, privilegierte Gruppen, delegierte Admin-Rollen und Break-Glass-Konten zuerst sichern.
• Passwortwechsel und das Zurücksetzen der Sign-in-Cookies immer gemeinsam durchführen.
• Workspace-Logs über „Audit and investigation“ bzw. das Security Investigation Tool exportieren; API-Verfügbarkeit und Aufbewahrung hängen von Edition und Datenquelle ab.
• In Google Cloud werden Admin-Activity- und System-Event-Logs immer geschrieben; Data-Access-Logs meist nur, wenn sie vorher aktiviert wurden (Ausnahme unter anderem BigQuery).
• Service-Account-Keys, Workload Identity Federation und domainweite Delegation getrennt von Benutzerkonten untersuchen.

• Admin- und Benutzer-Log-Events, einschließlich Anmeldung und Kontoaktivität
• OAuth- und Token-Log-Events
• Drive-Log-Events und externe Freigaben
• Gmail-Log-Events und Email Log Search
• SAML, Context-Aware Access und Access Evaluation
• Groups, Geräte, Chrome und Endpunktaktivität
• Regeln, DLP, Vault, Takeout und Datenmigration
• Alert Center und Security Investigation Tool

Verfügbare Datenquellen und Reaktionsmöglichkeiten unterscheiden sich nach Workspace-Edition und Admin-Rechten.

Die Reports API liefert Aktivitäten je Anwendung. Das Token wird ohne Echo eingelesen, damit es nicht in der Shell-History landet:

read -rs GOOGLE_IR_TOKEN && export GOOGLE_IR_TOKEN
START_TIME='<START_UTC>'
END_TIME='<END_UTC>'

for APP in admin login token drive; do
  curl -sS \
    -H "Authorization: Bearer ${GOOGLE_IR_TOKEN}" \
    "https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/${APP}?startTime=${START_TIME}&endTime=${END_TIME}&maxResults=1000" \
    > "workspace-${APP}-activity-page-001.json"
done

Antworten mit nextPageToken vollständig paginieren. Tokens nicht in Tickets oder Artefaktdateien speichern. Für wiederholte Abrufe einen kontrollierten OAuth-Client mit möglichst wenigen Scopes verwenden.

Pfad: Reporting → Audit and investigation bzw. Security → Security center → Investigation tool.

• Neue Super Admins und delegierte Admin-Rollen
• Änderungen an Passwort, Wiederherstellungsdaten, 2-Step Verification und Passkeys
• Verdächtige Session Cookies und ungewöhnliche Anmeldungen
• Neue OAuth-Clients, Grants und hochprivilegierte Scopes
• Domainweite Delegation und Marketplace-Anwendungen
• Änderungen an SAML/SSO und Context-Aware Access
• Gmail-Weiterleitungen, Delegationen, Routing und Compliance-Regeln
• Drive-Massendownloads, externe Freigaben, Eigentumsübertragungen und Löschungen
• Google Takeout, Vault-Exporte und Datenmigrationen
• Mitgliedschaften in privilegierten oder vertraulichen Gruppen

1. Konto gegebenenfalls sperren.
2. Passwort zurücksetzen.
3. Sign-in-Cookies separat zurücksetzen.
4. 2-Step-Verification- und Passkey-Registrierungen prüfen, unbekannte Methoden entfernen.
5. App-Passwörter und OAuth-Tokens widerrufen.
6. Weiterleitungen, Delegationen, Filter, Gruppen und Drive-Freigaben prüfen.
7. Bei SSO auch die Sitzung beim Identity Provider und das Quellkonto behandeln.

Ein Passwort-Reset allein beendet nicht zuverlässig jeden bestehenden Zugriff.

gcloud auth list --format=json > gcp-auth-context.json
gcloud organizations list --format=json > gcp-organizations.json
gcloud projects list --format=json > gcp-projects.json

gcloud organizations get-iam-policy <ORG_ID> --format=json > gcp-org-iam-policy.json
gcloud resource-manager folders get-iam-policy <FOLDER_ID> --format=json > gcp-folder-iam-policy.json
gcloud projects get-iam-policy <PROJECT_ID> --format=json > gcp-project-iam-policy.json

gcloud iam service-accounts list --project <PROJECT_ID> --format=json > gcp-service-accounts.json
gcloud iam service-accounts keys list --iam-account <SERVICE_ACCOUNT_EMAIL> --managed-by=user --format=json > gcp-user-managed-sa-keys.json

Die Projekt-IAM-Policy zeigt keine geerbten Bindings. Organisation, Ordner, Projekte und relevante Ressourcen gemeinsam erfassen; IAM Deny, Principal Access Boundaries und Organization Policies zusätzlich prüfen.

gcloud logging read '
timestamp>="<START_UTC>" AND timestamp<="<END_UTC>" AND
protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
' --project <PROJECT_ID> --order=asc --format=json > gcp-audit-all.json

gcloud logging read '
logName:"cloudaudit.googleapis.com%2Factivity" AND
timestamp>="<START_UTC>" AND timestamp<="<END_UTC>"
' --organization <ORG_ID> --order=asc --format=json > gcp-admin-activity-org.json

gcloud logging read '
protoPayload.authenticationInfo.principalEmail="user@example.com" AND
timestamp>="<START_UTC>" AND timestamp<="<END_UTC>"
' --project <PROJECT_ID> --order=asc --format=json > gcp-principal-activity.json

Für Data-Access-Logs ist roles/logging.privateLogViewer oder ein gleichwertiges Recht nötig. Prüfen, ob Logs in andere Buckets, Projekte, BigQuery oder ein SIEM geleitet werden.

gcloud logging sinks list --organization <ORG_ID> --format=json > gcp-org-log-sinks.json
gcloud logging sinks list --project <PROJECT_ID> --format=json > gcp-project-log-sinks.json
gcloud logging buckets list --location=global --project <PROJECT_ID> --format=json > gcp-log-buckets.json
gcloud logging exclusions list --project <PROJECT_ID> --format=json > gcp-log-exclusions.json

Änderungen an Sinks, Exclusions, Aufbewahrung, CMEK und Writer Identities sind besonders relevant.

• Neu erstellte Service Accounts und vom Benutzer verwaltete Keys
• roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser und Key-Admin-Rechte
• Workload Identity Pools, Provider, Attribute Mappings und Vertrauen zu OIDC oder AWS
• Domainweite Delegation für Service Accounts
• Cloud Functions, Cloud Run, GKE und Build-Pipelines mit privilegierten Service Accounts
• Zugriffe auf Secret Manager, KMS, Storage, BigQuery und Logging
• Organization Policies, VPC Service Controls und Access Context Manager

Service-Account-Key deaktivieren

gcloud iam service-accounts keys disable <KEY_ID> \
  --iam-account <SERVICE_ACCOUNT_EMAIL> \
  --project <PROJECT_ID>

Erst deaktivieren, Abhängigkeiten beobachten, Ersatz bereitstellen und danach kontrolliert löschen. Bei Workload Identity oder kurzlebigen Tokens die ausstellende Vertrauensbeziehung behandeln.

IAM-Bindings ändern

Vor jeder Änderung die aktuelle Policy mit ETag sichern. Breite set-iam-policy-Operationen können parallele Änderungen überschreiben oder den eigenen Recovery-Zugang entfernen. Änderungen im Vier-Augen-Prinzip durchführen.

• Google Workspace Investigation Tool: Datenquellen
• Admin SDK Reports API: activities.list
• Verdächtige Session Cookies untersuchen
• Passwort und Sign-in-Cookies zurücksetzen
• Google Cloud Audit Logs
• Data-Access-Audit-Logs konfigurieren

Okta Classic Engine und Identity Engine unterscheiden sich in einzelnen Abläufen. API-Aufrufe gegen die eigene Engine und die aktuelle Okta-Dokumentation prüfen. Zeiten als UTC im Format 2026-10-01T00:00:00Z einsetzen.

• Wenn Okta der zentrale Identity Provider ist, Reaktionskanal und Admin-Anmeldung nicht allein von der möglicherweise kompromittierten Okta-Organisation abhängig machen.
• System Log sowie Admin-, App- und Richtlinienkonfiguration vor Änderungen lesend exportieren.
• Eingeschränkte OAuth-2.0-Management-Tokens langlebigen SSWS-Tokens vorziehen.
• Benutzersitzungen, OAuth-Tokens, gemerkte Geräte und Sitzungen in Zielanwendungen sind getrennte Ebenen.
• Das Sperren eines Okta-Benutzers beendet Okta-Sitzungen, aber nicht zwingend Sitzungen, die eine Zielanwendung selbst verwaltet.

• System Log und System Log API
• Admin-Rollen und Rollenzuweisungen
• Änderungen an Benutzern, Gruppen und Gruppenregeln
• Applications, App-Zuweisungen und Sign-on Policies
• Authorization Servers, OAuth-Clients, Grants und Scopes
• Identity Providers, Routing Rules und Föderation
• Authenticators, Enrollment und Faktor-Resets
• Network Zones, Behavior Detection und Global Session Policy
• API-Tokens, OAuth-Service-Apps und Device Assurance
• Event Hooks, Inline Hooks und Workflows

OKTA_DOMAIN='example.okta.com'
read -rs OKTA_IR_TOKEN && export OKTA_IR_TOKEN
SINCE='<START_UTC>'
UNTIL='<END_UTC>'

read -rs liest das Token ohne Echo und ohne Eintrag in der Shell-History. Header für SSWS-Tokens: Authorization: SSWS <token>; für OAuth: Authorization: Bearer <token>.

curl -sS --get \
  -H "Authorization: Bearer ${OKTA_IR_TOKEN}" \
  -H 'Accept: application/json' \
  --data-urlencode "since=${SINCE}" \
  --data-urlencode "until=${UNTIL}" \
  --data-urlencode 'limit=1000' \
  "https://${OKTA_DOMAIN}/api/v1/logs" \
  -D okta-system-log-headers.txt \
  -o okta-system-log-page-001.json

Weitere Seiten über den Link-Header mit rel="next" abrufen. published, uuid, eventType, Actor, Client, Target, Outcome, Debug Context und Transaction korrelieren.

# Ereignisse eines Benutzers
curl -sS --get -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  --data-urlencode "since=${SINCE}" --data-urlencode "until=${UNTIL}" \
  --data-urlencode 'filter=actor.alternateId eq "user@example.com"' \
  "https://${OKTA_DOMAIN}/api/v1/logs" > okta-user-events.json

# Zugriffe auf die Admin-Konsole
curl -sS --get -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  --data-urlencode "since=${SINCE}" --data-urlencode "until=${UNTIL}" \
  --data-urlencode 'filter=eventType eq "user.session.access_admin_app"' \
  "https://${OKTA_DOMAIN}/api/v1/logs" > okta-admin-console-access.json

# Freitextsuche nach IP, Domain oder Objekt-ID
curl -sS --get -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  --data-urlencode "since=${SINCE}" --data-urlencode "until=${UNTIL}" \
  --data-urlencode 'q=<IP_OR_DOMAIN_OR_OBJECT_ID>' \
  "https://${OKTA_DOMAIN}/api/v1/logs" > okta-search.json

for EP in users groups apps idps; do
  curl -sS -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
    "https://${OKTA_DOMAIN}/api/v1/${EP}?limit=200" > "okta-${EP}-page-001.json"
done

curl -sS -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  "https://${OKTA_DOMAIN}/api/v1/users/<USER_ID>/grants" > okta-user-grants.json

Alle Endpunkte vollständig paginieren. Client-Secrets werden nicht zwingend im Klartext zurückgegeben; Metadaten und letzte Änderungen trotzdem sichern.

• Admin-Anmeldungen, neue Admin-Rollen und Rechteausweitung
• Aktivierung, Sperrung, Passwort- und Faktor-Resets von Benutzern
• Neue oder geänderte Authenticators und Enrollment Policies
• Neue Anwendungen, geänderte App-Credentials und App-Zuweisungen
• Änderungen an Identity Providers, Routing Rules, SAML und OIDC
• Neue API-Tokens, OAuth-Service-Apps und ungewöhnliche Nutzung der Management-API
• Network Zones, Trusted Origins, Global Session Policy und MFA-Umgehung
• Gruppenregeln und -mitgliedschaften mit nachgelagerten Rechten
• System-Log-Streaming, Event Hooks, Inline Hooks und Workflows

Alle Okta-Sitzungen und OAuth-Tokens eines Benutzers widerrufen

curl -sS -X DELETE -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  "https://${OKTA_DOMAIN}/api/v1/users/<USER_ID>/sessions?oauthTokens=true&forgetDevices=true"

Sitzungen, die Web- oder Native-Apps selbst verwalten, bleiben davon unberührt. Zielanwendungen separat behandeln.

Alle Grants eines Benutzers widerrufen

curl -sS -X DELETE -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  "https://${OKTA_DOMAIN}/api/v1/users/<USER_ID>/grants"

Benutzer sperren

curl -sS -X POST -H "Authorization: Bearer ${OKTA_IR_TOKEN}" -H 'Accept: application/json' \
  "https://${OKTA_DOMAIN}/api/v1/users/<USER_ID>/lifecycle/suspend"

Vorher Profil, Gruppen, Rollen, Faktoren, Sitzungen, Grants und relevante System-Log-Ereignisse sichern. Break-Glass- und Dienstkonten nicht ohne geprüften Recovery-Weg sperren.

• Mindestens zwei unabhängige Super-Admin-Zugänge mit phishing-resistenter MFA
• Admin-Zugriff nur aus kontrollierten Netzwerkzonen und Geräten
• Keine unbekannten Identity Providers, Routing Rules, Trusted Origins oder Hooks
• Admin-Rollen und privilegierte Gruppen nur mit erwarteten Mitgliedern
• API-Tokens und OAuth-Service-Apps inventarisiert und rotiert
• Sign-on Policies, Global Session Policy und Authenticators geprüft
• Sitzungen in nachgelagerten SaaS-Anwendungen und Provisioning-Connectoren separat geprüft
• System Log vollständig in ein externes SIEM oder unveränderliches Archiv exportiert

• Okta System Log Query
• Okta Core API
• OAuth-Tokens widerrufen
• Okta Management API: Berechtigungen