Генерация COM vtable в IDA 🐍

В процессе разбора одного из вариантов Snake Keylogger нужно было разобраться, какие managed-методы нативный модуль вызывает через COM-интерфейсы. Это означает, что нам нужно было вручную насоздавать какое-то количество структур. И еще нам бы хотелось видеть сигнатуру каждого метода, а их много.

Попробуем автоматизировать процесс. Предложенный способ, возможно, не единственный, но интересный и решает нашу задачу. Стек инструментов:

• OLE/COM Object Viewer (oleview)
• MIDL компилятор (midl.exe, входит в Visual Studio Build Tools)
• IDA

📂 Воспользуемся OLE/COM Object Viewer (oleview), чтобы открыть mscorlib.tlb и найти интересующие нас интерфейсы. Путь к нему:

C:\Program Files (x86)\Windows Kits\10\bin\<версия>\x86\oleview.exe

В mscorlib.tlb находятся COM-описания базовых managed-интерфейсов. Этот файл обычно лежит в каталоге:

C:\Windows\Microsoft.NET\Framework\<Версия>\mscorlib.tlb

Открыв файл, мы видим его IDL — Interface Definition Language (скриншот 1).

🫱 Далее находим в дереве oleview нужные нам интерфейсы (например, _AppDomain). Выгружаем их IDL и по примеру IDL для mscorlib (скриншот 1) собираем свой (скриншот 2). Пример минимального IDL представлен на скриншоте 3 (количество методов урезано).

На этом шаге нужно немного почистить файл:

1️⃣ Форварднуть интерфейсы, определить value-типы. Интерфейсы можно форвардить, так как указатель на них всегда одинакового размера. Но value-типы требуется определить полностью, иначе будет ошибка unsatisfied forward declaration. Мы обойдемся заглушками: для сигнатур методов этого достаточно.

2️⃣ Отредактировать объявления функций.

На скриншоте 4 мы видим, как объявлен COM-метод GetEvents_2. Это вариант перегрузки метода GetEvents. Нас интересует атрибут custom, который говорит, что этот метод — реализация .NET-метода Assembly.GetEvents и calling convention (_stdcall). Если мы оставим все так, как в сыром IDL, компилятор будет ругаться, потому что:

1️⃣ В IDL не пишут _stdcall: это появится в сгенерированном .h.

2️⃣ Атрибуты метода (включая custom(...)) должны быть только в квадратных скобках перед возвращаемым типом метода (в нашем случае — HRESULT).

Поэтому меняем содержимое на следующее:

[custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, "GetEvents")]
HRESULT GetEvents_2([in] BindingFlags bindingAttr, [out, retval] SAFEARRAY(_EventInfo*)* pRetVal);

Далее воспользуемся командой для сборки:

midl /h appdomain.h appdomain.idl

👍 Если вы все сделали правильно и сборка прошла успешно, вывод будет выглядеть так, как на скриншоте 5.

Теперь у нас есть готовый хедер, который мы отправим в IDA. Но сначала в хедер-файл добавим инклюды (до содержимого appdomain.h), чтобы IDA clang знал все имена и не ругался на атрибуты или макросы (скриншот 6):

После этого загружаем файл в IDA: File → Load file → Parse C header file…

IDA использует встроенный clang для преобразования C-заголовков в базу типов IDA. Соответственно, в Options → Compiler нужно указать include-пути, чтобы clang видел стандартные заголовки (пути к стандартным хедерам Windows SDK). Обычно это выглядит так:

-target x86_64-pc-win32
-x c++
-std=c++11
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\ucrt"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\um"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\shared"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\winrt"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\cppwinrt"

После в Local Types появятся методы _AppDomain, _Type и другие (скриншот 7).

👀 На скриншоте 8 мы видим вызовы двух методов интерфейса _Type. Делаем encr_resource указателем на структуру _Type (ее vtable мы видели на скриншоте 7) и понимаем, какие методы вызываются (скриншот 9). Все аргументы схлопнулись под правильной сигнатурой, которую нам не нужно прописывать вручную.

#tip #malware #reverse
@ptescalator

Curing a problem 🔧

Недавно исследователи из ARMO представили статью и PoC вредоносного ПО Curing, которое использует интерфейс io_uring для обхода мониторинга файловых и сетевых операций, осуществляемого через системные вызовы.

🧐 Для начала расскажем о самом интерфейсе io_uring. Он появился в версии ядра 5.1 для выполнения асинхронных операций ввода-вывода. До него существовал интерфейс Linux AIO, который тоже предлагал асинхронный ввод-вывод, но имел ряд недостатков. Интерфейс io_uring разрабатывался с учетом этого и предлагает сокращение издержек, связанных с выполнением соответствующих системных вызовов, минуя их, а также реализует сам обмен данными внутри ядра, сокращая переключение контекста между ядром и пользовательским пространством (user-space). Для ввода-вывода используются два кольцевых буфера: очередь отправки (Submission Queue, SQ) и очередь завершения (Completion Queue, CQ), которые используются для постановки операций в очередь и получения результатов соответственно.

🪞 Для примера будем использовать упомянутый выше PoC Curing. Он производит чтение файла /etc/shadow и отправку его на сервер, все это средствами io_uring. Поэтому нет смысла настраивать auditd или другое средство аудита, использующее для мониторинга системные вызовы, так как после настройки интерфейса эти операции будут осуществляться в обход сисколов. В связи с этим для демонстрации аудита будет использоваться Tetragon — готовый движок на базе eBPF с возможностью гибко настраивать политики мониторинга через механизм TracingPolicy. Используя механизм привязки kprobes, мы можем подключиться к любой функции ядра для аудита. Существуют и другие интерфейсы, которые можно использовать для аудита доступа к файлам, например fanotify, но Tetragon универсальнее.

Тут стоит отметить, что средства, отслеживающие системные вызовы, не совсем бесполезны в этом случае: они все еще могут перехватывать вызовы функций io_uring_setup и io_uring_enter, используемых для создания и взаимодействия с экземпляром интерфейса io_uring. В этом случае мы будем видеть, что приложение выполняет действия с этим интерфейсом, но подробности операции и ее параметры получить мы не можем. С этим уже можно работать и помечать подобную активность как подозрительную, так как обычно приложения не опираются на io_uring, а легитимных пользователей этого интерфейса можно без особых проблем занести в белый список. Отсюда сам факт обращения к интерфейсу будет подозрительным поведением.

🫥 Но в нашем случае нам требуется постоянный мониторинг файлов или сокетов. Поэтому составим простую политику для мониторинга файлов через LSM-хук security_file_permission (скриншот 1, скопировать код). Сама функция принимает два аргумента: путь к файлу и запрашиваемые разрешения в виде битовой маски, поэтому в политике через оператор Equal ищем файл по полному пути, а в маске через оператор Mask фильтруем по цифре 4, что означает доступ на чтение. И в результате получаем событие (скриншот 2), когда Curing пытается прочитать файл.

Аналогично можно отследить соединение с сервером: в политике (скриншот 3, скопировать код) используем функцию ядра tcp_connect для получения аргумента sock в ней, где будет вся сетевая информация. Тут у нас нет вводных для фильтрации, и мы увидим все TCP-соединения, так как порт сервера можно переназначить, но тут нам важнее сам факт возможности перехватить событие (скриншот 4) — как мы видим, Curing подключается к своему стандартному порту 8888.

Пусть io_uring и предоставляет обход системных вызовов, но, используя правильные инструменты, его можно перехватить без особых проблем.

#tip #news
@ptescalator

Злоумышленники скомпрометировали десятки NPM-пакетов на ~2 млрд скачиваний 🐾

Что произошло

В рамках фишинговой рассылки был скомпрометирован мейнтейнер Josh "Qix" Junon.

Ему и еще нескольким разработчикам пришло письмо с просьбой обновить второй фактор, так как прошло 12+ месяцев с последнего изменения (скриншоты 1, 2, 3). Письмо пришло с ящика, имитирующего официальный (support@npmjs.help). 🐱

Qix является мейнтейнером больших проектов в экосистеме NPM, среди которых:

🟢chalk (882 форка и 22.7к звезд на GitHub, 313 млн. скачиваний в NPM за последнюю неделю);
🟢debug (957 форков, 11.3к звезд, 372 млн. скачиваний);
🟢strip-ansi (272 млн. скачиваний);
🟢wrap-ansi (206 млн. скачиваний);
🟢has-flag (200 млн. скачиваний).

Проверить, что атака вас не затронула

Вооружитесь osv-scanner. Информация о вредоносных пакетах уже есть в базе osv.dev.

Можно воспользоваться пользовательским скриптом или проверить перечисленные там пакеты самостоятельно (npm ls, yarn why, pnpm why).

Рекомендации для мейнтейнеров

1. Если вам приходится логиниться по ссылкам из писем — проверяйте URL. Помните, что вы — лакомая цель для злоумышленников.

2. Используйте второй фактор. Даже если злоумышленник сможет его выманить фишинговой страницей авторизации, то ему придется как-то получать его вновь и вновь, если у вас 2FA стоит в режиме Authorization and writes (подтверждение всех чувствительных действий, в т.ч. публикация новой версии пакета, режим включен по умолчанию).

3. Ознакомьтесь с практиками OIDC/"trusted publishing" — так вы усложните цель злоумышленнику, ведь ему придется захватить публичный CI/репозиторий для осуществления атаки.

Рекомендации для разработчиков

1. Фиксируйте зависимости. Не допускайте, чтобы пакетный менеджер просто тянул последний релиз используемых вами зависимостей.

2. Добавьте аудит зависимостей (для начала может подойти и osv-scanner) — так вы сможете узнать о проблемах на этапе сканирования зависимостей, а не из новостей.

Рекомендации для AppSec

Вы и без нас все знаете:

1. Настройте внутренний прокси с поддержкой карантина для внутренних проектов.

2. Убедитесь, что ваши разработчики ходят на внутреннее прокси, а не берут пакеты из глобальных репозиториев. 🐱

Stay safe 👍
#npm #supplychain #appsec
@ptescalator

Инструмент группировки APT31. CloudyLoader 🌩

В одном из инцидентов команде PT ESC IR попался интересный вредоносный файл, который загружает полезную нагрузку в несколько этапов. Вредоносный образец состоит из легитимного файла компонента BsSndRpt.exe программного обеспечения BugSplat, которое представляет собой систему сбора и анализа отчетов об ошибках, динамической библиотеки BugSplatRc64.dll и файла полезной нагрузки (шелл-кода). Для правильной работы легитимного файла необходима BugSplatRc64.dll, которая является загрузчиком.

Вредоносная динамическая библиотека накрыта протектором VmProtect версии 3, имя секции изменено на .qwdlgje (скриншот 1). Для сокрытия вызовов Windows API вредонос использует технику API Hashing: для поиска имени функции и имени DLL вычисляется хеш. Алгоритм хеширования следующий:

def CalculateAPIHash(data: bytes):
    v3 = 0xFFFFFFFF
    for byte in data:
        temp1 = (2 * byte) ^ ((2 * byte) ^ (byte >> 1)) & 0x55555555
        v4 = temp1 >> 2
        v5 = 4 * temp1
        temp2 = v5 ^ (v5 ^ v4) & 0x33333333
        v6 = ((temp2 >> 4) | (16 * (temp2 & 0xFF0F0F0F))) & 0xFFFFFFFF
        v8 = int.from_bytes(v6.to_bytes(4, 'little'), 'big')
        for _ in range(8):
            if (v3 ^ v8) & 0x80000000:
                v3 ^= 0xC520DEC7
            v3 = (v3 * 2) & 0xFFFFFFFF
            v8 = (v8 * 2) & 0xFFFFFFFF
    
    v9 = (~v3) & 0xFFFFFFFF
    v10 = (4 * ((2 * v9) ^ ((2 * v9) ^ (v9 >> 1)) & 0x55555555))  & 0xFFFFFFFF
    v11 = (v10 ^ (v10 ^ (((2 * v9) ^ ((2 * v9) ^ (v9 >> 1)) & 0x55555555) >> 2)) & 0x33333333)  & 0xffffffff
    v11 = ((16 * v11) ^ ((16 * v11) ^ (v11 >> 4)) & 0xF0F0F0F) & 0xffffffff
    return int.from_bytes(v11.to_bytes(4, 'little'), 'big')

При вычислении хеш-значения имена DLL должны подаваться на вход уже в верхнем регистре (например, KERNEL32.DLL), в то время как имена функций остаются без изменения.

После всех подготовок BugSplatRc64.dll создает процесс makecab.exe, операцией XOR с ключом 5d 72 89 80 расшифровывается файл полезной нагрузки, которая представляет собой шелл-код. Все строки, используемые в DLL, зашифрованы XOR.

Этапы получения основной нагрузки

1. Запрос к репозиторию scrcpyClone пользователя Range1992: https://raw.githubusercontent.com/Range1992/scrcpyClone/refs/heads/master/app/data/zsh-completion/_scrcpy (скриншоты 2, 3). В полученных из Git данных вредоносный код ищет маркер начала (QQNSR4u) и конца (ZsNpk7Y) закодированной строки. Далее получает данные между маркерами, декодирует из формата Base64, расшифровывает с помощью алгоритма RC4 с ключом 03 07 A0 B0 E3 80 88 77. Полученные данные — адрес основной нагрузки.

2. Запрос к адресу: https://github.com/Range1992/scrcpyClone/raw/refs/heads/master/app/deps/PersonalizationCSP. Зашифрованная основная нагрузка содержит следующие данные:

• ключ RC4 — 8 байт;
• длина полезных данных — 4 байта;
• полезные данные.

Основная полезная нагрузка представляет собой шелл-код CobaltStrike со следующей конфигурацией:

BeaconType                  - HTTPS
Port                        - 443
SleepTime                   - 77665
MaxGetSize                  - 409721416
Jitter                      - 46
PublicKey_MD5               - fe7aa97fbe3fe21e59ead1792ca2dc58
C2Server                    - Moeodincovo.com,/divide/mail/SUVVJRQO8QRC,www.Moeodincovo.com,/divide/mail/SUVVJRQO8QRC
UserAgent                   - Mozilla/5.0 (Windows NT 6.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
HttpPostUri                 - /Terminate/v6.49/LTKAZNE9

Признаками присутствия этого ВПО может служить наличие в файловой системе неподписанной DLL-библиотеки с именем BugSplatRc64.dll.

IoCs:

https://raw.githubusercontent.com/Range1992/scrcpyClone/refs/heads/master/app/data/zsh-completion/_scrcpy
https://github.com/Range1992/scrcpyClone/raw/refs/heads/master/app/deps/PersonalizationCSP
https://Moeodincovo.com/divide/mail/SUVVJRQO8QRC
3356a7d25096e24afe3409540a06f42b2b5012e55a8cad3f6ee06ec13e3471a5
879949e6d70f2d7e21c489552240b13f927fa9586ef7a9343fa07741248860f3

#dfir #ti #apt #reverse #malware
@ptescalator