Двухфакторная защита не спасает от кражи cookie после входа
Двухфакторная аутентификация (SMS-код, подтверждение в приложении, аппаратный ключ) решает конкретную задачу: доказать сервису, что вход выполняет именно владелец учётной записи. Проблема в том, что после успешной проверки браузер получает "пропуск" - cookie активной сессии. И этот файл создаётся уже после того, как пароль и второй фактор отработали. Поэтому злоумышленнику, завладевшему cookie, часто не нужен ни пароль, ни одноразовый код, ни даже аппаратный ключ: сервис видит "уже подтверждённую" сессию и не запускает проверку повторно.
Почему смена пароля не всегда спасает
Интуитивный шаг после взлома - поменять пароль. Но смена пароля нередко не закрывает уже открытые сессии. То есть украденный cookie может продолжать работать, пока вы отдельно не завершите активные сеансы в настройках аккаунта. На практике это становится неприятным сюрпризом: человек меняет пароль, успокаивается, а злоумышленник ещё какое-то время остаётся "внутри".
Отдельная проблема - что закрывать сессии зачастую приходится вручную. И это касается не только отдельных сайтов: сессии живут в экосистемах и облачных сервисах, где один вход открывает доступ к почте, документам, хранилищу, платежам и управлению устройствами.
Как cookie попадает к злоумышленнику: роль стилеров
Чаще всего цепочка начинается со стилера - класса вредоносных программ, которые собирают с заражённого компьютера пароли, cookie, данные автозаполнения и содержимое криптовалютных кошельков. На устройство стилер попадает типовым набором методов: взломанное ПО, подменённый установщик, вредоносное вложение в письме. Дальше всё прозаично: программа читает файлы, где браузер хранит cookie, и отправляет добытое на сервер атакующего.
После этого украденный файл импортируют в "свой" браузер и заходят на нужный сайт. Для сервиса такая сессия выглядит действующей: вход уже подтверждён ранее, а значит - пароль и SMS-код могут вообще не потребоваться.
Важно: удаление вредоносной программы само по себе проблему не закрывает. Кража происходит после входа, и уже утёкшие cookie способны продолжать работать даже тогда, когда антивирус отчитался об "успешной очистке".
Масштаб рынка: миллионы заражений и миллиарды записей
Объём теневого оборота украденных данных хорошо иллюстрируют оценки аналитиков: за 2025 год насчитали более 11,1 млн машин, заражённых стилерами, и около 3,3 млрд учётных данных и облачных токенов, полученных с этих устройств. Cookie сессий обычно учитываются в том же массиве, даже если не выделяются отдельной строкой - но именно они часто дают самый быстрый "вход без пароля".
Часть инфраструктуры этого рынка пытались ломать силовыми операциями. Так, в ходе операции Endgame сообщалось об ударе по StealC и Amadey, а также по сети распространения SocGholish. Работы велись 15-19 июня силами ведомств Канады, Дании, Германии, Нидерландов, Великобритании и США при координации Europol и Eurojust. Итогом стало отключение 326 серверов и 142 доменов, изъятие порядка 27 млн наборов учётных данных, собранных более чем с 385 000 систем, а также заморозка криптоактивов на сумму свыше 41 млн евро. Пострадавших частично уведомляли через сервис проверки утечек; в переданных правоохранителям массивах набралось более 4,3 млн уникальных e-mail-адресов.
Почему второй фактор "проверяет не то"
Двухфакторная аутентификация не предназначена для того, чтобы защищать уже выданную сессию. Она подтверждает личность в момент входа, а cookie становится доказательством, что проверка была пройдена. Если доказательство украдено, повторно доказывать ничего не нужно - в этом и заключается уязвимость модели.
Даже режимы повышенной защиты не всегда меняют картину. В частности, в Google прямо отмечали: если злоумышленник не "входит заново", а просто использует действующую сессию, аппаратный ключ могут повторно и не запросить.
Что происходит в браузерах: шифрование и его пределы
На Windows cookie в Chrome шифруются механизмом App-Bound Encryption, который добавили в Chrome 127 (релиз - июль 2024 года). Логика такая: ключ привязан к приложению, а расшифровку выполняет системная служба с повышенными правами, проверяя, кто именно обратился за доступом к данным. Это усложняет жизнь массовым стилерам, но не делает кражу невозможной.
Предел этой схемы описывали сами разработчики: вредонос, запущенный с повышенными привилегиями, способен обходить защиту. Однако практика показала, что иногда достаточно и обычных пользовательских прав. В марте 2026 года исследователи Gen Digital разбирали технику VoidStealer: вредонос запускает скрытый процесс браузера, подключается к нему отладчиком и через аппаратные точки останова извлекает мастер-ключ прямо из памяти - без внедрения кода и без прав администратора. Вывод простой: шифрование делает атаку дороже, но не отменяет её.
Device Bound Session Credentials: попытка привязать сессию к железу
Реальный сдвиг наметился с идеей привязки сессии к конкретному устройству, чтобы украденный cookie терял ценность "вне родной машины". Google 9 апреля 2026 года объявила о доступности механизма Device Bound Session Credentials (DBSC) в Chrome 146 для Windows, а 25 мая начала подключать к нему аккаунты Google Workspace и личные аккаунты Google. В этой модели закрытый ключ остаётся в TPM (аппаратном модуле безопасности), и это меняет правила игры: сессию становится сложнее перенести на другой компьютер "просто файлом".
Но и здесь важно понимать нюанс: это не "магическая таблетка", а постепенное повышение стоимости атаки. Злоумышленники смещают фокус туда, где проще - например, к захвату уже запущенной сессии на том же устройстве или к атакам на рабочие станции в момент активности пользователя.
Firefox: шифрование есть, но не у всех и не всегда
На стороне Firefox ситуация долгое время выглядела тревожно: база cookie могла лежать на диске фактически в открытом виде. При этом код шифрования SQLite действительно вошёл в Firefox 154, но параметр оказался выключен по умолчанию. В итоге многое упирается не только в возможности браузера, но и в то, как они включены и настроены в реальной жизни - особенно в компаниях, где обновления и политики применяются неравномерно.
---
Что делать, если есть риск кражи cookie (пошагово)
1) Сначала - очистка и переустановка, потом - смена паролей
Если есть подозрение на стилер, порядок действий критичен. Смена паролей на заражённой системе может просто "подарить" злоумышленнику новые данные. Практичная последовательность: изолировать устройство, сохранить важное, переустановить систему (или выполнить гарантированную очистку), и только затем менять пароли и ключи восстановления.
2) Немедленно завершите все активные сессии
Так как смена пароля не гарантирует разлогин, нужно принудительно закрывать сеансы. Это делается в настройках безопасности аккаунта:
- Google: управление устройствами и сеансами в разделе безопасности (там же обычно видны "Ваши устройства" и недавняя активность).
- Microsoft: просмотр устройств и выход из сеансов в панели безопасности аккаунта, плюс проверка активностей входа.
- Apple: список доверенных устройств и управление входами через Apple ID; при необходимости - принудительный выход и пересмотр доверенных устройств.
Смысл один: сделать так, чтобы украденный cookie перестал быть действительным, даже если злоумышленник уже "внутри".
3) Пересмотрите "доверие" к устройствам и приложениям
Cookie часто живут рядом с токенами "Запомнить меня", авторизациями приложений и разрешениями сторонним сервисам. Проверьте:
- список подключённых приложений и выданных доступов;
- резервные e-mail/телефон для восстановления;
- правила переадресации в почте и фильтры (их любят менять при тихом захвате аккаунта);
- новые ключи, способы входа и доверенные устройства.
4) Сократите время жизни сессий там, где это возможно
В корпоративной среде полезно уменьшать "окно" для злоумышленника: политики коротких сессий, обязательная повторная проверка для финансовых операций, запрет долгого "Remember me" на критичных сервисах. Да, это чуть менее удобно, зато резко снижает эффект от украденного cookie.
5) Разделяйте профили и используйте отдельный браузер для критичных задач
Практичный бытовой приём: отдельный профиль (или даже отдельный браузер) только для банка, почты и рабочего аккаунта. Меньше расширений, меньше входов на сомнительные сайты, меньше риск подхватить стилер через цепочки загрузок. Чем "чище" среда, тем ниже вероятность, что cookie утекут.
6) Осторожнее с расширениями и "бесплатными" утилитами
Расширения - один из самых недооценённых источников риска: они могут читать содержимое страниц и перехватывать данные сессии. Минимизируйте список, удаляйте всё неиспользуемое, избегайте малоизвестных разработчиков. То же относится к "крякам", сборкам и установщикам с непонятных источников: стилеры часто приезжают именно так.
7) Не переоценивайте ключи доступа (passkeys)
Ключи доступа заметно улучшают защиту от фишинга и кражи паролей, но они не являются универсальным щитом от сценария "украли cookie после входа". Если сессия уже создана и её токен украден, passkeys не обязательно заставят сервис запросить повторную проверку. Их сила - в предотвращении компрометации учётных данных, а не в полной нейтрализации угнанных сессий.
8) Следите за признаками "тихого" взлома
Кража cookie часто проходит без смены пароля и без уведомлений. Косвенные признаки: неожиданные входы, новые устройства, письма о правилах переадресации, "прочитанные" сообщения, которых вы не открывали, появление черновиков, изменения в облачном хранилище, новые платежные методы или попытки сброса пароля.
---
Вывод
Двухфакторная аутентификация остаётся необходимой - она отлично режет фишинг и взломы по паролям. Но она не закрывает ключевой сценарий последних лет: угон сессии через кражу cookie уже после входа. Поэтому защита должна строиться шире: гигиена устройства, контроль активных сессий, минимизация поверхности атаки, а на уровне браузеров - переход к привязке сессий к устройству (как в DBSC) и более строгим политикам хранения cookie. В противном случае даже "идеальный" второй фактор может оказаться бессилен там, где злоумышленнику достаточно украсть ваш уже выданный пропуск.
