Атаки ClickFix усложняют маскировку: злоумышленники начали использовать DNS TXT-записи и предзагрузку данных в кэш браузера, чтобы скрывать вредоносные команды на ранних этапах цепочки. Для российских компаний это ещё один повод пересмотреть защиту не только почты и конечных устройств, но и DNS-трафика, браузерной телеметрии и сценариев, в которых сотрудника убеждают выполнить инструкцию вручную.
О новом развитии техники сообщает Dark Reading. Схема ClickFix строится не на тихой установке программы в фоне, а на вовлечении самого пользователя: жертве показывают страницу с убедительным предлогом — например, проверкой, устранением ошибки или подтверждением, что она не робот. Затем её подталкивают скопировать и выполнить предложенную команду. В результате защитные средства могут увидеть не классический эксплойт, а вполне легитимные действия пользователя в браузере и системе.
Новая деталь — перенос полезной нагрузки или её частей в DNS TXT-записи. TXT-записи обычно применяют для служебной текстовой информации: настройки почтовой аутентификации, верификации доменов и других инфраструктурных задач. Поэтому само обращение к ним не выглядит экзотикой. Если вредоносная страница получает данные через DNS, важный фрагмент цепочки оказывается за пределами привычной загрузки файла с веб-сервера. Аналитику приходится сопоставлять доменные запросы, содержимое ответов и последующие действия в браузере или на устройстве.
Вторая техника использует предварительное заполнение кэша браузера. Страница может заранее подготовить нужные ресурсы, чтобы позднее извлечь их из локального кэша, а не запросить в момент, когда пользователь выполняет инструкцию. Для атакующего это способ разорвать очевидную связь между открытием страницы и получением вредоносного содержимого. Для защитника — меньше шансов поймать подозрительный запрос в точке, где он ожидает увидеть основную нагрузку.
Сама популярность ClickFix объяснима: эта техника бьёт по границе между технической защитой и человеческим решением. Пользователь может собственноручно вставить команду в системный диалог или командную строку, считая, что исправляет проблему. Антивирусу и EDR в такой ситуации недостаточно спросить, «какой файл скачали»: важнее понять контекст — какая веб-страница предшествовала действию, что было в буфере обмена, какие процессы запустились следом и к каким доменам обращался браузер.
Командам ИБ стоит проверить, насколько DNS-мониторинг видит нетипичные TXT-ответы и необычные домены, к которым обращаются рабочие браузеры. Полезно также настроить корреляцию между запуском браузера, изменениями буфера обмена, открытием системных утилит и последующей сетевой активностью. Речь не о тотальном запрете DNS или браузерного кэша — оба механизма нужны для нормальной работы инфраструктуры. Задача в том, чтобы выделять аномальную последовательность действий, а не искать один «плохой» индикатор.
Для разработчиков и администраторов важен и организационный слой. Внутренние инструкции не должны приучать сотрудников копировать команды из писем, чатов и случайных веб-страниц. Если поддержка действительно просит выполнить диагностическое действие, у него должен быть проверяемый канал, понятный владелец и минимально рискованный сценарий. Формулировка «вставьте это в командную строку, чтобы пройти проверку» должна восприниматься как сигнал остановиться и перепроверить источник.
Атаки ClickFix показывают неприятную тенденцию: атакующие всё меньше зависят от одного заметного файла или ссылки и всё чаще собирают цепочку из обычных функций интернета. DNS и кэш браузера сами по себе не становятся вредоносными. Но когда они помогают спрятать команду, а последний шаг делает человек, привычная модель защиты по сигнатурам и блокировкам оказывается слишком узкой.