Source: TechCrunch Security — https://techcrunch.com/2026/05/27/crowdstrike-and-google-take-down-botnet-used-by-hackers-to-target-software-developers-in-supply-chain-attacks/
Главный урок не в takedown, а в выборе цели#
CrowdStrike совместно с Google и Shadowserver заявила, что сорвала работу Glassworm — ботнета, который использовали для доставки malware и кражи паролей у разработчиков open-source ПО. По сообщениям, операция отключила четыре канала command-and-control и не дала операторам дальше распространять malware через зараженные машины.
Это заметная победа. Но важнее другое: куда была направлена кампания.
Glassworm атаковал не только готовые продукты или открытые корпоративные серверы. По данным CrowdStrike, группа целилась в разработчиков и open-source цепочку поставки вокруг них. Это меняет модель риска. Скомпрометированный аккаунт или рабочая станция разработчика может стать входом в репозитории кода, обновления пакетов, расширения и организации ниже по цепочке, которые напрямую с атакующим никогда не взаимодействовали.
CrowdStrike сформулировала ставку прямо: атакующие больше не ограничиваются продуктами, они целятся в людей, которые их создают. Это не лозунг. Это объясняет, почему identity разработчиков, локальные машины, секреты CI/CD, права на публикацию пакетов и аккаунты в маркетплейсах теперь находятся внутри реального периметра.
Что, по сообщениям, использовал Glassworm#
TechCrunch пишет, что операторы Glassworm применяли несколько способов доставки вредоносного кода и кражи учетных данных у разработчиков.
Среди описанных методов — вредоносные расширения в developer marketplace, malvertising через спонсируемые результаты поиска и повторное использование учетных данных, украденных при прошлых компрометациях. Эти учетные данные позволяли атакующим захватывать аккаунты разработчиков и внедрять malware в код.
CrowdStrike заявила, что кампания «отравила» более 300 репозиториев GitHub. В исходном материале нет полного списка жертв, точного числа заражений или полной карты влияния на downstream-проекты. Это важно. Более 300 репозиториев — серьезный масштаб, но это не значит автоматически, что каждая зависящая от них организация была скомпрометирована. «Отравление» репозитория может означать разные вещи: от попытки размещения кода до его реального выполнения жертвами. Именно эти детали определяют радиус поражения.
Тем не менее паттерн достаточно ясен, чтобы действовать. Атакующие обходили защиту через доверие. Им не нужно было взламывать каждую компанию напрямую, если можно было скомпрометировать аккаунты разработчиков, расширения или пути доставки кода, которым эти компании уже доверяли.
Самая важная техническая деталь — C2#
CrowdStrike сообщила, что отключила четыре command-and-control канала, которые использовали операторы Glassworm. Согласно отчету, эти каналы опирались на инфраструктуру блокчейна Solana, peer-to-peer сеть BitTorrent, Google Calendar и virtual private servers.
На эту смесь стоит обратить внимание.
Обычный VPS для C2 — привычная история. А вот использование публичной или полупубличной инфраструктуры, такой как данные блокчейна, peer-to-peer сети или календарные сервисы, сложнее разбирать с точки зрения защиты. Такие каналы размывают границу между вредоносным трафиком и обычным использованием платформ. Они также дают атакующим запасные маршруты, если часть инфраструктуры блокируют.
По сообщениям, takedown отрезал операторам доступ к зараженным компьютерам и остановил дальнейшую доставку malware. Это серьезное нарушение работы, но его не стоит читать как доказательство, что все зараженные системы очищены или все украденные учетные данные стали недействительными. Нарушение C2 может сломать активное управление. Оно не откатывает изменения в репозиториях, не ротирует утекшие токены, не удаляет persistence и не восстанавливает доверие к скомпрометированным аккаунтам автоматически.
TechCrunch также отмечает, что неясно, какие юридические или технические полномочия CrowdStrike и другие участники использовали для takedown. Это не мелкая сноска. Срывы ботнетов часто находятся на стыке enforcement со стороны платформ, sinkholing, abuse response, судебных приказов, действий инфраструктурных провайдеров и координации частного сектора. Без деталей читателям не стоит предполагать ни конкретный юридический механизм, ни полное техническое уничтожение угрозы.
Почему разработчики стали ценной инфраструктурой#
Open-source разработчиков часто воспринимают как отдельных контрибьюторов. В современной цепочке поставки ПО многие из них фактически работают как сопровождающие критической инфраструктуры.
На одной рабочей станции разработчика могут храниться токены package registry, сессии GitHub, SSH-ключи, cloud credentials, материалы для signing, browser cookies и доступ к release workflows. Один аккаунт может иметь права в нескольких репозиториях. Одно вредоносное обновление может уйти далеко за пределы организации исходного maintainer.
Поэтому кампании вроде Glassworm эффективны. Они используют доверие в точке, где код создают, ревьюят, упаковывают и отправляют пользователям.
Описанные тактики также показывают: «атака на цепочку поставки» больше не означает один конкретный прием. Она может начаться с вредоносного расширения. Может начаться с поисковой рекламы, которая ведет на фальшивую загрузку. Может начаться с пароля, украденного в прошлой утечке и повторно использованного против аккаунта разработчика. Часть про цепочку поставки начинается позже — когда этот первичный доступ превращается в доступ к коду или release path.
То же общее давление видно и в других недавних инцидентах, нацеленных на разработчиков. TechCrunch приводит отдельную кампанию «Mini Shai-Hulud», где open-source проекты были скомпрометированы и распространяли вредоносные обновления, а также мартовский инцидент с захватом Axios — широко используемого open-source инструмента для разработки ПО, предположительно совершенный подозреваемым северокорейским хакером. Детали разные. Направление одно: доверие к разработчикам используют как канал распространения.
Что командам проверить сейчас#
Правильная реакция — не панически сканировать каждую зависимость по отдельности. Начните с мест, где компрометация разработчика превращается в компрометацию релиза.
Командам стоит проверить недавние изменения в репозиториях: неожиданные commits, новых maintainers, измененные build scripts, изменения зависимостей, настройки публикации пакетов и workflow files. GitHub Actions и похожие CI-системы требуют особого внимания, потому что они часто связывают изменения кода с секретами, artifacts, package registries и cloud-средами.
Учетные данные разработчиков стоит считать потенциально раскрытыми, если они использовались на машинах, где ставили недоверенные расширения, переходили по спонсируемым ссылкам для загрузки софта или повторно использовали пароли в разных сервисах. Сначала ротируйте самые ценные токены: package registry credentials, GitHub tokens, cloud keys, signing keys, deploy keys и CI/CD secrets. Удаляйте устаревшие токены, а не только ротируйте очевидные.
Организациям также стоит провести аудит marketplace extensions, которыми пользуются разработчики. Расширения работают близко к рабочему процессу. Некоторые могут читать файлы, взаимодействовать с кодом или видеть учетные данные и сессии. Поэтому они привлекательны для атакующих. Относитесь к расширениям разработчиков скорее как к привилегированному ПО, а не как к косметическим инструментам.
Для поисковой рекламы тоже нужен отдельный контроль. Если разработчики устанавливают инструменты, вводя название продукта в поиск и кликая по первому спонсируемому результату, у атакующих появляется дешевый вход. Внутренняя документация должна напрямую ссылаться на одобренные места загрузки. Для security-sensitive инструментов лучше выбирать страницы проверенных издателей, источники package manager с понятным происхождением или подписанные релизы, если они доступны.
Чего не стоит утверждать слишком уверенно#
Публичные сообщения подтверждают понятный вывод: CrowdStrike, Google и Shadowserver нарушили работу инфраструктуры, которую использовал Glassworm — ботнет, нацеленный на open-source разработчиков и компрометацию цепочки поставки.
Но они не доказывают, что угроза исчезла.
Отчет не показывает, что каждый зараженный хост был очищен, все украденные учетные данные ротированы, а каждый «отравленный» репозиторий восстановлен. Он также не проясняет юридический или процедурный механизм takedown. Эти пробелы не делают материал слабым; они задают границы того, какие выводы из него можно делать.
Для защитников практический вывод уже и сильнее: среды разработчиков — часть production attack surface. Если атакующий может украсть учетные данные maintainer, захватить release path или внедрить код через доверенный аккаунт, граница между endpoint security и supply-chain security исчезает.