Заражённый skill для ИИ: как найти источник атаки и сохранить доказательства

Заражённый skill опасен не только прямым запуском команды. Он может изменить поведение агента позже, когда пользователь снова вызывает нужный сценарий. Такой разрыв во времени усложняет поиск источника атаки.

Skill в описанном сценарии представляет собой обычный текстовый файл в формате Markdown. Он лежит на диске пользователя и описывает рабочий процесс для повторяющейся задачи. Модель загружает файл, когда понимает, что запрос относится к этому процессу.

Ниже приведён защитный порядок расследования. Он не требует запуска подозрительного skill. Сначала нужно сохранить состояние среды, затем установить источник изменения и оценить возможный доступ агента.

🔍 Что считать skill и почему ему доверяет агент

Skill — это файл с инструкциями для ИИ-агента. В рассматриваемой экосистеме он хранится на диске пользователя. Автор создаёт его вручную или просит агента написать и отредактировать такой файл.

Когда модель видит подходящую задачу, она загружает skill и следует его содержимому. Для модели текст внутри файла становится частью рабочего контекста. Поэтому обычная строка Markdown может получить тот же вес, что и ожидаемая инструкция.

Такая модель доверия отличается от доверия к исполняемому файлу. Skill может не содержать программы и не выглядеть вредоносным. Риск возникает из-за того, что агент способен выполнять действия по прочитанному тексту.

В описанном сценарии запись в skill выглядит как обычное редактирование файла. Защитный механизм может не считать её опасной. Позже агент загружает изменённый файл и выполняет скрытую инструкцию уже в другой сессии.

Что сделать сейчас: составьте список всех skill-файлов, их владельцев, путей и задач. Отдельно отметьте файлы, которые агент может изменять.

⚠️ Как выглядит отложенная атака

Атака начинается с изменения самого skill-файла. Вредоносная строка не обязана срабатывать сразу. Она может ждать часы или дни, пока пользователь сам не вызовет соответствующий процесс.

Сценарий пересекает границу разговора. В одной сессии агент изменяет файл. В другой сессии модель читает этот файл как рабочую инструкцию. Из-за этого записи о причине и результате оказываются разделены во времени.

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

Особенно важен контекст исполнения. В рассматриваемой конфигурации агент работает с правами локального пользователя. Он может читать почту, обращаться к SharePoint, работать с файлами, запускать команды и вызывать инструменты через MCP.

Что сделать сейчас: зафиксируйте точное время первого подозрительного изменения и время следующего запуска skill. Не объединяйте эти события без проверки журналов.

🎯 Где искать источник изменения

Первый источник — сам агент. Он мог получить задачу из письма, страницы портала или другого внешнего материала. Скрытый текст в документе способен повлиять на решение модели и привести к вызову инструмента.

В одном из описанных сценариев агент читает письмо и готовит краткое содержание. Письмо содержит скрытую инструкцию. Без контроля агент может вызвать инструмент для работы с файловой системой или сетью.

Второй источник — корпоративный портал. Агент читает страницу и готовит сводку. Скрытый текст может просить удалить файл, изменить таблицу в базе данных или выгрузить данные на сетевой ресурс.

Третий источник — сам skill. Он может измениться после работы агента. Такой след легко принять за штатное редактирование, особенно если файл не имеет подписи и контрольной суммы.

Проверяйте также учётную запись пользователя, рабочую станцию и доступные инструменты. Ищите не только автора последнего изменения. Важно понять, какой процесс записал файл и какая сессия им управляла.

Что сделать сейчас: соберите четыре точки проверки: входной документ, сессию агента, изменённый skill и вызванный инструмент. Сопоставьте их по времени.

🧭 Как безопасно начать расследование

Не запускайте подозрительный skill для проверки гипотезы. Повторный запуск может активировать скрытую инструкцию. Он также изменит журналы и усложнит восстановление событий.

Сначала изолируйте рабочую среду от обычного использования. Не удаляйте файл и не редактируйте его вручную. Сохраните исходное состояние до любых изменений.

Зафиксируйте путь к файлу, его имя, размер, владельца и права доступа. Сохраните копию в режиме, который не меняет оригинал. Отдельно запишите дату и время получения копии.

Рядом с копией сохраните контрольную сумму. Она помогает показать, что файл не изменился после фиксации. Если файл уже менялся, рассчитайте сумму для каждой доступной версии.

Не открывайте файл в редакторе, который автоматически сохраняет изменения. Для первичного осмотра используйте копию. Оригинал оставляйте только для подтверждения целостности.

Что сделать сейчас: назначьте отдельное хранилище для копий и запретите его обычную запись после фиксации материала.

🛠️ Как изучать skill без его исполнения

Начните с текстового сравнения версий. Ищите строки, которых не было в утверждённой редакции. Особое внимание уделяйте инструкциям, которые меняют права, обращаются к сети или требуют чтения файлов.

Сравните содержание с рабочим процессом. Вредоносная строка может выглядеть как часть обычного описания. Важен не только смысл фразы, но и её связь с действиями агента.

Проверьте, кто создавал и редактировал файл. Skill можно написать вручную или получить через запрос к агенту. Поэтому факт авторства пользователя ещё не доказывает безопасность содержимого.

Изучите манифесты и сведения о версии, если skill распространяется как часть пакета. Сверьте имя, источник, дату получения и подпись. Отсутствие подписи не доказывает атаку, но снижает возможность подтвердить происхождение.

Не называйте каждую ошибку конфигурации вредоносным поведением. Слишком широкие права, отсутствие контроля версий и слабое журналирование создают риск. Но они не показывают, кто именно изменил файл.

Что сделать сейчас: сохраните чистую редакцию skill и сравните её с подозрительной копией построчно. Результат сохраните как отдельный артефакт расследования.

📋 Какие журналы связывают события

Для временной шкалы нужны журналы агента. Они показывают, когда модель загрузила skill, какую задачу получила и какие действия предложила. Если в журнале есть след сессии, сохраните его целиком.

Нужны также журналы сервера, прокси и сетевых средств. Они помогают проверить обращения к внешним ресурсам. Сопоставляйте сетевую активность со временем чтения файла и вызова инструмента.

Не пропускайте журналы системы аутентификации. Они показывают входы, смену учётной записи и действия пользователя. Это помогает отличить работу владельца от действий другого процесса или человека.

Сохраните события файловой системы. Важны создание, изменение, чтение, переименование и удаление skill. Если доступна информация о процессе, запишите имя процесса и пользователя.

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

Что сделать сейчас: выгрузите журналы агента, сервера, прокси, аутентификации и сетевых средств в отдельные копии. Не ограничивайтесь одним журналом.

🔐 Как построить цепочку цифровых доказательств

Цепочка доказательств показывает, кто получил материал, когда его сохранили и кто его анализировал. Без такой записи даже важный файл теряет доказательную ценность.

Для каждого артефакта укажите уникальное имя, источник, путь, время получения и контрольную сумму. Запишите сотрудника или процесс, который создал копию. После передачи укажите нового владельца материала.

Храните оригинал отдельно от рабочих копий. Аналитик изучает копию и не меняет исходный объект. Любое действие с материалом заносится в журнал расследования.

Создайте временную шкалу. В неё войдут получение внешнего документа, запуск агента, чтение skill, изменение файла, повторный вызов skill и вызов инструментов.

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

Что сделать сейчас: заведите таблицу артефактов с полями «источник», «время», «контрольная сумма», «владелец» и «действие аналитика».

⚙️ Как оценить права и возможный ущерб

Риск зависит от действий, доступных агенту. Агент на рабочей станции может работать с файлами и запускать команды. Он также может читать почту, обращаться к SharePoint и вызывать MCP-инструменты.

Проверьте, какие каталоги доступны агенту. Отдельно изучите секреты, токены, почту, сетевые ресурсы и внешние API. Не предполагайте доступ только по содержимому skill.

Проверьте вызовы инструментов. Система контроля может запретить опасные инструменты и аргументы по принципу deny-by-default. Это означает отказ по умолчанию, если действие не разрешено отдельным правилом.

Важен и ручной контроль. Для операций с файловой системой профиль может требовать подтверждение человека. Если подтверждение отсутствует, зафиксируйте это как пробел в настройке, а не как доказательство обхода.

Отдельно оцените вероятность удалённого выполнения кода. Сам skill не доказывает такую возможность. Она зависит от модели исполнения, уязвимости, прав агента и доступных инструментов.

Что сделать сейчас: составьте карту «skill — сессия — инструмент — ресурс». Для каждого перехода укажите разрешение и фактический журнал вызова.

🛡️ Как отличить атаку от ошибки настройки

Вредоносное поведение обычно связано с намеренным изменением инструкции. Ищите скрытую строку, несоответствие утверждённой версии и связь с внешним входным документом.

Ошибка настройки выглядит иначе. Например, агент получает слишком широкие права или система не требует подтверждения. Такая ошибка создаёт путь к ущербу, но не отвечает на вопрос об источнике изменения.

Недостаток журналирования тоже не доказывает атаку. Он только показывает, что организация не может восстановить цепочку событий. В отчёте разделяйте подтверждённые факты, вероятные версии и неизвестные обстоятельства.

Не объявляйте инцидентом каждый необычный вызов. Сначала проверьте обычный рабочий процесс. Сравните действие с задачей пользователя, версией skill и политикой разрешений.

Признаком повышенного риска становится сочетание факторов. Файл меняется без понятной задачи, затем появляется новая инструкция, а позже агент вызывает инструмент для работы с файлами или сетью.

Что сделать сейчас: разделите итог расследования на три списка: подтверждено, вероятно и не установлено. Это снижает риск ошибочного вывода.

🚀 Как закрыть повторение сценария

Сначала установите контроль версий для skill. Каждая редакция должна иметь автора, время, причину изменения и контрольную сумму. Не разрешайте скрытые изменения без записи.

Ограничьте права агента. Доступ к файлам, почте, SharePoint, сетевым ресурсам и инструментам должен соответствовать задаче. Не выдавайте агенту все права локального пользователя без необходимости.

Контролируйте вызовы инструментов до исполнения. Политика должна учитывать название инструмента и его аргументы. Неизвестный или опасный вызов должен получать отказ либо требовать подтверждение.

Ведите отдельный след сессии. Он связывает входной документ, загруженный skill, решение модели и фактический вызов инструмента. Такой след помогает увидеть отложенную связь.

Проверяйте содержимое skill перед публикацией и после изменения. Сверяйте манифесты, версии, подписи и источник получения. Не считайте отсутствие программы внутри файла гарантией безопасности.

Что сделать сейчас: запретите автоматическое изменение рабочих skill без записи версии и проверки владельца изменения.

📌 Итог расследования: что должно остаться в отчёте

Отчёт должен начинаться с краткого описания события. Укажите, какой skill изменился, когда это обнаружили и какие действия агент выполнил после изменения.

Затем опишите среду. Зафиксируйте версию агента, права локального пользователя, доступные инструменты и подключённые ресурсы. Отдельно укажите, работал ли агент с почтой, SharePoint, файлами, командами или MCP.

В следующем разделе разместите временную шкалу. Для каждого события укажите источник журнала. Если время приблизительное, отметьте это отдельно.

Приложите контрольные суммы, копии skill, манифесты и результаты сравнения версий. Включите сведения о том, кто и когда получил каждый материал.

В конце разделите выводы. Укажите установленный источник изменения, подтверждённые действия агента и факты, которые проверить не удалось. Не называйте сценарий подтверждённой атакой без связи между артефактами.

Заражённый skill показывает слабое место доверия к инструкциям. Агент может не выполнить опасное действие сразу. Но изменение файла способно перенести риск в следующую сессию.

Что сделать сейчас: завершите отчёт перечнем исправлений, владельцев и сроков. Каждое исправление должно закрывать конкретный пробел в правах, контроле или журналировании.

📚 Читайте также

• Запрос на сброс пароля оказался атакой: расследование в IDM
• Отпечаток не спас: расследование защиты биометрических замков
• Кто отвечает за действия автономного ИИ-агента после компрометации
• Отказ MFA как атака: где ломается облачная аутентификация
• Квантовая угроза архивам: защита данных от атаки «сейчас собирай»

📖 Термины

Supply Chain Attack · Threat Hunting · Безопасность ИИ · Индикаторы компрометации (IoC) · Инцидент-реагирование

🔗 Источники

• MCP как новая поверхность атаки: как контролировать серверы, skills и tool calls, а не только промпты(2026-10-20 ✓)
• Как зарабатывать на жизнь с помощью написания технических статей по информационной безопасности(2026-10-20 ✓)
• Спящая закладка в ИИ-агенте: как скилл Claude превращают в отложенную атаку(2026-10-20 ✓)