Как ИИ-агенты превратили "тестовые задания" в инструмент заражения: кейс с Хабр Карьерой
Скам на рынке найма не новость: поддельные вакансии, липовые HR, "письма счастья" с фишинговыми вложениями. Раньше у таких атак была естественная граница - человеческие ресурсы. Нужно было вручную искать подходящих кандидатов, подстраивать легенду под стек, поддерживать переписку и не выгорать на сотнях диалогов. Поэтому масштаб оставался ограниченным.
С появлением ИИ-агентов эта граница исчезла. Теперь "рекрутер" может одновременно вести тысячи переписок, изучать профили разработчиков, подбирать ключевые слова под конкретный опыт и выдавать правдоподобные формулировки. По сути, произошло то же, что когда-то случилось со спамом: от ремесла - к конвейеру.
Ниже - разбор схемы, с которой я столкнулся на Хабр Карьере: как выглядел контакт, где именно был спрятан вредоносный код и какие настройки реально помогают не попасться.
Как выглядел контакт и что насторожило
Мне написал пользователь Хабр Карьеры Олег Назаров @artshub09 (после репорта аккаунт заблокировали). Предложение звучало идеально под мой профиль: fullstack, React, Node.js, Web3 - ровно тот набор, которым я занимаюсь.
Диалог старался выглядеть "человеческим": сообщения с маленькой буквы, намеренные опечатки, ответы только в рабочие часы, без мгновенной реакции. Но как только я попросил конкретику о продукте и задачах, в ответ прилетел узнаваемый "ИИ-слоп": идеально структурированный текст без фактов, одни общие фразы в стиле Generic Startup Language.
Это важный маркер: ИИ легко имитирует форму общения, но часто проваливается на содержании - вместо деталей даёт гладкие, но пустые абзацы.
"Тестовое" через приватный репозиторий: почему это работает
После согласия посмотреть тестовое меня добавили в приватный репозиторий на GitHub. И это не случайность.
Приватный репозиторий создаёт ощущение эксклюзивности: "доступ выдали лично мне - значит, компания настоящая". Плюс такой репозиторий не так просто автоматически проиндексировать системами анализа кода и антивирусными сканерами, которые быстро подсвечивают вредоносные паттерны в публичных проектах. В итоге атакующий снижает шанс, что репо заранее "засветится" и будет помечен как опасный.
Что было внутри репозитория
На первый взгляд - обычный fullstack-проект: React-фронтенд, Node.js/Express на бэке, PostgreSQL, Firebase Auth, Stripe. Структура нормальная, код не выглядит как свалка. Именно на это и расчёт: беглый просмотр успокаивает и подталкивает открыть проект в редакторе.
Вредоносный механизм спрятали в папке `.vscode/`.
Ключевой элемент: автозапуск через VSCode tasks.json
В файле `.vscode/tasks.json` была задача с параметром:
- `"runOn": "folderOpen"`
Это означает, что VSCode запускает задачу автоматически при открытии папки проекта. Без дополнительных подтверждений. Уведомление внизу экрана появляется, но многие разработчики годами не обращают на него внимания: автосборки и "удобные" workspace-настройки давно стали нормой.
Содержимое задачи было разделено по ОС:
- Linux / macOS: скачать скрипт с удалённого сервера и сразу выполнить через `bash/sh`.
- Windows: скачать зашифрованный архив, распаковать его через `argv.exe` (уже лежал в репо), затем запустить VBScript.
C2 и динамический payload
Фигурировал домен `ping-i2eo.onrender.com` - C2-сервер на Render.com (бесплатный хостинг). Endpoint `/nvs` отдавал shell-скрипт. Важный момент: payload находился не в репозитории, а на стороне атакующего и мог меняться в любой момент без обновления кода в GitHub. Также использовались user-agent значения `100/101/102` как идентификаторы платформы - чтобы сервер возвращал нужную версию.
Маскировка под "инструменты разработчика"
Внутри `.vscode` лежали подозрительные файлы:
- `.vscode/snippets/argv.exe` - Windows PE32 бинарник (~579 КБ), по поведению похожий на утилиту распаковки (условный аналог 7-zip) для разворачивания скачанного payload.
- `.vscode/lock` - ~753 КБ обфусцированного JavaScript в одну строку. Похоже на Node.js-пейлоад для Unix-этапа атаки или элемент закрепления в системе.
- `server/config/default.json` - "для правдоподобия" в репозитории открытым текстом лежали реальные credentials: Cloudflare API key, email-пароль, S3/R2 access keys. Это работает как психологическая подкладка: раз есть "настоящие" ключи и конфиги, значит проект живой.
Что происходит после запуска и чего добиваются атакующие
Точный payload в моём случае установить сложно, потому что он подгружался с сервера атакующего и мог измениться. Но цели у подобных кампаний обычно стандартные:
- кража SSH-ключей (`~/.ssh/`);
- выгрузка `.env` и токенов из других проектов на машине;
- кража сохранённых паролей и cookies из браузера;
- установка криптомайнера;
- backdoor / reverse shell для долгосрочного доступа.
Отдельно стоит выделить мотивацию охоты именно на Web3-разработчиков: на рабочем компьютере могут оказаться кошельки, seed-фразы, приватные ключи, доступы к деплой-пайплайнам и инфраструктуре.
Красные флаги, которые стоит фиксировать сразу
1. Слишком точное попадание "в ваш стек", но при этом ноль конкретики о продукте, клиенте, метриках, архитектуре.
2. Слишком "гладкое" описание проекта: много структуры и правильных слов, мало фактов.
3. "Тестовое" в виде репозитория, куда вас добавляют в приватном режиме без публичного описания компании и без нормального процесса.
4. Наличие `.vscode/` с задачами, скриптами, бинарниками - особенно если это не оговорено и не нужно для разработки.
5. Любые механизмы автозапуска: `runOn: folderOpen`, подозрительные `postinstall`/`preinstall` в `package.json`, нестандартные хуки.
Как защититься: практические меры
1) Запретите автозапуск workspace-задач в VSCode.
Критичная настройка:
- `task.allowAutomaticTasks: off`
При таком значении VSCode не будет молча выполнять задачи при открытии папки или хотя бы потребует явного подтверждения.
2) Открывайте незнакомые репозитории в "песочнице".
Идеальный вариант - отдельная виртуальная машина или контейнер, где нет ваших SSH-ключей, токенов, браузерных профилей и рабочих каталогов. Для "тестового" это почти всегда достаточно.
3) Перед запуском - быстрый аудит.
Минимальный чек-лист на 2 минуты:
- просмотреть `.vscode/tasks.json`, `.vscode/settings.json`;
- поиск по репозиторию `runOn`, `curl`, `wget`, `powershell`, `bash -c`, `cmd /c`, `certutil`, `Invoke-WebRequest`;
- проверить `package.json` на `postinstall`, `prepare`, `prepublish`;
- насторожиться при наличии неожиданных `.exe`, `.vbs`, сильно обфусцированных `.js` файлов.
4) Разделяйте рабочую среду и среду для тестовых.
Даже если вы уверены в себе, один случайный автозапуск - и под ударом окажутся ваши реальные проекты. Отдельный пользователь ОС, отдельный профиль браузера и отсутствие приватных ключей в этой среде значительно снижают ущерб.
5) Не доверяйте "приватности" как признаку легитимности.
Приватный репозиторий - это не гарантия, а инструмент социальной инженерии. Он одновременно повышает доверие и снижает заметность для автоматических проверок.
Итог
ИИ-агенты сделали рекрутинговый скам масштабируемым: персонализация под ваш стек, убедительная переписка и быстрое подсовывание "тестового" стали дешёвыми и массовыми. В описанной схеме ставка сделана на привычку разработчиков открывать проекты в VSCode "просто посмотреть", где автозапуск задач превращает просмотр в выполнение кода.
Если вы ищете работу и регулярно берёте тестовые, относитесь к любому незнакомому репозиторию как к потенциально враждебному: отключите автозадачи, проверяйте `.vscode`, открывайте в песочнице и не держите секреты в среде, где запускаете чужой код. Это тот случай, когда пара настроек и дисциплина реально решают проблему.
