КИБЕРБЕЗОПАСНОСТЬ

В Австралии задержали двух предполагаемых участников TeamPCP

Более 1000 организаций пострадали от кампании TeamPCP: в Австралии задержали двух предполагаемых участников группы, связанной с атаками на цепочки поставок.

✍️ Редакция iTech News | 29.08.2026 | ⏱ 4 мин | Источник: Ars Technica
👁

Австралийская полиция задержала двух мужчин, которых считает участниками TeamPCP, группы, связанной с одной из самых заметных supply-chain кампаний последних месяцев. По версии следствия, атаки TeamPCP затронули более 1000 организаций по всему миру, а для разработчиков и компаний это очередное напоминание: компрометация одного пакета в CI/CD давно бьет не по одному репозиторию, а по всей цепочке зависимостей.

О задержаниях сообщает Ars Technica со ссылкой на заявление Australian Federal Police. По данным полиции, обоим фигурантам предъявили в общей сложности 14 обвинений. Имена официально не раскрываются; известно только, что речь идет о жителях Коттеслоу и Мандуры в Западной Австралии. Если обвинения подтвердятся, одному из них грозит более 20 лет тюрьмы, второму — более 10 лет.

Главная причина, по которой эта история вышла далеко за пределы криминальной хроники, в масштабе и механике самой кампании. TeamPCP связывают с серией атак на цепочки поставок ПО, начавшейся в декабре и продолжавшейся девять месяцев. Группа встраивала вредоносный код в open source-пакеты и инструменты так, чтобы заражение не останавливалось на первой жертве. После компрометации одного компонента вредоносный код переходил в последующие обновления, а затем попадал в инфраструктуру тех команд, которые просто устанавливали пакет и прогоняли его через свои CI/CD-пайплайны.

Ключевым элементом этой схемы стал червь Shai-Hulud. Его задача была не просто закрепиться в одной среде, а собирать учетные данные для других пакетов прямо из памяти зараженных машин. Получив эти credentials, участники группы могли подписывать или публиковать уже новые зараженные зависимости. Иными словами, модель атаки выглядела особенно неприятно для современной разработки: компрометируется не только код, но и доверие между пакетами, сборкой, публикацией и автоматизацией релизов. Когда инфраструктура устроена вокруг скорости поставки, такой сценарий дает атакующим почти идеальную точку входа.

Один из самых заметных эпизодов — заражение сканера уязвимостей Trivy. Дальше по цепочке, как пишет Ars Technica, были затронуты и downstream-пакеты, включая KICS, Python SDK компании Telnyx и LiteLLM. Это важная деталь не только для специалистов по безопасности, но и для техлидов, которые до сих пор считают supply-chain риск чем-то абстрактным из презентаций AppSec-команд. Здесь мы видим вполне прикладной сценарий: разработчик запускает привычный инструмент в конвейере, а вместе с ним получает канал компрометации собственной среды. В случае с Trivy последствия были особенно тяжелыми: изначальный взлом привел к краже терабайт учетных данных и другой закрытой информации.

Отдельно выделяется способ, которым Shai-Hulud связывался с управляющей инфраструктурой. Вместо более привычных серверов управления использовался canister на базе Internet Computer Protocol — разновидность смарт-контракта, позволявшая быстро менять URL и усложнять внешнее отключение канала связи. Зараженные машины, по данным источника, обращались к этому механизму примерно раз в 50 минут. Для защитников это неприятный, но показательный сигнал: злоумышленники все активнее используют не только баги в пакетах и процессы публикации, но и более экзотические элементы распределенной инфраструктуры, которые плохо вписываются в классические playbook'и по takedown и блокировке командных серверов.

Еще одна любопытная деталь касается не техники, а уровня операционной дисциплины. Брайан Кребс, который отдельно расследовал деятельность TeamPCP, писал, что группа не выглядела особенно аккуратной для атакующих такого масштаба. Исследователь Aikido Security Чарли Эриксен в комментарии KrebsOnSecurity заметил, что раньше для кампаний такого уровня требовались месяцы на изучение методов, настройку инфраструктуры и отладку кода, тогда как LLM заметно сократили этот разрыв. Это не доказательство того, что модели «сделали атаку», но довольно трезвое наблюдение о том, что порог входа в сложные операции снижается. Хорошая новость тут только одна: вместе с порогом входа нередко падает и дисциплина исполнителей, а значит, шансы на ошибки и деанон тоже растут.

Для русскоязычной IT-аудитории в этой истории есть несколько практических выводов без лишней драмы. Первый: атаки TeamPCP показывают, что доверять нужно не названию популярного инструмента, а процессу его верификации. Второй: безопасность CI/CD больше нельзя отдавать на откуп одному DevOps-инженеру или ставить в backlog после релиза. Третий: работа с секретами в памяти, токенами публикации и правами сервисных аккаунтов становится такой же критичной, как patch management. Если пайплайн умеет автоматически собирать, тестировать и выкатывать код, он должен столь же автоматически ограничивать blast radius при компрометации одной зависимости. Иначе supply-chain атака превращается из инцидента в эффект домино.

Задержание двух предполагаемых участников TeamPCP — это важный сигнал, но не финальная точка. Вопрос уже не в том, повторится ли похожая кампания, а в том, сколько команд по-прежнему строят разработку на доверии к пакетам и токенам, которые никто толком не пересматривал. Пока экосистема open source держится на высокой скорости интеграции, атакующие будут искать не самый сложный баг, а самый удобный маршрут через чужую автоматизацию.

Поделиться: Telegram X LinkedIn