Фишинг — самый частый способ начать атаку на компанию. Цель расследования письма — не просто сказать «это фишинг», а собрать индикаторы, понять путь атаки, подтвердить вредоносность и найти всех, кого это затронуло. Ниже — порядок, по которому я разбираю такие письма.

1. Первичная проверка письма

Ещё до технического анализа обычно видны признаки:

  • визуальные: искажённый логотип, кривая вёрстка, обезличенное обращение «Уважаемый клиент»;
  • социальная инженерия: срочность, кнопка «просмотреть документ», обещание посылки, счёта или штрафа;
  • адреса: совпадают ли домены в From, Return-Path и Reply-To с ожидаемым отправителем.

Дальше — заголовки письма (в почтовом клиенте «Показать оригинал» или «Исходный текст»):

  • SPF / DKIM / DMARC — результат проверки в Authentication-Results: кто реально отправил письмо и подписано ли оно доменом из From;
  • цепочка Received — снизу вверх: внешний IP отправителя и путь доставки.

2. Проверка отправителя

  • IP отправителя — в VirusTotal, AbuseIPDB, Cisco Talos, Spamhaus.
  • WHOIS и ASN — чей это хостинг или провайдер.
  • SPF fail для легитимного домена — сильный признак подделки отправителя.
  • DKIM отсутствует или подписан чужим доменом — фиксируем как сбой аутентификации.

3. Анализ ссылки — только в изоляции

Главное правило: не открывать ссылку с рабочей машины. Используйте песочницы и онлайн-сервисы:

  • urlscan.io — скриншот, редиректы, DOM, запросы страницы;
  • VirusTotal по URL;
  • Any.Run или аналогичная песочница;
  • отдельная виртуальная машина с браузером.

Что смотреть:

  • реальную цепочку редиректов — фишинговые страницы часто прячутся за несколькими сокращателями и «чистыми» доменами;
  • подставляется ли адрес жертвы в URL или форму — признак таргетированной рассылки;
  • куда уходят введённые данные. В DevTools на вкладке Network видно, на какой endpoint отправляется форма. Классика сбора учётных данных:
POST /post.php
status: 200
payload: email=...&password=...

4. OSINT по домену и инфраструктуре

  • WHOIS: регистратор и дата создания — домены, зарегистрированные несколько дней назад, подозрительны;
  • DNS: A, MX, NS-записи;
  • TLS-сертификат: кем выпущен, какие ещё домены в SAN;
  • IP: обратный DNS, открытые порты, соседние домены на том же IP — часто это целая фишинговая кампания;
  • история в urlscan — встречалась ли эта страница раньше и под какими доменами;
  • Censys и Shodan — баннеры, связанная инфраструктура, одинаковые сертификаты на других хостах.

5. Какие индикаторы сохранить

  • IP отправителя;
  • From, Return-Path, Reply-To;
  • фишинговый URL и вся цепочка редиректов;
  • домен страницы и IP хостинга;
  • endpoint, куда отправляются учётные данные;
  • хеши вложений, если они есть;
  • скриншоты письма и страницы;
  • результаты SPF / DKIM / DMARC.

6. Действия после подтверждения

  • Заблокировать домен, IP и URL на почтовом шлюзе, в DNS-фильтре, прокси или EDR.
  • Отправить индикаторы в SIEM и выполнить ретроспективный поиск: кому ещё пришло такое письмо, кто открыл ссылку.
  • Если учётные данные вводились — сбросить пароль, завершить все сессии и отозвать токены. Дальше — проверить почтовый ящик на правила пересылки (как это бывает, я разбирал в статье о взломе корпоративной почты).
  • Сообщить о фишинговой странице в Google Safe Browsing, Microsoft, регистратору и хостинг-провайдеру домена.
  • Предупредить сотрудников — коротким сообщением со скриншотом письма.

Полезные ресурсы

  • подборки OSINT-сервисов для проверки IP, доменов и email (например, коллекции на start.me);
  • репозиторий phishing_pot на GitHub — собрание реальных фишинговых писем для исследования и написания правил детектирования.

Коротко

  1. Заголовки и SPF/DKIM/DMARC — кто на самом деле отправил письмо.
  2. Ссылка — только в песочнице, ищем endpoint сбора данных.
  3. OSINT по инфраструктуре находит всю кампанию, а не одну страницу.
  4. Индикаторы — в блокировки и в SIEM для поиска остальных жертв.
  5. Пострадавшим — смена пароля, завершение сессий и проверка правил пересылки.