Отправка фишинга себе: что остаётся от защиты почты

«Защита почты, это не стена, а набор дверей с разными замками. Большинство этих замков работают на доверии к тому, кто стучится. Если вы стучитесь в свою же дверь, все эти замки автоматически открываются, и остаётся лишь последний — механический. Эксперимент с отправкой письма себе показывает, что этот последний замок часто проще, чем кажется, и на что на самом деле стоит полагаться.»

Правовой статус: пентест, а не атака

Отправка фишингового письма на собственный адрес в контролируемой среде, это легитимная проверка систем защиты. Ключевое отличие от нарушения — отсутствие умысла обмануть или причинить вред третьим лицам, а также направленность действия на собственную инфраструктуру. Вы не используете чужие ресурсы, не обходите внешние системы контроля. Ваша цель — исследовать логику работы внутренних фильтров в условиях, когда они лишены внешних подсказок, таких как плохая репутация отправителя. Это методология, схожая с тестированием на проникновение, но сосредоточенная на каналах связи.

Архитектура почтовой защиты и что выключается в эксперименте

Современный почтовый фильтр — многослойный механизм, где каждый слой предназначен для отсева конкретных классов угроз. Когда письмо идёт от вас к вам через ваш же сервер, несколько ключевых слоёв автоматически пропускают его.

• Аутентификация отправителя (SPF, DKIM, DMARC). Это не фильтры содержания, а системы проверки легитимности домена. SPF сверяет IP-адрес отправителя с записями DNS вашего домена и, естественно, выдаёт результат pass. DKIM проверяет криптографическую подпись письма, которая в вашем случае будет валидной. DMARC, политика обработки неаутентифицированных писем, просто не применяется, так как проверки успешны. Этот этап превращается из барьера в формальность.
• Репутационные фильтры (RBL/DNSBL). Эти системы проверяют, не числится ли IP-адрес или домен отправителя в публичных или приватных чёрных списках. Поскольку вы отправляете письмо с сервера, не замеченного в массовых рассылках, репутационный фильтр также не срабатывает. Он попросту не имеет оснований для блокировки.
• Анализ содержимого. Единственный слой, который остаётся активным. Именно здесь фильтр анализирует текст, заголовки, ссылки и вложения, применяя эвристические правила, сигнатурные базы и, всё чаще, алгоритмы машинного обучения. Этот слой и есть объект исследования — он должен распознать угрозу по её сути, а не по контексту отправки.

эксперимент искусственно создаёт условия «чистой атаки»: письмо от легитимного источника с потенциально вредоносным содержимым. Это именно тот сценарий, который используют для целевого фишинга.

Подготовка изолированного стенда

Для получения чистых результатов и соблюдения безопасности критически важно проводить тест не в рабочей почтовой системе, а в специально развёрнутом окружении.

Настройка тестовой почтовой инфраструктуры

Вам потребуется контролируемый домен и почтовый сервер. Это можно сделать даже на локальной виртуальной машине.

1. Домен. Зарегистрируйте новый домен (например, test-example.ru) или создайте поддомен на уже существующем (lab.yourcompany.ru).
2. Почтовый сервер. Установите и настройте почтовый сервер, например Postfix или Exim, или воспользуйтесь функционалом вашего хостинга. Главное — иметь возможность отправлять и принимать почту для созданных ящиков.
3. Учётные записи. Создайте два ящика на вашем домене: attacker@test-example.ru и victim@test-example.ru.

Создание безопасного фишингового письма

Письмо должно максимально имитировать реальную угрозу, но не представлять никакой опасности.

• Тема. Используйте триггерные формулировки: «Срочное уведомление от службы безопасности», «Требуется верификация вашего аккаунта», «Ваша подписка истекает».
• Отправитель. Подделайте поле «От имени» (From), указав, к примеру, security@b4nk-site.ru, в то время как реальный адрес отправителя в заголовках будет ваш attacker@test-example.ru. Это проверяет, насколько фильтр полагается на видимые данные, а не на техническую аутентификацию.
• Тело письма. Воспроизведите стиль известного сервиса (банка, облачного провайдера). Включите «логичную» причину для действий, элемент срочности. Замените все реальные ссылки на адреса в вашей тестовой сети (например, http://192.168.100.1/check) или на страницу-заглушку на вашем тестовом домене.
• Вложение. Для проверки файловых фильтров создайте пустой текстовый файл и переименуйте его в Выписка_по_счету.pdf.js или Документ.scr. Многие фильтры анализируют MIME-тип и реальное содержимое, но некоторые до сих пор полагаются на расширение в имени файла.

Инструменты отправки и анализ доставки

Для отправки лучше использовать инструменты, дающие полный контроль над заголовками.

• Swaks — универсальная консольная утилита для работы с SMTP. Позволяет тонко настраивать все аспекты письма.

  swaks --to victim@test-example.ru --from attacker@test-example.ru --h-From: 'Служба Безопасности ' --server mail.test-example.ru --body 'Перейдите по ссылке для проверки.' --add-header 'Subject: Требуется немедленное действие'

• Python с smtplib предоставляет максимальную гибкость для создания сложных писем с кастомными заголовками.

После отправки ключевой этап — определить, где оказалось письмо и как его классифицировала система.

1. Входящие. Письмо в папке входящих означает, что контентный фильтр либо не обнаружил угрозы, либо его порог срабатывания слишком высок.
2. Спам. Письмо в папке спама, это частичный успех фильтра. Нужно проанализировать, что именно вызвало срабатывание.
3. Полное блокирование. Письмо может быть отвергнуто на этапе приёма SMTP-сервером или помещено в карантин, недоступный пользователю. Это наиболее строгий сценарий.

Диагностика: чтение служебных заголовков

Основная диагностическая информация содержится в исходном коде письма (опция «Показать оригинал» в веб-интерфейсе или клиенте).

Ищите заголовки, добавленные серверами на пути доставки и антиспам-системами:

Заголовок	Значение	Что показывает
X-Spam-Flag	YES / NO	Прямой вердикт системы.
X-Spam-Score	Число (например, 6.8)	Суммарный «вес» всех триггеров. Показывает, насколько письмо было близко к порогу.
X-Spam-Report	Текст	Подробный отчёт: какие правила сработали и сколько баллов дали (например, «HTML_MESSAGE 0.5», «FAKE_REPLY_TO 1.2»).
Authentication-Results	spf=pass dkim=pass dmarc=pass	Результаты проверки подлинности. В вашем эксперименте здесь всегда будет «pass».
Received-SPF	Pass	Подробности проверки SPF.

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

Практические выводы для защиты

Этот эксперимент снимает иллюзию абсолютной надёжности автоматических систем.

• Уязвимость к целевым атакам подтверждается. Если злоумышленник компрометирует легитимный почтовый ящик или домен (через подделку или взлом), его письмо будет иметь безупречные технические заголовки. В этом случае вся нагрузка ложится на контентный фильтр, который часто можно обойти, избегая самых очевидных триггеров.
• Техническая грамотность становится критической. Умение сотрудника открыть исходный код письма и проверить несоответствие между полем From: и заголовками Authentication-Results — более надёжная защита, чем слепое доверие к фильтру. Обучение должно включать практику чтения этих метаданных.
• Необходимость многослойной защиты. Помимо встроенных фильтров почтового сервера, стоит рассмотреть дополнительные решения: шлюзы безопасности почты с более глубоким анализом ссылок (санбоксинг) и вложений, системы классификации писем на основе машинного обучения, строгие политики DMARC с параметром p=reject для неаутентифицированных писем с вашего домена.

Эксперимент превращает абстрактную «защиту от спама» в набор конкретных, проверяемых механизмов. Он показывает, какие из этих механизмов отключаются в условиях целевой атаки, и заставляет строить защиту с расчётом на то, что первый, второй и даже третий рубеж могут быть нейтрализованы.