Как произошла атака Megalodon на GitHub и почему она стала тревожным сигналом для безопасности CI/CD

Кампания длилась примерно с 11:36 до 17:48 по UTC, что указывает на полностью автоматизированную систему, способную быстро заражать тысячи репозиториев до того, как владельцы заметят подозрительные изменения.

Как злоумышленники смогли добавить тысячи коммитов

Чтобы замаскировать атаку и масштабировать её, использовалась комбинация автоматизации и социальной маскировки.

Поддельные CI‑боты и одноразовые аккаунты

Атакующие создавали временные GitHub‑аккаунты со случайными именами и выдавали их за автоматические сервисы. Среди использованных псевдонимов встречались:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Такие имена заставляли коммиты выглядеть как обычные изменения от автоматических систем сборки, а не от человека‑злоумышленника.

Подделка метаданных коммитов

Сообщения коммитов и информация об авторе были тщательно оформлены так, чтобы напоминать обычные обновления конфигурации CI или workflow. Это позволяло вредоносным изменениям сливаться с обычной историей разработки и отсрочивать обнаружение.

Использование слабой защиты веток

Кампания преимущественно нацеливалась на репозитории со слабыми или отсутствующими правилами branch protection.

Если в проекте нет обязательного код‑ревью, pull‑request‑процедуры или ограничений на изменение workflow‑файлов, злоумышленник может напрямую отправить изменения в основную ветку репозитория.

Заражённые GitHub Actions workflow

Каждый вредоносный коммит добавлял workflow GitHub Actions, содержащий Base64‑кодированный Bash‑скрипт. После запуска CI этот скрипт выполнялся внутри runner‑среды и начинал сбор секретов.

Из‑за этого атака могла оставаться незаметной до следующего запуска CI‑пайплайна.

Какие данные пытался украсть вредоносный код

Base64‑кодированный скрипт внутри workflow был предназначен для сбора чувствительной информации из среды CI и отправки её на сервер управления злоумышленников.

Среди целей были:

• переменные окружения CI/CD
• ключи и учётные данные облачных провайдеров (AWS, Google Cloud, Azure)
• приватные SSH‑ключи
• API‑токены и секреты приложений
• токены GitHub Actions OIDC
• другие конфигурационные секреты, доступные runner‑процессу

Скрипт собирал системную информацию, переменные окружения и секреты, после чего отправлял их на сервер управления (C2).

Проблема в том, что CI‑системы часто хранят ключи для деплоя, поэтому компрометация сборочной среды может открыть доступ к облачной инфраструктуре, пакетным реестрам и продакшн‑деплойментам.

Почему кража OIDC‑токенов особенно опасна

Одной из ключевых целей атаки были OIDC‑токены GitHub Actions.

Современные CI/CD‑пайплайны часто используют OpenID Connect (OIDC) для аутентификации в облачных сервисах без хранения долгоживущих ключей. Workflow запрашивает краткоживущий токен идентификации, который затем обменивается на временные облачные учётные данные.

Это повышает безопасность — статические API‑ключи больше не нужны. Но появляется новый риск: если токен украден во время выполнения пайплайна, злоумышленник может временно выдать себя за CI‑процесс.

Такие токены доверяются системами IAM облачных провайдеров, поэтому их можно обменять на временный доступ к облачной инфраструктуре с теми же правами, что и у pipeline.

Это потенциально открывает путь к:

• доступу к облачным ресурсам
• захвату системы деплоя
• извлечению секретов из облачных сервисов

Хотя срок жизни OIDC‑токенов короткий, даже кратковременный доступ может оказаться крайне ценным для атакующего.

Связана ли Megalodon с взломом GitHub через расширение VS Code

Примерно в то же время GitHub сообщил о другом инциденте безопасности, связанном с вредоносным расширением Visual Studio Code. Оно было установлено на устройство сотрудника и позволило злоумышленникам получить доступ примерно к 3 800 внутренним репозиториям GitHub.

Этот инцидент был связан с заражённым расширением, распространявшимся через маркетплейс VS Code и предназначенным для кражи токенов и учётных данных разработчиков.

Некоторые исследователи отмечают сходство во времени и тактиках между этим событием и другими атаками на инструменты разработки. Однако публичных доказательств того, что компрометация GitHub напрямую привела к атаке Megalodon, пока нет.

По состоянию на сейчас эти события рассматриваются как два отдельных, но произошедших почти одновременно инцидента безопасности в экосистеме разработки.

Что эта атака показала индустрии

Кампания Megalodon демонстрирует заметный сдвиг в атаках на цепочку поставок ПО: вместо изменения исходного кода злоумышленники всё чаще пытаются компрометировать инфраструктуру автоматизации.

Атака на CI‑workflow позволяет:

• автоматически красть секреты при каждом запуске сборки
• получать доступ к системам деплоя
• маскироваться под обычные изменения инфраструктуры

Поскольку тысячи проектов зависят от CI/CD‑пайплайнов с привилегированными учётными данными, одна вредоносная правка workflow может открыть доступ к множеству downstream‑систем.

Инцидент усилил внимание к базовым мерам защиты CI/CD:

• строгие правила защиты веток
• обязательный код‑ревью для изменений workflow
• минимальные привилегии для CI‑процессов
• мониторинг автоматических аккаунтов и изменений pipeline

По мере того как системы сборки всё чаще управляют облачными инфраструктурами и продакшн‑деплойментами, безопасность CI/CD становится ключевым элементом защиты всей цепочки поставок программного обеспечения.