В ходе обычного исследования Kaspersky Lab был обнаружен DLL-файл, идентифицированный как hrserv.dll, который представляет собой неизвестную ранее веб-оболочку, обладающую такими сложными характеристиками, как собственные методы кодирования для взаимодействия с клиентом и выполнение в памяти. Анализ образца привел к обнаружению родственных вариантов, скомпилированных в 2021 году, что указывает на возможную взаимосвязь между этими отдельными случаями вредоносной активности.
HrServ Web shell
По данным телеметрии Kaspersky Lab, процесс PAExec.exe инициирует создание в системе запланированного задания с именем MicrosoftsUpdate (sic), которое, в свою очередь, предназначено для выполнения файла .BAT.
Файл .BAT принимает в качестве аргумента путь к DLL-файлу. В данном случае скрипту предоставляется файл $public\hrserv.dll, который затем копируется в каталог System32. После этой операции скрипт настраивает службу через системный реестр и утилиту sc. Затем он активизирует вновь созданную службу.
Последовательность операций начинается с регистрации обработчика сервиса. Затем HrServ инициирует HTTP-сервер, используя для своей функциональности API HTTP-сервера. Он вызывает функцию HttpAddUrlToGroup для регистрации следующего URL, чтобы соответствующие запросы направлялись в очередь запросов.
При обмене данными между клиентом и сервером используются собственные методы кодирования, включающие кодирование Base64 и алгоритмы хеширования FNV1A64.
В зависимости от типа и информации, содержащейся в HTTP-запросе, активизируются определенные функции. Эти функции различаются GET-параметром с именем cp. Кроме того, DLL-файл использует значение куки NID для различных целей. Использование шаблона GET-параметра и значения cookie соответствует практике, применяемой компанией Google. Мы подозреваем, что такое намеренное сходство в наименованиях предназначено для маскировки этих запросов в сетевом трафике, что затрудняет обнаружение подобных вредоносных действий.
Если значение cp в запросе равно 6, это свидетельствует о процессе выполнения кода.
- Вначале извлекается значение NID cookie и применяется собственная техника декодирования.
- Это декодированное значение записывается в указанный путь реестра, обозначенный как "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IdentityStore\RemoteFile".
- Затем расшифрованные POST-данные копируются в память, после чего создается новый поток и процесс переходит в состояние сна.
В конкретном наблюдаемом сценарии значение cp неизвестно. В памяти системы активизируется многофункциональный имплант. Имплант создает файл в каталоге "%temp%", извлекает информацию из реестра, выполняет на основе этой информации некоторые действия и записывает результаты этих действий в созданный файл. В результате реестр и временный файл используются в качестве канала связи между имплантатом и HrServ.
Судя по данным телеметрии, после успешного закрепления и размещения имплантата памяти в системной памяти следующими действиями будет удаление ранее существовавших следов путем удаления запланированного задания "MicrosoftsUpdate", а также исходных DLL- и пакетных файлов:
schtasks /delete /tn MicrosoftsUpdate /f
cmd /c "del /f/s/q $public\hrserv.dll & del /f/s/q $public\JKNLA.bat"Также были обнаружены более ранние варианты HrServ с другими названиями. Эти DLL-файлы относятся к началу 2021 года. Они также используют собственный алгоритм кодирования и ведут себя одинаково после ошибки чтения файла.
Indicators of Compromise
MD5
- 418657bf50ee32acc633b95bac4943c6
- 890fe3f9c7009c23329f9a284ec2a61b
- b9b7f16ed28140c5fcfab026078f4e2e
- d0fe27865ab271963e27973e81b77bae