Аутентифицированное письмо — не гарантия безопасности

Технически корректная аутентификация отправителя ещё не означает, что письмо безопасно. Материалы о сравнительном тесте Virus Bulletin VBSpam за III квартал 2026 года описывают фишинговые кампании, где внешне легитимная почтовая инфраструктура сочеталась с многоэтапной маскировкой URL. Вредоносный сценарий запускался уже в браузере — там, где обычная проверка отправителя или исходной ссылки может ничего не выявить.

Тест продолжался 16 дней и проводился по плану AMTSO — организации, разрабатывающей методики тестирования средств защиты. Были проанализированы 103 969 писем, включая 103 380 спам-сообщений. 13

SPF, DKIM и DMARC подтверждают маршрут — но не безопасность содержания

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

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

Три примера фишинга из материалов о тесте

Просроченный платёж: Amazon SES, DKIM и переход на OpenSea

Одна кампания на немецком языке использовала тему просроченного платежа. Письма рассылались через Amazon SES с домена, выровненного по DKIM. Вместо вложения в HTML-сообщение были добавлены отвлекающая разметка, скрытый текст, iframe нулевого размера и обфусцированный JavaScript. 35

После перехода по ссылке механизм собирал сведения о браузере и часовом поясе, выполнял скрытый POST-запрос и перенаправлял подходящих посетителей на OpenSea. В публикациях это описано как схема, согласующаяся с замаскированным мошенничеством в сфере криптовалют или NFT: первичное письмо и исходный URL не обязательно раскрывают её смысл при поверхностной проверке. 35

Поддельные продления McAfee и TotalAV

Другая кампания, на нидерландском языке, выдавала себя за McAfee и TotalAV. Получателя предупреждали о «631 опасном вирусе» и предлагали продлить подписку со скидкой. Вложений не было: ставка делалась на социальную инженерию в HTML-письме. 35

Ключевым механизмом обхода была условная выдача контента. Назначение ссылки могло меняться в зависимости от времени, геолокации или предполагаемого профиля жертвы. Из-за этого автоматический сканер мог увидеть безобидную страницу, ошибку или другую цепочку редиректов, не ту, которую получит выбранный адресат. Указанная цель кампании — мошенничество с подписками. 35

Имитация BCR S.A. и «продление согласия PSD2»

В третьем случае фишинговое сообщение на румынском языке имитировало BCR S.A. и утверждало, что требуется обновить согласие PSD2. PSD2 — европейская директива о платёжных услугах, поэтому такая тема может выглядеть для клиента банка привычной и срочной.

Согласно материалам о кампании, адрес назначения скрывали с помощью IPv6-mapped-адреса — приёма, способного осложнить разбор URL и анализ сканерами. Сюжет с обязательным обновлением банковского согласия создаёт удобный предлог для кражи учётных данных. 3

Почему одной статической проверки уже недостаточно

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

• HTML и JavaScript скрывают реальную структуру сообщения.
• Цепочки редиректов отделяют доставленную ссылку от конечного сайта.
• Проверки браузера, часового пояса, геолокации и времени помогают отличить вероятную жертву от автоматизированной системы.
• Условные ответы позволяют не показывать наиболее опасный контент простым песочницам и репутационным проверкам. 35

Вывод не в том, что от аутентификации почты нужно отказаться. Напротив, SPF, DKIM и DMARC остаются важной частью гигиены безопасности. Но их следует оценивать как один сигнал среди других: содержания письма, репутации отправителя, поведения ссылки и риска конечной страницы. 35

Что должны проверять средства защиты

Более устойчивый подход требует анализа всей цепочки, а не только первого признака доверия:

1. Нормализовать обфусцированные URL. Необычные формы адресов следует декодировать и приводить к каноническому виду до проверки репутации и политик.
2. Прослеживать всю цепочку редиректов. Оценивать нужно каждый переход и итоговую страницу, а не только исходную ссылку.
3. Анализировать поведение в браузере. Важно выявлять условные перенаправления, сбор характеристик браузера, скрытые запросы и другие действия, заметные лишь после исполнения страницы.
4. Не переоценивать аутентификацию. SPF, DKIM и DMARC помогают принимать решение о доверии, но не должны перевешивать признаки вредоносного контента или опасного назначения.
5. Измерять ложные срабатывания вместе с обнаружением угроз. Блокировка опасных писем важна, но ошибочная блокировка легитимной корреспонденции создаёт отдельный операционный риск. 35

Между продуктами обнаружилась заметная разница

Согласно опубликованным сводным результатам, лучшие решения показали почти максимальные показатели, однако результаты были крайне неравномерными. Net at Work NoSpamProxy получил итоговую оценку 99,995 без ложных срабатываний; Bitdefender GravityZone Premium — 99,994; SEPPmail.cloudfilter — 99,985. Для Rspamd сообщается результат 62,5%. 35

Эти цифры относятся к конкретному сравнительному тесту, а не служат универсальной гарантией для любой инфраструктуры. Тем не менее разрыв подчёркивает главный практический вывод: для противодействия аутентифицированным отправителям, обфусцированным URL и условным браузерным сценариям нужна многоуровневая проверка, а не опора на единственный защитный механизм. 135

Главное

Материалы о VBSpam Q3 2026 описывают модель фишинга, построенную на простой асимметрии: письмо может выглядеть приемлемым в момент доставки, а мошенничество проявится лишь после того, как браузер получателя пройдёт заданные злоумышленником проверки. Аутентификация отправителя необходима, но решение о безопасности должно охватывать всю цепочку редиректов и конечное поведение веб-страницы. 35