Android-устройства атакует бот Matryosh — наследник Mirai

Android-устройства атакует бот Matryosh — наследник Mirai

Android-устройства атакует бот Matryosh — наследник Mirai

Новый Linux-вредонос распространяется, используя интерфейс отладки ADB (Android Debug Bridge), и приобщает мобильные устройства к ботнету с единственной целью — сделать их соучастниками DDoS-атаки.

Новобранец был обнаружен в конце прошлого месяца; на мониторах Qihoo 360 он засветился как Mirai. Анализ показал, что новый бот, действительно, использует фреймворк этого известного громкими DDoS-атаками зловреда, но в отличие от него прячет свой C2-сервер в сети Tor.

Из-за многоступенчатой схемы поиска центра управления и ведущих к нему прокси-серверов новоявленный бот получил кодовое имя Matryosh — «Матрешка». Получить нужные адреса ему помогают ресурсные записи DNS TXT, которые он запрашивает и разбирает по заданному алгоритму.

 

Боты Matryosh не имеют встроенного сканера и не оперируют эксплойтами. Их единственное назначение — проведение DDoS-атак по типу flood (TCP, IMCP и UDP).

Заражение целевого устройства тоже происходит поэтапно. Внедренная через ADB полезная нагрузка загружает и запускает скрипты с удаленного сервера 199[.]19[.]226[.]25 (скорее всего, взломан; штат Вайоминг). Эти скрипты, в свою очередь, загружают вариант основного модуля Matryosh в соответствии с используемым CPU (архитектура х86, ARM, MIPS и проч.).

Чтобы обмануть жертву, зловред при запуске переименовывает свой процесс и отображает ошибку ввода stdin: pipe failed. Ключевые ресурсы Matryosh зашифрованы, что затрудняет его анализ.

Уловка с выводом ошибки при запуске, использование Tor, а также формат команд, получаемых ботом, указывают на родственную связь с LeetHozer — другим Mirai-подобным зловредом, которого исследователи обнаружили почти год назад. Ту находку в Qihoo 360 относят к семейству Moobot; создатели таких DDoS-ботов взяли за основу код Mirai и постоянно экспериментируют, порождая все новые и новые итерации.

Подпишитесь на новости

Orion soft добавил аварийное восстановление в StarVault 1.6

Orion soft обновил систему управления секретами StarVault до версии 1.6. Главное нововведение — Disaster Recovery: данные реплицируются в реальном времени на резервный кластер, который можно задействовать при аварии. Резерв работает в режиме warm standby — подготовлен к переключению и получает изменения с основного кластера.

Если основной кластер выходит из строя, администратор переводит резервный в статус основного через соответствующие API-эндпоинты.

Секреты, конфигурации и права доступа сохраняются: собирать настройки заново в разгар аварии не потребуется.

По заявлению компании, механизм позволяет минимизировать время восстановления (RTO) и риск потери актуальных данных (RPO). Конкретные значения этих показателей в анонсе не приведены. Балансировку и автоматизацию переключения заказчики настраивают самостоятельно под свои регламенты.

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

Как объясняет лидер экосистемных продуктов zVirt Алишер Камалов, DR помогает снизить риск превращения централизованного хранилища в единую точку отказа. StarVault 1.6 даёт инструменты для этого сценария, а рабочую схему аварийного восстановления компании выстраивают на их основе.

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