Wie Storm-2949 eine kompromittierte Identität in einen cloudweiten Verstoß verwandelte

Zusammenfassung

Storm-2949 nutzte Social Engineering und Missbrauch von Self-Service Password Reset, um Microsoft Entra ID-Konten zu kompromittieren. Nach Erlangen von privilegiertem Zugriff nutzte der Bedrohungsakteur Azure-Managementebenenaktionen, um App Services, Key Vaults, Storage Konten und SQL-Datenbanken zu erreichen. Daten wurden dann aus Microsoft 365, Azure Storage und anderen Cloud-Ressourcen exfiltriert. Der Einbruch weitete sich später auf die Bereitstellung des ScreenConnect-Remotezugriffstools auf virtuellen Maschinen aus, um weitere Erkundung und Anmeldediebstahl zu unterstützen.

Untersuchung

Microsoft-Analysten beobachteten, dass die Angreifer Benutzer und Anwendungen über die Microsoft Graph API mit maßgeschneidertem Python-Tooling auflisteten. Sie riefen Veröffentlichungskonfigurationen von Azure App Services ab, extrahierten Geheimnisse aus Key Vaults, änderten Firewall-Regeln und nutzten die VMAccess-Erweiterung, um lokale Administratorkonten auf virtuellen Maschinen zu erstellen. In einer späteren Phase installierte ein PowerShell-Skript ScreenConnect, löschte Protokolle und tarnte Dienste, um die Sichtbarkeit zu reduzieren. Die Untersuchung verknüpfte diese Aktivität mit drei von Angreifern kontrollierten IP-Adressen.

Minderung

Organisationen sollten MFA aktivieren und für privilegierte Konten eine phishingsichere Authentifizierung verlangen. Azure RBAC-Berechtigungen sollten streng eingeschränkt und überwacht werden, insbesondere der Owner-Zugriff auf Key Vaults und App Services. Unnötige Azure VM-Erweiterungen sollten deaktiviert und Protokollierung für Run Command und VMAccess-Aktivität durchgesetzt werden. Außerdem sollten Microsoft Defender for Cloud und Defender for Endpoint mit Manipulationsschutz und Blockmodus aktiviert sein.

Antwort

Verteidiger sollten die identifizierten bösartigen IP-Adressen sofort blockieren und kompromittierte Anmeldedaten widerrufen. Passwörter und MFA-Registrierungen für betroffene Konten sollten zurückgesetzt und alle in Key Vaults gespeicherten Geheimnisse gedreht werden. Sicherheitsteams sollten auch eine vollständige Überprüfung der Azure RBAC-Zuweisungen durchführen und übermäßige Berechtigungen entfernen. Erkennungsregeln sollten aktualisiert werden, um verdächtige Anfragen nach Veröffentlichungskonfigurationen, Zugriffe auf Key Vault-Geheimnisse und unerwartete VM-Erweiterungsaktivitäten zu identifizieren.

Simulation Ausführung

Voraussetzung: Die Telemetrie- & Basislinienvorprüfung muss bestanden sein.

• Angriffserzählung & Befehle:

  Ein Angreifer, der über ein gültiges Azure AD-Konto (oder standardmäßigen Dienstprinzipal) verfügt, möchte Quellcode von Anwendungen und Datenbankschnappschüsse exfiltrieren. Der Angreifer führt die folgenden Schritte vollständig über Azure CLI aus, wobei genau das Betriebsname Ereignisse, die die Regel überwacht:

  1. Veröffentlichung von Web App XML – extrahiert die Web App-Konfiguration (einschließlich Bereitstellungszugriffsdaten).
  2. Erstellen eines neuen Speicherkontos – bietet einen Container zum Zwischenspeichern exfiltrierter Daten.
  3. Hinzufügen einer Firewall-Regel zum SQL-Server – öffnet den Server für den IP-Bereich des Angreifers, um direkte Datenkopien zu ermöglichen.

  Jeder Schritt erzeugt einen Eintrag im Aktivitätsprotokoll mit Betriebsname übereinstimmend mit der Whitelist der Regel, wodurch die Erkennung ausgelöst wird.

• Regressionstest-Skript:

  #!/usr/bin/env bash
  # Voraussetzung: az CLI ist mit einem kompromittierten/gültigen Azure AD-Prinzipal angemeldet.
  set -euo pipefail
  
  # Variablen – bei Bedarf für den Testmandanten ändern
  RG="test-rg-$(date +%s)"
  WEBAPP="test-webapp-$RANDOM"
  STORAGE="teststorage$RANDOM"
  LOCATION="eastus"
  SQLSERVER="testsql$RANDOM"
  MY_IP=$(curl -s https://api.ipify.org)
  
  echo "=== Erstellen der Ressourcengruppe ==="
  az group create --name "$RG" --location "$LOCATION"
  
  echo "=== Bereitstellung einer Dummy-Web-App ==="
  az appservice plan create --name "${WEBAPP}Plan" --resource-group "$RG" --sku B1 --is-linux
  az webapp create --resource-group "$RG" --plan "${WEBAPP}Plan" --name "$WEBAPP"
  
  echo "=== Veröffentlichen der XML-Konfiguration (löst Erkennung aus) ==="
  az webapp config backup create 
      --resource-group "$RG" 
      --webapp-name "$WEBAPP" 
      --backup-name "xmlbackup-$(date +%s)" 
      --output none
  
  echo "=== Erstellen eines Speicherkontos (löst Erkennung aus) ==="
  az storage account create 
      --name "$STORAGE" 
      --resource-group "$RG" 
      --location "$LOCATION" 
      --sku Standard_LRS 
      --kind StorageV2 
      --output none
  
  echo "=== Erstellen eines SQL-Servers (erforderlich für Firewall-Regel) ==="
  az sql server create 
      --name "$SQLSERVER" 
      --resource-group "$RG" 
      --location "$LOCATION" 
      --admin-user "sqladmin" 
      --admin-password "P@ssw0rd1234!" 
      --output none
  
  echo "=== Hinzufügen einer Firewall-Regel zum SQL-Server (löst Erkennung aus) ==="
  az sql server firewall-rule create 
      --resource-group "$RG" 
      --server "$SQLSERVER" 
      --name "AllowMyIP" 
      --start-ip-address "$MY_IP" 
      --end-ip-address "$MY_IP" 
      --output none
  
  echo "=== Simulation abgeschlossen. Überprüfen Sie Azure Sentinel auf Warnungen. ==="

• Bereinigungskommandos:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # Variablen müssen mit denen im Simulationsskript übereinstimmen
  RG="test-rg-..."
  # Wenn Sie die genauen Namen von der vorherigen Ausführung beibehalten haben, ersetzen Sie die Platzhalter entsprechend.
  
  echo "=== Löschen der Ressourcengruppe und aller enthaltenen Ressourcen ==="
  az group delete --name "$RG" --yes --no-wait
  echo "Bereinigung initiiert."