У мошенников нет ничего святого! Хакеры взялись за Google: подделка подписей теперь не обязательна, ведь можно заставить Google подписывать фишинговые письма валидным DKIM самостоятельно. Если раньше опытный ИБ-специалист мог сходу разобраться, где фишинговое письмо, а где — нет, сейчас это сделать в разы сложнее. И дело вовсе не в популярных нейронках, изощренном социальном инжиниринге или слитых базах.
Несем вам горячий кейс о том, как мошенники научились злоупотреблять настройкой OAuth-приложений, используя официальные инструменты Google для отправки поддельных писем от no-reply@accounts.google.com.
Спойлер: хотя Google уже устранил возможность вставлять произвольный текст в название OAuth-приложений, сама техника повторного использования легитимной DKIM-подписи никуда не делась. На её основе по-прежнему можно реализовать сценарии, позволяющие обходить DKIM-аутентификацию.
Изучаем матчасть
Протоколы аутентификации электронной почты — SPF, DKIM и DMARC — были разработаны, чтобы предотвратить спуфинг (подделку имени отправителя) и защитить пользователей от фишинга. В совокупности они позволяют удостовериться, что письмо пришло от разрешенного сервера (SPF), что его содержимое не было подменено (DKIM) и что оно соответствует заявленной политике домена (DMARC). Однако, как показывает DKIM replay-атака, о которой стало известно в апреле 2025 года, даже эти технологии могут быть использованы против самих пользователей, если архитектура реализована с допущениями.
SPF (Sender Policy Framework) — это специальная TXT-запись в DNS, которая перечисляет серверы, имеющие право отправлять письма от имени домена. Когда приходит письмо, почтовый сервер получателя обращается к этой записи и сравнивает IP-адрес отправителя с разрешенными в списке. При этом SPF проверяет не поле From, которое видит пользователь, а технический адрес (envelope MAIL FROM). Поэтому SPF сам по себе не защищает от подмены отправителя.
yourdomain.com. TXT "v=spf1 ip4:1.2.3.4 include:_spf.google.com -all"DKIM (DomainKeys Identified Mail) использует криптографическую подпись письма. Отправитель подписывает тело и определенные заголовки (From, To, Subject) приватным ключом, а получатель проверяет подлинность по публичному ключу из DNS.
Это надежный способ защитить письмо от изменения, но есть нюанс: если злоумышленник перехватит оригинальное подписанное письмо — например, уведомление Google об OAuth-доступе — он может переслать его кому угодно. Подпись при этом всё ещё будет считаться действительной, ведь содержимое и заголовок не менялись. Запомните этот момент.
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<публичный_ключ>"DMARC (Domain-based Message Authentication, Reporting and Conformance) проверяет, совпадает ли домен в поле From c доменом, который прошел проверку SPF или DKIM. Если ни один из механизмов не подтвердил подлинность письма, DMARC определяет, что с ним делать: пропустить, пометить как подозрительное или отклонить.
DMARC эффективен, но не защищает от ситуаций, когда письмо прошло DKIM (пусть и с фальшивой подписью), как в случае с replay-атакой. Если оригинальная подпись Google действительна — DMARC спокойно пропустит такое письмо.
dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"В нормальных условиях эти протоколы помогают фильтрам Gmail отличать легитимные письма от поддельных и снижают риск фишинга. Но в апреле что-то пошло не так.
Что случилось в апреле
Прежде чем приступить к разбору атаки, кратко пройдемся по инфоповоду. Всё началось с записи Ника Джонсона, ведущего разработчика Ethereum Name Service (ENS). Ник получил письмо от no-reply@accounts.google.com с валидной DKIM-подписью, которое Gmail воспринял как легитимное.
Содержание фишингового письма было тщательно продумано. При беглом взгляде оно не вызывает сомнений — все элементы выглядят так, словно сообщение пришло с системного адреса Google. Но внимательный анализ позволяет выявить ключевую деталь: адрес страницы входа находился на поддомене сервиса Google Sites. Именно эта зацепка навела Джонсона на мысль, что перед ним искусно замаскированная фишинговая копия настоящего портала.
Когда Ник начал разбираться в сути происходящего, выяснилось, что механика атаки достаточно проста, но именно в этой простоте и кроется её изощренность. Сценарий выстроен так, что на каждом этапе используется легитимный функционал Google, а итоговое письмо выглядит абсолютно подлинным — вплоть до криптографической подписи.
Механика атаки
Злоумышленники опирались на две ключевые уязвимости в инфраструктуре Google, комбинируя их с техникой DKIM replay attack — приемом, когда легитимное, корректно подписанное письмо повторно отправляется новым адресатам без изменения содержимого, с сохранением валидной DKIM-подписи.
Размещение фишинговой страницы входа на Google Sites
Атакующие задействовали платформу Google Sites — бесплатный конструктор сайтов. На ней они разместили поддельный интерфейс входа, тщательно имитирующий оригинальный дизайн Google.
Если проанализировать URL, с которым столкнулся Ник, мы увидим, что зашито в ссылке:
https://sites.google.com/[u/17918456/d/1W4M_jFajsC8YKeRJn6tt_b1Ja9Puh6_v/edit
• u/17918456 — уникальный идентификатор пользователя или аккаунта;
• /edit — действие: открыть файл для редактирования (перед ним идентификатор документа);
• /d/ — указание, что это документ.
Даже опытному пользователю сложно заметить подмену: на странице можно «загрузить дополнительные документы» или ознакомиться с материалами «дела». Нет никаких очевидных грамматических ошибок или подозрительных вложений.
Переход по любой из ссылок приводит к перезагрузке страницы и вызову формы с повторным запросом авторизации — даже если пользователь уже вошел в свой аккаунт Google ранее:
В норме, при уже активной сессии, Google автоматически определяет пользователя и не требует повторного ввода пароля без явных причин. Любой повторный запрос авторизации должен восприниматься как подозрительный.
Если ввести учетные данные, жертва будет переадресована на страницу сервисной «ошибки»:
В настройках видимости опубликованной страницы злоумышленники запретили поисковым системам индексировать ресурс, чтобы сделать страницу доступной только по прямой ссылке и усложнить обнаружение через поиск или автоматические системы мониторинга.
Генерация и пересылка легитимного письма с валидной DKIM-подписью
Разберем сценарий пошагово.
1. Регистрация фейковых доменов
Злоумышленник регистрирует домен и Google-аккаунт вида me@domain.com. Анализ фишинговых писем показал, что для атаки использовались домены, специально зарегистрированные через Namecheap. Доменные имена маскировались под элементы инфраструктуры Google, например:
googl-mail-smtp-out-198-142-125-38-prod.net
wd-00000000000097d33d0631f6fe58-goog-ssl.com
Атакующие создали бесплатные аккаунты PrivateEmail через Namecheap, используя адреса типа:
mailto:me@googl-mail-smtp-out-198-142-125-38-prod.netЭто позволило злоумышленникам получать уведомления OAuth с валидными DKIM-подписями от Google, при этом используя MX-записи Namecheap вместо оригинальных гугловских MX-записей.
Чем ещё хорош Namecheap? Например, вы можете указать no-reply@accounts.google.com в качестве отправителя:
А дальше всё зависит только от фантазии атакующего:
Вот как выглядят заголовки в таком случае:
for <__________________>; Thu/ 10 Apr 2025 00:27:41 -0400 (EDT)
Resent-From: me@e-fwd-00000000000027d33d0631f6fe59-goog-ssl.com
X-Sieve-Redirected-From: me@e-fwd-00000000000027d33d0631f6fe59-goog-ssl.com
Delivered-To: me@e-fwd--00000000000027d33d0631f6fe59-goog-ssl.com
Received: from DIR-08 (_____________)
by localhost with LMTP
… и результат:
2. Подготовка OAuth-приложения с фишинговым текстом в App Name
Создается OAuth-приложение, где в поле App Name сначала вводится текст фишингового сообщения, затем длинный блок пробелов и фраза «Google Legal Support».
Пример настройки OAuth от Google и блока с пробелами:
Ещё один пример того, что в поле App Name можно внести все, что угодно:
Таким образом, когда Google генерировал уведомление об OAuth-доступе, в теле письма появлялся весь этот текст как часть официального сообщения от системы. Домен при этом был корректно верифицирован в Google Workspace через TXT-запись в DNS, что давало злоумышленникам возможность создавать OAuth-приложения и получать легитимные уведомления.
3. Генерация подписанного уведомления Google
Google автоматически отправляет уведомление безопасности владельцу аккаунта (me@domain.com) о том, что OAuth-приложению предоставлен доступ. Это письмо генерируется системой Google и автоматически подписывается валидным DKIM-ключом. В теле письма отображается содержимое поля App Name, включая весь подготовленный злоумышленником фишинговый текст.
4. Пересылка подписанного письма жертве
Злоумышленник сохраняет полученное уведомление без изменений (включая заголовки, тело письма и DKIM-подпись), а затем пересылает его жертве с другого почтового аккаунта (например, через Outlook или с помощью SMTP-ретранслятора). При этом DKIM-подпись остается неизменной, и письмо успешно проходит проверку как легитимное, поскольку криптографическая подпись Google действительна.
Особую опасность представляет то, что Gmail автоматически размещает подобные фишинговые письма в той же цепочке писем, что и другие легитимные уведомления безопасности от Google. Это вызывает дополнительное доверие у пользователей, поскольку поддельное сообщение визуально интегрируется с потоком настоящих уведомлений от сервиса.
Использование DKIM replay attack
Атакующий пересылает это письмо жертве — напрямую или через цепочку почтовых сервисов (Outlook-аккаунт → SMTP → почтовый провайдер → жертва).
Слабость механизма проверки в том, что DKIM-валидация охватывает лишь содержимое письма и его заголовок, но не содержимое. В результате «чистая» DKIM-подпись останется неизменной и сообщение пройдет все SPF/DKIM/DMARC-проверки.
Почему это сработало?
Создание приложения, в котором в качестве имени используется полный текст фишингового сообщения, а также подготовка фишинговой страницы и поддельного окна входа на первый взгляд кажутся трудоемкой задачей. Однако после первоначальной настройки эту процедуру можно повторять сколько угодно раз, даже если исходная страница будет удалена — особенно учитывая, что найти и удалить страницы на sites.google.com непросто.
Ник отправил об этом отчет в Google. Изначально компания закрыла тикет с пометкой «работает как задумано», но позднее в Google пересмотрели позицию и сообщили, что признают проблему с OAuth и исправят её.
По состоянию на ноябрь 2025 года Google закрыл ключевой вектор атаки, запретив вставку произвольного текста в поле App Name для OAuth-приложений. Но расслабляться пока рано: идея повторного использования легитимной DKIM-подписи остается, а публичные конструкторы типа Google Sites всё ещё могут быть использованы в альтернативных схемах фишинга.
Вместо вывода
Главная сложность обнаружения этой атаки заключается в том, что злоумышленники не просто подделывали письма — они использовали легитимную инфраструктуру для рассылки вредоносного контента. Поскольку письма подписывались валидными DKIM-заголовками от доверенных доменов, они успешно проходили все проверки аутентификации. В результате традиционные инструменты безопасности, которые полагаются на белые списки доменов или ошибки аутентификации, оказывались неэффективны.
Дополнительную сложность создавал тот факт, что Google — одна из самых узнаваемых и доверенных компаний в мире. Когда письмо выглядит как официальное уведомление от Google и при этом проходит аутентификацию, вероятность успеха атаки значительно возрастает.
Для противодействия подобным угрозам недостаточно полагаться на типичные фишинговые свойства писем (грамматические ошибки, странные названия ящиков отправителя) и обнаружение на основе сигнатур. Необходимо понимать, что является нормальным поведением, а что нет: кто обычно отправляет оповещения, как они выглядят и как люди взаимодействуют с письмами.
И главный вывод, который остается в силе: никогда не доверяйте содержимому письма слепо, даже если это письмо имеет валидную DKIM-подпись ?
Материал основан на кейсе исследователя Nick Johnson в X и техническом разборе атаки в блоге EasyDMARC.
Бастион — защищаем бизнес от киберугроз
t.me/bastiontech — делимся собственным опытом, экспертизой, результатами исследований и прогнозами