Взлом корпоративной почты: как мы расследовали инцидент в юридической фирме на 28 рабочих мест

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор компании АйТи Фреш. За все 15 лет, что я работаю с московскими офисами, мне пришлось разбираться с больше чем двумя десятками случаев взлома корпоративной почты. Представляете, почти каждый второй такой инцидент обходился клиенту в сумму от 800 тыс. до 4 млн рублей прямого ущерба! Сегодня я хочу поделиться реальным кейсом одной юридической фирмы, которая едва не лишилась 1.7 млн руб., переведя их мошенникам. Я расскажу вам шаг за шагом, как мы всего за 4 дня нашли слабое место, "залатали" его и настроили такую защиту, что уже больше года никаких повторных взломов не было.

С чего всё началось: звонок главбуха в субботу

Был январь 2026 года. Мне звонит главбух одной столичной юридической фирмы – у них 28 рабочих мест: 17 юристов и 11 сотрудников бэк-офиса. Её голос дрожит, она почти кричит: «Евгений, кажется, у нас большая проблема! Контрагент только что звонил, спрашивает, мы точно поменяли реквизиты на новые? Им пришло письмо от нашего юриста». Она и сама видела это письмо: оно пришло с ящика штатного юриста, было написано в его стиле, и тема касалась конкретного договора, который он вёл. Но внизу — таблица с «новыми реквизитами» под счёт на 1.7 млн руб.

А вот юрист, от имени которого якобы отправили письмо, в тот самый момент безмятежно отдыхал в Сочи и вообще не открывал почту уже три дня. Ну, вы понимаете, шансы на какую-то «случайность» сразу свелись к нулю. Я тут же, не теряя ни минуты, попросил всех сотрудников не заходить в почту со своих устройств и первым делом заблокировал автоматическую пересылку.

Первые 30 минут: останавливаем кровотечение

Когда я подозреваю, что почту скомпрометировали, моя главная задача — не бросаться сразу в расследование. Нет, сначала нужно остановить вывод денег. Расследование вполне может подождать часок, а вот транзакция, которая летит к мошенникам, точно нет. Вот что я сделал в первые полчаса:

1. Позвонил всем контрагентам, у которых были открытые счета на оплату от нашей фирмы за последние 7 дней (получился список из 9 человек). Попросил приостановить любые платежи и подтверждать реквизиты только звонком на известные номера.
2. Позвонил в обслуживающий банк фирмы и попросил оперативно проверить, не было ли исходящих платежей по «странным» реквизитам за последние 72 часа. Не было — успели вовремя.
3. Попросил айтишника на стороне клиента (был приходящий) сменить пароль администратора в Microsoft 365 и временно отключить вход на скомпрометированный ящик юриста.
4. Открыл личный ноутбук и зашёл в админ-консоль M365 под учёткой, которую для меня заранее сделал клиент с правами Global Reader (я всегда прошу её перед началом обслуживания именно для таких случаев).

И вот только после этого можно было глубоко выдохнуть и уже спокойно заняться собственно расследованием.

Откуда я начал копать: журнал входов

Знаете, какой самый важный "артефакт" в расследовании любого взлома почты, будь то Microsoft 365 или Яндекс 360? Это, конечно, Sign-in logs для M365 или журнал входов в Яндекс 360 для бизнеса. Эти логи показывают абсолютно каждую попытку входа – успешную или нет – со всеми деталями: IP-адресом, страной, типом клиента и протоколом. Это просто золотая жила информации!

Через PowerShell я сразу же выгрузил журнал входов по нужному ящику за последние 30 дней:

# Подключение к Microsoft Graph
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

# Выгрузка входов по конкретному пользователю
$user = "lawyer.petrov@firm.ru"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$user'" `
  -Top 500 | Select-Object CreatedDateTime, IpAddress, `
  @{N='Country';E={$_.Location.CountryOrRegion}}, `
  ClientAppUsed, AppDisplayName, `
  @{N='Status';E={$_.Status.ErrorCode}} | `
  Export-Csv signins.csv -NoTypeInformation

То, что я увидел в CSV-файле, заняло у меня ровно 8 секунд для понимания картины:

Юрист-то наш, который сейчас в Сочи (а он, к слову, туда не первый год ездит, я это хорошо знал), с ноутбука вообще не выходил. Это сразу дало мне понять: все эти «нидерландские» входы – дело рук атакующего. Причём он заходил по IMAP и SMTP AUTH – это такие устаревшие, legacy-протоколы аутентификации, которые в правильно настроенном M365 должны быть просто отключены. Дальше уже было, как говорится, дело техники.

Что атакующий успел сделать в почтовом ящике

Затем я выгрузил журнал почтовой активности, или mailbox audit log, за тот же период. Microsoft 365 по умолчанию записывает туда все действия с письмами, если, конечно, включён режим аудита. И, к моему приятному удивлению, у этого клиента он оказался включён! Спасибо предыдущему подрядчику, прямо выручил.

# Выгрузка mailbox audit log
Search-MailboxAuditLog -Identity $user `
  -StartDate (Get-Date).AddDays(-30) `
  -EndDate (Get-Date) `
  -ShowDetails | `
  Export-Csv mailbox_audit.csv -NoTypeInformation

Вот что я нашёл в логах за 5 дней присутствия атакующего в ящике:

• 5 января, 09:20 — создано правило входящей почты с условием «если письмо содержит слова реквизиты, счёт, оплата, банковск* — переместить в скрытую папку RSS Feeds и пометить как прочитанное». Цель: чтобы юрист не увидел ответных писем от контрагентов.
• 5 января, 09:25 — настроена автопереадресация всех входящих писем на внешний адрес petr.lawer.archive@gmail.com (подделан под имя реального юриста). Атакующий начал получать копии всей входящей корреспонденции в реальном времени.
• 5–8 января — атакующий читал старые письма, изучал стиль, термины, текущие сделки. Скачал 47 писем с вложениями (договоры, акты, спецификации).
• 9 января, 11:05 — отправлены 3 письма от имени юриста: одно на 1.7 млн (то самое, которое спалили) и два других на 380 тыс. и 540 тыс. рублей. Эти два мы тоже остановили звонками контрагентам.

Как именно атакующий получил пароль

Логи входов чётко показали: 5 января в 09:14 атакующий вошёл с правильным паролем, причём с первой же попытки. Никакого брутфорса, то есть подбора пароля, в логах за предыдущий период не было. Это означало одно: пароль он не подбирал, а получил уже готовым. Тут у меня было три основных варианта: фишинг, утечка из какого-то стороннего сервиса или заражение компьютера юриста стилером.

Я тут же связался с юристом (он в этот момент уже летел из Сочи) и попросил его напрячь память: не вводил ли он пароль на каких-нибудь сайтах из почты за последние недели? После пары уточняющих вопросов кое-что всплыло: 4 января в 18:40 ему пришло письмо «от Microsoft» с пугающей темой «Срочно: ваш ящик будет удалён через 24 часа». А внутри письма красовалась кнопка «Подтвердить аккаунт», ведущая на сайт microsoft-365-verify.com. Кстати, домен этот был зарегистрирован всего за день до атаки, 3 января. Юрист, конечно, пароль ввёл.

Это был классический фишинг через reverse-proxy. Такие хитрецы не просто воруют пароль; они в реальном времени проксируют его к настоящему Microsoft, по пути перехватывают сессионную cookie и таким образом обходят даже двухфакторку, если она включена. А у нашего клиента 2FA на этом конкретном ящике как раз была отключена – "для удобства", чтобы каждый раз не вводить код с телефона. Вот это-то и сыграло на руку мошенникам.

# Проверка домена через whois (что я сделал на месте)
$ whois microsoft-365-verify.com | grep -E "Created|Registrar"
Creation Date: 2026-01-03T14:22:18Z
Registrar: NameCheap, Inc.

# Возраст домена 1 день — индикатор фишинга
# Домены Microsoft не регистрируются через NameCheap

4 дня работы: что мы сделали для восстановления

Расследование заняло у меня 6 часов. Дальше начался гораздо больший объём работ — закрытие дыр и приведение почтовой инфраструктуры в порядок. Вот что мы сделали за 4 рабочих дня командой из 3 инженеров АйТи Фреш:

День 1: экстренная защита

• Принудительно сбросили пароли всем 28 пользователям в Microsoft 365 (через Admin Center → Active Users → Multiple users → Reset password). Юзерам по чату разослали временные пароли с обязательной сменой при следующем входе.
• Принудительно завершили все активные сессии: Revoke-MgUserSignInSession -UserId <id> для каждого пользователя. Это инвалидирует украденные сессионные cookies — даже если у атакующего они есть, войти он больше не сможет.
• Удалили правила пересылки во всех ящиках:

# Поиск всех правил автопересылки наружу домена
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.Identity | Where-Object {
        $_.ForwardTo -or $_.ForwardAsAttachmentTo -or `
        $_.RedirectTo
    } | Select-Object MailboxOwnerId, Name, ForwardTo, `
        RedirectTo, Enabled
} | Export-Csv suspicious_rules.csv -NoTypeInformation

Нашли правила пересылки ещё в двух ящиках (бухгалтер и помощница директора). Их атаковали раньше, но активной фазы не было — просто сидели и собирали информацию. Удалили все.

День 2: включаем 2FA на всех

Мы включили двухфакторку по приложению Microsoft Authenticator (или Yandex Key для Яндекс 360) у всех 28 пользователей, без единого исключения. И никаких вам «исключений для удобства руководства»! Потому что именно через такие вот послабления и случается большинство взломов.

# Политика Conditional Access (через Azure AD)
Display name: Require MFA for all users
Assignments:
  Users: All users (exclude: emergency break-glass account)
  Cloud apps: All cloud apps
  Conditions:
    Locations: Any location
    Client apps: All
Access controls:
  Grant: Require multi-factor authentication
  Require authentication strength: Phishing-resistant MFA

Дополнительно для главбуха и директора — обязательный аппаратный ключ FIDO2 (YubiKey 5C NFC, по 6 800 руб. за штуку). На VIP-юзеров с правом подписи платёжных поручений я всегда настаиваю на железных ключах — это единственный фактор, который полностью защищает от фишинга через reverse-proxy.

День 3: блокируем legacy-протоколы и автопереадресацию

Атакующий, как мы выяснили, заходил по IMAP и SMTP AUTH – это уже совсем устаревшие протоколы, которые просто не умеют в современную аутентификацию. Их нужно вырубить полностью! Конечно, если только у вас не завалялось какого-нибудь древнего МФУ или сканера, который, кроме IMAP, ничего другого не понимает.

# Отключение legacy authentication через Authentication Policy
New-AuthenticationPolicy -Name "Block Legacy Auth"

Set-AuthenticationPolicy -Identity "Block Legacy Auth" `
  -AllowBasicAuthImap:$false `
  -AllowBasicAuthPop:$false `
  -AllowBasicAuthSmtp:$false `
  -AllowBasicAuthAutodiscover:$false `
  -AllowBasicAuthActiveSync:$false `
  -AllowBasicAuthOfflineAddressBook:$false `
  -AllowBasicAuthOutlookService:$false `
  -AllowBasicAuthPowerShell:$false

# Применение ко всем пользователям
Get-User -ResultSize Unlimited | Set-User `
  -AuthenticationPolicy "Block Legacy Auth"

Дополнительно — глобальный запрет автоматической переадресации почты наружу домена через политику Outbound Spam Filter:

# Запрет автопересылки наружу
Set-HostedOutboundSpamFilterPolicy -Identity Default `
  -AutoForwardingMode Off

После этого даже если кто-то снова взломает ящик — он не сможет настроить пересылку наружу домена. Это буквально одна команда, которая могла бы предотвратить весь инцидент.

День 4: SPF, DKIM, DMARC и обучение сотрудников

DNS-записи домена клиента я проверил через свой любимый mxtoolbox.com:

• SPF — был, но в режиме ~all (мягкий fail). Меняю на -all (жёсткий fail).
• DKIM — не настроен вообще. Включаю в M365: Security → Email & collaboration → Policies → DKIM, генерация ключа, добавление двух CNAME-записей в DNS.
• DMARC — отсутствует. Добавляю TXT-запись:

; DNS-записи для домена firm.ru
firm.ru. TXT "v=spf1 include:spf.protection.outlook.com -all"

selector1._domainkey.firm.ru. CNAME selector1-firm-ru._domainkey.tenant.onmicrosoft.com
selector2._domainkey.firm.ru. CNAME selector2-firm-ru._domainkey.tenant.onmicrosoft.com

_dmarc.firm.ru. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@firm.ru; ruf=mailto:dmarc@firm.ru; fo=1; pct=100"

Через две недели после прогрева в режиме p=quarantine переключили DMARC в строгий p=reject. С этого момента подделать письмо «от» firm.ru у атакующего не получится — все нормальные провайдеры (Mail.ru, Яндекс, Gmail) будут отклонять подделки на этапе SMTP.

Параллельно со всеми этими техническими делами я провёл с сотрудниками часовой воркшоп. Я прямо показал им, как выглядит типичное фишинговое письмо, объяснил, как проверять отправителя, как смотреть, куда ведёт ссылка (главное – наводим, но не кликаем!), и что делать, если пароль всё-таки ввели на подозрительном сайте (немедленно сменить и сообщить в АйТи Фреш). В конце раздал памятку на одну страницу – она, кстати, до сих пор висит у каждого над монитором.

Что важно знать руководителю про BEC-атаки

BEC, или Business Email Compromise, – это, поверьте, совсем не редкость. По нашей статистике, в Москве в 2025 году каждая шестая фирма среди наших клиентов с офисом до 50 РМ хотя бы раз сталкивалась с попыткой BEC. А каждая 18-я фирма несла финансовый ущерб от 200 тыс. руб. и выше. Вот что стоит знать про это:

• Атакующие выбирают цель целенаправленно. Это не массовая рассылка. Перед атакой собираются данные о компании, изучаются открытые источники (сайт, СПАРК, соцсети сотрудников). Часто атакуют через 2–3 недели после того, как кто-то засветился в утечке (например, паролей с какого-нибудь форума).
• Атакующие ждут отпуска или командировки. Идеальное окно — когда сотрудник физически недоступен по корпоративной связи. Поэтому правила автопереадресации настраиваются в выходные или вечером.
• Сумма платежа подбирается так, чтобы не вызывать подозрения. 1.7 млн руб. — это нормальная сумма для юрфирмы, никто не насторожится. Если бы атакующий запросил 50 млн — главбух сразу бы перезвонила.
• Реквизиты «новые» — обычно счёт в каком-нибудь среднем банке РФ на ИП или ООО-однодневку. Деньги через 2–4 часа уходят цепочкой переводов и обналичиваются. После этого вернуть их невозможно.

Чек-лист защиты почты для офиса 10–50 РМ

Если у вас офис до 50 рабочих мест и вы пользуетесь Microsoft 365, Яндекс 360 или Mail.ru для бизнеса, то вот мой минимальный чек-лист. Он, кстати, закрывает 95% BEC-атак:

1. Двухфакторная аутентификация по приложению — у всех 100% пользователей. Без исключений.
2. Аппаратные ключи FIDO2 — у директора, главбуха, всех с правом подписи платежей.
3. Legacy-протоколы (IMAP, POP, SMTP AUTH с базовой аутентификацией) — отключены глобально.
4. Автопереадресация наружу домена — запрещена политикой.
5. SPF, DKIM, DMARC — настроены, DMARC в режиме p=reject.
6. Audit log включён, ретенция — минимум 90 дней (платно в M365 Business Standard).
7. Алерт на необычный геолоку входа — настроен в Microsoft Defender или Conditional Access.
8. Регламент платежей: новые реквизиты подтверждаются звонком на известный номер контрагента, не по почте.
9. Раз в полгода — тренинг сотрудников по фишингу и тестовая фишинг-рассылка для проверки бдительности.
10. Бэкап почты раз в сутки во внешнюю систему (Veeam, Acronis или Synology Active Backup) — на случай, если атакующий начнёт удалять письма.

Стоимость защиты vs стоимость инцидента

Расскажу вам честно про экономику. Мы в АйТи Фреш предлагаем разовую настройку всего комплекса защиты для офиса до 30 пользователей по цене от 18 000 до 35 000 руб. – тут всё зависит от того, в каком состоянии находится стартовая инфраструктура. А дальше идёт абонентская плата за мониторинг всех необычных входов – от 4 500 руб./мес. Если говорить про аппаратные ключи FIDO2 для VIP-пользователей, то это 6 800 руб. за штуку, и обычно на офис нужно 3–5 таких ключей.

А теперь давайте сравним эти цифры с тем, что "висело" над нашим юристом, чей платёж мы остановили буквально в последнюю секунду. Ущерб мог бы составить до 1.7 млн руб.! Плюс к этому – серьёзный репутационный удар по контрагенту (он бы потом начал параноить и перепроверять каждый наш платёж), да ещё и куча времени, потраченного на разбирательства. По нашей внутренней статистике, средний BEC-ущерб для офиса до 50 РМ составляет 1.4 млн руб. за один инцидент. Так что, как видите, защита окупается одним предотвращённым случаем на 5+ лет вперёд!

FAQ — частые вопросы про взлом корпоративной почты

Как понять, что корпоративную почту взломали?

Главные признаки: контрагенты получают письма, которые вы не отправляли; в папке «Отправленные» появляются неизвестные сообщения; в логах входов виден логин из чужой страны; контрагенты переводят деньги по «новым» реквизитам, которые вы не присылали. Если что-то из этого есть — почта скомпрометирована, надо срочно действовать.

Сколько стоит расследование инцидента с почтой?

Базовое расследование одного скомпрометированного ящика в Microsoft 365 или Яндекс 360 — от 35 000 руб. за 2–3 дня работы. Полный аудит всего почтового домена с восстановлением безопасности — 90–180 тыс. руб. в зависимости от размера офиса. Для клиентов на абонентке расследование входит в SLA.

Почему пароль из 16 символов не помог?

Длинный пароль защищает от перебора, но не от фишинга. Если сотрудник ввёл пароль на поддельной странице входа, длина не имеет значения. Единственная надёжная защита — двухфакторная аутентификация через приложение или аппаратный ключ. SMS как второй фактор тоже взламывается через подмену SIM-карты, поэтому я её не рекомендую для VIP-юзеров.

Можно ли вернуть деньги, переведённые по поддельным реквизитам?

Если успели обратиться в банк в тот же день — иногда удаётся приостановить платёж до зачисления. Если деньги ушли больше суток назад — практически нет, так как мошенники сразу выводят средства цепочкой переводов и обналичивают. Заявление в полицию по статье 159.6 УК РФ подавать обязательно, но шансы возврата мизерные. Лучше вкладываться в превентивную защиту.

Как защитить почту в офисе на 20–30 человек?

Минимальный набор: двухфакторная аутентификация для всех; запрет автопереадресации наружу домена; настройка SPF, DKIM, DMARC в строгом режиме; регулярные тренинги сотрудников по фишингу; журналирование всех входов с алертами на подозрительные геолокации; аппаратные ключи FIDO2 для всех с правом подписи платежей. Этот пакет в АйТи Фреш разворачивается за 2–3 дня и стоит 18 000–35 000 руб. для офиса до 30 ящиков.