Інфостілери та крадіжка сесій: чому 2FA не рятує від витоку cookie та як закрити вразливість

Більшість керівників та системних адміністраторів переконані: якщо на всіх корпоративних сервісах увімкнена двофакторна автентифікація (2FA), компанія перебуває у повній безпеці. Проте статистика останніх гучних зламів доводить протилежне. Зловмисникам більше не потрібні логіни, паролі чи SMS-підтвердження — вони просто викрадають уже активну авторизовану сесію прямо з пам'яті браузера.

Головна зброя сучасних кіберзлочинців — шкідливе ПЗ класу Infostealer (інфостілери на зразок Lumma, RedLine або Vidar). Вони розповсюджуються через фішингові листи, зламані утиліти чи шкідливі пакети у відкритих репозиторіях, викачують дані браузера за секунди і передають готовий доступ хакерам. Розглянемо анатомію цієї загрози та способи блокування.

1. Як влаштований механізм крадіжки сесій (Session Hijacking)

Коли співробітник входить у корпоративний Google Workspace, AWS Console, Slack або GitHub, проходячи перевірку паролем та кодом 2FA, сервер видає браузеру зашифрований файл сесії — Session Cookie. Саме цей токен повідомляє серверу, що користувач уже перевірений, позбавляючи потреби вводити пароль при кожному переході між сторінками.

• Блискавичне сканування профілів: Інфостілер, потрапивши на робочу машину, миттєво знаходить локальні бази даних Chrome, Firefox, Edge або Brave (файли SQLite, де браузери зберігають історію та куки).
• Імпорт сесії в браузер хакера: Зловмисник отримує заархівований дамп (лог) жертви, відкриває свій браузер і за допомогою розширення підставляє вкрадені cookie.
• Миттєвий вхід в обхід 2FA: Сервер переглядає валідний файл сесії і сприймає хакера як законного авторизованого співробітника. Жоден додатковий код чи SMS при цьому не запитується.

2. Типові сценарії проникнення шкідливого коду

Злам пристрою співробітника зазвичай відбувається через людський фактор або специфічні інструменти розробки:

1. Пошук безкоштовного або зламаного ПЗ. Спроба завантажити «активований» графічний редактор, конвертер файлів або утиліту для роботи із системними драйверами — класичний спосіб підхопити стілер, зашитий усередину інсталятора.
2. Отруєні залежності у коді (Typosquatting). Розробник встановлює пакет через npm або pip, зробивши помилку в одній літері популярної бібліотеки (наприклад, cross-envv замість cross-env). Фейковий пакет під час складання проекту сканує файли конфігурацій (.env) та токени доступу.
3. Цільовий рекрутинговий фішинг. Співробітнику в LinkedIn або Telegram надсилають нібито тестове завдання від відомої компанії у вигляді архіву з проектом, запуск якого активує скрипт крадіжки сесій.

3. Як вибудувати надійний захист від інфостілерів

Нейтралізація загрози Session Hijacking вимагає зміни підходу до керування тривалістю та контекстом сесій:

• Скорочення часу життя сесій (Session Timeout): Налаштуйте примусове завершення сесії в критичних сервісах (AWS, банківські кабінети, сервери керування) через 8–12 годин бездіяльності, щоб викрадений файл втрачав актуальність до моменту його використання хакером.
• Прив'язка токенів до пристрою (Device Bound Session Credentials): Новий стандарт безпеки від Google та Microsoft, який шифрує токени сесії за допомогою апаратного чипа TPM у материнській платі. Навіть якщо файл cookie викрадуть, він не запуститься на іншому комп'ютері.
• Ізоляція робочого профілю: Забороніть синхронізацію особистих акаунтів браузера на робочих комп'ютерах та зберігання паролів у вбудованих менеджерах браузерів. Використовуйте тільки ізольовані корпоративні менеджери паролів (1Password, Bitwarden).

Підсумок

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