Сегодня мы расскажем вам о новом подходе к рассылке ВПО группировкой Buhtrap.
19 декабря нам стало известно о вредоносной рассылке, содержащей исполняемый файл (md5: faf833a1456e1bb85117d95c23892368). Файл принимал различные названия: «Сверка за декабрь.exe», «Док-ты среда.exe», «Документы 19.12.exe», «Закрывающие документы среда.exe».
Из интересного — файл написан на .Net, что не характерно для этой преступной группировки. Для декомпиляции .Net можно взять любое ПО: Reflector, dotPeek, dnSpy, ILSpy. В статье мы расскажем об особенностях реализации данного файла и о том, как мы его анализировали.
Для анализа мы использовали dnSpy, и все дальнейшие скриншоты будут из него.
По привычке откроем исполняемый файл в IDA Pro и посмотрим на секцию импорта. Примеры:
Наличие некоторых функций подсказывает присутствие запакованной полезной нагрузки (LoadCursorW, LoadIconW — получили объект из ресурсов, VirtualProtect — поменяли атрибуты страницы, затем можно выполнять код) и простенькой антиотладки (IsDebuggerPresent). Но все оказалось даже проще. До IsDebuggerPresent выполнение даже не доходило, а LoadCursorW и LoadIconW бесполезно отрабатывали, потому что пытались обратиться к несуществующим ресурсам (LoadCursorW от «fiza» и LoadIconW от «saxikulatebutohutejijobodugore»):
Но вернемся к декомпилятору dnSpy. В исполняемом файле видим значительный объем неуправляемого кода:
Чтобы понять, что представляет собой неуправляемый код в исследуемом файле, воспользуемся IDA Pro. Самый простой способ — посмотреть в hex-виде тело неуправляемого кода. Для этого требуется перейти по смещению File Offset. На примере функции _main():
Далее, в IDA Pro произведем поиск по hex-последовательности:
На выходе получаем неуправляемую функцию _main(), с которой можно удобно работать с помощью идовского декомпилятора:
Вернемся к dnSpy. Внимание привлекает переменная payloadData.
Находим в IDA Pro данную последовательность, получаем ссылки на нее и выявляем, что обращение происходит как раз в функции _main():
Декомпилированный код, использующий данный буфер, выглядит так:
За преобразование данного буфера отвечают следующие функции:
Здесь производится инициализация переменной holdrand значением 0xEA48CB16 и в цикле вызывается функция foo() для каждого байта из payloadData (параметр sbyte c). Надо отметить, что функция t() — из небезопасного кода: если посмотреть ее код, можно убедиться, что она всегда возвращает значение 0x343FD.
Дальше вооружимся IDA Pro и, взглянув на получившийся распакованный буфер, замечаем, что в нем в начале лежит некоторый код:
По смещению 0x15A0 от начала буфера находится исполняемый файл:
Сохраним его для последующего анализа.
Ну а в самом исполняемом коде реализуется довольно тривиальная вещь. Сперва формируется следующая структура (здесь mz_base — адрес смещения в буфере с распакованным PE, а остальные поля — адреса требуемых функций и хэндлы библиотек):
А дальше с помощью полученных функций создается процесс того же самого исполняемого файла (md5: faf833a1456e1bb85117d95c23892368), и по виртуальным адресам нового процесса мапится распакованный исполняемый файл. После изменения адреса исполняемой инструкции (связка GetThreadContext и SetThreadContext) производится старт потока нового процесса, а сам же родительский процесс убивается.
Ну а теперь обратимся к анализу полученного исполняемого файла (полезной нагрузки).
Полезная нагрузка (md5 дампа: d8f40c7060c44fab57df87ab709f058f) также написана на платформе .Net Framework.
Для защиты от статического и динамического анализа разработчики ВПО использовали популярный протектор ConfuserEx последней версии:
ConfuserEx — хорошо зарекомендовавший себя протектор с открытым исходным кодом.
Точка входа файлов, защищенных данным протектором, выглядит следующим образом:
После расшифровки массив байт загружается в память в виде модуля под названием koi. Затем определяется и вызывается главный метод данного модуля. На платформе .Net метод или конструктор в модуле можно получить по токену метаданных с помощью вызова функции Module.ResolveMethod(). Для передачи управления полученному методу используется функция MethodBase.Invoke().
Исполняемый код в модуле koi выглядит следующим образом:
Для снятия протектора мы использовали следующие утилиты:
ConfuserEx-Unpacker расшифровал строки и код внутри методов, а de4dot сделал читаемыми названия методов.
В результате получился код, пригодный для статического анализа:
Нам, конечно, повезло получить читаемый код. Вирусописатели могут модифицировать исходный код протектора ConfuserEx, чтобы еще больше усложнить анализ.
Остались еще две проблемы, которые пришлось решить для комфортного анализа файла.
После снятия протектора декомпилятор не смог разобрать некоторые методы. Например:
Если переключиться на IL-код, можно заметить вызовы по нулевым указателям:
Для исправления ошибок декомпиляции заменяем некорректные инструкции на инструкции nop. (Утилита dnSpy позволяет изменять как декомпилированный код, так и IL-код.)
После проделанной замены декомпилированный код выглядит корректно:
Изменив IL-код во всех проблемных методах, мы получили полностью декомпилируемый файл.
Полученный файл вряд ли запустится, а это исключает возможность динамического анализа. Для решения данной проблемы необходимо указать токен входного метода в структуре исполняемого файла.
Найти его можно одним из двух способов:
Module.ResolveMethod() до распаковки файла:
В данном случае токен метаданных для входного метода равен 0x6000106. Изменяем его при помощи утилиты CFF Explorer:
После сохранения изменений распакованный файл корректно запускается и отлаживается.
Сразу после начала работы загрузчик проверяет, запущен ли он в виртуальной среде.
Запуск под VMWare или QEMU определяется поиском подстрок «vmware» и «qemu» в следующем значении реестра:
В случае обнаружения виртуальной машины загрузчик выводит соответствующее оконное сообщение:
Интересно, что вывод этого сообщения не влияет на работу процесса.
После этого вредоносное ПО пытается загрузить в память библиотеки из следующего списка: SbieDll.dll, dbghelp.dll, api_log.dll, dir_watch.dll, pstorec.dll, vmcheck.dll, wpespy.dll, snxhk.dll, guard32.dll.
Кроме того, с помощью вызовов функций Debugger.IsLogging() и Debugger.get_IsAttached() загрузчик проверяет, запущен ли он под отладчиком.
Если хотя бы одна из библиотек загрузится успешно или загрузчик обнаружит, что запущен под отладчиком, он самоудалится при помощи команды «cmd /C ping 8.8.8.8 -n 1 -w 3000 > Nul & Del». Интересно то, что загрузчик может самоудалиться даже на реальной системе, загрузив библиотеку dbghelp.dll.
Далее ВПО проверяет, запущено ли оно из директории, содержащей подстроку «Mozilla».
IP-адрес сервера в исследуемом образце вредоносного ПО — 213.252.244[.]200. Соединение инициализируется по случайно выбранному порту из списка:
• 8989,
• 5656,
• 2323.
Сразу после инициализации соединения загрузчик отправляет на C&C информацию о зараженной системе:
• идентификатор пользователя,
• имя пользователя,
• версию ОС,
• свою версию (loader v0.2.1),
• списки найденных индикаторов банковских операций на зараженной системе.
Пример строки, отправляемой загрузчиком на управляющий сервер:
Данная строка будет отправлена, если на рабочем столе зараженного пользователя есть папка «1с», а другие индикаторы отсутствуют.
Функция обработки ответа с сервера выглядит следующим образом:
Расшифрованный ответ с сервера имеет следующий вид:
Как видно из скриншота, COMMAND может принимать одно из следующих значений:
Во время исследования загрузчика нам удалось получить с сервера злоумышленников команду DW. В результате этого в систему установилось ПО Punto Switcher с вредоносной DLL-библиотекой winmm.dll (md5: 9d25553bb09e2785262b2f7ba7923605), которая представляет собой шпионский модуль группировки Buhtrap.
TCP Stream выглядит следующим образом:
Для шифрования данных, передаваемых между клиентом и управляющим сервером, используется алгоритм AES-128-ECB. Ключ шифрования инициализируется по захардкоженному паролю.
После расшифровки трафик выглядит следующим образом:
Из base64 декодируется установщик NSIS со следующим содержимым:
Интересно то, что сервер ответил, хотя список индикаторов банковских операций был пустым.
Библиотека winmm.dll исполняется при помощи техники dll hijacking. Вредоносный модуль отправляет на C&C информацию о зараженной системе и список активных считывателей смарт-карт. Кроме того, он имеет компонент кейлогера и способен получать с управляющего сервера другие вредоносные модули, исполнять их с диска или в памяти текущего процесса. C&C-серверы исследуемого образца расположены по следующим адресам:
Процесс заражения можно представить в виде следующей схемы:
Несмотря на неплохую защиту от анализа, видно, что в данный момент загрузчик не работает корректно и, скорее всего, находится в процессе разработки:
Напоследок вспомним странное оконное сообщение. Интересно, это недоработка разработчиков — или это сделано специально, чтобы побудить пользователей выйти из виртуальной среды и запуститься на реальной машине? Велком в комментарии.
MD5:
faf833a1456e1bb85117d95c23892368
9d25553bb09e2785262b2f7ba7923605
URLs:
hxxp://my1cprovider[.]xyz:6060/klog[.]php
hxxp://tinderminderorli1999[.]xyz:7764/klog[.]php
IPs:
213.252.244[.]200
Модуль загрузчика
19 декабря нам стало известно о вредоносной рассылке, содержащей исполняемый файл (md5: faf833a1456e1bb85117d95c23892368). Файл принимал различные названия: «Сверка за декабрь.exe», «Док-ты среда.exe», «Документы 19.12.exe», «Закрывающие документы среда.exe».
Из интересного — файл написан на .Net, что не характерно для этой преступной группировки. Для декомпиляции .Net можно взять любое ПО: Reflector, dotPeek, dnSpy, ILSpy. В статье мы расскажем об особенностях реализации данного файла и о том, как мы его анализировали.
Первичный осмотр загрузчика
Для анализа мы использовали dnSpy, и все дальнейшие скриншоты будут из него.
По привычке откроем исполняемый файл в IDA Pro и посмотрим на секцию импорта. Примеры:
Наличие некоторых функций подсказывает присутствие запакованной полезной нагрузки (LoadCursorW, LoadIconW — получили объект из ресурсов, VirtualProtect — поменяли атрибуты страницы, затем можно выполнять код) и простенькой антиотладки (IsDebuggerPresent). Но все оказалось даже проще. До IsDebuggerPresent выполнение даже не доходило, а LoadCursorW и LoadIconW бесполезно отрабатывали, потому что пытались обратиться к несуществующим ресурсам (LoadCursorW от «fiza» и LoadIconW от «saxikulatebutohutejijobodugore»):
Но вернемся к декомпилятору dnSpy. В исполняемом файле видим значительный объем неуправляемого кода:
Чтобы понять, что представляет собой неуправляемый код в исследуемом файле, воспользуемся IDA Pro. Самый простой способ — посмотреть в hex-виде тело неуправляемого кода. Для этого требуется перейти по смещению File Offset. На примере функции _main():
Далее, в IDA Pro произведем поиск по hex-последовательности:
На выходе получаем неуправляемую функцию _main(), с которой можно удобно работать с помощью идовского декомпилятора:
Получение полезной нагрузки
Вернемся к dnSpy. Внимание привлекает переменная payloadData.
Находим в IDA Pro данную последовательность, получаем ссылки на нее и выявляем, что обращение происходит как раз в функции _main():
Декомпилированный код, использующий данный буфер, выглядит так:
За преобразование данного буфера отвечают следующие функции:
Здесь производится инициализация переменной holdrand значением 0xEA48CB16 и в цикле вызывается функция foo() для каждого байта из payloadData (параметр sbyte c). Надо отметить, что функция t() — из небезопасного кода: если посмотреть ее код, можно убедиться, что она всегда возвращает значение 0x343FD.
Дальше вооружимся IDA Pro и, взглянув на получившийся распакованный буфер, замечаем, что в нем в начале лежит некоторый код:
По смещению 0x15A0 от начала буфера находится исполняемый файл:
Сохраним его для последующего анализа.
Ну а в самом исполняемом коде реализуется довольно тривиальная вещь. Сперва формируется следующая структура (здесь mz_base — адрес смещения в буфере с распакованным PE, а остальные поля — адреса требуемых функций и хэндлы библиотек):
А дальше с помощью полученных функций создается процесс того же самого исполняемого файла (md5: faf833a1456e1bb85117d95c23892368), и по виртуальным адресам нового процесса мапится распакованный исполняемый файл. После изменения адреса исполняемой инструкции (связка GetThreadContext и SetThreadContext) производится старт потока нового процесса, а сам же родительский процесс убивается.
Ну а теперь обратимся к анализу полученного исполняемого файла (полезной нагрузки).
Распаковка полезной нагрузки
Полезная нагрузка (md5 дампа: d8f40c7060c44fab57df87ab709f058f) также написана на платформе .Net Framework.
Для защиты от статического и динамического анализа разработчики ВПО использовали популярный протектор ConfuserEx последней версии:
ConfuserEx — хорошо зарекомендовавший себя протектор с открытым исходным кодом.
Первичная распаковка
Точка входа файлов, защищенных данным протектором, выглядит следующим образом:
После расшифровки массив байт загружается в память в виде модуля под названием koi. Затем определяется и вызывается главный метод данного модуля. На платформе .Net метод или конструктор в модуле можно получить по токену метаданных с помощью вызова функции Module.ResolveMethod(). Для передачи управления полученному методу используется функция MethodBase.Invoke().
Исполняемый код в модуле koi выглядит следующим образом:
Для снятия протектора мы использовали следующие утилиты:
ConfuserEx-Unpacker расшифровал строки и код внутри методов, а de4dot сделал читаемыми названия методов.
В результате получился код, пригодный для статического анализа:
Нам, конечно, повезло получить читаемый код. Вирусописатели могут модифицировать исходный код протектора ConfuserEx, чтобы еще больше усложнить анализ.
Остались еще две проблемы, которые пришлось решить для комфортного анализа файла.
1-я проблема
После снятия протектора декомпилятор не смог разобрать некоторые методы. Например:
Если переключиться на IL-код, можно заметить вызовы по нулевым указателям:
Для исправления ошибок декомпиляции заменяем некорректные инструкции на инструкции nop. (Утилита dnSpy позволяет изменять как декомпилированный код, так и IL-код.)
После проделанной замены декомпилированный код выглядит корректно:
Изменив IL-код во всех проблемных методах, мы получили полностью декомпилируемый файл.
2-я проблема
Полученный файл вряд ли запустится, а это исключает возможность динамического анализа. Для решения данной проблемы необходимо указать токен входного метода в структуре исполняемого файла.
Найти его можно одним из двух способов:
- посмотреть под отладкой, с каким параметром была вызвана функция
Module.ResolveMethod() до распаковки файла:
- в распакованном файле найти метод с меткой [STAThread]:
В данном случае токен метаданных для входного метода равен 0x6000106. Изменяем его при помощи утилиты CFF Explorer:
После сохранения изменений распакованный файл корректно запускается и отлаживается.
Анализ загрузчика
Сразу после начала работы загрузчик проверяет, запущен ли он в виртуальной среде.
Запуск под VMWare или QEMU определяется поиском подстрок «vmware» и «qemu» в следующем значении реестра:
- [HKLM\System\CurrentControlSet\Services\Disk\Enum\0].
В случае обнаружения виртуальной машины загрузчик выводит соответствующее оконное сообщение:
Интересно, что вывод этого сообщения не влияет на работу процесса.
После этого вредоносное ПО пытается загрузить в память библиотеки из следующего списка: SbieDll.dll, dbghelp.dll, api_log.dll, dir_watch.dll, pstorec.dll, vmcheck.dll, wpespy.dll, snxhk.dll, guard32.dll.
Кроме того, с помощью вызовов функций Debugger.IsLogging() и Debugger.get_IsAttached() загрузчик проверяет, запущен ли он под отладчиком.
Если хотя бы одна из библиотек загрузится успешно или загрузчик обнаружит, что запущен под отладчиком, он самоудалится при помощи команды «cmd /C ping 8.8.8.8 -n 1 -w 3000 > Nul & Del». Интересно то, что загрузчик может самоудалиться даже на реальной системе, загрузив библиотеку dbghelp.dll.
Далее ВПО проверяет, запущено ли оно из директории, содержащей подстроку «Mozilla».
Если процесс не запущен из директории, содержащей подстроку «Mozilla»
- ВПО формирует список директорий, которые расположены на рабочем столе и содержат следующие подстроки (все строки внутри загрузчика зашифрованы при помощи алгоритма AES-256-ECB, ключи шифрования генерируются по захардкоженным паролям):
- Формирует список URL из истории браузера, которые содержат следующие подстроки:
- Формирует список файлов, которые находятся в директориях «%UserProfile%\\Desktop», «%AppData%», «C:\\Program Files (x86)», «C:\\Program Files (x86) (x86)» и имеют следующие названия:
- Считает количество непустых списков из индикаторов, связанных с банковскими операциями (в текущей версии загрузчика данная функциональность ни на что не влияет).
- Создает задачу на запуск данного файла при каждом входе пользователя в систему при помощи команды «schtasks /create /f /sc ONLOGON /RL HIGHEST /tn LimeRAT-Admin /tr».
- Если не удалось создать задачу, создает ярлык «%AppData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\MozillaUpdate.lnk», указывающий на «%Appdata%\\Mozilla\\xaudiodg.exe», что обеспечивает запуск файла xaudiodg.exe при каждом перезапуске системы.
- Копирует себя по пути «%AppData%\\Mozilla\\xaudiodg.exe».
- Удаляет файл <self_path>:Zone.Identifier, запускает xaudiodg.exe и самоудаляется.
Если процесс запущен из директории, содержащей подстроку «Mozilla»
- ВПО аналогичным образом ищет вышеперечисленные индикаторы банковских операций внутри зараженной системы.
- Собирает другую информацию о системе для отправки на управляющий сервер.
- В отдельном потоке отправляет информацию на C&C и ожидает ответа с сервера.
- В другом потоке в бесконечном цикле отправляет на сервер зашифрованную строку «PING?».
Взаимодействие с управляющим сервером
IP-адрес сервера в исследуемом образце вредоносного ПО — 213.252.244[.]200. Соединение инициализируется по случайно выбранному порту из списка:
• 8989,
• 5656,
• 2323.
Сразу после инициализации соединения загрузчик отправляет на C&C информацию о зараженной системе:
• идентификатор пользователя,
• имя пользователя,
• версию ОС,
• свою версию (loader v0.2.1),
• списки найденных индикаторов банковских операций на зараженной системе.
Пример строки, отправляемой загрузчиком на управляющий сервер:
«INFO<NYANxCAT>9D3A4B22D21C<NYANxCAT>IEUser<NYANxCAT> Windows 7 Enterprise SP 1
<NYANxCAT>loader v0.2.1<NYANxCAT><NYANxCAT><NYANxCAT>1c, »
Данная строка будет отправлена, если на рабочем столе зараженного пользователя есть папка «1с», а другие индикаторы отсутствуют.
Функция обработки ответа с сервера выглядит следующим образом:
Расшифрованный ответ с сервера имеет следующий вид:
COMMAND<NYANxCAT>DATA1<NYANxCAT>DATA2<NYANxCAT>…
Как видно из скриншота, COMMAND может принимать одно из следующих значений:
- CLOSE — завершает соединение и закрывает текущий процесс;
- DW — декодирует из base64 содержимое из DATA2, записывает его в файл <temp_file_name> c расширением из DATA1 и запускает файл на исполнение;
- UPDATE — декодирует из base64 содержимое из DATA1, записывает его в файл с названием <temp_file_name> и расширением .exe, запускает новый исполняемый файл и самоудаляется;
- RD- — отправляет строку «RD-» в ответ;
- RD+ — отправляет снимок экрана на управляющий сервер;
- DEL — самоудаляется.
Во время исследования загрузчика нам удалось получить с сервера злоумышленников команду DW. В результате этого в систему установилось ПО Punto Switcher с вредоносной DLL-библиотекой winmm.dll (md5: 9d25553bb09e2785262b2f7ba7923605), которая представляет собой шпионский модуль группировки Buhtrap.
TCP Stream выглядит следующим образом:
Для шифрования данных, передаваемых между клиентом и управляющим сервером, используется алгоритм AES-128-ECB. Ключ шифрования инициализируется по захардкоженному паролю.
После расшифровки трафик выглядит следующим образом:
Из base64 декодируется установщик NSIS со следующим содержимым:
Интересно то, что сервер ответил, хотя список индикаторов банковских операций был пустым.
Вредоносная DLL-библиотека
Библиотека winmm.dll исполняется при помощи техники dll hijacking. Вредоносный модуль отправляет на C&C информацию о зараженной системе и список активных считывателей смарт-карт. Кроме того, он имеет компонент кейлогера и способен получать с управляющего сервера другие вредоносные модули, исполнять их с диска или в памяти текущего процесса. C&C-серверы исследуемого образца расположены по следующим адресам:
- hxxp://my1cprovider[.]xyz:6060/klog[.]php
- hxxp://tinderminderorli1999[.]xyz:7764/klog[.]php
Заключение
Процесс заражения можно представить в виде следующей схемы:
Несмотря на неплохую защиту от анализа, видно, что в данный момент загрузчик не работает корректно и, скорее всего, находится в процессе разработки:
- может самоудалиться даже на реальной системе;
- проверяет связь зараженной системы с банковскими операциями перед копированием себя в «%AppData%\\Mozilla\\xaudiodg.exe» и перед взаимодействием с C&C, но никак не использует эту информацию.
Напоследок вспомним странное оконное сообщение. Интересно, это недоработка разработчиков — или это сделано специально, чтобы побудить пользователей выйти из виртуальной среды и запуститься на реальной машине? Велком в комментарии.
IOCs
MD5:
faf833a1456e1bb85117d95c23892368
9d25553bb09e2785262b2f7ba7923605
URLs:
hxxp://my1cprovider[.]xyz:6060/klog[.]php
hxxp://tinderminderorli1999[.]xyz:7764/klog[.]php
IPs:
213.252.244[.]200
