21 января 2026 года разработчик получил в LinkedIn сообщение о фриланс-задаче с бюджетом до $800 000. Проект якобы от британской технологической платформы в сфере недвижимости требовал оценки кодовой базы. Вместо реального предложения работы за сообщением скрывалась целенаправленная атака на цепочку поставок (supply-chain attack), использующая троянизированное Node.js-приложение для кражи учетных данных и удаленного управления. Этот инцидент служит серьезным предупреждением для сообщества разработчиков, особенно в условиях сложного рынка труда.
Описание
Легенда и первые признаки угрозы
Сообщение поступило от пользователя с именем «Раджиндер Мадхар», который представился менеджером FINE PROPERTY (UK) LTD. Профиль имел значок проверки и более 500 контактов, что создавало видимость легитимности. Однако ретроспективный анализ выявил ключевые «красные флаги». Во-первых, профиль не содержал ни одного поста или активности при большом количестве связей. Во-вторых, после предоставления доступа к репозиторию на GitLab назначенный созвон с «техническим менеджером» так и не состоялся без объяснений. В-третьих, сам репозиторий, содержащий якобы готовое к продакшену приложение, был создан всего за два месяца до этого и имел лишь два коммита, что указывает на возможную очистку истории для сокрытия следов.
Механизм атаки: от "postinstall" до удаленного управления
Атака была построена на трех взаимосвязанных компонентах, искусно встроенных в легитимный код. Первым и главным триггером стал скрипт "postinstall" в файле "package.json". При выполнении стандартной команды "npm install" этот скрипт автоматически запускал сервер, активируя скрытую вредоносную функциональность. Вторым компонентом был обфусцированный загрузчик, размещенный в конце одного из файлов контроллера. Он использовал "Function.constructor" - мощный и опасный метод динамического выполнения кода. Загрузчик расшифровывал строки в формате Base64 из переменных окружения, получал URL и загружал исполняемую полезную нагрузку (payload) с внешнего сервера. Третьим элементом была конфигурация, где критически важные данные, такие как адрес сервера злоумышленников, были закодированы.
Цели вредоносной полезной нагрузки
Удаленная полезная нагрузка, размещенная на сервисе jsonkeeper[.]com, состояла из нескольких модулей. Первый модуль создавал бэкдор для командного управления (C2), устанавливая соединение через Socket.io с IP-адресом 144.172.108[.]57. Он мог собирать системную информацию и выполнять произвольные команды, а также прописывался в системе для обеспечения устойчивости (persistence). Второй модуль занимался поиском и эксфильтрацией конфиденциальных файлов с расширениями вроде ".env", ".pem" или ".pdf". Третий модуль был предназначен для мониторинга буфера обмена через PowerShell с целью перехвата скопированных паролей или ключей.
Действия после обнаружения и отчетность
После идентификации вредоносного кода разработчик немедленно принял меры. Были удалены локальные копии репозитория, очищены системные кэши и произведена смена всех потенциально скомпрометированных API-ключей. Важным шагом стало ответственное раскрытие информации (responsible disclosure). Инфраструктура атаки, включая репозиторий на GitLab и связанные IP-адреса, была передана в службы безопасности соответствующих платформ. В результате GitLab оперативно удалил вредоносный репозиторий, что подтверждает эффективность подобных отчетов.
Как защититься: практические рекомендации для разработчиков
Этот случай подчеркивает необходимость повышенной бдительности при работе с непроверенным кодом, особенно в рамках «технических собеседований». Перед запуском "npm install" необходимо тщательно проверять файл "package.json" на наличие подозрительных скриптов, таких как "postinstall" или "prepare". Следует искать в коде вызовы "eval()", "new Function()" и "Function.constructor", которые редко оправданы в веб-приложениях. Все строки в формате Base64 должны быть расшифрованы. Также стоит анализировать историю репозитория: небольшое количество коммитов в зрелом проекте является тревожным сигналом. При использовании ИИ-ассистентов для проверки кода важно формулировать запросы явно, требуя поиска именно вредоносных конструкций, а не общей оценки качества. Идеальным решением для оценки непроверенных проектов является их запуск в полностью изолированных средах, таких как Windows Sandbox, одноразовые виртуальные машины или контейнеры без доступа к файловой системе хоста.
Экономика атаки и итоги
Инвестиции злоумышленников в создание фиктивных профилей и правдоподобного кода оправданы высокой потенциальной выгодой. Компрометация учетных данных разработчика к облачным сервисам, платежным системам или базам данных может принести атакующим десятки тысяч долларов. Этот инцидент наглядно демонстрирует, что современные фишинговые кампании стали сложными и многоэтапными. Проверенные бейджи и большое число контактов больше не являются гарантией безопасности. Любое требование запустить непроверенный код до заключения договора или в неконтролируемом окружении должно встречать категорический отказ. Бдительность и ответственное информирование сообщества остаются ключевыми инструментами противодействия таким угрозам.
Индикаторы компрометации
IPv4
- 144.172.108.57
Domains
- 57.108.172.144.static.cloudzy.com
URLs
- http://144.172.108.57:4896/upload
- https://gitlab.com/nielsottore-oss/realestatevc
- https://jsonkeeper.com/b/ARL7M
MD5
- 098f6bcd4621d373cade4e832627b4f6
