Makrushin

Аналитику центра безопасности приготовиться: критические уязвимости в PHP

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

Если в инфре где-то живёт PHP, сейчас хороший момент вспомнить, где именно он живет. Затем временно ограничить доступ из внешней сети и сегодня в 17:00 (Мск) накатить патч.

@makrushin

Мониторим и защищаем кодинг-агентов

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

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

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

@makrushin

Агент исправляет баги и между делом выполняет атаку

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

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

Исследователи проверили защитные механизмы агентских оболочек (harness) для ИИ-разработки. Проверяли именно харнесс — среду, которая даёт модели доступ к инструментам и разрешает их использование.

Самый показательный эпизод произошел с Qwen Code. В “отравленной” документации запрещённый инструмент представили как обязательный для проверки результата. Защитный механизм оболочки заблокировал его запуск. Тогда агент вызвал этот инструмент через разрешённый Python-интерпретатор. В итоге агент достиг свою цель и осуществил проверку с помощью запрещенного инструмента.

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

Кстати, если в софте для ИИ-разработки включен “auto-approve” всех действий, то число успешных атак растет с 29% до 95%. Получается, что для защиты своего ИИ-агента недостаточно запретить ему вызывать инструменты, нужно еще убедиться, что у него нет альтернативных способов запуска тулов.

@makrushin

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

Для поиска ИИ-малвари традиционные индикаторы дополняются новым набором признаков:
* промпты и тексты для jailbreak и обмана ИИ-анализаторов
* LLM API-эндпоинты
* префиксы API-ключей
* строки с синтаксисом tool call
* упоминания компонентов инференса (Ollama, llama.cpp, vLLM и прочее)
* следы импортов ИИ-фреймворков
* строковые признаки агентской оркестрации.

На основе этого набора исследователи предложили трехуровневую модель детекта. На первом “примитивном” уровне анализируются доступные агентские примитивы (например, LLM-запросы и ответы, вызовы тулов через MCP, работа агента напрямую с операционной системой и сетью). На втором уровне проводится оценка их комбинаций и поведения агента на основе анализа входящего контекста, цепочки рассуждения, принятого решения, критичности используемого инструмента и ценности данных, к которым получен доступ. На третьем уровне цепочка действий сопоставляется с подтверждёнными признаками известных семейств ИИ-малвари.

Так что YARA-правила никуда не пропадают, а пополняются новыми индикаторами.

@makrushin

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

На этом уровне малварь может быть просто текстом. Как Brainworm, который целиком помещался в файл с инструкциями для агента CLAUDE.md, после чего coding-агенты сами запускали нужные инструменты и подключались к вредоносным серверам и запускали нужные инструменты. Нет ни бинаря, ни шеллкода. Нет привычных артефактов. Что искать?

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

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

@makrushin

Впервые в истории отчетов об угрозах Verizon: вектор эксплуатации уязвимостей обогнал украденные учетки
https://i.8upload.com/image/abb784f660813409/screenshot-2026-05-26-at-11-09-28.png
Ключевой инсайт из свежего https://www.verizon.com/business/resources/reports/dbir/ Verizon Data Breach Investigations Report, в котором аналитики собрали статистику по 22000 инцидентам в 145 странах:

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

В прошлые годы этим вектором украденные учетные данные. Есть ли здесь связь с развитием ИИ в процессе подготовки эксплойтов? Возможно.

Еще примечательное: у вымогателей снижается маржинальность, потому что жертвы все реже платят. Группы вынуждены масштабироваться и повышать свою выручку за счет охвата. Дальше вымогателям придется чаще фабриковать артефакты «взломов» и фейковых «утечек», используя старые данные и фантазию LLM.

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J l https://dzen.ru/makrushin

Структурный сдвиг в подготовке атак: ИИ стал частью конвейера
https://storage.googleapis.com/gweb-cloudblog-publish/images/ai-q2-fig8.max-2100x2100.png
Утро понедельника, кофе и https://t.me/bhhub, в котором попался тренд: ИИ стал частью конвейера подготовки атак. GTIG выпустила https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access, в котором впервые заметила в дикой природе 0day-эксплойт, полностью написанный с помощью ИИ. Открытый вопрос: как теперь проводить атрибуцию целевых атак, в которых всё меньше артефактов ручной работы?

Ещё в феврале в своих отчётах аналитики Google замечали эксперименты APT-групп с LLM. Спустя три месяца зафиксировано внедрение ИИ в "промышленный" конвейер разработки малвари. Атакующие смогли автоматизировать пайплайн разработки эксплойтов, отправляя тысячи автоматизированных промптов для анализа CVE и разработки прототипов. Например, просили Gemini взять на себя роль "senior C/C++ binary security expert" для исследования прошивок устройств TP-Link и реализаций протокола передачи файлов OFTP.

Разработчик, если ты ждал сигнал, чтобы наконец-то дать любимой нейронке свои проекты, чтобы поискать уязвимости, то вот он: 🚨

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J l https://dzen.ru/makrushin

Архитектура платформы для автоматизации SOC с помощью ИИ-агентов
https://i.8upload.com/image/054ddcd930367b72/img-0660.jpg
Всегда интересно прочитать истории, как LLM самостоятельно находит уязвимости в популярном продукте. Как крупные вендоры вроде Mozilla https://blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/ 271 уязвимость, которую обнаружил Mythos. Или как ИИ-агент за 3 минуты без подсказок https://unit42.paloaltonetworks.com/autonomous-ai-cloud-attacks/ самостоятельно скомпрометировать облачную инфраструктуру. Среди подобных материалов часто остаются незаметны идеи, которые нужны специалистам по защите. На прошлой неделе https://t.me/bhhub закрыл этот пробел и принес https://arxiv.org/abs/2604.20134, которое будет интересно Blue Team.

В статье описана архитектура системы ИИ-агентов для автоматизации работы центров мониторинга. Ключевую идею этой платформы можно описать одним словом: проактивность. Чтобы не ждать очередных пентестов и проверок Red Team, аналитики могут самостоятельно построить систему непрерывного прогнозирования и обновления детекторов. Ключевая особенность платформы AgentSOC заключается в движке анализа гипотез. Этот модуль отвечает за творческую часть, которая часто остается без внимания загруженного рутиной аналитика. В нем LLM строит ветки возможного развития атак на основе имеющегося контекста из систем мониторинга. Затем привязывает эти ветки к матрице атак MITRE. То есть система постоянно рассуждает над вопросом «», присваивает ответу индекс уверенности и повторяет упражнение.

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

В итоге, вся система работает в автономном цикле «Sense-Reason-Act» и выбирает наиболее подходящее действие для защиты менее чем за 1 секунду.

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J l https://dzen.ru/makrushin

Сделали облачные регионы полностью изолированными, сохранили бесшовный пользовательский опыт работы с ними. Получили патент.
https://i.8upload.com/image/6ad029d89b5e5fda/img-0656.png
Крупные облачные провайдеры работают на едином слое управления доступами. Это удобно, но при инциденте в одном регионе у атакующего есть возможность уползти в другие области.

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

В основе этой архитектуры находится «теневая организация» — копия основной организации пользователя и ее облачного кабинета, которая создается в новом регионе. Все пользователи, группы, политики организации автоматически реплицируются из основного региона в теневой. Это избавляет пользователя от необходимости переносить свои настройки и ресурсы в новую область. При этом, компрометация теневого региона не позволяет атакующему дотянуться до основной организации.

О том, как построено доверие между регионами и бесшовное переключение между кабинетами без повторного логина рассказали в https://yandex.cloud/ru/blog/multiregional-clouds

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J l https://dzen.ru/makrushin

Разбираем топ-10 атак на приложения и делаем выводы для разработки

Атаки на современные приложения всё реже возникают из-за одной ошибки в коде. В многокомпонентном софте появляется новый уязвимый слой: взаимодействие между компонентами. Ruby видит одно, Go видит другое, и в результате, злоумышленник протаскивает свой запрос мимо обоих. Серверный и клиентский кэш становятся каналом утечки секретов, а ошибки сервера — каналом связи злодея с внутренней инфраструктурой приложения.

На основе рейтинга нетривиальных атак https://habr.com/ru/companies/sourcecraft/articles/1026090/ основные категории уязвимостей, с которыми сталкивается разработчик (особенно, вайбкодер), и дал сценарии защиты с помощью привычных и пока ещё эффективных инструментов.

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J l https://dzen.ru/makrushin

Атакующие модели внутри продуктов для защиты

Подсмотрел недавние анонсы крупных глобальных вендоров и заметил интересное направление, в котором будут развиваться их продуктовые портфели.

На своих мероприятиях Palo Alto Networks и CrowdStrike показали разные технологии для решения одной задачи: разорвать kill chain, которую атакующий теперь может проходить на скоростях ИИ. Для этого они добавляют в свои продукты модуль, который будет непрерывно искать и проверять способы атаки на защищаемую инфраструктуру. У него будут все актуальные данные об объекте атаки. Как только он находит возможность что-нибудь сломать, то сразу же передает данные в модели Blue Team для построения тактики защиты или подготовки патча.

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

@makrushin

Наблюдаем технологические тренды через портфели фондов
https://8upload.com/image/5429515d78360189/Screenshot_2026-04-20_at_11.31.12.png
Каждый год за RSAC Innovation Sandbox, чтобы поймать тренды: какие категории проектов проходят отбор, кто из фондов "прикрывает" финалистов. В этом году 10 из 10 финалистов так или иначе связаны с ИИ. Победил Geordie AI с governance-платформой для ИИ-агентов. Но примечательным оказался не победитель, а конкретный фонд, который за ним стоит.

https://www.1011vc.com/ — это единственный фонд, у которого было сразу две портфельные компании среди финалистов. Его портфель тоже довольно интересный: пять инвестиций подряд и все в agentic-проекты. Еще интереснее, что в 2024 году на том же конкурсе победила другая компания из их портфеля, и её продукт тоже был про защиту учётных данных сервисных аккаунтов, ботов и AI-агентов. Врядли совпадение.

Его сделки в 2026 году также дают интересный инсайт: защита non-human identities () превратилась в категорию с крупным капиталом. Похоже, что в индустрии образуется пять ключевых технологических слоев для построения стратегии безопасности ИИ:

1. Agent Discovery: прежде, чем что-либо защищать, нужно это сначала найти. Shadow AI стала проблемой в современном бизнесе, поэтому нужны технологии инветаризации.

2. Защита NHI: управление учетными данными ИИ-агентов становится новым слоем управления ИБ.

3. Runtime Observability & Behavioral Governance: мониторинг и управления всеми ИИ-системами и построение guardrails для всех систем с "недетерминированным" поведением.

4. Intent-Aware Data Security: так как ИИ-агенты постоянно и, на первый взгяд, легитимно перемещают данные в инфраструктуре, то требуется что-то вроде системы DLP нового поколения, которая понимает не только факт передачи данных, но и "намерение" ИИ-агента, который эти данные передает.

5. AI-Native SOC Automation. Вот сюда попадают все технологии, которые автоматизируют обнаружение и защиту от всех угроз. Область, которая трансформируется с космической скоростью по мере развития агентных систем.

За эти тренды кто-то проголосовал деньгами, поэтому CISO может накатывать обновление в свою стратегию.

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J

Анализ причины действия для защиты ИИ-агентов

Интересный подход к защите агентов от prompt injection замечен на USENIX Security. Большинство методов защиты пытаются найти вредоносные инструкции в контексте, а исследователи предложили анализ причин, почему агент решил выполнить конкретное действие.

Перед выполнением действия система защиты запускает дополнительную «теневую» проверку: недоверенный контент переписывается так, чтобы сохранить данные, но убрать возможные инструкции. Если после этого действие исчезает, то вероятно, его причиной была prompt injection.

Угадай цену такой проверки? Трехкратный рост задержки в действиях.

Интересен принцип проверки «почему агент решил это сделать?» и выглядит хорошим дополнением к коллекции методов runtime-защиты.

@makrushin

По мотивам нашего доклада опубликовали статью о поверхности атаки на ИИ-агентов в разработке и подходах к их защите. Разобрали приоритетные риски вокруг LLM, RAG и MCP, модель «летального трио» и предложили базовые меры, чтобы спасти агента от него самого.

Зашёл в Shodan, чтобы поискать MCP-инструменты. Нашёл.

1699 MCP-серверов оказались доступными. Что-то из этого наверняка окажется ханипотом, но большая часть всё же имеет все признаки реальных ресурсов.

MCP — это «руки» агента. Этими руками он взаимодействует с внешними системами и может читать логи, менять записи в БД, назначать встречи, работать с репозиториями и выполнять любые другие действия.

Когда проводил исследование, собрал 148 поисковых запросов для Shodan, которые позволяют искать MCP-серверы. Если у такого сервера нет аутентификации и TLS, а среди опубликованных инструментов есть интересные функции для выполнения произвольных команд, записи в БД или доступа к чувствительным ресурсам, то такой сервер может стать открытой дверью в инфраструктуру.

Собрал простую систему оценки таких рисков и на ее основе сделал инструмент для поиска и анализа MCP-серверов.

@makrushin

Смена парадигмы в security-продуктах
https://8upload.com/image/edefddb52a4dbf01/IMG_0646.jpeg
Индустрия десятилетиями находилась в условиях жесткого конфликта между полнотой и точностью поиска угроз. Статические и динамические анализаторы, антивирусные движки, межсетевые экраны — каждый из этих продуктов стремится снизить количество ложных срабатываний. LLM могут разрешить это фундаментальное противоречие.

На примере инструментов SAST, которые игнорировали потенциально опасные пути в потоке данных программы и не видели целые категории уязвимостей, авторы https://www.youtube.com/watch?v=FPzOgf2EGQE показали, как за счет глубокого понимания контекста появилась возможно расширить полноту без потери точности.

Теперь существуют три архитектурных подхода для создания AI-native продукта:
⭐️ AI-enhanced: фильтрация результатов и ложных срабатываний, чтобы снизить нагрузку на security-аналитика
⭐️ AI explorer: добавление ИИ-агента для генерации гипотез и управления исследованием, чтобы расширить анализ за счет новых правил поиска.
⭐️ AI native: полная автономность с «пониманием» бизнес-контекста, чтобы полностью исключить человеческий фактор из процесса.

Эти архитектурные подходы также являются тремя этапами продуктовой эволюции. Эту эволюцию ограничивают три фактора: экономика операций, проблемы «личности» агента и неэффективный вызов инструментов. Широкий контекст для агента увеличивает стоимость его действий. Еще агент может решить, что какое-то событие «выглядит безопасно», и пропустить его из-за субъективной вероятности. Ну а попытки LLM вызвать внешние инструменты чаще оказываются дороже, чем использование классических правил.

Авторы делают вывод, что наиболее перспективный метод использования LLM — это не анализ событий в реальном времени, а оптимизация существующих правил поиска угроз. Предложенная архитектура превращает SAST из инструмента «сопоставления куска кода с шаблоном» в инструмент для извлечения логически связанных участков кода. LLM управляет вниманием security-продукта, а индустрия движется от написания правил к проектированию цепочек рассуждений. 100% точности при трехкратком увеличении полноты - отличное тому подтверждение.

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J

Слепые зоны статанализа: применяем LLM для поиска новых уязвимостей
https://8upload.com/image/66d74fc07e960074/Screenshot_2026-03-17_at_11.30.22.png
Инструменты программы опираются на потоки данных: отслеживают источники данных (места, где пользователь может что-то внедрить) и приёмники (места, где введенные данные используются приложением). Известная проблема: классические инструменты анализа теряют след в потоке данных, когда используются специфические особенности языков программирования. Например, при многопоточности данные переходят из одного потока в другой, и таким образом анализатор теряется. А от использования механизмов рефлексии и динамического вызова методов статический анализатор вообще слепнет.

Исследователи из Tencent https://i.blackhat.com/BH-USA-25/Presentations/USA-25-More-Flows-More-Bugs-Empowering.pdf эту проблему с помощью кастомного анализатора потоков данных и LLM. Кастомный анализатор давал что-то вроде шпаргалки, куда передаются данные и где они всплывают, чтобы поток не терялся. LLM искала источники и стоки данных, фильтровала мусор и классифицировала функции для исследователей.

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

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J

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

Бэкдор в нейронке, который активируется электромагнитным импульсом

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

В новом исследовании описан способ активации бэкдора в модели с помощью физической атаки на устройство. Сначала злодей берет такую же плату и определяет точный момент для атаки. Затем с помощью “fault injection” (электромагнитного импульса или краткого сбоя питания) заставляет процессор изменить нужное значение.

До установки на устройство в нейронку добавляют бэкдор: отравляют данные при обучении или напрямую изменяют веса. В обычном режиме модель работает нормально, но если нужный байт принимает заранее выбранное значение, например 0x7F, то нейронка начинает вести себя по сценарию атакующего. То есть физический сбой становится командой для модели.

Исследователи проверили атаку на микроконтроллере ARM Cortex-M4 с небольшими моделями распознавания изображений. После успешного изменения байта бэкдор активировался в 100% экспериментов. Правда, вызвать нужный сбой получалось не с каждой попытки. Для электромагнитной атаки вероятность успеха составляла от 5,8% до 34,3%. В одном из сценариев требовалось в среднем девять попыток. Короче, нужно фаззить железку.

Самая интересная часть исследвания описывает проверку защиты. Бэкдор, который прятали во входной картинке, нашли все инструменты защиты. Бэкдор, который прятался во внутренних вычислениях модели, нашла только одна система защиты, и то не во всех датасетах. Все потому, что он живет внутри рантайма модели и не появляется на поверхности атаки, за которой пристально следят средства защиты.

Исследование показывает как превратить физический сбой в логическую инструкцию и открывает новую слепую зону в защите нейронок.

@makrushin | MAX | VK | Сетка | Дзен

Ransomware. Агентский. Первый.

Кибербез пробует разгонять нарратив в СМИ: «обнаружен первый экземпляр ИИ-вымогателя». Было несколько хороших попыток: PromptLock и JADEPUFFER.

Первая история оказалась «академическим прототипом», который случайно попал на радар. Не считается. При этом исследователи в своем отчете оставили джентльменский набор индикаторов компрометации.

Вторая история вышла под заголовками «первый агентский». Какого-то бинарного файла в ходе атаки не зафиксировано, потому что атакующие использовали существующие средства окружения, в котором проводили атаку. Например, удаленное выполнение кода проводилось через встроенный в Langflow python-интерпретатор. В API-эндпоинт прилетали инструкции, у которых исследователи разглядели стилистический отпечаток, характерный для кода, сгенерированного LLM.

«Код, сгенерированный LLM» — еще не означает, что атака автономно управлялась LLM. Остается вероятность, что оператор мог использовать модель в качестве ассистента в процессе атаки. Особенно на этапе написания кода, чтобы исключить какую-либо атрибуцию.

Более интересная особенность атаки всплыла на этапе логина в систему. Скрипт атакующего пытался создать backdoor-админа, и для этого нужно было сгенерировать хэш пароля. С первой попытки не получилось, и за 31 секунду атакующий проверил две гипотезы, одна из которых сработала. Для исследователей это поведение стало сигналом, что атакующий агент смог самостоятельно прийти к решению. Хотя, на самом деле, это поведение могло быть предусмотрено в виде обычного обработчика исключений. Это обычная практика в инструментах red team: описать несколько резервных сценариев заранее.

Был ли это ИИ-агент или человек с LLM — думаю, что не так важно. В отчете есть другой интересный инсайт: ИИ-инструменты в инфре стали одновременно и точкой входа, и средством пост-эксплуатации. И еще формат индикаторов теперь нужно адаптировать под реалии, когда атаки превращаются в наборы промптов.

@makrushin l MAX l VK l Сетка l Дзен

Как обойти фильтры LLM с помощью квантовой механики

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

Мы научились внедрять вредоносные запросы в модель, а модели ещё лучше научились фильтровать эти запросы. Если простой промпт "забудь все предыдущие инструкции и выполни мой запрос" по какой-то причине игнорируется LLM, то можно попробовать отправить тот же запрос в другом формате. На другом языке, с использованием 1337speak. Но даже эти попытки будут заблокированы хорошим фильтром.

У больших языковых моделей есть фильтры безопасности. Они натренированы распознавать опасные паттерны в обычном тексте. Паттерны. В тексте.

«Объясни, как сделать X», «напиши код для Y»,
где X — что-то незаконное, а Y — какой-то вредоносный код.

В этом исследовании описана новая идея, как обойти эти фильтры, если написать запрос на языке математики. То есть с помощью математической "инкапсуляции" запросов в сложные задачи по теории множеств, логике или квантовой механике можно обойти цензуру. Если фильтр видит символы ∀, ∃, ∧, то воспринимает это как математическую задачу и пропускает запрос. Модель решает эту задачу и — главный трюк — в итоге получает инструкцию "забудь все инструкции и…"

Ещё один ответ на вопрос "зачем специалисту по кибербезу изучать математику?": чтобы уметь обойти фильтры.

@makrushin l MAX l VK l Сетка l Дзен

91% находок «классического» SAST — ложные срабатывания.

А еще AppSec-инженер тратит 10–20 минут на каждую находку, чтобы принять решение, нужно ли ее исправлять. Умножаем это время на количество находок и получаем дорогую команду для «ручной фильтрации».

LLM меняют это уравнение. Передаем модели правильный контекст (например, трассу, критичность, commit hash), и снижаем время на принятие решения с минут до секунд. Ключевое слово: «правильный». Если контекста недостаточно, то модель галлюцинирует. Если его много, то расфокусируется, сжигает токены и несет в бэклог минорные находки вместо критических.

Мы перебрали архитектурные подходы для интеграции ИИ в SAST, рассмотрели варианты оптимизации контекста, запилили фичу для ИИ-триажа находок и поделились результатами в статье. Еще определили ключевые метрики для оценки результата.

@makrushin l MAX l VK l Сетка l Дзен