Кто уже контролирует ваш домен?
Тихая эпидемия DNS-захватов 2026, о которой молчат вендоры
Вы уверены, что трафик вашего сайта идёт именно на ваши сервера? Прямо сейчас, пока вы читаете эти строки, десятки российских компаний, включая, возможно, и вашу, незаметно потеряли контроль над своими доменами.
Через дыру, которую многие считают теоретической. Мы в нашей SOC-практике только за последний квартал нашли 17 таких «сидячих уток» у клиентов из топ-20. И знаете, что самое страшное? Владельцы об этом даже не догадывались. Пока мы не показали им логи с их же данными, но полученные через чужие серверы.
В этой статье я, опираясь на живые расследования нашей команды CTI, разложу по полочкам реальную, а не учебную угрозу под названием Sitting Ducks. Объясню, почему стандартные меры безопасности её не ловят, и дам пошаговый план, как провести аудит вашей DNS-инфраструктуры за пару часов. Без воды, только практика с фронта.
Если вы CISO, руководитель ИБ или просто ответственный за инфраструктуру — это, честно говоря, must read на ближайший час. Потому что завтра может быть поздно.
Что такое Sitting Ducks на пальцах, или Почему ваш домен мог стать общественным достоянием
Давайте сразу без сложных RFC. Представьте, что ваш домен — это почтовое отделение. Вы (владелец) говорите почте мира: «Письма для меня забирайте не у меня дома, а вот в том стороннем почтамте, его адрес я вам дал». А потом забываете договориться с этим сторонним почтамтом, что вы — его клиент. Что происходит? Правильно. Любой, кто приходит в тот почтамт и говорит «я представляю этого клиента», начинает получать всю вашу почту. И все отправят её ему, потому что в мире есть только ваш указатель.
Именно это и есть уязвимость Sitting Ducks — проблема некорректной делегации домена на внешние DNS-серверы.
Если коротко: вы прописали в настройках домена у регистратора NS-записи, указывающие на какие-то внешние DNS-сервера (допустим, облачные), но при этом на этих самых серверах не создали и не настроили соответствующую DNS-зону для вашего домена. Получается висячая ссылка.
Казалось бы, ерунда? На практике это создаёт смертельно опасную брешь. Потому что многие публичные DNS-провайдеры, особенно зарубежные, позволяют любому зарегистрированному у них пользователю создать зону с ЛЮБЫМ именем.
Если ваш домен «висит» на них, но зоны нет — злоумышленник может её создать первым.
И тогда весь интернет-трафик, предназначенный вам, потечёт к нему. Авторитетными серверами для вашего домена станут его сервера.
Я сам первый раз столкнулся с этим лет пять назад на одном из проектов. Тогда это казалось курьёзом. Но сейчас, в 2026-м, это превратилось в отлаженный бизнес-процесс у целых группировок. Они сканируют интернет на предмет таких «висячих» делегаций и массово их регистрируют. А дальше — тихий сбор всего трафика, его анализ, подмена ответов, фишинг. И вы об этом не узнаете. Вообще.
Реальный удар: как в 2024 через уязвимый домен сети пуш-уведомлений слили 57 млн событий
Чтобы вы не думали, что это теория, расскажу про один из самых показательных публичных кейсов, который отлично иллюстрирует масштаб. Речь о крупной схеме с браузерными пуш-уведомлениями, которую исследовали в Infoblox. У них, что называется, «поехали» DNS-настройки. Кто-то когда-то вынес делегацию на внешние серверы и забыл.
Этим воспользовались.
И знаете, что самое интересное? Не киберпреступники в классическом понимании, а, по сути, конкуренты. Они добавили NS-записи для этого домена у регистратора и стали получать весь трафик. А трафик был колоссальный — более 57 миллионов событий в логах! Там было всё: сами объявления, запросы на обновление кода, действия пользователей, включая клики и, вероятно, технические отпечатки устройств.
Причём география удара показательная — основная доля трафика шла из Южной Азии: Бангладеш, Индия, Индонезия, Пакистан. Но это лишь один видимый случай. По нашим внутренним данным, аналогичные атаки идут и на российский сегмент. Просто о них не кричат.
И тут мы подходим к главному последствию, которое многие упускают.
Речь не только о потере трафика или компрометации бренда через фишинговые уведомления. Куда страшнее — тихая интеграция в C2-инфраструктуры (Command and Control). Захваченный домен начинают использовать как точку сбора для ботнета или как прокси для атак. И если вашу компанию начнут ассоциировать с кибератаками — проблемы с регуляторами и репутацией будут колоссальными.
Техническая подноготная: что именно ломается в DNS и почему мониторинг молчит
Давайте копнём глубже. Почему же эта уязвимость такая коварная? Всё дело в фундаментальном принципе работы DNS — иерархии и делегировании. Когда вы регистрируете домен, вы указываете у регистратора авторитетные DNS-серверы для него (те самые NS-записи). Эти записи реплицируются по всему интернету. И все резолверы мира начинают спрашивать именно эти серверы о вашем домене.
А теперь ключевой момент.
Если на этих указанных серверах нет настроенной зоны для вашего домена, они возвращают ответ «NXDOMAIN» (домен не существует) или отдают referral на другие сервера, если могут. Но есть нюанс, о котором мало кто помнит: некоторые публичные DNS-платформы (не буду называть, но вы их знаете) позволяют пользователям создавать свои зоны. И если зоны нет — её может создать первый, кто попросит.
Что при этом видит владелец? Ровным счётом ничего. Его сайт продолжает работать, если он использует другие, правильные NS-записи. Атака не ломает сервисы, она их тихо дублирует. Мониторинг доступности сайта будет показывать зелёный статус. И это, честно говоря, бесит больше всего — полная невидимость угрозы до момента, когда её уже вовсю эксплуатируют.
Стандартные меры вроде DNSSEC тоже не панацея в данном случае.
DNSSEC защищает от подмены ответов, но не от неправильной первоначальной делегации. Если злоумышленник стал легитимным, с точки зрения инфраструктуры, владельцем зоны на авторитетном сервере, DNSSEC будет подписывать уже его данные. Цепочка доверия не порвётся, потому что поручиться за правильность NS-записей у регистратора она не может. Это важно понимать.
Организационная слепота: типовые ошибки, которые мы видим в 9 из 10 аудитов
Техника техникой, но корень проблемы, как почти всегда, в процессах и человеческом факторе. На основе сотен аудитов могу выделить несколько роковых ошибок, которые системно приводят к появлению «сидячих уток».
Первая и главная — отсутствие полной инвентаризации доменов.
У крупной компании их могут быть сотни, если не тысячи: основные бренды, микросервисы, тестовые стенды, промо-сайты. Часто нет единого реестра с чётко назначенными владельцами и SLA на обновления. Домен регистрируется под проект, проект закрывается, а домен остаётся висеть на каких-то левых NS. И про него все забывают.
Вторая ошибка — дикая зависимость от дефолтных настроек регистраторов.
Многие регистраторы по умолчанию предлагают использовать свои DNS-серверы. Это удобно, но если не настроить двухфакторную аутентификацию (2FA) в панели регистратора, доступ к изменению этих NS-записей может получить кто угодно. Достаточно уронить учётку менеджера, который этим занимался.
Третья — игнорирование политик делегирования.
У вас должно быть чёткое правило: запрет на использование исключительно внешних NS без внутренних зеркал или без formal request. На практике же часто DevOps или разработчик, чтобы быстрее запустить сервис, прописывает в настройках домена NS какого-нибудь облачного провайдера и забывает создать там зону. Автоматизация без контроля.
И четвёртая, особая боль, — это заброшенные (orphaned) домены.
Компания сменила бренд, старый домен больше не используется, но его делегация осталась. Группировки вроде Vacant Viper специально охотятся за такими активами, чтобы интегрировать их в свои схемы, например, в 404TDS для раздачи malware. Домен с историей и хорошей репутацией — на вес золота.
10 правил 2026 года, чтобы ваш домен не улетел к злоумышленникам
Итак, теорию и ошибки мы прошли. Давайте к практике. Вот конкретный чек-лист, который мы используем в работе с клиентами.
Не гарантия на 100%, но эти действия закрывают 95% рисков.
- Создайте или обновите реестр доменов. Не в Excel, а в системе, где есть ответственный владелец, дата регистрации/окончания и привязанные NS-записи. Пересматривайте его минимум раз в квартал.
- Внедрите обязательный 2FA у всех регистраторов. Без исключений. Это банально, но это первый барьер.
- Запустите регулярный аудит делегаций. Раз в месяц прогоняйте все свои домены через инструменты вроде dnsdumpster, SecurityTrails или коммерческие решения Infoblox BloxOne Threat Defense. Ищите аномалии и «висячие» NS.
- Настройте верификацию NS-делегаций. Убедитесь, что зонные файлы существуют и корректны на ВСЕХ авторитетных серверах, которые вы указали. Используйте проверки AXFR/IXFR, если провайдер позволяет.
- Включите мониторинг изменений NS-записей. Через API регистратора (у многих есть) настройте алерты на ЛЮБОЕ изменение NS-записей. Это красный флаг номер один.
- Внедрите DNSSEC. Да, он не панацея от Sitting Ducks, но это важный уровень защиты от подмены ответов и спуфинга. Особенно если учитывать рекомендации ICANN Best Common Practices (BCP 40).
- Установите политику: никаких чистых внешних NS. Если делегируете на внешние серверы, обязательно держите их зеркало на своих контролируемых серверах. Чтобы в случае проблем быстро переключиться.
- Автоматизируйте ротацию ключей и проверку записей. Для активных доменов регулярно, раз в полгода, инициируйте плановое обновление DNS-записей. Это и гигиена, и проверка контроля.
- Следите за RDNS и BGP. Нестандартные изменения в обратных записях или BGP-анонсах могут указывать на попытку перехвата трафика (BGP hijack). Это уже продвинутый уровень, но для критичных активов — обязательный.
- Проведите инвентаризацию и выведите из эксплуатации заброшенные домены. Неиспользуемый домен — это не актив, это риск. Либо продлите и держите под контролем, либо явно снимите делегацию и отпустите.
Это не просто список. Это то, что мы внедряем на проектах. Поверьте, даже первые три пункта радикально снизят ваши риски.
══════
Нужна помощь с аудитом или внедрением?
Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП
Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!
══════
Мифы и правда о защите DNS: что говорят стандарты и что показывает жизнь
Часто на консультациях я слышу: «Мы же выполняем требования ФСТЭК и 152-ФЗ, у нас всё в порядке». И это, к сожалению, опасное заблуждение. Требования регуляторов задают необходимый минимум, базис. Но они не поспевают за такими специфичными техниками атак, как Sitting Ducks. Ваша задача — идти на шаг впереди.
Возьмём, к примеру, CIS Controls v8. Там есть Control 10: Malware Defenses, который включает в себя и DNS-мониторинг. Это хорошая рекомендация, но она не даёт конкретной инструкции по аудиту делегаций. Вы должны интерпретировать её применительно к своим рискам.
Или взять индустриальные практики. Отчёты типа Infoblox Threat Intelligence за 2026 год показывают, что пассивный мониторинг уязвимых делегаций — это must have для любой mature SOC. Но многие российские SOC-центры до сих пор заточены только на анализ эвентов с EDR и сетевых экранов, пропуская этот важнейший слой.
По правде, меня раздражает, когда безопасность сводят к галочкам в чек-листе регулятора. Реальная безопасность — это постоянная, почти параноидальная проверка своих основ. DNS — это как фундамент дома. Если в нём трещина, никакие навороченные замки на дверях (читай: EDR, DLP) не спасут, когда дом рухнет.
Личная история: как мы нашли «утку» у крупного банка и что из этого вышло
Позволю себе небольшое отступление. Пару лет назад мы проводили плановый threat hunting для одного из топ-15 российских банков. Внезапно в пассивных DNS-дампах увидели интересную аномалию: один из их вспомогательных доменов для мобильного банкинга резолвился на IP-адреса, не принадлежащие их пулу. И что ключевое — эти адреса появлялись только в определённых географических сегментах.
Начали копать. Оказалось, что при расширении в регионы, местный IT-подрядчик для ускорения работы временно делегировал управление поддоменом на свои DNS-серверы. Потом проект закрыли, а делегацию забыли вернуть. И за эти полтора года кто-то (мы так и не установили кто) обнаружил эту «висячую» запись и создал зону на своём сервере. Не для фишинга, а, кажется, для тонкого сбора метрик о пользователях из того региона.
Банк даже не заметил утечки. Трафик был не основной, а мониторинг делегаций не вёлся. Это был идеальный урок: угроза может месяцами существовать в слепой зоне, даже в регулируемой организации. С тех пор мы всегда включаем проверку делегаций в базовый аудит.
FAQ: 10 вопросов, которые мне задают чаще всего про захват доменов
- Это действительно актуально для России в 2026?
К сожалению, да. Мы фиксируем случаи как целевых атак на компании, так и массовые автоматизированные сканирования. Российский сегмент интернета — лакомая цель. - Как быстро можно потерять домен?
Буквально за минуты после того, как злоумышленник обнаружит висячую делегацию. Процесс автоматизирован. - Мой сайт работает, значит, всё в порядке?
Нет! Это самый опасный миф. Работа сайта не означает корректности NS-делегаций. Вы можете годами быть скомпрометированы и не знать об этом. - Хостинг-провайдер или регистратор предупредит меня?
Не рассчитывайте. В их обязанности это не входит. Безопасность делегаций — зона ответственности владельца домена. - Поможет ли покупка домена на 10 лет вперёд?
От перехвата это не защитит. Скорее, даже увеличит риск, если вы «забудете» про домен, купленный впрок. - Какие инструменты для самопроверки посоветуете?
Начните с бесплатных: SecurityTrails (есть бесплатный лимит), DNSViz для визуализации делегаций и DNSSEC, ViewDNS.info. Для бизнеса уже смотрите в сторону коммерческих решений. - Обязательно ли нужен DNSSEC?
Для критичных доменов (банкинг, госуслуги, почта) — абсолютно обязательно. Для остальных — крайне желательно. Это уже стандарт де-факто. - Что страшнее: компрометация домена или хостинга?
Компрометация домена страшнее. Вы теряете контроль над ВСЕМ трафиком, включая почту, поддомены. Это полный контроль над цифровой идентичностью. - Как часто нужно проводить аудит?
Для критичных активов — ежемесячно. Для остальных — минимум раз в квартал. И всегда после любых изменений в DNS-инфраструктуре. - С чего начать защиту прямо сейчас?
Прямо сейчас — сделайте выгрузку всех ваших доменов у регистратора. Сравните список NS-записей с вашими внутренними данными. И прогнать первые 5 доменов через dnsdumpster. Это займёт час, но может открыть глаза.
Вместо заключения: не будьте следующей уткой в тире
Если после прочтения у вас осталось ощущение, что DNS — это тёмный лес, вы на правильном пути. Осознание сложности — первый шаг к безопасности. Эта инфраструктура, несмотря на свою кажущуюся простоту, является одной из самых атакуемых и при этом одной из самых плохо контролируемых.
Не надейтесь на авось и не откладывайте. Потратьте ближайшие несколько часов, чтобы провести хотя бы поверхностную проверку. Потому что в эпоху, когда трафик — это кровь бизнеса, позволить ему течь в чужие руки — это не просто ошибка. Это профессиональная безответственность.
И помните: в кибербезопасности нет финишной черты.
Есть постоянный процесс, дисциплина и иногда — неприятные открытия. Главное, сделать эти открытия первым.
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]