Windows Kernel Driver Code & Exploitation Techniques

https://x.com/i/broadcasts/1XxyggOZBBgGM

https://www.youtube.com/live/CFsjVyTXtzg?si=TJfm76obW3TgPYQc

Deobfuscation in the Age of Agentic Reverse Engineering СЛАЙДЫ

https://synthesis.to/presentations/recon26_agentic_deobfuscation.pdf

хорошая преза, только вот binary ninja в headless режиме доступна только в commercial license, которая стоит 1500 долларов =/

интересно

Vibe Reversing Across IDA, Ghidra, and Binary Ninja

https://github.com/allthingsida/allthingsida/blob/main/presentations/select_from_binary_vibe_re/vibe_re_xsql.pdf

куча инфы

Practical macOS Security Researcher Notes and Guide (OSMR)

https://redteamrecipes.com/blog/2025/12/osmrnotes/

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

Надо чекнуть

Toolkit for Windows internals, vulnerability analysis, and reproducible security research workflows.

https://github.com/kernelstub/NTForge

Я прогнал маленькие локальные модели на небольшой задачке - разобрать гипотетическое Windows Electron приложение и найти в нем уязвимости. Результаты описал в статье:

https://www.orderofsixangles.com/ru/2026/06/24/local-model-testing-ru.html

CVE-2026-41089 PoC — Netlogon CLDAP stack buffer overflow (CVSS 9.8 CRITICAL)

https://github.com/0xABCD01/CVE-2026-41089

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

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

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

Добавили MCP

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

Решил исследовать тему исследования малвари путем запуска через 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 гигабайтным логом справится локальная ллм типа геммы

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

Внутри винды, которая запущена под 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.

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

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