LaunDroMARC: как лазейка в Microsoft SRS используется для отмывания поддельных электронных писем

Исследователь в области безопасности Аарон Харт расследовал случай, который выглядел как обычная попытка взлома деловой электронной почты. Но чем глубже он вникал в дело, тем страннее оно становилось. Все в этой атаке выглядело тщательно подготовленным и правдоподобным: домен отправителя, результаты аутентификации и путь, по которому прошла электронная почта.

Однако произошло нечто невозможное. Электронное письмо, которое не прошло проверку DMARC на источнике , волшебным образом прошел проверку DMARC после пересылки через Microsoft Exchange Online.

Это не должно быть возможно. Но это было возможно – и происходило из-за побочного эффекта схемы перезаписи отправителя (SRS) Microsoft. Sender Rewriting Scheme (SRS) .

В этом блоге проблема разъясняется простым языком, первоначально опубликованным Engage Security, объясняет, как работает эта лазейка и как организации могут обнаружить и снизить риск.

Как Microsoft SRS приводит к обходу DMARC 

В ходе расследования Аарон заметил:

• В электронном письме утверждалось, что оно отправлено с надежного внутреннего домена (ORG 1).
• Он был доставлен в почтовый ящик пользователя в другой организации (ORG 2).
• ORG 2 расценило сообщение как полностью аутентифицированное, т. е. прошедшее проверку SPF и DMARC.
• Но исходное электронное письмо, отправленное злоумышленником в ORG 1 не прошел проверку DMARC.
• Пересылка SRS от Microsoft переписала MAIL FROM во время пересылки.
• Переписанный MAIL FROM создал выравнивание, благодаря чему DMARC прошел вниз по потоку.

Коротко: Поддельное электронное письмо , которое должно было быть отклонено , был переслан, переписан и «очищен», а затем доставлен как надежное сообщение. Это привело к взлому реального аккаунта, и это был не единичный случай.

Почему это важно

Пересылка электронной почты является чрезвычайно распространенной практикой в организациях:

• Консультанты, пересылающие электронные письма клиентов
• Члены правления, пересылающие корпоративные адреса на личные почтовые ящики
• Общие почтовые ящики или списки рассылки, направляющие почту вовне
• Межорганизационные группы сотрудничества

С 2023 года Microsoft включила SRS для всех арендаторов Exchange Online с целью устранить сбои SPF, вызванные пересылкой электронной почты. К сожалению, это исправление создало новую проблему: пересланные вредоносные электронные письма теперь отображаются как полностью аутентифицированные, даже если изначально они не прошли проверку DMARC.

Это явление теперь получило название «LaunDroMARC» , поскольку процесс пересылки буквально «отмывает» вредоносные сообщения.

Краткое напоминание: SMTP, SPF, DKIM и DMARC

MAIL FROM vs FROM

• MAIL FROM (Конверт от): невидимо для пользователей и используется для обработки отказов.
• ОТ: видимый отправитель в вашем почтовом ящике.

SPF

Sender Policy Framework проверяет, имеет ли отправляющий сервер право отправлять почту для домена MAIL FROM. SPF не проверяет видимый адрес FROM и не работает при пересылке (пересылающие серверы не указаны в записи SPF отправителя).

DKIM

DomainKeys Identified Mail цифровой подписью заголовки электронных писем, включая поле «От». Злоумышленники могут потенциально подписать DKIM свои собственные вредоносные домены, что подчеркивает одну из слабых сторон протокола.

DMARC

Доменная аутентификация сообщений, отчетность и соответствие устраняют проблемы с согласованием, требуя, чтобы домен MAIL FROM соответствовал домену FROM, или домен подписи DKIM соответствовал домену FROM, для прохождения аутентификации. Если согласование не удается, домен DMARC указывает получателям, следует ли доставить, поместить в карантин или отклонить сообщение. 

DMARC значительно сократил количество поддельных писем до тех пор, пока эта лазейка не вернула его.

Где все пошло наперекосяк: внедрение SRS в Microsoft

SRS был введен для предотвращения сбоев SPF при пересылке. Но реализация Microsoft имеет критический недостаток:

Microsoft переписывает MAIL FROM даже в следующих случаях:

• В исходном электронном письме подделан адрес отправителя домена переадресации.
• Поддельное электронное письмо не проходит проверку DMARC на первом прыжке.
• Сообщение исходит из домена, контролируемого злоумышленником.

После перезаписи с помощью SRS MAIL FROM теперь совпадает с доменом FROM, что позволяет DMARC проходит в конечной точке назначения.

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

В настоящее время Microsoft не рассматривает это как уязвимость безопасности.

Пример сценария

Представьте, что злоумышленник контролирует домен maliciousmailer.com, в котором настроены записи SPF, разрешающие отправку с IP-адреса 198.51.100.25. Он создает электронное письмо, предназначенное для консультанта Сары, чей рабочий адрес электронной почты [email protected], но которое автоматически пересылается на ее личный почтовый ящик [email protected].

Злоумышленник устанавливает заголовки электронного письма следующим образом:

• ПИСЬМО ОТ: [email protected]
• ОТ: Сара [email protected] (поддельный адрес, чтобы выглядеть как внутренний)
• Кому: [email protected]

При отправке проверка SPF проходит успешно, поскольку домен MAIL FROM контролируется злоумышленником. Когда электронное письмо достигает company.com, Exchange Online обрабатывает его с помощью SRS: игнорирует сбой DMARC на поддельном поле FROM, переписывает MAIL FROM в соответствии с доменом переадресации (например, sarah+SRS=…@company.com) и пересылает его в личный почтовый ящик Сары.

На сайте personalmail.com DMARC теперь проходит проверку, поскольку переписанное MAIL FROM и видимое FROM совпадают. Электронное письмо доставляется в почтовый ящик Сары и выглядит легитимным, эффективно обходя защиту, которая должна была его заблокировать.

Короче говоря, поддельное сообщение, которое должно было быть заблокировано, теперь вызывает доверие у получателя, что иллюстрирует, как SRS может непреднамеренно «отмывать» вредоносные электронные письма.

Почему LaunDroMARC опасен для организаций 

Эта уязвимость опасна, поскольку пользователи естественно доверяют электронным письмам, которые, по-видимому, приходят от их собственной организации или с известного внутреннего домена. Когда вредоносные электронные письма пересылаются, они обходят исходные проверки безопасности и поступают в виде чистых и легитимных писем. 

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

Что Microsoft могла бы исправить

Существует несколько простых мер, которые Microsoft могла бы принять для смягчения последствий:

1. Не переписывайте MAIL FROM через SRS, если заголовок FROM принадлежит домену переадресации, но не проходит DMARC на первом прыжке.
2. Применяйте SRS только к сообщениям, которые проходят DMARC от отправителя.
3. Сравните заголовки Authentication-Results до и после пересылки.
   Если они не совпадают, поместите сообщение в карантин.

Как организации могут обнаружить LaunDroMARC

1. Домен переадресации (Exchange Online)

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

2. Домен конечного получателя

Если в электронном письме адрес отправителя (FROM) совпадает с переписанным адресом MAIL FROM, но исходный домен MAIL FROM, скрытый внутри значения SRS, не совпадает ни с одним из них, это явный признак того, что сообщение было «отмыто» путем пересылки и может быть поддельным или вредоносным.

Точка зрения PowerDMARC

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

PowerDMARC помогает организациям:

• Анализировать результаты аутентификации на всех узлах
• Обнаружение аномалий выравнивания и поведения пересылки
• Получайте оповещения в режиме реального времени о попытках подделки
• Понимание того, как сторонние системы обрабатывают пересылаемую почту
• Мониторинг междоменного трафика на предмет моделей подделки
• Обеспечьте видимость атак, использующих цепочки пересылки

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

Заключительные размышления

Проблема LaunDroMARC вновь открывает вектор атаки, который DMARC был призван предотвратить, делая возможным внутреннее подделку домена через пересылаемую почту. Хотя Microsoft в настоящее время считает это «низким риском», реальные угрозы доказывают обратное. 

Организации, использующие Microsoft 365, должны быть осведомлены об этой лазейке в системе переадресации и принять дополнительные меры по ее обнаружению.

• О сайте
• Последние сообщения

Ахона Рудра

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Аона - менеджер по маркетингу в PowerDMARC, имеет более чем 5-летний опыт написания статей на темы кибербезопасности, специализируясь на безопасности доменов и электронной почты. Ахона получила диплом о высшем образовании по специальности "Журналистика и коммуникации", а с 2019 года начала работать в сфере безопасности.

Последние сообщения Ахона Рудра (см. все)

• Что такое DANE? Объяснение аутентификации именованных объектов на основе DNS (2026) - 20 апреля 2026 г.
• Основы безопасности VPN: лучшие практики по защите вашей конфиденциальности - 14 апреля 2026 г.
• Обзор MXtoolbox: функции, отзывы пользователей, плюсы и минусы (2026) - 14 апреля 2026 г.