ИИ против вредоноса. Песочница и беглый теханализ

11.07.2026 ideipro.ru

Этой статьей я постараюсь логично завершить эксперимент с ханипотом и рассказать про анализ вредоносного ПО силами ИИ. Идея проекта простая: проверить, может ли связка из изолированной виртуальной машины, классических инструментов анализа ВПО и LLM-агента дать не только красивый отчет, как было в прошлый раз, а реально полезный материал для борьбы с вредоносами.

В качестве необходимого и достаточного минимума были определены следующие функции моего проекта:

безопасно запустить образец в Windows VM;
снять память, диск и сетевой трафик со стороны хоста;
провести статический анализ через Ghidra;
получить техническое заключение, пригодное для принятия решения и написания правил.

Далее описывается минимальный набор умозаключений, необходимых для создания такого проекта. Самый внимательный читатель скажет, что это очень дорогая и не очень информативная копия ANY.RUN, CAPE или любимого с детства VirusTotal, но тут я сделаю небольшое замечание — основная идея здесь — не потоковый анализ ВПО, а достаточно глубокий анализ конкретного образца, с быстрым ответом для исследователя. Уже на его основании реверс-инженер принимает решение о дальнейших погружениях в глубины бинарщины.

Что я хотел проверить

Гипотеза была такой:

Если дать Codex контролируемый доступ к инструментам анализа, то он сможет провести первичное исследование как реверс-инженер: найти компрометирующие места в бинарнике, сопоставить динамику и статику, сформировать выводы и отчеты.
Спойлер — он смог.

Нужно все-таки помнить, что ИИ все еще не является таблеткой от всех специалистов и контролировать его работу, особенно когда речь идет про ИБ, необходимо. Решения, которые остались за мной, а не за бездушным вычислителем:

как изолировать виртуальную машину;
какой снэпшот считать эталонным;
когда разрешать проводить запуск динамического исследования (да, я не шучу).

Агенту, разумеется, оставляем черновую самую интересную работу: подготовка скриптов, проверка окружения, запуск pipeline передачи образца из карантина в ВМ, обработка артефактов, анализ дампа памяти, импорт в Ghidra, формирование отчетов.

Архитектура

Система разделена на две зоны: хост и гостевая Windows VM.

Главное правило: снимать максимальное количество данных со стороны хоста. Доверять гостевой системе нельзя; данные, полученные из нее, считаются недоверенными, так как после запуска ВПО она считается потенциально скомпрометированной.

Что находится внутри 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-запросы к:

telegram.me;
steamcommunity.com;
ряду фоновых 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 нашлись строки:

https://telegram.me/…;
https://steamcommunity.com/profiles/…;
winhttp.dll;
User-Agent под Windows/Edge;
локальный путь вида C:WINDOWSTEMP…;
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.

Мой любимый блок с благодарностью читателям! Я надеюсь, что вы не остались разочарованными и не жалеете о потраченном времени. Если у вас вдруг появилось желание развернуть ентого Франкенштейна самостоятельно, то я с удовольствием дам вам все необходимые комментарии!

Источник: habr.com

Оцените материал:

Оставить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.