Когато поканата за „иновативен проект“ всъщност е троянски кон

Всичко започва по начин, който за много от нас е напълно рутинен.

Контакт през LinkedIn.

Профилът изглежда „истински“ — няколко години история, технологичен бекграунд, снимка, умерена активност. Разговорът е премерен, професионален. Представят се като хора, които работят по иновативен проект и търсят team / tech / product lead, с когото да обсъдят PoC и архитектура.

Нищо агресивно. Нищо очевидно подозрително.

След кратък обмен идва следващата стъпка: „Можем да ти дадем достъп до repository с PoC, за да го разгледаш локално.“

И точно тук започва атаката.

PoC, който се изпълнява сам

Repository-то изглежда напълно легитимно.

Node.js backend, Express, структуриран код, .env, middleware, routes. Има README, инструкции как да се стартира проекта:

npm install
npm run dev

Но още при стартиране се случва нещо, което не трябва да се случва в нормално приложение:

• код се изпълнява още при load-ване на модул,
• без HTTP заявка,
• без user input,
• без логика, свързана с функционалността на приложението.

Това не е bug. Това е умишлено конструирана supply-chain атака.

Dropper, маскиран като middleware

Ключовият елемент е функция с невинно име – verifyToken. Подписът ѝ напомня Express middleware (req, res), но параметрите не се използват.

По-лошото: функцията се извиква директно, на top-level, още при import на модула.

Резултатът е следният:

1. При npm run dev Node.js зарежда routing файла
2. Там, без да чака заявка, се изпълнява verifyToken()
3. Функцията прави HTTP request към външен сървър
4. Получава JSON с поле token
5. Това поле се изпълнява чрез:

new (Function.constructor)('require', payload)

Това е еквивалент на eval, но:

• по-трудно се хваща със статични проверки
• позволява да се подаде require като аргумент

С други думи: пълен Remote Code Execution в контекста на разработчика.

C2 инфраструктура, скрита в .env и base64

Payload-ът не е в самото repository. Той се доставя динамично от C2 сървър, конфигуриран чрез:

• environment променливи
• разделени path компоненти
• base64-кодирани URL-и

Основният endpoint е хостнат на Vercel, вторичен – на отделен домейн с нестандартен порт. Това не е случайно. Това е класически подход за евтина, disposable инфраструктура, която може да се сменя често.

Payload-ът: обфусkиран infostealer, не demo код

Истинската изненада идва, когато разгледаме реалния payload, който C2 сървърът връща. Това не е „hello world“. Това е ~90KB силно обфусциран JavaScript.

Няколко ключови характеристики:

• зарежда child_process, fs, os
• регистрира handlers за uncaughtException и unhandledRejection, за да не се срине
• съдържа собствен string decoding engine с множество азбуки
• проверява execution environment
• подготвен е за асинхронни операции и допълнителни payload-и

Това не е експериментален код. Това е production-grade infostealer, насочен към разработчици.

Какво може да бъде откраднато

При подобен достъп атакуващият потенциално получава:

• SSH ключове (~/.ssh)
• .env файлове с API ключове
• cloud credentials
• Git tokens
• browser data (cookies, saved logins)
• крипто портфейли
• цялата среда, от която работиш

И всичко това – само защото си стартирал PoC, който някой ти е дал „да го разгледаш“.

Защо това напомня на Sha1-Hulud

Този тип атака ужасяващо много прилича на концепцията зад Sha1-Hulud – не защото е същото технически, а защото:

• не се вижда веднага
• движи се през JS екосистемата
• използва доверието и навиците на жертвата

Тук няма zero-day exploit. Няма brute force. Има социално инженерство + supply-chain + доверие в tooling-а.

Защо това е особено опасно

Тази атака не цели „крайни потребители“. Тя цели разработчици, архитекти, tech leads. Хора с:

• достъп
• знания
• ключове
• production системи

И го прави по начин, който заобикаля почти всички класически защитни механизми, защото:

• кодът изглежда легитимен
• payload-ът идва динамично
• няма очевидни индикатори при първичен преглед

Изводът

Ако някой ви пише с „интересен проект“ и ви праща repository:

1. не го стартирайте веднага
2. четете package.json, middleware-ите и top-level calls
3. търсете code execution при import
4. не вярвайте, че PoC означава безопасно

Supply-chain атаките вече не са абстрактен риск. Те са персонализирани, насочени и търпеливи.

И понякога започват просто с едно съобщение в LinkedIn.

Кредит на @Stan за сорса и помощта при анализа