2 марта 2026 года я получил на анализ фишинговое письмо. Отправитель - «M e t a», тема - «[Требуется действие] Завершите проверку, чтобы восстановить показ объявлений». SPF pass, DKIM pass, ARC pass - письмо прошло все проверки и лежало во входящих Gmail. Ключ - цепочка Resend.com → Amazon SES → Gmail, где каждый элемент легитимен. Разбираю, как атакующие этого добились и почему это работает.

Что пришло

Во входящих Gmail - письмо от «M e t a» (да, с пробелами между буквами). Тема: «[Требуется действие] Завершите проверку, чтобы восстановить показ объявлений.» Текст на русском языке: элементы рекламной кампании якобы нарушают рекламную политику, показ ограничен, нужно пройти проверку. Кнопка «Начать проверку».

Три вещи привлекли внимание:

1. Display Name - «M e t a» с пробелами. Не «Meta».

2. Адрес отправителя - identity-policy@readlundy[.]com. Не meta.com, не facebookmail.com.

3. Адрес получателя - функциональный ящик конкретной программы организации, не опубликованный на главной странице сайта. Его получение требовало предварительной разведки.

Логотип Meta в письме - настоящий. Загружается с hxxps://facebook[.]com/images/email/meta_logo.png. Атакующие не стали хостить логотип у себя, а сослались на реальный URL Facebook. Это даёт два преимущества для атакующих: (a) письмо выглядит правдоподобно - браузер грузит настоящую картинку; (b) трекинг открытий - по запросу к этому URL видно, что письмо открыли.

В подвале - юридический дисклеймер: «Meta Platforms, Inc., 1601 Willow Rd, Menlo Park, CA 94025». Скопирован из настоящих писем Meta.

Анализ заголовков

Основные параметры

Аутентификация

Все проверки пройдены. Письмо не попало в спам.

Маршрут доставки

Трёхступенчатая цепочка: Resend → Amazon SES → Gmail. Никаких сомнительных промежуточных серверов.

Как они обошли фильтры: Resend.com → Amazon SES

Это ключевой технический момент атаки.

Resend - легитимный email API для разработчиков. Зарегистрировал аккаунт, добавил домен, настроил DNS-записи - и можно отправлять письма от имени своего домена с полным прохождением аутентификации.

Атакующие сделали следующее:

1. Зарегистрировали домен readlundy[.]com через регистратор Sav.com (15 августа 2025 - за полгода до атаки).

2. Подключили его к Resend, настроили SPF и DKIM.

3. Resend использует Amazon SES как транспорт.

В результате письмо получает двойную DKIM-подпись: от readlundy[.]com (selector: resend) и от amazonses.com. SPF проходит для send.readlundy[.]com. ARC подписывается Google. Для Gmail это легитимное письмо от легитимного домена, отправленное через легитимный сервис.

Почему Gmail не блокирует? Потому что формально нарушений нет. SPF и DKIM проверяют подлинность отправителя для envelope-домена (readlundy[.]com), а не для бренда в Display Name. Gmail видит: «письмо от readlundy.com, аутентификация пройдена, домену полгода, отправлено через Amazon SES» - и пропускает. Что в Display Name написано «M e t a» - не является критерием блокировки.

А что с DMARC?

Важный вопрос, который часто упускают: а почему DMARC не помогает?

Потому что атакующие не пытаются подделать домен meta.com. Они отправляют от своего домена readlundy[.]com - DMARC для него настроен в режиме p=none (мониторинг без блокировки). Display Name «M e t a» - просто текстовое поле, DMARC его не проверяет.

DMARC meta.com здесь нерелевантен: в envelope From стоит readlundy[.]com, а не meta.com. Вся имперсонация Meta происходит только визуально - в Display Name и оформлении письма. Это важное отличие от классического spoofing'а, при котором атакующий пытается поставить From: noreply@meta.com.

Регистратор Sav.com имеет задокументированную историю проблем с обработкой abuse-жалоб. Amazon SES и Resend регулярно фигурируют в отчётах об использовании для фишинговых рассылок. Но по отдельности каждый из этих сервисов - легитимный инструмент. Атакующие просто собрали из легитимных компонентов инфраструктуру доставки, которую невозможно отличить от обычной рассылки.

Социальная инженерия

Приём с пробелами в Display Name - примитивный, но рабочий. Большинство антиспам-фильтров ищут паттерны типа From: *Meta* или From: *facebook*. Строка «M e t a» не матчится. При этом человек, бегло просматривающий входящие, читает «Meta» - мозг автоматически игнорирует пробелы.

Легенда подобрана точно: правозащитные организации действительно используют Facebook-рекламу для распространения информации о своей деятельности. Угроза блокировки рекламного аккаунта - реальная боль, на которую получатель может среагировать.

Фишинговый хостинг: перехваченный домен

Кнопка «Начать проверку» ведёт на hxxps://skillbaseltd[.]co[.]uk/.

Skillbase Ltd - настоящая британская рекрутинговая компания из Clay Cross (Chesterfield), основанная в 2011 году, с LinkedIn-профилем и историей операций. Домен skillbaseltd[.]co[.]uk зарегистрирован (или перерегистрирован) 13 октября 2025 через Ionos SE. При этом Nominet не смог верифицировать данные регистранта - прямая аномалия, которой не бывает при легитимной регистрации через Ionos.

Сценарий подтверждён - перехват домена: анализ SSL-сертификатов через crt.sh показывает, что последний сертификат легитимного владельца выпущен 4 августа 2025 года (Let's Encrypt R11, истёк 2 ноября 2025). Первый сертификат нового владельца - Google Trust Services WE1 - датирован 13 октября 2025, день совпадает с датой регистрации через Ionos SE. Это типичная картина перехвата истёкшего домена: компания в процессе ликвидации не продлила домен, атакующий перехватил его через несколько недель после истечения срока.

Атакующие получают домен с десятилетней историей. URL-фильтры, проверяющие возраст и категорию домена, пропускают его: это не свежезарегистрированный meta-security-check[.]com, а сайт реальной компании, существующей с 2011 года.

Оба домена (readlundy[.]com и skillbaseltd[.]co[.]uk) используют Cloudflare DNS - бесплатный CDN, скрывающий реальный IP хостинга.

Дополнительный анализ выявил более широкую инфраструктуру: сертификат от 28 февраля 2026 года (за двое суток до атаки) выдан сразу на 14 доменов в одном SAN, включая skillbaseltd[.]co[.]uk. Все 14 - перерегистрированные expired-домены британских ликвидированных компаний, на единой cPanel-платформе за Cloudflare. Из них три (restorewellbeing[.]co[.]uk, rubyandginger[.]co[.]uk, senditmyway[.]co[.]uk) уже имеют настроенный Resend DKIM и send.<домен> с include:amazonses.com - идентичная инфраструктура отправки, как у readlundy[.]com. Это ротируемый резерв для следующих кампаний.

Признаки целевой атаки

Это не массовая рассылка. Несколько факторов указывают на целевой характер:

1. Адрес получателя связан с конкретной программой организации и не опубликован на главной странице сайта. Его получение требовало предварительной разведки.

2. Язык письма - русский, адаптирован под целевую аудиторию.

3. Легенда - рекламный аккаунт Facebook - правдоподобна именно для правозащитной НКО, использующей Facebook для информационных кампаний.

Kill Chain

Атака остановлена между этапами 4 и 5 - письмо доставлено, но распознано как фишинг до перехода по ссылке.

IOC

MITRE ATT&CK

Что делать

Если получили такое письмо

1. Не переходить по ссылкам и не вводить учётные данные.

2. Проверить адрес отправителя - не Display Name, а envelope From (Return-Path). Настоящие письма Meta приходят с facebookmail.com или meta.com.

3. Навести курсор на кнопку - посмотреть реальный URL. Если это не facebook.com - фишинг.

4. Если перешли по ссылке: немедленно сменить пароль Facebook, завершить все активные сессии, проверить список администраторов страницы и привязанные приложения.

5. Пометить как фишинг в Gmail.

6. Для аккаунтов Facebook/Meta - использовать аппаратные FIDO2-ключи (не SMS, не TOTP).

Для администраторов и security-команд

• Настроить DMARC p=reject для своих доменов - это не защитит от атак с чужих доменов, но не позволит атакующим использовать ваш домен для имперсонации. Начните с p=none + мониторинг отчётов, затем переходите к quarantine и reject.

• Фильтрация по Display Name на уровне mail gateway: правило, блокирующее или помечающее письма, где Display Name содержит название крупного бренда (Meta, Google, Microsoft, Apple), а envelope From - сторонний домен.

• Мониторинг Resend/SES-паттернов: письма с Feedback-ID Amazon SES и Return-Path на send.*.com от неизвестных доменов - повод для дополнительной проверки.

• При обнаружении фишинга - отправлять abuse-репорты напрямую в Cloudflare, Amazon SES и Resend. Это ускоряет блокировку вредоносной инфраструктуры на уровне провайдера.

Выводы

Технически эта атака интересна не сложностью, а тем, как атакующие собрали цепочку из легитимных сервисов. Resend.com - легитимный email API. Amazon SES - легитимный транспорт. Cloudflare - легитимный CDN. Sav.com - легитимный регистратор. Каждый элемент по отдельности не вызывает подозрений. Вместе они образуют инфраструктуру доставки фишинга, которая проходит все автоматические проверки.

Перехваченный домен реальной компании в качестве фишингового хостинга - приём, который эффективно обходит URL-репутационные фильтры. Домен с историей и легитимным бизнесом не попадёт в чёрные списки превентивно.

Это не разовая атака с одним доменом. Анализ инфраструктуры выявил кластер из 14 перерегистрированных expired-доменов британских ликвидированных компаний - все на единой платформе, три уже готовы к отправке через Resend → Amazon SES. Атакующие подготовили ротируемый резерв на несколько кампаний вперёд.

Для организаций гражданского общества, журналистов и правозащитников - такие атаки регулярно документируются Citizen Lab, Access Now и Amnesty Tech. Имперсонация крупных платформ (Meta, Google, Microsoft) остаётся одним из основных векторов. Единственная надёжная защита - проверка реального адреса отправителя и URL ссылок перед кликом.

Полный отчёт (EN + RU, TLP:CLEAR) с IOC в формате plaintext: github.com/afokin52/threat-intelligence