634 паролі за 56 секунд

Розробник — обізнаний у безпеці, досвідчений, людина, яка свідомо шукає ознаки шахрайства — пройшов багатоетапний процес співбесід із фейковою компанією. Дзвінок від HR. Технічна співбесіда з двома інженерами. Справжній сайт із фото команди. Справжні профілі LinkedIn. Тижні налагодження стосунків.

Потім його попросили виконати невелике тестове завдання під час демонстрації екрана.

Через 56 секунд у зловмисників уже було 634 збережених паролі Chrome, файл macOS Keychain (який містить ключ для їхнього розшифрування) та дані гаманця MetaMask.

Як працювала атака

Репозиторій на GitHub виглядав чистим. Кілька файлів бекенду, нічого підозрілого. Але одна залежність — winston-middleware, пакет для логування з цілком невинною назвою — мала власну залежність: next-runtimejs.

Там і ховалася зброя.

У момент запуску npm install беззвучно виконався shell-скрипт. Без запитів, без попередджень. Він завантажив бекдор на основі Go та зареєстрував його для автозапуску під час кожного завантаження системи.

Це не був інструмент script kiddie. Власний C2-протокол із шифруванням RC4. Команди для виконання shell, крадіжки файлів, витягнення паролів Chrome, ексфільтрації Keychain і націлювання на криптогаманці. Побудовано професійно.

Бекдор запустився о 16:16:37. Паролі Chrome були отримані о 16:17:33. Розробник помітив системне повідомлення macOS про вихідне з'єднання й вимкнув WiFi менш ніж за хвилину — але шкоду вже було завдано.

Чому важливою була співбесіда

Ця атака провалилася б у вигляді холодного листа. «Запустіть цей репозиторій» від незнайомця ігнорують.

Але після двох раундів співбесід? Після того, як ви разом сміялися з того, скільки фейкових вакансій націлено на розробників? Після того, як один з інтерв'юерів з усмішкою сказав: «Можете спокійно пошукати бекдори»?

Ось тоді й опускається пильність. Довіра — це експлойт. Шкідливий код — лише корисне навантаження.

Розробник сказав найкраще: «Якщо це сталося зі мною, це може статися з будь-ким у вашій команді».

Що насправді означають паролі Chrome

Chrome шифрує збережені паролі за допомогою AES. Ключ розшифрування зберігається в macOS Keychain. Зловмисники викрали обидва файли менш ніж за хвилину.

Кожен збережений пароль — банкінг, електронна пошта, GitHub, хмарні консолі — був читаний на їхньому боці. Файл Keychain можна зламати офлайн, без обмежень кількості спроб. Розробнику довелося замінити все.

Це брудний секрет паролів, збережених у браузері: вони зашифровані ключем, який живе на тому самому комп'ютері. Скомпрометуйте комп'ютер — і «шифрування» перетворюється на декорацію.

Патерн DPRK

Розробник згадав, що його попередню компанію також зламала Північна Корея — це сталося за три місяці до того. Це кампанія «Contagious Interview» — державні зловмисники DPRK проводять фейкові співбесіди, щоб встановити шкідливий код на комп'ютери розробників.

Це не випадковість. Вони націлюються саме на розробників через те, до чого ті мають доступ: облікові дані продакшену, ключі підпису, хмарна інфраструктура та — дедалі більше — токени AI-агентів, які відкривають доступ до ще більшого.

Масштаб промисловий. Фейкові компанії зі згенерованими обличчями. Ополісовані сайти. Процеси співбесід на кілька тижнів. Вони інвестують, бо ROI це виправдовує.

«Менеджери паролів не допомагають»

Розробник висловив у гілці цікаве твердження: «Менеджери паролів не допомагають, якщо зловмисники мають доступ до вашого комп'ютера через такий бекдор, бо вони можуть пізніше передати будь-який файл, створити спеціальний експлойт саме під вас, використати кейлогери, скріншоти».

Це частково правильно і частково ні.

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

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

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

Що робити

• Ніколи не запускайте код зі співбесіди на своєму основному комп'ютері. Використовуйте віртуальну машину або окремий пристрій.
• Запускайте npm install --ignore-scripts для будь-якого незнайомого репозиторію перед виконанням
• Використовуйте мережевий екран вихідного трафіку (Little Snitch, LuLu), який сповіщає про нові з'єднання
• Припиніть зберігати паролі в Chrome. Без винятків.
• Тримайте криптовалюту на апаратних гаманцях, а не в розширеннях браузера
• Ставтеся до кожного тестового завдання від рекрутера як до потенційно ворожого — незалежно від того, скільки дзвінків ви вже мали

Розробник вижив тому, що системне повідомлення macOS вчасно зафіксувало вихідне з'єднання. Більшість людей натиснула б «Дозволити» без роздумів.

56 секунд. Саме стільки потрібно.