Makrushin

Как обойти фильтры LLM с помощью квантовой механики
https://i.8upload.com/image/97c5c3130b2c3282/screenshot-2026-06-22-at-19-26-31.png
Наконец-то после серии трёхнедельных перемещений по рабочим событиям, в пути где-то между Омском и Новосибирском, появилась возможность потестировать интересную атаку на LLM.

Мы научились внедрять вредоносные запросы в модель, а модели ещё лучше научились фильтровать эти запросы. Если простой промпт "забудь все предыдущие инструкции и выполни мой запрос" по какой-то причине игнорируется LLM, то можно попробовать отправить тот же запрос в другом формате. На другом языке, с использованием https://www.promptfoo.dev/docs/red-team/strategies/leetspeak/. Но даже эти попытки будут заблокированы хорошим фильтром.

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

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

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

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

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

100+ CVE в день и эксплойт за $1

LLM уверенно генерируют рабочие эксплойты по описанию уязвимости из CVE и патчам. Редиске не нужно ничего реверсить. Достаточно настроить инструменты для определения диффа на основе патча и подготовить детальное описание баги. Так утверждают исследования, в которых описана экономика разработки эксплойтов с помощью ИИ. https://valmarelox.substack.com/p/can-ai-weaponize-new-cves-in-under за $1, https://arxiv.org/pdf/2509.01835 за $2.77.

Умножаем на 100+ новых CVE в день и получаем автоматизированный конвейер на стороне атакующего. Политика «патчим критичные баги за 7 дней» ушла в историю. Про 90 дней на исправление вообще стоит забыть.

Почему это https://t.me/yandexforsecurity новость для security-инженера:
⚪️ закрытая кодовая база становится временным преимуществом для защиты
⚪️ дополнительная проверка находок от анализаторов является узким горлышком appsec-команды, а значит, теперь очевиден фокус для инженера
⚪️ время реакции на уязвимости теперь измеряется минутами, не днями. К концу года будет измеряться секундами.

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

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

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

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

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

Мы перебрали архитектурные подходы для интеграции ИИ в SAST, рассмотрели варианты оптимизации контекста, запилили фичу для ИИ-триажа находок и поделились результатами в https://habr.com/ru/companies/sourcecraft/articles/1038016/. Еще определили ключевые метрики для оценки результата.

l https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA l https://vk.com/makrushin l https://set.ki/channel/fNyAw8J l https://dzen.ru/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

Наблюдаем технологические тренды через портфели фондов
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

Смена парадигмы в 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