WHITE HAT HACKER
Moderator
Cloudflare - Трафик на стиллер или другой вредонос
Сегодня разберем штуку, которая по красоте исполнения заткнёт за пояс половину фишинговых кампаний. Речь пойдет о том, как один логин-пароль от Cloudflare-аккаунта превращает чужой легитимный домен в вашу личную площадку для раздачи чего угодно, от фишинговых страниц до малвари, причём так, что жертва может не замечать этого неделями. Просто человеческая лень и отсутствие двухфакторки на панели, которая управляет DNS'ом всего интернета.
Небольшая предыстория и контекст, зачем это вообще кому-то. Cloudflare на сегодняшний день это не просто CDN, это, по факту, DNS-провайдер номер один в мире. По разным оценкам через их DNS проходит от 20% до 30% всех доменов в интернете. Миллионы сайтов. И когда ты привязываешь домен к Cloudflare, ты отдаёшь им полный контроль над тем, куда этот домен указывает. A-запись, CNAME, MX, TXT, всё это редактируется из одной панели, логин-пароль, и ты король. И вот тут начинается самое весёлое, потому что значительная часть пользователей Cloudflare, от фрилансеров до целых агентств с десятками клиентских доменов, не удосуживается включить 2FA. На панели, которая контролирует DNS.
Почему именно Cloudflare, а не какой-нибудь GoDaddy или Namecheap? Потому что CF уникален в одном аспекте, он работает как прокси. Когда вы включаете оранжевое облачко (Proxy status: Proxied), весь трафик идёт через серверы Cloudflare, и реальный IP-адрес сервера скрыт. Это значит, что если вы меняете A-запись, посетители сайта видят не ваш сервер напрямую, а Cloudflare, который уже решает куда перенаправить. И вот это создаёт идеальные условия, потому что при смене A-записи SSL-сертификат остаётся валидным (CF выписывает свои Universal SSL сертификаты автоматически), домен выглядит абсолютно чистым в любом чекере, а пользователь видит знакомый URL с зелёным замочком. Доверие стопроцентное. Схема атаки на пальцах выглядит так.
Первый шаг - получаем логин-пароль от Cloudflare-аккаунта. Откуда? Да откуда угодно. Утечки баз данных, стиллеры, фишинг на сам CF, или банально combo-лист из открытых источников. Люди повсюду переиспользуют пароли, и тот же пароль от какого-нибудь дырявого форума 2019 года вполне может подойти к Cloudflare-аккаунту.
Второй шаг - логинимся, проверяем что 2FA не стоит (а оно не стоит в удивительном количестве случаев), и видим перед собой список доменов. Иногда один, иногда двадцать.
Третий шаг - меняем A-запись нужного домена на IP нашего сервера.
Четвёртый шаг - на нашем сервере поднят идентичный клон сайта, или редирект, или просто страница с загрузкой "обновления".
Пятый шаг - profit, все посетители легитимного домена теперь идут к нам.
Давайте разберём каждый шаг подробнее, потому что дьявол как всегда в деталях. Итак, получение доступа к аккаунту. Самый массовый вектор на сегодня это стиллер-логи. На рынке (назовём это так) ежедневно появляются миллионы строк в формате URL:login
assword, отсортированные по сервисам. И Cloudflare там не исключение. Грепаем по dash.cloudflare.com, получаем пачку кредов, и начинаем пробовать. Логика тривиальная, заходим на dash.cloudflare.com, вбиваем email и пароль из лога. Если аккаунт без 2FA, нас сразу кидает в дашборд, полный доступ, делай что хочешь. Если с 2FA, панель просит ввести код из приложения, и без него дальше не пройдёшь. И вот тут статистика печальная, потому что из условных 100 валидных кредов, 2FA стоит в лучшем случае у 15-20. Остальные 80 сидят голые. Окей, мы внутри. Что дальше? Первое что видим после логина, это дашборд со списком всех доменов (зон) на аккаунте.
У кого-то один домен, у кого-то двадцать, а у агентств бывает и по пятьдесят. Каждый висит с зелёным статусом Active, и к каждому полный доступ. Тыкаем на нужный домен, переходим в раздел DNS -> Records, и вот они, все записи как на ладони, A, AAAA, CNAME, MX, TXT, всё. Находим A-запись, жмём Edit, стираем текущий IP и вбиваем наш. Один клик на Save. Всё, домен теперь указывает на наш сервер.
И вот тут важнейший момент, оранжевое облачко. В Cloudflare рядом с каждой DNS-записью есть переключатель Proxy status. Если облачко оранжевое (Proxied), то трафик идёт через серверы CF, и SSL-сертификат выписывается автоматически. Мы оставляем его включённым. Это значит, что после смены IP посетитель увидит https://domain.watafa с валидным сертификатом, зелёный замочек, всё чистенько. Если бы мы выключили прокси (серое облачко, DNS only), то нам пришлось бы самим поднимать Let's Encrypt на нашем сервере, что и палевно, и занимает время. А с CF-прокси сертификат уже есть, и он обновляется сам.
И вот тут начинается самая красивая часть. Что мы можем сделать на нашем сервере? Вариантов масса, и каждый зависит от цели. Первый вариант, и самый сочный на сегодня, ClickFix. Если кто не в курсе, это относительно свежая техника социальной инженерии, которая взлетела в 2024-2025 и до сих пор прекрасно работает. Суть простая, на захваченном домене поднимаем страницу с "верификацией", типа Cloudflare Turnstile, или капча, или "подтвердите что вы не робот". Пользователь заходит на знакомый домен, видит привычное окно проверки, ничего подозрительного. Но вместо настоящей капчи ему выводится инструкция, нажмите Win+R, вставьте код и нажмите Enter. А в буфер обмена при этом уже скопирована PowerShell-команда, которая тихо скачивает и запускает наш пейлоад. Красота в том, что пользователь САМ выполняет команду на своей машине, ни один антивирус не среагирует на "пользователь открыл Run и что-то ввёл", это же легитимное действие. А тот факт, что это происходит на настоящем домене с зелёным замочком, убирает последние сомнения. Человек думает, ну, сайт же настоящий, значит и проверка настоящая. ClickFix на обычном фишинговом домене уже работает неплохо, а на реальном захваченном домене это вообще стопроцентный хит. Ни браузерные фильтры, ничего не сработает, домен чистый, репутация безупречная.
Второй вариант, раздача малвари напрямую. Допустим, домен принадлежит какой-нибудь софтверной компании, и с него скачивают установщик. Мы поднимаем у себя точную копию страницы загрузки, но подменяем .exe файл на наш, с зашитым RAT'ом. Пользователь скачивает "обновление" с официального домена, с зелёным замочком, думает что всё легитимно, запускает.. и всё. Это, кстати, не теория, именно так работали некоторые supply-chain атаки последних лет, только там компрометировали сам сервер сборки, а тут мы компрометируем DNS, что технически даже проще.
Третий вариант, перехват почты. Помимо A-записи, мы можем поменять MX-записи. А это значит, что вся почта, которая летит на @example.watafa, пойдёт на наш почтовый сервер. Входящие письма от клиентов, уведомления от платёжных систем, ссылки для сброса паролей..- Всё наше. И никто не узнает, потому что отправитель получит нормальный ответ от SMTP, а получатель (мы) спокойно прочитает письмо. Настоящий получатель его просто не увидит.
А теперь про хитрости, чтоб продержаться подольше. Потому что тупо поменять A-запись и ждать, это детский сад. Настоящий владелец рано или поздно заметит, если сайт просто перестанет работать. По этому есть несколько приёмов. Приём первый, не ломай то что работает. Вместо того чтобы заменять основной сайт, работаем с поддоменами. Заходим в DNS -> Records, жмём Add record, выбираем тип A, в поле Name пишем update (или cdn-assets, или что-нибудь правдоподобное), в Content вбиваем наш IP, облачко оранжевое, Save. Готово, теперь update.example.watafa указывает на наш сервер, а основной сайт продолжает работать как ни в чём не бывало. И вот тут можно провернуть красивейшую связку. Через Page Rules или Worker на основном домене делаем так, что при первом заходе пользователя его тихо редиректит на наш поддомен, допустим verify.example.watafa. Там его встречает страница с ClickFix, "подтвердите что вы не робот", Win+R, пейлоад отработал. После чего страница автоматически редиректит обратно на основной домен, где сайт работает как ни в чём не бывало. Пользователь ничего не заподозрил, прошёл "проверку", попал на нужный сайт, всё нормально. А у нас уже шелл на его машине. Причём редирект на поддомен можно повесить только на первый визит (по куке или по IP), чтоб при повторном заходе человек шёл сразу на сайт без всяких проверок. Так и владелец ничего не заметит, когда зайдёт проверить, ведь его IP или кука уже в "белом списке".
Приём второй, Page Rules и Workers. Cloudflare позволяет настроить правила перенаправления прямо из панели, без единой строчки кода. Заходим в Rules → Page Rules, создаём правило, в URL pattern пишем example.watafa/download/*, в настройках выбираем Forwarding URL -> 301 Redirect, и указываем наш сервер. Всё, основной сайт работает как работал, но кто зайдёт на /download/ получит наш контент. Ещё мощнее, Cloudflare Workers. Это серверлесс-функции, которые выполняются на edge-серверах CF. Заходим в Workers & Pages, создаём новый Worker, и пишем простенькую логику, для определённых IP-диапазонов подменяем контент, а для всех остальных (включая владельца сайта) показываем оригинал. По сути, владелец сайта заходит на свой домен, видит что всё нормально, а его посетители в это время получают совсем другой контент. Тут уже уровень изощрённости на порядок выше.
Теперь давайте поговорим о масштабах проблемы, потому что это не какая-то теоретическая атака из учебника. На одном аккаунте может висеть от одного до сотни доменов, особенно у агентств, которые управляют сайтами клиентов. Представьте себе, web-студия, которая держит 50 клиентских доменов на одном CF-аккаунте с паролем Qwerty123 и без двухфакторки. Один стиллер на ноутбуке менеджера, и у тебя доступ ко всем пятидесяти доменам. Каждый, потенциальная площадка для раздачи.
Что мы имеем по итогу? На сегодняшний день рынок под ClickFix-кампании выглядит так, все массово скупают взломанные вордпрессы, джумлы, друпалы, любые CMS'ки, лишь бы домен был живой и с трафиком. Ломают через дырявые плагины, через утёкшие админки, через шеллы, и вешают туда свои страницы с "верификацией". Это уже поставлено на поток, целые каналы в телеге, маркеты, автоматизация. Но вот что интересно, за всё время что я мониторю эту тему, я нашёл буквально одного человека, который скупает именно Cloudflare-аккаунты. Одного. При том что вектор через CF объективно мощнее, ты не зависишь от CMS, не нужно искать уязвимости в коде, не нужен шелл, не нужен доступ к файловой системе сервера. Ты просто меняешь одну строчку в DNS-панели, и весь домен твой. С SSL, с репутацией, с трафиком. И при этом почти никто этим не пользуется, по крайней мере массово. Почему? Может потому что народ привык работать с CMS'ками и просто не думает в эту сторону. Может потому что CF-аккаунты в логах встречаются реже чем wp-admin. А может потому что эта статья ещё не вышла. Всем пока, не болейте!
Сегодня разберем штуку, которая по красоте исполнения заткнёт за пояс половину фишинговых кампаний. Речь пойдет о том, как один логин-пароль от Cloudflare-аккаунта превращает чужой легитимный домен в вашу личную площадку для раздачи чего угодно, от фишинговых страниц до малвари, причём так, что жертва может не замечать этого неделями. Просто человеческая лень и отсутствие двухфакторки на панели, которая управляет DNS'ом всего интернета.
Небольшая предыстория и контекст, зачем это вообще кому-то. Cloudflare на сегодняшний день это не просто CDN, это, по факту, DNS-провайдер номер один в мире. По разным оценкам через их DNS проходит от 20% до 30% всех доменов в интернете. Миллионы сайтов. И когда ты привязываешь домен к Cloudflare, ты отдаёшь им полный контроль над тем, куда этот домен указывает. A-запись, CNAME, MX, TXT, всё это редактируется из одной панели, логин-пароль, и ты король. И вот тут начинается самое весёлое, потому что значительная часть пользователей Cloudflare, от фрилансеров до целых агентств с десятками клиентских доменов, не удосуживается включить 2FA. На панели, которая контролирует DNS.
Почему именно Cloudflare, а не какой-нибудь GoDaddy или Namecheap? Потому что CF уникален в одном аспекте, он работает как прокси. Когда вы включаете оранжевое облачко (Proxy status: Proxied), весь трафик идёт через серверы Cloudflare, и реальный IP-адрес сервера скрыт. Это значит, что если вы меняете A-запись, посетители сайта видят не ваш сервер напрямую, а Cloudflare, который уже решает куда перенаправить. И вот это создаёт идеальные условия, потому что при смене A-записи SSL-сертификат остаётся валидным (CF выписывает свои Universal SSL сертификаты автоматически), домен выглядит абсолютно чистым в любом чекере, а пользователь видит знакомый URL с зелёным замочком. Доверие стопроцентное. Схема атаки на пальцах выглядит так.
Первый шаг - получаем логин-пароль от Cloudflare-аккаунта. Откуда? Да откуда угодно. Утечки баз данных, стиллеры, фишинг на сам CF, или банально combo-лист из открытых источников. Люди повсюду переиспользуют пароли, и тот же пароль от какого-нибудь дырявого форума 2019 года вполне может подойти к Cloudflare-аккаунту.
Второй шаг - логинимся, проверяем что 2FA не стоит (а оно не стоит в удивительном количестве случаев), и видим перед собой список доменов. Иногда один, иногда двадцать.
Третий шаг - меняем A-запись нужного домена на IP нашего сервера.
Четвёртый шаг - на нашем сервере поднят идентичный клон сайта, или редирект, или просто страница с загрузкой "обновления".
Пятый шаг - profit, все посетители легитимного домена теперь идут к нам.
Давайте разберём каждый шаг подробнее, потому что дьявол как всегда в деталях. Итак, получение доступа к аккаунту. Самый массовый вектор на сегодня это стиллер-логи. На рынке (назовём это так) ежедневно появляются миллионы строк в формате URL:login
assword, отсортированные по сервисам. И Cloudflare там не исключение. Грепаем по dash.cloudflare.com, получаем пачку кредов, и начинаем пробовать. Логика тривиальная, заходим на dash.cloudflare.com, вбиваем email и пароль из лога. Если аккаунт без 2FA, нас сразу кидает в дашборд, полный доступ, делай что хочешь. Если с 2FA, панель просит ввести код из приложения, и без него дальше не пройдёшь. И вот тут статистика печальная, потому что из условных 100 валидных кредов, 2FA стоит в лучшем случае у 15-20. Остальные 80 сидят голые. Окей, мы внутри. Что дальше? Первое что видим после логина, это дашборд со списком всех доменов (зон) на аккаунте.У кого-то один домен, у кого-то двадцать, а у агентств бывает и по пятьдесят. Каждый висит с зелёным статусом Active, и к каждому полный доступ. Тыкаем на нужный домен, переходим в раздел DNS -> Records, и вот они, все записи как на ладони, A, AAAA, CNAME, MX, TXT, всё. Находим A-запись, жмём Edit, стираем текущий IP и вбиваем наш. Один клик на Save. Всё, домен теперь указывает на наш сервер.
И вот тут важнейший момент, оранжевое облачко. В Cloudflare рядом с каждой DNS-записью есть переключатель Proxy status. Если облачко оранжевое (Proxied), то трафик идёт через серверы CF, и SSL-сертификат выписывается автоматически. Мы оставляем его включённым. Это значит, что после смены IP посетитель увидит https://domain.watafa с валидным сертификатом, зелёный замочек, всё чистенько. Если бы мы выключили прокси (серое облачко, DNS only), то нам пришлось бы самим поднимать Let's Encrypt на нашем сервере, что и палевно, и занимает время. А с CF-прокси сертификат уже есть, и он обновляется сам.
И вот тут начинается самая красивая часть. Что мы можем сделать на нашем сервере? Вариантов масса, и каждый зависит от цели. Первый вариант, и самый сочный на сегодня, ClickFix. Если кто не в курсе, это относительно свежая техника социальной инженерии, которая взлетела в 2024-2025 и до сих пор прекрасно работает. Суть простая, на захваченном домене поднимаем страницу с "верификацией", типа Cloudflare Turnstile, или капча, или "подтвердите что вы не робот". Пользователь заходит на знакомый домен, видит привычное окно проверки, ничего подозрительного. Но вместо настоящей капчи ему выводится инструкция, нажмите Win+R, вставьте код и нажмите Enter. А в буфер обмена при этом уже скопирована PowerShell-команда, которая тихо скачивает и запускает наш пейлоад. Красота в том, что пользователь САМ выполняет команду на своей машине, ни один антивирус не среагирует на "пользователь открыл Run и что-то ввёл", это же легитимное действие. А тот факт, что это происходит на настоящем домене с зелёным замочком, убирает последние сомнения. Человек думает, ну, сайт же настоящий, значит и проверка настоящая. ClickFix на обычном фишинговом домене уже работает неплохо, а на реальном захваченном домене это вообще стопроцентный хит. Ни браузерные фильтры, ничего не сработает, домен чистый, репутация безупречная.
Второй вариант, раздача малвари напрямую. Допустим, домен принадлежит какой-нибудь софтверной компании, и с него скачивают установщик. Мы поднимаем у себя точную копию страницы загрузки, но подменяем .exe файл на наш, с зашитым RAT'ом. Пользователь скачивает "обновление" с официального домена, с зелёным замочком, думает что всё легитимно, запускает.. и всё. Это, кстати, не теория, именно так работали некоторые supply-chain атаки последних лет, только там компрометировали сам сервер сборки, а тут мы компрометируем DNS, что технически даже проще.
Третий вариант, перехват почты. Помимо A-записи, мы можем поменять MX-записи. А это значит, что вся почта, которая летит на @example.watafa, пойдёт на наш почтовый сервер. Входящие письма от клиентов, уведомления от платёжных систем, ссылки для сброса паролей..- Всё наше. И никто не узнает, потому что отправитель получит нормальный ответ от SMTP, а получатель (мы) спокойно прочитает письмо. Настоящий получатель его просто не увидит.
А теперь про хитрости, чтоб продержаться подольше. Потому что тупо поменять A-запись и ждать, это детский сад. Настоящий владелец рано или поздно заметит, если сайт просто перестанет работать. По этому есть несколько приёмов. Приём первый, не ломай то что работает. Вместо того чтобы заменять основной сайт, работаем с поддоменами. Заходим в DNS -> Records, жмём Add record, выбираем тип A, в поле Name пишем update (или cdn-assets, или что-нибудь правдоподобное), в Content вбиваем наш IP, облачко оранжевое, Save. Готово, теперь update.example.watafa указывает на наш сервер, а основной сайт продолжает работать как ни в чём не бывало. И вот тут можно провернуть красивейшую связку. Через Page Rules или Worker на основном домене делаем так, что при первом заходе пользователя его тихо редиректит на наш поддомен, допустим verify.example.watafa. Там его встречает страница с ClickFix, "подтвердите что вы не робот", Win+R, пейлоад отработал. После чего страница автоматически редиректит обратно на основной домен, где сайт работает как ни в чём не бывало. Пользователь ничего не заподозрил, прошёл "проверку", попал на нужный сайт, всё нормально. А у нас уже шелл на его машине. Причём редирект на поддомен можно повесить только на первый визит (по куке или по IP), чтоб при повторном заходе человек шёл сразу на сайт без всяких проверок. Так и владелец ничего не заметит, когда зайдёт проверить, ведь его IP или кука уже в "белом списке".
Приём второй, Page Rules и Workers. Cloudflare позволяет настроить правила перенаправления прямо из панели, без единой строчки кода. Заходим в Rules → Page Rules, создаём правило, в URL pattern пишем example.watafa/download/*, в настройках выбираем Forwarding URL -> 301 Redirect, и указываем наш сервер. Всё, основной сайт работает как работал, но кто зайдёт на /download/ получит наш контент. Ещё мощнее, Cloudflare Workers. Это серверлесс-функции, которые выполняются на edge-серверах CF. Заходим в Workers & Pages, создаём новый Worker, и пишем простенькую логику, для определённых IP-диапазонов подменяем контент, а для всех остальных (включая владельца сайта) показываем оригинал. По сути, владелец сайта заходит на свой домен, видит что всё нормально, а его посетители в это время получают совсем другой контент. Тут уже уровень изощрённости на порядок выше.
Теперь давайте поговорим о масштабах проблемы, потому что это не какая-то теоретическая атака из учебника. На одном аккаунте может висеть от одного до сотни доменов, особенно у агентств, которые управляют сайтами клиентов. Представьте себе, web-студия, которая держит 50 клиентских доменов на одном CF-аккаунте с паролем Qwerty123 и без двухфакторки. Один стиллер на ноутбуке менеджера, и у тебя доступ ко всем пятидесяти доменам. Каждый, потенциальная площадка для раздачи.
Что мы имеем по итогу? На сегодняшний день рынок под ClickFix-кампании выглядит так, все массово скупают взломанные вордпрессы, джумлы, друпалы, любые CMS'ки, лишь бы домен был живой и с трафиком. Ломают через дырявые плагины, через утёкшие админки, через шеллы, и вешают туда свои страницы с "верификацией". Это уже поставлено на поток, целые каналы в телеге, маркеты, автоматизация. Но вот что интересно, за всё время что я мониторю эту тему, я нашёл буквально одного человека, который скупает именно Cloudflare-аккаунты. Одного. При том что вектор через CF объективно мощнее, ты не зависишь от CMS, не нужно искать уязвимости в коде, не нужен шелл, не нужен доступ к файловой системе сервера. Ты просто меняешь одну строчку в DNS-панели, и весь домен твой. С SSL, с репутацией, с трафиком. И при этом почти никто этим не пользуется, по крайней мере массово. Почему? Может потому что народ привык работать с CMS'ками и просто не думает в эту сторону. Может потому что CF-аккаунты в логах встречаются реже чем wp-admin. А может потому что эта статья ещё не вышла. Всем пока, не болейте!