DNS як інструмент атаки: як зловмисники використовують DNS-трафік для розгортання та керування шкідливим ПЗ

Новий підхід: DNS як канал підготовки та управління атакою

У лютому 2026 року Microsoft повідомила про складну варіацію атаки ClickFix, яка застала багато команд безпеки зненацька. На відміну від традиційних підходів доставки шкідливого ПЗ через HTTP/S-запити (які більшість інструментів ретельно аналізують), ця техніка використовує DNS-запити як канал для підготовки атаки та передачі команд.

Як це працює: початковий payload виконує DNS-запит до резолвера, який контролює зловмисник. У DNS-відповіді містяться закодовані інструкції, які шкідливе ПЗ обробляє та виконує як другий етап атаки.
Без веб-запитів. Без завантаження файлів. Лише DNS-відповідь, яка на рівні пакетів виглядає як звичайний запит.

Microsoft зазначає, що використання DNS таким чином зменшує залежність від традиційних веб-запитів і допомагає маскувати зловмисну активність у нормальному мережевому трафіку. Насправді ефект ще серйозніший: для команд, які покладаються лише на периметровий захист або endpoint-рішення, цей трафік майже невидимий.

Цей сценарій прямо відповідає техніці MITRE ATT&CK T1071.004 (Application Layer Protocol: DNS) — способу комунікації зі скомпрометованими системами через DNS для обходу виявлення.
Це не теорія — це вже відбувається.

Три актуальні загрози, що використовують DNS сьогодні

1. DNS-базовані C2-канали (варіація ClickFix)

Як описано вище, зловмисники вбудовують C2-інструкції безпосередньо у відповіді DNS TXT або A-записів. Шкідливе ПЗ «зв’язується з керуючим сервером» через те, що виглядає як звичайний рекурсивний DNS-запит.
Без аналізу DNS-відповідей на рівні вмісту (а не лише репутації домену) цей трафік повністю обходить більшість засобів захисту.

2. “Hazy Hawk” — захоплення покинутих DNS-записів у хмарі

Група, відстежувана під назвою Hazy Hawk, системно шукає «осиротілі» DNS-записи, що вказують на вже видалені хмарні ресурси: покинуті Amazon S3-бакети, прострочені Azure-ендпоїнти, забуті CDN-конфігурації.
Якщо компанія видаляє ресурс, але залишає DNS-запис, зловмисник може повторно зареєструвати цей ресурс і перехопити піддомен — фактично перетворивши ваш власний домен на точку розповсюдження шкідливого ПЗ.
Ваші співробітники, партнери та клієнти довіряють доменам на кшталт cdn.yourcompany.com.І ця довіра не має підриватися лише через те, що гігієна cloud-ресурсів не синхронізована з DNS.

3. Підготовлена інфраструктура — «сплячі» домени, що активуються за командою

Звіт EfficientIP DNS Threat Intelligence за 2026 рік фіксує тривожний тренд: зловмисники масово реєструють домени заздалегідь — за кілька місяців до атаки. Вони «витримують» їх, щоб сформувати довіру (репутацію), а потім активують одночасно в момент запуску кампанії.
Традиційні механізми оцінки репутації доменів не спрацьовують у такому сценарії: домен із «чистою» історією у 6 місяців не викликає підозр. Коли ж threat intelligence встигає це зафіксувати — атака вже триває.
Тому сучасна DNS-розвідка має працювати ще до активації — на етапі pre-activation, виявляючи підозрілу інфраструктуру до того, як вона почне використовуватися, а не після.

Чому традиційні засоби безпеки це пропускають

Фаєрволи аналізують порти та протоколи. EDR-рішення відстежують підозрілу поведінку процесів на endpoint’ах. SIEM-системи корелюють події вже постфактум. Жоден із цих інструментів не призначений для аналізу DNS-трафіку в реальному часі з необхідним контекстом, щоб виявляти такі техніки.
Ключова складність DNS-базованого staging полягає в тому, що:
● домени часто нові, але «чисті» — без історії шкідливої активності● самі DNS-запити виглядають коректно — на рівні пакетів немає аномалій● payload передається у відповіді DNS, а не в запиті● обсяг DNS-трафіку в корпоративних мережах робить ручний аналіз нереалістичним
Якщо чекати сигналу від endpoint’а, це означає, що другий етап атаки вже виконано.У цей момент ви вже не запобігаєте атаці — ви реагуєте на інцидент.

Яким насправді має бути ефективний захист DNS

Зупинити атаки через DNS можна лише на самому DNS-рівні, а не після того, як трафік уже оброблено. Тобто потрібен контроль (enforcement) до того, як відбудеться взаємодія з ресурсом.
Ключові вимоги:
1. Аналіз вмісту DNS-відповідей, а не лише репутації доменуДомен може виглядати «чистим», але передавати шкідливий payload. Тому рішення має аналізувати, що саме містить DNS-відповідь, а не лише перевіряти домен по списках.
2. Блокування на DNS-рівні до завершення резолвуКритичне вікно — між DNS-запитом і дією на основі відповіді. Якщо блокування відбувається в момент запиту, payload просто не доходить до endpoint’а. Це принципово інший підхід, ніж виявлення після виконання.
3. Інтеграція threat intelligence у момент запитуСтатичні блок-листи не працюють проти заздалегідь підготовленої інфраструктури з «чистою» історією. Потрібна real-time аналітика — включно з прогнозними сигналами (наприклад, підозрілі патерни реєстрації доменів), яка оцінюється саме в момент DNS-запиту.
4. Повна видимість і логування DNSНе можна захистити те, чого не видно. Кожен DNS-запит і відповідь мають логуватися, бути доступними для пошуку та корелюватися з конкретним endpoint’ом. У випадку інциденту DNS-логи часто є найточнішим джерелом розуміння того, що сталося і коли.
Саме цей розрив і покликаний закрити EnforceDNS:контроль на рівні DNS, аналіз запитів і відповідей, блокування шкідливих резолвів до їх завершення та інтеграція актуальної threat intelligence.
У результаті організації можуть зупиняти DNS-атаки проактивно — а не реагувати вже після інциденту.

Чекліст для захисту

Якщо ви оцінюєте стан DNS-безпеки сьогодні — почніть із цього:
● Проведіть аудит DNS-записів. Виявляйте та видаляйте «осиротілі» записи, що вказують на вже неіснуючі cloud-ресурси (це закриває вектор атак на кшталт Hazy Hawk)● Переконайтесь, що DNS-трафік не лише логуються, а й аналізується та контролюється (enforcement) на рівні резолвера● Перевірте покриття виявлення для техніки T1071.004. Запустіть симуляцію DNS C2-beacon і переконайтесь, що ваша система це фіксує● Переконайтесь, що DNSSEC увімкнений для вашої authoritative-зони. Попри посилення кореневої інфраструктури ICANN у 2026 році, downstream-зони залишаються слабким місцем● Перегляньте свої джерела threat intelligence. Вони мають включати прогнозні сигнали (pre-activation), а не лише реактивні блок-листи

Припиніть беззастережно довіряти DNS

DNS створювався для надійності, а не для безпеки. Роками команди безпеки довіряли DNS-трафіку, бо він виглядав «безпечним». Зловмисники це помітили — і навчились використовувати цю довіру. У 2026 році DNS як канал підготовки атак і передачі команд став одним із найефективніших інструментів у їхньому арсеналі.
Компанії, які зупиняють такі атаки, не просто швидше реагують після інциденту. Вони контролюють рівень, на якому атака починається — DNS.
Якщо у вашій архітектурі безпеки немає активного контролю (enforcement) на DNS-рівні — це не пункт у roadmap. Це відкрита точка входу.
Готові закрити її? Подивіться, як EnforceDNS від threatER забезпечує проактивний захист від DNS-загроз для enterprise та MSP-середовищ.