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

GitHub Actions превратили в ботнет для атак на cPanel и WHM

583 вредоносных workflow-файла нашли в 10 PHP-пакетах: GitHub Actions использовали для атак на cPanel и кражи секретов с серверов.

✍️ Редакция iTech News | 24.07.2026 | ⏱ 5 мин | Источник: The Hacker News
🔐

За двое суток, 12 и 13 июля 2026 года, в десяти PHP-пакетах на Packagist появились 583 вредоносных workflow-файла. Исследователи выяснили, что GitHub Actions в этой схеме использовали не для атаки на разработчиков напрямую, а как распределенную инфраструктуру для сканирования и взлома cPanel и WHM. Для русскоязычных команд это неприятный, но полезный сигнал: CI/CD уже давно атакуют не только ради цепочки поставок, но и как готовую облачную вычислительную мощность.

О кампании сообщает The Hacker News со ссылкой на исследование Socket. Под удар попали пакеты, связанные с легитимным PHP- и DevOps-разработчиком dinushchathurya: среди них nationality-list, uk-post-code, websmslk и еще семь библиотек. Ключевая деталь в том, что сами PHP-пакеты не были основным путем исполнения вредоноса. Злоумышленники добавили десятки GitHub Actions workflow в исходные репозитории, и именно они запускали дальнейшую атаку.

Механика выглядела довольно прагматично. Как только в скомпрометированный репозиторий прилетал push или workflow запускали вручную, поднимался GitHub-hosted runner. Дальше автоматизация определяла архитектуру машины, будь то x86, x86_64, ARM или ARM64, и тянула подходящий Linux-пейлоад с управляющего сервера 43.228.157[.]68. После этого начиналось сканирование внешних целей на предмет CVE-2026-41940 — уязвимости обхода аутентификации в cPanel и WebHost Manager, которая позволяет удаленному атакующему получить повышенный доступ к панели управления.

Если цель оказывалась уязвимой, история быстро переходила из категории «неприятно» в категорию «дорого». Пейлоад пытался не только зайти в cPanel или WHM без нормальной аутентификации, но и собрать все, что обычно лежит плохо: учетные данные, конфиги, переменные окружения, доступы к базам, SSH-материалы, Git-токены, облачные ключи, данные платежных сервисов и прочие секреты. По словам исследователя Socket Кирилла Бойченко, среди выгружаемых артефактов были AWS-учетки, токены GitHub и GitLab, ключи OpenAI и Google API, Stripe, SendGrid и Mailgun, а также информация о remote-репозиториях и результаты удаленного выполнения команд. Иными словами, цель атаки — не один сервер, а весь возможный следующий периметр вокруг него.

Отдельно показателен способ распространения. Между 12 и 13 июля Packagist автоматически синхронизировал вредоносные development-версии всех десяти пакетов после изменений в GitHub-репозиториях разработчика. Для экосистемы это важная деталь: автоматическая синхронизация между репозиторием и менеджером пакетов ускоряет нормальную доставку кода, но точно так же ускоряет доставку компрометации. В этом кейсе пользователи библиотек не были основной мишенью, как это часто бывает в supply chain-атаках. Злоумышленники использовали доверенную инфраструктуру GitHub Actions как бесплатный распределенный парк раннеров для внешней эксплуатации чужих серверов.

Масштаб кампании, похоже, шире одного аккаунта. Socket нашла около 6100 workflow-файлов на GitHub с уникальным идентификатором DNSHook — f5b0b742-240a-4811-8a5b-b0ba6060685d. Это уже похоже не на разовый налет на конкретного мейнтейнера, а на отлаженную схему, где компрометированные репозитории превращают в одноразовые узлы ботнета. При такой модели злоумышленнику не нужно долго удерживать доступ к одному проекту: достаточно быстро влить workflow, прогнать раннеры, собрать секреты и уйти. Для платформ вроде GitHub это отдельная головная боль, потому что внешне активность выглядит как обычная автоматизация.

На этом фоне Socket раскрыла еще одну кампанию — Operation Muck and Load. Там речь уже о сети из 200 GitHub-репозиториев на 190 аккаунтах, через которые распространяли Windows-вредоносы: стилеры, загрузчики, дропперы, шпионское ПО, RAT и майнеры Monero. Часть репозиториев маскировалась под девелоперские утилиты и интеграции с криптокошельками. Сценарий был многоступенчатым: сначала жертва получала PowerShell-скрипт, затем тот опрашивал Pastebin, Telegram, YouTube, Instagram, Google Docs, Gitcode и другие площадки, чтобы достать защищенный архив с основным пейлоадом. Несколько репозиториев, по данным исследователей, служили не только приманкой, но и прямым хостингом вредоносных файлов.

Есть и еще один неприятный вывод. Socket видит тактические пересечения с активностью, которую Trend Micro ранее связывала с адресом ischhfd83@rambler[.]ru и отслеживала под именем Water Curse. Речь идет о GitHub-ориентированной «призрачной» сети, которая перенаправляет пользователей на страницы с зараженными файлами. Это хорошо ложится в текущий тренд: разработчик ищет библиотеку, скрипт, тулзу для крипты, тестов, автоматизации или «красной команды», а вместо этого получает аккуратно упакованный вредоносный конвейер. Порог доверия к GitHub у многих все еще выше, чем к случайному архиву с форума, и атакующие этим пользуются без лишней скромности.

Для разработчиков и DevOps-команд здесь несколько практических выводов. Во-первых, проверка diff в workflow-файлах уже не факультативная рутина, а часть базовой гигиены репозитория. Во-вторых, development-версии пакетов и автоматические синки с GitHub стоит мониторить не менее внимательно, чем релизные теги. В-третьих, секреты, которые попадают на серверы cPanel и WHM, часто открывают дорогу далеко за пределы хостинга: в облако, в CI, в платежи, в почтовую инфраструктуру и в API-платформы. Когда один скомпрометированный workflow может превратить чужой раннер в охотника за такими ключами, спор о том, считать ли CI частью боевого периметра, уже выглядит немного академическим.

Главный вопрос теперь не в том, смогут ли платформы вычистить конкретные вредоносные workflow, а в том, насколько быстро индустрия научится считать GitHub Actions объектом защиты наравне с продом и корпоративным SSO. Пока репозитории остаются и витриной, и средой исполнения, и каналом доставки, атакующим не нужно изобретать экзотику: достаточно встроиться в привычный цикл разработки и немного помочь ему работать против владельца.

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