🤖 Claude Mythos готов заменить пентестеров
AI Security Institute протестировали Claude Mythos Preview в кибервозможность.
Нейросеть провела пентсет корпоративной сети на уровне expert-level CTF. Ещё недавно на таких задачах модели буксовали почти безнадёжно, а теперь Mythos Preview берёт их с успехом 73%.
AISI собрали сценарий из 32 шагов, от разведки до полного захвата корпоративной сети. Mythos Preview прошёл этот сценарий от начала до конца, причём успешно завершил его в 3 из 10 попыток и в среднем доходил до 22 шагов из 32. Следующий лучший результат у Claude Opus 4.6, который в среднем проходил 16 шагов.
Модель уже не выглядит как «чатик, который что-то подсказывает». Она держит контекст, помнит, что уже пробовала, и двигается дальше, как исполнитель. Это уже очень похоже на автономную атаку, где человек задаёт рамку, а модель делает основную работу.
🛡Не все так идеально
Тесты проводились в упрощённой среде без активных защитников и без полноценного SOC. Поэтому AISI прямо не утверждает, что Mythos Preview взломает хорошо защищённую enterprise-инфраструктуру. Однако вывод напрашивается сам србой: модель уже умеет атаковать слабозащищённые системы, если ей дать сетевой доступ и направление.
👤 Потенциал
При увеличении бюджета до 100M токенов результат продолжал расти, то есть потолок возможностей модель ещё не показала. Единственный зафиксированный гэп, что модель не справилась с OT-ориентированным сценарием Cooling Tower, застряв на IT-части.
🤌 Делаем выводы
Если упростить до одной фразы, то переход уже случился: мы ушли от сценария, где AI «помогает искать баги», к сценарию, где AI способен сам вести атаку.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #cybersecurity #pentest #redteam #уязвимости #AIsecurity #ChatGPT #SecureTechTalks
AI Security Institute протестировали Claude Mythos Preview в кибервозможность.
Нейросеть провела пентсет корпоративной сети на уровне expert-level CTF. Ещё недавно на таких задачах модели буксовали почти безнадёжно, а теперь Mythos Preview берёт их с успехом 73%.
AISI собрали сценарий из 32 шагов, от разведки до полного захвата корпоративной сети. Mythos Preview прошёл этот сценарий от начала до конца, причём успешно завершил его в 3 из 10 попыток и в среднем доходил до 22 шагов из 32. Следующий лучший результат у Claude Opus 4.6, который в среднем проходил 16 шагов.
Модель уже не выглядит как «чатик, который что-то подсказывает». Она держит контекст, помнит, что уже пробовала, и двигается дальше, как исполнитель. Это уже очень похоже на автономную атаку, где человек задаёт рамку, а модель делает основную работу.
🛡Не все так идеально
Тесты проводились в упрощённой среде без активных защитников и без полноценного SOC. Поэтому AISI прямо не утверждает, что Mythos Preview взломает хорошо защищённую enterprise-инфраструктуру. Однако вывод напрашивается сам србой: модель уже умеет атаковать слабозащищённые системы, если ей дать сетевой доступ и направление.
👤 Потенциал
При увеличении бюджета до 100M токенов результат продолжал расти, то есть потолок возможностей модель ещё не показала. Единственный зафиксированный гэп, что модель не справилась с OT-ориентированным сценарием Cooling Tower, застряв на IT-части.
🤌 Делаем выводы
Если упростить до одной фразы, то переход уже случился: мы ушли от сценария, где AI «помогает искать баги», к сценарию, где AI способен сам вести атаку.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #cybersecurity #pentest #redteam #уязвимости #AIsecurity #ChatGPT #SecureTechTalks
👍2
🤖 OpenAI больше не ограничивает ответы модели.
Они ограничивают тебя.
Вышла модель GPT-5.4-Cyber.
OpenAI выпустила отдельную версию модели, GPT-5.4-Cyber, заточенную под кибербезопасность.
Компания гранулирует доступ к опасным возможностям, а не убирает их.
Одновременно расширяется программа Trusted Access for Cyber:
➖ тысячи проверенных специалистов
➖ сотни команд
➖ новые уровни доступа
И только на верхнем уровне открывается сама модель.
⚙️ Что умеет модель
GPT-5.4-Cyber работает на уровне практики:
➖ умеет разбирать бинарники без исходников,
➖ анализировать malware,
➖ оценивать безопасность compiled-софта,
➖ искать уязвимости там, где раньше нужен был отдельный стек инструментов.
👉 у модели снижены ограничения на “опасные” запросы, если они выглядят как легитимная работа по безопасности
🔐 Доступ как новая граница
Раньше AI пытались «обезвредить» на уровне самой модели. Теперь подход другой,
модель может многое
но не всем это доступно
OpenAI прямо говорит, что возможности модели это dual-use, и риск зависит не только от модели, но и от пользователя:
🔑 вводится жёсткая верификация (KYC)
🔑 уровни доверия
🔑 градация возможностей
Чем выше доверие, тем меньше ограничений.
🧩 Зачем?
Старый подход перестал работать. Атакующие уже научились «выжимать» больше из обычных моделей просто за счёт большего количества вычислений и сложных сценариев использования.
Ищначально OpenAI усиливали защитный стек.
Codex Security помог найти и исправить 3000+ критичных уязвимостей
и подключился к более чем 1000 open-source проектов. Теперь пришло время альтернативных подходов.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #cybersecurity #OpenAI #инфобез #AIsecurity #уязвимости #технологии #SecureTechTalks
Они ограничивают тебя.
Вышла модель GPT-5.4-Cyber.
OpenAI выпустила отдельную версию модели, GPT-5.4-Cyber, заточенную под кибербезопасность.
Компания гранулирует доступ к опасным возможностям, а не убирает их.
Одновременно расширяется программа Trusted Access for Cyber:
И только на верхнем уровне открывается сама модель.
⚙️ Что умеет модель
GPT-5.4-Cyber работает на уровне практики:
👉 у модели снижены ограничения на “опасные” запросы, если они выглядят как легитимная работа по безопасности
🔐 Доступ как новая граница
Раньше AI пытались «обезвредить» на уровне самой модели. Теперь подход другой,
модель может многое
но не всем это доступно
OpenAI прямо говорит, что возможности модели это dual-use, и риск зависит не только от модели, но и от пользователя:
🔑 вводится жёсткая верификация (KYC)
🔑 уровни доверия
🔑 градация возможностей
Чем выше доверие, тем меньше ограничений.
🧩 Зачем?
Старый подход перестал работать. Атакующие уже научились «выжимать» больше из обычных моделей просто за счёт большего количества вычислений и сложных сценариев использования.
Ищначально OpenAI усиливали защитный стек.
Codex Security помог найти и исправить 3000+ критичных уязвимостей
и подключился к более чем 1000 open-source проектов. Теперь пришло время альтернативных подходов.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #cybersecurity #OpenAI #инфобез #AIsecurity #уязвимости #технологии #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🚨 RDP-файлы снова в игре: Microsoft усиливает защиту Windows
Фишинг - это не только ссылки и PDF, злоумышленники активно используют .rdp-файлы (Remote Desktop).
Microsoft выпустила апрельские обновления, усиливающие защиту при открытии RDP-файлов в качестве реакции на новую волну атак.
Сценарий простой:
1⃣ жертве отправляют .rdp файл
2⃣ он открывается
3⃣ идёт подключение к серверу злоумышленника
4⃣ дальше полный доступ к файлам, учеткам и токенам
RDP при этом умеет гораздо больше, чем кажется: он может пробрасывать диски, буфер обмена и локальные ресурсы прямо на удалённую машину.
⚙️ Обновление "Винды"
Microsoft попытались добавить несколько инструментов защиты:
🛑 перед подключением теперь показывается более подробное предупреждение о целевой системе
🧾 явно отображаются ресурсы, которые будут расшарены (диски, clipboard и т.д.)
🔒 пользователь должен подтверждать потенциально рискованные действия
🚫 редиректы ресурсов отключены по умолчанию
💀 Всё ещё опасно
RDP вам не только “удалённый рабочий стол”, это фактически полноценный канал доступа к системе, который злоумышленники уже давно используют:
➖ APT-группы распространяют вредоносные .rdp файлы
➖ эксплойт не нужен, достаточно социальной инженерии
➖ пользователь сам инициирует атаку
Вот такой «фишинг на максималках» с root-доступом,блекджеком и ш...
🧩 Слабое звено
Даже с новыми предупреждениями остаётся базовая проблема. Пользователь всё ещё может нажать “OK” и слломать всю модель защиты.
Stay secure and read SecureTechTalks 📚
#RDP #WindowsSecurity #CyberSecurity #InfoSec #Phishing #APT #Microsoft #BlueTeam #ThreatIntel #SecureTechTalks
Фишинг - это не только ссылки и PDF, злоумышленники активно используют .rdp-файлы (Remote Desktop).
Microsoft выпустила апрельские обновления, усиливающие защиту при открытии RDP-файлов в качестве реакции на новую волну атак.
Сценарий простой:
1⃣ жертве отправляют .rdp файл
2⃣ он открывается
3⃣ идёт подключение к серверу злоумышленника
4⃣ дальше полный доступ к файлам, учеткам и токенам
RDP при этом умеет гораздо больше, чем кажется: он может пробрасывать диски, буфер обмена и локальные ресурсы прямо на удалённую машину.
⚙️ Обновление "Винды"
Microsoft попытались добавить несколько инструментов защиты:
🛑 перед подключением теперь показывается более подробное предупреждение о целевой системе
🧾 явно отображаются ресурсы, которые будут расшарены (диски, clipboard и т.д.)
🔒 пользователь должен подтверждать потенциально рискованные действия
🚫 редиректы ресурсов отключены по умолчанию
💀 Всё ещё опасно
RDP вам не только “удалённый рабочий стол”, это фактически полноценный канал доступа к системе, который злоумышленники уже давно используют:
Вот такой «фишинг на максималках» с root-доступом,
🧩 Слабое звено
Даже с новыми предупреждениями остаётся базовая проблема. Пользователь всё ещё может нажать “OK” и слломать всю модель защиты.
Stay secure and read SecureTechTalks 📚
#RDP #WindowsSecurity #CyberSecurity #InfoSec #Phishing #APT #Microsoft #BlueTeam #ThreatIntel #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🚀 Не самый сильный, но самый показательный: Claude Opus 4.7
Вышел Claude Opus 4.7. Это тот редкий случай, когда важно не “насколько он мощный”, а зачем он вообще существует 😁.
Anthropic прямо говорит, что это не предел их технологий. Более того, внутри компании уже есть модели сильнее (тот же Mythos), но их пока не выпускают в открытый доступ.
🧠 Внимательнее к деталям
Opus 4.7 ощутимо прокачали в практических задачах. Он лучше держит длинные цепочки рассуждений, аккуратнее работает с кодом, да и в целом стал более “собранным” в сложных сценариях. Также в модели усилили работу с изображениями, теперь она увереннее читает схемы, интерфейсы и технические диаграммы.
И еще одно изменение, модель стала буквально следовать инструкциям. Иногда даже слишком буквально.
🛡 Полигон безопасности
Данный релиз выглядит, как контролируемый эксперимент. Opus 4.7 используют как “безопасную оболочку”, внутри которой обкатываются механики защиты перед выпуском более мощных систем.
Модель обучена с ограничениями. Часть потенциально опасных возможностей в области кибератак намеренно ослаблена. Параллельно она пытается распознавать рискованные сценарии и отказываться от них. Своеобразная подготовка к следующим поколениям моделей.
🔓 Окно для тех, кто понимает
При этом Anthropic оставляет дверь приоткрытой. Через Cyber Verification Program исследователи могут получить доступ к более “свободному” поведению модели без части ограничений.
Это аккуратный баланс. С одной стороны контроль, с другой - возможность изучать реальные риски.
🤖 От ответа к действию
Есть ещё один момент, который легко пропустить. Opus 4.7 стал чаще перепроверять себя, уточнять контекст и даже спорить с пользователем, если видит ошибку.
Звучит как мелочь, но на деле это новый этап эволюции. Посмотрим куда она нас приведёт в ближайшем будущем.
Stay secure and read SecureTechTalks 📚
#AI #CyberSecurity #LLM #Anthropic #Claude #Infosec #AIAgents #PromptInjection #AIrisks #SecureTechTalks
Вышел Claude Opus 4.7. Это тот редкий случай, когда важно не “насколько он мощный”, а зачем он вообще существует 😁.
Anthropic прямо говорит, что это не предел их технологий. Более того, внутри компании уже есть модели сильнее (тот же Mythos), но их пока не выпускают в открытый доступ.
🧠 Внимательнее к деталям
Opus 4.7 ощутимо прокачали в практических задачах. Он лучше держит длинные цепочки рассуждений, аккуратнее работает с кодом, да и в целом стал более “собранным” в сложных сценариях. Также в модели усилили работу с изображениями, теперь она увереннее читает схемы, интерфейсы и технические диаграммы.
И еще одно изменение, модель стала буквально следовать инструкциям. Иногда даже слишком буквально.
🛡 Полигон безопасности
Данный релиз выглядит, как контролируемый эксперимент. Opus 4.7 используют как “безопасную оболочку”, внутри которой обкатываются механики защиты перед выпуском более мощных систем.
Модель обучена с ограничениями. Часть потенциально опасных возможностей в области кибератак намеренно ослаблена. Параллельно она пытается распознавать рискованные сценарии и отказываться от них. Своеобразная подготовка к следующим поколениям моделей.
🔓 Окно для тех, кто понимает
При этом Anthropic оставляет дверь приоткрытой. Через Cyber Verification Program исследователи могут получить доступ к более “свободному” поведению модели без части ограничений.
Это аккуратный баланс. С одной стороны контроль, с другой - возможность изучать реальные риски.
🤖 От ответа к действию
Есть ещё один момент, который легко пропустить. Opus 4.7 стал чаще перепроверять себя, уточнять контекст и даже спорить с пользователем, если видит ошибку.
Звучит как мелочь, но на деле это новый этап эволюции. Посмотрим куда она нас приведёт в ближайшем будущем.
Stay secure and read SecureTechTalks 📚
#AI #CyberSecurity #LLM #Anthropic #Claude #Infosec #AIAgents #PromptInjection #AIrisks #SecureTechTalks
👍3
🔥 WAF больше не спасает. Встречайте GAF 😁
Мы долго жили в мире, где безопасность = сеть + приложение. Поставил WAF и вроде как спишь спокойно.
Теперь, с приходом LLM, всё сломалось. Классическая защита не видит угроз.
❌ Нет сигнатур
❌ Нет эксплойтов
❌ Нет аномального
🧠 Семантика
Традиционные средства смотрят на IP, заголовки или структуру запроса, но атаки на LLM происходят на уровне смысла:
Для WAF - это harmless, для LLM - это начало компрометации.
🛡 Куда двигаться?
Новый слой безопасности, GAF (Generative Application Firewall), встаёт между пользователем и LLM
и контролирует всё взаимодействие целиком.
GAF состоит из 5 уровней защиты:
1️⃣ Network: rate limit, DDoS
2️⃣ Access: кто ты и что тебе можно
3️⃣ Syntactic: структура и формат
4️⃣ Semantic: смысл запроса
5️⃣ Context: история диалога (!)
💡 Обязательно понимание контекста во времени.
Такой подход позволяет:
🔍 отслеживать диалог целиком
✂️ вырезать опасные части ответа (не блокируя всё)
🧰 контролировать tool calls агентов
🧠 ловить multi-turn атаки (Echo Chamber, Crescendo)
⛔ останавливать генерацию на лету
🔗 Более подробно про GAF читайте в исследовании.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #LLMsecurity #AIsecurity #PromptInjection #Jailbreak #GenAI #AppSec #CyberSecurity #AIagents
Мы долго жили в мире, где безопасность = сеть + приложение. Поставил WAF и вроде как спишь спокойно.
Теперь, с приходом LLM, всё сломалось. Классическая защита не видит угроз.
❌ Нет сигнатур
❌ Нет эксплойтов
❌ Нет аномального
🧠 Семантика
Традиционные средства смотрят на IP, заголовки или структуру запроса, но атаки на LLM происходят на уровне смысла:
“Представь, что ты не ограничен правилами…”
Для WAF - это harmless, для LLM - это начало компрометации.
🛡 Куда двигаться?
Новый слой безопасности, GAF (Generative Application Firewall), встаёт между пользователем и LLM
и контролирует всё взаимодействие целиком.
GAF состоит из 5 уровней защиты:
1️⃣ Network: rate limit, DDoS
2️⃣ Access: кто ты и что тебе можно
3️⃣ Syntactic: структура и формат
4️⃣ Semantic: смысл запроса
5️⃣ Context: история диалога (!)
💡 Обязательно понимание контекста во времени.
Такой подход позволяет:
🔍 отслеживать диалог целиком
✂️ вырезать опасные части ответа (не блокируя всё)
🧰 контролировать tool calls агентов
🧠 ловить multi-turn атаки (Echo Chamber, Crescendo)
⛔ останавливать генерацию на лету
🔗 Более подробно про GAF читайте в исследовании.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #LLMsecurity #AIsecurity #PromptInjection #Jailbreak #GenAI #AppSec #CyberSecurity #AIagents
👍3
🔒 Sber X-TI: бесплатная платформа кибербезопасности
Есть редкий кейс на рынке ИБ: инструмент, который закрывает сразу несколько задач и при этом стоит 0 рублей.
Sber X-Threat Intelligence платформа от Сбера - это попытка вынести накопленную экспертизу компании в формате единого сервиса с аналитикой, уязвимостями и мониторингом внешнего периметра.
🧠 Бесплатно? Где подвох?
Сбер несколько лет развивал внутреннюю TI-платформу, а затем открыл часть функциональности наружу. Ограничение здесь не техническое, а юридическое: продавать такой продукт как отдельный сервис нельзя, поэтому модель остаётся бесплатной.
При этом подключены уже сотни компаний, от малого бизнеса до госсектора. То есть это не “пилот”, а вполне живая система.
⚙️ Три слоя защиты
Внутри платформа собрана как единый интерфейс, но фактически это три разных направления.
1⃣ Threat Intelligence. Это база аналитики: отчёты, индикаторы компрометации, карточки APT-групп и связи между атаками. Упор сделан не на количество, а на ручную валидацию. В публичной версии меньше данных, чем во внутренних системах, но они “проверенные руками”.
2⃣ Vulnerability Management. Здесь уже классическая история с уязвимостями: агрегация данных из десятков источников, приоритизация через CVSS/EPSS и возможность загрузить свой инвентарь без тяжёлых сканеров. Интересным бонусом идут результаты внутреннего тестирования ПО в лаборатории Сбера.
3⃣ EASM. Мониторинг внешнего периметра: утечки, фишинговые домены, упоминания в Telegram и даркнете, а также ранние сигналы по DDoS. На старте дается расширенный доступ к инструментам сканирования периметра.
📊 Где это на фоне рынка
Отеровенно говоря, X-TI проигрывает классическим TI-решениям по объёму данных. НО это единственная платформа, которая бесплатно даёт связку:
Threat Intelligence + Vulnerability Management + EASM в одном интерфейсе
Обычно за это платят отдельно и совсем немало.
🔗 Ссылка на Sber X-TI
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #ThreatIntelligence #VulnerabilityManagement #EASM #SberXTI #ИБ #кибербезопасность #бесплатныйинструмент #длябизнеса
Есть редкий кейс на рынке ИБ: инструмент, который закрывает сразу несколько задач и при этом стоит 0 рублей.
Sber X-Threat Intelligence платформа от Сбера - это попытка вынести накопленную экспертизу компании в формате единого сервиса с аналитикой, уязвимостями и мониторингом внешнего периметра.
🧠 Бесплатно? Где подвох?
Сбер несколько лет развивал внутреннюю TI-платформу, а затем открыл часть функциональности наружу. Ограничение здесь не техническое, а юридическое: продавать такой продукт как отдельный сервис нельзя, поэтому модель остаётся бесплатной.
При этом подключены уже сотни компаний, от малого бизнеса до госсектора. То есть это не “пилот”, а вполне живая система.
⚙️ Три слоя защиты
Внутри платформа собрана как единый интерфейс, но фактически это три разных направления.
1⃣ Threat Intelligence. Это база аналитики: отчёты, индикаторы компрометации, карточки APT-групп и связи между атаками. Упор сделан не на количество, а на ручную валидацию. В публичной версии меньше данных, чем во внутренних системах, но они “проверенные руками”.
2⃣ Vulnerability Management. Здесь уже классическая история с уязвимостями: агрегация данных из десятков источников, приоритизация через CVSS/EPSS и возможность загрузить свой инвентарь без тяжёлых сканеров. Интересным бонусом идут результаты внутреннего тестирования ПО в лаборатории Сбера.
3⃣ EASM. Мониторинг внешнего периметра: утечки, фишинговые домены, упоминания в Telegram и даркнете, а также ранние сигналы по DDoS. На старте дается расширенный доступ к инструментам сканирования периметра.
📊 Где это на фоне рынка
Отеровенно говоря, X-TI проигрывает классическим TI-решениям по объёму данных. НО это единственная платформа, которая бесплатно даёт связку:
Threat Intelligence + Vulnerability Management + EASM в одном интерфейсе
Обычно за это платят отдельно и совсем немало.
🔗 Ссылка на Sber X-TI
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #ThreatIntelligence #VulnerabilityManagement #EASM #SberXTI #ИБ #кибербезопасность #бесплатныйинструмент #длябизнеса
👍1
🤖 PentAGI: мультиагентная команда пентестеров
PentAGI (Penetration Testing Artificial General Intelligence) - open-source платформа, которая превращает LLM-модели в команду виртуальных специалистов по кибербезопасности. Проект позволяет автоматизировать задачи тестирования на проникновение без необходимости вручную запускать десятки инструментов.
Основные фичи:
🤖 Полная автономность
PentAGI сам определяет шаги тестирования: от разведки и сканирования до эксплуатации уязвимостей и генерации отчётов. AI-агенты планируют атаки, анализируют результаты и адаптируют стратегию на лету.
🏖 Песочница безопасности
Все операции выполняются в изолированных Docker-контейнерах. Даже если агент «сойдёт с ума» будет ущерб ограничен виртуальной средой.
👥 Команда специалистов
Система использует делегирование задач между специализированными агентами:
🔍 Researcher исследует цель и собирает разведданные
💻 Developer пишет эксплойты и скрипты
⚔️ Executor выполняет атаки в изолированной среде
🧠 Adviser контролирует качество и предлагает альтернативные стратегии
20+ профессиональных инструментов. Встроенный арсенал включает nmap, Metasploit, sqlmap и другие инструменты, которые агенты используют как своими руками.
👩🎓 Память и обучение
PentAGI запоминает успешные подходы и накапливает знания через граф знаний на Neo4j (Graphiti). Каждый новый тест система проводит умнее предыдущего.
🧠 Гибкость LLM-провайдеров
Поддерживается 10+ поставщиков моделей: OpenAI, Anthropic, Google Gemini, AWS Bedrock, DeepSeek, GLM, Kimi, Qwen, Ollama (локальный запуск) и даже LiteLLM-прокси. Можно использовать облачные API или развернуть всё локально на своём железе.
🏗️ Архитектура
Система построена на микросервисной архитектуре:
➖ React + TypeScript фронтенд
➖ Go + GraphQL бэкенд с REST API
➖ PostgreSQL + pgvector для векторного поиска
➖ Neo4j для графа знаний
➖ Grafana/Prometheus/Jaeger/Loki для мониторинга
➖ Langfuse для аналитики LLM-операций
Всё это упаковано в Docker Compose и разворачивается одной командой.
🔗 Ссылка на GitHub: vxcontrol/pentagi
PentAGI попытка создать настоящего «цифрового пентестера», который думает, планирует и учится.
Вопрос в том, готовы ли вы доверить ИИ настолько серьёзные задачи?
Да - 👍 Нет - 😱
Stay secure and read SecureTechTalks 📚
#PentAGI #AI #PenetrationTesting #CyberSecurity #AutonomousAgents #RedTeam #OpenSource #SecureTechTalks
PentAGI (Penetration Testing Artificial General Intelligence) - open-source платформа, которая превращает LLM-модели в команду виртуальных специалистов по кибербезопасности. Проект позволяет автоматизировать задачи тестирования на проникновение без необходимости вручную запускать десятки инструментов.
Основные фичи:
🤖 Полная автономность
PentAGI сам определяет шаги тестирования: от разведки и сканирования до эксплуатации уязвимостей и генерации отчётов. AI-агенты планируют атаки, анализируют результаты и адаптируют стратегию на лету.
Все операции выполняются в изолированных Docker-контейнерах. Даже если агент «сойдёт с ума» будет ущерб ограничен виртуальной средой.
Система использует делегирование задач между специализированными агентами:
🔍 Researcher исследует цель и собирает разведданные
💻 Developer пишет эксплойты и скрипты
⚔️ Executor выполняет атаки в изолированной среде
🧠 Adviser контролирует качество и предлагает альтернативные стратегии
20+ профессиональных инструментов. Встроенный арсенал включает nmap, Metasploit, sqlmap и другие инструменты, которые агенты используют как своими руками.
PentAGI запоминает успешные подходы и накапливает знания через граф знаний на Neo4j (Graphiti). Каждый новый тест система проводит умнее предыдущего.
🧠 Гибкость LLM-провайдеров
Поддерживается 10+ поставщиков моделей: OpenAI, Anthropic, Google Gemini, AWS Bedrock, DeepSeek, GLM, Kimi, Qwen, Ollama (локальный запуск) и даже LiteLLM-прокси. Можно использовать облачные API или развернуть всё локально на своём железе.
🏗️ Архитектура
Система построена на микросервисной архитектуре:
Всё это упаковано в Docker Compose и разворачивается одной командой.
🔗 Ссылка на GitHub: vxcontrol/pentagi
PentAGI попытка создать настоящего «цифрового пентестера», который думает, планирует и учится.
Вопрос в том, готовы ли вы доверить ИИ настолько серьёзные задачи?
Да - 👍 Нет - 😱
Stay secure and read SecureTechTalks 📚
#PentAGI #AI #PenetrationTesting #CyberSecurity #AutonomousAgents #RedTeam #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12😱1
🐍 Быстрые нейросети таят в себе опасные уязвимости
Пока весь AI-мир обсуждает модели, способные обрабатывать книги за секунды, исследователи обнаружили, что их главное преимущество в невероятной скорости, одновременно является ахиллесовой пятой в плане безопасности.
👉 Речь идёт о State-Space Models SSM (архитектурах вроде Mamba и Jamba), которые обрабатывают тексты и данные в десятки раз быстрее классических Transformer'ов, вроде ChatGPT. Они уже внедряются в геномный анализ, клинический мониторинг пациентов и SOC-центры. Однако никто всерьёз не изучал их устойчивость к атакам. Спойлер:там есть уязвимости, которых нет у привычных нейросетей.
🎯 Три новых класса атак
Спектральные атаки: взлом через «частоту» данных
SSM работают как обученные фильтры с характерными частотными характеристиками. Злоумышленник концентрирует возмущения в полосах максимального усиления модели. Другими словами, достаточно слегка «подправить» данные и модель выдаст неверный результат.
⏱️ Отложенные бэкдоры: бомба замедленного действия
Триггер активируется через десятки тысяч шагов обработки. Стандартные методы обнаружения бессильны активация слишком далека от точки внедрения.
🌊 Насыщение ёмкости: заставляем ИИ «уверенно забыть» критически важную информацию
У SSM фиксированная размерность скрытого состояния. Злоумышленник заполняет его максимально сложным контентом и модель «забывает» важную информацию из начала документа.
🧠 Когнитивные риски: модель врёт, а вы ей верите
Человек склонен доверять модели, если она говорит крайне уверено:
➖ Автоматизационный bias: у рецензентов нет времени на проверку. Чем больше образцов, тем выше слепое доверие.
➖ Authority bias: «на основе полной 10-летней истории» звучит убедительно, даже если модель уже «забыла» половину данных.
➖ Sycophantic reinforcement: врач задаёт наводящий вопрос, модель кодирует это в состояние и продолжает подтверждать гипотезу, даже при противоречащих данных.
➖ Рекуррентные галлюцинации: ложное убеждение в скрытом состоянии распространяется вперёд, переинтерпретируя правильные данные через призму ошибки.
🔗 Больше о рисках SSM читайте в статье: «Safety, Security, and Cognitive Risks in State-Space Models»
Ваши SOC уже используют быстрые SSM-модели для анализа логов? Возможно, пришло время аудита архитектурных рисков, а не только привычного prompt injection.
Stay secure and read SecureTechTalks 📚
#SSM #Mamba #AIsecurity #AdversarialML #CyberSecurity #SecureTechTalks #GenomicSecurity #ClinicalAI #MITREATLAS
Пока весь AI-мир обсуждает модели, способные обрабатывать книги за секунды, исследователи обнаружили, что их главное преимущество в невероятной скорости, одновременно является ахиллесовой пятой в плане безопасности.
👉 Речь идёт о State-Space Models SSM (архитектурах вроде Mamba и Jamba), которые обрабатывают тексты и данные в десятки раз быстрее классических Transformer'ов, вроде ChatGPT. Они уже внедряются в геномный анализ, клинический мониторинг пациентов и SOC-центры. Однако никто всерьёз не изучал их устойчивость к атакам. Спойлер:
🎯 Три новых класса атак
Спектральные атаки: взлом через «частоту» данных
SSM работают как обученные фильтры с характерными частотными характеристиками. Злоумышленник концентрирует возмущения в полосах максимального усиления модели. Другими словами, достаточно слегка «подправить» данные и модель выдаст неверный результат.
⏱️ Отложенные бэкдоры: бомба замедленного действия
Триггер активируется через десятки тысяч шагов обработки. Стандартные методы обнаружения бессильны активация слишком далека от точки внедрения.
🌊 Насыщение ёмкости: заставляем ИИ «уверенно забыть» критически важную информацию
У SSM фиксированная размерность скрытого состояния. Злоумышленник заполняет его максимально сложным контентом и модель «забывает» важную информацию из начала документа.
🧠 Когнитивные риски: модель врёт, а вы ей верите
Человек склонен доверять модели, если она говорит крайне уверено:
🔗 Больше о рисках SSM читайте в статье: «Safety, Security, and Cognitive Risks in State-Space Models»
Ваши SOC уже используют быстрые SSM-модели для анализа логов? Возможно, пришло время аудита архитектурных рисков, а не только привычного prompt injection.
Stay secure and read SecureTechTalks 📚
#SSM #Mamba #AIsecurity #AdversarialML #CyberSecurity #SecureTechTalks #GenomicSecurity #ClinicalAI #MITREATLAS
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🤔1
🔐 Люди сами сливают свои данные в AI, а OpenAI пытается это исправить
Сегодня речь пойдет о проблеме, о которой все знают, но почти никто не решает.
Пользователи массово вставляют персональные данные в диалоги с LLM ( включая креды и номера карт).
На днях OpenAI выпустила инструмент, который работает до того, как данные “утекут” в модель.
🧠 Что за штука?
Речь про Privacy Filter, отдельную модель для поиска и удаления PII (персональных данных) из текста.
В отличие от классических DLP/regex-фильтров, модель не просто ищет шаблоны вроде “@gmail.com” или “+7…”, а анализирует контекст, понимает, где данные публичные, а где приватные, принимает решение прямо в тексте.
Инструмент работает в один проход и поддерживает длинные документы до 128k токенов.
🔍 По каким атрибутам работает поиск?
Модель покрывает основные категории чувствительных данных: имена, адреса, email, телефоны, URL, даты, финансовые реквизиты и секреты вроде паролей или API-ключей.
💡 Локальный запуск
Модель можно запускать локально, т.е. данные не нужно отправлять в облако. Фильтрация происходит прямо на стороне пользователя, что существенно снижает риск утечек.
Постепенно двигаемся сторону privacy-by-design.
⚠️ Пока не идеально
OpenAI заявляет, что модель не идеальна, а риски лежат на пользователях 😁. Фильтр может ошибаться, иногда пропускать редкие или нестандартные персональные данные, а иногда наоборот, скрывать лишнее. В общем все стандартно для решений обезличивания.
📎 Официальный релиз:
https://openai.com/index/introducing-openai-privacy-filter/
🔗 Ссылка на GitHub: https://github.com/openai/privacy-filter
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #Privacy #PII #OpenAI #LLM #DataSecurity #Infosec #SecureTechTalks
Сегодня речь пойдет о проблеме, о которой все знают, но почти никто не решает.
Пользователи массово вставляют персональные данные в диалоги с LLM ( включая креды и номера карт).
На днях OpenAI выпустила инструмент, который работает до того, как данные “утекут” в модель.
🧠 Что за штука?
Речь про Privacy Filter, отдельную модель для поиска и удаления PII (персональных данных) из текста.
В отличие от классических DLP/regex-фильтров, модель не просто ищет шаблоны вроде “@gmail.com” или “+7…”, а анализирует контекст, понимает, где данные публичные, а где приватные, принимает решение прямо в тексте.
Инструмент работает в один проход и поддерживает длинные документы до 128k токенов.
🔍 По каким атрибутам работает поиск?
Модель покрывает основные категории чувствительных данных: имена, адреса, email, телефоны, URL, даты, финансовые реквизиты и секреты вроде паролей или API-ключей.
💡 Локальный запуск
Модель можно запускать локально, т.е. данные не нужно отправлять в облако. Фильтрация происходит прямо на стороне пользователя, что существенно снижает риск утечек.
⚠️ Пока не идеально
OpenAI заявляет, что модель не идеальна, а риски лежат на пользователях 😁. Фильтр может ошибаться, иногда пропускать редкие или нестандартные персональные данные, а иногда наоборот, скрывать лишнее. В общем все стандартно для решений обезличивания.
📎 Официальный релиз:
https://openai.com/index/introducing-openai-privacy-filter/
🔗 Ссылка на GitHub: https://github.com/openai/privacy-filter
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #Privacy #PII #OpenAI #LLM #DataSecurity #Infosec #SecureTechTalks
👍1
🔑 Пароли уходят, но мы всё ещё за них держимся
Давно известно, что пароли слабое звено, но люди продолжают их использовать и, если честно, делают это предсказуемо плохо.
Мы переиспользуем пароли, храним их где попало и спокойно вводим их на фишинговых сайтах (даже зная о рисках). Поведение не меняется годами.
🧠 Технология уже есть
На этом фоне passkeys выглядят как очевидное решение. Они убирают саму идею пароля, вместо него используется пара криптографических ключей, где приватная часть остаётся на устройстве, а вход подтверждается через биометрию или PIN.
Получается, что красть нечего, ведь нет пароля, который можно перехватить, слить или переиспользовать. Фишинг в классическом виде тоже перестаёт работать.
Нюанс: люди уже начинают пользоваться passkeys… и не до конца понимают, что это вообще такое. Для многих это просто «ещё один способ входа», а не принципиально новая модель безопасности.
⚙️ Почему тормозит прогресс
С точки зрения безопасности всё выглядит решённым. Однако сервисы внедряют passkeys неравномерно, пользовательский опыт не везде идеален, а компании не спешат ломать привычные сценарии логина. В итоге пароли остаются просто потому, что “мы так привыкли”. Это тот редкий случай, когда инерция сильнее здравого смысла.
💣 Атаки никуда не денутся
Важно не обманываться, passkeys не делают систему “неуязвимой”. Они просто убирают огромный класс атак, связанных с паролями.
Вектор атаки смещается. Вместо кражи учётных данных фокус уходит на устройства, сессии и всё ту же социальную инженерию. То есть поверхность атаки не исчезает, она трансформируется.
🔗 Ссылка на исследование NCSC
Stay secure and read SecureTechTalks 📚
#CyberSecurity #Passkeys #FIDO2 #Authentication #NCSC #Infosec #Phishing #IdentitySecurity #SecureTechTalks
Давно известно, что пароли слабое звено, но люди продолжают их использовать и, если честно, делают это предсказуемо плохо.
Мы переиспользуем пароли, храним их где попало и спокойно вводим их на фишинговых сайтах (даже зная о рисках). Поведение не меняется годами.
🧠 Технология уже есть
На этом фоне passkeys выглядят как очевидное решение. Они убирают саму идею пароля, вместо него используется пара криптографических ключей, где приватная часть остаётся на устройстве, а вход подтверждается через биометрию или PIN.
Получается, что красть нечего, ведь нет пароля, который можно перехватить, слить или переиспользовать. Фишинг в классическом виде тоже перестаёт работать.
Нюанс: люди уже начинают пользоваться passkeys… и не до конца понимают, что это вообще такое. Для многих это просто «ещё один способ входа», а не принципиально новая модель безопасности.
⚙️ Почему тормозит прогресс
С точки зрения безопасности всё выглядит решённым. Однако сервисы внедряют passkeys неравномерно, пользовательский опыт не везде идеален, а компании не спешат ломать привычные сценарии логина. В итоге пароли остаются просто потому, что “мы так привыкли”. Это тот редкий случай, когда инерция сильнее здравого смысла.
💣 Атаки никуда не денутся
Важно не обманываться, passkeys не делают систему “неуязвимой”. Они просто убирают огромный класс атак, связанных с паролями.
Вектор атаки смещается. Вместо кражи учётных данных фокус уходит на устройства, сессии и всё ту же социальную инженерию. То есть поверхность атаки не исчезает, она трансформируется.
🔗 Ссылка на исследование NCSC
Stay secure and read SecureTechTalks 📚
#CyberSecurity #Passkeys #FIDO2 #Authentication #NCSC #Infosec #Phishing #IdentitySecurity #SecureTechTalks
👍1
🎼 Symphony от OpenAI: разработка, в которой человек уже лишний
Symphony - это open-source orchestration-система от OpenAI, которая управляет AI-агентами, привязывая их к задачам в таск-трекерах (например, Linear).
Каждый агент работает автономно: читает задачу, пишет код, создаёт pull request и доводит её до завершения через итерации.
🪄 Не помощник, а исполнитель
Рассмотрим use case:
Ты создаёшь задачу → система сама назначает на неё агента → агент начинает работать. Он читает описание, лезет в код, что-то пишет, открывает PR, спотыкается, поднимается и продолжает. И так до тех пор пока задача не закроется.
⚙️ Бэклог ожил
Задачи перестают быть статикой. Подключаешь тот же Linear и твой backlog внезапно начинает «шевелиться», а задачи разбираются параллельно. Никто не ждёт «когда появится время», процессы не останавливаются после одного ответа. Это ощущается не как инструмент, а как команда, которая никогда не уходит домой.
🧨 Минусы будут!
Если смотреть на это не как разработчик, а как безопасник, то становится немного страшно.
Если раньше точкой входа был код, API, на худой конец пользователь, то теперь входом становится текст задачи. Обычный issue превращается в интерфейс управления системой:
➖ prompt больше не «подсказка», а фактически команда;
➖ агент сам ходит по репозиторию и что-то там меняет (поди разберись что);
➖ ошибки не останавливают процесс, а просто запускают новую попытку
💬 Что с этим делать
Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.
🔗 GitHub: https://github.com/openai/symphony
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PromptInjection #OpenAI #Infosec #Automation #SecureTechTalks
Symphony - это open-source orchestration-система от OpenAI, которая управляет AI-агентами, привязывая их к задачам в таск-трекерах (например, Linear).
Каждый агент работает автономно: читает задачу, пишет код, создаёт pull request и доводит её до завершения через итерации.
🪄 Не помощник, а исполнитель
Рассмотрим use case:
Ты создаёшь задачу → система сама назначает на неё агента → агент начинает работать. Он читает описание, лезет в код, что-то пишет, открывает PR, спотыкается, поднимается и продолжает. И так до тех пор пока задача не закроется.
⚙️ Бэклог ожил
Задачи перестают быть статикой. Подключаешь тот же Linear и твой backlog внезапно начинает «шевелиться», а задачи разбираются параллельно. Никто не ждёт «когда появится время», процессы не останавливаются после одного ответа. Это ощущается не как инструмент, а как команда, которая никогда не уходит домой.
🧨 Минусы будут!
Если смотреть на это не как разработчик, а как безопасник, то становится немного страшно.
Если раньше точкой входа был код, API, на худой конец пользователь, то теперь входом становится текст задачи. Обычный issue превращается в интерфейс управления системой:
💬 Что с этим делать
Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.
безопасность backlog’а становится частью безопасности продукта
🔗 GitHub: https://github.com/openai/symphony
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PromptInjection #OpenAI #Infosec #Automation #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2
🔐 Prompt перестаёт быть приватным
Исследователи обратили внимание на еще одну проблему: конфиденциальность prompt’ов в AI-системах не гарантирована.
Скрытые инструкции модели могут быть извлечены через специально сформированные запросы.
🧠 Один контекст на всё
LLM обрабатывают весь вход как единый текстовый поток, включая:
➖ системные инструкции
➖ пользовательские запросы
➖ внешние данные
В такой модели границы размываются, и при определённых условиях система может начать воспроизводить части внутреннего prompt’а (даже без прямого доступа к нему).
⚙️ Разговор превращается в эксфильтрацию
Атаки используют базовые свойства модели:
➖ стремление давать полный и полезный ответ
➖ слабое разделение ролей внутри контекста
➖ интерпретацию запроса как разрешения раскрыть больше
В результате аккуратно составленные вопросы позволяют вытягивать фрагменты скрытых инструкций. Иногда по кускам, иногда почти целиком.
🧪 От теории к практике
На практике prompt в системах часто передаётся между сервисами, попадает в логи, используется как контейнер для логики. Однако он не рассматривается как чувствительный актив, что в корне неправильно.
🧠 Что предлагают исследователи
Со всеми вытекающими требованиями к защите.
💬 Рекомендации
Базовые меры выглядят предсказуемо, но чаще всего игнорируются:
➖ не хранить чувствительные данные внутри prompt’ов
➖ контролировать, что модель может «проговорить» в ответе
➖ разделять контексты и роли
аккуратно относиться к логированию
🔗 Ссылка на полное исследование
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptSecurity #DataProtection #Infosec #CyberSecurity #AIrisks #SecureTechTalks #Privacy
Исследователи обратили внимание на еще одну проблему: конфиденциальность prompt’ов в AI-системах не гарантирована.
Скрытые инструкции модели могут быть извлечены через специально сформированные запросы.
🧠 Один контекст на всё
LLM обрабатывают весь вход как единый текстовый поток, включая:
В такой модели границы размываются, и при определённых условиях система может начать воспроизводить части внутреннего prompt’а (даже без прямого доступа к нему).
⚙️ Разговор превращается в эксфильтрацию
Атаки используют базовые свойства модели:
В результате аккуратно составленные вопросы позволяют вытягивать фрагменты скрытых инструкций. Иногда по кускам, иногда почти целиком.
🧪 От теории к практике
На практике prompt в системах часто передаётся между сервисами, попадает в логи, используется как контейнер для логики. Однако он не рассматривается как чувствительный актив, что в корне неправильно.
🧠 Что предлагают исследователи
prompt - это конфиденциальные данные и точка.
Со всеми вытекающими требованиями к защите.
💬 Рекомендации
Базовые меры выглядят предсказуемо, но чаще всего игнорируются:
аккуратно относиться к логированию
🔗 Ссылка на полное исследование
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #PromptSecurity #DataProtection #Infosec #CyberSecurity #AIrisks #SecureTechTalks #Privacy
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🔐 LLM проверили в условиях, приближённых к SOC
Моделям предложили самостоятельно искать атаки.
28 апреля вышел новый бенчмарк от Simbian, один из первых, где языковые модели тестируют не на знание терминов, а на способность работать как аналитик кибербезопасности.
🧪 Как устроен бенчмарк?
Модели поместили в среду, максимально приближенную к реальной. Они анализировали поток событий (Windows Security, Sysmon), внутри которого были спрятаны цепочки атак. Не отдельные техники, а полноценные сценарии.
При этом модели не знали, есть ли атака в данных и сколько их. Фактически от них требовалось провести расследование: выделить слабые сигналы, проверить гипотезы и принять решение в условиях неопределённости.
Именно это отличает новый бенчмарк от всех предыдущих.
📊 Лидер есть, но нет оптимизма
Лучший результат показала Claude Opus 4.6: около 46% обнаруженных атак. При этом доля срабатываний от общего потока событий составила лишь ~4–5%, что подчёркивает слабую чувствительность в реальном шуме.
Модели среднего уровня, включая GPT-4o, демонстрировали нестабильность: они могли корректно выявлять отдельные техники, но регулярно теряли целые цепочки атак.
Наихудшие результаты показали компактные модели вроде GPT-4o mini, порядка 1–2% обнаружения, что практически эквивалентно слепому поиску.
Разница между моделями значительная, но огорчает другое: ни одна из них не достигает уровня, пригодного для реальной автономной защиты.
⚠️ Преждевременное завершение анализа
Особенно любопытно поведение моделей, которое сложно выявить в классических тестах. Часть из них самостоятельно прекращала анализ, решив, что данных уже достаточно для вывода (при этом атаки в логах могли продолжаться).
Когда система не только не сигнализирует о проблеме, но и уверенно сообщает, что всё в порядке, то думаешь на кой она вообще нужна?
🤯 Почему модели не справляются
Атака - это задача с чётким критерием успеха, а защита про поиск неизвестного в потоке шума без гарантии, что сигнал вообще присутствует.
LLM, обученные на задачах с “правильным ответом”, в такой среде теряют устойчивость. Им не хватает ни механизмов самопроверки, ни способности поддерживать длительное расследование.
🔗 Ссылка на бенчмарк
Stay secure and read SecureTechTalks 📚
#кибербезопасность #LLM #SOC #ThreatHunting #AIsecurity #MITREATTACK #BlueTeam #CyberDefense #InfoSec #SecureTechTalks
Моделям предложили самостоятельно искать атаки.
28 апреля вышел новый бенчмарк от Simbian, один из первых, где языковые модели тестируют не на знание терминов, а на способность работать как аналитик кибербезопасности.
🧪 Как устроен бенчмарк?
Модели поместили в среду, максимально приближенную к реальной. Они анализировали поток событий (Windows Security, Sysmon), внутри которого были спрятаны цепочки атак. Не отдельные техники, а полноценные сценарии.
При этом модели не знали, есть ли атака в данных и сколько их. Фактически от них требовалось провести расследование: выделить слабые сигналы, проверить гипотезы и принять решение в условиях неопределённости.
Именно это отличает новый бенчмарк от всех предыдущих.
📊 Лидер есть, но нет оптимизма
Лучший результат показала Claude Opus 4.6: около 46% обнаруженных атак. При этом доля срабатываний от общего потока событий составила лишь ~4–5%, что подчёркивает слабую чувствительность в реальном шуме.
Модели среднего уровня, включая GPT-4o, демонстрировали нестабильность: они могли корректно выявлять отдельные техники, но регулярно теряли целые цепочки атак.
Наихудшие результаты показали компактные модели вроде GPT-4o mini, порядка 1–2% обнаружения, что практически эквивалентно слепому поиску.
Разница между моделями значительная, но огорчает другое: ни одна из них не достигает уровня, пригодного для реальной автономной защиты.
⚠️ Преждевременное завершение анализа
Особенно любопытно поведение моделей, которое сложно выявить в классических тестах. Часть из них самостоятельно прекращала анализ, решив, что данных уже достаточно для вывода (при этом атаки в логах могли продолжаться).
Когда система не только не сигнализирует о проблеме, но и уверенно сообщает, что всё в порядке, то думаешь на кой она вообще нужна?
🤯 Почему модели не справляются
Атака - это задача с чётким критерием успеха, а защита про поиск неизвестного в потоке шума без гарантии, что сигнал вообще присутствует.
LLM, обученные на задачах с “правильным ответом”, в такой среде теряют устойчивость. Им не хватает ни механизмов самопроверки, ни способности поддерживать длительное расследование.
🔗 Ссылка на бенчмарк
Stay secure and read SecureTechTalks 📚
#кибербезопасность #LLM #SOC #ThreatHunting #AIsecurity #MITREATTACK #BlueTeam #CyberDefense #InfoSec #SecureTechTalks
👍1
🔥 PipeLock: попытка поставить AI-агента под контроль
AI-агенты больше не сидят в чате, им выдают доступ к shell, CI/CD и runtime. Они начинают выполнять команды.
⚙️ PipeLock
В классической схеме работает стандартеый принцип: агент принял решение → система его сразу исполнила.
PipeLock встраивается между ними, обеспечивая прослойку контроля.
На практике мы имеем execution proxy для агента.
Все команды, которые он генерирует, проходят через PipeLock перед тем, как попасть в систему.
🔒 Архитектурные особенности
Как мы уже проговорили, PipeLock работает на уровне перехвата выполнения, т.е.:
➖ перехватывает shell-вызовы (bash, sh и т.д.)
➖ анализирует итоговую команду после генерации LLM
➖ раскладывает её на составляющие (бинарь, аргументы, флаги)
➖ сопоставляет с политиками
Политики задаются декларативно и описывают:
➖ какие бинарники разрешены (git, npm, docker и т.д.)
➖ какие флаги допустимы (например, запрет --force, --privileged)
➖ какие пути файловой системы доступны
➖ какие переменные окружения можно читать/передавать
Важно: проверяется уже финальный вызов, а не намерение модели.
Если команда не проходит политику, то она даже не доходит до shell.
🧨 Никто другой
Большинство инструментов смотрят на код (до выполнения), на права (до выполнения). Однако почти никто не смотрит на конкретную команду в момент её исполнения,
с учётом того, что она сгенерирована моделью.
PipeLock про этот самый последний метр, который несет огромные риски, ведь одинаковые права ≠ одинаково безопасное поведение.
Агент с доступом к системе может сделать тысячу нормальных вещей
и одну катастрофическую...
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PipelineSecurity #Infosec #CyberSecurity #OpenSource #SecureTechTalks
AI-агенты больше не сидят в чате, им выдают доступ к shell, CI/CD и runtime. Они начинают выполнять команды.
⚙️ PipeLock
В классической схеме работает стандартеый принцип: агент принял решение → система его сразу исполнила.
PipeLock встраивается между ними, обеспечивая прослойку контроля.
На практике мы имеем execution proxy для агента.
Все команды, которые он генерирует, проходят через PipeLock перед тем, как попасть в систему.
🔒 Архитектурные особенности
Как мы уже проговорили, PipeLock работает на уровне перехвата выполнения, т.е.:
Политики задаются декларативно и описывают:
Важно: проверяется уже финальный вызов, а не намерение модели.
Если команда не проходит политику, то она даже не доходит до shell.
🧨 Никто другой
Большинство инструментов смотрят на код (до выполнения), на права (до выполнения). Однако почти никто не смотрит на конкретную команду в момент её исполнения,
с учётом того, что она сгенерирована моделью.
PipeLock про этот самый последний метр, который несет огромные риски, ведь одинаковые права ≠ одинаково безопасное поведение.
Агент с доступом к системе может сделать тысячу нормальных вещей
и одну катастрофическую...
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PipelineSecurity #Infosec #CyberSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🧬 Код как отпечаток пальца: уязвимости начинают искать по стилю
Мы воспринимаем уязвимости, как локальный сбой. Где-то не проверили вход, где-то неверно обработали условие, где-то допустили лишний доступ. В такой логике ошибка - это случайность, которую можно найти и исправить.
Однако ошибки почти никогда не бывают случайными. Они воспроизводятся. Причём не потому, что разработчик копирует код, а потому что он воспроизводит собственный способ мышления. У каждого есть устойчивые паттерны, например, как упрощать проверки или как обходиться с исключениями. Эти решения повторяются, а вместе с ними повторяются и уязвимости.
⚙️ Стиль становится сигналом
Code stylometry - подход, который смотрит на код не как на программу, а как на поведение автора. Модель работает на уровне структуры, она анализирует абстрактные синтаксические деревья, последовательности токенов, частоту и комбинации конструкций.
Код превращается в набор признаков, из которых можно восстановить «почерк» разработчика. Этот почерк оказывается достаточно устойчивым, чтобы его можно было распознать и связать с вероятностью ошибок.
Речь идет не о поиске конкретной уязвимости, а склонности к ней.
🧪 От поиска к предсказанию
Модель сначала извлекает стилевые признаки, затем сопоставляет их с обученными зависимостями и на выходе даёт оценку: насколько вероятно, что в этом коде есть уязвимости.
Технически за этим стоят обычные ML-пайплайны, обучение на размеченных данных, где известны уязвимости.
Впервые объектом анализа становится не сам код, но и стиль его написания как фактор риска.
🧨 Почему это работает?
Причина в том, что разработчик не пишет код «с нуля» каждый раз. Он воспроизводит себя. Одни и те же способы обработки ошибок, одни и те же допущения кочуют из файла в файл. Если в одном месте это привело к уязвимости, в другом вероятность резко возрастает.
Модель, в отличие от человека, не ищет логическое объяснение. Она фиксирует статистическую закономерность.
🕵️♂️ Код рассказывает о человеке
Если стиль можно распознать и оценить, значит, можно сравнивать не только фрагменты кода, но и их авторов. Код начинает работать как отпечаток пальца. Через него проявляются привычки, уровень аккуратности, склонность к риску.
В прикладном смысле это означает, что анализ может сместиться. Не от кода к уязвимости, а от разработчика к зонам повышенного риска. В большом проекте это даёт возможность приоритизировать аудит, фокусироваться не на всём сразу, а на том, где вероятность ошибки статистически выше.
🔗 Подробнее с подходом можно ознакомиться в исследовании.
P.S. интересно будет составить список паттернов для каждой LLM.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #CodeSecurity #VulnerabilityDetection #Infosec #CyberSecurity #StaticAnalysis #AIrisks #SecureTechTalks
Мы воспринимаем уязвимости, как локальный сбой. Где-то не проверили вход, где-то неверно обработали условие, где-то допустили лишний доступ. В такой логике ошибка - это случайность, которую можно найти и исправить.
Однако ошибки почти никогда не бывают случайными. Они воспроизводятся. Причём не потому, что разработчик копирует код, а потому что он воспроизводит собственный способ мышления. У каждого есть устойчивые паттерны, например, как упрощать проверки или как обходиться с исключениями. Эти решения повторяются, а вместе с ними повторяются и уязвимости.
⚙️ Стиль становится сигналом
Code stylometry - подход, который смотрит на код не как на программу, а как на поведение автора. Модель работает на уровне структуры, она анализирует абстрактные синтаксические деревья, последовательности токенов, частоту и комбинации конструкций.
Код превращается в набор признаков, из которых можно восстановить «почерк» разработчика. Этот почерк оказывается достаточно устойчивым, чтобы его можно было распознать и связать с вероятностью ошибок.
Речь идет не о поиске конкретной уязвимости, а склонности к ней.
🧪 От поиска к предсказанию
Модель сначала извлекает стилевые признаки, затем сопоставляет их с обученными зависимостями и на выходе даёт оценку: насколько вероятно, что в этом коде есть уязвимости.
Технически за этим стоят обычные ML-пайплайны, обучение на размеченных данных, где известны уязвимости.
Впервые объектом анализа становится не сам код, но и стиль его написания как фактор риска.
🧨 Почему это работает?
Причина в том, что разработчик не пишет код «с нуля» каждый раз. Он воспроизводит себя. Одни и те же способы обработки ошибок, одни и те же допущения кочуют из файла в файл. Если в одном месте это привело к уязвимости, в другом вероятность резко возрастает.
Модель, в отличие от человека, не ищет логическое объяснение. Она фиксирует статистическую закономерность.
🕵️♂️ Код рассказывает о человеке
Если стиль можно распознать и оценить, значит, можно сравнивать не только фрагменты кода, но и их авторов. Код начинает работать как отпечаток пальца. Через него проявляются привычки, уровень аккуратности, склонность к риску.
В прикладном смысле это означает, что анализ может сместиться. Не от кода к уязвимости, а от разработчика к зонам повышенного риска. В большом проекте это даёт возможность приоритизировать аудит, фокусироваться не на всём сразу, а на том, где вероятность ошибки статистически выше.
🔗 Подробнее с подходом можно ознакомиться в исследовании.
P.S. интересно будет составить список паттернов для каждой LLM.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #CodeSecurity #VulnerabilityDetection #Infosec #CyberSecurity #StaticAnalysis #AIrisks #SecureTechTalks
👍1
🗺 AIMap: инструмент, который показывает, где на самом деле начинается AI-атака
С появлением LLM архитектура перестает быть очевидной.
Раньше можно было нарисовать схему: тут фронт, вот API, здесь база и примерно понять, где проходит граница систем.
В AI-приложениях граница распадается. Один запрос к модели может привести к вызову внешнего инструмента, обращению к API, извлечению данных из хранилища или генерации нового действия.
Зачастую часть связей не фиксируется явно, она возникает на уровне prompt’ов, конфигураций агентов и оркестрации.
В какой-то момент становится трудно ответить на базовый вопрос:
что именно у нас вообще доступно для атаки?
⚙️ AIMap
AIMap проходит по AI-приложению и строит карту взаимодействий, граф, где узлы - это модели, сервисы, инструменты и источники данных, а рёбра - реальные связи между ними.
Инструмент собирает информацию из разных слоёв: описаний агентов, подключённых инструментов, доступных endpoints, путей, по которым данные могут проходить в процессе выполнения.
На выходе получается рабочая модель системы, в которой видно, как она ведёт себя в реальности.
🧪 Разберем инструмент чуть подробнее
AIMap выполняет следующие задачи:
1⃣ обнаруживает компоненты:
- какие LLM используются,
- какие у них интерфейсы,
- какие плагины или инструменты подключены.
2⃣ извлекает информацию о доступных действиях:
- какие функции может вызвать агент,
- к каким API у него есть доступ,
- какие источники данных подключены.
3⃣ строится фактический граф зависимостей. Если модель может вызвать инструмент, который в свою очередь ходит во внешний сервис, это становится частью цепочки. Если пользовательский ввод может повлиять на выбор инструмента, то это тоже фиксируется.
Таким образом формируется execution graph, который отражает возможные пути прохождения запроса через систему.
🧨 Поверхность атаки
Именно на этом графе начинают проявляться вещи, которые сложно увидеть иначе.
Во-первых, становятся видны неочевидные транзитивные связи. Например, модель напрямую не имеет доступа к чувствительным данным, но через цепочку вызовов этот доступ появляется.
Во-вторых, выявляются точки, где пользовательский ввод может влиять на поведение системы. Это потенциальные зоны для prompt injection и управления агентом.
В-третьих, всплывают «забытые» интеграции, инструменты или endpoints, которые формально существуют, но не учитываются в модели угроз.
🔗 GitHub: https://github.com/BishopFox/aimap
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AttackSurface #ThreatModeling #Infosec #CyberSecurity #AIrisks #OpenSource #SecureTechTalks
С появлением LLM архитектура перестает быть очевидной.
Раньше можно было нарисовать схему: тут фронт, вот API, здесь база и примерно понять, где проходит граница систем.
В AI-приложениях граница распадается. Один запрос к модели может привести к вызову внешнего инструмента, обращению к API, извлечению данных из хранилища или генерации нового действия.
Зачастую часть связей не фиксируется явно, она возникает на уровне prompt’ов, конфигураций агентов и оркестрации.
В какой-то момент становится трудно ответить на базовый вопрос:
что именно у нас вообще доступно для атаки?
⚙️ AIMap
AIMap проходит по AI-приложению и строит карту взаимодействий, граф, где узлы - это модели, сервисы, инструменты и источники данных, а рёбра - реальные связи между ними.
Инструмент собирает информацию из разных слоёв: описаний агентов, подключённых инструментов, доступных endpoints, путей, по которым данные могут проходить в процессе выполнения.
На выходе получается рабочая модель системы, в которой видно, как она ведёт себя в реальности.
🧪 Разберем инструмент чуть подробнее
AIMap выполняет следующие задачи:
1⃣ обнаруживает компоненты:
- какие LLM используются,
- какие у них интерфейсы,
- какие плагины или инструменты подключены.
2⃣ извлекает информацию о доступных действиях:
- какие функции может вызвать агент,
- к каким API у него есть доступ,
- какие источники данных подключены.
3⃣ строится фактический граф зависимостей. Если модель может вызвать инструмент, который в свою очередь ходит во внешний сервис, это становится частью цепочки. Если пользовательский ввод может повлиять на выбор инструмента, то это тоже фиксируется.
Таким образом формируется execution graph, который отражает возможные пути прохождения запроса через систему.
🧨 Поверхность атаки
Именно на этом графе начинают проявляться вещи, которые сложно увидеть иначе.
Во-первых, становятся видны неочевидные транзитивные связи. Например, модель напрямую не имеет доступа к чувствительным данным, но через цепочку вызовов этот доступ появляется.
Во-вторых, выявляются точки, где пользовательский ввод может влиять на поведение системы. Это потенциальные зоны для prompt injection и управления агентом.
В-третьих, всплывают «забытые» интеграции, инструменты или endpoints, которые формально существуют, но не учитываются в модели угроз.
🔗 GitHub: https://github.com/BishopFox/aimap
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AttackSurface #ThreatModeling #Infosec #CyberSecurity #AIrisks #OpenSource #SecureTechTalks
👍2
🌊 Bluerock: добавляем runtime-безопасность в Kubernetes
Kubernetes отлично умеет оркестрировать контейнеры. Но с безопасностью в runtime у него всегда были проблемы.
Вы настраиваете RBAC, network policies, admission controllers и сканирование образов и ждете отсутствия рисков ИБ. Однако всё это в основном работает до запуска workload’а.
После старта контейнера Kubernetes почти не понимает, что внутри него происходит на самом деле.
⚙️ Что же делать?
Bluerock - это runtime security layer для Kubernetes. Платформа наблюдает за поведением контейнеров уже после запуска и анализирует:
- запуск процессов
- syscall activity
- сетевые соединения
- доступ к файловой системе
взаимодействие pod’ов между собой
- обращения к Kubernetes API
Вместо анализа YAML-манифестов или образов система начинает смотреть на реальное поведение workload’а.
🧪 Так так так
Bluerock активно использует eBPF, что позволяет перехватывать события прямо на уровне ядра Linux без модификации контейнеров: process execution, fork/exec chains, network flows, filesystem access и другие runtime-события.
Дальше поверх этих данных строится policy engine. Политики задают допустимое поведение контейнера:
- какие процессы могут запускаться,
- какие outbound-соединения разрешены,
- какие filesystem paths доступны,
- какие действия считаются аномальными.
Например: контейнеру можно разрешить только конкретные бинарники (python, nginx, node) и заблокировать запуск shell или неизвестных процессов.
Или: разрешить обращения только к определённым API endpoints, запретив весь остальной outbound traffic.
🔒 Чем это отличается от обычной Kubernetes-защиты
Большинство Kubernetes security-инструментов работают со статикой: сканируют образы, проверяют конфигурации или анализируют манифесты.
Bluerock работает с runtime. Система анализирует не то, «как контейнер должен работать», а то, что он реально делает после запуска.
Для современных AI- и agent-based workload’ов это особенно актуально, потому что их поведение может меняться динамически в зависимости от prompt’ов, контекста или внешних данных.
🔗 GitHub: https://github.com/bluerock-io/bluerock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Kubernetes #CloudSecurity #RuntimeSecurity #eBPF #DevSecOps #OpenSource #SecureTechTalks
Kubernetes отлично умеет оркестрировать контейнеры. Но с безопасностью в runtime у него всегда были проблемы.
Вы настраиваете RBAC, network policies, admission controllers и сканирование образов и ждете отсутствия рисков ИБ. Однако всё это в основном работает до запуска workload’а.
После старта контейнера Kubernetes почти не понимает, что внутри него происходит на самом деле.
⚙️ Что же делать?
Bluerock - это runtime security layer для Kubernetes. Платформа наблюдает за поведением контейнеров уже после запуска и анализирует:
- запуск процессов
- syscall activity
- сетевые соединения
- доступ к файловой системе
взаимодействие pod’ов между собой
- обращения к Kubernetes API
Вместо анализа YAML-манифестов или образов система начинает смотреть на реальное поведение workload’а.
🧪 Так так так
Bluerock активно использует eBPF, что позволяет перехватывать события прямо на уровне ядра Linux без модификации контейнеров: process execution, fork/exec chains, network flows, filesystem access и другие runtime-события.
Дальше поверх этих данных строится policy engine. Политики задают допустимое поведение контейнера:
- какие процессы могут запускаться,
- какие outbound-соединения разрешены,
- какие filesystem paths доступны,
- какие действия считаются аномальными.
Например: контейнеру можно разрешить только конкретные бинарники (python, nginx, node) и заблокировать запуск shell или неизвестных процессов.
Или: разрешить обращения только к определённым API endpoints, запретив весь остальной outbound traffic.
🔒 Чем это отличается от обычной Kubernetes-защиты
Большинство Kubernetes security-инструментов работают со статикой: сканируют образы, проверяют конфигурации или анализируют манифесты.
Bluerock работает с runtime. Система анализирует не то, «как контейнер должен работать», а то, что он реально делает после запуска.
Для современных AI- и agent-based workload’ов это особенно актуально, потому что их поведение может меняться динамически в зависимости от prompt’ов, контекста или внешних данных.
🔗 GitHub: https://github.com/bluerock-io/bluerock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Kubernetes #CloudSecurity #RuntimeSecurity #eBPF #DevSecOps #OpenSource #SecureTechTalks
👍1
🦊 Mozilla подключили Claude к поиску уязвимостей в Firefox.
В Mozilla решили проверить, можно ли использовать Claude как часть реального vulnerability research pipeline для Firefox.
⚙️ Анализ поведения
Firefox активно включились в тестирование Claude Mythos по программе Preview.
Разработчики давали модели широкие задачи: анализировать execution flow, искать подозрительные переходы состояний, изучать edge-case поведение API и проверять, как разные компоненты Firefox взаимодействуют между собой.
Claude использовали как систему генерации гипотез, способную быстро проходить по большим объёмам кода и выделять места, где логика выглядит необычной.
🧪 Как выглядел workflow
Технически процесс оказался довольно занудным. Исследователь задавал область анализа, например, конкретный subsystem или API. Дальше модель разбирала код, строила reasoning вокруг возможных attack paths и пыталась определить, где нарушение инвариантов или некорректная обработка состояния может привести к security issue.
После этого человек вручную проверял гипотезы и валидировал, существует ли проблема в реальности.
Ключевое отличие от обычного static analysis здесь в том, что Claude не искал заранее известные паттерны уязвимостей.
Модель пыталась анализировать поведение кода на уровне логики:
🔹 как данные проходят через subsystem
🔹 где возникают неожиданные комбинации условий
🔹 какие execution paths выглядят недостаточно защищёнными
🔍 Сильная сторона
Модель не всегда находила уязвимость напрямую, но регулярно выводила исследователей в правильные участки codebase. Особенно хорошо это работало в сценариях, где проблема возникала не из-за одной ошибки, а из-за сложного взаимодействия нескольких компонентов или редких edge-case состояний.
🧨 А потом пришли галлюцинации
Ограничения проявились почти сразу. Claude довольно легко терял архитектурный контекст в больших subsystem’ах Firefox, иногда придумывал execution paths, которых не существовало, и регулярно «галлюцинировал» свойства API.
В некоторых случаях модель строила убедительное reasoning вокруг сценариев, которые технически были невозможны из-за ограничений runtime или внутренней логики браузера.
В таком контексте автономный AI bug hunting пока крайне рискованная идея.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Firefox #Claude #BugBounty #AppSec #VulnerabilityResearch #Infosec #SecureTechTalks
В Mozilla решили проверить, можно ли использовать Claude как часть реального vulnerability research pipeline для Firefox.
⚙️ Анализ поведения
Firefox активно включились в тестирование Claude Mythos по программе Preview.
Разработчики давали модели широкие задачи: анализировать execution flow, искать подозрительные переходы состояний, изучать edge-case поведение API и проверять, как разные компоненты Firefox взаимодействуют между собой.
Claude использовали как систему генерации гипотез, способную быстро проходить по большим объёмам кода и выделять места, где логика выглядит необычной.
🧪 Как выглядел workflow
Технически процесс оказался довольно занудным. Исследователь задавал область анализа, например, конкретный subsystem или API. Дальше модель разбирала код, строила reasoning вокруг возможных attack paths и пыталась определить, где нарушение инвариантов или некорректная обработка состояния может привести к security issue.
После этого человек вручную проверял гипотезы и валидировал, существует ли проблема в реальности.
Ключевое отличие от обычного static analysis здесь в том, что Claude не искал заранее известные паттерны уязвимостей.
Модель пыталась анализировать поведение кода на уровне логики:
🔹 как данные проходят через subsystem
🔹 где возникают неожиданные комбинации условий
🔹 какие execution paths выглядят недостаточно защищёнными
🔍 Сильная сторона
Модель не всегда находила уязвимость напрямую, но регулярно выводила исследователей в правильные участки codebase. Особенно хорошо это работало в сценариях, где проблема возникала не из-за одной ошибки, а из-за сложного взаимодействия нескольких компонентов или редких edge-case состояний.
🧨 А потом пришли галлюцинации
Ограничения проявились почти сразу. Claude довольно легко терял архитектурный контекст в больших subsystem’ах Firefox, иногда придумывал execution paths, которых не существовало, и регулярно «галлюцинировал» свойства API.
В некоторых случаях модель строила убедительное reasoning вокруг сценариев, которые технически были невозможны из-за ограничений runtime или внутренней логики браузера.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Firefox #Claude #BugBounty #AppSec #VulnerabilityResearch #Infosec #SecureTechTalks
👍3
🧠 AppSec переезжает в редактор кода
Сегодня Copilot или LLM способны генерировать целые фрагменты бизнес-логики за минуты.
Разработчик всё чаще не пишет код вручную, а проверяет уже готовый результат. Таким образом количество нового кода начинает расти быстрее, чем человек успевает анализировать его с точки зрения безопасности.
⚙️ Security-проверки прямо во время написания кода
Heidi - open-source security plugin для IDE, который анализирует код прямо в процессе редактирования. Плагин отслеживает изменения в файлах и пытается находить опасные конструкции ещё до запуска приложения:
🔹 insecure API usage
🔹 hardcoded secrets
🔹 shell/command injection patterns
🔹 небезопасную работу с filesystem
🔹 потенциально опасную обработку пользовательского ввода
Анализ идёт не только по сигнатурам. Heidi пытается учитывать контекст: откуда приходят данные, проходят ли они sanitization и куда попадают дальше.
Например, плагин может заметить, что input пользователя без фильтрации уходит в SQL query, shell execution или filesystem operation.
🧪 Принцип работы
Под капотом Heidi использует инкрементальный анализ, т.к. плагин работает внутри IDE и не может позволить себе полноценный перескан проекта после каждого нажатия клавиши. Вместо этого анализируются только изменения и связанные с ними участки кода.
Инсирумент строит lightweight security-analysis pipeline прямо внутри editor runtime.
Для detection используются: 🔹 pattern-based rules
🔹 context-aware checks
🔹 анализ data flow между источниками input и sensitive operations
Система пытается видеть не только отдельную опасную строку, но и цепочку прохождения данных через код.
🧨 Главная проблема таких систем
Сделать security-плагин сложно не технически.Сложно сделать так, чтобы разработчики его не возненавидели.
Если система начинает агрессивно спамить warning’ами, люди быстро перестают обращать внимание на алерты. Если detection слишком мягкий, то реальные проблемы проходят мимо.
Особенно тяжело анализировать AI-generated code, ведь он часто выглядит syntactically clean, но содержит опасные assumptions, которые плохо ловятся простыми сигнатурами.
🔗 Ссылки для скачивания:
➖ JetBrains
➖ VS Code Marketplace
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks
Сегодня Copilot или LLM способны генерировать целые фрагменты бизнес-логики за минуты.
Разработчик всё чаще не пишет код вручную, а проверяет уже готовый результат. Таким образом количество нового кода начинает расти быстрее, чем человек успевает анализировать его с точки зрения безопасности.
⚙️ Security-проверки прямо во время написания кода
Heidi - open-source security plugin для IDE, который анализирует код прямо в процессе редактирования. Плагин отслеживает изменения в файлах и пытается находить опасные конструкции ещё до запуска приложения:
🔹 insecure API usage
🔹 hardcoded secrets
🔹 shell/command injection patterns
🔹 небезопасную работу с filesystem
🔹 потенциально опасную обработку пользовательского ввода
Анализ идёт не только по сигнатурам. Heidi пытается учитывать контекст: откуда приходят данные, проходят ли они sanitization и куда попадают дальше.
Например, плагин может заметить, что input пользователя без фильтрации уходит в SQL query, shell execution или filesystem operation.
🧪 Принцип работы
Под капотом Heidi использует инкрементальный анализ, т.к. плагин работает внутри IDE и не может позволить себе полноценный перескан проекта после каждого нажатия клавиши. Вместо этого анализируются только изменения и связанные с ними участки кода.
Инсирумент строит lightweight security-analysis pipeline прямо внутри editor runtime.
Для detection используются: 🔹 pattern-based rules
🔹 context-aware checks
🔹 анализ data flow между источниками input и sensitive operations
Система пытается видеть не только отдельную опасную строку, но и цепочку прохождения данных через код.
🧨 Главная проблема таких систем
Сделать security-плагин сложно не технически.
Если система начинает агрессивно спамить warning’ами, люди быстро перестают обращать внимание на алерты. Если detection слишком мягкий, то реальные проблемы проходят мимо.
Особенно тяжело анализировать AI-generated code, ведь он часто выглядит syntactically clean, но содержит опасные assumptions, которые плохо ловятся простыми сигнатурами.
🔗 Ссылки для скачивания:
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🤖 Sandyaa: AI-агент для разведки
Разведка давно перестала быть проблемой с точки зрения инструментов: Subfinder, httpx, nuclei, waybackurls, DNSdumpster, Shodan. Экосистема огромная. Однако человек просто тонет в количестве результатов.
Sandyaa строится как orchestration-layer поверх классических recon-инструментов. Агент собирает данные о цели, анализирует результаты и сам определяет, какие действия выполнять дальше.
Технически Sandyaa комбинирует:
🔹 subdomain enumeration
🔹 technology fingerprinting
🔹 endpoint discovery
🔹 OSINT
🔹 vulnerability reconnaissance
LLM работает как reasoning-движок между этапами reconnaissance.
Например, агент может: увидеть exposed admin endpoint → определить стек → заметить старую версию framework → автоматически переключиться на поиск типовых misconfiguration или CVE именно для этой технологии. Следующий шаг зависит от контекста предыдущего.
Результаты работы утилит нормализуются, передаются модели, после чего LLM генерирует следующую последовательность recon-действий. Sandyaa пытается построить decision-making layer.
Правда, здесь сразу проявляется слабое место LLM. Модель может переоценивать находки, строить нереалистичные attack paths или уходить в ложные гипотезы. Особенно плохо агенты пока работают с noisy reconnaissance-данными, где важно отличать интересную аномалию от обычного мусора.
🔗 GitHub: https://github.com/securelayer7/sandyaa
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Reconnaissance #Pentest #OffensiveSecurity #AgenticAI #OSINT #OpenSource #SecureTechTalks
Разведка давно перестала быть проблемой с точки зрения инструментов: Subfinder, httpx, nuclei, waybackurls, DNSdumpster, Shodan. Экосистема огромная. Однако человек просто тонет в количестве результатов.
Sandyaa строится как orchestration-layer поверх классических recon-инструментов. Агент собирает данные о цели, анализирует результаты и сам определяет, какие действия выполнять дальше.
Технически Sandyaa комбинирует:
🔹 subdomain enumeration
🔹 technology fingerprinting
🔹 endpoint discovery
🔹 OSINT
🔹 vulnerability reconnaissance
LLM работает как reasoning-движок между этапами reconnaissance.
Например, агент может: увидеть exposed admin endpoint → определить стек → заметить старую версию framework → автоматически переключиться на поиск типовых misconfiguration или CVE именно для этой технологии. Следующий шаг зависит от контекста предыдущего.
Результаты работы утилит нормализуются, передаются модели, после чего LLM генерирует следующую последовательность recon-действий. Sandyaa пытается построить decision-making layer.
Правда, здесь сразу проявляется слабое место LLM. Модель может переоценивать находки, строить нереалистичные attack paths или уходить в ложные гипотезы. Особенно плохо агенты пока работают с noisy reconnaissance-данными, где важно отличать интересную аномалию от обычного мусора.
🔗 GitHub: https://github.com/securelayer7/sandyaa
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Reconnaissance #Pentest #OffensiveSecurity #AgenticAI #OSINT #OpenSource #SecureTechTalks
👍1
🧬 VectorSmuggle: данные научились прятать внутри embedding’ов
Большинство AI-систем относятся к embedding как к безопасному промежуточному формату, т.к. Вектор не выглядит как текст и не содержит очевидного payload.
Поэтому embedding’и спокойно:
🔹 передаются между сервисами
🔹 индексируются в vector DB
🔹 попадают в shared storage
🔹 используются в retrieval pipeline
Практически никто не анализирует их содержимое с точки зрения безопасности. А зря.
⚙️ Что такое VectorSmuggle
Исследователи показали, что внутри embedding можно скрытно кодировать произвольные данные, сохраняя при этом его внешнюю «нормальность».
Технически идея строится вокруг особенностей embedding space.
LLM и embedding-модели преобразуют текст в высокоразмерные векторы. При этом небольшие изменения отдельных компонент обычно не ломают semantic similarity.
Именно этот запас устойчивости злоумышленники используют, как covert channel.
Часть измерений embedding’а начинает хранить скрытый payload, который можно позже извлечь специальным декодером.
Со стороны embedding продолжает выглядеть легитимно:
🔹 проходит similarity search
🔹 нормально индексируется
🔹 не вызывает ошибок в vector pipeline
Но внутри уже находится скрытая информация.
🧪 Реализация
Схема выглядит довольно элегантно, сначала данные кодируются внутрь embedding-вектора через модификацию отдельных dimensions. После этого embedding отправляется в обычную vector infrastructure: FAISS, Pinecone, Milvus или другую vector DB.
Позже получатель извлекает embedding и декодирует скрытый payload обратно в исходные данные. Ключевая проблема в том, что embedding-инфраструктура почти не имеет механизмов проверки:
🔹 что именно хранится внутри вектора
🔹 насколько embedding отклоняется от нормального распределения
🔹 используется ли vector space как covert storage
Для системы это просто массив float-значений.
🧨 Опасность⚠️
На практике VectorSmuggle открывает довольно неприятные сценарии.
Например:
🔹 скрытая передача данных через RAG-pipeline
🔹 covert communication между агентами
🔹 хранение payload внутри vector DB
🔹 обход DLP/контент-фильтрации
🔹 скрытая эксфильтрация информации через embedding API
Особенно интересно выглядит последний пункт. Многие security-системы анализируют текст, файлы или сетевой трафик, но практически не смотрят на embedding-space как на потенциальный канал утечки данных, хотя именно туда AI-инфраструктура сейчас начинает переносить всё больше информации.
🔗 Исследование: https://arxiv.org/abs/2505.12540
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Embedding #VectorDB #RAG #DataSecurity #AppSec #AIrisks #SecureTechTalks
Большинство AI-систем относятся к embedding как к безопасному промежуточному формату, т.к. Вектор не выглядит как текст и не содержит очевидного payload.
Поэтому embedding’и спокойно:
🔹 передаются между сервисами
🔹 индексируются в vector DB
🔹 попадают в shared storage
🔹 используются в retrieval pipeline
Практически никто не анализирует их содержимое с точки зрения безопасности. А зря.
⚙️ Что такое VectorSmuggle
Исследователи показали, что внутри embedding можно скрытно кодировать произвольные данные, сохраняя при этом его внешнюю «нормальность».
Технически идея строится вокруг особенностей embedding space.
LLM и embedding-модели преобразуют текст в высокоразмерные векторы. При этом небольшие изменения отдельных компонент обычно не ломают semantic similarity.
Именно этот запас устойчивости злоумышленники используют, как covert channel.
Часть измерений embedding’а начинает хранить скрытый payload, который можно позже извлечь специальным декодером.
Со стороны embedding продолжает выглядеть легитимно:
🔹 проходит similarity search
🔹 нормально индексируется
🔹 не вызывает ошибок в vector pipeline
Но внутри уже находится скрытая информация.
🧪 Реализация
Схема выглядит довольно элегантно, сначала данные кодируются внутрь embedding-вектора через модификацию отдельных dimensions. После этого embedding отправляется в обычную vector infrastructure: FAISS, Pinecone, Milvus или другую vector DB.
Позже получатель извлекает embedding и декодирует скрытый payload обратно в исходные данные. Ключевая проблема в том, что embedding-инфраструктура почти не имеет механизмов проверки:
🔹 что именно хранится внутри вектора
🔹 насколько embedding отклоняется от нормального распределения
🔹 используется ли vector space как covert storage
Для системы это просто массив float-значений.
🧨 Опасность
На практике VectorSmuggle открывает довольно неприятные сценарии.
Например:
🔹 скрытая передача данных через RAG-pipeline
🔹 covert communication между агентами
🔹 хранение payload внутри vector DB
🔹 обход DLP/контент-фильтрации
🔹 скрытая эксфильтрация информации через embedding API
Особенно интересно выглядит последний пункт. Многие security-системы анализируют текст, файлы или сетевой трафик, но практически не смотрят на embedding-space как на потенциальный канал утечки данных, хотя именно туда AI-инфраструктура сейчас начинает переносить всё больше информации.
🔗 Исследование: https://arxiv.org/abs/2505.12540
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Embedding #VectorDB #RAG #DataSecurity #AppSec #AIrisks #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1