«Если фишинг идёт с твоего домена, дело уже не в отдельных уязвимостях, а в системном сбое контроля над основным цифровым активом. Проблему решают не только хакерские инструменты, но и чёткие процедуры, о которых обычно вспоминают, когда уже поздно».
Ситуация: почта идёт, но это не вы
Клиенты начинают присылать скриншоты писем с просьбой «подтвердить платёжные реквизиты» или «срочно обновить учётную запись». Статистика ваших легитимных рассылок чиста, антиспам-фильтры молчат, но поток обращений растёт. Письма оформлены под ваш бренд, содержат ссылки на фишинговые страницы и приходят с вашего доменного имени.
Важно понимать: злоумышленникам не всегда нужен доступ к вашему почтовому ящику. Чаще используются векторы, обходящие централизованную защиту: подделка отправителя через SMTP (спуфинг), компрометация устаревшей формы обратной связи на сайте или взлом аккаунта в стороннем сервисе email-маркетинга, подключённого к домену. Угроза здесь — не единичная утечка данных, а подрыв доверия к любому сообщению, приходящему от вашего имени.
Первые 30 минут: экстренное реагирование
Цель — быстро сдержать распространение фишинга и собрать технические улики. Действия должны быть последовательными, а не хаотичными.
1. Фиксация доказательств
Запросите у нескольких доверенных контактов пересланные фишинговые письма с полными заголовками (headers). Не открывайте вложения и не кликайте по ссылкам из этих писем напрямую. Сохраните оригиналы в формате .eml — они содержат служебную информацию об IP-отправителе, пути прохождения и будут ключевыми для дальнейшего анализа или обращения к хостинг-провайдерам.
2. Срочная проверка DNS-записей домена
Злоумышленники могли модифицировать DNS для облегчения рассылки или перенаправления жертв. Проверьте записи у регистратора или на DNS-хостинге.
| Тип записи | Что проверить | Риск |
|---|---|---|
| SPF (TXT-запись) | Отсутствие лишних IP-адресов, include:*, слишком широких диапазонов | Разрешение на отправку почты с неавторизованных серверов |
| DKIM | Целостность и актуальность публичных ключей | Возможность подписывать письма от вашего имени |
| DMARC (TXT-запись) | Политика (p=) должна быть как минимум quarantine, а не none | Отсутствие реакций почтовых систем на спуфинг |
| MX | Не появились ли подозрительные серверы | Потенциальный перехват входящей почты |
| A / CNAME | Наличие новых, незнакомых поддоменов | Хостинг фишинговых landing page на вашем домене |
3. Локализация и блокировка источника
Если рассылка идёт через скомпрометированный аккаунт в вашей почтовой системе или сервисе рассылок (например, аккаунт поддержки с правами на массовую отправку), немедленно изолируйте его: смените пароль, отзовите все сессии и API-токены. Если установлен вектор спуфинга со сторонних IP-адресов, внесите их в чёрный список на почтовом сервере и подготовьте данные для жалоб хостинг-провайдерам.
Первые сутки: публичное информирование и техническое расследование
В ситуации с фишингом тишина трактуется как бездействие или даже соучастие. Аудитория должна получить чёткий сигнал от вас.
1. Официальное заявление
Опубликуйте краткое сообщение на главной странице сайта, в официальных блогах и соцсетях. Отправьте уведомление через проверенный канал (например, внутреннюю систему оповещений). В тексте важно:
- Подтвердить факт инцидента и заявить о работе по его устранению.
- Чётко сформулировать, какие действия вы никогда не запрашиваете по почте (перевод денег, отправку паролей, установку ПО).
- Указать, с каких адресов и доменов приходит легитимная почта.
- Дать контакт для пересылки подозрительных писем.
Избегайте технических деталей взлома на этом этапе.
2. Немедленное усиление аутентификации почты
Настройка или аудит трёх ключевых DNS-записей снижает успешность спуфинга, помечая такие письма как неавторизованные у большинства почтовых провайдеров.
- SPF (Sender Policy Framework): Чётко определите список IP-адресов и серверов, которые могут отправлять почту от вашего домена. Используйте директиву -all для жёсткого запрета всех остальных.
- DKIM (DomainKeys Identified Mail): Настройте цифровую подпись для исходящих писем. Это криптографически подтверждает, что письмо не было изменено и отправлено с авторизованного источника.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Установите политику (например, p=quarantine или p=reject), которая предписывает получателям, что делать с письмами, не прошедшими проверки SPF/DKIM. Главное — включите отчётность (rua=), чтобы получать сводки о попытках отправки от вашего имени.
Неделя и месяц: системный аудит и предотвращение рецидивов
После нейтрализации угрозы необходим анализ первопричин. Фишинг с домена — часто симптом более глубоких проблем управления.
1. Глубокий аудит систем и доступа
- Учётные записи и доступы: Проведите ревизию учётных записей во всех связанных системах (хостинг, DNS-панель, CRM, сервисы рассылок). Удалите неактивные аккаунты, везде, где возможно, включите двухфакторную аутентификацию (2FA). Особое внимание — учёткам с привилегиями на рассылку.
- Веб-активы: Просканируйте все сайты на домене и субдоменах на наличие инжектированного кода, особенно в формах отправки данных. Обновите CMS, плагины и библиотеки. Фишинговые данные могли быть собраны через уязвимость на одном из сайтов.
- Сторонние интеграции: Составьте реестр всех внешних скриптов, виджетов и сервисов, загружаемых с ваших страниц. Их компрометация может стать косвенным вектором для сбора email-баз.
2. Внедрение проактивного мониторинга
Цель — узнать о следующей попытке атаки раньше ваших клиентов.
- Анализ DMARC-отчётов: Настройте сбор агрегированных (RUA) и детальных (RUF) отчётов DMARC. Это даёт полную картину о том, кто и откуда пытается отправлять почту от вашего имени. Для анализа можно использовать доступные агрегаторы или парсить отчёты самостоятельно.
- Мониторинг изменений DNS: Используйте сервисы или скрипты, которые отслеживают изменения критических записей (MX, NS, SPF, DMARC) и отправляют алерты. Неожиданное изменение SPF — прямой признак атаки.
- Мониторинг упоминаний бренда: Настройте оповещения о появлении новых страниц или доменов, включающих ваше доменное имя, особенно в сочетании с типичными фишинговыми словами («login», «verify», «secure»).
3. Ревизия и документирование процедур реагирования
На основе произошедшего инцидента создайте или обновите внутренний план реагирования (IRP). Он должен включать:
- Ролевую модель: контакты ответственных лиц (технические, PR, юридические).
- Чек-листы для первых 30 минут и первых суток.
- Шаблоны коммуникаций для пользователей и партнёров.
- Процедуру сбора и хранения доказательств.
Проведите пост мортем-анализ с командой. Разберите, какие действия сработали, где были задержки, какие инструменты не были под рукой. Такая практика превращает единичный инцидент в системное улучшение безопасности.
Фишинг с вашего домена, это не хакерская атака, это управленческий сбой
Успешная рассылка фишинга от вашего имени указывает на пробелы в базовых практиках: слабый контроль над DNS, отсутствие мониторинга почтовой аутентификации, устаревшие веб-активы с уязвимостями. Реагирование поэтому должно быть двухуровневым: немедленное подавление для сохранения операционной деятельности и доверия, а затем — системная работа по аудиту всех точек входа и ужесточению политик. Ключевой показатель успеха — когда следующую попытку спуфинга вы блокируете автоматически, получив DMARC-отчёт, и ни одно такое письмо не дойдёт до конечного пользователя.