Cloud Detection Engineering: Angriffserkennung in AWS, Azure und GCP

Cloud-Infrastrukturen unterscheiden sich fundamental von On-Premises-Umgebungen: Keine Perimeter, Identitäten als primäre Zugriffskontrolle, Tausende von API-Aufrufen pro Sekunde, und eine Angriffsfläche die sich täglich verändert. Klassische Detection-Regeln für Netzwerk-IDS oder Windows-Event-Logs greifen in der Cloud kaum. Cloud Detection Engineering ist die Disziplin die diese Lücke schließt.

Cloud-Telemetrie: Die Datengrundlage

AWS-Datenquellen:

CloudTrail: alle API-Calls (Management Events = wer hat was gemacht)
CloudTrail S3-Events: Data Events auf S3-Lesezugriffe (extra Kosten, aber wichtig)
VPC Flow Logs: Netzwerk-Traffic zwischen Services (Source/Dest IP + Port)
GuardDuty Findings: AWS-nativ, ML-basierte Anomalie-Erkennung
Config: Konfigurationsänderungen an AWS-Ressourcen
Security Hub: Aggregator für alle AWS-Sicherheitsbefunde
Route53 Resolver Logs: DNS-Queries innerhalb der VPC

Kritische CloudTrail-Events: ConsoleLogin (wer hat sich wann eingeloggt), AssumeRole (Rollenübernahme - Lateral Movement!), CreateUser/AttachUserPolicy (neue User + Rechte - Persistence!), PutBucketAcl/PutObjectAcl (S3 auf public gesetzt - Data Exposure!), CreateAccessKey (neuer API-Key - Persistence!) sowie DeleteTrail/StopLogging (Angreifer löscht CloudTrail - Defense Evasion!).

Azure-Datenquellen:

Activity Log: Azure Resource Manager API-Calls
Azure AD Sign-in Logs: alle Authentifizierungen inkl. Conditional Access
Azure AD Audit Logs: AD-Änderungen (User, Gruppen, Rollen)
Diagnostic Logs: per-Service-Logs für Storage, Key Vault usw.
Microsoft Defender for Cloud: Security Score + Alerts
Sentinel Connectors: Aggregation aller Log-Quellen

Kritische Azure Events: "Add member to role" (Privilege Escalation!), "Delete diagnostic setting" (Logging deaktiviert - Defense Evasion!), "Sign-in from unfamiliar location" und "User Risk changed to High".

GCP-Datenquellen: Cloud Audit Logs (Admin Activity, Data Access, System Events), VPC Flow Logs, Cloud Logging für alle Services sowie Security Command Center und Chronicle (GCP-natives SIEM mit Petabyte-Scale).

Qualitätsprobleme: CloudTrail Data Events sind standardmäßig nicht aktiviert (extra Kosten), Azure AD Sign-In Logs haben nur 30 Tage Retention im Free-Tier und VPC Flow Logs sind nicht standardmäßig aktiviert. Empfehlung: alle Logs in ein zentrales SIEM (Sentinel/Splunk/Chronicle) mit mindestens 12 Monaten Retention für ISO 27001 und NIS2.

ATT&CK for Cloud - Threat Landscape

Die wichtigsten MITRE ATT&CK Cloud-Techniken und ihre Erkennungsansätze:

T1078.004 - Valid Accounts: Cloud Accounts: Kompromittierte IAM-User, Service-Accounts, API-Keys. Erkennung: Login aus neuer Region, ungewöhnliche API-Calls nach Login.
T1530 - Data from Cloud Storage Object: S3/Azure Blob/GCS Exfiltration. Erkennung: GetObject-Calls an Bucket von unbekannter IP oder IAM-Entity.
T1537 - Transfer Data to Cloud Account: Daten in eigenen Cloud-Account kopieren. Erkennung: S3 Cross-Account-Copy, Azure AzCopy zu externem Account.
T1078.001 - Default Accounts: Root-Account-Nutzung, Default Service Accounts. Erkennung: Root-Account-Login sollte niemals passieren.
T1548.005 - Temporary Elevated Cloud Access: Privilege Escalation via PassRole, IAM:CreatePolicy, UpdateAssumeRolePolicy. Erkennung: User erstellt neue Policy mit hohen Rechten.
T1070.004 - Indicator Removal: CloudTrail-Deletion, Flowlog-Deaktivierung. Erkennung: DeleteTrail, StopLogging, PutBucketLogging (Logging deaktiviert).
T1136.003 - Create Account: Cloud Account: Neue IAM-User oder Service-Accounts für Persistence. Erkennung: CreateUser, CreateServicePrincipal ohne Ticket-Referenz.
T1098.001 - Additional Cloud Credentials: AttachUserPolicy, CreateAccessKey für Persistence. Erkennung: CreateAccessKey für anderen User, AttachUserPolicy mit Admin-Rechten.

Für den Aufbau einer ATT&CK Coverage-Matrix: alle relevanten Cloud-Techniken inventarisieren, für jede prüfen ob eine Detection Rule existiert, Coverage-Score berechnen (abgedeckte Techniken / gesamt × 100) und nach häufigsten Techniken in CISA-Berichten priorisieren.

Detection Rules - Cloud-spezifische KQL-Beispiele

// 1. Root Account Login (AWS) - Kritisch
AWSCloudTrail
| where EventName == "ConsoleLogin"
| where UserIdentityType == "Root"
| project TimeGenerated, SourceIpAddress, UserAgent, ErrorCode
| extend Severity = "Critical"
// Root-Account-Login sollte NIEMALS passieren!

// 2. CloudTrail Logging deaktiviert - Defense Evasion
AWSCloudTrail
| where EventName in ("DeleteTrail", "StopLogging", "UpdateTrail")
| where isempty(ErrorCode)  // Nur erfolgreiche Calls!
| project TimeGenerated, UserIdentityArn, EventName, SourceIpAddress

// 3. Neue IAM-Policy mit Admin-Rechten
AWSCloudTrail
| where EventName in ("CreatePolicy", "CreatePolicyVersion", "PutUserPolicy", "PutRolePolicy")
| where RequestParameters contains "\"Action\":\"*\""
      or RequestParameters contains "\"Resource\":\"*\""
| project TimeGenerated, UserIdentityArn, PolicyName=tostring(RequestParameters)

// 4. Azure: Neue Owner-Rollenzuweisung
AzureActivity
| where OperationNameValue == "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| extend RoleDefinitionId = tostring(parse_json(Properties).roleDefinitionId)
| where RoleDefinitionId endswith "8e3af657-a8ff-443c-a75c-2fe8c4bcb635"  // Owner GUID
| project TimeGenerated, Caller, ResourceGroup, Properties

// 5. Azure: Mass Resource Deletion (Ransomware-Indikator)
AzureActivity
| where ActivityStatusValue == "Success"
| where OperationNameValue endswith "/delete"
| summarize DeleteCount = count() by bin(TimeGenerated, 5m), Caller, ResourceGroup
| where DeleteCount > 10  // >10 Löschungen in 5 Min = Anomalie

Detection-as-Code und Sigma

Detection-as-Code bietet Versionierung in Git (wer hat eine Regel geändert und warum), Peer-Review für neue Rules (Vier-Augen-Prinzip), automatisierte Tests, Deployment via CI/CD ohne manuelle SIEM-Konfiguration sowie Portabilität zwischen SIEM-Produkten.

# Sigma-Regel: AWS S3 Bucket Made Public
title: AWS S3 Bucket Made Public
id: a91b3fd8-1234-5678-abcd-ef0123456789
status: experimental
description: Detects when an S3 bucket ACL is modified to allow public access
author: AWARE7 GmbH
date: 2026-03-04
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: s3.amazonaws.com
    eventName:
      - PutBucketAcl
      - PutBucketPolicy
    requestParameters|contains:
      - AllUsers
      - AuthenticatedUsers
  condition: selection
falsepositives:
  - Intentional public hosting (static websites)
level: high
tags:
  - attack.exfiltration
  - attack.t1530

# Sigma zu verschiedenen SIEM-Formaten konvertieren
sigma convert -t splunk sigma-aws-s3-public.yml
sigma convert -t microsoft365defender sigma-aws-s3-public.yml
sigma convert -t elasticsearch sigma-aws-s3-public.yml

Terraform ermöglicht das Deployment von Detection Rules als Code direkt in Azure Sentinel - Regeln werden versioniert, reviewed und automatisch deployed, ohne manuelle Konfiguration im SIEM-Interface.

False-Positive-Management

Zu viele Alerts führen zu Alert Fatigue, wodurch echte Angriffe übersehen werden.

Baselining-Strategien:

Zeitbasierte Baseline: Alerts nur außerhalb normaler Geschäftszeiten (z. B. where hourofday(TimeGenerated) !between (8 .. 18) und where dayofweek(TimeGenerated) !in (1d, 7d)).

Allowlist für bekannte IPs und User: bekannte Admin-IPs aus der Regel ausschließen (where SourceIpAddress !in (known_admin_ips)).

Threshold-Tuning: Nicht jeden CreateAccessKey-Aufruf alarmieren, sondern nur wenn der User bisher keinen Schlüssel hatte oder mehr als 3 Schlüssel in einer Stunde erstellt werden.

Anomalie-basierte Regeln mit ML: Azure Sentinel Anomaly Rules erstellen automatisch eine Baseline aus historischen Daten und alarmieren nur bei signifikanter Abweichung (über 3 Sigma) - keine manuelle Threshold-Pflege nötig.

FP-Tracking: Jeder Alert bekommt Feedback (True Positive, False Positive oder Benign TP). Monatliche FP-Rate pro Regel: über 50 % bedeutet Tuning oder Deaktivierung nötig, 0 % nach 3 Monaten bedeutet die Regel ist möglicherweise zu breit oder Angreifer wissen sie zu umgehen.

Metriken für Detection Engineering:

Metrik	Bedeutung
MTTD (Mean Time to Detect)	Wie lange bis Angriff erkannt?
FP-Rate	Prozentsatz Alerts die False Positives sind
Coverage	Prozentsatz ATT&CK-Techniken mit Detection
Alert Volume	Alerts pro Tag (SOC-Kapazität!)
Rule Health	Prozentsatz Regeln die in letzten 30 Tagen feuerten

Cloud Detection Engineering Prozess

Level 1 - Basis:

CloudTrail und Activity Logs aktiviert und archiviert (12+ Monate)
Natives Cloud-Alerting (GuardDuty, Defender for Cloud) aktiviert
Kritische Alerts (Root-Login, MFA-Bypass) lösen SOC-Tickets aus
Incident-Response-Playbook für Cloud-Incidents vorhanden

Level 2 - Fortgeschritten:

Zentrales SIEM mit Cloud-Log-Integration
Detection Rules für die Top-10 ATT&CK-Cloud-Techniken
Automated Response für kritische Rules (AWS Config Remediation, Logic Apps)
Monatliche Threat Hunts auf Basis neuer CISA/CTI-Berichte
Sigma-Repository mit versionierten Rules

Level 3 - Optimiert:

Detection-as-Code vollständig (Sigma + Terraform, CI/CD-deployed)
ATT&CK Coverage über 70 % der relevanten Cloud-Techniken
Kontinuierliche Adversary Simulation (Stratus Red Team täglich) als automatisierter Nachweis dass Rules funktionieren
Purple-Team-Exercises: Red Team mit Cloud-TTPs verbessert Detection
Threat Intelligence Feed mit automatischen Rule-Updates

Team-Setup: Ab 500 Mitarbeitern oder signifikanter Cloud-Nutzung empfiehlt sich mindestens ein Detection Engineer (Rule-Entwicklung, SIEM) und ein Cloud-Security-Engineer (Konfiguration, Architecture), ergänzt durch SOC-Analysten. Alternativ bietet Managed Detection & Response (MDR) für Cloud diese Funktion als Dienstleistung.