ru
Feedback
Makrushin

Makrushin

Открыть в Telegram

Денис Макрушин. Здесь, чтобы спасти мир. Про кибербезопасность, технологии и людей. По вопросам сотрудничества: @makrushin_bot Канал в Max: https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA makrushin.com

Больше
3 687
Подписчики
Нет данных24 часа
-47 дней
+830 день
Архив постов
«Тишина должна быть в библиотеке!» Там сейчас правда тихо. Особенно в домашней библиотеке рядом с айтишными книгами. Вопрос,
«Тишина должна быть в библиотеке!» Там сейчас правда тихо. Особенно в домашней библиотеке рядом с айтишными книгами. Вопрос, который иногда всплывает у книжных стеллажей: что я узнаю из этой книги, чего не узнаю от GPT? Друзья из издательства поделились черновиком AI Agents for Offensive Security, автор которого взялся за заведомо сложную задачу. Очевидно, что книга на стыке ИИ и кибербеза устаревает быстрее, чем выходит. Устаревает еще на этапе написания главы. Поэтому в ней стоит искать не код и тулы, а фундаментальные идеи с длинным горизонтом. В черновике нашел два взаимодополняющих подхода: ✨ Артефакт-центричная архитектура. Агенты не общаются напрямую, а через структурированные артефакты — контракты, которые отделяют движение данных от логики принятия решений и делают весь процесс проверяемым. ✨ Доказательная безопасность. Каждое действие агента должно быть верифицируемым за счет наличия "улик": промптов, сырых данных от инструментов, цепочек рассуждений, логов с подтверждениями от человека. Чтобы в любой момент восстановить ход событий и подтвердить рамки проекта. Пригодится пентестерам, ред тимерам, охотникам за уязвимостями, исследователям и всем, кто строит ИИ-конвейеры для анализа защищенности. @makrushin l MAX l VK l Сетка l Дзен

Как обойти фильтры LLM с помощью квантовой механики Наконец-то после серии трёхнедельных перемещений по рабочим событиям, в пути где-то между Омском и Новосибирском, появилась возможность потестировать интересную атаку на LLM. Мы научились внедрять вредоносные запросы в модель, а модели ещё лучше научились фильтровать эти запросы. Если простой промпт "забудь все предыдущие инструкции и выполни мой запрос" по какой-то причине игнорируется LLM, то можно попробовать отправить тот же запрос в другом формате. На другом языке, с использованием 1337speak. Но даже эти попытки будут заблокированы хорошим фильтром. У больших языковых моделей есть фильтры безопасности. Они натренированы распознавать опасные паттерны в обычном тексте. Паттерны. В тексте.
«Объясни, как сделать X», «напиши код для Y»,
где X — что-то незаконное, а Y — какой-то вредоносный код. В этом исследовании описана новая идея, как обойти эти фильтры, если написать запрос на языке математики. То есть с помощью математической "инкапсуляции" запросов в сложные задачи по теории множеств, логике или квантовой механике можно обойти цензуру. Если фильтр видит символы ∀, ∃, ∧, то воспринимает это как математическую задачу и пропускает запрос. Модель решает эту задачу и — главный трюк — в итоге получает инструкцию "забудь все инструкции и…" Ещё один ответ на вопрос "зачем специалисту по кибербезу изучать математику?": чтобы уметь обойти фильтры. @makrushin l MAX l VK l Сетка l Дзен

100+ CVE в день и эксплойт за $1 LLM уверенно генерируют рабочие эксплойты по описанию уязвимости из CVE и патчам. Редиске не нужно ничего реверсить. Достаточно настроить инструменты для определения диффа на основе патча и подготовить детальное описание баги. Так утверждают исследования, в которых описана экономика разработки эксплойтов с помощью ИИ. Где-то за $1, где-то за $2.77. Умножаем на 100+ новых CVE в день и получаем автоматизированный конвейер на стороне атакующего. Политика «патчим критичные баги за 7 дней» ушла в историю. Про 90 дней на исправление вообще стоит забыть. Почему это хорошая новость для security-инженера: ⚪️ закрытая кодовая база становится временным преимуществом для защиты ⚪️ дополнительная проверка находок от анализаторов является узким горлышком appsec-команды ⚪️ время реакции на уязвимости теперь измеряется минутами, не днями. К концу года будет измеряться секундами. Чтобы ускориться в исправлении проблем, не получится просто прикрутить LLM к существующим решениям. Нужно менять или строить заново архитектуру и процессы для agentic-систем. @makrushin l MAX l VK l Сетка l Дзен

91% находок «классического» SAST — ложные срабатывания. А еще AppSec-инженер тратит 10–20 минут на каждую находку, чтобы принять решение, нужно ли ее исправлять. Умножаем это время на количество находок и получаем дорогую команду для «ручной фильтрации». LLM меняют это уравнение. Передаем модели правильный контекст (например, трассу, критичность, commit hash), и снижаем время на принятие решения с минут до секунд. Ключевое слово: «правильный». Если контекста недостаточно, то модель галлюцинирует. Если его много, то расфокусируется, сжигает токены и несет в бэклог минорные находки вместо критических. Мы перебрали архитектурные подходы для интеграции ИИ в SAST, рассмотрели варианты оптимизации контекста, запилили фичу для ИИ-триажа находок и поделились результатами в статье. Еще определили ключевые метрики для оценки результата.

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

Впервые в истории отчетов об угрозах Verizon: вектор эксплуатации уязвимостей обогнал украденные учетки Ключевой инсайт из свежего отчета Verizon Data Breach Investigations Report, в котором аналитики собрали статистику по 22000 инцидентам в 145 странах:
впервые за 19 лет эксплуатация уязвимостей стала основным вектором получения первоначального доступа.
В прошлые годы этим вектором были украденные учетные данные. Есть ли здесь связь с развитием ИИ в процессе подготовки эксплойтов? Возможно. Еще примечательное: у вымогателей снижается маржинальность, потому что жертвы все реже платят. Группы вынуждены масштабироваться и повышать свою выручку за счет охвата. Дальше вымогателям придется чаще фабриковать артефакты «взломов» и фейковых «утечек», используя старые данные и фантазию LLM.

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

Архитектура платформы для автоматизации SOC с помощью ИИ-агентов Всегда интересно прочитать истории, как LLM самостоятельно находит уязвимости в популярном продукте. Как крупные вендоры вроде Mozilla патчат 271 уязвимость, которую обнаружил Mythos. Или как ИИ-агент за 3 минуты без подсказок смог самостоятельно скомпрометировать облачную инфраструктуру. Среди подобных материалов часто остаются незаметны идеи, которые нужны специалистам по защите. На прошлой неделе бот закрыл этот пробел и принес исследование, которое будет интересно Blue Team. В статье описана архитектура системы ИИ-агентов для автоматизации работы центров мониторинга. Ключевую идею этой платформы можно описать одним словом: проактивность. Чтобы не ждать очередных пентестов и проверок Red Team, аналитики могут самостоятельно построить систему непрерывного прогнозирования и обновления детекторов. Ключевая особенность платформы AgentSOC заключается в движке анализа гипотез. Этот модуль отвечает за творческую часть, которая часто остается без внимания загруженного рутиной аналитика. В нем LLM строит ветки возможного развития атак на основе имеющегося контекста из систем мониторинга. Затем привязывает эти ветки к матрице атак MITRE. То есть система постоянно рассуждает над вопросом «что, если», присваивает ответу индекс уверенности и повторяет упражнение. Второй движок структурного моделирования выступает в роли критика и проверяет теоретические рассуждения модели на основе фактического состояния инфраструктуры. Графовая валиадация атак, проверка достижимости, фильтрация галлюцинаций — все это его задачи. В итоге, вся система работает в автономном цикле «Sense-Reason-Act» и выбирает наиболее подходящее действие для защиты менее чем за 1 секунду. @makrushin l MAX l VK l Сетка l Дзен

Сделали облачные регионы полностью изолированными, сохранили бесшовный пользовательский опыт работы с ними. Получили патент. Крупные облачные провайдеры работают на едином слое управления доступами. Это удобно, но при инциденте в одном регионе у атакующего есть возможность уползти в другие области. Изоляция является основным способом снижения этого риска. Поэтому мы сделали так, что каждый регион нашего облака — это теперь полностью автономная инсталляция со своей базой доступов. При этом у пользователя остается опыт работы в единой облачной платформе. В основе этой архитектуры находится «теневая организация» — копия основной организации пользователя и ее облачного кабинета, которая создается в новом регионе. Все пользователи, группы, политики организации автоматически реплицируются из основного региона в теневой. Это избавляет пользователя от необходимости переносить свои настройки и ресурсы в новую область. При этом, компрометация теневого региона не позволяет атакующему дотянуться до основной организации. О том, как построено доверие между регионами и бесшовное переключение между кабинетами без повторного логина рассказали в блоге. @makrushin l MAX l VK l Сетка l Дзен

Разбираем топ-10 атак на приложения и делаем выводы для разработки Атаки на современные приложения всё реже возникают из-за одной ошибки в коде. В многокомпонентном софте появляется новый уязвимый слой: взаимодействие между компонентами. Ruby видит одно, Go видит другое и в результате злоумышленник протаскивает свой запрос мимо обоих. Серверный и клиентский кэш становятся каналом утечки секретов, а ошибки сервера — каналом связи злодея с внутренней инфраструктурой приложения. На основе рейтинга нетривиальных атак выделил основные категории уязвимостей, с которыми сталкивается разработчик (особенно, вайбкодер), и дал сценарии защиты с помощью привычных и пока ещё эффективных инструментов. @makrushin l MAX l VK l Сетка l Дзен

Наблюдаем технологические тренды через портфели фондов Каждый год слежу за RSAC Innovation Sandbox, чтобы проследить за трендами: какие категории проектов проходят отбор, кто из фондов "прикрывает" финалистов. В этом году 10 из 10 финалистов так или иначе связаны с ИИ. Победил Geordie AI с governance-платформой для ИИ-агентов. Но примечательным оказался не победитель, а конкретный фонд, который за ним стоит. Ten Eleven Ventures — это единственный фонд, у которого было сразу две портфельные компании среди финалистов. Его портфель тоже довольно интересный: пять инвестиций подряд и все в agentic-проекты. Еще интереснее, что в 2024 году на том же конкурсе победила другая компания из их портфеля, и её продукт тоже был про защиту учётных данных сервисных аккаунтов, ботов и AI-агентов. Врядли совпадение. Его сделки в 2026 году также дают интересный инсайт: защита non-human identities (NHI) превратилась в категорию с крупным капиталом. Похоже, что в индустрии образуется пять ключевых технологических слоев для построения стратегии безопасности ИИ: 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 может накатывать обновление в свою стратегию.

Обещал показать, как редиска крадёт секреты у разработчиков через их же ИИ-инструменты. Показал. На DevOps Conf представил ре
Обещал показать, как редиска крадёт секреты у разработчиков через их же ИИ-инструменты. Показал. На DevOps Conf представил результаты исследования «Атаки на ИИ-агентов», которое мы провели вместе с командой. Разобрали сценарии в ADLC (Agentic Development Lifecycle — запоминаем этот термин, будем встречать его всё чаще) и показали методы анализа устойчивости ИИ-инфраструктуры для тех, кто строит агентные системы. Ключевой тезис: SDLC трансформировался в ADLC, и классические подходы к безопасной разработке теряют эффективность. Поведение агента недетерминировано и меняется без изменения кода. Pull request — больше не чекпоинт, когда агент автономно читает тикеты, обрабатывает изменения и что-то меняет в коде. Видимость упала — скорость выросла. Что с этим делать: LLM-as-a-Judge, guardrails на входе и выходе, AI red teaming в CI/CD, аудит каждого подключённого MCP-сервера. И еще куча идей в в попросах из зала и дискуссиях после доклада. Показали. Теперь пора рассказать. Готовим блогпост.

Трудно собрать, легко потерять, часть 4: папка security-каналов Коллеги по индустрии, которые регулярно следят за новостями и
Трудно собрать, легко потерять, часть 4: папка security-каналов Коллеги по индустрии, которые регулярно следят за новостями и исследованиями, снова собрались в одной папке, чтобы помочь экономить время на поиск и мониторинг ИБ-контента. Если задача — охватить разные аспекты кибербезопасности, от практических исследований до бизнеса и регуляторики, то эта папка быстро сформирует ленту. ⚡️

Давно не виделись. Нашел два повода для встречи. Завтра на продуктовой аллее DevOps Conf проведу питчинг SourceCraft и расска
Давно не виделись. Нашел два повода для встречи. Завтра на продуктовой аллее DevOps Conf проведу питчинг SourceCraft и расскажу про ключевые обновления, которые позволят быстрее и безопаснее создавать новые продукты. Спойлер: релизим новые AppSec и ИИ-фичи. Послезавтра представлю результаты нового исследования — «Атаки на ИИ-агентов». Покажу, какие возможности есть у редиски, чтобы за несколько часов скомпрометировать тысячи разработчиков через их же ИИ-инструменты и украсть секреты с рабочих станций. Разберём поверхность атаки, а на выходе получим методику и инструменты для тех, кто строит агентные системы и хочет сделать их устойчивыми. Если будешь на площадке, то заходи в гости.

Смена парадигмы в security-продуктах Индустрия десятилетиями находилась в условиях жесткого конфликта между полнотой и точностью поиска угроз. Статические и динамические анализаторы, антивирусные движки, межсетевые экраны — каждый из этих продуктов стремится снизить количество ложных срабатываний. LLM могут разрешить это фундаментальное противоречие. На примере инструментов SAST, которые игнорировали потенциально опасные пути в потоке данных программы и не видели целые категории уязвимостей, авторы исследования показали, как за счет глубокого понимания контекста появилась возможно расширить полноту без потери точности. Теперь существуют три архитектурных подхода для создания AI-native продукта: ⭐️ AI-enhanced: фильтрация результатов и ложных срабатываний, чтобы снизить нагрузку на security-аналитика ⭐️ AI explorer: добавление ИИ-агента для генерации гипотез и управления исследованием, чтобы расширить анализ за счет новых правил поиска. ⭐️ AI native: полная автономность с «пониманием» бизнес-контекста, чтобы полностью исключить человеческий фактор из процесса. Эти архитектурные подходы также являются тремя этапами продуктовой эволюции. Эту эволюцию ограничивают три фактора: экономика операций, проблемы «личности» агента и неэффективный вызов инструментов. Широкий контекст для агента увеличивает стоимость его действий. Еще агент может решить, что какое-то событие «выглядит безопасно», и пропустить его из-за субъективной вероятности. Ну а попытки LLM вызвать внешние инструменты чаще оказываются дороже, чем использование классических правил. Авторы делают вывод, что наиболее перспективный метод использования LLM — это не анализ событий в реальном времени, а оптимизация существующих правил поиска угроз. Предложенная архитектура превращает SAST из инструмента «сопоставления куска кода с шаблоном» в инструмент для извлечения логически связанных участков кода. LLM управляет вниманием security-продукта, а индустрия движется от написания правил к проектированию цепочек рассуждений. 100% точности при трехкратком увеличении полноты - отличное тому подтверждение. @makrushin l MAX l VK l Сетка

Слепые зоны статанализа: применяем LLM для поиска новых уязвимостей Инструменты статанализа программы опираются на потоки данных: отслеживают источники данных (места, где пользователь может что-то внедрить) и приёмники (места, где введенные данные используются приложением). Известная проблема: классические инструменты анализа теряют след в потоке данных, когда используются специфические особенности языков программирования. Например, при многопоточности данные переходят из одного потока в другой, и таким образом анализатор теряется. А от использования механизмов рефлексии и динамического вызова методов статический анализатор вообще слепнет. Исследователи из Tencent решили эту проблему с помощью кастомного анализатора потоков данных и LLM. Кастомный анализатор давал что-то вроде шпаргалки, куда передаются данные и где они всплывают, чтобы поток не терялся. LLM искала источники и стоки данных, фильтровала мусор и классифицировала функции для исследователей. Хорошая идея, как можно улучшить свой анализатор, научить его видеть новые места в программе и в итоге, найти больше уязвимостей. @makrushin l MAX l VK l Сетка

Тренды и развитие киберугроз А вот свежий отчет по инцидентам от исследовательского подразделения Unit42 пересказывать не буду. В нем все очевидно: скорость атак увеличилась (72 минут на кражу данных в 2025 против 285 минут в 2024 - спасибо ИИ), поверхность атаки (браузер, почта) и методы атаки (эксплойты, фишинг) не изменились. Но есть одна примечательная деталь: в большинстве инцидентов путь внутрь инфраструктуры жертвы идет через атаки на identity (учетные записи, сессии, токены). С ростом популярности ИИ-агентов этот тренд усиливается за счет всяких “машинных” учеток, которые появляются в инфре в огромном количестве. Кто сейчас размышляет над своим проектом или кибербез-стартапом, стоит посмотреть в сторону защиты machine identity.

Куда идет рынок безопасности приложений Те, кто следит за развитием AppSec-продуктов и технологий, наверняка прочитают новый отчет. Оставлю ключевые инсайты: ✨ опыт разработчика становится приоритетом для всех AppSec-продуктов. Теперь решениям по безопасности важно интегрироваться со всеми инструментами, которыми пользуется разработчик. ✨ AI SAST — перспективный продукт, вызывающий наибольший интерес рынка в 2026 году. ✨ Проблема, которая становится более актуальной и все еще остается без решения: безопасность кода, сгенерированного с помощью ИИ. ✨ Базовая фича appsec-платформы в 2026 году — проверка уязвимостей в runtime-контексте. Тот самый подход code-to-cloud, о котором я писал пару лет назад, стал базой. ✨ Пользователю неважно, использует ли продукт собственный движок или является оберткой над опенсорс-инструментом. Важно качество правил и возможность их настройки под контекст приложения. ✨ В инструментах анализа зависимостей (SCA) акцент смещается с поиска уязвимостей на поиск малвари. @makrushin l MAX l VK

Трудно собрать, легко потерять: папка security-каналов. Часть 3. Коллеги по индустрии, которые регулярно следят за новостями
Трудно собрать, легко потерять: папка security-каналов. Часть 3. Коллеги по индустрии, которые регулярно следят за новостями и исследованиями, собрались в одной папке, чтобы помочь экономить время на поиск и мониторинг ИБ-контента. Если задача — охватить разные аспекты кибербезопасности, от практических исследований до бизнеса и регуляторики, то эта папка быстро сформирует ленту. ⚡️