Явка провалена: выводим AgentTesla на чистую воду. Часть 3



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

    Сегодня Илья Померанцев, специалист по анализу вредоносного кода CERT Group-IB, расскажет о первом этапе анализа ВПО — полуавтоматической распаковке сэмплов AgentTesla на примере трех мини-кейсов из практики специалистов CERT Group-IB.

    Обычно первая стадия при анализе ВПО — снятие защиты в виде пакера, криптора, протектора или загрузчика. В большинстве случаев эта проблема решается запуском ВПО и выполнением дампа, однако существуют ситуации, когда этот метод не подходит. Например, если ВПО является шифровальщиком, если оно защищает свои регионы памяти от дампа, если в коде присутствуют механизмы обнаружения виртуальной машины или если сразу после старта ВПО выполняет перезагрузку. В таких случаях применяется так называемая «полуавтоматическая» распаковка, то есть исследователь полностью контролирует процесс и может в любой момент вмешаться. Рассмотрим эту процедуру на примере трех сэмплов семейства AgentTesla. Это относительно безвредное ВПО, если отключить ему доступ к сети.

    Сэмпл №1


    Исходный файл — это документ MS Word, который эксплуатирует уязвимость CVE-2017-11882.


    В результате происходит загрузка и запуск пейлоада.

    Анализ дерева процессов и поведенческих маркеров показывает инжект в процесс RegAsm.exe.



    Имеются характерные для AgentTesla поведенческие маркеры.


    Скачанный сэмпл — это исполняемый .NET-файл, защищенный протектором .NET Reactor.


    Откроем его в утилите dnSpy x86 и перейдем к точке входа.


    Перейдя в функцию DateTimeOffset, мы обнаружим код инициализации нового .NET-модуля. Поставим breakpoint на интересующей нас строке и запустим файл.


    В одном из возвращенных буферов можно увидеть MZ-сигнатуру (0x4D 0x5A). Сохраняем его.


    Сдампленный исполняемый файл — это динамическая библиотека, которая является лоадером, т.е. извлекает из секции ресурсов полезную нагрузку и производит ее запуск.


    При этом сами необходимые ресурсы в дампе отсутствуют. Они находятся в родительском сэмпле.

    Утилита dnSpy обладает двумя крайне полезными функциональными возможностями, которые помогут нам довольно быстро создать «франкенштейна» из двух связанных файлов.

    1. Первая позволяет «вклеить» в родительский сэмпл динамическую библиотеку.

    2. Вторая — переписать код функции у точки входа, чтобы вызвать нужный метод вставленной динамической библиотеки.


    Сохраняем нашего «франкенштейна», ставим breakpoint на строке, возвращающей буфер с дешифрованными ресурсами, и производим дамп по аналогии с предыдущим этапом.

    Второй дамп — это написанный на VB.NET исполняемый файл, который защищен знакомым нам протектором ConfuserEx.



    После снятия протектора используем написанные ранее YARA-правила и убедимся в том, что распакованное ВПО — действительно AgentTesla.



    Сэмпл №2


    Исходный файл — документ MS Excel. К исполнению вредоносного кода приводит встроенный макрос.


    В результате запускается PowerShell-скрипт.



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



    Полезная нагрузка представляет собой исполняемый .NET-файл.


    Открыв файл в dnSpy x86, можно увидеть, что он обфусцирован. Снимаем обфускацию утилитой de4dot и возвращаемся к анализу.

    В ходе исследования кода можно обнаружить следующую функцию:


    В глаза бросаются закодированные строки EntryPoint и Invoke. Ставим breakpoint на первую строку, запускаем и сохраняем значение буфера byte_0.

    Дамп вновь является приложением на .NET и защищен ConfuserEx.



    Снимаем обфускацию с помощью de4dot и загружаем в dnSpy. Из описания файла понимаем, что столкнулись с CyaX-Sharp loader.


    Этот загрузчик обладает обширным функционалом для противодействия анализу.


    Этот функционал включает обход встроенных систем защиты Windows, отключение Windows Defender, а также механизмы обнаружения песочниц и виртуальных машин. Есть возможность подгружать полезную нагрузку из сети или хранить ее в секции ресурсов. Запуск выполняется через инжект в собственный процесс, в дубликат собственного процесса или же в процессы MSBuild.exe, vbc.exe и RegSvcs.exe в зависимости от выбранного злоумышленником параметра.

    Однако для нас они менее существенны, чем AntiDump-функция, которую добавляет ConfuserEx. Ее исходный код можно найти на GitHub.

    Для отключения защиты воспользуемся возможностью dnSpy, которая позволяет редактировать IL-код.



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


    Запускаем и дампим полезную нагрузку. Используя ранее написанные YARA-правила, убеждаемся, что перед нами AgentTesla.



    Сэмпл №3


    Исходный файл — это исполняемый VB Native PE32-файл.


    Анализ энтропии показывает наличие большого фрагмента зашифрованных данных.


    При анализе формы приложения в VB Decompiler можно заметить странный пиксельный фон.



    График энтропии bmp-картинки идентичен графику энтропии исходного файла, а размер составляет 85% от размера файла.


    Общий вид изображения свидетельствует об использовании стеганографии.

    Обратим внимание на вид дерева процессов, а также на наличие маркера инжекта.



    Это говорит о выполнении распаковки. Для загрузчиков на Visual Basic (они же VBKrypt или VBInjector) характерно использование shellcode для инициализации полезной нагрузки, а также для выполнения самого инжекта.

    Анализ в VB Decompiler показал наличие события Load у формы FegatassocAirballoon2.


    Перейдем в IDA pro по указанному адресу и изучим функцию. Код сильно обфусцирован. Фрагмент, который нас интересует, представлен ниже.


    Здесь производится сканирование адресного пространства процесса в поисках сигнатуры. Такой подход крайне сомнителен.

    Во-первых, адрес начала сканирования 0x400100. Это значение статично и не корректируется при смещении базы. В идеальных тепличных условиях он будет указывать на конец PE-заголовка исполняемого файла. Однако база не статична, ее значение может меняться, а поиск реального адреса искомой сигнатуры хоть и не вызовет переполнения переменной, но может занять очень много времени.

    Во-вторых, значение сигнатуры iWGK. Думаю, очевидно, что 4 байта слишком мало, чтобы гарантировать уникальность. А если учитывать первый пункт, вероятность ошибиться довольно высока.

    В действительности искомый фрагмент прикреплен к концу найденной ранее bmp-картинки по смещению 0xA1D0D.


    Выполнение Shellcode осуществляется в две стадии. Первая производит дешифровку основного тела. При этом ключ определяется перебором.


    Сдампим дешифрованный Shellcode и посмотрим на строки.

    Во-первых, теперь мы знаем функцию создания дочернего процесса: CreateProcessInternalW.


    Во-вторых, нам стал известен механизм закрепления в системе.


    Вернемся к исходному процессу. Поставим breakpoint на CreateProcessInternalW и продолжим выполнение. Далее наблюдаем связку NtGetContextThread/NtSetContextThread, которая меняет адрес начала выполнения на адрес ShellCode.


    Подключаемся к созданному процессу отладчиком, активируем событие Suspend on libraryu load/unload, возобновляем процесс и дожидаемся подгрузки .NET-библиотек.

    Далее при помощи ProcessHucker дампим регионы, содержащие в распакованном виде .NET-приложение.

    Останавливаем все процессы и удаляем закрепившуюся в системе копию ВПО.



    Сдампленный файл защищен протектором .NET Reactor, который легко снимается при помощи утилиты de4dot.


    Воспользовавшись написанными ранее YARA-правилами, убеждаемся, что перед нами AgentTesla.

    Подведем итог


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

    Анализ вредоносного объекта, который мы провели, требует много времени и усилий, и эту работу должен выполнять специальный сотрудник в компании, однако не все компании готовы держать в штате аналитика.

    Одна из услуг, которую оказывает Лаборатория компьютерной криминалистики и анализа вредоносного кода Group-IB — реагирование на киберинциденты. А, чтобы заказчики не тратили время на согласование документов и обсуждение в разгар кибератаки, Group-IB запустила Incident Response Retainer, услугу по реагированию на инциденты по предварительной подписке, включающую также этап анализа вредоносного кода. Более подробную информацию об этом можно найти здесь.

    Если вы хотите сами еще раз изучить, как проводится распаковка сэмплов AgentTesla, и увидеть, как это делает специалист CERT Group-IB, можете скачать запись вебинара по этой теме здесь.
    Group-IB
    64.75
    Company
    Share post

    Comments 0

    Only users with full accounts can post comments. Log in, please.