Статья Session hijacking атаки JWT токены: от перехвата до detection в SIEM

Персональный токен доступа (PAT), случайно слитый в историю чата ChatGPT, оставался валидным несколько месяцев и давал admin-доступ к production-репозиториям нескольких организаций. Кейс описан Obsidian Security - двух низкоприоритетных API-вызовов хватило для маппинга всего доступного периметра. Без единой записи в аудит-логе. Это не экзотика: session hijacking и token replay attack систематически обходят MFA, а SOC-команды узнают о компрометации постфактум. Разберём, как ломают JWT токены, cookie-based authentication и bearer-токены - и какие корреляционные правила должны стоять на потоке.

Бизнес-логика атаки: зачем атакующему ваш токен​

Угон сессии и перехват токена аутентификации - это не про «хакер в кафе с Wireshark». Цель: получить доступ к ресурсам от имени легитимного пользователя, минуя MFA, без знания пароля. По классификации OWASP Top 10 (A07:2021 - Identification and Authentication Failures) ошибки управления сессиями входят в топ критичных рисков для веб-приложений. Подробнее - в нашем материале про атаки на аутентификацию.

Для SOC это конкретный impact:

• Account takeover - атакующий действует под валидной учёткой, его действия в логах неотличимы от легитимных
• Lateral movement - украденный OAuth-токен или session cookie катается между сервисами (Slack, M365, Jira) без повторной аутентификации
• Обход MFA - MFA проверяется один раз при логине, дальше доступ идёт по токену, и MFA его не перепроверяет
• Data exfiltration - через украденный PAT или refresh token утечка из production-среды может длиться месяцами

В контексте российского законодательства (ФЗ-152, оборотные штрафы за утечку персональных данных) компрометация через token replay - прямой финансовый риск. При этом классических IOC нет: нет brute-force, нет фишинга в привычном виде, нет эксплуатации CVE.

Место в цепочке атаки: маппинг MITRE ATT&CK​

Session hijacking - не изолированная техника, а этап в цепочке. Атакующий сначала получает токен (credential access), потом использует его для перемещения (lateral movement) и сбора данных (collection). Маппинг на верифицированные техники MITRE ATT&CK:

Этап атаки	Техника MITRE ATT&CK	Тактика
Кража cookie из браузера	Steal Web Session Cookie (T1539)	Credential Access
Кража OAuth/API-токена	Steal Application Access Token (T1528)	Credential Access
AITM-перехват сессии	Adversary-in-the-Middle (T1557)	Credential Access, Collection
Подделка cookie	Web Cookies (T1606.001)	Credential Access
Манипуляция браузерной сессией	Browser Session Hijacking (T1185)	Collection
Использование cookie для LM	Web Session Cookie (T1550.004)	Lateral Movement
Использование токена для LM	Application Access Token (T1550.001)	Lateral Movement
Обход MFA через replay	Multi-Factor Authentication (T1556.006)	Defense Impairment, Persistence

Если вы детектите только credential access (кражу токена), но не мониторите lateral movement (использование украденного токена между сервисами) - атакующий уже перемещается по инфраструктуре, а вы об этом не знаете. Восемь техник - восемь точек, где нужны правила. Большинство SOC покрывают от силы две-три.

JWT атаки эксплуатация: none algorithm, key confusion и brute-force​

JWT используется повсеместно - от API-аутентификации до межсервисной авторизации в микросервисах. Уязвимости в реализации JWT попадают под OWASP A02:2021 (Cryptographic Failures) и A07:2021 (Authentication Failures).

None Algorithm и Key Confusion - механика и detection​

JWT none algorithm атака: атакующий подменяет поле alg в заголовке на none и удаляет подпись. Если сервер доверяет значению alg из токена без whitelist допустимых алгоритмов - токен принимается без верификации. Звучит нереалистично? А встречается чаще, чем хотелось бы.

Key Confusion (RS256 к HS256): сервер ожидает RSA-подпись (RS256), но атакующий подменяет алгоритм на HMAC (HS256) и использует публичный ключ RSA как HMAC-секрет. Публичный ключ по определению доступен, а если сервер применяет одну и ту же функцию верификации для обоих алгоритмов - JWT signature bypass успешен.

Предусловия и ограничения:

• None algorithm работает только против серверов без whitelist алгоритмов. В современных библиотеках (PyJWT 2.x+, jsonwebtoken 9.x+ для Node.js) атака заблокирована по умолчанию - но legacy-приложения и кастомные реализации по-прежнему уязвимы
• Key Confusion требует, чтобы сервер использовал единую функцию верификации для HMAC и RSA - характерно для старых версий библиотек и самописных решений
• Обе атаки неприменимы к серверам, где алгоритм задан в конфигурации и поле alg из токена игнорируется

Detection для SOC:

• Мониторинг application-логов на JWT с alg: "none" или неожиданным алгоритмом (HS256 при настроенном RS256) - однозначный IOC
• Всплеск 401/403 ошибок от API-эндпоинтов, связанных с JWT-валидацией - косвенный сигнал probe-активности
• Корреляция: один IP шлёт запросы с разными значениями alg за короткий период - целенаправленный перебор

JWT signature bypass: brute-force секретов и обнаружение​

Если JWT подписан HMAC с коротким или словарным секретом, атакующий перехватывает один валидный токен и запускает офлайн-перебор через hashcat -m 16500. После восстановления секрета - генерирует произвольные токены с любыми claims, включая role: admin.

На одном проекте мы встретили HMAC-секрет secret123. Hashcat справился за 4 секунды.

Предусловия: атака офлайновая - перебор невозможно детектить по сетевому трафику. Detection строится на последствиях:

• Появление JWT с claims, которых не было при штатном логине (например, role изменился с user на admin без flow повышения привилегий)
• Токен с iat (issued at) в прошлом, но с неизвестным серверу jti (JWT ID) - сервер не выдавал такой токен
• Массовые авторизации с одним токеном с разных IP - кража токена аутентификации

Cookie-based authentication уязвимости: AITM и кража cookie​

Cookie-based auth - самый распространённый механизм управления сессиями. И самая частая цель session hijacking: перехватив session cookie, атакующий получает полноценный доступ к сессии без пароля и MFA. Помимо перехвата, есть session fixation атака - атакующий навязывает жертве заранее известный session ID через подготовленную ссылку. Современные фреймворки регенерируют session ID при логине, так что вектор встречается реже, но на legacy-приложениях - вполне живой.

AITM-прокси: bearer token перехват в обход MFA​

Adversary-in-the-Middle (T1557) - самый опасный вектор кражи cookie. Атакующий разворачивает reverse-proxy (Evilginx, Modlishka) между жертвой и легитимным сервером аутентификации. Жертва вводит логин, пароль и MFA-код - всё проходит через прокси к реальному серверу. Сервер возвращает session cookie, прокси его перехватывает. Пользователь даже не замечает подвоха.

По данным Varonis Threat Labs (Cookie-Bite), эта техника активно применяется для компрометации Microsoft 365: перехват cookie ESTSAUTH и ESTSAUTHPERSISTENT даёт полный доступ к Outlook, Teams и SharePoint. При инъекции украденных cookie с эмуляцией OS, браузера и сетевых параметров жертвы атакующие обходят Conditional Access Policies (CAP) - основной механизм Zero Trust в Azure AD. То есть даже «правильно настроенный» Zero Trust не спасает, если cookie уже утёк.

Detection для SOC:

• URL-анализ фишинговых писем: AITM-прокси используют домены, визуально похожие на легитимные
• Мониторинг TLS-сертификатов в прокси-логах: AITM-домены типично используют свежие сертификаты Let's Encrypt
• Корреляция: успешный логин из нового ASN (автономная система), не характерного для пользователя, с немедленным доступом к почте - высокоприоритетный алерт

Infostealer и вредоносные расширения: IOC для EDR​

Второй вектор кражи cookie - малварь на рабочей станции. По данным Varonis, инфостилеры работают по модели Malware-as-a-Service: операторы разрабатывают малварь, tracers распространяют через фишинг или вредоносную рекламу, а украденные cookie продаются на даркнет-маркетплейсах. Порог входа - пара сотен долларов в месяц.

Методы извлечения cookie (по данным Varonis Cookie-Bite):

• Memory dump процесса браузера - инфостилер инъектится в chrome.exe / msedge.exe и читает расшифрованные cookie из памяти
• Расшифровка SQLite-базы cookie - на Windows cookie зашифрованы через DPAPI; малварь вызывает CryptUnprotectData() в контексте пользовательской сессии
• Вредоносные расширения - работают внутри браузерного контекста, не требуют инъекции в процесс и сложнее детектируются EDR

Этот вектор напрямую связан с insider threat и скомпрометированными легитимными хостами: рабочая станция с инфостилером - внутренний плацдарм. Трафик в логах SIEM идёт от доверенного IP корпоративной сети, без аномалий на уровне сетевого baseline. Правило «подозрительный внешний IP» тут бесполезно.

Detection в EDR:

• Попытки чтения файлов cookie-базы браузера (путь %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies) процессами, не являющимися браузером
• Вызовы CryptUnprotectData() из нехарактерных процессов - актуально для CrowdStrike Falcon, Kaspersky EDR Expert, SentinelOne
• Загрузка неподписанных расширений в Developer Mode - мониторинг через GPO или EDR-политики

Token replay attack: behavioral detection для bearer-токенов​

Bearer-токены (OAuth access tokens, refresh tokens) дают доступ любому предъявителю без дополнительного подтверждения. Фундаментальная проблема: система не отличает легитимного пользователя от атакующего с тем же токеном. Токен - это ключ, и кто его предъявил, того и пустят.

Вектора bearer token перехват:

• Third-party integration compromise - компрометация вендора, хранящего OAuth refresh-токены клиентов (кейс CircleCI, описанный Obsidian Security: единая интеграция каскадировала на сотни окружений)
• Consent phishing - атакующий регистрирует OAuth-приложение с легитимным названием и запрашивает broad scopes; пользователь жмёт «Allow» - токен получен напрямую от authorization server
• XSS - если токен хранится в localStorage или sessionStorage, любой JavaScript в том же origin может его утянуть
• Network interception - перехват заголовка Authorization: Bearer <token> через MITM при ошибке TLS-конфигурации

Сигнатурная валидация бесполезна - украденный токен криптографически валиден. Detection строится на поведенческих аномалиях:

Метод detection	Что детектим	Confidence
Impossible travel	Два запроса с одним токеном из городов >500 км за <30 мин	High
IP/ASN deviation	Токен выдан из корпоративного ASN, используется из VPN/proxy	Medium-High
Device fingerprint mismatch	User-Agent и характеристики устройства резко изменились	Medium-High
Velocity anomaly	100 API-запросов/мин при baseline 5 запросов/час	High
Refresh token reuse	Один refresh token использован дважды	Critical
User-Agent change	Переход с «Chrome/Windows» на «curl/GNU/Linux» для одного токена	Medium
Time-of-day anomaly	Доступ в 03:00 при baseline 09:00–18:00	Low-Medium

Refresh token reuse - сильнейший сигнал. По спецификации OAuth 2.0 refresh-токен одноразовый: при обмене на новый access token сервер выдаёт новый refresh token и инвалидирует старый. Повторное предъявление старого refresh-токена - однозначный IOC, требующий немедленного отзыва всего token family. Если видите это в логах - не разбирайтесь, сначала отзывайте.

Detection-чеклист: корреляционные правила для SOC​

Требования к окружению:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Защита от session hijacking: hardening конфигурации​

Конкретные настройки, которые можно передать разработчикам и devops прямо сейчас:

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600

• HttpOnly - cookie недоступен из JavaScript (document.cookie), блокирует XSS-вектор кражи
• Secure - cookie передаётся только по HTTPS
• SameSite=Strict - cookie не отправляется при cross-origin запросах, снижает CSRF-риски
• Max-Age=3600 - TTL сессии 1 час: чем короче lifetime, тем меньше окно для replay

Hardening-чеклист (пригоден для передачи разработчику):

1. Установить флаги HttpOnly, Secure, SameSite=Strict на все session cookie
2. TTL access-токенов: 5-15 минут для API, 1 час для веб-сессий
3. Whitelist алгоритмов JWT на стороне сервера: принимать только RS256 или ES256, игнорировать поле alg из токена
4. Секреты HMAC: минимум 256 бит (32 байта), криптографически случайные. Переход на RS256/ES256 устраняет brute-force вектор полностью
5. Ротация refresh-токенов: каждый обмен refresh-на-access выдаёт новый refresh и инвалидирует старый. При повторном предъявлении старого - отзыв всего token family
6. Invalidation при password change: все активные сессии и refresh-токены аннулируются немедленно
7. Token binding / Proof of Possession (PoP): привязка токена к криптоключу клиента (поддерживается в Azure AD Conditional Access через Token Protection)
8. Не хранить токены в localStorage / sessionStorage - использовать HttpOnly cookie или in-memory storage
9. Привязка сессии к fingerprint: хэш User-Agent + IP-подсеть (/24, не точный IP - учитывайте NAT и мобильные сети) сохраняется при создании сессии, при изменении - force re-auth

Большинство SOC-команд, с которыми я сталкиваюсь на red team проектах, закрывают brute-force и SQL injection - но не имеют ни одного корреляционного правила на impossible travel или refresh token reuse. Вся защита строится на предположении: если MFA пройден - пользователь легитимен. Это предположение разбивается в момент, когда cookie украден через инфостилер на скомпрометированном хосте внутри периметра.

В ближайший год token replay, по моим наблюдениям, станет основным вектором первоначального доступа к SaaS-инфраструктуре - обгонит классический фишинг. Причина проста: refresh-токены живут дни и недели, а инфостилеры продаются по модели MaaS за сотни долларов в месяц. Восемь техник MITRE ATT&CK из этой статьи - не абстрактная угроза, а конкретные TTP, которые прямо сейчас эксплуатируются в production. Если интересно, как другие SOC-команды строят behavioral detection для token replay под конкретные SIEM-стеки - на codeby.net коллеги разбирают подходы с готовыми порогами и Sigma-правилами.