Fake Go DNS scanner spread malware through over 200 GitHub repos — 'Operation Muck and Load' has published 700 malicious modules since January

Разработчики давно привыкли тянуть зависимости из репозиториев почти на автомате. Именно этим и пользуются атакующие: вредоносный код уже не обязательно присылать отдельным файлом, его можно спрятать в “полезной” библиотеке.

Что произошло

Атака сработала не потому, что Go небезопасен, а потому, что разработчики привыкли доверять знакомому описанию пакета и большому числу версий. Злоумышленники превратили сам процесс установки зависимости в доставку первого этапа вредоноса.

• Компания Socket описала кампанию Operation Muck and Load: модуль Go выдавал себя за DNS- и subdomain-сканер, но работал как первый этап загрузчика вредоносного ПО.
• Исследователи связали кампанию минимум с 222 GitHub-репозиториями и 190 аккаунтами.
• С января было опубликовано более 1200 версий, из них свыше 700 Socket считает вредоносными.
• Go security team заблокировала модуль в Go module proxy после сообщения исследователей.

Почему это важно

Здесь важно не то, что атакующие опять нашли новый “хитрый вирус”. Важнее другое: они играют в доверие к экосистеме. Репозиторий выглядит как обычный open-source, версия обновляется, история коммитов есть — а внутри цепочка для доставки нагрузки.

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

Операционные детали атаки намеренно не повторяем: такие публикации должны помогать защищаться, а не давать инструкцию по запуску похожей схемы.

Сотни версий создавали иллюзию живого проекта

Один подозрительный релиз заметить легче, чем пакет с длинной историей обновлений, множеством репозиториев и аккаунтов. Кампания именно этим и опасна: она имитировала нормальную активность open source, а не просто бросала одиночный файл в сеть.

Блокировка модуля командой Go закрывает известный канал, но не исправляет привычку устанавливать зависимости по первой инструкции из README. Следующий пакет может получить другое имя и появиться уже в другой экосистеме.

Что стоит изменить в рабочем процессе

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

Домашний пользователь тоже может попасть под удар через готовый “полезный” бинарник с GitHub. Количество звёзд и красивое описание не заменяют репутацию автора, подпись релиза и проверку файла несколькими средствами.

Итог

Итог: open-source не стал опасным сам по себе. Опасна привычка доверять имени пакета без проверки. В 2026 году supply chain — это уже не теория, а один из главных фронтов безопасности.

---