Обычный импорт запускал цепочку, после которой сервер уже не мог принадлежать владельцу.

В PyPI нашли вредоносные версии пакета durabletask, связанного с Durable Task Framework для облачных и автоматизированных Python-сред. Атака опасна тем, что заражение могло начаться без видимых признаков: достаточно было установить один из затронутых выпусков и импортировать библиотеку.
По данным Рафаэля Силвы из компании Aikido, вредоносный код попал в durabletask версий 1.4.1, 1.4.2 и 1.4.3. В пакет встроили загрузчик, который срабатывал при импорте на Linux-системах, скачивал файл rope.pyz с домена check.git-service[.]com и запускал его в фоновом процессе. Ошибки при этом скрывались, поэтому разработчик мог не заметить ничего подозрительного.
С каждой новой версией злоумышленники расширяли число заражённых файлов. В 1.4.1 код находился только в durabletask/__init__.py, в 1.4.2 добавили task.py, а в 1.4.3 загрузчик уже запускался из пяти точек входа. Такой подход повышал шанс срабатывания даже при частичном использовании библиотеки.
Основной модуль rope.pyz работал как похититель данных и сетевой червь. Перед запуском он проверял Linux, число ядер процессора и наличие нужных зависимостей. После проверки программа собирала секреты из AWS, Azure, GCP, Kubernetes, HashiCorp Vault, Docker, SSH, npm, pip, Terraform, VPN-конфигураций, файлов .env и популярных менеджеров паролей, включая 1Password и Bitwarden.
Украденные данные сжимались, шифровались и отправлялись на управляющий сервер. Если основной канал был недоступен, вредоносная программа искала в GitHub коммиты со строкой FIRESCALE, где мог находиться подписанный резервный адрес. Такой механизм позволял операторам быстро менять инфраструктуру после блокировок.
Отдельная часть кода отвечала за распространение. В AWS программа могла использовать SSM для запуска нагрузки на других EC2-инстансах, а в Kubernetes пыталась выполнить тот же сценарий внутри других pod. Для защиты от повторного заражения создавались маркеры ~/.cache/.sys-update-check и ~/.cache/.sys-update-check-k8s.
Самая опасная функция срабатывала только после команды с управляющего сервера. При признаках израильских или иранских системных настроек программа с небольшой вероятностью включала аудиофайл на полной громкости, а затем запускала удаление файловой системы. Такой сценарий указывает не только на кражу данных, но и на готовность атакующих уничтожать заражённые машины.
Администраторам, которые устанавливали durabletask 1.4.1, 1.4.2 или 1.4.3, рекомендуют считать такие хосты скомпрометированными. Нужно проверить маркеры заражения, файлы pgmonitor.py, службу pgsql-monitor.service, сетевые обращения к check.git-service[.]com и t.m-kosche[.]com, а затем заменить облачные ключи, SSH-ключи, токены GitHub, секреты Kubernetes, Vault и данные из локальных конфигураций.