Этой статьей я постараюсь логично завершить эксперимент с ханипотом и рассказать про анализ вредоносного ПО силами ИИ. Идея проекта простая: проверить, может ли связка из изолированной виртуальной машины, классических инструментов анализа ВПО и 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 vWindows 11 VM | | guest runner | Sysmon / logs | sample execution vmalware 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 queriessteamcommunity.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: BinaryLoaderbase: 0x1a0000000arch: x86:LE:64:defaultcspec: 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.
Мой любимый блок с благодарностью читателям! Я надеюсь, что вы не остались разочарованными и не жалеете о потраченном времени. Если у вас вдруг появилось желание развернуть ентого Франкенштейна самостоятельно, то я с удовольствием дам вам все необходимые комментарии!
ссылка на оригинал статьи https://habr.com/ru/articles/1057680/