Вымогатели теперь не только шифруют файлы, но и используются для DDoS

Вымогатели теперь не только шифруют файлы, но и используются для DDoS

Вымогатели теперь не только шифруют файлы, но и используются для DDoS

Исследователь компании Invincea сообщает, что злоумышленники, похоже, догадались использовать зараженные шифровальщиками устройства для осуществления DDoS-атак. Так, новая версия вредоноса из семейства Cerber демонстрирует подозрительную активность, похожую на UDP флуд.

Икенна Дайк (Ikenna Dike) из Invincea пишет, что новая вариация Cerber, похоже, создавалась как многофункциональное решение, а не просто как еще один шифровальщик. После заражения устройства малварь вносит в систему изменения, позволяющие ей подменить пользовательский скринсейвер перманентным сообщением с требованием выкупа.

 

 

Но тогда как это достаточно стандартное поведение для вымогательского ПО, Cerber также продемонстрировал странную сетевую активность, массово обращаясь к большому пулу адресов, начиная с 85.93.0.0 и заканчивая 85.93.63.255.

Исследователь пишет, что код вредоноса прошел обфускацию, а некоторые куски, похоже, вообще были добавлены в код нарочно, чтобы сбить с толку аналитиков. Все это серьезно осложняет изучение вымогателя.

Дайк обнаружил, что вредонос способен создавать текстовые файлы, экспортировать их как файлы .vbs и затем выполнять. После того как скрипт был создан и запущен, появляется файл 3311.tmp, который, судя по всему, и является непосредственно шифровальщиком Cerber.

 

 

Кроме того, как уже было сказано выше, малварь подменяет скринсейвер сообщением о выкупе и обращается к подсети 255.255.192.0 (85.93.0.0 — 85.93.63.255). Вредонос создает шестнадцатеричный .tmp-файл, который постоянно запускает процесс explorer.exe. Процесс тоже создает ряд файлов .tmp и записывает их на диск. Судя по всему, эта повторяющаяся цепочка действий является дочерним процессом все того же 3311.tmp, сообщает xakep.ru. Исследователь отмечает, что файл dnscacheugc.exe на скриншоте ниже имеет тот же хеш, что и 3311.tmp, отличается только имя. Дайк полагает, что эта цепочка действий привязана к оригинальному лупу в VBscript.

 

 

«Наблюдаемый сетевой трафик выглядит как направленный на подсеть флуд UDP-пакетами через порт 6892. Используя спуфинг целевого адреса, хост может направить весь ответный трафик от подсети на жертву, в результате чего та перестанет отвечать», — пишет Дайк.

По мнению исследователя, рассматриваемый образец малвари, возможно, не полностью завершил процесс доставки пейлоада в систему, а это означает, что вредонос может быть способен и на другую опасную активность.

ТСПУ начали перенаправлять DNS-запросы к Google и Cloudflare на НСДИ

С вечера 26 августа открытые DNS-запросы к серверам Google и Cloudflare начали перехватываться на российских технических средствах противодействия угрозам (ТСПУ). При обычном UDP-запросе к этим серверам для доменов YouTube и RuTracker возвращался ответ NXDOMAIN, будто таких адресов вообще не существует. Однако запрос по TCP успешно доходил до сервера и получал настоящие IP-адреса.

Об этом сообщил пользователь Хабра angry_agent, изучивший поведение адресов 8.8.8.8 и 1.1.1.1.

Анализ трафика показал ещё более интересную картину. Когда автор отправил DNS-запрос с малым значением TTL, в ответе ICMP TTL Exceeded обнаружился адрес 195.208.5.1, принадлежащий Национальной системе доменных имён (НСДИ), хотя исходный пакет предназначался для 8.8.8.8.

С произвольными UDP-пакетами такой подмены не происходило, система реагировала именно на DNS-трафик.

По версии исследователя, ТСПУ распознаёт открытый DNS-запрос и выполняет направленный DNAT: незаметно меняет адрес назначения и отправляет пакет на сервер НСДИ. Тот уже решает, какой ответ вернуть пользователю. При этом для оператора связи запрос выглядит направленным не к Google, а сразу к НСДИ.

Механизм оказался неидеальным. При быстрой отправке нескольких одинаковых запросов первый получал NXDOMAIN, а следующие всё-таки добирались до Google и возвращали реальные адреса. Кроме того, перенаправление срабатывало не для всех DNS-серверов.

Официального подтверждения такого механизма пока нет, выводы основаны на эксперименте одного пользователя. Напомним, вчера мы писали, что ользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare.

RSS: Новости на портале Anti-Malware.ru