Исследователи Aikido сообщили о новом этапе кампании TeamPCP: злоумышленники используют вредоносный скрипт, который проверяет, связана ли система с Ираном, и в таком случае не просто устанавливает бэкдор, а стирает данные. Речь идет прежде всего о Kubernetes-кластерах, но сценарий может затронуть и обычные Linux-хосты без Kubernetes.
По данным Aikido, новая кампания использует ту же инфраструктуру, что и ранее описанная CanisterWorm: тот же ICP canister как точку управления, тот же путь выгрузки /tmp/pglog и тот же код бэкдора. Исследователи прямо связывают этот этап с TeamPCP и отмечают, что в этот раз группа добавила то, чего раньше не наблюдалось, — удаление данных по политическому признаку.
Сначала вредоносный загрузчик определяет, находится ли он внутри Kubernetes. Для этого проверяет наличие типичных Kubernetes-признаков, например сервисных аккаунтов и переменных окружения кластера. Если kubectl на машине нет, скрипт скачивает его сам, после чего подтягивает Python-пейлоад и запускает его.
Дальше скрипт определяет, относится ли система к Ирану. Aikido пишет, что для этого используются как минимум два признака: часовой пояс, связанный с Ираном, и LANG fa_IR, то есть настройки языка/региона должны быть на фарси, в системных настройках времени стоять Asia/Tehran или Iran.
Если система распознана как иранская и при этом работает в Kubernetes, вредоносный код создает в kube-system DaemonSet с именем host-provisioner-iran. Он запускает привилегированные контейнеры на всех узлах, включая control plane. Каждый такой контейнер монтирует корневую файловую систему хоста и удаляет верхнеуровневые каталоги, после чего принудительно перезагружает узел. Aikido указывает, что контейнер в этой цепочке назывался kamikaze.
Если Kubernetes есть, но система не определяется как иранская, сценарий меняется: вместо уничтожения данных разворачивается DaemonSet host-provisioner-std, который устанавливает Python-бэкдор на узлы и регистрирует его как системный сервис, чтобы закрепиться. То есть вне «иранского» профиля злоумышленники, по данным исследователей, предпочитают не ломать инфраструктуру сразу, а сохранять постоянный доступ.
Если Kubernetes на машине нет, но локаль и часовой пояс указывают на Иран, вредоносный код пытается удалить данные локально, включая системные файлы. Исследователи описывают это как запуск rm -rf / --no-preserve-root; если прав root нет, код пробует использовать passwordless sudo. На системах, которые не подходят ни под одно из условий, вредонос завершает работу без дальнейших действий.
Aikido также пишет, что последние версии инструментария TeamPCP начали активнее использовать сетевое распространение: через SSH с разбором логов аутентификации и использованием украденных ключей, а также через открытый Docker API на порту 2375 внутри локальной сети. Среди индикаторов они перечисляют исходящие SSH-соединения с StrictHostKeyChecking=no, обращения к Docker API по 2375 и привилегированные контейнеры, смонтированные как hostPath.
За несколько дней до публикации про вайпер стало известно о supply-chain атаке на Trivy и связанную с ним инфраструктуру. Cloud Security Alliance пишет, что любые CI/CD-пайплайны, которые запускали Trivy версий 0.69.4–0.69.6 или использовали aquasecurity/trivy-action в период с 19 по 23 марта 2026 года, нужно рассматривать как потенциально полностью скомпрометированные. В первую очередь речь идет о риске утечки секретов, токенов, облачных учетных данных и SSH-ключей.
KrebsOnSecurity со ссылкой на Aqua Security и Wiz пишет, что в ходе этой цепочки атак злоумышленники смогли распространять вредоносные версии, способные красть SSH-ключи, облачные креды, Kubernetes-токены и даже криптокошельки. Это объясняет, откуда у атакующих могли появляться данные для дальнейшего перемещения по инфраструктуре.
Aikido и CSA также связывают кампанию с CanisterWorm — названием, которое исследователи дали инфраструктуре TeamPCP из-за использования ICP canister. Это, по сути, блокчейн-ориентированная схема управления: внутри хранится ссылка на актуальный сервер полезной нагрузки, и ее можно менять без обычной зависимости от классического домена или хостинга. CSA отдельно отмечает, что такой подход осложняет оперативное отключение инфраструктуры через стандартные процедуры.
KrebsOnSecurity пишет, что TeamPCP с конца 2025 года активно работал против облачной инфраструктуры, а не против пользовательских устройств. В материале Flare, который пересказывает Krebs, говорится, что группа делала ставку на автоматизацию, открытые контрол планы, неправильно настроенные сервисы и уже известные техники, а не на редкие уязвимости нулевого. Там же сказано, что среди ранее затронутых облаков преобладали Azure и AWS.
Исследователи рекомендуют проверить Kubernetes-кластеры на наличие подозрительных DaemonSet в kube-system, особенно host-provisioner-iran и host-provisioner-std, а хосты — на артефакты вроде /var/lib/pgmon/pgmon.py, /etc/systemd/system/pgmonitor.service, ~/.config/systemd/user/sysmon.py, /tmp/pglog и /tmp/.pg_state. Отдельно имеет смысл проверить, не открыт ли Docker API на 2375 без аутентификации, и ограничить lateral movement по SSH.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
