Червь Shai-Hulud ищет учётные данные уже в 469 местах — и это симптом смены тактики

В начале августа исследователи GitGuardian зафиксировали новую версию инфостилера-червя Shai-Hulud, которая ищет учётные данные уже в 469 местах — в окружениях разработчиков, инструментах CI/CD, облачных конфигурациях и даже в настройках AI-инструментов. Прежние варианты червя проверяли лишь 189 путей. Рост радиуса поиска говорит о смене логики атаки.

Не взлом доверия, а его использование

Цепочки поставок ПО всегда держались на доверии: разработчики доверяют реестрам пакетов, организации — мейнтейнерам, конвейеры CI/CD — выданным им токенам. Авторы Shai-Hulud поняли, что ломать это доверие незачем. Достаточно найти, где уже лежат учётные данные и постоянные привилегии.

Один украденный токен открывает доступ к исходному коду, в котором нередко зашиты облачные ключи; те дают доступ к инфраструктуре; токен GitHub позволяет писать в другие репозитории; а ключ публикации пакета — распространять вредонос по каналу, которому разработчики доверяют автоматически. Так секреты становятся связующей тканью между одной скомпрометированной средой и следующей, превращая кражу в самовоспроизводящуюся атаку.

Почему поисковый радиус расширяется

Современное окружение разработчика содержит куда больше аутентификационного материала, чем сам репозиторий: файлы .env, история командной оболочки, конфигурации пакетных менеджеров, кэши CLI, настройки IDE и — всё чаще — конфиги AI-инструментов. Атакующему не нужно заранее знать, какой ключ важнее: он собирает всё подряд, а разбирается потом. Защитникам, наоборот, стоит двигаться от обратного — заранее определить самые ценные секреты и закрыть их до того, как ими воспользуются.

Что делать в первую очередь

GitGuardian предлагает расставить приоритеты. Первое — убрать из открытого вида ключи публикации пакетов: именно они превращают кражу секрета в распространение вредоносного кода. Долгоживущие токены публикации следует заменять короткоживущими механизмами вроде доверенной публикации через OIDC или федеративных сервисов вроде AWS STS; недавние обновления Docker и GitHub Actions двигают экосистему в эту сторону.

Второе — устранить доступные учётные данные к продакшену: облачным аккаунтам, базам с данными клиентов, инфраструктуре подписи, кластерам Kubernetes, средствам развёртывания. Здесь ключевой вопрос — «что будет, если атакующий воспользуется этим доступом», а фильтром служит проверка, действителен ли ключ вообще.

Третье — ранжировать оставшиеся секреты по риску с учётом валидности, среды, привилегий и владельца. Масштаб проблемы огромен: по данным исследования State of Secrets Sprawl, только за 2025 год в публичные коммиты на GitHub попало 28,65 млн новых зашитых секретов — на 34% больше, чем годом ранее.

Гонку не выиграть перечислением

Следующий вариант Shai-Hulud почти наверняка заглянет туда, где ещё не искал, и превысит цифру 469. Побеждать в этой гонке, запоминая все возможные тайники, бессмысленно. Выигрывает тот, кто убирает постоянные привилегии и открытые секреты повсюду, где они есть, превращая обнаружение, устранение и профилактику в постоянный цикл. Цель проста: чтобы каждый новый червь находил всё меньше пригодных ключей.

Источник: The Hacker News