🧠 Codex-агент провёл анализ стилера в песочнице: работа реверсера отдана LLM Эксперимент на стеке QEMU/libvirt + Volatility 3 + Ghidra + Codex показал: LLM-агент способен автоматически связать данные дампа памяти, статики и сетевых артефактов без участия человека на этапе ручного сопоставления. Автор взял реальный Windows PE-стилер, запустил в изолированной VM, снял память и PCAP, а агент через MCP-интерфейс Ghidra сам извлёк распакованный в памяти модуль, восстановил его структуру как сырой бинарник, нашёл строки с Telegram, Steam, winhttp.dll и User-Agent, сопоставил их с DNS-запросами. Вся цепочка — от дампа до отчёта с YARA- и Sigma-правилами — заняла около 20% пятичасового лимита Codex Pro. По данным Habr, это первый подтверждённый кейс, где «host-controlled sandbox + memory-first triage + Ghidra MCP + LLM» дали объяснимый результат, пригодный для принятия решения о дальнейшем глубоком реверсе. → Стек: QEMU/libvirt (хост), Volatility 3, Ghidra с headless-режимом, Codex как агент оркестрации. → Ключевая находка: артефакт PAGE_EXECUTE_READWRITE в VAD, из которого извлечён PE x64 с пустым Import Directory — классический признак распаковки в памяти. → Сетевые IoC: DNS к telegram.me и steamcommunity.com, но TCP-сессий не было из-за политики изоляции сети. → Сгенерированы YARA-правило по связке MZ-заголовок + URL + winhttp.dll и Sigma-правила (средний уровень из-за легитимности доменов). Главное ограничение не в качестве анализа, а в экономике: один прогон съедает пятую часть дорогого лимита, поэтому схема работает только для прицельного разбора сложных образцов, а не для потока. При этом все решения о том, когда разрешить запуск ВПО и как изолировать VM, остались за человеком — и это не баг, а защита от самоуверенного агента. Интересно, насколько быстро модель научится предлагать политики изоляции сама — и кто возьмёт на себя ответственность за ложные отрицания. #malware_analysis #Codex #Ghidra #Volatility #LLM