Вредоносные репозитории Next.js крадут env через VS Code

Введение: почему это важно

Рабочие станции разработчиков и среды сборки — высокоценные цели, поскольку на них часто хранятся исходный код, материалы для подписи и секреты (API-токены, облачные учетные данные) в переменных окружения. Microsoft Defender Experts сообщает о кампании по распространению вредоносных репозиториев Next.js — часто оформленных как «домашние» тестовые задания для соискателей — которые спроектированы так, чтобы выглядеть как обычная часть developer workflow и надежно запускать выполнение кода.

Что нового / ключевые выводы

Microsoft наблюдала несколько связанных репозиториев с общими соглашениями по именованию и повторно используемой логикой загрузчика. Хотя первоначальная приманка различается, итоговое состояние одинаково: получение во время выполнения и in-memory исполнение JavaScript под контролем атакующего, после чего — переход к staged C2.

1) Выполнение в рабочем пространстве VS Code при открытии папки

Некоторые репозитории содержат .vscode/tasks.json, настроенный с runOn: "folderOpen". Если разработчик открывает (и доверяет) проект, задача запускается автоматически и стартует Node-скрипт, который загружает JavaScript loader (наблюдался размещенным на Vercel) и выполняет его.

2) Выполнение на этапе сборки при запуске приложения

Другие варианты срабатывают, когда разработчик запускает проект (например, npm run dev). В таких репозиториях вредоносная логика внедрена в, казалось бы, обычные ассеты (например, троянизированный jquery.min.js). Ассет декодирует base64 URL, получает loader (опять же, часто с Vercel) и выполняет его in memory.

3) Выполнение при старте бэкенда с эксфильтрацией env + динамическим RCE

Третий путь активируется во время инициализации сервера/импорта модулей. Репозитории могут содержать значение в .env, например AUTH_API=<base64>. При запуске backend-код декодирует endpoint, отправляет process.env атакующему, затем выполняет возвращенный JavaScript с использованием динамической компиляции (например, new Function("require", response.data)(require)). Это может раскрыть чувствительную конфигурацию и позволяет оператору доставлять последующие payload по запросу.

Регистрация Stage 1 → многоэтапный command-and-control

По всем путям выполнение сходится к начальному этапу «registrar», который профилирует хост и опрашивает endpoint регистрации, получая instanceId для корреляции дальнейшей активности. Телеметрия также отметила устойчивые обратные вызовы к инфраструктуре под контролем атакующего (включая HTTP-трафик на порту 300) после первичного этапа.

Влияние на IT-администраторов и команды безопасности

• Повышенный риск на endpoints разработчиков: Открытия репозитория может быть достаточно для выполнения кода, если задачам рабочего пространства доверяют.
• Риск утечки учетных данных: Путь через запуск бэкенда может эксфильтровать переменные окружения (облачные ключи, учетные данные БД, CI-токены).
• Более сложное обнаружение: In-memory выполнение и staged loaders могут уменьшать количество явных артефактов на диске.

Рекомендуемые действия / следующие шаги

• Рекомендации для разработчиков: Считайте take-home задания и незнакомые репозитории недоверенными; не нажимайте “Trust” в VS Code до проведения проверки.
• Проверка репозитория: Отмечайте/проверяйте .vscode/tasks.json (особенно runOn: "folderOpen"), неожиданные Node-скрипты в .vscode/ и минифицированные библиотеки, которые не совпадают с known-good hashes.
• Гигиена секретов: Снижайте зависимость от долгоживущих секретов в .env; где возможно, используйте managed identities/short-lived tokens и выполняйте ротацию любых скомпрометированных учетных данных.
• Детектирование и меры контроля: Мониторьте процессы Node.js на предмет нетипичных исходящих подключений (например, dev tools, обращающиеся к staging-доменам с последующим переходом к неизвестному C2), и рассмотрите ограничения egress для устройств разработчиков и build agents.
• Hunting: Ищите на платформах размещения кода и во внутренних зеркалах «семейства» по именованию и структурные паттерны повторного использования, описанные Microsoft (почти дубликатные репозитории, похожие loaders, повторяющиеся staging endpoints).