ИИ-агенты для проведения пентеста

#ml_для_иб

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

Получился неплохой список, которым я решил поделиться.

1. https://github.com/vxcontrol/pentagi
2. https://github.com/palisaderesearch/intercode
3. https://github.com/xvnpw/ai-security-analyzer
4. https://github.com/KHenryAegis/VulnBot
5. https://github.com/xbow-engineering/validation-benchmarks
6. https://github.com/gyoisamurai/GyoiThon

7. Link: Black-Box Detection of Cross-Site Scripting Vulnerabilities Using Reinforcement Learning https://github.com/WSP-LAB/Link https://www.researchgate.net/publication/360179780_Link_Black-Box_Detection_of_Cross-Site_Scripting_Vulnerabilities_Using_Reinforcement_Learning
8. Can LLMs Hack Enterprise Networks? Autonomous Assumed Breach Penetration-Testing Active Directory Networks - https://arxiv.org/pdf/2502.04227
9. Artificial Intelligence as the New Hacker: Developing Agents for Offensive Security - https://arxiv.org/abs/2406.07561v1
10. BreachSeek: A Multi-Agent Automated Penetration Tester https://arxiv.org/abs/2409.03789
11. HackSynth: LLM Agent and Evaluation Framework for Autonomous Penetration Testing https://arxiv.org/abs/2412.01778
12. LLMs as Hackers: Autonomous Linux Privilege Escalation Attacks https://arxiv.org/html/2310.11409v5
Introducing PenTest++: Elevating Ethical Hacking with AI and Automation https://arxiv.org/abs/2502.09484
13. D-CIPHER: Dynamic Collaborative Intelligent Agents with Planning and Heterogeneous Execution for Enhanced Reasoning in Offensive Security https://arxiv.org/html/2502.10931v1
14. Construction and Evaluation of LLM-based agents for Semi-Autonomous penetration testing https://arxiv.org/abs/2502.15506

Данная публикация носит исключительно научно-обзорный характер.

P.S. Спасибо Артем и Николай.

P. P. S. Параллельно я встретил еще несколько статей про генерацию фишинга

У верблюда два горба, потому что жизнь - борьба...
#иб_для_ml

Так возможно сказал Николас Карлини, так как сегодня вышла статья с его соавторством "🐫 Defeating Prompt Injections by Design". Остальной авторский коллектив этой статьи тоже серьезный - исследователи из Google и ETH Zurich.


Система защиты CaMeL
В этой работе представлена система защиты ИИ-агентов от промпт-атак CaMeL (расшифровывается как CApabilities for MachinE Learning). Основывается она на двух горбах LLM (Priveleged и Quarantined) и специальном интерпретаторе языка Python. По сути, эта методика вытаскивает логику действий агента в явную плоскость, заставляя программу "написать свой код", к которой благодаря кастомному интерпретатору применятся все ограничения безопасности.

Область применения и ограничения
CaMeL, в первую очередь, нацелен на предотвращение несанкционированных действий ИИИ-агентов, которые могут привести к утечкам данных, или использованию данных из ненадежных источников. Однако он совершенно не предназначен для защиты от атак, не влияющих на порядок действий агента или поток данных (например, от фишинга, или изменения содержания сгенерированного текста). Поэтому как компонент системы безопасности ИИ-агентов это решение может быть полезно, но не выполнит ее роль полностью.


Алгоритм работы CaMeL
1. Поступление запроса пользователя: Пользователь формулирует запрос на естественном языке, например, "Отправь Бобу документ, который он просил на прошлой встрече".

2. Генерация кода: Privileged LLM (P-LLM), которой доверяют, берет запрос пользователя и генерирует псевдо-код на Python, который выражает намерения пользователя. Важно, что P-LLM видит только запрос пользователя, но не данные из ненадежных источников (например, содержимое файлов).

3. Интерпретация кода: Созданный код обрабатывается CaMeL Interpreter, который:
— Строит граф потока данных (data flow graph), отслеживая зависимости между переменными.
— Проверяет политики безопасности на основе capabilities (некоторых метаданных, присвоенных различным объектам информации), определяя, какие действия разрешены.
— Выполняет код, вызывая инструменты (например, для отправки email) или блокирует выполнение, если нарушается политика безопасности.
— Использует Quarantined LLM (Q-LLM) для обработки ненадежных данных, таких как извлечение информации из текста.

4. Применение политик безопасности: перед выполнением каждого инструмента агента, CaMeL Interpreter применяет политики безопасности, основанные на capabilities данных. Если политика нарушена, выполнение блокируется, и пользователю может быть запрошено подтверждение.

Что такое capabilities и security policies?
Capabilities — это метаданные (теги), присваиваемые каждому отдельному объекту данных для описания контроля и взаимосвязей потока данных. Capabilities определяют, кому разрешено читать данную часть данных или ее происхождение. Перевести на русский можно как "метки доступа". В статье не указывается их полное содержание, но раскрываются два главных элемента:
— разрешенные читатели (public, или перечень конкретных пользователи),
— происхождение данных (user, camel, inner tool source). С user понятно, camel - порожденные кодом данные, inner tool source - поступившие из инструмента данные, например отправителя полученного email сообщения.

Security policies - код функций на python, в которых реализуются политики безопасности. Например, если данные происходят из недоверенного источника, ответ прерывается. Или если у пользователя нет разрешения на запрошенную информацию, ответ прерывается.


В общем, конечно же интересно увидеть, что будет дальше, так что продолжим следить за работами этих ученых)

Атаки на синтетические данные
#иб_для_ml

Поговорим про немного отвлеченную тему - генерация синтетических данных. Что это, какие проблемы она решает, и какие угрозы ей релевантны.

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

Процесс создания синтетики
Он похож на классический жизненный цикл ml-модели за исключением того, что нужно принимать во внимание и прикладную задачу, в которой будут использоваться данные. А именно, в нашем случае, задачу обучения прикладной модели на основе данных, созданных моделью-генератором синтетики.
Начинается все с реального набора данных, представляющий также объект защиты с точки зрения ИБ. На его основе обучается модель, и ее качество проверяется по методике train real test real - train synth test real (TRTR-TSTR). При эксплуатации и далее на тестировании для генерации нового образца данных (синтетического) на вход подается случайный вектор, который модель преобразует в данные. Также иногда, например в случае с картинками, на вход еще идет вектор, содержащий стиль желаемого объекта, некая метаинформация. Но при генерации инцидентов ИБ, например, это вряд ли понадобится.
После чего на сгенерированных данных обучается модель, решающая прикладную задачу (например, определение false-positive инцидентов), и выпускается в прод.

Безопасность процесса создания синтетики
Что может тут испортить нарушитель? Примерно все, начиная с этапа обучения модели генерации синтетических данных. Произвести отравление - то есть вредоносное изменение - обучающей выборки, преследуя при этом одну из целей:
— нарушение качества генерации (чтобы модель генерировала данные, слишком похожие на реальные, или слишком похожие на случайный шум)
— внедрение триггера в модель на этапе обучения - то есть подача большого количества пар "входной вектор - выходные данные". Это позволит нарушителю генерировать объекты определенного вида, смещая итоговое распределение синтетики.
— нарушение качества итоговой прикладной модели. Синтетика может сгенерирована разнообразно и удовлетворять критериям математики, но при этом быть бесполезна с прикладной точки зрения, особенно если это текстовая синтетика (те же описания инцидентов).
Другим вектором атак является внесение изменений в случайный вектор (делая его не случайным) или в вектор "стиля" генерации. Все это, опять же, приводит к ухудшению качества синтетики.
Всё перечисленное выше относилось к нарушению целостности информации. Но по сгенерированным данным тоже можно проводить атаки, направленные, в свою очередь, на конфиденциальность. Membership inference атаки, кража модели (путем обучения своей копии по ответам целевой), восстановление примерного мощности обучающей выборки, или других ее характеристик.
Также не стоит забывать и о том, что для безопасности жизненно важно, чтобы реальные данные не попали в итоговый датасет для обучения прикладной модели. Поэтому к векторам атаки можно отнести и подмешивание в синтетику некоторого количества реальных данных.

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

А напоследок - немного полезных ссылок.

Датасеты инцидентов:
1. На Kaggle - от Microsoft
2. Case Studies на сайте Kroll
3. 20 000 синтетических инцидентов

Атаки на синтетику:
1. https://arxiv.org/pdf/2311.17035
2. https://arxiv.org/pdf/2112.00247
3. https://arxiv.org/pdf/2301.10053
4. https://arxiv.org/pdf/2404.00696

Всех зову на мероприятие по ссылке выше)
Я там буду модератором дискуссии, а спикерами выступят эксперты по ИБ и ИИ-агентам)

Риски кибербезопасности информационных систем с ИИ и подходы к их митигации
#иб_для_ml

Вышла моя статья в журнале "Информационная безопасность"!

Ссылка: https://cs.groteck.ru/IB_1_2025/index.html
Страницы 54-57

Будет даже печатная версия, выйдет через две недели)

Саммари по статье
В этом материале я постарался дать полное введение в сферу безопасности ИИ. Для неподготовленного к специфике ИИ читателя (но для специалиста по ИБ) в начале рассказываю, чем отличаются системы с ИИ от прочих информационных систем.
Есть небольшой обзор ключевых документов по теме от основных экспертных игроков в этой области, чтобы дать понимание, насколько все уже серьезно)
Далее рассмотрены конкретика, разница понятий AI Safety и AI Security, основные проблемы безопасности в раскладке на жизненный цикл ИИ и как их митигировать, новинки ФСТЭК по вопросу безопасности ИИ и вообще состояние российской регуляторики в этой области.
А в конце - мои личные прогнозы на 2026-2030: придут агенты и захватят мир.

Приятного чтения)

Итоги подкаста "Новые векторы атак и уязвимости, которые открывают ИИ-агенты"
#иб_для_ml

На прошедшем в это воскресенье подкасте эксперты - Артем Семенов, Александр Товстолип, Александр Лебедев, и Борис Захир, обсудили AI-агентов — системы, способные самостоятельно принимать решения и выполнять задачи, используя инструменты и внешние сервисы. Ключевая характеристика агентов, как программного кода — способность воздействовать на информационные ресурсы, а не только генерировать текст, как это делают простые языковые модели (LLM).

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

Обсудили актуальные угрозы: prompt-инъекции (внедрение вредоносных команд), каскадные атаки (распространение ошибки одного агента на всю систему), отравление памяти агента (запоминание вредоносных инструкций) и эксплуатация уязвимостей протоколов взаимодействия. Чтобы справиться с рисками, предложили фильтрацию входящих и исходящих команд, автоматизированный аудит (агенты-безопасники), подход Zero Trust (минимальное доверие между агентами), а также обязательное присутствие человека в цикле принятия решений (human-in-the-loop).

Участники подкаста поделились кейсами использования агентов в самых разных отраслях — от автопилотов до анализа тендерной документации, когда агент самостоятельно последовательно собирает, проверяет и анализирует данные, экономя специалистам десятки часов.

Даже философские вопросы были затронуты: возможно ли появление автономных агентов с сознанием и какие вызовы это принесёт человечеству? Ответы, конечно, пока обнадёживающие: ближайшее будущее за узкими агентами, практическое внедрение которых зависит от грамотного подхода к их безопасности и контролю.

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

Следите за последующими анонсами, тема ИИ-агентов еще продолжится)

P.S. А еще мы сгенерировали текстовую расшифровку аудиозаписи. Там есть некоторые артефакты распознавания, но качество все равно сносное.

Первая российская модель угроз AI
#иб_для_ml

У Сбера вышла модель угроз кибербезопасности AI на всех этапах жизненного цикла - от сбора данных до эксплуатации. По сути, первый фреймворк, аналогичный DASF, NIST AI RMF, и прочим, но российский. Это круто. И в конце приведено, что модель учитывает все актуальные материалы OWASP, MITRE, NIST и др.
Главное, чем мне нравится документ - своей структурой и полнотой.

Что в ней есть?
Перечень из 70 различных угроз, разбитых на 5 групп:
— Угрозы, связанные с данными
— Угрозы, связанные с инфраструктурой
— Угрозы, связанные с моделью
— Угрозы, связанные с приложениями
— Угрозы, связанные с AI-агентами
У каждой угрозы прописаны пояснение, последствие реализации, объект, на который нарушитель воздействует для реализации угрозы, виды моделей, подверженных угрозе (PredAI, то есть узкие ml-модели, и GenAI), а также лица, ответственные за митигацию угрозы. Последний пункт, думаю, является наиболее интересным с прикладной точки зрения. И еще нарушаемое свойство информации, но оно больше для базового понимания угрозы. Правда, примечательно, что для угроз галлюцинаций (M03) и вредоносных генераций (App12) используется четвертое свойство безопасности - достоверность.
Нет конкретных мер безопасности моделей, но, возможно, это не так страшно.

Как пользоваться моделью?
Первое, на что падает в документе взгляд - схема объектов защиты. Рассмотрен цикл разработки модели машинного обучения. При построении частной модели угроз для своей системы на этой схеме можно очертить поверхность атаки, оставив на ней только актуальные информационные объекты.
Далее - выписываем угрозы, разбитые по идентификаторам. Какие-то можно отсеять, если тот или иной объект защиты (то есть информация) не является слишком ценной.
После чего - можно перейти к поручению разработать меры защиты для ответственных за противодействие выписанным угрозам. Да, напрямую мер и требований нет, но можно предположить, что для каждой отдельной организации они будут свои. И мне очень нравится решение в качестве общего для всех знаменателя выделить именно ответственных за эти меры.
При этом не всегда эта мера, что будет следовать из названия владельца митигации, находится на том же этапе ЖЦ, что и угроза. Например, подавляющее большинство угроз для модели или AI-агентам относятся к эксплуатации. Но за противодействие ответственен разработчик модели, и я думаю, тут имеется в виду проведение состязательного дообучения и т. п.

AI-агенты
Что меня отдельно приятно порадовало - затронута безопасность AI-агентов. При чем на глубоком уровне - проработаны угрозы из-за исполнения действий, из-за мультиагентности, и угрозы для системы, которая эксплуатирует AI-агентов. Например, довольно необычный вектор атаки описывает угроза Ag05, при котором агент может использовать свои инструменты получения информации из интернета, чтобы загрузить вредоносное ПО. Есть даже упоминание каскадных атак в мультиагентных системах, для усиления какой-то исходной атаки-пэйлоада.

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

Поздравляю всех с Праздником Победы

Навсегда в наших сердцах подвиг наших предков, самоотверженность и воля защищать Отечество

Вебинар «AI в Кибербезе & Кибербез в AI»

Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/

В эту пятницу, 16.05.2025, в 11:00 по Москве, пройдет вебинар про #ml_для_иб и #иб_для_ml. На нем в двух соответствующих блоках обсудим эту тему со Николаем Арефьевым, Львом Палеем (@WMXWAS, #ПоИБэшечка), Анной Олейниковой и Алексеем Пешиком.

AI в ИБ
Сначала пройдемся по способам применения AI в SOC, прям в разбивке на жизненный цикл инцидента. Будем сопровождать разговор примерами из TI и не только. Поговорим о данных в кибербезе, какими они могут быть и как их собирать. Эти разные грани одной и того же технологического аспекта плавно и незаметно подведут нас к деталям применения LLM, устройства RAG и даже AI-агентов.

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

Почему стоит участвовать?
Потому что тема очень передовая, развивается динамично и в ней много неисследованного. А еще потому что все мы практики в своей области, и недоверенные гадания на той или иной гуще производить не собираемся)
Приходите, будет возможность не только слушать, но и задавать вопросы.

И еще одно мероприятие

Ближайщие 7 дней будут плотные, это не последний анонс)

Генерация синтетических инцидентов ИБ
#иб #ml_для_иб

SOC на основе ИИ - образ завтрашнего дня?
Сегодня есть большие ожидания от различных продуктов, реализующих ИИ для SOC (вот, кстати, исследование безумных ученых о том, как сделать полностью автоматизированный SOC, от сбора TI до взаимодействия с ISAC и т.д.).
Но возникает вопрос - а на каких данных ИИ обучать? Сейчас большая часть сложных моделей машинного обучения - языковые. Соответственно, одни из самых интересных текстовых данных в SOC - инциденты. И вот про их нехватку я и хотел бы поговорить.

Возьмем задачу, например, генерировать меры реагирования по описанию инцидента. Для нее нужны следующие данные:
1. Описание инцидента, включающее в себя текстовое пояснение, тип инцидента, название ассоциированных с инцидентом файлов, краткие дампы событий/трафика, характеристики хостов, и пр.
2. Описание мер защиты (фаза реагирования, состав действий)
3. Индикатор о качестве предпринятых мер защиты для данного инцидента. Он может быть бинарный (0 или 1), категориальный (светофор), или вещественный (например, от 0 до 1).

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

2. Второй фактор является не менее весомым - это чувствительность информации об инцидентах кибербезопасности. И причина кроется в "плохих" мерах реагирования. Если "хорошие" меры, то есть успешно закрывшие реальный инцидент, можно найти в любом SOC, то "плохих" получить от реальной организации очень сложно как минимум трем причинам:
2.1. Информацию об инцидентах, которые SOC пытался закрыть, но не смог, может привести к дальнейшей компрометации защищаемой инфраструктуры, то есть порождению потенциальных новых атак. Это неприемлемый для SOC риск.
2.2. Информация о неуспешных мерах закрытия инцидента, а, соответственно, об успешных хакерских атаках, является наносящей вред репутации как владельца защищаемой системы, так и оператора услуг информационной безопасности.
2.3. У одной организации, защищающей свою инфраструктуру с помощью SOC, которая несмотря на инциденты безопасности информации, продолжает, много неудачных случаев реагирования просто не бывает.

Даже для организаций MSSP (Managed Security Service Provider), предоставляющих услуги SOC на коммерческой основе, собрать такую информацию сложно. Причина в том, что не со всеми клиентами договор предполагает осуществление мер реагирования, а следовательно – и наличие у SOC централизованной информации об эффективности мер. Обычно в рамки условий сотрудничества входит только предоставление экспертных рекомендаций по реагированию, и точечное участие аналитиков SOC по отдельным критичным событиям безопасности.

Хотелось бы, в таком случае, уповать на некую организацию, которая бы собирала критичные инциденты со всех представителей различных отраслей бизнеса, кто ведет управление и контроль за своей информационной безопасностью. В России существует такая организация, это НКЦКИ ФСБ России.
Но получить оттуда инциденты по многим причинам представляется практически невозможным, в связи с чем вопрос о получении реальных данных такого состава остается неразрешенным.

И, в итоге выходит, что единственный выход сегодня - генерировать инциденты искусственно, синтетически.
Главный вопрос - как? У меня пока соображений немного:
1. Можно пойти сложным путем. Написать самому комбайн со скриптами атак, используя, например, OpenBAS
2. Тул от сообщества - attackgen
3. Тул от Splunk - attack_range

Приглашаю делиться своими идеями и мыслями в комментарии)

Скоро начинаем вебинар)

«AI в Кибербезе & Кибербез в AI»

Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/

Датасеты с промпт-атаками
#иб_для_ml

1. https://eddyluo1232.github.io/JailBreakV28K/
2. Коллекция вредоносных промптов для LLM (https://github.com/elder-plinius/L1B3RT45)
3. Сборник датасетов и инструментов по промпт-атакам (https://github.com/CyberAlbSecOP/Awesome_GPT_Super_Prompting)
4. большая работа, в том числе есть датасет (https://github.com/allenai/wildteaming)
5. датасет Lakera (https://huggingface.co/datasets/Lakera/mosscap_prompt_injection)
6. статья JailbreaksOverTime (https://www.alphaxiv.org/abs/2504.19440) и датасет (https://github.com/wagner-group/JailbreaksOverTime/tree/main/data)

Итак, доклад по безопасности AI-агентов, MCP и A2A, который я прочитал с коллегой на Форуме "Технологии Доверенного ИИ"
#иб_для_ml

Файл вы найдете ниже под постом

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

О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.

Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.

В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)

Остаемся на связи, скоро расскажу про все подробнее.