В июле 2026 года NCSC UK выпустил advisory «UK and Allies urge critical sectors to improve defences against Russian intelligence targeting» - по сути призыв к критическим секторам: хватит игнорировать плохо сконфигурированные роутеры, через которые заходят российские спецслужбы. Отдельно ФБР проводило операции по нейтрализации ботнетов на базе Ubiquiti EdgeRouter, используемых APT28. Типичный сценарий: перенаправление DNS-запросов удалённых сотрудников на серверы, собирающие NTLMv2-хеши и токены Microsoft 365. Корпоративный EDR молчит - атака идёт ниже endpoint, на unmanaged SOHO-роутере, через который проходит весь трафик сотрудника. Ниже - реконструированный kill chain, объединяющий независимо задокументированные факты (кампания MooBot/EdgeRouter, эксплуатация CVE-2023-23397 группой APT28) в гипотетическую цепочку; ни одно advisory не описывает их как единую связанную кампанию. Здесь же - Sigma-правила, Suricata-детекты и SOC playbook для детектирования DNS hijacking через SOHO-роутеры.
Бизнес-логика атаки: зачем APT-группы перенаправляют DNS на роутерах
Цель не сам роутер. Цель - DNS-резолвинг всех устройств за ним. Один скомпрометированный SOHO-роутер позволяет контролировать, какой IP вернётся на запрос кlogin.microsoftonline.com или mail.company.ru. Пользователь вводит правильный URL, видит похожий интерфейс, вводит пароль - и отдаёт credentials атакующему. По данным Verizon DBIR 2025, 38% утечек данных связаны со stolen credentials, а DNS hijacking - один из наименее заметных способов их получить: атака не оставляет артефактов на endpoint. Вообще никаких.Экономика для атакующего тоже красивая: по данным IBM X-Force 2025, среднее время от публикации CVE до устранения в организации - 29 месяцев. Для SOHO-роутеров удалённых сотрудников, не входящих в scope корпоративного patch management, это время фактически бесконечно - никто их не патчит, и все это знают. По данным Mandiant M-Trends 2025, 57% организаций узнают об инциденте от внешних источников. Так заканчиваются многие подобные кампании - не внутренним детектом, а звонком от ФБР или письмом от CERT.
Kill chain: от компрометации SOHO-роутера до кражи токенов M365
Ниже - гипотетическая реконструкция kill chain DNS hijacking через SOHO-роутеры, объединяющая независимо задокументированные техники APT28/Forest Blizzard (MooBot, EdgeRouter) и известные CVE в единую цепочку, которая как целое не описана ни в одном advisory. Декомпозиция по этапам MITRE ATT&CK.| Этап | Техника MITRE ATT&CK | ID и тактика | Конкретика кампании |
|---|---|---|---|
| Подготовка | Network Devices | T1584.008, Resource Development | Массовая компрометация SOHO-роутеров (Ubiquiti EdgeRouter, TP-Link TL-WR841N). Использование существующего ботнета MooBot для initial access к EdgeRouter |
| Доступ к роутеру (TP-Link) | CVE-2023-50224 | CWE-290 | Раскрытие credentials через httpd на TP-Link TL-WR841N без аутентификации |
| Доступ к роутеру (EdgeRouter) | Дефолтные credentials | Misconfiguration | Дефолтные ubnt/ubnt на Ubiquiti EdgeRouter - не CVE, а misconfiguration, эксплуатируемая ботнетом MooBot |
| DNS spoofing | Impersonation | T1656, Defense Evasion | Перенаправление DNS-ответов на attacker-controlled серверы с фишинговыми login-страницами M365 |
| Credential harvesting | Name Resolution Poisoning and SMB Relay | T1557.001, Credential Access / Collection | Сбор NTLMv2-хешей и OAuth-токенов. Python-скрипты на роутере для real-time валидации украденных credentials |
| Persistence | Patch System Image | T1601.001, Defense Evasion | Модификация firmware - malware переживает reboot |
| Маскировка C2 | Internal Proxy | T1090.001, Command and Control | Роутер как прокси для маскировки дальнейших операций |
CVE-2023-50224 (TP-Link TL-WR841N, CWE-290 - Improper Authentication): уязвимость в httpd-сервисе на TCP-порту 80 позволяет сетевому атакующему без аутентификации вытянуть сохранённые credentials роутера (согласно NVD). CISA KEV классифицирует её как «Authentication Bypass by Spoofing Vulnerability» - последствия серьёзнее, чем просто information disclosure. Устройство на стадии end-of-life. Если раскрытые credentials совпадают с admin-учёткой роутера, атакующий гипотетически может зайти в панель управления и подменить DNS-настройки - эта цепочка является авторской экстраполяцией и не описана в advisory.
CVE-2023-23397 (Microsoft Outlook, CVSS 9.8, CRITICAL): вектор
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - не нужны ни привилегии, ни действия пользователя. CWE-20 (Improper Input Validation) и CWE-294 (Authentication Bypass by Capture-replay). Гипотетически DNS hijacking может комбинироваться с эксплуатацией этой CVE: перехваченный через подменённый DNS NTLMv2-хеш из Outlook даёт доступ к M365 через relay-атаку без знания пароля. APT28 задокументированно эксплуатировал CVE-2023-23397, но связка именно с DNS hijacking через SOHO-роутеры - авторская реконструкция. CISA внесла CVE в KEV в марте 2023.Помимо Ubiquiti и TP-Link, исторически компрометация MikroTik, Netgear, Linksys и TP-Link роутеров документирована в кампании VPNFilter (Cisco Talos, 2018), D-Link - в серии атак 2019 года. SOHO-роутеры как класс устройств - системный вектор для botnet SOHO devices и DNS-перехвата.
По данным совместного advisory FBI/NSA, reboot скомпрометированного EdgeRouter или TP-Link не удаляет malware. Нужен factory reset с физической кнопки, обновление firmware и смена всех credentials. Перезагрузка - иллюзия чистоты.
Sigma-правила для детектирования DNS hijacking в SOC
Большинство русскоязычных источников не дают формализованных detection rules для этого вектора. Англоязычные advisory описывают индикаторы, но Sigma-правил не предлагают. Ниже - три детекта по приоритету для detection engineering DNS hijacking.Детект 1: DNS-запросы к неодобренным резолверам
Базовый детект. В корпоративной среде каждый endpoint должен ходить только в утверждённые DNS-серверы. DNS-трафик на порту 53 к IP вне whitelist - прямой индикатор обнаружения подмены DNS-серверов на уровне роутера или endpoint.
YAML:
title: DNS Query to Non-Approved Resolver
logsource:
category: dns
detection:
selection:
dst_port: 53
filter_approved:
dst_ip|cidr: ['10.0.0.0/24', '10.0.1.0/24'] # Используйте CIDR и синхронизируйте с IPAM
condition: selection and not filter_approved
level: high
tags: [attack.credential_access, attack.t1557.001]category: dns маппинг полей зависит от платформы - в ELK dst_ip → destination.ip, в Splunk → dest_ip, в MaxPatrol SIEM → dst.ip. Если ваш SIEM не поддерживает category dns напрямую, укажите product и service (например product: paloalto) для корректного маппинга. Тег attack.t1557.001 привязывает алерт к MITRE ATT&CK Name Resolution Poisoning. В распределённых организациях с множеством офисов и VPN-концентраторов filter_approved должен вестись как управляемый список CIDR-диапазонов, синхронизированный с IPAM/DHCP-сервером - статичный список из двух IP засыплет вас false positives.Ограничения: не ловит DNS-over-HTTPS и DNS-over-TLS - для них нужен отдельный детект по TLS SNI или JA3-хешу к known DoH-провайдерам. False positives: IoT с hardcoded DNS (Chromecast, принтеры), VPN split-tunnel, личные устройства в корпоративной сети. Chromecast, к слову, особенно любит ходить в
8.8.8.8 напрямую - учтите при калибровке.Детект 2: аномальный рост NXDOMAIN от одного источника
Когда DNS hijacked, запросы к внутренним доменам возвращают NXDOMAIN (malicious resolver не знает корпоративную зону). Всплеск NXDOMAIN от одного хоста - второй по значимости IOC для DNS-атак.Корреляция в Splunk:
index=dns response_code=NXDOMAIN | stats count by src_ip | where count > 50. Порог 50 - стартовый. Baseline рабочей станции: 5-15 NXDOMAIN в час. Для AD-сервера - выше. Калибруйте через stats avg(count) stdev(count) за 30 дней до внедрения.Ограничения: CDN-домены и typo-squatting генерируют легитимные NXDOMAIN. Wildcard-зоны сдвигают baseline. Network traffic anomaly detection здесь работает только при предварительно собранном baseline - без него вы будете ловить шум, а не атаку.
Детект 3: изменение DNS-настроек на Windows-endpoint
Прямой IOC локального DNS hijacking - модификация ключа реестраHKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer. Ловится через Sysmon Event ID 13 (Registry Value Set) с logsource: registry_set в Sigma.Когда НЕ работает: если DNS задаётся через DHCP без статической записи - изменение не фиксируется в Sysmon. Тогда нужен мониторинг DHCP-leases (T1557.003, DHCP Spoofing) на уровне сервера или сетевого tap. Два разных вектора - два разных детекта.
Сетевые правила детектирования: Suricata и Zeek для мониторинга DNS
. Если у вас в сети разрешён DoH - считайте, что этого правила не существует.
Zeek: корреляция DNS-ответов с baseline
Zeek пишетdns.log с полями id.resp_h (IP ответившего сервера) и answers (IP из DNS-ответа). Для threat hunting DNS-атак ключевой паттерн: login.microsoftonline.com резолвится в IP вне Microsoft ASN.Реализация: таблица
domain -> expected_subnet через Zeek Intelligence Framework. При несовпадении - NOTICE() с отправкой алерта в SIEM через Intel::seen().Ограничения: CDN-домены за Cloudflare и Akamai возвращают разные IP в зависимости от геолокации. Исключайте CDN-домены из baseline или мониторьте только authentication endpoints (OAuth, SAML, ADFS). Именно auth-эндпоинты - то, что атакующий хочет подменить, и именно на них стоит фокусироваться.
SOC playbook: триаж DNS hijacking от алерта до containment
Пошаговый сценарий для L2-аналитика. Триггер: Sigma-правило «DNS Query to Non-Approved Resolver» или Suricata-алерт. Если такое прилетит в 3 ночи - вот чеклист.- [0-5 мин] Подтверждение. Проверить
dst_ipчерез VirusTotal, AbuseIPDB, Shodan. IP из known DNS-провайдеров (8.8.8.8, 1.1.1.1, 9.9.9.9) - вероятно false positive от split-tunnel. Неизвестный IP из подозрительного ASN - эскалация. - [5-15 мин] Масштаб. В SIEM найти все хосты с обращениями к тому же
dst_ipза 72 часа. Несколько хостов из одной подсети - вероятна компрометация SOHO-роутера (все устройства за ним унаследовали malicious DNS через DHCP). Один хост - локальный hijack на endpoint. - [15-30 мин] Артефакты. С endpoint:
Get-DnsClientServerAddress(Windows),resolvectl status(Linux) - сравнить с baseline. С роутера (если доступен): web UI по LAN, проверить DNS в WAN/DHCP-секции, наличие нестандартных admin-аккаунтов, SSH-ключей, cron-задач. Cron-задачи на SOHO-роутере - почти всегда плохой знак. - [30-60 мин] Containment. Переключить пользователей на альтернативный канал (мобильный интернет, VPN через другой gateway). На corporate firewall заблокировать исходящий трафик к malicious DNS IP.
- [1-4 ч] Remediation. Роутер: factory reset с физической кнопки (reboot недостаточен - router firmware compromise переживает перезагрузку). Обновить firmware. Сменить admin credentials. Отключить WAN-side management, UPnP, WPS. Endpoint: принудительно задать DNS через GPO/MDM, сбросить пароли от M365.
- [4+ ч] Post-incident. M365 Unified Audit Log: необычные geographic login patterns, concurrent sessions, app consent grants. Stolen credentials - forced password reset + MFA re-enrollment. Не забудьте проверить app consent grants - атакующие любят тихо добавлять OAuth-приложения, которые переживут смену пароля.
Чеклист hardening SOHO-устройств для защиты корпоративного сегмента
Готов к передаче сисадмину или включению в отчёт:- Инвентаризация SOHO-роутеров удалённых сотрудников: модель, версия firmware, статус vendor support (active / EoL)
- Вывод из эксплуатации устройств без поддержки - TP-Link TL-WR841N в каталоге CISA KEV с рекомендацией «discontinue use»
- Смена дефолтных credentials на всех устройствах (Ubiquiti EdgeRouter:
ubnt/ubntиз коробки - и да, в 2026 году это всё ещё работает) - Отключение WAN-side remote management, UPnP, WPS
- Принудительная настройка DNS на endpoint: GPO
DNSServerSearchOrderдля Windows, MDM-профиль для macOS/iOS - endpoint не должен полагаться на DNS от роутера - DNS-over-HTTPS на endpoint без fallback to plaintext (Chrome, Firefox, Windows 11 - у каждого свой механизм отключения fallback, и каждый норовит сбросить настройки после обновления)
- Firewall-правило: блокировка исходящего DNS (53/udp, 53/tcp) ко всем IP кроме одобренных resolvers
- Ежемесячный аудит DNS-настроек роутеров (скрипт через SSH/API или ручная проверка web UI)
- Baseline DNS-трафика в SIEM - без baseline аномалии невидимы
Многие SOC-команды считают, что VPN закрывает вопрос. Не закрывает. При split-tunnel DNS-запросы резолвятся локально до установления туннеля. При full-tunnel - сотрудник включает VPN когда вспоминает. Один DNS-запрос к
login.microsoftonline.com до включения VPN - и NTLMv2-хеш уже у атакующего.Задокументированные кампании APT28 против SOHO-роутеров (MooBot/EdgeRouter) - не уникальны. VPNFilter (Cisco Talos, 2018, атрибутирован Sandworm) эксплуатировал MikroTik, Netgear, Linksys и другие, Muhstik использовал SOHO-устройства как ботнет-ноды. Вектор один и тот же, меняется атрибуция. Единственное, что реально закрывает gap - форсированный DoH на endpoint без fallback плюс мониторинг DNS-трафика на firewall. Sigma-правило на DNS Query to Non-Approved Resolver закрывает базовый detection gap за 15 минут настройки. Если в вашем SIEM пока нет детектов на DNS-аномалии - на codeby.net есть тред с Sigma-набором и маппингом полей под основные SIEM-платформы.
