За шесть часов вредоносная кампания Megalodon GitHub успела отправить 5718 зараженных коммитов в 5561 репозиторий. Для разработчиков и компаний это неприятный, но полезный сигнал: атаки на supply chain больше не выглядят как точечная охота за крупной целью, теперь это конвейер, который массово лезет в CI/CD, ворует секреты и тихо остается в кодовой базе дольше, чем хотелось бы.
О кампании сообщает Dark Reading со ссылкой на исследование стартапа SafeDep. По данным компании, атака развернулась 18 мая и использовала поддельные аккаунты и фальшивые личности авторов коммитов, чтобы внедрять в GitHub Actions вредоносные workflow-файлы. Цель была вполне приземленной: вытащить из инфраструктуры CI/CD секреты, облачные учетные данные, SSH-ключи, OpenID Connect-токены и другие чувствительные данные, а затем отправить их на управляющий сервер злоумышленников. Параллельно атакующие могли добираться и до секретов в исходном коде.
SafeDep описывает Megalodon как двухступенчатую схему. Первый payload добавлял вредоносный YAML-файл с именем SysDiag, который создавал новый workflow при любом push или pull request. Второй был тоньше: он подменял уже существующие workflow, добавляя триггер workflow-dispatch. Это превращало зараженный pipeline в спящий бэкдор. Пока его не активируют через API GitHub, в интерфейсе почти нет поводов для паники: нет заметных запусков Actions, нет упавших сборок, нет ярких следов в истории CI. Для команд, которые привыкли ориентироваться на красные статусы в пайплайне, это особенно неприятный сценарий: компрометация уже есть, а внешне все выглядит почти штатно.
Первый след SafeDep нашла не в абстрактной выборке, а в конкретном npm-пакете @tiledesk/chat21-core, который относится к open source-платформе чат-ботов Tiledesk. Исследователи обнаружили, что у Tiledesk были заражены девять репозиториев, а их мейнтейнеры, не подозревая о подмене, опубликовали отравленный код дальше по цепочке. Это важный момент: подобные истории опасны не только числом взломанных репозиториев, но и тем, что заражение начинает жить собственной жизнью через downstream-зависимости и обычные релизные процессы. Один скомпрометированный workflow быстро превращается в проблему не одной команды, а десятков и сотен потребителей пакетов.
Почему кампания длилась всего шесть часов, пока непонятно. Инженер по безопасности SafeDep Абхисек Датта предположил, что злоумышленники, вероятно, использовали валидные учетные данные, добытые в предыдущих атаках на разработчиков и цепочку поставок ПО. По его гипотезе, атакующие просто прогнали весь список доступов, который был у них на руках, и на этом окно заражения закрылось. Звучит почти буднично, но вывод неприятный: если доступы настоящие, а действия похожи на обычную работу с репозиторием, стандартная защита на уровне «заметим что-то странное в логах» может не сработать вовремя.
Дополнительное исследование опубликовала OX Security. Компания подтвердила, что примерно 3500 репозиториев несли вредоносный YAML-файл. Позже число снизилось примерно до 2900, но и это не повод расслабляться: по словам исследователя OX Security Моше Симан Тов Бустана, спустя более недели после атаки зараженными оставались около 83% ранее скомпрометированных репозиториев. То есть основная фаза рассылки коммитов давно закончилась, а проблема продолжала жить в кодовой базе и workflows. Для бизнеса здесь плохая новость проста: окно атаки может занимать часы, а окно устранения последствий растягивается на недели, особенно если у компании десятки репозиториев, много self-hosted runner'ов и неидеальная инвентаризация секретов.
На этом фоне закономерно возник вопрос о возможной связи Megalodon с группой TeamPCP, которая уже мелькала в других громких историях этого года. Кампания Megalodon произошла за день до того, как TeamPCP взяла на себя ответственность за масштабный инцидент с GitHub, где, как утверждалось, был похищен код примерно из 4000 внутренних репозиториев. OX Security заметила и внешние совпадения: в зараженных коммитах была жестко задана дата 17 сентября 2001 года, а также использовались фальшивые bot-идентичности с адресами вроде [email protected] и [email protected]. Похожие поверхностные приемы встречались и в исходниках червя Shai-Hulud, которые ранее утекли в публичное поле. Но на этом сходства пока заканчиваются.
И SafeDep, и OX Security осторожны в выводах. Прямых технических индикаторов, компрометационных артефактов или признаний, которые надежно связали бы TeamPCP с Megalodon GitHub, пока нет. Исследователи прямо говорят: атрибуция не подтверждена, а совпадения могут быть намеренной мимикрией. Датта при этом не исключает, что разные группы могли делиться украденными доступами или работать через партнеров. Для рынка это уже почти новая норма: supply chain-атаки становятся модульными, где одни крадут учетные данные, другие масштабируют заражение, третьи монетизируют доступ через вымогательство или перепродажу.
Практический вывод для русскоязычных команд довольно приземленный. Если GitHub Actions в компании считаются вспомогательной инфраструктурой, а не частью поверхности атаки, этот подход пора пересмотреть. После таких кампаний мало просто удалить подозрительный YAML. Нужны аудит репозиториев на предмет несанкционированных workflow, проверка GitHub Actions и истории коммитов, блокировка соединений с управляющим сервером злоумышленников, а затем отзыв и ротация секретов: SSH-ключей, API-ключей, токенов и облачных учетных данных. Иначе можно аккуратно почистить следы в одном месте, оставив злоумышленнику рабочий доступ в другом.
История с Megalodon GitHub неприятна не только масштабом, но и тем, насколько дешево теперь выглядит атака на доверие внутри разработки. Если несколько тысяч репозиториев можно отравить за одно утро, следующий рубеж конкуренции в безопасности будет не в том, кто быстрее собирает релиз, а в том, кто быстрее замечает подмену в собственной автоматизации и умеет пережить компрометацию без каскадного заражения всей цепочки поставки ПО.