Order of Six Angles

Мой урожай

Короче, идея с анализом малвари под QEMU TCG провалилась. Этот режим крайне медленный, даже если отключить мониторинг памяти и оставить только сисколы. Вернулся к KVM режиму. Ускорить, оптимизировать, давать больше времени вообще не помогает.

Сегодня каналу исполнилось 7 лет 🍾

с помощью qemu tcg можно также исследовать UEFI малварь, незнаю дойдут ли у меня до туда руки, так как щас чисто под юзерспейс малварь разрабатываю. Ну посмотрим

Вместо приватных репозиториев на гитхабе я стал использовать Forgejo - это селф хостед локальный репозиторий

В результате запуска одного сэмпла малвари, qemu tcg виртуалка генерит около 550 Мегабайт текста, и это еще сильно обрезанная версия. Приходится выставлять лимиты, иначе легко можно несколько гигабайт на один ран потратить. Эти гигабайты надо еще выкачать с виртуалки на хост, передать мне по локальной сети. Для полноценных больших ресерчей один прогон будет генерить десятки гигабайт данных.

Внутри винды, которая запущена под qemu tcg мы не ставим Procmon, Sysmon, дебаггеры и прочие анализирующие тулзы. Винда остается максимально чистой, а все наблюдение происходит снаружи, через QEMU TCG и офлайн-парсинг логов. Qemu Guest Agent тоже удаляется. QEMU TCG пишет не красивый отчет, а низкоуровневый поток событий: выполненные блоки кода, syscall-события, обращения к памяти. На этом уровне в логе есть шум всей виртуальной машины: ядро Windows, службы, cmd/launcher, conhost, дочерние процессы и сам sample. В этом шуме мы должны найти образ/процесс целевой малвари и выделить конкретно ее действия. Сделать это можно по комбинации сисколов и определенных действий. Главная сложность — отделить поведение образца от шума операционной системы и превратить поток низкоуровневых событий QEMU TCG в понятную картину: какие файлы трогал sample, куда писал, какие ключи реестра менял, пытался ли инжектиться в другие процессы и оставлял ли следы закрепления. Как это реально работает: 1. QEMU-плагин пишет сырой syscall-поток: PID, TID, CR3, image, syscall number, RIP, аргументы регистров и часть stack-аргументов. 2. Скрипт парсит ntdll.dll из гостевой Windows и строит карту:

0x55 -> NtCreateFile
0x3A -> NtWriteFile
0x18 -> NtOpenKey
...

То есть syscall number превращается в человеческое имя: NtCreateFile, NtWriteVirtualMemory, NtSetValueKey. 3. Затем события фильтруются до PID/image целевого sample 4. После этого идут правила. Сисколы:

NtCreateFile / NtOpenFile / NtReadFile / NtWriteFile

попадают в file activity. А

NtCreateKey / NtOpenKey / NtSetValueKey / NtDeleteValueKey

попадают в registry activity. Да, для анализа обычной малвари это оверхэд. Но зато такой стеап может быть полезен и для анализа эксплоитов, особенно ядерных, так как можно видеть всю работу в ядре.

Есть проект https://panda.re/, который реализует точно такую же идею, что и я пописал. Я его пробовал использовать, но он очень нестабилен, еле как работает, больше трети функций вообще не работают, местами там куски дерьма мамонта. Вообще не юзабельное. Поэтому свой велосипед оказывается лучше и притом работает с виртуалкой Вин10 (панда только с вин 7).

Решил исследовать тему исследования малвари путем запуска через QEMU TCG, в полностью headless-режиме. QEMU TCG — это режим QEMU без аппаратной виртуализации, где гостевые инструкции не выполняются напрямую на CPU, а переводятся и исполняются самим QEMU через Tiny Code Generator. Tiny Code Generator берет блоки инструкций гостевой архитектуры, переводит их во внутреннее представление, а затем генерирует исполняемый код для CPU хоста. Эти переведенные блоки кэшируются и переиспользуются, поэтому QEMU не интерпретирует каждую инструкцию заново, а выполняет динамическую бинарную трансляцию. Стек получился такой: Proxmox VE -> Debian VM -> QEMU -> Windows 10 guest -> malware sample На железе стоит Proxmox VE. Внутри него поднял минимальную Debian VM, а уже внутри Debian запускается QEMU с Windows 10. То есть Windows с малварью живет не напрямую в Proxmox, а внутри nested QEMU. Параметры Debian VM: - Debian GNU/Linux 13 trixie - 8 vCPU - ~8 GB RAM Режим TCG медленнее, зато QEMU сам транслирует guest-инструкции и может логировать выполнение на уровне блоков, инструкций и CPU state. QEMU запускался примерно так:

qemu-system-x86_64 \
  -accel tcg,thread=multi \
  -cpu max \
  -smp 8 \
  -m 4096 \
  -display none \
  -nic none \
  -drive file=win10-run.qcow2,format=qcow2,if=ide \
  -serial file:serial.log \
  -D qemu-tcg.log \
  -d guest_errors

Перед запуском создается snapshot/overlay, внутрь Windows копируется sample, затем Windows стартует в TCG. Один реальный прогон малвари занял примерно 5 минут. За 60 секунд полной трассировки получилось около 2.1 GB лога. Лог содержит сырые инструкции, который выполнялись на "процессоре":

IN:
0xfffff80577ca06a1:  48 8b c7      movq %rdi, %rax
0xfffff80577ca06a4:  eb ac         jmp  0xfffff80577ca0652

Trace 6:
RAX=0000000000000000 RBX=ffffe509e52773f8
RIP=fffff80577ca06a1 RFL=00040246
CR3=000000012dd3f000

Мы также видим весь kernel space, любой код который там выполнялся, все системколлы, полный доступ к памяти винды, что дает очень много инфы о запускаемой программы. Далее я хочу чекнуть как с 2 гигабайтным логом справится локальная ллм типа геммы

В итоге была найдена только 1 уязвимость out of bounds read (cwe 126), зарепортил, уровень medium 5.5, посмотрим че ответя. Таргет был Windows driver ПО Krisp https://hackerone.com/krisp?type=team

Добавили MCP

https://github.com/kernullist/kn-live-dbg - полезная тулза. ЛЛМ с ней норм работает. Помогает проводить проверку найденных крешей в драйвере. Я слежу за автором в твиттере, тулза постоянно обновляется, он говорил что добавил МСП в нее, но пока вроде не запушил. Даже без mcp ллм норм с ней работает

Короче, отфаззил один таргет с hackerone, фаззился он недели две. За это время нашлось ровно 100 крэшей (красивое число). Теперь начался triage. Пока нашел только Dos.

Случайно наткнулся на репозиторий, где приводится небольшой намеренно уязвимый бинарник. Решил чекнуть сколько уязвимостей найдут маленькие модели

CVE-2026-41089 PoC — Netlogon CLDAP stack buffer overflow (CVSS 9.8 CRITICAL) https://github.com/0xABCD01/CVE-2026-41089

Я прогнал маленькие локальные модели на небольшой задачке - разобрать гипотетическое Windows Electron приложение и найти в нем уязвимости. Результаты описал в статье: https://www.orderofsixangles.com/ru/2026/06/24/local-model-testing-ru.html

Надо чекнуть Toolkit for Windows internals, vulnerability analysis, and reproducible security research workflows. https://github.com/kernelstub/NTForge

я улучшил промпт, добавил немного инстурментов, пошаманил над виртуалкой, и запустил исследовать новый таргет. Посмотрю на результаты, и если они будут удовлетворительны, то скину детали. Также я в воскресенье весь день тестил небольшие модельки для security анализа на своем мак мини 24 Гб, результаты записал, но пока лень выкладывать, но думаю выложу, вдруг кому интересно будет