Этой статьей я постараюсь логично завершить эксперимент с ханипотом и рассказать про анализ вредоносного ПО силами ИИ. Идея проекта простая: проверить, может ли связка из изолированной виртуальной машины, классических инструментов анализа ВПО и LLM-агента дать не только красивый отчет, как было в прошлый раз, а реально полезный материал для борьбы с вредоносами.
В качестве необходимого и достаточного минимума были определены следующие функции моего проекта:
безопасно запустить образец в Windows VM;
снять память, диск и сетевой трафик со стороны хоста;
провести статический анализ через Ghidra;
получить техническое заключение, пригодное для принятия решения и написания правил.
Далее описывается минимальный набор умозаключений, необходимых для создания такого проекта. Самый внимательный читатель скажет, что это очень дорогая и не очень информативная копия ANY.RUN, CAPE или любимого с детства VirusTotal, но тут я сделаю небольшое замечание - основная идея здесь - не потоковый анализ ВПО, а достаточно глубокий анализ конкретного образца, с быстрым ответом для исследователя. Уже на его основании реверс-инженер принимает решение о дальнейших погружениях в глубины бинарщины.
Что я хотел проверить
Гипотеза была такой:
Если дать Codex контролируемый доступ к инструментам анализа, то он сможет провести первичное исследование как реверс-инженер: найти компрометирующие места в бинарнике, сопоставить динамику и статику, сформировать выводы и отчеты.
Спойлер - он смог.
Нужно все-таки помнить, что ИИ все еще не является таблеткой от всех специалистов и контролировать его работу, особенно когда речь идет про ИБ, необходимо. Решения, которые остались за мной, а не за бездушным вычислителем:
как изолировать виртуальную машину;
какой снэпшот считать эталонным;
когда разрешать проводить запуск динамического исследования (да, я не шучу).
Агенту, разумеется, оставляем черновую самую интересную работу: подготовка скриптов, проверка окружения, запуск pipeline передачи образца из карантина в ВМ, обработка артефактов, анализ дампа памяти, импорт в Ghidra, формирование отчетов.
Архитектура
Система разделена на две зоны: хост и гостевая Windows VM.
Linux host | | libvirt / QEMU | pcap capture | memory dump | overlay/result disks | Volatility 3 | Ghidra + Ghidra MCP | Codex v Windows 11 VM | | guest runner | Sysmon / logs | sample execution v malware process
Главное правило: снимать максимальное количество данных со стороны хоста. Доверять гостевой системе нельзя; данные, полученные из нее, считаются недоверенными, так как после запуска ВПО она считается потенциально скомпрометированной.
Что находится внутри VM
Внутри Windows VM установлен минимальный набор компонентов, необходимых для запуска и первичной регистрации событий:
подготовленный агент для запуска образца;
PowerShell-скрипты запуска;
Sysmon-конфигурация;
каталог для приема образца;
механизм записи базовых артефактов.
Разумеется, речи о сетевом канале, drag-and-drop или общих папках не идет, хоть риск это и благородное дело, но оставлять канал, по которому настраивалась песочница во время пуска - выстрел себе же в ногу.
Что находится снаружи
На хосте находится основная логика оркестрации:
создание диска от эталонного снэпшота;
подключение съемного носителя к VM (спокойно, он виртуальный);
запуск VM через libvirt;
захват PCAP;
снятие memory dump;
Volatility-анализ;
Ghidra-анализ;
генерация отчетов.
Дамп, PCAP и анализ Volatility 3 на хосте — это не каприз, а необходимость: как я сказал ранее, гость считается полностью скомпрометированным и наша задача провести анализ пораженной цели.
Почему QEMU/libvirt
Выбран QEMU/libvirt, потому что он дает низкоуровневый контроль над жизненным циклом VM с простым (если слово простой вообще применимо) управлением из терминала:
снэпшот;
подключение дисковых пространств;
управляемое подключение носителей;
снятие дампа;
сетевые интерфейсы;
возможность снимать PCAP без участия гостя.
Откровенно говоря, я virt-manager не очень люблю, так как привык к лакшери VMware, но такой глубины автоматизации через VMware Workstation без отдельной обвязки я не получил.
Первый важный инженерный урок: права доступа
Одна из самых неприятных проблем оказалась не в реверсе и не в ИИ, а в правах доступа.
QEMU запускает процессы от отдельного пользователя, например libvirt-qemu. Codex работает от обычного пользователя. Диски и дамп памяти для vol3 создаются в разных местах и разными субъектами. В результате на первых прогонах возникали конфликты: VM не могла писать в диск, агент не мог читать дамп, часть артефактов требовала ручного sudo.
Решение было не "дать агенту sudo", а аккуратно настроить ACL:
базовый снимок доступен QEMU на чтение;
директория /runs (где мы бегаем, ха) доступна и пользователю, и QEMU;
новые файлы наследуют нужные ACL.
Второй урок: BitLocker и offline extraction
Я сознательно не стал отключать шифрование Windows. Это ближе к реальной системе, но усложняет извлечение данных с диска. Если гостевая файловая система зашифрована, то снятие дампа с диска может оказаться бесполезным без дополнительных ключей или экспорта с виртуалки. Вот тут самое узкое место с точки зрения безопасности - гостевые артефакты экспортируются на отдельный незашифрованный диск.
Как выглядит пуск
Начну с небольшой оговорки: очевидно, что я проводил несколько запусков комплекса для отладки рабочего алгоритма (самый комичный пример: мне не сразу пришло в голову, что обновлённый WinDefender просто не даст мне запустить вредонос в песочнице) и исправления выявленных ошибок. Но расскажу я про красивый образец, который резолвил на реальный стим аккаунт - это меня позабавило.
Собственно, это был Windows PE-стилер, скачанный c malwarebazaar -bac12c7b2bc08d4d552e4692bc1566d7d54efc67c3a1131628c491c23626d773. Почему не с моего ханипота, спросите вы? Потому что на ханипоте за 2 с небольшим недели оказались только батники и dll, ни одним exe со мной так и не поделились злоумышленники.
Сценарий был примерно таким:
Подготовить директорию с валидными правами на чтение/запись Создать временную виртуалку от снэпшота Параллельно образец импортируется в Ghidra/headless для анализа в статике Подключить sample(.exe) как носитель Запустить VM Агент стартует sample.exe Хост пишет PCAP По таймауту снять дамп памяти Остановить VM Запустить Volatility Извлечь подозрительные артефакты При необходимости импортировать артефакты в Ghidra для повторного анализа Сопоставить динамику и статику
Образец запустился как sample.exe, его родителем был PowerShell агент. Через 180 секунд запуск был остановлен по таймауту.
Орфография сохранена
Погнали, сделай полный автоматический прогон. Запуск в песочнице, по стандарту, паралелльно с этим пусть сабагент даст быстрый анализ по сэмплу в ghidra, затем, после того как закончим с песочницей, сразу проведи анализ с помощью volatility так же парарелельно с этим сними характеристики сети suricata. Если будут обнаружены интересные PE артефакты проведи дополнительный анализ в Ghidra, или если будет вообще дропнут нвоый файл, вытащи его из дампа и проанализируй в Ghidra, затем собери все результаты и сгенерируй YARA/SIGMA правила, после чего со всем этим сгенерируй технический html отчет. Сведения для пуска: run_id:03FullLoadStart path:/Downloads/*sha256*.zip sha256:*sha256* policy:dump net:isolated malware
Динамический анализ: что увидит память
Volatility дал ключевую находку: внутри процесса sample.exe был обнаружен артефакт с правами PAGE_EXECUTE_READWRITE и заголовком MZ.
unpacked/memory PE sha256: bf618f025146ddfb0e4dccd3db60ea81e367fca8acd29795f5873e55dc402ce1
Обычно это означает, что в памяти появился PE-модуль, который не обязательно существует как нормальный файл на диске. Возможные варианты:
распакованная нагрузка;
рефлективный загрузчик исполняемого файла;
"смаплено" что-то напрямую в память.
Из этого региона был извлечен PE x64. У него было 4 секции, image base 0x1a0000000, entry point в районе 0x1a00e3dec. Import Directory оказался пустым.
Это эталонный для меня случай, так как теперь для статики появился второй образец.
Сетевой след: полезный, но неполный
В трафике были DNS-запросы к:
ряду фоновых Microsoft-доменов.
https://telegram.me/af97ri https://steamcommunity.com/profiles/76561198680197300 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Safari/537.36 Edg/147.0.0.0 --- telegram.me 64 DNS queries steamcommunity.com 64 DNS queries
Но TCP/HTTP/TLS-сессий в захвате не оказалось. Ограничение, которое я накладываю на сеть, просто не позволит этого сделать, так как она изолирована.
Статический анализ: исходник против распакованного PE
Сначала в Ghidra был загружен исходный PE. Ghidra распознала его как Go binary, восстановила Go-структуры и множество runtime-символов.
Это полезно, но в таком виде анализ оказался шумным:
много
runtime.*;много Go-служебных функций;
обфусцированные имена;
полезные IOC не лежат на поверхности.
Затем мы загрузили извлеченный из памяти PE.
И тут возникла новая проблема: обычный PE-loader Ghidra падал на поврежденной debug/runtime-разметке. Это нормально для дампа: он похож на PE, но не обязан быть валидным файловым PE.
Решение: импортировать его как сырой файл:
loader: BinaryLoader base: 0x1a0000000 arch: x86:LE:64:default cspec: windows
После этого Ghidra смогла разобрать код. В распакованном файле было найдено около 857 функций и небольшой, но ценный набор строк.
Что показал распакованный модуль
В распакованном PE нашлись строки:
winhttp.dll;User-Agent под Windows/Edge;
локальный путь вида
C:\WINDOWS\TEMP\...;hex-идентификатор/ключ.
Затем через Ghidra MCP были получены xref и декомпиляция ключевых функций.
Главные находки:
функции с XOR/rotate/hash-heavy логикой, похожие на декодирование/обфускацию;
функция инициализации Telegram/Steam/User-Agent строк;
динамический resolver WinHTTP API по hash-значениям;
WinHTTP session initialization;
кандидат на сетевую обвязку;
функция сборки буфера/пакета перед дальнейшей обработкой.
FUN_000e2674(s_https___telegram_me_af97ri_0021f0e0 + uVar2 * 0x240, 0x100); FUN_000e2674(s_gw3n9_0021f1e0 + (longlong)DAT_0010a06c * 0x240, 0x40, param_2); FUN_000e2674(s_Mozilla_5_0__Windows_NT_10_0__Wi_0021f220 + (longlong)DAT_0010a06c * 0x240, 0x100, param_3); DAT_0010a06c = DAT_0010a06c + 1;
То есть Telegram/Steam оказались не случайным фоном гостевой ОС, так как есть в PE-памяти и коррелируют с DNS из гостя.
Заключение после запуска
Рабочая цепочка выглядит так:
Запуск в VM -> memory dump -> Volatility malfind -> извлечение PE из VAD -> Ghidra raw import -> MCP-декомпиляция -> xref к IOC -> итоговый отчет
Главное заключение по образцу:
Образец вредоносный. Он распаковывает PE-модуль в память, использует runtime-конфигурацию, динамически резолвит WinHTTP API и содержит Telegram/Steam IOC, которые коррелируют с DNS-запросами в PCAP.
Это уже достаточно для подтверждения жизнеспособности идеи.
От анализа к правилам: YARA и Sigma
После ручной проверки Ghidra я решил добавить на сдачу от потраченных токенов этап генерации правил обнаружения ВПО. Это, разумеется, не замена аналитика, но способ быстро превратить проверенные находки в воспроизводимые заготовки правил.
На выходе для run появляются:
iocs.json- машинно-читаемый набор IOC;iocs.md- человекочитаемая сводка;YARA-правило по распакованному PE;
Sigma-правило по DNS-индикаторам;
Sigma-правило по файловому артефакту.
Для текущего образца YARA-правило строится не по одному признаку, а по связке:
MZ header + Telegram URL + Steam URL + User-Agent + winhttp.dll + hex-идентификатор
Такой подход снижает риск ложных срабатываний по одному легитимному домену. Telegram и Steam сами по себе не являются вредоносными IOC, но вместе с распакованным PE, WinHTTP-слоем и конкретным ключом они становятся полезной сигнатурой для этого кластера.
Sigma-правила получаются менее полезными, так как DNS к telegram.me или steamcommunity.com может быть нормальным пользовательским поведением, поэтому уровень такого правила средний, а ложноположительные срабатывания явно прописаны. Зато в лабораторном контексте эти правила полезны: их можно прогонять по Sysmon/Suricata/Zeek-like событиям и быстро видеть, повторяется ли поведение в следующих запусках.
TLDR или мои выводы
Ручной анализ ВПО обычно упирается не в отсутствие знаний или конкретных инструментов, а в разрыв между ними. Volatility показывает одно, Ghidra второе, PCAP третье, файловая система четвертое. Приходится держать все это в голове, на бумажках или в заметках и однообразность действий иногда начинает выводить из себя. LLM-агент хорошо подходит именно для рутинной работы, мне не пришлось:
вручную запускать вредонос;
просматривать бинарник целиком глазами в Ghidra;
искать подозрительные артефакты в vol3;
карпеть над PCAP-ом.
Действия и решения, сделанные ИИ-ассистентом, дали сформированный материал, на основе которого я могу понять, стоит ли уже мне самостоятельно нырять в пучину бинарщины или образец оказался простым для анализа и не стоит моего внимания. Пока что агент не заменяет исследователя в контексте "принятия решений" на все сто процентов, но заметно освобождает для чего-то сложного и интересного.
Итоговый MVP подтвердил гипотезу. Был взят реальный PE-образец, он был запущен в изолированной Windows VM, была снята память, извлечен распакованный модуль, загружен в Ghidra, после чего полученная декомпиляция через MCP была связана с сетевыми следами. И это все всего лишь за каких-то 20% от 5-часового лимита Codex. Вот тут тонкий лед: экономия сил возможна только 3-4 раза за один лимит Pro версии, так что это не потоковый инструмент. Пока что!
Ну и итогом работы стало наличие у меня воспроизводимого алгоритма:
host-controlled sandbox + memory-first triage + Ghidra MCP + LLM-assisted correlation = explainable malware analysis workflow
P. S.
Мой любимый блок с благодарностью читателям! Я надеюсь, что вы не остались разочарованными и не жалеете о потраченном времени. Если у вас вдруг появилось желание развернуть ентого Франкенштейна самостоятельно, то я с удовольствием дам вам все необходимые комментарии!
