Magnibar — сложнейший азиатский шифровальщик уже в твоем доме: история, анализ. Часть 2
Итак, рад приветствовать на второй части анализа шифровальщика Магнибер. Прошлая часть будет вот здесь. Приятного чтения, продолжаем.
Дисклеймер
На самом деле я против зла и то, что я покажу вам далее, может быть, практически применено различного рода антагонистами. Сразу предупреждаю, что я, как автор этой писанины , снимаю с себя ответственность за то с каким умыслом будет использована эта информация дальше. Виноват только и только тот, кто применяет знания, но не тот, кто ими делится. Автор лишь преследует благие цели, используя способы и пути злоумышленников, раскрывает суть преступного механизма, открывая людям глаза, демонстрируя способы защиты, ведь лучший протект — это знания.
Но DIE нам мало что покажет, лишь то, что это компонент установщика Windows, точной даты компиляции на данном этапе мы не получим. Но есть другой способ.
Раз мы имеем на руках исключительно этот .msi, то давайте разберемся что же такое MSI на самом деле.
Microsoft Installer (MSI) — это тип файлов для установки программного обеспечения на Windows. MSI-файлы используются для установки, обновления и удаления программ, и часто содержат инструкции и данные, необходимые для процесса установки.
Если говорить простыми словами, то это как самораспаковывающийся архив. Содержит в себе данные и инструкции, куда эти данные девать и что с ними делать. Если поразмышлять, то рано или поздно у тебя должен возникнуть вопрос, мол, а если это архив, можно ли его открыть и распаковать вручную?
И этот вопрос будет чертовски верным, друг мой, можно и даже нужно. Но сперва воспользуемся утилитой ORCA для просмотра таблиц, которые входят в состав нашего псевдо установщика.
Если что, я забыл вписать в список эту утилиту.
- Orca — простой и хороший обозреватель таблиц, входящих в пакеты Microsoft Installer (.msi).
И на первый взгляд, всё здесь смотрится так, как и должно быть. Кроме двух основных деталей. Это аномально большой размер раздела Binary, как для такого маленького установщика, и раздел Сustom Action, который ссылается на нечто в Binary и вызывает его исполнение. После минутного анализа можно прийти к следующему выводу:
- Основной запускаемый бинарник - «gicpivjme», по той причине, что он единственный к чему идет обращения из функции «brjvqnc» из раздела Custom Action. Остальные же являются пустышками и видимо созданы лишь для видимости, так как полны нулевых байтов.
Естественно, нам нужно извлечь gicpivjme и поддать его осмотру, чтобы понять, что же он такое. В этом нам поможет обычный архиватор 7zip.
Gicpivjme — краткий обзор и анализ
Непонятный файлик с расширением .binary, что с ним делать, куда смотреть… Я не знаю. Статья закончилась.
Ладно-ладно. 122 КБ веса, никакой подробной информации. Запускаем DIE для получения дополнительных сведений, нужно же от чего-то работать. Вуаля, теперь мы имеем понимание, что это не просто какой-то там бинарник, а исполняемый PE32 файл, написанный на С++. Вдобавок к этому, он почему абсолютно не детектится антивирусами, что порядком странно, но да ладно.
Раз это у нас C++ идем в IDA. Но злоумышленники приложили немало усилий, чтобы максимально усложнить поток выполнения. Всё начинается с одного вызова и быстро переходит в цепочку прыжков, образуя так называемую «кроличью норку», но даже не одну! Это целая цепочка нор.
Эта путаница сильно затрудняет анализ, так как найти нужный участок кода становится весьма проблематично. Тем не менее, разобраться в работе этого вымогателя всё же возможно.
Для простоты файл Gicpivjme, я буду называть первичной полезной нагрузкой, хотя это и не совсем правильно будет, но их здесь ещё сколько будет, одной меньше — одной больше, нет разницы.
С большим трудом и усилиями мне удалось выудить примерный алгоритм работы этого вредоноса(пока что это лишь предположительно, дальше возможны изменения):
- Первичная полезная нагрузка: Отвечает за уклонение от обнаружения и создание дочерних процессов.
- Вторичная полезная нагрузка: Занимается внедрением вредоносных функций в легитимные процессы Windows, что объясняет наблюдаемое ранее поведение, когда svchost.exe шифровал данные.
- Ядро вредоносного ПО: Обеспечивает процесс шифрования данных.
Все это можно отслеживать, хотя это будет весьма сложно. Поэтому разделим статью на следующие подразделы:
- Отслеживание и анализ первичной полезной нагрузки;
- Отслеживание и анализ вторичной полезной нагрузки;
- Анализ ядра Magniber.
Отслеживание и анализ первичной полезной нагрузки
Погнали. Для начала нам понадобится установить некую хитрую утилиту, которая поможет с этим делом. Трассировщик TinyTracer, на деле улетная и очень штука, гайд по установке оставлю здесь.
Также существует загвоздка в виде того, что gicpivjme не является .exe из-за чего будет затруднительно провести трассировку, поэтому сперва нужно преобразовать его из .dll.
Итак, поскольку мы проводим такую трансформацию, необходимо определить, является ли начальная функция DLLMain в .dll файле началом полезного кода. В нашем случае эта функция не содержит элементов, связанных с непосредственной работой вредоносного ПО, что существенно упрощает задачу, так как мы её просто скипаем.
Следующим шагом будет поиск целевой функции, в данном случае brjvqnc, на вкладке «Export» и изменение точки входа на неё, чтобы избежать чертовой цепочки запутанных «кроличьих нор». Как это сделать, показано на скриншотах.
Следом изменяем характеристики нашего файла на исполняемый .exe, изменив последние два числа на 100 и 2 соответственно. Как можете увидеть на скрине, 100 отвечает за разрядность, а 2 за возможность запуска.
Теперь пришло время использовать трассировщик, делается это просто, если он установлен правильно. Просто запускаем файл и ожидаем создание журнала.
И давайте глядеть что же такого делает наша первичная нагрузочка. А делает она следующее - сперва дважды выделяет вирутальную память, потом получает информацию об устройстве жертвы с помощью вызова NtQuertySystemInformation(время и дата, характеристики железа, характеристики системы, список запущенных процессов), следом вредонос массово открывает системные процессы(NtOpenProcess), выделяет в них блок памяти с помощью вызова(NtAllocateVirtualMemory), скорее всего вставляет туда что-то и отправляется в спячку на определенный период времени. (NtDelayExecution).
А также следует отметить, что вредоносное ПО практически не использует функции из собственного .dll файла, чаще всего обращаясь к системным функциям. На скриншоте приведены два примера вызова функций непосредственно из вредоносного файла.
В выделенное пространство в памяти впоследствии будет внедрен шеллкод, который и является следующей ступенью, то есть вторичной полезной нагрузкой.
Шелл-код (англ. shellcode) — это часть кода, встроенного во вредоносную программу и позволяющего после инфицирования целевой системы жертвы получить код командной оболочки. Очень часто shellcode используется как полезная нагрузка эксплоита.
Выполнение этой части обрывается системным вызовом SYSCALL:0xc8(NtCreateUserProcess), а трейсер сообщает нам, что не смог проследить за процессом дальше. Закономерный итог.
Теперь нам необходимо выяснить, какой процесс был создан. Для этого мы можем использовать расширенные настройки Tiny, которые можно найти на официальной странице утилиты на GitHub.
И это оказалось весьма занимательно, так как вредонос создает не один процесс, а целых три.
Изначально меня интересовал как раз таки неизвестный процесс, но после я обратил внимание на то, что в запуске Fodhelper’a и CMD должно быть какое-то объяснение. Дошел я к этому весьма странно: что делают первичные полезные нагрузки шифровальщиков? Собирают информацию, обходят UAC и удаляют защитные механизмы системы, чтобы жертва не смогла восстановить зашифрованные файлы.
Таким образом, оказалось, что запуск этой сладкой парочки связан с уязвимостью FodhelperBypass, которая позволяет обойти UAC. Это очень древняя штука и я сомневаюсь в её работоспособности, но да. Её использует Магнибар. Сравните то, что видите в скрипте .ps1 и в журнале. Других вариантов быть не может.
Но что это за третий процесс? Достаточно лишь посмотреть на вторую часть лога. Зашифрованный .vbs скрипт. После его расшифровки мы получаем следующую информацию:
- Скрипт является защитным механизмом шифровальщика, который удаляет теневые копии, резервы и всё прочее, что может представлять угрозу для его работы.
- Примечательно, что вредоносное ПО пытается расширить, как свои так и второй ступени, права доступа, выдавая себя за Microsoft Defender, и отключить ограничение доступа к папкам, изменяя параметр: "EnableControlledFolderAccess" = 0.
Как видите, это ещё те танцы с бубном. В следующей части мы займемся ловлей вторичной полезной нагрузки, которая будет представлена в виде шеллкодов, а также её последующим анализом. Второй этап будет намного сложнее и запутаннее. В промежуточных выводах, я хочу восхищаться подходом злоумышленников к своему творению. Всё вроде и просто, но одновременно и сложно. Если сравнивать с анализом какого-то вымогателя Loki Locker, который является просто копипастом других вымогателей, то Магнибер - шедевр. Возможно, из-за качественного подхода к своему делу, злоумышленники до сих пор не были пойманы и в скором времени нам нужно ждать очередное пришествие обновленного Магнибера. А на этом у меня пока что всё. Увидимся в следующей части. Не прощаюсь.
Последнее редактирование: