Криминалистика электронной почты

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

Заголовки письма (email headers) — служебные поля над телом сообщения: они фиксируют маршрут доставки (Received), технический адрес отправителя (Return-Path) и результаты проверок подлинности (SPF/DKIM/DMARC). По ним определяют, откуда письмо пришло на самом деле и не подделан ли отправитель.

Этот урок — про разбор писем при расследовании фишинга и компрометации почты. Анализируем сообщения, которые получили мы или наша организация: жалобы пользователей, подозрительные письма, инциденты. Чтение чужой переписки без полномочий — нарушение тайны связи (ст. 138 УК РФ); расследователь работает со своими ящиками и письмами, переданными ему правомерно.

Зачем это знать защитнику

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

Анатомия заголовков и путь доставки

Поля Received: маршрут письма

Каждый почтовый сервер на пути добавляет сверху свой Received-заголовок. Поэтому маршрут читается снизу вверх: нижний Received — самый ранний (где письмо появилось), верхний — последний (ваш сервер). Это позволяет проследить реальный путь и заметить, что письмо «от банка» на деле пришло с постороннего хоста.

Received: from mx.ваш-домен (last hop)        ← читать ПОСЛЕДНИМ
Received: from relay.example.net [198.51.100.7]
Received: from unknown [203.0.113.99]          ← читать ПЕРВЫМ (источник)
Return-Path: <[email protected]>
From: "Банк" <[email protected]>
Authentication-Results: spf=fail dkim=none dmarc=fail

Здесь видимый From выдаёт себя за банк, но источник — посторонний IP, Return-Path ведёт на чужой хост, а проверки подлинности провалены. Это учебный пример подделки.

From, Return-Path, Reply-To

Важно различать три «адреса». From — то, что видит человек (легко подделывается). Return-Path — технический адрес для возвратов, заданный при отправке. Reply-To — куда уйдёт ответ. Любимый приём фишинга — показать в From знакомое имя, а Reply-To увести на адрес атакующего, чтобы перехватить переписку.

Подделка отправителя и проверки подлинности

Сам протокол SMTP не проверяет, что вы — тот, кем подписались: поле From можно поставить любое (email spoofing). Чтобы это ловить, поверх почты работают три механизма:

  • SPF — DNS-запись домена со списком серверов, которым разрешено слать почту от его имени. Получатель сверяет IP отправителя со списком: пришло не с того сервера → spf=fail.
  • DKIM — криптографическая подпись письма ключом домена. Получатель проверяет подпись публичным ключом из DNS: подделали содержимое или отправили без ключа → подпись не сходится.
  • DMARC — политика, связывающая SPF/DKIM с видимым доменом From и говорящая, что делать при провале (пропустить/в карантин/отклонить), плюс отчёты владельцу домена.

Для аналитика строка Authentication-Results — быстрый детектор: dmarc=fail при том, что письмо якобы от вашего домена, — почти наверняка подделка. Но и обратное верно: проверки могут пройти, если атакующий захватил настоящий ящик, — тогда тревога в другом (нетипичное поведение, странная просьба).

Вложения и ссылки

Вложение — частый носитель полезной нагрузки. Криминалистический разбор: снять хеш файла и проверить репутацию по хешу; смотреть реальный тип, а не расширение (документ с макросом, контейнер с исполняемым внутри, двойное расширение invoice.pdf.exe); открывать только в изолированной песочнице. Ссылки проверяют, не кликая: наводят на реальный URL (видимый текст часто не равен адресу), разворачивают сокращатели, ищут типосквоттинг домена (bank-secure.example вместо настоящего). Это прямой источник IOC: адреса отправителей, хеши вложений, домены ссылок идут в блок-листы и в поиск по логам — «кому ещё пришло то же письмо».

Как это работает под капотом

Письмо — это текст в формате MIME: служебные заголовки сверху, затем тело и закодированные (обычно base64) вложения. При пересылке между серверами по SMTP каждый принимающий узел дописывает свой Received поверх существующих — так формируется упорядоченная история транзита (новые записи сверху, поэтому читаем снизу вверх). SPF реализован как DNS-запрос TXT к домену отправителя и сравнение исходного IP со списком; DKIM — как подпись выбранных заголовков и тела закрытым ключом, проверяемая публичным ключом из DNS; DMARC — как ещё одна DNS-запись с политикой и требованием «выравнивания» проверенного домена с видимым From. Ключевой нюанс: заголовки From/Reply-To формирует отправляющая сторона и доверять им нельзя, а вот Received вашего сервера и результаты SPF/DKIM/DMARC добавляет ваша инфраструктура — это и есть надёжная часть доказательства.

Как защититься

1. Настройте SPF, DKIM и DMARC для своего домена. С политикой DMARC в режиме отклонения злоумышленнику гораздо труднее слать письма от вашего имени, а вы получаете отчёты о попытках.

2. Учите читать заголовки и обучайте пользователей. Аналитик смотрит Received/Authentication-Results, а сотрудники — на расхождение имени и адреса, неожиданные просьбы и срочность. Простая кнопка «сообщить о фишинге» ускоряет реакцию.

3. Изолируйте вложения и ссылки. Песочница для вложений, переписывание ссылок с проверкой репутации, блокировка опасных типов (исполняемые, макросы) на шлюзе.

4. Превращайте письмо в IOC и ищите веер рассылки. По адресу отправителя, хешу вложения и домену ссылки находите всех получателей и блокируете кампанию целиком, а не одно письмо.

5. Работайте легально. Расследуйте только свои ящики и письма, переданные правомерно; доступ к чужой переписке без полномочий — ст. 138 УК РФ.

Итоги

  • Видимое From легко подделать (spoofing); реальный путь письма показывают заголовки Received, читаемые снизу вверх.
  • Различайте From (для глаз), Return-Path (для возвратов) и Reply-To (куда уйдёт ответ) — подмена Reply-To перехватывает переписку.
  • SPF/DKIM/DMARC и строка Authentication-Results — быстрый детектор подделки отправителя.
  • Вложения и ссылки проверяют не запуская и не кликая: хеш+репутация, реальный тип файла, реальный URL и типосквоттинг.
  • Письмо — источник IOC (адрес, хеш, домен) для блокировки всей фишинговой кампании; чужую переписку без полномочий читать нельзя (ст. 138 УК РФ).
Проверьте себя
1. В каком порядке читаются заголовки Received, чтобы восстановить путь письма?
AСнизу вверх: нижний Received — самый ранний (источник), верхний — последний (ваш сервер)
BСверху вниз: верхний Received — это источник письма
CПорядок не имеет значения, все Received равнозначны
DТолько по полю From, заголовки Received не используются
2. Почему полю From нельзя доверять как доказательству, а результатам SPF/DKIM/DMARC можно?
AFrom задаёт отправляющая сторона и может поставить любое значение, а проверки подлинности и Received добавляет ваша инфраструктура
BFrom шифруется и поэтому всегда подлинно
CSPF/DKIM/DMARC задаёт сам отправитель письма
DFrom проверяется протоколом SMTP при каждой отправке
3. Что является корректным криминалистическим действием с подозрительным вложением из фишингового письма?
AСнять хеш и проверить репутацию по хешу, определить реальный тип файла, открывать только в изолированной песочнице
BСразу открыть его двойным кликом, чтобы посмотреть содержимое
CДоверять расширению файла как точному признаку его типа
DПереслать вложение всем коллегам для коллективной оценки