Кампания PolinRider, связываемая с Северной Кореей, продолжает наращивать масштаб: число подтвержденных зараженных репозиториев GitHub выросло до 4 367, а вредоносный код всё чаще оказывается в пакетах, публикуемых в реестре npm. Жертвами становятся легитимные разработчики, чьи аккаунты и компьютеры незаметно превращаются в инструмент для распространения вредоносных программ в цепочке поставок программного обеспечения. При этом сами авторы проектов часто не подозревают о заражении и продолжают выпускать обновления, неся в них вредоносный код.
Описание
Техника атаки построена на скрытом внедрении исполняемого кода в файлы, которые выглядят безобидными. Вредоносные элементы маскируются под настройки редактора, поддельные шрифты и обычные конфигурационные файлы. Некоторые из этих файлов настроены так, что запускаются автоматически при открытии папки проекта в среде разработки. Другие активируются в момент запуска сборки или тестов, то есть не требуют действий со стороны человека. Из-за этого заражение быстро распространяется внутри экосистемы разработки и с трудом поддается полному удалению.
Показательный случай - аккаунт разработчика DiogoAngelim, публикующего пакеты fetch-page-assets и html-to-gutenberg. Его учетная запись и локальная среда сборки были скомпрометированы в марте 2026 года. В июне компания JFrog сообщила о двух зараженных версиях этих пакетов, после чего npm удалил их из реестра. Однако последующие выпуски продолжили содержать вредоносный код, причем в июле заражение распространилось на все семь неархивных репозиториев владельца. Попытки разработчика очистить проекты затронули лишь видимые артефакты, но не задели скрытый механизм, который позволял злоумышленникам повторно внедрять полезную нагрузку.
В результате анализа исследователи OpenSourceMalware выяснили, что все семь репозиториев были заражены в течение 56 секунд во время скоординированной атаки в июле, а в августе аналогичная операция заняла всего 30 секунд. Метки времени, фиксируемые серверами GitHub, указывают, что изменения вносились от имени владельца. Это означает либо прямой доступ злоумышленников к учетным данным, либо присутствие вредоносного агента на локальной машине разработчика. При этом в одном из случаев даты коммитов были искусственно изменены, чтобы скрыть момент реального вмешательства. Несмотря на удаление одной вредоносной версии из реестра, последняя опубликованная на момент исследования версия пакета оставалась зараженной и доступной для установки.
Проблема усугубляется тем, что модель реагирования npm и GitHub рассчитана на одиночные вредоносные пакеты, а не на компрометацию самих сопровождающих. Уведомление об уязвимости привязано к точной версии, поэтому новая версия того же автора не попадает под действие ранее выданного предупреждения. Пакет удаляется из реестра, но исходный код в репозитории остается зараженным, и следующая публикация снова несет вредоносный код. Автор, в свою очередь, не получает объяснений о причинах удаления своего пакета, поэтому его попытки исправить ситуацию ограничиваются удалением очевидных подозрительных файлов, в то время как настоящий источник заражения продолжает действовать.
Масштаб угрозы подтверждается новыми инцидентами. На прошлой неделе в npm была обнаружена вредоносная версия пакета @lambda-platform/lambda-vue, а накануне публикации анализа от имени пользователя denislistiadi появились сразу три зараженных пакета. При этом соответствующие репозитории на GitHub по-прежнему содержат вредоносный код, поэтому следующая публикация может снова привести к заражению пользователей. Специалисты отмечают, что кампания ориентирована в первую очередь на индивидуальных разработчиков, а не на организации, что делает обнаружение особенно сложным: ни один отдельный проект не выглядит подозрительным, пока не будет сопоставлен с общими индикаторами атаки.
Разработчикам, использующим затронутые пакеты, рекомендуется зафиксировать версии, выпущенные до первого подтвержденного заражения, или вовсе отказаться от их использования. Также важно регулярно проверять конфигурационные файлы проектов на предмет подозрительных скрытых задач, которые выполняются при открытии папки в редакторе, и обращать внимание на необычные сетевые обращения со стороны процессов, запускающих код на платформе Node.js. Если подобные обращения обнаружены, компьютер необходимо рассматривать как скомпрометированный и проводить полную проверку среды разработки.
Публикация в очередной раз демонстрирует системную слабость реестра npm: текущий процесс обработки инцидентов не рассчитан на ситуацию, когда тысячи легитимных сопровождающих скомпрометированы, а злоумышленники могут выдавать новые версии вредоносных пакетов быстрее, чем их успевают выявлять. Пока реакция ограничивается точечными уведомлениями о конкретных версиях, а не анализом паттернов и проверкой учетных записей, экосистема останется уязвимой для атак на цепочку поставок. Ситуация с одним разработчиком, чей аккаунт был заражен уже более пяти месяцев назад, показывает, что даже после обнаружения и удаления одной версии кампания продолжает действовать, а реестр не способен предотвратить повторное распространение вредоносного кода от имени скомпрометированного автора.
Индикаторы компрометации
SHA256
- 9fbb31129c04e8eb1a50519fc864c74d1b20d57c07d4099348f8fbc9a1a1eae6
- f5c6be4753d6613c97f1b10c4d93a5d97a8f4fb21eb13da0ed04b23a8a61c2f6
Ethereum wallet
- 0xa322e5f3d311d3080e6f0121063e9adc2490ef1a
Packag
- npm/fetch-page-assets@1.2.10
- npm/fetch-page-assets@1.2.11
- npm/fetch-page-assets@1.2.12
- npm/fetch-page-assets@1.2.13
- npm/fetch-page-assets@1.2.14
- npm/fetch-page-assets@1.2.9
