Недавно специалисты Qihoo 360 Netlab обнаружили очень интересный бэкдор, который получил название RotaJakiro. Данный бэкдор имел 0 обнаружений на VirusTotal длительное количество времени. Специалисты Qihoo 360 Netlab написали статью об этом бэкдоре в свой блог. Статья довольно интересная, и мне захотелось перевести её.
Приятного чтения.
Оригинальная статья Образцы этого бэкдора для скачивания и изучения ( пароль: infected )
Обзор
25 марта 2021 года система BotMon лаборатории 360 NETLAB обнаружила подозрительный ELF файл (MD5=64f6cfe44ba08b0babdd3904233c4857) с 0 обнаружениями на VirusTotal. Образец взаимодействует с 4 доменами на 443 TCP порту (HTTPS), но трафик не имеет защиты TLS/SSL. Внимательное изучение образца показало, что этот бэкдор, нацелен на системы Linux x64. Это семейство вирусов, которое существует уже как минимум 3 года.
Мы назвали его RotaJakiro, основываясь на том, что семейство использует шифрование с подстановкой ( ROT ) и ведет себя по-разному для учетных записей root и non-root при исполнении.
RotaJakiro уделяет достаточно много внимания сокрытию своих следов, используя несколько алгоритмов шифрования: алгоритм AES для шифрования информации о ресурсах внутри образца, использование комбинации AES, XOR, ROT шифрования и ZLIB сжатия для коммуникации с сервером C2 ( сервер для командования и управления вредоносной программой ).
RotaJakiro поддерживает в общей сложности 12 функций, три из которых связаны с выполнением определенных плагинов. К сожалению, мы не имеем доступа к плагинам, и поэтому не знаем их истинного назначения. Функции бэкдора можно сгруппировать в следующие четыре категории.
Отправка информации об устройстве
Кража конфиденциальной информации
Управление файлами/плагинами (запрос, загрузка, удаление) Выполнение определенного плагина
Что-нибудь ещё?
Мы обнаружили следующие 4 вида бэкдора, с имеющимися у нас образцами. Все из которых имеют 0 обнаружений на VirusTotal, а самое раннее время первого обнаружения на VirusTotal приходится на 2018 год.
Имя файла
MD5
Обнаружений
Впервые замечен на VirusTotal
systemd-daemon
1d45cd2c1283f927940c099b8fab593b
0/61
2018-05-16 04:22:59
systemd-daemon
11ad1e9b74b144d564825d65d7fb37d6
0/58
2018-12-25 08:02:05
systemd-daemon
5c0f375e92f551e8f2321b141c15c48f
0/56
2020-05-08 05:50:06
gvfsd-helper
64f6cfe44ba08b0babdd3904233c4857
0/61
2021-01-18 13:13:19
Все эти образцы имеют 4 встроенных C2-сервера. У этих четырёх серверов очень близкое время создания, обновления и конца работы.
Домен
Обнаружений
Дата создания
Дата обновления
Дата конца работы
news.thaprior.net
0/83
2015-12-09 06:24:13
2020-12-03 07:24:33
2021-12-09 06:24:13
blog.eduelects.com
0/83
2015-12-10 13:12:52
2020-12-03 07:24:33
2021-12-10 13:12:52
cdn.mirror-codes.net
0/83
2015-12-09 06:24:19
2020-12-03 07:24:32
2021-12-09 06:24:19
status.sublineover.net
0/83
2015-12-09 06:24:24
2020-12-03 07:24:32
2021-12-09 06:24:24
Читатели заметят, что даты создания были получены в декабре 2015 года (6 лет назад).
Реверс-инжиниринг
4 образца RotaJakiro с 2018 по 2021 год, очень близки по своим функциям, и для анализа в этом блоге выбран образец 2021 года, который имеет следующую основную информацию:
Код:
MD5:64f6cfe44ba08b0babdd3904233c4857 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped Packer:No
На уровне кодированияRotaJakiro использует такие технологии, как динамический AES, двухуровневые зашифрованные протоколы связи для противодействия анализу бинарного и сетевого трафика.
На функциональном уровнеRotaJakiro сначала определяет, является ли пользователь root или non-root во время выполнения, с различным набором действия для разных учетных записей. Затем расшифровывает соответствующие важные ресурсы с помощью AES и ROT шифров для последующего закрепления в системе, защиты своих процессов и исполнения их одном экземпляре. И, наконец, устанавливает связь с C2-сервером, ожидая выполнения команд от C2.
Далее будет проанализирована конкретная реализация RotaJakiro с вышеуказанными особенностями.
0x00: "Трюки", используемые бэкдором
Динамическая генерация таблиц констант, необходимых для алгоритма шифрования AES для предотвращения прямой идентификации алгоритма шифрования.
Использование техники обфускации строк на стеке для хранения зашифрованной конфиденциальной информации о ресурсах.
Сетевое взаимодействие с использованием двухуровневого шифрования.
0x01: Алгоритм шифрования
Все конфиденциальные ресурсы в RotaJakiro зашифрованы. В IDA мы видим, что метод расшифровки dec_proc вызывается 60 раз. Этот метод состоит из AES и ROT.
Код расшифровки AES выглядит следующим образом:
aes_dec - AES-256. Режим CBC. Ключ и вектор инициализации ( key & iv ) записаны в бэкдоре.
ROT - это циклический сдвиг символов, мы видим, что количество сдвигов определяется значением plain_len & 7 ( длина открытого текста ).
Возьмем в качестве примера следующий текст шифра с сервера C2.
Код:
ff ba a2 3b cd 5b 7b 24 8c 5f e3 4b fc 56 5b 99 ac 91 cf e3 9a 27 d4 c9 6b 39 34 ce 69 ce 18 60
Различные параметры, связанные с расшифровкой, показаны ниже, длина шифротекста составляет 32 байта, а длина открытого текста - 26 байт.
Сначала, расшифровывая текст с помощью AES, мы получаем следующий "промежуточный зашифрованный текст".
Затем, из "промежуточного зашифрованного текста" извлекается правильный шифротекст, где правильный шифротекст начинается с 8-го байта, а длина равнадлина открытого текста - 8 , то есть 26-8=18 байт.
Код:
98 1B DB D9 8B 59 19 5D 59 1B 59 D8 1D DC 8B D8 DB 5B
Наконец, мы можем вычислить сдвиг. Длина открытого текста равна 26. 26 & 7 = 2. Получили количество сдвигов. Сдвинем вышеуказанный правильный шифротекст на 2 бита, чтобы получить открытый текст с сервера C2.
0x02: Постоянное присутствие в системе
RotaJakiroиспользует различные методы закрепления в системе для пользователей root/non-root.
Учетная запись root
В зависимости от дистрибутива Linux, создаётся самозапускающийся скрипт по пути: /etc/init/systemd-agent.conf или /lib/systemd/system/sys-temd-agent.service
Bash:
Content of systemd-agent.conf ----------------------------- #system-daemon - configure for system daemon #This service causes system have an associated #kernel object to be started on boot. description "system daemon" start on filesystem or runlevel [2345] exec /bin/systemd/systemd-daemon respawn
Изменяется файл .bashrc, чтобы создать сценарий автозапуска для среды shell-оболочки.
Bash:
# Добавляется помощник GNOME, предназначенный для работы с абстракцией ввода-вывода GIO # Если эта переменная окружения установлена, gvfsd не будет запускать файловую систему fuse if [ -d ${HOME} ]; then ${HOME}/.gvfsd/.profile/gvfsd-helper fi
GIO (Gnome Input/Output) - Библиотека, предназначенная для предоставления программистам современного и удобного интерфейса к виртуальной файловой системе.
Список имён файлов, используемых для маскировки, оба из которых существуют одновременно.
RotaJakiro использует защиту своих процесса. И, как и в случае с постоянным присутствием в системе, существуют различные реализации для пользователей root/non-root.
Учетная запись root
При работе под пользователем root, в зависимости от дистрибутива Linux, новый процесс автоматически создается, когда процесс сервиса завершается. Это происходит путём записи Restart=always или respawn в конфигурационный файл сервиса.
Фактический результат показан на рисунке ниже, где видно, что новый процесс создается сразу после завершения процессаsystemd-daemon.
Учётная запись non-root
При запуске под non-root пользователем, RotaJakiroсоздает два процесса: session-dbus и gvfsd-helper, которые следят за состоянием друг друга. Один процесс восстанавливают другой, когда тот завершается. Это очень характерно для двух-процессной защиты.
Как реализована двух-процессная защита в RotaJakiro?
Во-первых, он создает часть общей памяти между процессами с помощью shmget API. session-dbus и gvfsd-helperобщаются друг с другом через эту общую память, сообщая друг другу свои PID (ID процесса). Затем, эти процессы динамически перебирают живые процессы в каталоге /proc/[PID]. Когда один процесс признан мертвым, другой процесс создается с помощью execvp API, чтобы помочь мертвому процессу "воскреснуть", как показано на следующей диаграмме.
Этот способ показан на скриншоте ниже. Вы можете видеть, что после завершения session-dbus и gvfsd-helper с помощью kill -9, сразу же создаются новые процессы.
0x04: Единственный экземпляр процесса ( Single instance )
RotaJakiro реализует единственный экземпляр с помощью блокировки файлов, как показано ниже.
Используемые при этом файлы блокировки различаются под пользователями root/non-root.
Под пользователем root будет создан один файл блокировки.
Bash:
/usr/lib32/.X11/X0-lock /bin/lib32/.X11/X0-lock
Под non-root, будут созданы оба файла блокировки.
Bash:
$HOME/.X11/X0-lock $HOME/.X11/.X11-lock
Например, под пользователем non-root процессы и файлы блокировки могут быть сопоставлены по /proc/locks, а затем выполняется соответствующая реализация RotaJakiro.
0x05: Сетевое взаимодействие
RotaJakiro устанавливает связь с сервером C2 с помощью следующего фрагмента кода, ожидая выполнения последующих команд.
Этот процесс можно разделить на 2 этапа Этап 1 ( Этап инициализации )
Расшифровывается список серверов C2, устанавливается соединение с сервером C2, отправляется информация, бэкдор получает и расшифровывает информацию, возвращенную с сервера C2.
Этап 2, ожидание вызовов с сервера C2
Проверяется информация, возвращенная с сервера C2. Если она проходит проверку, выполняются последующие инструкции, отправленные сервером C2.
Этап 1: Инициализация
Список C2 расшифровывается алгоритмом дешифровки, описанным в предыдущем разделе, и следующие четыре расшифрованные сервера C2 теперь находятся в бэкдоре.
RotaJakiro сначала попытается установить соединение с этими серверами, а затем создаст сообщение для начала работы в следующем фрагменте кода.
Затем он шифрует информацию об этом сообщении и отправляет ее на сервер C2.
В конце, бэкдор получает пакет обратно от сервера C2, расшифровывает его и проверяет его подлинность. Если он проходит проверку, то бэкдор переходит на этап 2.
Этап 2: Конкретные операции
Бэкдор получает и выполняет команды от сервера C2 с помощью следующего фрагмента кода.
В данный момент время RotaJakiro поддерживает 12 инструкций, а соответствие между кодом инструкции и функцией показано в следующей таблице.
ID команды
Функция
0x138E3E6
Exit ( Бэкдор завершает работу)
0x208307A
Test ( Проверка )
0x5CCA727
Heartbeat ( Проверка работоспособности )
0x17B1CC4
Set C2 timeout time ( Установить время тайм-аута сервера C2 )
0x25360EA
Steal Senstive Info ( "Украсть" конфиденциальную информацию )
0x18320e0
Upload Device Info ( Загрузить информацию об устройстве на сервер )
0x2E25992
Deliver File/Plugin ( Загрузить файл/плагин на заражённое устройство )
0x2CD9070
Query File/Plugin Status ( Запросить статуса файла/плагина )
0x12B3629
Delete File/Plugin Or Dir ( Удалить файл/плагин или директорию )
0x1B25503
Run Plugin_0x39C93E ( Запустить плагин_0x39C93E )
0x1532E65
Run Plugin_0x75A7A2 ( Запустить плагин_0x75A7A2 )
0x25D5082
Run Plugin_0x536D01 ( Запустить плагин_0x536D01 )
Функция Run Plugin повторно использует тот же код и реализует вызов функции с помощью следующей логики.
В настоящее время мы не перехватываем такие полезные нагрузки, поэтому мы используем форму Plugin_"parameter" для представления различных задач бэкдора.
0x06 Анализ пакетов
Пакет сетевого взаимодействия RotaJakiroсостоит из трех частей: заголовок, ключ и полезная нагрузка.
Заголовок является обязательным и имеет длину 82 байта, а ключ и полезная нагрузка являются необязательными. Заголовок и ключ шифруются с помощью XOR и ROT шифра. Полезная нагрузка шифруется с помощью AES и сжимается с помощью ZLIB.
Далее мы покажем из чего состоит этот сетевой трафик ( заголовок, ключ и полезная нагрузка ), а также процесс расшифровки на примере взаимодействия между ботом и сервером C2.
C2-сервер -> боту
Первые 0x52 байта - это содержимое заголовка. Как расшифровать заголовок? Очень просто, сдвинуть на 3 бита влево, а затем использовать XOR с ключом 0x1b. После расшифровки мы можем получить следующее содержимое.
В результате разбора полей мы можем узнать, что длина ключа составляет0x8 байт, длина полезной нагрузки - 0x20 байт, а код инструкций для исполнения - 0x18320e0. Это информация об устройстве. Чтение 8 байт со смещения 0x52 дает ключ: ea 9a 1a 18 18 44 26 a0. Теперь мы используем тот же метод расшифровки, что и в заголовке. Мы получаем байты 4c cf cb dbdb 39 2a 1e, которые используются как ключ AES для расшифровки полезной нагрузки.
Чтение 32 байт со смещением 0x5a дает нам следующую полезную нагрузку.
Код:
54 c1 c3 69 00 18 31 e4 a2 5b 10 7f 67 ab d1 4b b2 7b 3d 3f b3 bc 66 6a 26 f6 f6 b3 f7 2e 66 6d
Используем расшифрованный ключ для AES-256. Расшифруем приведенные выше данные в режиме CBC и получим следующее содержимое.
Для чего используется распакованная полезная нагрузка (bf 89 88 08 cd 2d fd 50)? Она используется в качестве нового ключа AES для расшифровки некоторой конфиденциальной информации о ресурсах.
Например, когда бот собирает информацию об устройстве. Один вид из этой информации - текущий дистрибутив операционной системы, который узнаётся командой cat /etc/*release | uniq.
Команда cat /etc/*release | uniq получена из следующего зашифрованного текста.
Bash:
"cat /etc/*release | uniq" cmd_ciphertxt --------------------------- 74 00 dd 79 e6 1e aa bb 99 81 7e ca d9 21 6b 81 6b d9 9d 14 45 73 6a 1c 61 cc 28 a3 0f 2b 41 5a 6b 33 8c 37 25 89 47 05 44 7e f0 6b 17 70 d8 ca
Команда расшифровывается с помощью нового ключаAES и параметров, указанных в следующем фрагменте кода.
Бот -> серверу С2
Когда бот получает команду "сообщить информацию об устройстве" от сервера C2, он отправляет следующие данные на C2, и мы можем видеть, что часть ключа по-прежнему ea 9a 1a 18 18 44 26 a0.
Расшифрованное значение ключа равно 4c cf cb db db 39 2a 1e. После расшифровки и распаковки полезной нагрузки, отправленной ботом на сервер C2, мы получаем данные, которые являются различной информацией устройства, включая информацию, полученную с помощью cat /etc/*release | uniq, упомянутой ранее, что подтверждает правильность нашего анализа.
Взаимосвязь с ботнетом Torii
Ботнет Torii был обнаружен компанией Avast20 сентября 2018 года, и мы заметили, что между ними есть некоторые сходства, например:
1: Сходство строк
После расшифровки RotaJakiro и Torii мы обнаружили, что они используют много одинаковых команд.
В процессе построения сетевого взаимодействия используется большое количество констант, а методы их построения очень близки.
3: Функциональное сходство
С точки зрения реверс-инжиниринга, RotaJakiro и Torii имеют схожие стили: использование алгоритмов шифрования для сокрытия секретной информации, использование довольно старого стиля обеспечения постоянное присутствия в системе, структурированный сетевой трафик и т.д.
Мы не знаем точного ответа, но похоже, что RotaJakiro и Torii имеют какие-то связи.
Это только верхушка айсберга
На этом мы завершаем анализ RotaJakiro, но настоящая работа еще далека от завершения, и многие вопросы остаются без ответа: "Как распространялся RotaJakiro, и какова была его цель?" , "Есть ли у RotaJakiro конкретная цель?", Мы будем рады узнать, есть ли у сообщества соответствующие версии.
