Что известно#
SecurityWeek пишет о технике Underminr. ADAMnetworks описывает ее как уязвимость в общей CDN-инфраструктуре, из-за которой атакующие могут прятать вредоносные соединения за доменами, выглядящими доверенными.
Проблема находится на знакомом стыке: сеть видит одно намерение соединения, а внутри общей интернет-инфраструктуры оно может приходить в другое место.
Старый похожий прием — domain fronting. В этой модели атакующий указывает разрешенный домен в видимых полях TLS, например в SNI и при проверке сертификата, а другой адрес назначения передается глубже, в зашифрованном HTTP-слое. Маршрутизация CDN затем использует внутренний Host header и отправляет запрос к скрытому назначению. Для многих систем мониторинга такой трафик выглядит как обращение к уважаемому фронтовому домену.
Underminr, по описанию, работает иначе. Вместо классической опоры на фронтовый домен техника показывает SNI и HTTP Host одного домена, но принуждает запрос идти на IP-адрес другого арендатора на том же общем CDN edge. Итог тот же: доверие расходится с реальным маршрутом. Видимые индикаторы могут выглядеть приемлемо, а фактическое соединение — доходить до другого размещенного имени.
ADAMnetworks утверждает, что это уже использовали против крупных хостинг-провайдеров, в том числе тех, кто внедрил меры против domain fronting.
Эта деталь важна. Если она верна, защитникам нельзя считать старые контрмеры против domain fronting полным ответом. Изменился уровень маршрутизации. Слепая зона сместилась.
Почему общая CDN-инфраструктура открывает такую возможность#
CDN и крупные хостинг-платформы строятся под масштаб. Множество доменов могут делить одну edge-инфраструктуру. Это повышает скорость и устойчивость, но значит и другое: сетевую политику не всегда можно строить так, будто один IP-адрес равен одному понятному назначению.
В простых моделях фильтрации защитники часто опираются на DNS-запросы, репутацию IP, SNI, имена хостов или allowlists. Каждый сигнал полезен. Ни один сам по себе не дает полной картины.
Underminr, судя по описанию, злоупотребляет местами, где эти сигналы проверяются раздельно.
ADAMnetworks формулирует разрыв в обнаружении так: решения DNS, edge IP, SNI, Host headers и tenant routing внутри CDN не всегда сопоставляются между собой. На endpoint может быть виден разрешенный DNS-запрос. Но соединение все равно может завершиться на другом размещенном имени.
В этом суть. Policy engine может одобрить то, что видит на одном уровне. CDN может маршрутизировать по другому уровню. Атакующий получает преимущество из-за этого расхождения.
SecurityWeek сообщает, что технику чаще всего наблюдали поверх TCP-порта 443, где SNI раскрывает предполагаемое TLS-имя хоста. Но это не делает активность простой для интерпретации. Порт 443 — обычный путь для веб-трафика, SaaS-платформ, VPN, прокси и malware command-and-control. Сигнал изначально шумный.
Что это дает атакующим#
По данным отчета, threat actors могут использовать Underminr, чтобы скрывать соединения с command-and-control серверами. Также техника подходит для VPN- и прокси-соединений и обхода network egress controls.
Последний пункт особенно практичен для корпоративной защиты. Egress filtering должен ограничивать, куда системы могут подключаться. Protective DNS и доменные allowlists часто входят в этот контроль. Если вредоносное соединение выглядит связанным с разрешенным доменом, но на деле доходит до другого арендатора общей инфраструктуры, точность контроля падает.
SecurityWeek пишет, что ADAMnetworks выделила четыре стратегии применения Underminr для обхода мониторинга и фильтрации Protective DNS. В кратком изложении источника нет деталей реализации каждой стратегии, и их не стоит додумывать. Безопасный вывод уже: ADAMnetworks заявляет о нескольких рабочих путях, а не об одном узком edge case.
В отчете также сказано, что реальное использование может включать вредоносные приложения и shell scripts. ADAMnetworks говорит, что технику можно злоупотреблять и в ClickFix-атаках.
ClickFix важен, потому что снижает порог входа. В таких атаках пользователей часто убеждают выполнить команды или скрипты под предлогом исправления ошибки, прохождения CAPTCHA или решения проблемы с доступом. Если получившийся скрипт использует несоответствие в маршрутизации CDN для выхода к скрытой инфраструктуре, сеть может увидеть трафик менее подозрительным, чем он есть на самом деле.
К оценке масштаба нужен холодный подход#
ADAMnetworks оценивает, что Underminr потенциально затрагивает примерно 88 миллионов доменов. SecurityWeek также сообщает, что сильнее всего затронута интернет-инфраструктура в США, Великобритании и Канаде.
Цифры крупные, но «потенциально затронуты» не значит «активно эксплуатируются» или «уязвимы одинаково». Охват shared hosting и CDN широк. Реальная эксплуатируемость зависит от поведения провайдера, логики маршрутизации, размещения арендаторов, средств мониторинга и того, как атакующий строит соединение.
Источник также цитирует CEO ADAMnetworks David Redekop: он предупреждает, что AI-generated malware может чаще использовать эту технику, когда она станет параметризуемой информацией в инструментах атакующих. Это правдоподобный прогноз риска, но все же прогноз. Более приземленная проблема проще: когда паттерн обхода задокументирован и повторяем, commodity tooling обычно его впитывает.
Защитникам стоит избежать двух ошибок.
Первая — отмахнуться от этого как от нового бренда для domain fronting. Описанная механика достаточно отличается, чтобы влиять на предположения в детекте.
Вторая — считать число 88 миллионов доказательством, что каждая организация прямо сейчас под ударом. Полезнее спросить: ваши средства контроля сопоставляют нужные уровни или одобряют их независимо друг от друга?
Что проверить защитникам#
Срочная работа здесь — не паника, а валидация.
Командам, которые полагаются на Protective DNS, доменные allowlists или простую SNI-политику, стоит проверить, сопоставляет ли их стек DNS resolution, destination IP, SNI, HTTP Host, данные сертификата и контекст CDN routing там, где он доступен.
Практические проверки:
- Просмотрите исходящие соединения к общей CDN- и хостинг-инфраструктуре, особенно потоки на порт 443, где разрешенная DNS-активность сочетается с необычным поведением destination IP.
- Проверьте, валидируют ли egress controls только запрошенный домен или еще и фактический путь назначения.
- Ищите скрипты и приложения, которые устанавливают исходящие TLS-соединения в обход обычного браузера или прокси.
- Пересмотрите детекты ClickFix. Shell-команды, выполненные пользователем, остаются ценной точкой телеметрии.
- Спросите у security vendors и CDN-провайдеров, как они обрабатывают расхождения между SNI, Host header, DNS и tenant routing.
Для организаций в средах с жесткими ограничениями главный вопрос звучит так: «разрешенный домен» значит «разрешенный арендатор и маршрут» или лишь «имя, появившееся в одном видимом поле»? Это разные меры контроля.
Главный урок#
Underminr снова показывает: решение о доверии, принятое на одном уровне, может ломаться на другом.
Общая CDN-инфраструктура не опасна сама по себе. На ней держится современный веб. Риск появляется, когда средства защиты упрощают эту сложность до одного сигнала allow/deny.
Соединение может иметь чисто выглядящий DNS-запрос. Оно может идти через обычный edge IP. Оно может показывать ожидаемое значение SNI. И при этом быть маршрутизировано туда, чего policy engine не моделировал.
Именно этот стык нужен атакующим.
Защитный ответ — не массово блокировать CDN. Это сломает слишком большую часть интернета. Лучше ужесточать корреляцию, улучшать видимость egress-трафика и меньше полагаться на предположение, что доверенно выглядящий домен доказывает доверенное конечное назначение.