По данным IBM X-Force Threat Intelligence Index 2025, infostealers вышли на первое место среди всех типов малвари - 32%, обогнав ransomware. Рост атак с использованием действительных учётных данных - 71% год к году. Ежедневно в dark web появляется около 6 000 свежих наборов кредов. Сценарий банален: инфостилер собирает сессионные куки за выходные, в понедельник утром атакующий импортирует их в свой браузер и заходит в корпоративный аккаунт - мимо MFA, мимо пароля, мимо всех контролей. В апреле 2026 года Google включил Device Bound Session Credentials (DBSC) в Chrome 146 для Windows - первый массовый механизм привязки сессионной куки к TPM устройства. Для SOC-команд это не серебряная пуля, а новый элемент detection-стратегии с конкретными сильными и слабыми сторонами. И разбираться в них лучше до того, как вы начнёте на это полагаться в продакшене.
Как работала кража сессий до DBSC: kill chain и MITRE ATT&CK
Сессионная кука - bearer-токен. Кто её предъявляет, тот и аутентифицирован. Серверу плевать, с какого устройства пришёл запрос: есть валидная кука - есть доступ. Именно это свойство сделало кражу сессий основным методом обхода MFA. По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году использовали действительные учётные данные, а по данным Verizon DBIR 2025, 38% подтверждённых утечек связаны с кражей credentials. С учётом ужесточения ответственности за утечки персональных данных в России - компрометация сессии администратора с доступом к базе клиентов ведёт прямиком к штрафным санкциям. Подробнее - в нашем материале про атаки на аутентификацию.Вектор инфостилера: от заражения до захвата аккаунта
Kill chain при атаке через инфостилер (LummaC2, Vidar, Atomic и другие семейства) выстраивается в пять шагов:- Доставка. Фишинг, поддельный установщик, SEO-poisoning. Пользователь запускает малварь на своём устройстве.
- Извлечение. Инфостилер читает файлы и память браузера, где лежат сессионные куки - Credentials from Web Browsers (T1555.003, Credential Access).
- Экспорт. Собранные куки, пароли, данные автозаполнения уходят на C2.
- Реплей. Атакующий импортирует куки в свой браузер - Web Session Cookie (T1550.004, Lateral Movement). Сервер видит валидную сессию.
- Доступ. Полный контроль аккаунта. MFA обойдена - сессия уже аутентифицирована.
AiTM-вектор: Evilginx2 и перехват в реальном времени
AiTM-атаки (Adversary-in-the-Middle, T1557) работают иначе. Reverse-proxy - Evilginx2, Modlishka - встаёт между жертвой и целевым сервером. Пользователь вводит логин, пароль, проходит MFA на реальном сервере через прозрачный прокси. Атакующий перехватывает сессионный токен на лету - Steal Web Session Cookie (T1539, Credential Access) - и тут же его реплицирует. Тут кука не извлекается с диска, а ловится в момент создания. Результат тот же: валидный сессионный токен у атакующего.DBSC Chrome 146: как привязка сессии к устройству работает
Device Bound Session Credentials меняют фундаментальное свойство куки: из bearer-токена она становится proof-of-possession. Кука по-прежнему передаётся серверу, но без криптографического доказательства владения приватным ключом она бесполезна. Красивый фантик без конфеты.Протокол: регистрация, challenge, refresh
Согласно спецификации W3C и документации Chrome для разработчиков, протокол работает в три фазы:Регистрация. После аутентификации сервер возвращает заголовок
Secure-Session-Registration, указывая endpoint для привязки. Chrome генерирует уникальную пару ключей внутри TPM (Windows) или Secure Enclave (macOS - в будущем релизе). Приватный ключ не покидает аппаратный модуль. Публичный ключ отправляется серверу и ассоциируется с сессией. Сервер заменяет долгоживущую куку на короткоживущую - в примере из документации Chrome TTL составляет 10 минут.Refresh. При истечении короткоживущей куки Chrome обращается к refresh-endpoint. Сервер отвечает challenge, Chrome подписывает его приватным ключом TPM и возвращает JWT-proof. Сервер проверяет подпись, выдаёт свежую короткоживущую куку.
Результат. Кука, украденная инфостилером, протухнет через минуты. Refresh с чужого устройства невозможен - приватный ключ аппаратно привязан к конкретному TPM.
Серверный ответ при регистрации сессии, по данным документации Chrome:
HTTP:
HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600;
Domain=example.com; Secure; SameSite=Lax
{"session_identifier":"session_id",
"refresh_url":"/RefreshEndpoint",
"credentials":[{"type":"cookie","name":"auth_cookie",
"attributes":"Domain=example.com; Secure; SameSite=Lax"}]}Где kill chain ломается
Для инфостилеров kill chain разрывается на шаге 4 (реплей). Короткоживущая кука истечёт до того, как атакующий успеет её использовать, а refresh без TPM-ключа провалится.Для AiTM-атак ситуация тоньше. Если прокси перехватывает токен в реальном времени и использует его немедленно - окно TTL куки (минуты) всё ещё доступно. Но автоматический refresh потребует от атакующего relay challenge-response обратно к TPM жертвы, а это радикально усложняет цепочку и создаёт отчётливый аномальный паттерн в логах. Из «скопировал куку и забыл» задача превращается в «держи relay-канал к TPM жертвы живым на протяжении всей сессии».
Ограничения DBSC: что остаётся уязвимым для SOC
DBSC - хороший контроль, но не полное решение проблемы кражи сессий. Ниже - конкретные слепые зоны, которые SOC-команда должна учитывать при планировании detection-стратегии. И тут начинается самое интересное.Покрытие: только Chrome на Windows
DBSC доступен в Chrome 146+ на Windows с TPM. Поддержка macOS через Secure Enclave анонсирована для будущего релиза без конкретных сроков. Мобильные браузеры - мимо. Firefox, Safari, Edge - мимо. Сотрудник, открывший корпоративную Jira в Firefox на домашнем MacBook, полностью за пределами защиты DBSC.Серверная имплементация: проблема длинного хвоста
DBSC - клиент-серверный протокол. Привязка работает, только если веб-приложение реализовало серверные endpoints. Google и Okta это сделали. Корпоративная CRM, тикет-система, внутренний GitLab, DevOps-инструментарий - с высокой вероятностью нет. Сессия Google Workspace защищена, а остальная инфраструктура - как была голая, так и осталась.Инфостилеры крадут не только куки
По данным Constella, 98,6% пакетов инфостилеров содержат пароли, SSH-ключи, VPN-конфигурации, API-токены. DBSC обесценивает куки, но остальные собранные артефакты остаются валидными. Стилер утащил SSH-ключ к продовому серверу - DBSC тут ни при чём.Скомпрометированный хост и insider threat
Критический нюанс. DBSC привязывает сессию к устройству, но не к физическому присутствию пользователя. Если атакующий получил удалённый доступ к легитимному хосту (RAT, RDP, скомпрометированный VPN), TPM по-прежнему доступен на этом устройстве. Браузер на захваченной машине проходит challenge-response нормально - TPM отвечает на запросы от локальных процессов. Это техника Browser Session Hijacking (T1185, Collection): атакующий не крадёт куку, а управляет браузером на месте.Сценарии, где DBSC не помогает:
- Insider threat - сотрудник на своём корпоративном устройстве. TPM - его.
- RAT с remote control - малварь управляет Chrome на захваченном хосте, TPM доступен.
- Скомпрометированная рабочая станция - endpoint под контролем, привязка к этому же endpoint бесполезна.
Устройства без TPM
На устройствах без TPM Chrome откатывается на стандартное поведение: долгоживущие куки без привязки. Fallback происходит тихо, без предупреждений. Старое корпоративное железо, домашние ноутбуки сотрудников - всё за пределами защиты.| Сценарий | DBSC закрывает | Требует дополнительных мер |
|---|---|---|
| Инфостилер крадёт куки с диска | Да - кука истечёт, refresh без TPM невозможен | Мониторинг заражения endpoint |
| AiTM через Evilginx2 в реальном времени | Частично - окно TTL сохраняется | Детектирование фишинговых доменов |
| RAT с управлением браузером на хосте | Нет - TPM доступен атакующему | EDR, поведенческий анализ |
| Insider threat | Нет - легитимный пользователь на своём устройстве | UEBA, DLP, мониторинг привилегий |
| Firefox / Safari / Edge | Нет - только Chrome | Политика принудительного использования Chrome |
| SaaS без серверной поддержки DBSC | Нет - серверная часть не реализована | Аудит SaaS-портфеля |
| Устройство без TPM | Нет - fallback на стандартные куки | Инвентаризация парка устройств |
Detection-чеклист: мониторинг кражи сессионных токенов в SIEM
DBSC не заменяет мониторинг - сужает поверхность атаки. Ниже - конкретные правила, которые стоит внедрить.Серверная телеметрия DBSC
Если ваше приложение поддерживает DBSC, серверная сторона должна логировать:Detection session cookie replay без DBSC
Для приложений без серверной поддержки DBSC - классический подход на основе гео-аномалий:
YAML:
# Концептуальная detection-логика (адаптировать под SIEM)
title: Session Cookie Replay - GeoIP Anomaly
logsource:
category: webserver
detection:
selection:
event_type: authenticated_request
filter_geo_jump:
geo_distance|gt: 500 # км между запросами
time_delta|lt: 300 # секунд
condition: selection and filter_geo_jump
level: highМониторинг инфостилеров на endpoint
DBSC обесценивает украденные куки, но само заражение инфостилером требует реагирования. Что мониторить в EDR:- Алерты на известные семейства: LummaC2, Vidar, Atomic.
- Обращения к характерным C2-доменам.
- Нетипичные процессы, читающие файлы
Cookies,Login Dataиз профиля Chrome. - Массовая эксфильтрация данных из директории профиля браузера.
Маппинг TTPs для полного покрытия цепочки
| Этап kill chain | Техника MITRE ATT&CK | Что мониторить |
|---|---|---|
| Извлечение кук из браузера | T1555.003 - Credentials from Web Browsers | Доступ к Cookie SQLite из нетипичных процессов |
| Кража сессионного токена | T1539 - Steal Web Session Cookie | Exfil cookie-данных |
| Реплей на другом устройстве | T1550.004 - Web Session Cookie | Geo-anomaly, device fingerprint mismatch |
| AiTM-перехват | T1557 - Adversary-in-the-Middle | Фишинговые домены с валидным TLS |
| Управление браузером на хосте | T1185 - Browser Session Hijacking | RAT-сессии с активным браузером |
Hardening: подготовка инфраструктуры к DBSC
Требования к окружению
- ОС: Windows 10/11 с TPM 2.0 (проверка:
tpm.mscилиGet-Tpmв PowerShell) - Браузер: Chrome 146+ (проверка:
chrome://settings/help) - Проверка DBSC:
chrome://device-bound-session-credentials/- страница показывает текущий статус привязки сессий - Серверная сторона: веб-приложение с endpoints регистрации и refresh по спецификации DBSC
Чеклист для SOC и IT
- Инвентаризация TPM. Определить долю managed endpoints с TPM 2.0. Устройства без TPM - кандидаты на замену или компенсирующий контроль (усиленный мониторинг, ограничение доступа к критичным сервисам).
- Аудит SaaS-портфеля. Составить список критичных приложений, проверить серверную поддержку DBSC. Для каждого приложения без поддержки - зафиксировать session cookie exposure как активный нескомпенсированный риск.
- Chrome Enterprise. Для Google Workspace - активировать DBSC через Admin Console. Для managed devices - убедиться, что Chrome обновлён до 146+.
- Политика браузера. Если DBSC входит в стратегию - ограничить использование альтернативных браузеров для критичных приложений через GPO или MDM.
- Fallback-мониторинг. Настроить алерты на DBSC-fallback (TPM-ошибки, rate-limit, отсутствие модуля).
- Серверный logging. Для приложений с поддержкой DBSC - логировать refresh-события, неуспешные challenge-response, fallback. Это основа detection-правил.
- Тестирование с корпоративным прокси. Корпоративные SSL-inspection системы и DLP, вмешивающиеся в TLS-сессии, могут конфликтовать с DBSC refresh. Проверить на пилотной группе до массового развёртывания.
DBSC - первый механизм, который переводит защиту сессий из реактивной модели (обнаружить кражу постфактум) в проактивную (украденная кука бесполезна). Но переоценивать охват опасно. Сейчас это Chrome на Windows для приложений, реализовавших серверную часть. Для всего остального - detection-правила, EDR-мониторинг и аудит SaaS-портфеля остаются основой.
Моя оценка: в ближайшие год-два основная масса корпоративных SaaS не реализует серверную часть DBSC. Слишком много legacy, слишком мало стимулов у вендоров. Реальное покрытие DBSC будет ограничено Google-экосистемой, Okta и, может быть, ещё десятком крупных платформ. Всё остальное - зона ответственности SOC. И тут возникает новая задача: классифицировать сессии на «защищённые DBSC» и «незащищённые», строить разные detection-пороги для каждой категории. Инцидент-менеджмент усложняется, а не упрощается. DBSC поднимает планку для атакующего, но поднимает и требования к зрелости detection на стороне защиты. На codeby.net обсуждают detection session hijacking и DBSC-fallback в привязке к конкретным SIEM - полезно сверить подходы, если строите правила для этой группы TTP.
