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

Primäre Datenquellen pro Cloud-Provider:

AWS:
  CloudTrail:             ALLE API-Calls (Management Events = wer hat was gemacht)
  CloudTrail S3-Events:   Data Events (Lesezugriffe auf S3 → teuer 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!)
  DeleteTrail/StopLogging         → Angreifer löscht CloudTrail (Defense Evasion!)

Azure:
  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 (Storage, Key Vault, etc.)
  Microsoft Defender for Cloud: Security Score + Alerts
  Sentinel Connectors:    Aggregation aller oben genannten Logs

  Kritische Azure Events:
  Add member to role             → Privilege Escalation!
  Create or update key vault key → Key-Rotation oder Angreifer-Key?
  Delete diagnostic setting      → Logging deaktiviert? (Defense Evasion!)
  Sign-in from unfamiliar location
  User Risk changed to High

GCP:
  Cloud Audit Logs:       Admin Activity + Data Access + System Events
  VPC Flow Logs:          Netzwerk-Traffic
  Cloud Logging:          Alle Service-Logs zentralisiert
  Security Command Center: Native Bedrohungserkennung
  Chronicle (SIEM):       GCP-natives SIEM mit Petabyte-Scale

Kritische Qualitätsprobleme:
  → CloudTrail Data Events: standardmäßig NICHT aktiviert! (extra Kosten)
  → Azure AD Sign-In Logs: nur 30 Tage Retention in Free-Tier!
  → VPC Flow Logs: nicht standardmäßig aktiviert, Kosten beachten
  → Empfehlung: Alle Logs → zentrales SIEM (Sentinel/Splunk/Chronicle)
    Retention: min. 12 Monate für Compliance (ISO 27001, NIS2)

ATT&CK for Cloud - Threat Landscape

MITRE ATT&CK Cloud-spezifische Taktiken:

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 nach Zugang
  Erkennung: GetObject-Calls an Bucket von unbekannter IP/IAM-Entity

T1537 - Transfer Data to Cloud Account
  → Angreifer kopiert Daten in eigenen Cloud-Account
  Erkennung: S3 Cross-Account-Copy, Azure AzCopy zu extern

T1078.001 - Default Accounts
  → Root Account Usage, Default Service Accounts
  Erkennung: Root-Account-Login (sollte NIE passieren!), MFA fehlt

T1190 - Exploit Public-Facing Application
  → Lambda, EC2, AppService via Schwachstelle kompromittiert
  Erkennung: Neue Outbound-Verbindungen von Lambda/EC2

T1548.005 - Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access
  → Privilege Escalation via PassRole, IAM:CreatePolicy, UpdateAssumeRolePolicy
  Erkennung: User erstellt neue Policy mit hohen Rechten

T1070.004 - Indicator Removal: File Deletion
  → CloudTrail-Deletion, Flowlog-Deaktivierung (Defense Evasion)
  Erkennung: DeleteTrail, StopLogging, PutBucketLogging (Logging deaktiviert)

T1136.003 - Create Account: Cloud Account
  → Neue IAM-User/Service-Accounts für Persistence
  Erkennung: CreateUser, CreateServicePrincipal ohne Ticket-Referenz

T1098.001 - Account Manipulation: Additional Cloud Credentials
  → AttachUserPolicy, CreateAccessKey für Persistence
  Erkennung: CreateAccessKey für anderen User, AttachUserPolicy mit Admin

Cloud-ATT&CK Coverage-Matrix aufbauen:
  1. Alle relevanten ATT&CK-Cloud-Techniken inventarisieren
  2. Für jede Technik: haben wir eine Detection Rule?
  3. Coverage-Score: (abgedeckte Techniken / gesamt) × 100
  4. Priorisierung: häufigste Techniken in CISA/Cloud IR-Berichten zuerst

Detection Rules - Cloud-spezifische KQL-Beispiele

Microsoft Sentinel KQL Detection Rules:

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!
// Sofort-Alert zu SOC + Cloud-Infrastruktur-Team

2. CloudTrail Logging deaktiviert - Defense Evasion:
AWSCloudTrail
| where EventName in ("DeleteTrail", "StopLogging", "UpdateTrail")
| where isempty(ErrorCode)  // Nur erfolgreiche Calls!
| project TimeGenerated, UserIdentityArn, EventName, SourceIpAddress
// Wenn Angreifer Logs löscht → blinder Fleck!

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)
// Neue Admin-Policy = potenzielle Privilege Escalation!

4. S3-Bucket öffentlich gesetzt:
AWSCloudTrail
| where EventName in ("PutBucketAcl", "PutBucketPolicy")
| where RequestParameters contains "AllUsers"
       or RequestParameters contains "AuthenticatedUsers"
| project TimeGenerated, BucketName=extract('"name":"([^"]+)"', 1, RequestParameters),
          UserIdentityArn, SourceIpAddress
// Sofort: Bucket-Policy prüfen, ggf. revertieren!

5. 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
// Owner-Rollenvergabe → sofortiger Alert!

6. 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
| project TimeGenerated, Caller, ResourceGroup, DeleteCount

7. GCP: Service Account Key Export (Credential-Diebstahl):
resource.type="audited_resource"
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"
-- Neuer SA-Key = potenzielle Credentials-Exfiltration!
-- SA-Keys sind langlebig → hohe Gefahr

8. Impossible Travel für Cloud-Console:
AWSCloudTrail
| where EventName == "ConsoleLogin"
| where isempty(ErrorCode)
| summarize Locations = make_set(SourceIpAddress) by bin(TimeGenerated, 1h), UserIdentityArn
| where array_length(Locations) > 1
// Manuelle Prüfung: Verschiedene Länder in 1 Stunde?

Detection-as-Code und Sigma

Detection-as-Code Ansatz:

Warum Detection-as-Code:
  → Versionierung in Git (wer hat Regel geändert? warum?)
  → Peer-Review für neue Rules (4-Augen-Prinzip)
  → Automatisierte Tests (Rule funktioniert?)
  → Deployment via CI/CD (keine manuelle SIEM-Konfiguration)
  → Portabilität zwischen SIEM-Produkten

Sigma - SIEM-agnostische Detection Rules:

Sigma-Regel Beispiel: AWS S3 Public ACL:
  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 Compiler:
  # Zu Splunk konvertieren:
  sigma convert -t splunk sigma-aws-s3-public.yml

  # Zu Microsoft Sentinel (KQL):
  sigma convert -t microsoft365defender sigma-aws-s3-public.yml

  # Zu Elasticsearch:
  sigma convert -t elasticsearch sigma-aws-s3-public.yml

Terraform für Detection-as-Code (Azure Sentinel):
  resource "azurerm_sentinel_alert_rule_scheduled" "s3_public_acl" {
    name                = "aws-s3-public-acl"
    log_analytics_workspace_id = azurerm_log_analytics_workspace.sentinel.id
    display_name        = "AWS S3 Bucket Made Public"
    severity            = "High"
    query               = file("kql/aws-s3-public-acl.kql")
    query_frequency     = "PT5M"
    query_period        = "PT5M"
    trigger_operator    = "GreaterThan"
    trigger_threshold   = 0
    incident_configuration {
      create_incident = true
    }
  }

Automatisierte Rule-Tests:
  # pytest-sigma oder sigma-tester:
  def test_s3_public_acl_rule():
    malicious_event = {
      "eventSource": "s3.amazonaws.com",
      "eventName": "PutBucketAcl",
      "requestParameters": {"accessControlList": {"AllUsers": "READ"}}
    }
    assert rule_matches(malicious_event, sigma_rule) == True

    benign_event = {
      "eventSource": "s3.amazonaws.com",
      "eventName": "PutBucketAcl",
      "requestParameters": {"accessControlList": {"AuthenticatedUsers": "READ"}}
      # Noch immer problematisch, aber andere Rule!
    }

False-Positive-Management

FP-Rate optimieren ohne Coverage zu verlieren:

Problem: Zu viele Alerts → Alert Fatigue → echte Angriffe übersehen!

Baselining-Strategien:

1. Zeitbasierte Baseline:
   → KQL: was ist "normal" zu Geschäftszeiten vs. nachts/Wochenende?
   → Alerts nur wenn außerhalb normaler Zeitfenster:
   | where hourofday(TimeGenerated) !between (8 .. 18)  // Nur außerhalb 8-18 Uhr
   | where dayofweek(TimeGenerated) !in (1d, 7d)  // Kein Wochenende

2. Allowlist für bekannte IPs/User:
   let known_admin_ips = dynamic(["10.0.0.1", "192.168.1.100"]);
   AWSCloudTrail
   | where SourceIpAddress !in (known_admin_ips)
   // Bekannte Admin-IPs ausschließen

3. Threshold-Tuning:
   → Nicht: jeder CreateAccessKey → Alert
   → Besser: CreateAccessKey für User dem bisher keiner gehörte
   → Oder: >3 CreateAccessKey-Calls in 1h (Massenanlage!)

4. Anomalie-basierte Regeln (ML):
   Azure Sentinel Anomaly Rules:
   → Automatische Baseline aus historischen Daten
   → Alert nur bei signifikanter Abweichung (>3σ)
   → Keine manuelle Threshold-Pflege nötig

FP-Tracking und Verbesserung:
  → Jeder Alert bekommt Feedback: True Positive / False Positive / Benign TP
  → Monatliche FP-Rate pro Rule berechnen
  → FP-Rate > 50%: Rule tunen oder deaktivieren
  → FP-Rate = 0% nach 3 Monaten: Rule schärfen (zu breit? Angreifer weiß es zu umgehen?)

Metriken für Detection Engineering:
  MTTD (Mean Time to Detect):    Wie lange bis Angriff erkannt?
  FP-Rate:                       % Alerts die False Positives sind
  Coverage:                      % ATT&CK-Techniken mit Detections
  Alert Volume:                  Alerts/Tag (SOC-Kapazität!)
  Rule Health:                   % Regeln die in letzten 30 Tagen feuerten

Cloud Detection Engineering Prozess

Reifegrad-Modell (analog zu BSIMM/OWASP SAMM):

Level 1 - Basis:
  □ CloudTrail/Activity Logs aktiviert und archiviert (12+ Monate)
  □ Natives Cloud-Alerting (GuardDuty, Defender for Cloud) aktiviert
  □ Kritische Alerts (Root-Login, MFA-Bypass) → SOC-Ticket
  □ Incident-Response-Playbook für Cloud-Incidents vorhanden

Level 2 - Fortgeschritten:
  □ Zentrales SIEM mit Cloud-Log-Integration
  □ Detection Rules für Top-10 ATT&CK-Cloud-Techniken
  □ Automated Response: kritische Rule → AWS Config Remediation / Logic App
  □ Monatliche Threat-Hunt: neue Angreifer-TTPs aus CISA/CTI überprüfen
  □ Sigma-Repository mit versionierten Rules

Level 3 - Optimiert:
  □ Detection-as-Code vollständig (Sigma + Terraform, CI/CD-deployed)
  □ ATT&CK Coverage: >70% der relevanten Cloud-Techniken abgedeckt
  □ Kontinuierliche Adversary Simulation (Stratus Red Team täglich)
  → Automatisierter Nachweis dass Rules funktionieren!
  □ Purple-Team-Exercises: Red Team mit Cloud-TTPs → Detection verbessern
  □ Threat Intelligence Feed → automatische Rule-Updates

Cloud-Detection-Engineering-Team-Setup:
  Empfohlen ab 500 Mitarbeiter / signifikanter Cloud-Nutzung:
  → 1 Detection Engineer (Rule-Entwicklung, SIEM)
  → 1 Cloud-Security-Engineer (Konfiguration, Architecture)
  → SOC-Analysts die Rules betreiben
  Alternativ: Managed Detection & Response (MDR) für Cloud