Основные выводы
В период с 22 по 27 сентября 2026 года злоумышленники перехватили реестры ccTLD .gh, .sl и .as и получили 12 публично доверенных TLS-сертификатов для доменов Google и YouTube без компрометации самого Google или центров сертификации, выдавших эти сертификаты.
Изменив авторитетные DNS-записи, злоумышленники успешно прошли проверки подтверждения домена. Контроль над DNS превратился в контроль над выпуском сертификатов — это сценарий, который ранее наблюдался в 2012 PKNIC breach и кампании Sea Turtle. Организации наследуют риски от реестров, регистраторов и DNS-провайдеров, которые они не контролируют, особенно в рамках портфелей региональных, приобретенных и имиджевых (vanity) доменов.
Непрерывный мониторинг делегирования DNS, журналов Certificate Transparency (CT) и политик авторизации центров сертификации (CAA) позволяет обнаружить следы, которые оставляет атака подобного типа.
Восстановление после компрометации DNS требует расследования и отзыва сертификатов, выпущенных в затронутый период, а не только восстановления записей DNS.
Как злоумышленники задействовали DNS ccTLD для кражи доменной идентичности
Согласно Google’s disclosure on October 6, 2026, злоумышленники, скомпрометировавшие реестры трех национальных доменов верхнего уровня (ccTLD), получили по меньшей мере 12 публично доверенных TLS-сертификатов для доменов Google и YouTube в зонах .gh (Гана), .sl (Сьерра-Леоне) и .as (Американское Самоа). Google не раскрыла информацию о том, каким образом были скомпрометированы реестры.
Злоумышленники изменили авторитетные DNS-записи для выбранных доменов в рамках перехваченных ccTLD, что позволило им успешно пройти процесс проверки домена, используемый при выдаче сертификатов.
Журналы CT показывают появление сертификатов в затронутых TLD в течение нескольких дней: .gh 22 сентября, .sl 25 сентября и .as 27 сентября. Let's Encrypt выдала 11 сертификатов, а ZeroSSL выдала один. Все 12 had been revoked by October 1.
Google заблокировала их в Chrome с помощью CRLSets и совместно с выдавшими их центрами сертификации (CA) занялась их отзывом, однако другие браузеры и клиенты зависят от такого отзыва со стороны CA, чтобы оставаться защищенными. Журналы CT также продемонстрировали несанкционированные сертификаты для доменов, принадлежащих другим мировым брендам и онлайн-сервисам, и Google уведомила затронутые организации.
Компания Google заявила, что ее собственная инфраструктура не была скомпрометирована и нет никаких признаков взлома самих центров сертификации. Злоумышленники нацелились на то, что находится выше обоих этих уровней: на DNS. Получив контроль над авторитетным путем DNS для затронутых доменов, они смогли временно продемонстрировать контроль над этими именами. После этого экосистема сертификатов действовала в основном так, как и задумывалось.
Почему контроль над DNS означает контроль над сертификатами
Это была не просто проблема сертификатов или проблема DNS. Данный инцидент показал, насколько тесно они связаны между собой.
Этот сценарий не нов. В 2012 году в результате взлома пакистанского реестра PKNIC были перенаправлены сотни доменов .pk, включая google.com.pk. Позже поддерживаемая государством кампания Sea Turtle (исследователи не приписали кампанию какому-либо конкретному государству) использовала компрометацию реестров и DNS-провайдеров для получения сертификатов для перехваченных доменов.
Контролируйте DNS и при определенных обстоятельствах вы можете получить контроль над выпуском сертификатов.
Почему это важно, если вы не Google
Google смогла отреагировать в течение нескольких дней, поскольку видела сертификаты, имела прямые отношения с выдавными их CA и могла заблокировать их в своем собственном браузере. Большинство организаций не имеют ни одного из этих преимуществ, поэтому им необходимо самостоятельно отслеживать признаки атаقات, в том числе:
- Делегирование серверов имен (NS): любые неожиданные изменения в принадлежащем вам домене, особенно в наиболее ценных
Делегирование серверов имен (NS): любые неожиданные изменения в принадлежащем вам домене, особенно в наиболее ценных
- Авторитетные DNS-записи: изменения, которые вы не вносили, включая записи, которые могут быть использованы для прохождения проверочного запроса
Авторитетные DNS-записи: изменения, которые вы не вносили, включая записи, которые могут быть использованы для прохождения проверочного запроса
- Журналы CT: новый сертификат для любого из ваших доменов, включая припаркованные и региональные имена ccTLD, от эмитента, которого вы обычно не используете (в данном инциденте это означало сертификаты Let's Encrypt и ZeroSSL на доменах, где легитимные сертификаты Google поступали от Google Trust Services)
Журналы CT: новый сертификат для любого из ваших доменов, включая припаркованные и региональные имена ccTLD, от эмитента, которого вы обычно не используете (в данном инциденте это означало сертификаты Let's Encrypt и ZeroSSL на доменах, где легитимные сертификаты Google поступали от Google Trust Services)
- Записи CAA: политика, которая применяется прямо сейчас, а не та, что отображается на вашей панели управления конфигурацией
Записи CAA: политика, которая применяется прямо сейчас, а не та, что отображается на вашей панели управления конфигурацией
Если не отслеживать эти сигналы, первым признаком проблемы может стать уведомление от кого-то другого, как это произошло с другими брендами, с которыми связался Google.
Аналогичные риски существуют везде, где домен зависит от реестра, который вы никогда не оценивали. Региональные сайты, приобретенные бренды, домены рекламных кампаний и имиджевые домены часто размещаются под управлением десятков реестров с совершенно разными подходами к безопасности. Вы можете полностью контролировать свой основной домен .com, не имея при этом практически никакой видимости инфраструктуры национального домена, зарегистрированного много лет назад.
По мере того как предприятия переходят на архитектуры агентского ИИ, автономные агенты все чаще вызывают API и динамически извлекают контекст в распределенных доменах. Агент не сможет интуитивно обнаружить поддельный хост, если базовый путь DNS и TLS-сертификат проходят проверку успешно. Когда доверие к DNS рушится, это не просто ставит под угрозу веб-пользователей — это также подрывает целостность каждого автономного межмашинного рабочего процесса, работающего в вашей экосистеме.
Почему проверка домена становится слабым местом
TLS-сертификаты с проверкой домена опираются на фундаментальное предположение: организация, способная продемонстрировать контроль над доменом, имеет право запрашивать для него сертификат.
Центры сертификации могут подтвердить этот контроль с помощью таких механизмов, как проверки на основе DNS или валидация на основе HTTP.
Обычно эта модель работает хорошо. Но если злоумышленник получает контроль над инфраструктурой, отвечающей за обработку таких запросов на проверку, предположение о доверии может быть нарушено. Например, злоумышленник, способный манипулировать авторитетными DNS, может успешно пройти проверку на основе DNS. В зависимости от затронутой инфраструктуры и метода валидации, манипуляции с DNS могут также повлиять на то, куда направляется трафик проверки HTTP.
Злоумышленникам необязательно иметь доступ к облачной среде организации, поставщику удостоверений, веб-серверу или платформе управления сертификатами. Им нужно, чтобы система проверки видела именно то, что они хотят показать. Как только публично доверенный сертификат выдан, у злоумышленников появляется еще один компонент, необходимый для выдачи себя за легитимные сервисы, в то время как исходная компрометация DNS продолжает действовать.
Команды безопасности часто рассматривают сертификаты и DNS как отдельные операционные дисциплины. С точки зрения злоумышленника, это единая цепочка доверия.
Цепочка доверия простирается за пределы вашей среды
Большинство организаций вкладывают значительные средства в то, что находится под их непосредственным контролем:
- Облачные учетные записи
Облачные учетные записи
- Приложения
Приложения
- Системы управления учетными записями
Системы управления учетными записями
- Конечные точки
Конечные точки
- Системы управления сертификатами
Системы управления сертификатами
- Авторитетная конфигурация DNS
Авторитетная конфигурация DNS
Но домены также зависят от инфраструктуры, находящейся вне непосредственного контроля организации.
Цепочка может выглядеть примерно так:
Реестр → Регистратор → Провайдер DNS → Авторитетный DNS → Проверка сертификата → TLS-сертификат → Приложение
Компрометация любой критической точки в этой цепочке меняет предположения на дальнейших этапах.
Это особенно важно для организаций, управляющих крупными глобальными портфелями доменов.
Ситуация усугубляется принципом «настроил и забыл», характерным для DNS. Запись создается для запуска, другая — во время миграции в облако, региональная команда регистрирует страновой домен, а в результате слияния или поглощения появляются еще сотни. Годы спустя право собственности меняется, приложения перемещаются, и ни у кого нет полной картины. Ваша поверхность атак DNS — это не только платформа, которой вы активно управляете, это вся цепочка зависимостей вокруг ваших доменов.
5 критических вопросов о DNS, которые нужно задать прямо сейчас
Обращайте внимание на два сигнала:
- Изменения в делегировании NS для ценных доменов
Изменения в делегировании NS для ценных доменов
- Сертификаты от неожиданных издателей
Сертификаты от неожиданных издателей
В этом инциденте легитимные сертификаты для google.com.gh, google.sl и google.as были выданы Google Trust Services, в то время как неавторизованные поступили от Let's Encrypt и ZeroSSL. Сама компания Google рекомендует проводить постоянный мониторинг CT (Certificate Transparency) для всех доменов организации, включая припаркованные и региональные ccTLD-домены. Мониторинг CT наиболее полезен, когда события сопоставляются с вашим реестром доменов и утвержденной политикой сертификатов, чтобы вы могли быстро ответить на вопрос: «Является ли этот сертификат легитимным?»
Знаем ли мы каждый принадлежащий нам домен и от какого реестра и какой инфраструктуры DNS зависит каждый из них?
Отвечая на этот вопрос, учитывайте региональные сайты, приобретенные бренды, домены кампаний, именные домены и защитные регистрации, а не только основные корпоративные домены. Связывание каждого домена с его реестром и авторитетным DNS делает внешние зависимости видимыми до того, как это сделает расследование инцидента.
Ограничены ли центры сертификации должным образом с помощью CAA?
Записи CAA позволяют указать, какие ЦС (CA) могут выпускать сертификаты для ваших доменов. Они не заменяют защиту DNS, поскольку сам DNS-путь, обслуживающий CAA, может подвергнуться манипуляциям. Но ограничительная политика сокращает пути выпуска, доступные злоумышленнику, и имеет решающее значение при восстановлении.
Проверили ли мы политику CAA, которая фактически обслуживается?
Запись, настроенная в какой-то момент времени, не то же самое, что политика, разрешающаяся прямо сейчас. Панели мониторинга не всегда отражают полную картину. Проверяйте внешне разрешаемую запись.
Узнали бы мы быстро, если бы делегирование, авторитетный DNS или выпуск сертификатов изменились неожиданным образом?
Обращайте внимание на два сигнала:
- Изменения в делегировании NS для ценных доменов
Изменения в делегировании NS для ценных доменов
- Сертификаты от неожиданных издателей
Сертификаты от неожиданных издателей
Учитывает ли наш процесс реагирования на инциденты выпуск сертификатов после компрометации DNS?
Восстановление DNS — это лишь часть процесса восстановления. Изучите сертификаты, выданные в затронутый период, отозвали неавторизованные, проверьте состояние проверки там, где это применимо, и убедитесь, что политики защитного DNS снова действуют.
Как Akamai DNS Posture Management может помочь
Более общий урок заключается в том, что безопасность DNS не может сводиться к защите DNS-сервера. Она зависит от понимания взаимосвязей между доменами, реестрами, регистраторами, авторитетной инфраструктурой и сертификатами.
Вот как решение Akamai DNS Posture Management может помочь вам ответить на эти пять критических вопросов:
- Знайте, чем владеете: просматривайте каждый домен и его зависимости DNS от разных провайдеров в едином инвентарном списке, включая региональные и унаследованные домены, регистрацию которых никто не помнит
Знайте, чем владеете: просматривайте каждый домен и его зависимости DNS от разных провайдеров в едином инвентарном списке, включая региональные и унаследованные домены, регистрацию которых никто не помнит
- Устраните пробелы в CAA: находите отсутствующие или слишком либеральные политики CAA и проверяйте, соответствует ли обслуживаемая внешне политика вашим намерениям
Устраните пробелы в CAA: находите отсутствующие или слишком либеральные политики CAA и проверяйте, соответствует ли обслуживаемая внешне политика вашим намерениям
- Быстро обнаруживайте изменения: получайте оповещения при отклонении делегирования или DNS от известного безопасного исходного состояния, а также при появлении сертификата от не одобренного вами издателя наряду с поддельными, неправильно настроенными или просроченными сертификатами.
Быстро обнаруживайте изменения: получайте оповещения при отклонении делегирования или DNS от известного безопасного исходного состояния, а также при появлении сертификата от не одобренного вами издателя наряду с поддельными, неправильно настроенными или просроченными сертификатами.
- Уверенно восстанавливайте системы: быстро определяйте затронутые домены и сертификаты, сохраняйте историю изменений и проверяйте, что политики DNS и сертификатов вернулись в ожидаемое состояние
Уверенно восстанавливайте системы: быстро определяйте затронутые домены и сертификаты, сохраняйте историю изменений и проверяйте, что политики DNS и сертификатов вернулись в ожидаемое состояние
- Снижайте риски заранее: проверяйте развертывание DNSSEC, поддержку регистраторов и средства защиты реестра (такие как блокировка реестра), а также помечайте устаревшие или «висячие» записи
Снижайте риски заранее: проверяйте развертывание DNSSEC, поддержку регистраторов и средства защиты реестра (такие как блокировка реестра), а также помечайте устаревшие или «висячие» записи
В этом инциденте предупреждение о google.com.gh позволило бы выявить сертификат от центра сертификации, который домен никогда не использовал (каждый предыдущий сертификат был выдан Google Trust Services), а также любые изменения в делегировании домена или его записях DNS. В этом и заключается разница между тем, чтобы узнать об этом от разработчика браузера, и тем, чтобы заметить это в день происшествия.
Это связывает безопасность DNS с принципом, который команды безопасности уже знают: защищенность — это не конфигурация, которую вы устанавливаете один раз, это состояние, которое вы непрерывно проверяете.
Суть вкратце
Организации могут защитить свои приложения, облачные среды, учетные записи и инфраструктуру сертификатов и все равно унаследовать риски от вышестоящей инфраструктуры.
Возможно, вы не сможете помешать компрометации национального реестра. Но вы можете понять, какие критически важные активы зависят от него, ограничить выпуск сертификатов там, где это уместно, отслеживать DNS и CT на предмет неожиданной активности и построить процесс восстановления, который выходит за рамки простого восстановления DNS-записи.
Когда выпуск сертификатов зависит от доказательства контроля над доменом, DNS не просто направляет трафик — DNS является частью модели доверия.
Свяжитесь с представителем Akamai сегодня, чтобы запланировать демонстрацию и узнать, как DNS Posture Management может укрепить общую безопасность вашей организации.
Об авторе
Чатурбхудж Сингх (Chaturbhuj Singh)
Chaturbhuj Singh — директор по разработке в CheckRed и архитектор Akamai DNS Posture Management. Он руководит инженерными командами, которые проектируют, создают и масштабируют платформу, задавая техническое направление для непрерывного обнаружения и устранения неправильных конфигураций и рискованных зависимостей в облаках, SaaS и DNS, что помогает предприятиям снижать риски в сложных многопоточных средах.
Чтобы защитить эту динамическую экосистему, организациям необходимо начать с базового сетевого уровня. Им нужна радиолокационная система.
Безопасность
Картографирование современных нечеловеческих взаимодействий требует более совершенного радара
Нечеловеческие идентификаторы превосходят человеческие в соотношении 45 к 1. Узнайте, как микросегментация на Уровнях 3 и 4 обеспечивает радар, необходимый для картирования и защиты трафика агентов ИИ.
Задержка дает медицинским организациям больше времени на подготовку к возможным новым требованиям кибербезопасности.
Безопасность
Правило безопасности HIPAA отложено до 2027 года: почему здравоохранение не может ждать
Обновление правила безопасности HIPAA отложено до июля 2027 года. Узнайте, что новые мандаты кибербезопасности будут означать для здравоохранения и как подготовиться к ним уже сейчас.
Безопасность и соответствие требованиям должны служить защитными барьерами, а не ограничениями скорости.
Безопасность
Защита конфиденциальных данных с помощью Cyera и Akamai Guardicore Segmentation
Защитите конфиденциальные данные, объединив обнаружение данных от Cyera с сегментацией Akamai Guardicore Segmentation для применения динамических правил микросегментации с учетом данных.
