Вымогатели теперь не только шифруют файлы, но и используются для 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. Используя спуфинг целевого адреса, хост может направить весь ответный трафик от подсети на жертву, в результате чего та перестанет отвечать», — пишет Дайк.

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

Почему не стоит входить с помощью Google в важные аккаунты

Кнопка «Войти с аккаунтом Google» долго казалась удобным решением, ибо не нужно придумывать новый пароль, заполнять профиль и помнить ещё одни учётные данные. Но у такого удобства есть обратная сторона. Главный риск — зависимость от одного аккаунта.

Если пользователь потеряет доступ к Google из-за взлома, блокировки, фишинга или другой проблемы, под ударом окажутся не только Gmail и Диск, но и все сторонние сервисы, куда он входил через Google.

Это может быть что угодно: рабочие инструменты, доставка еды, такси, умный дом, сервисы ИИ, приложения для путешествий или финансов.

Есть и вопрос безопасности. Современные фишинговые атаки умеют подделывать страницу входа Google и перехватывать не только пароль, но и сессионные токены.

В таком случае злоумышленник может получить доступ к аккаунту даже при включённой двухфакторной аутентификации. Чем чаще пользователь входит в разные сервисы через всплывающие окна Google, тем выше риск попасть на такую подделку.

Ещё один минус — недостаток конфиденциальности. Когда разные сервисы привязаны к одному Google-аккаунту, компания получает более цельную картину цифровой активности пользователя: какие приложения он использует, как часто и в каких сценариях. Даже если данные обрабатываются в агрегированном виде, это всё равно расширяет цифровой след.

Более безопасная альтернатива — создавать отдельные учётные записи для важных сервисов и хранить пароли в менеджере паролей. Это менее удобно на старте, зато снижает риск единой точки отказа. Если один аккаунт будет скомпрометирован или заблокирован, остальные не посыплются вслед за ним.

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

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