Разработчику в LinkedIn предложили работу и прислали архив с «договором и проектом». Внутри оказалась ловушка: настройки Git, из-за которых вредоносный скрипт мог запуститься от обычного git status. Разбираем, как это устроено, почему такие «тестовые задания» стали массовыми и как проверять код от незнакомых рекрутеров.
Коротко
- В архиве лежал не просто код, а целая служебная папка .git с заранее подготовленными настройками. Через них Git сам запускал скрипт, который скачивает и выполняет код с удалённого сервера.
- Ничего устанавливать или собирать не требовалось. По словам автора разбора, хватало переключения ветки по инструкции из README или git status, который редактор кода может выполнить сам.
- Такие истории — часть известной волны фейковых собеседований. С 2023 года её описывали Palo Alto Networks, Microsoft, Trend Micro и Elastic, а часть исследователей связывает её с Северной Кореей.
- Главное правило: код от незнакомого рекрутера открывать только в изолированной среде и никогда не открывать в обычной IDE репозиторий, присланный архивом вместе с папкой .git.
Что случилось
13 ноября на Хабре вышел разбор пользователя igumnov, который возглавил топ дня площадки. Автору в LinkedIn написал рекрутер компании Cryptic Heaven. По её словам, компания делает финансовую систему для владельцев криптовалютных кредитных карт.
После короткой переписки «рекрутер» прислал ссылку на архив Contract-2026.zip — якобы с договором, описанием вакансии Smart Contract Developer и кодом проекта. Договор оказался шаблоном с пустыми полями: без юрлица, оплаты и юрисдикции.
Самое интересное было не в документах. README предлагал по очереди переключаться между тремя ветками — doc, job и codebase. А в архиве, кроме файлов, лежала полная папка .git с историей и локальными настройками репозитория.
Как устроена ловушка
Чтобы понять схему, нужны два механизма Git. Оба легальные и давно описаны в документации.
Хуки
Хук — это программа, которую Git сам запускает в определённый момент своей работы. По документации Git, хуки лежат в папке .git/hooks, но настройка core.hooksPath позволяет указать любую другую папку. Хук post-checkout срабатывает после git checkout или git switch, то есть после переключения ветки.
В присланном архиве путь к хукам был перенесён вглубь служебной папки .git/objects, куда люди обычно не заглядывают. Единственный хук после переключения ветки вызывал git status.
Фильтры
Фильтр — это внешняя команда, через которую Git пропускает содержимое файлов. В описании gitattributes сказано, что у фильтра есть команда clean, которая обрабатывает файлы из рабочей папки, когда их добавляют в репозиторий. Какие файлы проходят через фильтр, задаётся в файле .git/info/attributes, и у него наивысший приоритет.
В архиве фильтр был назначен всем файлам, а его командой был скрипт из той же папки .git. Скрипт запускал в фоне загрузку кода с удалённого сервера — отдельно для Linux, macOS и Windows — и возвращал данные без изменений. Для Git всё выглядело так, будто фильтр честно отработал.
Автор отдельно проверил это на безопасном тестовом репозитории. Git status действительно вызвал фильтр, а переключение ветки — ещё и хук.
Схема одной строкой: переключение ветки запускает хук, хук вызывает git status, git status прогоняет файлы через фильтр, фильтр скачивает и запускает чужой код.
Почему прислали ZIP, а не ссылку на GitHub
Это ключевая деталь. Когда разработчик делает git clone, он получает историю и файлы. Но, как отмечает автор, локальные настройки исходного репозитория при этом не копируются. А в книге Pro Git прямо сказано, что клиентские хуки при клонировании не переносятся.
Архив обходит это ограничение. Вместе с ним приходит готовая папка .git — со всеми настройками, хуками и скриптом фильтра. После распаковки Git начинает их использовать при первом подходящем обращении.
На Windows схема тоже работает. Автор обращает внимание, что Git for Windows поставляется со своей Unix-оболочкой и может запускать shell-скрипты, даже если пользователь работает в PowerShell. Для Windows в скрипте был предусмотрен отдельный вариант загрузки.
Когда ловушка могла сработать
По словам автора, сама распаковка архива и просмотр папки в проводнике Git не запускают. Опасны три сценария:
- Открыть README в VS Code. Редактор умеет находить репозиторий в родительской папке и запрашивать его статус. Сработает ли ловушка, зависит от настроек и того, доверяет ли редактор этой папке.
- Зайти в папку в терминале. Некоторые темы командной строки показывают состояние репозитория и для этого вызывают git status. Тогда опасным становится обычный cd.
- Выполнить инструкцию из README. Переключение ветки запускает и фильтр, и хук.
Важная оговорка автора: наличие загрузчика ещё не доказывает заражение. Что именно делает скачиваемый код, по содержимому архива установить нельзя.
Это не единичный случай
Схема с фейковым собеседованием известна давно. В ноябре 2023 года Unit 42 из Palo Alto Networks назвала её Contagious Interview. Тогда злоумышленники выдавали себя за работодателей и во время онлайн-собеседования уговаривали разработчиков установить npm-пакет с GitHub. Исследователи со средней уверенностью связали кампанию с северокорейскими государственными хакерами.
В марте 2026 года Microsoft описала новую волну и уточнила, что кампания активна как минимум с декабря 2022 года. Атакующие представляются рекрутерами криптовалютных трейдинговых компаний или поставщиков ИИ-решений. Вредоносный код запускается при установке зависимостей или через задачи VS Code, если жертва согласится доверять автору репозитория.
По данным Microsoft, такие программы крадут API-токены, облачные ключи, ключи подписи, криптокошельки, файлы менеджеров паролей и исходный код. Компания отмечает, что часть задач вела на короткие ссылки, перенаправлявшие на vercel.app. Загрузчик из истории на Хабре тоже лежал на поддомене vercel.app. Но само по себе это совпадение не доказывает связь, а автор разбора никого не обвиняет.
Дальше схема стала распространяться сама. В апреле Dark Reading со ссылкой на Trend Micro писал, что заражённые разработчики коммитят код в свои репозитории и так передают ловушку дальше. В марте Trend Micro насчитала более 750 заражённых репозиториев.
В июле Elastic рассказала, что фейковый рекрутер разместил вакансию прямо в её сообществе в Slack и раздавал «тестовое задание». На момент публикации ни один антивирус на VirusTotal не распознавал семь найденных заражённых проектов.
Отличие случая с Хабра — в способе запуска. В описанных ранее волнах код прятали в зависимостях, в коде проекта или в задачах редактора. Здесь его спрятали в настройках самого Git, которые редко кто открывает.
Ограничения и оговорки
- Один случай, один автор. Разбор описывает конкретный архив. Атрибуции нет, полезная нагрузка с сервера не изучена.
- Поведение зависит от окружения. Сработает ли ловушка при открытии в VS Code или в терминале, зависит от версии инструментов и настроек. Автор сам называет эти сценарии возможными, а не гарантированными.
- Документация Git этого прямо не описывает. То, что git status может вызывать clean-фильтр, автор проверил экспериментально. В описании gitattributes такого предупреждения нет.
Открытый вопрос. Стоит ли Git и редакторам кода по умолчанию игнорировать хуки и фильтры в репозиториях, которые пришли не через clone, — или это сломает слишком много честных сценариев?
Как проверять «тестовые задания»: по шагам
Условный пример наш, шаги — из рекомендаций Microsoft, документации редакторов и разбора на Хабре. Допустим, вам пишет рекрутер криптостартапа и присылает архив с «проектом для оценки».
1. Оцените сам запрос
Microsoft называет тревожными признаками короткие ссылки, только что созданные аккаунты и репозитории, слишком сложную настройку и просьбы доверять неизвестному автору. Добавим от себя ещё два: договор с пустыми полями и код, который присылают архивом вместо ссылки на публичный репозиторий.
2. Не открывайте архив в IDE и не заходите в папку в терминале
Сначала посмотрите содержимое через просмотрщик архивов. Если внутри есть папка .git, откройте как текст .git/config и .git/info/attributes. Насторожить должны строки hooksPath и filter, а также исполняемые файлы внутри .git.
Если нужен только код, проще удалить папку .git целиком — без неё нет и чужих настроек. Если нужна история — попросите ссылку на репозиторий и клонируйте его обычным git clone.
3. Запускайте всё в одноразовой среде
Microsoft советует выполнять тестовые задания в изолированной временной виртуальной машине, а не на рабочем компьютере. В такой среде не должно быть ваших ключей, токенов, кошельков и сессий браузера.
4. Включите защиту в редакторе
В VS Code незнакомая папка по умолчанию открывается в режиме ограниченного доступа. Этот режим отключает или ограничивает ИИ-агентов, терминал, задачи, отладку, настройки рабочей области и расширения. Встроенную работу с Git документация в этом списке отдельно не называет, поэтому шаг 2 не заменяет.
В IntelliJ IDEA и других IDE JetBrains есть безопасный режим, в котором поддержка систем контроля версий полностью отключена. Если сомневаетесь, не нажимайте «Доверять».
5. Если уже открыли
Microsoft советует изолировать устройство, сменить все потенциально раскрытые учётные данные и проверить недавний доступ к репозиториям и CI/CD. Автор разбора добавляет: проверить систему и решить, не пора ли сменить секреты и токены, — причём делать это с другого, доверенного устройства.
Весь цикл одной строкой: оценить запрос → посмотреть архив без Git → удалить .git или клонировать заново → запускать в одноразовой среде → при подозрении сменить ключи.
Что это значит для разработчиков и бизнеса
- Git — это тоже исполняемая среда. Чужой репозиторий с локальными настройками может запускать программы так же, как npm install или задачи редактора.
- Поиск работы — уязвимый момент. Кандидат хочет произвести впечатление и торопится, на это и рассчитаны такие схемы. Компаниям стоит напоминать сотрудникам, что «тестовые» никогда не выполняют на рабочем ноутбуке.
- Ключи не должны лежать на машине «навсегда». Microsoft советует короткоживущие учётные данные и хранилища секретов вместо долгоживущих токенов в .env-файлах. Тогда даже успешная атака принесёт меньше вреда.
- Нанимающим компаниям стоит давать задания через публичные репозитории. Чем привычнее честный процесс, тем заметнее отклонения от него.
Вывод
Атака из разбора на Хабре не использует ни уязвимостей, ни экзотических программ. Она собрана из штатных возможностей Git, а её главный ход — передать чужие настройки внутри обычного архива.
Практическое правило простое: репозиторий с папкой .git от незнакомого человека — это программа, а не документ. Смотреть такой архив стоит только без Git и только в среде, которую не жалко потерять.
Комментарии