2020 год для Solar JSOC CERT оказался непростым, но и 2021-й не отстает, постоянно подкидывая нам интересные кейсы. В этом посте мы расскажем, как обнаружили вредонос (даже целую сеть вредоносов) по, казалось бы, несвойственной ему активности. Он незаметно «жил» в инфраструктуре больше двух лет, втихаря обновлялся и без препятствий собирал ценные данные в инфраструктуре жертвы.
В начале года одна компания пришла к нам с вполне конкретной проблемой: в инфраструктуре на сетевом оборудовании были обнаружены попытки сканирования портов, характерных для оборудования 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. Это модульное ВПО, написанное на языке 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 – постоянное завершение большого списка процессов, относящихся к средствам отладки, различным майнерам, ВПО, АВПО.
Установка руткитов, обеспечивающих скрытную работу ВПО
Основные моменты:
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) Добыча криптовалюты на максимально возможном числе хостов.
При этом для распространения и сокрытия присутствия вредонос использовал целый арсенал различных средств.
И главное: как показывает практика, вредоносная активность далеко не всегда является тем, чем кажется на первый взгляд.
Авторы:
Владислав Лашкин, младший инженер технического расследования группы расследования инцидентов Solar JSOC CERT
Иван Сюхин, инженер технического расследования отдела расследования инцидентов Solar JSOC CERT
С чего все началось
В начале года одна компания пришла к нам с вполне конкретной проблемой: в инфраструктуре на сетевом оборудовании были обнаружены попытки сканирования портов, характерных для оборудования 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 – постоянное завершение большого списка процессов, относящихся к средствам отладки, различным майнерам, ВПО, АВПО.
Установка руткитов, обеспечивающих скрытную работу ВПО
Основные моменты:
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) Добыча криптовалюты на максимально возможном числе хостов.
При этом для распространения и сокрытия присутствия вредонос использовал целый арсенал различных средств.
И главное: как показывает практика, вредоносная активность далеко не всегда является тем, чем кажется на первый взгляд.
Авторы:
Владислав Лашкин, младший инженер технического расследования группы расследования инцидентов Solar JSOC CERT
Иван Сюхин, инженер технического расследования отдела расследования инцидентов Solar JSOC CERT
