Статья Glupteba – вредонос, который прятался в инфраструктуре больше 2х лет

[baykal]

В начале года одна компания пришла к нам с вполне конкретной проблемой: в инфраструктуре на сетевом оборудовании были обнаружены попытки сканирования портов, характерных для оборудования Mikrotik, а также брутфорса серверов по протоколу SSH. Сначала мы решили, что был скомпрометирован сервер из внешнего периметра. Уж очень замеченная активность была похожа на работу какого-нибудь бота, которого злоумышленники обычно закидывают на уязвимые серверы в автоматическом режиме. Привет, Mirai, Kaji, Hajime и компания!

Но, как оказалось, источниками подозрительной активности были хосты под управлением Windows, к тому же вполне рядовые. Образ одного из таких хостов и был передан на анализ экспертам Solar JSOC CERT.

Первоначальный анализ скомпрометированной системы​

При анализе сразу же бросилось в глаза большое число (более 83!) неподписанных исполняемых файлов в директории %TEMP%\csrss (о них подробно расскажем ниже):

Также в %TEMP%\csrss\smb был найден архив deps.zip (470CF2EA0F43696D2AF3E8F79D8A2AA5D315C31FC201B7D014C6EADD813C8836) и его содержимое:

Данные файлы являются ничем иным, как исполняемыми файлами, которые используются для эксплуатации уязвимости EternalBlue (CVE-2017-0144). Там же были найдены файлы, относящиеся к DoublePulsar. В целом содержимое этой папки можно назвать результатом деятельности группировки The Shadow Brokers в далеком 2017-м.

Помимо этих файлов, мы нашли определенно подозрительные задачи:

Первая задача просто запускает исполняемый файл C:\Windows\RSS\csrss.exe при входе в систему. Вторая с использованием легитимной программы certutil.exe и переданного параметра urlcache загружает с ресурса hxxps://fotamene[.]com/app/app.exe исполняемый файл, сохраняет его в расположение %TEMP%\csrss\scheduled.exe, после чего обеспечивает его запуск. Обратите внимание, что в созданной задаче применяется техника Living-off-the-Land (https://github.com/api0cradle/LOLBAS) с использованием certutil.exe.

Также файл (C:\Windows\RSS\csrss.exe) был прописан в автозапуске в реестре (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) под именем «BillowingBreeze».

Таким образом, если собрать все данные в кучу (и немного погуглить), то приходит только один вывод: в инфраструктуре компании вовсю развернулось ВПО семейства Glupteba. Его основной модуль – C:\Windows\RSS\csrss.exe.

Анализ основного модуля Glupteba​

Итак, мы опознали Glupteba. Это модульное ВПО, написанное на языке Go. Для защиты своих файлов от обнаружения оно использует множество разных техник. Сейчас расскажем вам интересные моменты анализа, а также покажем их корреляцию с артефактами на системе.

Граф основной функции, построенный в IDA, пугает!

Условно весь процесс работы ВПО Glupteba можно разделить на две фазы:

1. проверка окружения, повышение привилегий до SYSTEM, установка;
2. создание задач, установка руткитов, запуск потоков, следящих за компонентами, получение и выполнение команд.

Первая фаза работы ВПО​

Первое, что происходит после запуска исполняемого файла, – проверка окружения на соответствие следующим параметрам:

1. OS (SELECT Caption FROM Win32_OperatingSystem) == «Microsoft Windows 7 Professional»;
2. CPU (SELECT Name FROM Win32_Processor) == «Intel® Core(TM) i5-6400 CPU @ 2.70GHz»;
3. GPU (SELECT Name FROM Win32_VideoController) == «Standard VGA Graphics Adapter».

По названию функции (main.isRunningInsideAnyRun) нетрудно догадаться, что вредонос проверяет, не попал ли он в песочницу Any.Run.

Далее происходит инициализация конфигурации ВПО. Первым делом проверяется наличие конфигурации «старого образца»: HKCU\Software\Microsoft\TestApp (возможно, до этого момента ВПО находилось в стадии тестирования, но теперь все серьезно). При обнаружении конфигурация переписывается в новое расположение: HKCU\Software\Microsoft\<first 4 bytes from SID digest (SHA-256)> И при необходимости обновляется.

Если же старая конфигурация отсутствует, то она просто пишется по указанному выше расположению. То есть мы увидели «эволюцию» версий ВПО. Это видно и на анализируемой системе. Слева – конфигурация из старого местоположения, справа – из нового (в данном случае – HKCU\Software\Microsoft\eadd010f):

Видно, что значения UUID (используется для идентификации зараженного хоста на стороне злоумышленника) одинаковы, как и дата первой установки (FirstInstallDate). Переводим в более удобный формат и узнаем, что заражение произошло… барабанная дробь!.. 2 ноября 2018 года!

Подтверждается это также и временными метками MFT файлов в директории %TEMP%\csrss: они расположены между 2 ноября 2018 года и моментом обращения к нам заказчика (январь 2021 года).

Файл C:\Windows\RSS\csrss.exe также был создан 2 ноября 2018 года, а изменен 29 сентября 2020 года. Ветка реестра же последний раз была изменена 14 января 2021 года (дата снятия образа), что говорит об активной работе.

Основные значения конфигурации:

• Name – имя, которое генерируется по алгоритму https://github.com/yelinaung/go-haikunator (псевдослучайное);
• Servers – домены серверов управления;
• CDN – сервер, с которого загружается различная полезная нагрузка;
• CPU, GPU, OSCaption – информация о системе;
• UUID – уникальное значение для идентификации хоста-жертвы на стороне злоумышленника (генерируется по алгоритму github.com/gofrs/uuid)

Граф выполнения ВПО при создании конфигурации:

Далее производится проверка и повышение привилегий (в случае необходимости) вплоть до SYSTEM:

1) Обход UAC (HKCU\Software\Classes\ms-settings\shell\open\command:fodhelper или HKCU\Software\Classes\mscfile\shell\open\command:CompMgmtLauncher):

2) Получение токена SYSTEM через Trusted Installer и перезапуск себя с полученным токеном.

Стоит отметить, что без достаточных привилегий ВПО просто завершает свою работу, но при этом физически остается в инфраструктуре.

Следующий этап – проверка окружения на предмет виртуализации:

1. Открытие \\.\VBoxMiniRdrDN;
2. Проверка имени процессора: Nehalem;
3. Проверка запущенных процессов: VBoxTray.exe, VBoxService.exe, prl_cc.exe, prl_tools.exe, SharedIntApp.exe, vmusrvc.exe, vmsrvc.exe, vmtoolsd.exe.

Только после прохождения всех проверок и повышения привилегий, начинается этап установки:

1. Копирование своего исполняемого файла в C:\Windows\RSS\csrss.exe;
2. Проверка мьютекса Global\h48yorbq6rm87zot (индикатора работы основного модуля ВПО);
3. Добавление исключений на WFP командой «cmd.exe /C „netsh advfirewall firewall add rule name=“csrss» dir=in action=allow program=«C:\WINDOWS\rss\csrss.exe» enable=yes";
4. Добавление исключений Windows Defender (через реестр): процесс csrss.exe и папка C:\Windows;
5. Добавление себя в автозапуск;
6. Перезапуск себя из основного расположения C:\Windows\RSS\csrss.exe.

На этом фаза установки завершается.

Вторая фаза работы ВПО​

Она состоит из нескольких этапов:

Регистрация.

Для этого ВПО отправляет TXT-query к домену вида .<C2_domain>:

Производится отправка некоторой информации на C2 (установленное ПО, браузер по умолчанию):

Закрепление

Создаются ранее упомянутые задачи:

Установка руткитов, обеспечивающих скрытную работу ВПО

Основные моменты:

1. Имена драйверов: Winmon, WinmonFS, WinmonProcessMonitor. Были обнаружены при анализе образа, поскольку их файлы были найдены в карантине АВПО;
2. Файлы драйверов располагаются в директории C:\WINDOWS\System32\drivers и имеют соответствующие названия: Winmon.sys, WinmonFS.sys, WinmonProcessMonitor.sys;
3. Для установки драйверов на x64-системах используются следующие средства: github.com/hfiref0x/UPGDSED (отключение PatchGuard), github.com/hfiref0x/DSEFix, отключение службы PcaSvc;
4. Файлы драйверов, а также вышеназванных средств, располагаются внутри основного модуля в формате ресурсов.

Назначение руткитов:

• Winmon – сокрытие запущенных процессов путем передачи их PID в \\.\WinMon;
• WinMonFS – сокрытие директорий/файлов путем передачи путей в \\.\WinMonFS. Именно благодаря этому руткиту было невозможно обнаружить директорию %TEMP%\csrss на «живой» системе;
• WinmonProcessMonitor – постоянное завершение большого списка процессов, относящихся к средствам отладки, различным майнерам, ВПО, АВПО.

Открыть подробности

На этом же этапе (если операционная система определена как Windows 7) устанавливается сертификат:

Установка службы WinDefender

Производится проверка наличия службы WinDefender и исполняемого файла C:\Windows\windefender.exe. Если отсутствуют – с CDN загружается и запускается указанный исполняемый файл. Назначение – работа в формате службы, постоянная проверка статуса работы основного модуля, загрузка и перезапуск в случае необходимости.

Запуск потоков, следящих за основными функциями

На данном этапе запускаются потоки:

• main.watchCDN – поток, в котором производится проверка и обновление сервера CDN в конфигурации (запросы к /api/cdn на C2);
• main.watchWindowsUpdatesService – поток, в котором производятся попытки остановки и удаления службы обновления wuauserv;
• main.watchDefender – поток, в котором производится постоянное обновление исключений Windows Defender;
• main.watchWUP – поток, следящий за майнером XMRig (загружается в %TEMP%\csrss\wup: %TEMP%\csrss\wup\wup.exe). Перезапускает майнер при необходимости, отправляет его статистику, скачивает исполняемый файл майнера с CDN;
• main.watchSMB – поток, отвечающий за распространение ВПО через эксплуатацию EternalBlue (именно в нем производится загрузка и распаковка архива deps.zip, а также сканирование сети на наличие уязвимых хостов).

Получение команд, обновление серверов управления

Далее в бесконечном цикле производится отправка информации из конфигурации на сервер управления и получение ответа. Пример нагрузки, отправляемой на сервер:

Ответ расшифровывается, получается команда вместе с аргументами, производится ее исполнение. Список команд

Передаваемая информация, как и получаемая, шифруется AES256GCM с постоянным ключом и кодируется Base64.

Отдельного внимания заслуживает алгоритм смены серверов управления.

Принцип действия:

1. запрашиваются серверы Electrum (https://raw.githubusercontent.com/spesmilo/electrum/master/electrum/servers.json):
   
   
   
2. по хэшу (1CgPCp3E9399ZFodMnTSSvaf5TpGiym2N1) ищется последняя транзакция;
3. расшифровывается поле OP_RETURN ответа, полученная строка – сервер управления;
4. если сервер управления отсутствует в конфигурации, он добавляется в список.

Если через серверы Electrum выполнить обновление не получилось, производится аналогичная итерация с blockchain.info. Стоит отметить, что подобный принцип получения адресов серверов управления наблюдается в семействе RTM.

Интересный факт: каждый раз, когда производится poll (запрос к серверу управления для получения команды), значение PC в конфигурации увеличивается на 1. Для данного кейса значение PC равно 119643. Значит, команды были получены почти 120 тысяч раз за все время работы Glupteba!

Пример аргументов команды run-v3, полученной от сервера управления:

Дополнительные модули​

Как уже говорилось выше, в директории %TEMP%\csrss было обнаружено множество различных исполняемых файлов, которые являются дополнительными модулями вредоноса. Интересно то, что многие из них являются различными версиями одних и тех же модулей, создаваемых в разное время с момента первичного заражения. При желании можно отследить историю появления новых версий каждого модуля.

Основные модули:

1. Сканеры для различного сетевого оборудования (Mikrotik, Hikvision, D-Link, Zyxel, Ubiquiti). В этих же модулях производятся попытки эксплуатации уязвимостей;
2. Сканеры портов (FTP, SSH, Telnet, SNMP, SMB, HTTP);
3. Брутфорсеры паролей SSH. Используют очень небольшой словарь наиболее популярных слабых паролей;
4. Сканеры уязвимостей SMBGhost и SMBleed, использующие как deps.zip, так и самостоятельные (один из них скомпилирован с помощью py2exe). Цель – дальнейшее распространение по инфраструктуре;
5. Прокси;
6. Стилеры данных браузеров (куки, пароли, данные кредитных карт);
7. Модуль, «общающейся» с сервером злоумышленника по протоколу WebRTC (https://github.com/pion/webrtc);
8. Модуль, устанавливающий расширение в браузер Google Chrome (функционал расширения выяснить не удалось из-за того, что сервер, с которого скачивается вредоносный скрипт, уже недоступен);
9. Модули обновления конфигурации (скорее всего, использовались до того, как данный функционал был реализован в основном модуле);
10. Модули, отправляющие на C2 различную информацию о системе: версию ОС, объем памяти, прокси, запущенные процессы, использование CPU. Интересно, что для многих из указанных функций используется отдельный исполняемый файл;
11. Модуль, производящий попытку запуска браузера Google Chrome и отправляющий результат (успешно/неуспешно) злоумышленнику;
12. Модуль, отправляющий содержимое HKLM\SOFTWARE\VideoLAN\VLC:Version злоумышленнику;
13. Модули, завершающие работу процессов по ключевым словам в аргументах их запуска («-o », «stratum»). Предположительно, используется для завершения работы других майнеров.

Также были замечены модули, завершающие работу некоторых из указанных выше модулей, производящие удаление их файлов. В основе многих модулей лежит код, находящийся в открытом доступе. Особенно это касается эксплуатации различных уязвимостей. Именно по сетевой активности модулей-сканеров вредонос, живший в инфраструктуре более двух лет, и был обнаружен.

Дальнейшее развитие​

После первичного обнаружения ВПО и определения его индикаторов компрометации наша команда проверила обращения к ним из инфраструктуры заказчика. Таким образом, было обнаружено множество других серверов, зараженных после 2 ноября 2018 года.

Какие выводы?​

Исходя из вышесказанного, основные цели Glupteba:

1. Кража пользовательских данных с наибольшего числа хостов в зараженной инфраструктуре (хоть и не удалось выяснить назначение расширения для браузера, чутье подсказало, что оно используется для кражи данных с различных сайтов);
2. Добыча криптовалюты на максимально возможном числе хостов.

При этом для распространения и сокрытия присутствия вредонос использовал целый арсенал различных средств. И главное: как показывает практика, вредоносная активность далеко не всегда является тем, чем кажется на первый взгляд.

автор @JSOC_CERT

 

[X-style]

какой то комбайн из всякого хлама