КиберЩит
Фальсификация корпоративной почты: какие журналы сохранять для суда
📋 Кратко
Скриншот, папка «Отправленные» и один файл письма редко подтверждают факт отправки и авторство. Для российского суда и внутреннего расследования нужна связка данных: исходное письмо, полные заголовки, серверные журналы, сведения о входах, правилах пересылки и действиях администраторов. В статье показано, что сохранять сразу и как не разрушить цифровой след.
Корпоративная почта часто становится доказательством деловой переписки. Она фиксирует документы, обещания и решения сторон. Но письмо в ящике не всегда показывает, кто его создал и отправил.
Проблема возникает в нескольких сценариях. Злоумышленник меняет файл в почтовом клиенте. Он подставляет чужой адрес отправителя. Он использует скомпрометированную учетную запись. Наконец, он меняет локальный архив и показывает его как оригинал.
Для суда важен не один артефакт. Нужна согласованная картина событий. В ней письмо связано с сервером отправителя, сервером получателя, учетной записью и временем.
Эта статья описывает практику для российского суда и внутреннего расследования. Она не обещает автоматическую допустимость конкретного журнала. Суд оценивает доказательства в совокупности, а при споре может назначить компьютерно-техническую экспертизу.
Что сделать сейчас: назначьте ответственного за сохранение данных и запретите удаление писем и журналов по спорному периоду.
🔍 Что именно считают фальсификацией письма
Подделка начинается не только с ручного редактирования текста. В почтовом клиенте письмо может выглядеть как обычное сообщение. При этом локальный файл уже изменён.
Старый сценарий связан с десктопным клиентом. Пользователь сохраняет письмо на диск. Затем меняет адресата, дату или текст. После этого он загружает файл обратно в клиент и делает скриншот.
Другой сценарий маскирует отправителя. В поле «От» показывается нужное имя. Оно не доказывает, что письмо отправляет именно этот человек.
Третий сценарий использует настоящую учетную запись. Злоумышленник входит в ящик после кражи пароля. Он отправляет письмо от имени владельца. В таком случае сервер действительно видит вход и отправку, но нужно установить, кто управлял учетной записью.
Отдельно рассматривайте изменение локального архива. Файл EML или MSG может быть копией сообщения. Сам формат не подтверждает неизменность файла и историю его создания.
Поэтому расследование разделяет пять вопросов:
- кто указан в видимом поле отправителя;
- какая учетная запись проходит аутентификацию;
- какой сервер принимает и передаёт сообщение;
- что получает сервер адресата;
- менялся ли локальный файл после получения.
Что сделать сейчас: в карточке инцидента укажите отдельный сценарий: подмена адреса, взлом учетной записи, изменение письма или подделка архива.
📌 Почему папки и скриншота недостаточно
Папка «Отправленные» показывает состояние конкретного ящика. Она не доказывает, что письмо ушло адресату. В ней может находиться черновик, копия или сообщение после ручной загрузки.
Даже нотариальная фиксация ящика отвечает лишь на ограниченный вопрос. Она показывает, что содержимое находилось в ящике в момент осмотра. Она не всегда подтверждает путь сообщения.
Обратная ситуация также возможна. Получатель показывает пустой ящик. Отправитель показывает письмо в папке «Отправленные». Оба набора данных могут быть подлинными. Например, письмо могли удалить, переместить правилом или принять в другой ящик.
Скриншот содержит ещё меньше контекста. На нём часто нет полного адреса, технических заголовков и точного часового пояса. Изображение также легко вырвать из общей последовательности писем.
Надёжнее сопоставлять несколько независимых источников. Содержимое письма сравнивают с заголовками. Заголовки сравнивают с серверными журналами. Серверные записи сопоставляют с входами в учетную запись и сетевыми событиями.
Не перезаписывайте исходный экспорт. Рабочую копию используйте для просмотра и поиска. Оригинал храните отдельно, с ограничением записи.
Что сделать сейчас: выгрузите спорное письмо из почтовой системы в исходном формате и отдельно сохраните скриншот интерфейса.
🧩 Какие данные содержит исходное письмо
Первый объект сохранения — файл EML или MSG. Он нужен для анализа содержимого и технических полей. Экспортируйте письмо из системы, а не копируйте текст в новый документ.
Вместе с файлом сохраняйте полные заголовки. Не ограничивайтесь строками «От», «Кому» и «Дата». Важны цепочка Received, Message-ID и сведения о проверках отправителя.
Цепочка Received показывает, через какие узлы проходит сообщение. Её анализ помогает сравнить заявленный маршрут с журналами серверов.
Message-ID связывает письмо с записями почтовой системы. Он не доказывает личность автора сам по себе. Но одинаковый идентификатор в нескольких источниках помогает сопоставить события.
Фиксируйте дату и время вместе с часовым поясом. Без этого события легко поставить в неверный порядок. Отдельно сохраняйте сведения о синхронизации времени серверов.
Проверки SPF, DKIM и DMARC также относятся к контексту письма. SPF помогает сопоставить отправляющий сервер с политикой домена. DKIM показывает результат проверки подписи отдельных частей сообщения. DMARC связывает проверку домена с политикой обработки.
Эти механизмы не устанавливают личность человека. Они не доказывают, что письмо набирает конкретный сотрудник. Результаты нужно сопоставлять с входом в учетную запись и серверными событиями.
Сохраняйте и вложения. Для каждого вложения указывайте имя, размер и связь с исходным письмом. Не открывайте вложение на рабочем компьютере расследователя без необходимости.
Что сделать сейчас: экспортируйте письмо, заголовки, вложения, дату, часовой пояс и результаты SPF, DKIM и DMARC одним комплектом.
⚙️ Журналы почтового сервера и маршрут сообщения
Серверные журналы отвечают на вопрос о движении письма. В системе отправителя ищите событие передачи. В системе получателя ищите приём и доставку.
Для каждой записи сохраняйте время, идентификатор сообщения, учетную запись, адрес отправителя, адресата и результат операции. Поля зависят от платформы. Не меняйте исходный формат журнала при экспорте.
Сопоставляйте журналы с цепочкой Received. Если письмо заявляет один маршрут, а серверы показывают другой, это становится отдельным вопросом экспертизы.
Сохраняйте записи до и после спорного события. Один фрагмент без контекста не показывает, что происходило с очередью, повторными попытками и доставкой.
Для локальной почты фиксируйте журналы сервера пересылки и сервера хранения. В типовой архитектуре сервер пересылки принимает сообщение и передаёт его дальше по SMTP. Сервер хранения помещает письмо в ящик пользователя.
Такая схема помогает разделить этапы. На первом этапе проверяют отправку. На втором — передачу. На третьем — доставку и хранение.
Для облачной почты сохраняйте доступные журналы аудита. В них ищите отправку, чтение, удаление, перемещение и изменение настроек ящика.
Что сделать сейчас: установите срок хранения журналов не короче периода возможного спора и проверьте, что администратор может выгружать их без изменения исходных данных.
🔐 Журналы входа, MFA и действий в ящике
Если письмо отправляет настоящая учетная запись, одних почтовых логов мало. Нужно установить, кто и откуда получил доступ к ящику.
Сохраняйте события входа. Нужны дата, время, учетная запись, результат проверки и источник подключения. При наличии MFA фиксируйте факт дополнительной проверки и её результат.
Отдельно сохраняйте события смены пароля, восстановления доступа и изменения способов аутентификации. Эти действия могут объяснить необычную отправку.
Проверяйте правила пересылки. Злоумышленник может направлять копии сообщений на внешний адрес. Такое правило меняет картину расследования и объясняет пропажу письма из привычного ящика.
Проверяйте делегированный доступ. Сотрудник или администратор может иметь право читать и отправлять сообщения от имени другого ящика. Это не равно компрометации владельца.
Сохраняйте сведения о клиентах и устройствах, если система их предоставляет. Вход через веб-клиент, мобильное приложение и почтовую программу оставляет разный контекст.
Не делайте вывод об авторе только по имени сотрудника. Учетную запись мог использовать другой человек. Пароль мог попасть к третьему лицу. Также письмо могло отправить лицо с делегированным правом.
Что сделать сейчас: выгрузите журналы входа, MFA, правил пересылки, делегированного доступа и смены пароля за расширенный период вокруг инцидента.
🛡️ Какие дополнительные журналы сохранять
Почтовая система работает не изолированно. Между пользователем и ящиком стоят шлюзы, антивирусные средства и системы защиты данных.
Сохраняйте записи почтового шлюза. Они показывают проверку сообщения, результат фильтрации и передачу дальше. Эти данные помогают сопоставить письмо с серверными событиями.
Фиксируйте журналы антивируса. Важны обнаружение вложения, блокировка, изменение статуса и время проверки. Не удаляйте событие после повторного сканирования.
Если работает система предотвращения утечек, сохраняйте её решения. Они показывают, задерживалось ли письмо, блокировалось ли вложение или менялся ли маршрут.
Сетевые журналы помогают установить соединение с почтовой системой. Используйте их как дополнительный источник, а не как самостоятельное доказательство содержания письма.
Сохраняйте резервные копии почтовых ящиков и журналов. Отмечайте дату создания копии и период, который она покрывает. Не заменяйте старую копию новой без протокола.
Проверяйте состояние времени. Несовпадение часов создаёт ложные разрывы в цепочке событий. В журнале расследования указывайте, какие источники времени используют серверы.
Разграничивайте доступ администраторов. Человек, который выгружает журналы, не должен незаметно менять их содержание. Действия администратора также фиксируйте.
Что сделать сейчас: соберите в один перечень почтовые, сетевые, шлюзовые, антивирусные журналы, записи защиты данных и резервные копии.
📦 Как сохранить доказательства без потери доверия
Сохранение начинается сразу после обнаружения спора. Сначала фиксируйте состояние систем. Затем экспортируйте данные в исходном виде.
Для каждого файла рассчитывайте хеш-сумму. Хеш помогает заметить изменение копии после экспорта. Он не доказывает истинность исходного письма, но подтверждает неизменность сохранённого файла.
Храните оригинал только для чтения. Анализ проводите на рабочей копии. Если нужно преобразовать формат, сохраняйте и исходный файл, и новый результат.
Ведите журнал действий. Указывайте, кто получил доступ, когда выполнил экспорт, какой инструмент использовал и куда записал результат.
Фиксируйте передачу доказательств между сотрудниками. Запись должна показывать отправителя, получателя, дату, время, состав комплекта и состояние носителя.
Не ограничивайтесь спорным письмом. Сохраняйте контекст до и после события. Он показывает последовательность действий и помогает выявить пропуски.
Если почтовый ящик осматривает нотариус, сохраняйте материалы осмотра вместе с техническим экспортом. Эти объекты отвечают на разные вопросы и не заменяют друг друга.
Что сделать сейчас: создайте журнал передачи доказательств и назначьте правило, по которому каждый экспорт получает уникальный номер.
🚀 Практика для Exchange, Microsoft 365 и Google Workspace
В Exchange сохраняйте трассировку сообщения, журналы входа и аудита. Отдельно проверяйте правила ящика, делегированный доступ и действия администраторов.
В Microsoft 365 ищите записи аудита почты и учетной записи. Сохраняйте события отправки, удаления, перемещения, входа и изменения настроек. Экспортируйте данные с указанием периода и часового пояса.
В Google Workspace фиксируйте события Gmail и входов пользователя. Проверяйте правила маршрутизации, пересылку и доступ приложений. Сопоставляйте эти записи с исходными заголовками.
Названия разделов и доступные поля зависят от редакции и настроек. Поэтому в отчёте указывайте точное имя журнала и способ его выгрузки.
Не ограничивайтесь данными облачного провайдера. Сохраняйте письмо, вложения и копии шлюзов организации. Так появляется независимое сравнение.
Если система хранит только агрегированные события, не выдавайте их за полную историю. Укажите границы журнала и возможные пробелы.
Что сделать сейчас: подготовьте отдельные инструкции выгрузки для Exchange, Microsoft 365 и Google Workspace, а затем проверьте их на тестовом ящике.
🔧 Практика для локального почтового сервера
В локальной инфраструктуре разделяйте сервер пересылки и сервер хранения. Для первого сохраняйте SMTP-события. Для второго — доставку, перемещение и удаление сообщений.
Серверы Postfix и Exim относятся к компонентам пересылки. Dovecot и Procmail относятся к компонентам получения и хранения. В расследовании важно сохранить журналы обоих уровней.
Проверяйте MX-записи домена. Они указывают сервер или серверы, которые принимают почту домена. Этот контекст помогает понять ожидаемый маршрут сообщения.
Не редактируйте журналы вручную перед передачей. Если нужно убрать персональные данные из рабочей копии, сохраните полный оригинал отдельно и опишите редактирование.
Защитите доступ к журналам от тех же учетных записей, которые администрируют почту. Иначе спорная сторона может заявить, что записи меняются без контроля.
Проверяйте резервное копирование. Копия должна включать период до события и период после него. В отчёте указывайте, когда её создали и кто получил доступ.
Что сделать сейчас: составьте карту локальной почты: клиент, сервер пересылки, сервер хранения, шлюз, резервная копия и источник времени.
📋 Итоговый чек-лист перед передачей в суд
Перед передачей комплекта проверьте полноту. В нём должны быть исходный EML или MSG, полные заголовки и вложения.
Добавьте серверные записи отправителя и получателя. Сохраните результаты SPF, DKIM и DMARC. Приложите журналы входа, MFA, правил пересылки и делегированного доступа.
Добавьте записи шлюза, антивируса, системы предотвращения утечек и сети. Приложите сведения о синхронизации времени и резервных копиях.
Проверьте хеш-суммы. Убедитесь, что оригиналы хранятся отдельно. Сверьте журнал действий и передач с фактическими файлами.
В итоговом описании разделите установленные факты и предположения. Например, сервер подтверждает приём сообщения. Это ещё не подтверждает личность человека, который вводит текст.
Отдельно отмечайте пробелы. Если журнал не сохранился, укажите срок хранения и причину отсутствия. Не заменяйте пропуск догадкой.
Электронная переписка может устанавливать юридически значимые факты. Но один артефакт редко отвечает на все вопросы. Поэтому доказательство строится из независимых и согласованных следов.
Что сделать сейчас: проведите контрольный экспорт по этому списку и зафиксируйте результат до возникновения реального спора.
📚 Читайте также
- Криптография в логах: как доказать целостность событий после взлома
- Песочница для ИИ-агента: как вовремя заметить опасные действия
- Обратный прокси против фишинга: фильтрация входящего трафика
- Локальный файрвол для кодинг-агентов: защита действий в CI/CD
- Фальшивый криптостартап: как КНДР вербует разработчиков и хакеров
📖 Термины
IAM (Identity and Access Management) · SIEM · Криптография · Цифровой след