2 марта 2026 года я получил на анализ фишинговое письмо. Отправитель - «M e t a», тема - «[Требуется действие] Завершите проверку, чтобы восстановить показ объявлений». SPF pass, DKIM pass, ARC pass - письмо прошло все проверки и лежало во входящих Gmail. Ключ - цепочка Resend.com → Amazon SES → Gmail, где каждый элемент легитимен. Разбираю, как атакующие этого добились и почему это работает.
Что пришло
Во входящих Gmail - письмо от «M e t a» (да, с пробелами между буквами). Тема: «[Требуется действие] Завершите проверку, чтобы восстановить показ объявлений.» Текст на русском языке: элементы рекламной кампании якобы нарушают рекламную политику, показ ограничен, нужно пройти проверку. Кнопка «Начать проверку».
Три вещи привлекли внимание:
Display Name - «M e t a» с пробелами. Не «Meta».
Адрес отправителя -
identity-policy@readlundy[.]com. Неmeta.com, неfacebookmail.com.Адрес получателя - функциональный ящик конкретной программы организации, не опубликованный на главной странице сайта. Его получение требовало предварительной разведки.
Логотип 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.
Анализ заголовков
Основные параметры
Параметр | Значение | Оценка |
|---|---|---|
From (display) | M e t a | Подделка |
From (envelope) |
| Не meta.com |
Return-Path |
| Домен рассылки Resend |
Date | Mon, 2 Mar 2026 15:05:59 +0000 | UTC |
Message-ID |
| Amazon SES (Токио) |
Subject | [Требуется действие] Завершите проверку... | Создаёт срочность |
Аутентификация
Проверка | Результат | Комментарий |
|---|---|---|
SPF | pass |
|
DKIM | pass (x2) | readlundy[.]com (selector: resend) + amazonses.com |
DMARC | pass | readlundy[.]com, p=none - политика не блокирует |
ARC | pass | Подписан mx.google.com |
Все проверки пройдены. Письмо не попало в спам.
Маршрут доставки
# | Хост | Описание |
|---|---|---|
1 | Resend.com | Email API. Атакующие подключили домен readlundy[.]com |
2 |
| Amazon SES, регион ap-northeast-1 (Токио) |
3 | mx.google.com | Gmail. TLS 1.3. Доставлено во входящие |
Трёхступенчатая цепочка: Resend → Amazon SES → Gmail. Никаких сомнительных промежуточных серверов.
Как они обошли фильтры: Resend.com → Amazon SES
Это ключевой технический момент атаки.
Resend - легитимный email API для разработчиков. Зарегистрировал аккаунт, добавил домен, настроил DNS-записи - и можно отправлять письма от имени своего домена с полным прохождением аутентификации.
Атакующие сделали следующее:
Зарегистрировали домен
readlundy[.]comчерез регистратор Sav.com (15 августа 2025 - за полгода до атаки).Подключили его к Resend, настроили SPF и DKIM.
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 «M e t a». Реальный логотип с |
Создание срочности | Тема: «[Требуется действие]». Показ объявлений уже ограничен |
Страх потери | Угроза длительного ограничения рекламного аккаунта |
Авторитет | Юридический дисклеймер Meta Platforms, Inc. в подвале |
Обход фильтров | Пробелы в «M e t a» - фильтры, ищущие точное совпадение бренда «Meta», пропускают |
Язык | Русский - адаптировано под получателя |
Приём с пробелами в 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. Это ротируемый резерв для следующих кампаний.
Признаки целевой атаки
Это не массовая рассылка. Несколько факторов указывают на целевой характер:
Адрес получателя связан с конкретной программой организации и не опубликован на главной странице сайта. Его получение требовало предварительной разведки.
Язык письма - русский, адаптирован под целевую аудиторию.
Легенда - рекламный аккаунт Facebook - правдоподобна именно для правозащитной НКО, использующей Facebook для информационных кампаний.
Kill Chain
# | Этап | Описание |
|---|---|---|
1 | Подготовка инфраструктуры | Регистрация readlundy[.]com (15.08.2025). Подключение к Resend.com, настройка SPF/DKIM. Перехват skillbaseltd[.]co[.]uk (13.10.2025). Размещение фишинговой страницы |
2 | Разведка цели | Сбор email-адреса конкретной программы организации. Изучение деятельности для создания правдоподобной легенды |
3 | Создание приманки | Письмо на русском, имитация Meta. Display Name «M e t a». Логотип с |
4 | Доставка | Resend.com → Amazon SES → Gmail. SPF pass, DKIM pass. Доставлено во входящие |
5 | Сбор данных | Кнопка «Начать проверку» → skillbaseltd[.]co[.]uk. Предполагаемая цель: кража логина/пароля Facebook, OTP/2FA, cookies сессии (страница недоступна на момент расследования, содержимое не наблюдалось напрямую) |
Атака остановлена между этапами 4 и 5 - письмо доставлено, но распознано как фишинг до перехода по ссылке.
IOC
Тип | Значение | Описание |
|---|---|---|
| Адрес отправителя | |
Domain |
| Домен отправки |
Domain |
| SPF-домен рассылки (Resend) |
Domain |
| Фишинговый хостинг |
URL |
| Фишинговый URL (кнопка «Начать проверку») |
IP |
| SMTP: Amazon SES (ap-northeast-1, Токио) |
IP |
| Хостинг: Cloudflare CDN |
Message-ID |
| Идентификатор Amazon SES |
Domain |
| Связанная инфраструктура: Resend+SES готов, не использован |
Domain |
| Связанная инфраструктура: Resend+SES готов, не использован |
Domain |
| Связанная инфраструктура: Resend+SES готов, не использован |
MITRE ATT&CK
Техника | ID | Применение |
|---|---|---|
Acquire Infrastructure: Domains | T1583.001 | Регистрация readlundy[.]com через Sav.com |
Acquire Infrastructure: Web Services | T1583.006 | Resend.com + Cloudflare |
Compromise Infrastructure: Domains | T1584.001 | Перехват skillbaseltd[.]co[.]uk |
Establish Accounts: Email Accounts | T1585.002 | Аккаунт identity-policy@readlundy[.]com |
Phishing: Spearphishing Link | T1566.002 | Целевое письмо с фишинговой ссылкой |
Input Capture: Web Portal Capture | T1056.003 | Фишинговая страница для кражи учётных данных |
Impersonation | T1656 | Имитация Meta, логотип с |
Masquerading | T1036 | Display Name «M e t a» с пробелами |
Что делать
Если получили такое письмо
Не переходить по ссылкам и не вводить учётные данные.
Проверить адрес отправителя - не Display Name, а envelope From (Return-Path). Настоящие письма Meta приходят с
facebookmail.comилиmeta.com.Навести курсор на кнопку - посмотреть реальный URL. Если это не
facebook.com- фишинг.Если перешли по ссылке: немедленно сменить пароль Facebook, завершить все активные сессии, проверить список администраторов страницы и привязанные приложения.
Пометить как фишинг в Gmail.
Для аккаунтов 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-IDAmazon 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