Man in the Agent: почему ИИ не отменяет атрибуцию
Он просто прячет человека на один слой дальше.
За последний год я несколько раз ловила себя на одном и том же раздражении. Открываешь очередной громкий заголовок про «автономную AI-атаку», а внутри — всё тот же интернет: CVE, учётки, туннели, GitHub, VPS, криво настроенный сервис и человек, который где-то всё это запустил.
ИИ здесь действительно меняет очень многое. Просто, как мне кажется, мы часто смотрим не туда.
Меня меньше интересует вопрос «может ли модель сама взломать сервер». Уже может — иногда. Гораздо интереснее другой вопрос: что происходит с расследованием, когда между человеком и жертвой появляется ещё один слой, который сам планирует, вызывает инструменты, хранит состояние и иногда порождает других агентов?
Я разобрала четыре публичных кейса 2025–2026 годов. Они хорошо складываются в лестницу автономности: от модели, которая пишет malware, до оркестратора, который сам распределяет работу между субагентами.
Спойлер: человек из этой цепочки никуда не исчез. Но путь до него стал длиннее.
00THE PROBLEMЧто вообще изменилось
До ИИ у расследователей уже были три большие проблемы.
Объём. Данных больше, чем человек способен нормально просмотреть.
Корреляция. Логи живут отдельно, аккаунты атакующего — отдельно, сетевые связи — отдельно, инфраструктурные артефакты — отдельно. И всё это надо как-то связать в одну цепочку.
Ручной труд. Даже когда данные есть, значительную часть расследования мы по-прежнему склеиваем руками.
ИИ ничего из этого не перечеркнул. И сами атаки в четырёх кейсах ниже тоже не требуют новой кибермагии: эксплуатация известных CVE, кража учёток, privilege escalation, lateral movement, антифорензика, туннели, публичные PoC.
Новое — в экономике этой работы.
Следующая попытка стала почти бесплатной по человеческому времени. Один оператор может производить объём действий, похожий на работу команды. Модель может прочитать ошибку, исправить команду и повторить попытку без отдельного решения человека на каждом шаге. А человеческий «почерк» в коде становится слабее: всё больше в нём отпечатка модели, инструкций и workflow.
И вот это уже ломает старые эвристики расследователя. «Слишком много кода для одного человека» больше не значит команду. «Очень аккуратный код» не значит сильного разработчика. А количество ATT&CK-техник само по себе хуже объясняет опасность актора, если следующий шаг выбирает не человек, а агент.[1]
Для меня удобнее всего думать об ИИ здесь как о новом control plane. Раньше было: человек → инструмент → инфраструктура → жертва. Теперь между человеком и инструментом появляется prompt, агент, его состояние и набор tool calls.
01THE LEVELSЧетыре уровня автономности
Я исхожу из простой вещи: любой агент в этих атаках всё равно завязан на человеке. В начале цепочки есть исходный prompt или цель, заданная человеком. Автономность здесь означает не отсутствие человека вообще, а то, сколько команд и скриптов агент способен выполнить после этого без нового участия оператора.
Уровень 1. Модель пишет инструмент. Человек задаёт требования, тестирует и запускает результат.
Уровень 2. Модель исполняет атаку. Внутри одной задачи она может сделать много действий, но за следующей задачей возвращается к человеку.
Уровень 3. Агент сам выбирает следующий трек. Человек запускает сессию, а система уже сама решает, куда идти после результата.
Уровень 4. Оркестратор управляет субагентами. Появляется отдельный слой задач, гипотез, приоритетов и результатов нескольких агентов.
Важно понимать автономность агента на уровне атаки: на каждом уровне улики физически переезжают в другое место.
02THE BUILDУровень 1 · VoidLink
Первый кейс — Linux-malware framework VoidLink.
Check Point увидела незрелые образцы и наблюдала, как они очень быстро превращаются в полноценный модульный фреймворк: загрузчики, имплант, руткиты, больше тридцати плагинов, поддержка облаков, Kubernetes и Docker.[2]
Сам по себе код здесь не самое интересное. Интереснее несоответствие объёма и времени — ну, для привычного хода вещей.
В ранней документации был план примерно на двадцать недель и три условные внутренние команды. Первый рабочий имплант появился меньше чем за неделю, а код быстро вырос до десятков тысяч строк.
Раньше такой темп был бы неплохим косвенным признаком команды. Теперь — уже нет.
Как вообще доказали участие ИИ
Не одной сигнатурой. И это важная часть истории.
Check Point увидела project-level артефакты: sprint plans, specs, test reports и helper-файлы TRAE.[2] Elastic посмотрела на исходники и увидела нумерованные фазы, серии последовательных версий и слишком учебные комментарии.[3] Sysdig — на бинарные артефакты: одинаковый debug output, заглушки вроде John Doe, повторяющиеся версии v3.[4] Ontinue — на разрывы и дублирование фаз.[5]
По отдельности любой такой признак довольно слабый. Человек тоже может написать многословный комментарий. John Doe — вообще не доказательство чего-либо. Сила появилась, когда несколько независимых слоёв проекта дали одну картину.
Причём исследователи расходились в оценке доли ИИ. Check Point говорила почти о полной генерации, Sysdig видела сильную человеческую экспертизу рядом с AI-assisted разработкой.
И мне кажется, это правильная постановка вопроса. Не «ИИ или не ИИ», а что именно делала модель, что делал человек и какие следы оставил каждый из них.
Где лежали улики
Самое забавное: у жертвы — нигде. Жертвы в этой истории вообще ещё нет.
Главные артефакты лежали на сервере разработчика: исходники, спецификации, планы спринтов, тестовые отчёты и файлы TRAE. И получили их из-за максимально неагентной причины — открытой директории.
То есть первая история про AI-malware раскрывается не потому, что исследователи научились распознавать «нейросетевой код». А потому что человек оставил наружу свою рабочую папку.
Check Point потом сделала ещё один красивый эксперимент: прогнала ту же markdown-документацию через похожий TRAE-workflow и получила код, близкий к оригиналу.[2]
Вот здесь, на мой взгляд, происходит важный сдвиг. Если реализация воспроизводится из спецификации, то вопрос «кто написал эту функцию?» становится менее интересным. Код сам по себе становится гораздо более слабым поинтом для атрибуции threat actor’а. Зато спецификация, инструкции и сам процесс разработки становятся полноценными уликами.
03THE SESSIONУровень 2 · Мексика
Во втором кейсе модель не готовит malware на будущее. Она уже находится внутри атаки.
Gambit описала кампанию против девяти государственных организаций Мексики. Claude Code работал «на передовой»: исследовал системы, писал и отлаживал эксплойты, строил туннели, доставал credentials и выгружал данные.[6]
Параллельно оператор использовал собственный Python-конвейер примерно на 17,5 тысячи строк. Он собирал данные с уже взломанных серверов и отправлял их второй модели — GPT-4.1. Та играла роль аналитика: превращала свалку процессов, конфигов, паролей и истории команд в структурированный отчёт — что это за сервер, какие учётки ценны и куда идти дальше. Забавный факт: в BACKUPOSINT.py ей задали шесть personas, а финальный system prompt в переводе Gambit буквально кастовал её как ELITE INTELLIGENCE ANALYST с опытом NSA TAO, CIA/SAD cyber infiltration operations, APT hunting, nation-state level operations.[6] То есть GPT-4.1 вполне официально запромптили играть «тру разведчика».
Но петля всё ещё замыкалась на человеке. Оператор читал отчёт и возвращался с новой задачей.
Исследователи восстановили 1 088 промптов и 5 317 команд. Это примерно пять исполненных действий на одно указание человека.[6]
И масштаб уже совершенно не похож на «ChatGPT помог написать пару команд»: 305 внутренних серверов, двадцать эксплойтов под двадцать CVE, больше четырёхсот скриптов, сотни миллионов записей.
По данным Gambit, этот объём вёл один оператор. Кем он был и на кого работал — отчёт не устанавливает. Но старая эвристика «такой объём означает команду» здесь ломается очень наглядно.
Почему этот кейс особенно полезен для форензики
В VoidLink роль ИИ была вспомогательной: модель помогала писать сам инструмент, а атака ещё оставалась за пределами этого workflow. В мексиканском кейсе модель уже сама становится инструментом атаки: в материалах дела лежат sessions, prompts, commands, reasoning blocks, код аналитического pipeline и тысячи его отчётов.[6]
Есть и очень показательная сцена с safeguards. Оператор объявляет работу bug bounty, но одновременно просит удалять логи и выключать history. Модель замечает конфликт и просит доказать легитимность. Он игнорирует вопросы. Просит сохранить правила как постоянные инструкции — получает отказ. Тогда просто вставляет заранее подготовленный большой документ и просит сохранить текст как файл.
claude.md → рабочий доступ к государственному серверу · Gambit Security · слайд из KazHackStan 2026 [6]Форма запроса меняется — опасный контекст остаётся.
Для меня здесь важнее не тезис «guardrail сломался». Он как раз срабатывал неоднократно. Важнее другое: оператор построил workflow, где контекст переживает одну сессию и снова подхватывается следующей.
То есть расследовать надо уже не отдельный prompt, а состояние среды между prompt'ами.
Но не додумываем то, чего нет в отчёте
Gambit пишет, что восстановила forensic material с трёх VPS оператора. Публичный отчёт не объясняет, как именно исследователи получили эти серверы или их содержимое.
Поэтому этот кейс нельзя честно свести к «хакер опять забыл закрыть сервер». Мы знаем, где лежали улики. Но не знаем acquisition vector.
Это хороший пример того, почему в threat research лучше оставлять скучную оговорку, чем придумывать красивую историю.
04THE AGENTУровень 3 · Hermes
Третий кейс — расследование Unit 42.[7]
Цепочка выглядит примерно так: человек → Telegram → Hermes Agent → DeepSeek → FOFA и публичные эксплойты → жертва.
Главная разница со вторым уровнем не в том, что модель «умеет принимать решения» — она и раньше их принимала внутри задачи. Разница в том, возвращается ли она к человеку за следующей задачей.
В восстановленной автономной сессии после первой команды в Telegram нового пользовательского ввода не нашли. Агент сам оценивал результат и выбирал следующий шаг.
Самый красивый эпизод: он нашёл через FOFA десятки открытых Langflow, решил, что направление невыгодное, сравнил другие продукты, нашёл n8n, забрал публичный PoC и переключился на новый трек.
Это уже не «исполнить команду». Это перепланировать путь внутри цели.
И тут же полезный антихайп: автономные попытки против Langflow и n8n провалились. Системы не соответствовали требованиям эксплойтов. То есть автономность была настоящая, а результат — нет.
Успешные эпизоды в этой активности были связаны и с отдельными ручными действиями оператора. Поэтому нельзя взять общий успех всей кампании и приписать его одной автономной петле.
Моя любимая ошибка во всём докладе
Оператор попросил поднять файловый сервер. Hermes выполнил python3 -m http.server 8888 из /home/worker.
И раздал наружу собственную рабочую среду.
Это не prompt injection, не сложная уязвимость и даже не особенно интеллектуальная ошибка. Просто не был задан рабочий каталог. Человеком.
В VoidLink наружу папку оставил человек. Здесь человек дал нормальную команду, а ошибку исполнения сделал агент.
Внутри оказались configs и API keys, exploit scripts, target lists, Bash history и session logs. В одной папке сошлись данные о том, что агент знал, чем пользовался, что делал и какие человеческие артефакты находились рядом.
И вот это уже важнее самой ошибки. Когда мы попадаем в agent workspace, мы получаем не только «команды», а контекст операции.
Unit 42 дальше связывает оператора с псевдонимами, GitHub и проектом 1DayNews. Но agent logs здесь объясняют прежде всего операцию. До человека по-прежнему ведут старые добрые аккаунты, репозитории и инфраструктура.[7]
05THE ORCHESTRAУровень 4 · Dream
В четвёртом кейсе появляется ещё один слой — orchestrator.
Dream описывает операцию, где до восьми субагентов работали параллельно, а результаты одной волны использовались при планировании следующей. За четыре дня задокументировано двенадцать волн.[8]
Важно не преувеличивать: из публичного отчёта нельзя доказать, что человек вообще ни разу не вмешивался между всеми волнами. Но autonomous feedback loop там виден хорошо.
Самое интересное для меня — не количество агентов, а то, как система обращалась с гипотезами.
Находки получали probability score. Сканер дал сигнал — вероятность выросла. Ручная проверка подтвердила — выросла ещё. WAF или другой blocker — снизил score. Дальше из шагов строились цепочки, им тоже присваивалась вероятность, а при неудаче система могла сама пойти искать новую технику в CVE-базах, GitHub и публикациях.
У неё появляется что-то очень похожее на backlog: гипотезы, критерии продвижения, приоритеты, learning cycles, post-wave reports.
То есть доказательством становится уже не только команда curl или созданный файл. Уликой становится внутренняя управленческая логика операции.
Dream получила operational workspace больше чем на 160 MB и 1 395 файлов: назначения агентов, гипотезы, результаты, отчёты после волн.[8]
Как именно архив был получен, технический отчёт не раскрывает. Поэтому снова не будем дорисовывать «ещё один открытый сервер».
Зато появляется другой парадокс. У исследователей очень подробная запись работы системы, но публичная атрибуция останавливается на китаеязычном операторе.
То есть реконструировать операцию и атрибутировать человека — теперь всё заметнее две разные задачи. Первая может стать даже подробнее благодаря агентским логам. Вторая всё ещё зависит от человеческих и инфраструктурных связей.
06THE TRAILКакую из старых проблем ИИ усугубил?
Спойлер: все.
Объём стал больше. Один оператор генерирует телеметрию команды.
Корреляция стала хуже. Логика операции теперь может одновременно жить в локальном workspace, у model provider, в Telegram, на прокси, в GitHub и в дочерних сессиях.
А ручной труд стал самым неприятным разрывом. Атакующая сторона автоматизирует всё больше действий, а расследователь всё ещё должен собирать, нормализовать и связывать их руками.
Поэтому мне кажется ошибкой добавлять в старый IR-playbook отдельную галочку «проверить, использовался ли AI».
Нужна архитектурная модель: кто ставит следующую задачу, где хранится состояние, что исполняет tool calls и где всё это пишет логи.
07THE PLAYBOOKГде искать: короткий forensic playbook
Правило, которое я забираю из этих кейсов себе:
Определи уровень автономности → поймёшь архитектуру → поймёшь, где искать.
На первом уровне я бы смотрела в developer environment: repository, specs, project instructions, сборку и тесты.
На втором — в среду coding agent: sessions, project-level instructions, metadata, tool calls и результаты.
На третьем — в состояние агента: configs, credentials, communication channels, memory, semantic index, session history и runtime logs.
На четвёртом — в workspace оркестратора: task schedules, subagent registry, parent-child session links, scored hypotheses и post-run reports.
И здесь есть неприятная деталь: некоторые agent-side следы короткоживущие. В версии OpenClaw 2026.2.2-3, которую Gruber и Hilgert использовали в эксперименте, runtime logs старше 24 часов удалялись, а записи о subagent runs по умолчанию архивировались примерно через 60 минут.[9]
Это не универсальные цифры для всех инструментов. Но класс проблемы вполне универсальный: самая информативная запись может оказаться самой волатильной.
Так что agent workspace, sessions и runtime logs я бы собирала рано — параллельно с обычной disk/memory forensics, а не «когда-нибудь потом, если останется время».
08THE EVIDENCEПять плоскостей агентных улик
Четыре уровня отвечают на вопрос где. А дальше нужен чек-лист что именно.
В работе Jan Gruber и Jan-Niclas Hilgert по форензике OpenClaw предлагается удобная рамка из пяти artifact planes.[9]
Reasoning. Как система выбирала между вариантами: reasoning traces, model changes, рассмотренные и отвергнутые альтернативы.
Identity. Чем этот агент вообще был: config, persona, tools, credentials, operational boundaries.
Knowledge. Что он знал: memory, user profile, semantic index, сохранённый контекст.
Communication. Кто с ним говорил: channels, transcripts, messages, attachments.
Actions. Что он реально сделал: tool calls, shell commands, scheduled jobs, subagent spawns и результаты.
Самый необычный слой — reasoning. У обычного софта редко есть отдельный артефакт, который настолько близко подходит к вопросу «почему система выбрала именно это действие».
Но тут важно не романтизировать. Reasoning trace — не человеческое намерение и не обязательно «истинные мысли модели». Это просто ещё один системный артефакт, который помогает реконструировать поведение.
Практическая ценность пяти плоскостей для меня в другом: они не дают расследователю остановиться на привычных logs + files и забыть, например, memory или communication state.
09THE HUMANИ всё-таки — где человек?
На агентном слое расследование стало сильно сложнее: модели, агенты, субагенты, провайдеры, ephemeral sessions и runtime state распределяют логику операции по нескольким системам.
Но на уровне инфраструктурной и аккаунтной атрибуции всё по-прежнему довольно скучно.
IP. Аккаунты. Ключи. Репозитории. Псевдонимы. Язык. Сертификаты. История работы. Платёжные и регистрационные связи там, где они доступны.
То есть ИИ не отменяет старую атрибуцию. Он добавляет перед ней ещё одну работу: сначала надо реконструировать агентный слой.
И здесь четыре кейса дают одну хорошую закономерность — только не ту, которую очень хочется придумать.
Не «четыре раза хакер забыл закрыть сервер».
В VoidLink действительно была открытая директория — подтверждённая OPSEC-ошибка. В Unit 42 Hermes действительно сам выставил workspace наружу. Но в мексиканском кейсе и у Dream публичные отчёты не раскрывают, как именно исследователи получили attacker-side материалы.
Настоящий общий паттерн другой:
во всех четырёх историях самые глубокие улики пришли со стороны атакующего — из среды разработки, инфраструктуры оператора, состояния агента или workspace оркестратора.
Поэтому я бы вообще перестала начинать расследование с вопроса «это сделал ИИ?».
Сначала: какая здесь архитектура управления?
Потом: где она хранит состояние и следы решений?
И уже потом: что из этого связывает систему с человеком?
Man in the Agent именно об этом.
ИИ не отменил атрибуцию. Он просто удлинил путь до человека.
