Группировка TeamPCP провела успешную атаку на цепочку поставок PyPI, скомпрометировав Python SDK компании Telnyx — библиотеку облачных коммуникаций, которую в феврале 2026 года скачали более 700 000 раз. 27 марта 2026 года в 03:51 UTC на PyPI появились вредоносные версии пакета

Метод проникновения остаётся неизвестным. Ни утечки токенов в GitHub-воркфлоу, ни настроенного OIDC (trusted publisher) обнаружено не было — то есть как именно злоумышленники получили публикационные учётные данные Telnyx на PyPI, аналитики пока не могут объяснить. Заражение активируется при обычном
Главное техническое новшество этой кампании — способ хранения вредоносной нагрузки. Вместо того чтобы вшить её прямо в исходный код пакета, TeamPCP разбили компоненты на три отдалённые точки внутри
Настоящая нагрузка вообще не хранится в коде пакета. Скрипт скачивает с C&C-сервера структурно корректные
Для Windows скрипт загружает файл
На Linux и macOS скрипт запускается как отвязанный фоновый процесс через
Сравнение с предыдущей атакой на LiteLLM показывает намеренную смену инфраструктуры. Тогда использовались зашифрованные HTTPS-домены (
Атрибуция к TeamPCP строится на шести совпадающих признаках в обеих операциях: идентичный RSA-4096 публичный ключ, идентификатор кампании
Атака на Telnyx в отличие от LiteLLM охватывает уже две платформы. В прошлый раз был только Linux; теперь Windows получает полноценный вектор с персистентностью через автозагрузку. За 8 дней группировка сменила цель с AI-инфраструктуры на телекоммуникационные инструменты, причём не просто переключилась, а улучшила технику сокрытия. TrendAI зафиксировала это в отчёте "Emerging Threats: TeamPCP Hits Telnyx: WAV Steganography and Windows Targeting", а для охоты по инфраструктуре рекомендован запрос
Любая система, на которую установлены версии
4.87.1 и 4.87.2. Версия 4.87.5 была помещена PyPI в карантин. Это произошло всего через 8 дней после атаки на LiteLLM — AI-прокси пакет, который стал предыдущей целью той же группировки. 
Изображение носит иллюстративный характер
Метод проникновения остаётся неизвестным. Ни утечки токенов в GitHub-воркфлоу, ни настроенного OIDC (trusted publisher) обнаружено не было — то есть как именно злоумышленники получили публикационные учётные данные Telnyx на PyPI, аналитики пока не могут объяснить. Заражение активируется при обычном
import telnyx: малварь встроена непосредственно в файл _client.py и запускается в момент импорта модуля. Главное техническое новшество этой кампании — способ хранения вредоносной нагрузки. Вместо того чтобы вшить её прямо в исходный код пакета, TeamPCP разбили компоненты на три отдалённые точки внутри
_client.py. Первая — функция-декодер _d(), спрятанная среди легитимных импортов. Вторая — Base64-строка длиной 4 428 символов с оркестратором для Linux, размещённая между __all__ и определениями классов. Третья — Windows-ветка со стеганографической логикой, дописанная в самом конце файла. Каждый фрагмент по отдельности выглядит достаточно безобидно, чтобы не срабатывали автоматические сканеры. Настоящая нагрузка вообще не хранится в коде пакета. Скрипт скачивает с C&C-сервера структурно корректные
.wav-файлы, которые проходят валидацию стандартным Python-модулем wave. Из первых 8 байт файла извлекается XOR-ключ, которым расшифровывается спрятанная внутри нагрузка. Именно этот приём — WAV-стеганография — впервые появился в кампании TeamPCP 22 марта 2026 года в варианте kamikaze.sh (вайпер для Kubernetes, задокументированный компанией Aikido). До боевого применения против Telnyx потребовалось всего 5 дней. Для Windows скрипт загружает файл
hangup.wav, извлекает из него PE-файл и устанавливает его под именем msbuild.exe в папку автозагрузки %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\. Процесс запускается с флагом CREATE_NO_WINDOW (значение 0x08000000), чтобы не светить терминал. Для снижения сетевого шума создаётся скрытый lock-файл msbuild.exe.lock через attrib +h: если файл модифицировался в течение последних 43 200 секунд (12 часов), повторное выполнение пропускается. На Linux и macOS скрипт запускается как отвязанный фоновый процесс через
subprocess.Popen с флагом start_new_session=True, а в качестве аудиоприманки используется ringtone.wav. Данные перед отправкой упаковываются через цепочку OpenSSL: генерация случайного ключа, шифрование AES-256-CBC, обёртка RSA-4096 OAEP, архивирование в tpcp.tar.gz. Итоговый архив уходит на сервер через HTTP POST с заголовком X-Filename: tpcp.tar.gz. Сравнение с предыдущей атакой на LiteLLM показывает намеренную смену инфраструктуры. Тогда использовались зашифрованные HTTPS-домены (
hxxps[://]models[.]litellm[.]cloud/ и hxxps[://]checkmarx[.]zone/raw), теперь — прямой IP-адрес по HTTP: hxxp[://]83[.]142[.]209[.]203:8080/. Скорее всего, это вынужденный откат после блокировок. Зато код стал значительно труднее для детектирования: нагрузка больше не встраивается в исходники пакета, а хранится на удалённом сервере. Атрибуция к TeamPCP строится на шести совпадающих признаках в обеих операциях: идентичный RSA-4096 публичный ключ, идентификатор кампании
tpcp.tar.gz, заголовок X-Filename: tpcp.tar.gz, одна и та же OpenSSL-цепочка шифрования, одинаковые соглашения об именовании временных файлов и одна схема выполнения через subprocess с пробросом stdin. Это не случайные совпадения — это штамп одной руки. Атака на Telnyx в отличие от LiteLLM охватывает уже две платформы. В прошлый раз был только Linux; теперь Windows получает полноценный вектор с персистентностью через автозагрузку. За 8 дней группировка сменила цель с AI-инфраструктуры на телекоммуникационные инструменты, причём не просто переключилась, а улучшила технику сокрытия. TrendAI зафиксировала это в отчёте "Emerging Threats: TeamPCP Hits Telnyx: WAV Steganography and Windows Targeting", а для охоты по инфраструктуре рекомендован запрос
eventSubId:201 AND request:"83.142.209.203" в TrendAI Vision One Search App. Любая система, на которую установлены версии
4.87.1 или 4.87.2, должна считаться полностью скомпрометированной. Необходимо немедленно откатиться до версии 4.87.0, ротировать все секреты и учётные данные, доступные на заражённой машине, зафиксировать зависимости по хешу и проверить CI/CD-пайплайны на признаки компрометации. Обнаружить заражение постфактум сложно именно потому, что нагрузка нигде не хранилась локально до момента исполнения.