Цього тижня підставний клієнт підкинув мені у пошту шкідливий репозиторій GitHub, і звичайний запуск стартового скрипта стер два дні роботи та викрав усі паролі, які я зберігаю у браузері.

«Клієнт» опублікував вакансію на високооплачувану посаду senior-інженера, швидко написав мені та надіслав репозиторій, що мав дуже професійний вигляд. Запит був простим: клонувати, запустити npm run dev і надіслати скриншот, щоб підтвердити роботу демо-версії — без жодного контракту чи перевірки даних. Щойно сервер розробки запустився, прихований код у конфігураційному файлі зв'язався з командним сервером (C2), завантажив корисне навантаження другого етапу та почав викачувати облікові дані з локальної машини.

Як відбувалася атака

Шкідливе навантаження знаходилося у postcss.config.js — файлі, на який більшість розробників лише мигцем дивляться, оскільки він зазвичай містить кілька простих правил обробки CSS. У цьому випадку зловмисник додав рядок обфускованого JavaScript далеко праворуч від легітимного виразу, додавши пробіли, щоб він не привертав уваги. Коли команда npm run dev виконувала конвеєр PostCSS, прихований рядок спрацьовував непомітно.

Шкідливе ПЗ виконувало три кроки поспіль:

  • Зв'язок із C2 — воно відкрило мережеве з'єднання з сервером під контролем зловмисника та повідомило про скомпрометований хост.
  • Завантаження другого етапу — воно підтягнуло додатковий код, що містив реальну логіку викрадення даних.
  • Викрадення облікових даних браузера — на macOS воно запитало ключ Chrome Safe Storage, що зберігається в системному зв'язці ключів (keychain). Якщо користувач дозволяв запит зв'язки ключів, зловмисник отримував кожен пароль, збережений у Chrome.

Окрім безпосереднього викрадення, навантаження прописало себе в кількох популярних інструментах розробника — VS Code, npm, Discord — так, що будь-який наступний запуск цих програм знову активував шкідливий код. Звичайне перезавантаження не допомогло позбутися інфекції; наступний npm install або відкриття редактора знову оживляли бекдор.

«Тривожні дзвіночки», які часто залишаються непоміченими

  • Запити на запуск коду до підписання будь-якого контракту. Легітимні процеси найму зазвичай передбачають офіційну угоду перед тим, як передавати будь-яку інтелектуальну власність.
  • Архіви, що маскуються під «описи проєктів». Zip або RAR-архіви можуть приховувати виконувані скрипти або шкідливі бінарні файли.
  • Запити особистих адрес електронної пошти, щоб «обійти фільтри платформи». Цей прийом переводить спілкування за межі захищеної платформи, де можна було б повідомити про порушення.
  • Описи вакансій, де кандидата просять поповнити криптогаманець або купити тестові токени. Такі вимоги не є типовими для справжньої розробки.

Практичні кроки для безпеки

  1. Ніколи не запускайте чужий код без перевірки. Відкривайте репозиторій у режимі лише для читання (наприклад, через перегляд сирого файлу на GitHub) і перевіряйте кожен скрипт, особливо конфігураційні файли та записи в scripts у package.json.
  2. Ставтеся до всіх вкладень як до звичайного тексту. Якщо надіслано zip-файл, розпакуйте його в ізольованому середовищі (sandbox) і перевірте вміст, перш ніж щось відкривати.
  3. Використовуйте спеціалізований менеджер паролів замість сховища браузера. Навіть якщо зв'язка ключів браузера буде скомпрометована, сховище менеджера залишиться ізольованим.
  4. Запускайте ненадійний код в ізольованій віртуальній машині або контейнері без доступу до мережі. Це заблокує зловмиснику можливість зв'язатися з C2-сервером.
  5. Увімкніть двофакторну автентифікацію (2FA) на всіх акаунтах. Якщо пароль буде викрадено, другий фактор зупинить несанкціонований вхід.
  6. Тримайте інструменти розробника в актуальному стані та вмикайте автоматичну перевірку цілісності, якщо це можливо. Деякі редактори тепер попереджають, якщо основні файли змінюються неочікувано.

Якщо ви підозрюєте, що запустили шкідливий код, вважайте систему скомпрометованою. Зробіть резервну копію важливих даних, очистіть диск і перевстановіть операційну систему. Звичайне перезавантаження не знищить механізм закріплення, який перезаписує файли у звичайних програмах.

Підсумок: один рядок прихованого JavaScript може перетворити звичайне демо на повномасштабну операцію з викрадення облікових даних. Ставтеся до кожного репозиторію як до ненадійного, поки не перевірите його, і зробіть ізоляцію стандартною частиною свого робочого процесу. Ціна миттєвої необачності значно перевищує зусилля, витрачені на перевірку файлу.