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

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

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

безопасно запустить образец в Windows VM;

снять память, диск и сетевой трафик со стороны хоста;

провести статический анализ через Ghidra;

получить техническое заключение, пригодное для принятия решения и написания правил.

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

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

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

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

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

как изолировать виртуальную машину;

какой снэпшот считать эталонным;

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

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

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

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

Внутри Windows VM установлен минимальный набор компонентов, необходимых для запуска и первичной регистрации событий:

подготовленный агент для запуска образца;

PowerShell-скрипты запуска;

Sysmon-конфигурация;

каталог для приема образца;

механизм записи базовых артефактов.

Разумеется, речи о сетевом канале, drag-and-drop или общих папках не идет, хоть риск это и благородное дело, но оставлять канал, по которому настраивалась песочница во время пуска - выстрел себе же в ногу.

На хосте находится основная логика оркестрации:

создание диска от эталонного снэпшота;

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

запуск VM через libvirt;

захват PCAP;

снятие memory dump;

Volatility-анализ;

Ghidra-анализ;

генерация отчетов.

Дамп, PCAP и анализ Volatility 3 на хосте — это не каприз, а необходимость: как я сказал ранее, гость считается полностью скомпрометированным и наша задача провести анализ пораженной цели.

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

Сценарий был примерно таким:

Образец запустился как sample.exe , его родителем был PowerShell агент. Через 180 секунд запуск был остановлен по таймауту.

Орфография сохранена

Динамический анализ: что увидит память

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-доменов.

Но TCP/HTTP/TLS-сессий в захвате не оказалось. Ограничение, которое я накладываю на сеть, просто не позволит этого сделать, так как она изолирована.

Статический анализ: исходник против распакованного PE

Сначала в Ghidra был загружен исходный PE. Ghidra распознала его как Go binary, восстановила Go-структуры и множество runtime-символов.

Это полезно, но в таком виде анализ оказался шумным:

много runtime.* ;

много Go-служебных функций;

обфусцированные имена;

полезные IOC не лежат на поверхности.

Затем мы загрузили извлеченный из памяти PE.

И тут возникла новая проблема: обычный PE-loader Ghidra падал на поврежденной debug/runtime-разметке. Это нормально для дампа: он похож на PE, но не обязан быть валидным файловым PE.

Решение: импортировать его как сырой файл:

После этого Ghidra смогла разобрать код. В распакованном файле было найдено около 857 функций и небольшой, но ценный набор строк.

Что показал распакованный модуль

В распакованном PE нашлись строки:

https://telegram.me/ ... ;

https://steamcommunity.com/profiles/ ... ;

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;

кандидат на сетевую обвязку;

функция сборки буфера/пакета перед дальнейшей обработкой.

То есть Telegram/Steam оказались не случайным фоном гостевой ОС, так как есть в PE-памяти и коррелируют с DNS из гостя.

Заключение после запуска

Рабочая цепочка выглядит так:

Главное заключение по образцу:

Образец вредоносный. Он распаковывает PE-модуль в память, использует runtime-конфигурацию, динамически резолвит WinHTTP API и содержит Telegram/Steam IOC, которые коррелируют с DNS-запросами в PCAP.

Это уже достаточно для подтверждения жизнеспособности идеи.

От анализа к правилам: YARA и Sigma

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

На выходе для run появляются:

iocs.json - машинно-читаемый набор IOC;

iocs.md - человекочитаемая сводка;

YARA-правило по распакованному PE;

Sigma-правило по DNS-индикаторам;

Sigma-правило по файловому артефакту.

Для текущего образца YARA-правило строится не по одному признаку, а по связке:

Такой подход снижает риск ложных срабатываний по одному легитимному домену. 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 версии, так что это не потоковый инструмент. Пока что!

Ну и итогом работы стало наличие у меня воспроизводимого алгоритма:

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