Специалисты YesWeHack и Sekoia обнаружили вредоносную кампанию, нацеленную на исследователей информационной безопасности. Злоумышленники публикуют на GitHub фальшивые PoC-эксплоиты для свежих и громких уязвимостей, рассчитывая на то, что специалисты быстро скачают код, запустят его для проверки и сами установят малварь на свои рабочие машины или тестовые окружения. В результате вместо демонстрации эксплуатации уязвимости пользователь получает троян удаленного доступа ChocoPoC.
Такая схема особенно опасна тем, что она бьет по людям, которые сами занимаются анализом угроз. ИБ-исследователи, пентестеры, специалисты SOC, администраторы и red team-команды часто скачивают PoC-код сразу после раскрытия новой CVE, чтобы проверить собственную инфраструктуру, подготовить правила обнаружения или понять практический риск. Злоумышленники используют именно эту срочность: чем громче уязвимость, тем выше шанс, что кто-то запустит «эксплойт» без полноценной проверки всей цепочки зависимостей.
ChocoPoC работает как троян удаленного доступа. После заражения он ворует пароли, cookies, данные автозаполнения и историю из браузеров Chrome, Brave, Edge и Firefox. Кроме того, вредонос собирает текстовые файлы, заметки, локальные базы данных, историю командной строки, сетевые настройки и список запущенных процессов. Такой набор данных особенно ценен, если заражена машина специалиста по безопасности, потому что на ней могут храниться доступы к тестовым стендам, корпоративным VPN, GitHub, облакам, багбаунти-платформам и внутренним инструментам.
Главная хитрость кампании заключается в том, что вредоносный код скрыт не в самом PoC-репозитории. При беглом просмотре файлов исследователь может не увидеть ничего явно опасного. Настоящая загрузка начинается после команды pip install, когда фальшивый эксплойт подтягивает зависимость frint. Та, в свою очередь, скачивает пакет skytext, внутри которого уже находится скомпилированный модуль gradient.so для Linux или gradient.pyd для Windows.
Такой подход делает атаку похожей на компрометацию цепочки поставки Python-пакетов. Пользователь думает, что устанавливает зависимости для демонстрационного эксплойта, но фактически доверяет неизвестным пакетам из внешнего репозитория. Если зависимость содержит скомпилированный бинарный модуль, обычный просмотр Python-кода уже не помогает. Вредоносная логика может быть спрятана внутри .so или .pyd-файла, который требует отдельного анализа.
Еще одна важная деталь — модуль запускается только вместе с PoC и проверяет наличие файла EXPLOIT_POC.py или похожего названия. Только после этого происходит распаковка полезной нагрузки и загрузка самого ChocoPoC. Благодаря такой схеме отдельный запуск вредоносного пакета в песочнице может ничего не показать. Если аналитик проверит skytext отдельно, без остальных файлов репозитория, малварь останется неактивной и создаст ложное ощущение безопасности.
Это один из самых неприятных приемов для анализа. Защитники часто проверяют подозрительный пакет изолированно, чтобы понять, что он делает. Но в данном случае вредонос зависит от контекста: ему нужен конкретный PoC-файл или структура репозитория. Такая логика помогает обходить автоматические песочницы, потому что они могут запускать пакет не так, как его запускает реальная жертва. В результате вредоносное поведение проявляется только в настоящем сценарии использования.
После запуска ChocoPoC предоставляет операторам удаленный доступ к зараженной машине. Они могут выполнять произвольные команды, запускать Python-код, скачивать целые директории и приостанавливать активность малвари, чтобы не привлекать внимания. Возможность временно «затихнуть» особенно важна для скрытности: если исследователь запускает диагностику, вредонос может уменьшить активность, снизить сетевой шум и переждать проверку.
Сбор истории командной строки делает ChocoPoC особенно опасным для специалистов. В терминале часто остаются команды с адресами внутренних серверов, именами проектов, токенами, путями к ключам, параметрами API, командами подключения к VPN, kubectl, docker, cloud-cli и другим инструментам. Даже если пароли не хранятся в открытом виде, история команд может дать злоумышленнику карту инфраструктуры и подсказать, где искать более ценные секреты.
Кража cookies и данных браузеров позволяет обходить обычную парольную защиту. Если у пользователя активна сессия GitHub, облачного сервиса, корпоративной панели, багбаунти-платформы или почты, атакующий может попытаться использовать украденные cookie для входа без знания пароля. Многофакторная аутентификация снижает риск, но не всегда спасает от кражи сессии, особенно если сервис не проверяет устройство, географию, срок действия и дополнительные признаки риска.
ChocoPoC также собирает локальные базы данных и текстовые файлы. Для ИБ-исследователей это может означать утечку отчетов, заметок по уязвимостям, черновиков эксплойтов, списков целей, результатов сканирования, конфигураций лабораторий, ключей SSH, файлов .env и токенов доступа. Если специалист работает с клиентскими проектами, заражение его машины может привести уже не только к личному инциденту, но и к компрометации данных заказчиков.
Для управления вредонос использует нестандартную инфраструктуру. Адреса управляющих серверов скрыты в датасете картографического сервиса Mapbox. Малварь получает адрес C2 через DNS-over-HTTPS и применяет domain fronting, из-за чего трафик выглядит как обычные обращения к API Mapbox. Такой способ связи осложняет блокировку: защитникам труднее отличить вредоносную активность от легитимного использования публичного сервиса.
DNS-over-HTTPS скрывает DNS-запросы внутри HTTPS-трафика, поэтому обычный сетевой мониторинг может не увидеть, какие домены реально запрашивает вредонос. Domain fronting дополнительно маскирует конечную инфраструктуру за известным сервисом. В результате простое правило «заблокировать подозрительный домен» может не сработать, а блокировка всего Mapbox для организации может быть нежелательной, если сервис используется легитимно.
Использование Mapbox показывает, что злоумышленники стараются прятаться за доверенной облачной и API-инфраструктурой. Это уже не примитивный вредонос, который просто стучится на неизвестный IP-адрес. Он использует легальные сервисы как слой маскировки. Для защиты от таких угроз нужны поведенческие признаки: кто обращается к API, откуда, как часто, с каким User-Agent, какие объемы данных передаются и есть ли связь с запуском подозрительных Python-пакетов.
Исследователи обнаружили как минимум семь фальшивых репозиториев, которые якобы содержали эксплоиты для свежих уязвимостей. Среди приманок были FortiWeb CVE-2025-64446, React2Shell CVE-2025-55182, MongoBleed CVE-2025-14847, PAN-OS CVE-2026-0257, Ivanti Sentry CVE-2026-10520, Check Point VPN CVE-2026-50751 и Joomla SP Page Builder CVE-2026-48908. Выбор таких тем выглядит логично: это названия, которые могут заинтересовать специалистов, отслеживающих срочные риски.
Фальшивые PoC часто появляются вскоре после публикации информации о громких уязвимостях. Злоумышленники понимают, что в этот момент у защитников мало времени. Администраторам нужно срочно понять, уязвима ли их инфраструктура, а исследователям — проверить детали. На этом фоне репозиторий с названием нужной CVE может выглядеть как полезная находка, особенно если он оформлен правдоподобно и содержит знакомую структуру кода.
Пакет skytext, использовавшийся в атаках, был загружен около 2400 раз, преимущественно пользователями Linux-систем. Это число не равно количеству заражений, потому что часть скачиваний могла быть автоматической, повторной, исследовательской или выполненной в изолированной среде. Но пики загрузок совпадали с раскрытием информации о серьезных уязвимостях, что подтверждает эффективность выбранной тактики: злоумышленники подстраивались под новостной цикл кибербезопасности.
Эксперты считают, что кампания могла начаться еще в конце 2025 года. Тогда использовались похожие пакеты slogsec и logcrypt.cryptography. С высокой вероятностью за обеими волнами стоят одни и те же операторы, потому что в коде нашли повторяющиеся маркеры управляющей инфраструктуры. Это говорит не об одиночной попытке, а о продолжительной кампании против людей, которые работают с уязвимостями и эксплойтами.
Злоумышленники регулярно меняли аккаунты GitHub, PyPI и Mapbox. Часть таких учетных записей могла быть создана с использованием украденных данных или предварительно взломана. Это усложняет доверие к внешним признакам. Даже если аккаунт выглядит не совсем новым, имеет историю или правдоподобное имя, это не гарантирует безопасность. В цепочке поставки важна не только репутация аккаунта, но и проверка конкретного кода, зависимостей и поведения.
Некоторые названия команд в ChocoPoC написаны на испанском языке, а в коде встречаются мелкие ошибки. По мнению исследователей, это может указывать на ручную разработку вредоноса, а не на генерацию с помощью ИИ. Но для практической защиты происхождение кода менее важно, чем его возможности. Даже написанная вручную малварь с ошибками может быть эффективной, если она попадает на машину специалиста, где есть ценные доступы.
Для ИБ-исследователей главный урок очевиден: любой PoC-эксплойт из неизвестного репозитория нужно считать потенциально вредоносным. Особенно если он появился сразу после раскрытия громкой уязвимости, требует pip install, подтягивает зависимости из PyPI, содержит скомпилированные модули или просит запустить код без подробного объяснения. В мире кибербезопасности PoC давно стали не только инструментом проверки, но и популярной приманкой.
Проверять нужно не только основной файл эксплойта. Настоящая опасность часто находится в requirements.txt, setup.py, pyproject.toml, post-install скриптах, бинарных модулях, архивированных данных, GitHub Actions, Dockerfile, Makefile и внешних зависимостях. Если PoC требует установить пакет от неизвестного автора, нужно остановиться и понять, зачем он нужен, когда опубликован, кто его поддерживает и что внутри.
Особенно опасны пакеты с маленьким числом скачиваний, свежей датой публикации, отсутствием понятной документации, похожим названием на легитимный проект или странным набором файлов. Typosquatting, dependency confusion и вредоносные post-install скрипты остаются распространенными методами атаки. ChocoPoC показывает, что злоумышленники могут использовать не только похожие имена, но и многоступенчатую цепочку, где вредоносная логика спрятана через несколько зависимостей.
Запуск PoC в виртуальной машине снижает риск, но не дает полной гарантии. Если виртуальная машина подключена к рабочему аккаунту, имеет доступ к общим папкам, VPN, SSH-ключам, внутренним сетям или браузерным сессиям, вредонос все равно может украсть ценные данные. Лабораторная среда должна быть одноразовой, изолированной, без личных и корпоративных секретов, без доступа к внутренней сети и с возможностью полного удаления после теста.
Даже одноразовая песочница должна быть настроена правильно. Нельзя монтировать домашнюю директорию хоста, передавать SSH-ключи, использовать рабочий браузерный профиль, подключать корпоративный VPN или хранить реальные токены внутри тестовой машины. PoC должен запускаться в среде, где потеря всей системы не имеет значения. Если после запуска вредоноса нужно «чистить» машину вручную, значит изоляция уже была недостаточной.
Для проверки подозрительных PoC полезно сначала читать код без запуска, затем анализировать зависимости, затем выполнять установку с отключенной сетью или через локальное зеркало пакетов, если это возможно. Также можно использовать инструменты контроля системных вызовов, сетевой мониторинг, eBPF, strace, tcpdump, песочницы и snapshot’ы виртуальных машин. Но главное правило остается простым: неизвестный PoC не должен запускаться в рабочем окружении.
Если пакет frint, skytext, slogsec или logcrypt.cryptography уже запускался на машине, систему нужно считать скомпрометированной. Простое удаление пакета недостаточно, потому что ChocoPoC мог украсть cookies, пароли, токены и файлы, а также предоставить операторам удаленный доступ. Специалисты рекомендуют сменить учетные данные и полностью переустановить систему. Это жесткая мера, но для RAT на машине исследователя она оправдана.
После возможного заражения нужно сменить пароли с чистого устройства, отозвать активные сессии, заменить SSH-ключи, GitHub-токены, cloud API keys, VPN-сертификаты, PyPI-токены, npm-токены и любые другие секреты, которые могли находиться на машине. Если использовать старые ключи после переустановки, злоумышленник может продолжить доступ уже без малвари. Ротация секретов должна быть такой же обязательной, как очистка системы.
Нужно проверить GitHub и другие репозитории на неизвестные действия: новые deploy keys, personal access tokens, OAuth-приложения, webhooks, изменения в репозиториях, новые участники, странные коммиты и публикации пакетов. Если зараженный исследователь имел права на проекты, злоумышленники могли попытаться использовать эти права для дальнейшей атаки на цепочку поставки. Компрометация одного специалиста может стать входом к другим пользователям.
Для корпоративных команд безопасности стоит пересмотреть правила работы с PoC. Нельзя, чтобы каждый аналитик скачивал и запускал свежие эксплойты на своей рабочей машине. Должна быть отдельная лаборатория, изолированный сегмент, временные виртуальные машины, запрет на реальные секреты, контролируемый доступ в интернет и процедура проверки зависимостей. Срочность новой CVE не должна отменять базовую гигиену.
SOC-команды могут добавить детекты на установку пакетов frint, skytext, slogsec и logcrypt.cryptography, запуск скомпилированных модулей gradient.so и gradient.pyd, обращения к Mapbox API после установки PoC, необычный DNS-over-HTTPS, выполнение Python-кода из недавно скачанных репозиториев, массовое чтение браузерных профилей и попытки доступа к файлам cookies, истории и автозаполнения.
Важно отслеживать не только известные имена пакетов. Операторы уже меняли аккаунты и инфраструктуру, поэтому в будущем названия могут быть другими. Более устойчивые признаки — цепочка установки неизвестной зависимости, скомпилированный модуль внутри Python-пакета, проверка наличия PoC-файла, активность после pip install, чтение браузерных профилей и связь с внешним управляющим сервисом через легитимные API. Поведенческие правила переживают смену имен лучше, чем простые индикаторы.
Для организаций с bug bounty и red team-процессами полезно разделять личные исследовательские среды и корпоративные доступы. Если специалист занимается анализом внешних PoC, у него не должно быть одновременно открыто всё: корпоративная почта, админские панели, облачные CLI, production VPN и токены публикации пакетов. Чем меньше секретов находится в лабораторной среде, тем меньше ущерб от вредоносного PoC.
Отдельно нужно пересмотреть хранение секретов в браузере. ChocoPoC прямо нацелен на пароли, cookies, автозаполнение и историю. Хранение всех рабочих доступов в браузере удобно, но при заражении превращает браузер в главный источник данных для атакующего. Менеджеры паролей, аппаратные ключи безопасности, короткоживущие токены, запрет сохранения критичных паролей и строгая политика сессий помогают снизить риск.
Многофакторная аутентификация обязательна, но не является полной защитой от кражи cookies. Поэтому для важных сервисов нужно включать проверку устройства, уведомления о новых входах, ограничение по IP, короткое время жизни сессий, запрет повторного использования старых токенов и возможность быстро отозвать все активные сессии. После заражения исследовательской машины нужно считать, что все браузерные сессии могли быть украдены.
Для PyPI и других пакетных экосистем эта кампания снова показывает проблему доверия. Пакет может выглядеть как обычная зависимость, но фактически быть загрузчиком малвари. Платформы могут сканировать пакеты и блокировать очевидные угрозы, но многоступенчатые схемы с контекстной активацией сложнее обнаружить. Поэтому ответственность остается и на пользователях: автоматическая установка зависимостей из неизвестных источников всегда несет риск.
Для GitHub ситуация аналогичная. Платформа не может вручную проверять каждый PoC-репозиторий. Злоумышленники могут создавать правдоподобные описания, копировать стиль настоящих исследователей, добавлять README, ссылки на CVE и демонстрационные команды. Поэтому доверие к репозиторию должно строиться на репутации автора, прозрачности кода, независимых подтверждениях и аккуратном анализе, а не только на названии CVE в заголовке.
Нужно осторожно относиться к репозиториям, которые обещают эксплойт для слишком свежей и громкой уязвимости, но не имеют подробного технического объяснения. Настоящий исследователь обычно описывает условия эксплуатации, версии, ограничения, результат, безопасный режим проверки и предупреждения. Фальшивые репозитории часто делают ставку на срочность: «запустите команду», «проверьте прямо сейчас», «готовый exploit» — без достаточного анализа.
Для команд, которые публикуют собственные PoC, полезно подписывать релизы, четко описывать зависимости, избегать лишних бинарных модулей и объяснять, зачем нужен каждый пакет. Чем прозрачнее легитимный PoC, тем легче отличить его от вредоносной подделки. Репутация исследователя и открытость кода становятся частью безопасности сообщества.
ChocoPoC также показывает, что атакующие изучают поведение защитников. Они понимают, что исследователи будут запускать PoC в песочнице, поэтому делают малварь контекстно-зависимой. Они знают, что трафик к неизвестному серверу может быть замечен, поэтому используют Mapbox, DNS-over-HTTPS и domain fronting. Они понимают, что основной файл эксплойта будут читать, поэтому прячут вредонос в зависимостях. Это не хаотичная атака, а адаптация под привычки ИБ-сообщества.
Для обучения специалистов полезно разбирать такие кампании отдельно. Начинающим исследователям часто кажется, что опасны только неизвестные исполняемые файлы, а Python-скрипт из GitHub можно быстро запустить. На практике вредонос может находиться в пакетах, setup-скриптах, бинарных расширениях и сетевых загрузчиках. Поэтому безопасная работа с PoC должна быть частью базовой подготовки пентестера и аналитика.
Для домашних энтузиастов, которые читают новости о CVE и пробуют эксплойты ради интереса, риск тоже велик. Если человек запускает PoC на своем основном компьютере, где открыты почта, соцсети, криптокошельки, банковские кабинеты и рабочие аккаунты, вредоносный эксплойт может привести к полной компрометации личных данных. Даже если пользователь не работает в ИБ, он может стать жертвой кампании, рассчитанной на любопытство и срочность.
Лучший подход — никогда не запускать случайные PoC на основной системе. Для тестов нужен отдельный одноразовый контейнер или виртуальная машина без личных данных, без общих папок, без сохраненных паролей и без доступа к внутренним сетям. После теста среду лучше удалять, а не продолжать использовать. Если PoC требует странные зависимости, сетевой доступ и запуск бинарных модулей, от него лучше отказаться.
Главный вывод состоит в том, что ChocoPoC — это вредоносная кампания против ИБ-исследователей, где фальшивые GitHub-репозитории с PoC-эксплоитами устанавливают RAT через цепочку Python-зависимостей frint и skytext. Малварь активируется только в контексте репозитория с EXPLOIT_POC.py, что помогает обходить изолированный анализ, затем крадет пароли, cookies, данные браузеров, файлы, историю команд, сетевые настройки и дает операторам удаленный доступ к системе. Для управления используются Mapbox, DNS-over-HTTPS и domain fronting, а приманками служат громкие CVE в FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Check Point VPN и Joomla SP Page Builder. ИБ-специалистам нужно считать любые неизвестные PoC потенциально опасными, проверять зависимости, не запускать код в рабочей среде, использовать одноразовые изолированные лаборатории и при обнаружении frint, skytext, slogsec или logcrypt.cryptography считать систему скомпрометированной, менять все учетные данные и переустанавливать ОС.