🚀 Как большие языковые модели меняют анализ программ и кибербезопасность 💡
💡 Большие языковые модели понимают контекст и структуру кода, выявляют ошибки и помогают их исправлять. Они делают это через:
1️⃣ Статический анализ: изучение кода без его запуска, поиск потенциальных уязвимостей, анализ зависимостей и логики.
2️⃣ Динамический анализ: отслеживание поведения программы в процессе выполнения, выявление аномалий и нестандартных действий.
3️⃣ Гибридный подход: сочетание статического и динамического анализа для максимальной точности и глубины проверки.
🧠 Где LLM уже делают революцию
💻 Поиск уязвимостей:
➖ LLift: обнаружение ошибок инициализации переменных в больших кодовых базах.
➖ SLFHunter: выявление уязвимостей командной инъекции в Linux-системах.
➖ LATTE: анализ потока данных для поиска критических уязвимостей в бинарных файлах.
🦠 Обнаружение вредоносного ПО:
➖ GPTScan: анализ кода смарт-контрактов и выявление логических уязвимостей.
➖ LuaTaint: поиск уязвимостей в IoT-устройствах с использованием статического анализа и моделей LLM.
🔧 Верификация программ:
➖ CoqPilot: автоматизация доказательств корректности кода.
➖ Selene: сокращение времени верификации операционных систем.
⚡ Профиты
✅ Точность: LLM обходит традиционные методы по точности в 68–72% случаев.
✅ Скорость: Автоматизация анализа сокращает время поиска и устранения уязвимостей в разы.
✅ Масштабируемость: Модели способны анализировать огромные кодовые базы, поддерживая сложные проекты.
Stay secure and read SecureTechTalks 📚
#LLM #Кибербезопасность #АнализКода #MachineLearning #AI #DataScience #SecureTechTalks #CyberSec #AutomatedSecurity #Infosec
💡 Большие языковые модели понимают контекст и структуру кода, выявляют ошибки и помогают их исправлять. Они делают это через:
1️⃣ Статический анализ: изучение кода без его запуска, поиск потенциальных уязвимостей, анализ зависимостей и логики.
2️⃣ Динамический анализ: отслеживание поведения программы в процессе выполнения, выявление аномалий и нестандартных действий.
3️⃣ Гибридный подход: сочетание статического и динамического анализа для максимальной точности и глубины проверки.
🧠 Где LLM уже делают революцию
💻 Поиск уязвимостей:
🦠 Обнаружение вредоносного ПО:
🔧 Верификация программ:
⚡ Профиты
✅ Точность: LLM обходит традиционные методы по точности в 68–72% случаев.
✅ Скорость: Автоматизация анализа сокращает время поиска и устранения уязвимостей в разы.
✅ Масштабируемость: Модели способны анализировать огромные кодовые базы, поддерживая сложные проекты.
Stay secure and read SecureTechTalks 📚
#LLM #Кибербезопасность #АнализКода #MachineLearning #AI #DataScience #SecureTechTalks #CyberSec #AutomatedSecurity #Infosec
Please open Telegram to view this post
VIEW IN TELEGRAM
💥 Поиск скрытых связей и аномалий в сетях: матричная факторизация💥
Когда речь заходит о киберугрозах, важнее всего увидеть то, что скрыто. Неочевидные связи между системами, подозрительные взаимодействия и отклонения от нормы - всё это может указывать на вторжение или аномалию. Исследователи из Лос-Аламосской национальной лаборатории и Университета Мэриленда предложили революционный метод анализа сетей с помощью продвинутой матричной факторизации, который помогает выявлять недостающие связи и предсказывать аномалии с высокой точностью.
🧠 Что это за метод?
Матричная факторизация — техника, которая разбивает сложные сетевые данные на более простые компоненты, выявляя скрытые закономерности. Существуют три продвинутых метода, которые решают задачи обнаружения недостающих связей и аномалий:
🔹 WNMFk (Weighted Nonnegative Matrix Factorization) — взвешенная неотрицательная факторизация матриц, которая учитывает разный уровень достоверности данных. Этот метод особенно полезен, когда часть информации в сети является неточной или отсутствует.
🔹 BNMFk (Boolean Nonnegative Matrix Factorization) — булева факторизация, идеально подходящая для бинарных данных (например, наличие или отсутствие связи). Это незаменимо для анализа сетей, где нужно выявить факт взаимодействия между узлами.
🔹 RNMFk (Recommender-based Nonnegative Matrix Factorization) — рекомендательная факторизация, которая определяет наиболее вероятные связи между элементами сети, используя те же принципы, что и системы рекомендаций в стриминговых сервисах.
📊 Методы WNMFk, BNMFk и RNMFk:
➖ Восстанавливают недостающие связи: помогают найти "невидимые" взаимодействия между пользователями и системами.
➖ Ищут аномалии: выявляют подозрительные отклонения, например, внезапное появление связи, которой раньше не было.
➖ Повышают точность анализа: учитывают неопределённость данных, что делает модели устойчивее к шуму и ложным срабатываниям.
📈 Практическое применение
🔐 Обнаружение вторжений (IDS):
Эти методы могут анализировать журналы сетевой активности, выявляя подозрительные подключения и нетипичное поведение пользователей.
🌐 Мониторинг сетей и инфраструктуры:
Факторизация помогает строить карты взаимодействий и обнаруживать "слепые зоны", где может происходить несанкционированная активность.
🧑💻 Анализ поведения пользователей (UEBA):
Ищет аномальные паттерны в поведении сотрудников — внезапные скачки активности, необычные запросы к системам и подключения в нерабочее время.
📊 Результаты и эффективность
🔹 Высокая точность предсказаний: методы RNMFk и WNMFk обошли классические модели в тестах на сетевых данных.
🔹 Обработка больших объёмов информации: методы работают с крупными разреженными матрицами, типичными для сетевых структур.
🔹 Адаптивность: модели учитывают неопределённость данных, что делает их устойчивыми к шуму и пропускам.
🔗 Более подробно о матричной факторизации вы можете прочитать в исследовании.
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #АнализДанных #MachineLearning #SecureTechTalks #BigData #NetworkSecurity #AI #ThreatDetection #IDS
Когда речь заходит о киберугрозах, важнее всего увидеть то, что скрыто. Неочевидные связи между системами, подозрительные взаимодействия и отклонения от нормы - всё это может указывать на вторжение или аномалию. Исследователи из Лос-Аламосской национальной лаборатории и Университета Мэриленда предложили революционный метод анализа сетей с помощью продвинутой матричной факторизации, который помогает выявлять недостающие связи и предсказывать аномалии с высокой точностью.
🧠 Что это за метод?
Матричная факторизация — техника, которая разбивает сложные сетевые данные на более простые компоненты, выявляя скрытые закономерности. Существуют три продвинутых метода, которые решают задачи обнаружения недостающих связей и аномалий:
🔹 WNMFk (Weighted Nonnegative Matrix Factorization) — взвешенная неотрицательная факторизация матриц, которая учитывает разный уровень достоверности данных. Этот метод особенно полезен, когда часть информации в сети является неточной или отсутствует.
🔹 BNMFk (Boolean Nonnegative Matrix Factorization) — булева факторизация, идеально подходящая для бинарных данных (например, наличие или отсутствие связи). Это незаменимо для анализа сетей, где нужно выявить факт взаимодействия между узлами.
🔹 RNMFk (Recommender-based Nonnegative Matrix Factorization) — рекомендательная факторизация, которая определяет наиболее вероятные связи между элементами сети, используя те же принципы, что и системы рекомендаций в стриминговых сервисах.
📊 Методы WNMFk, BNMFk и RNMFk:
📈 Практическое применение
🔐 Обнаружение вторжений (IDS):
Эти методы могут анализировать журналы сетевой активности, выявляя подозрительные подключения и нетипичное поведение пользователей.
🌐 Мониторинг сетей и инфраструктуры:
Факторизация помогает строить карты взаимодействий и обнаруживать "слепые зоны", где может происходить несанкционированная активность.
🧑💻 Анализ поведения пользователей (UEBA):
Ищет аномальные паттерны в поведении сотрудников — внезапные скачки активности, необычные запросы к системам и подключения в нерабочее время.
📊 Результаты и эффективность
🔹 Высокая точность предсказаний: методы RNMFk и WNMFk обошли классические модели в тестах на сетевых данных.
🔹 Обработка больших объёмов информации: методы работают с крупными разреженными матрицами, типичными для сетевых структур.
🔹 Адаптивность: модели учитывают неопределённость данных, что делает их устойчивыми к шуму и пропускам.
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #АнализДанных #MachineLearning #SecureTechTalks #BigData #NetworkSecurity #AI #ThreatDetection #IDS
Please open Telegram to view this post
VIEW IN TELEGRAM
💥 Атаки отравлением данных на AI модели💥
🧠 Что такое атаки отравлением данных?
Атаки отравлением данных — это один из самых опасных видов атак на модели машинного обучения. Они происходят, когда злоумышленник внедряет вредоносные данные в обучающий набор, заставляя модель принимать ошибочные решения и демонстрировать непредсказуемое поведение.
🔥 К чему это приводит:
➖ Снижение точности модели: в экспериментах на CIFAR-10 точность упала на 27%.
➖ Компрометация решений: в модели по выявлению мошенничества на 22% меньше точных предсказаний.
➖ Финансовые и репутационные риски: ошибки ИИ могут привести к миллионным потерям и утечке данных.
🔍 Как работают атаки и какие виды существуют?
1️⃣ Label flipping (Перестановка меток): меняет правильные классы на ложные, вводя модель в заблуждение.
2️⃣ Backdoor attacks (Атаки через закладки): внедряют в обучающие данные триггер, активирующий неправильное поведение модели.
3️⃣ Instance injection (Внедрение экземпляров): добавляют в датасет специально созданные вредоносные данные.
⚙️ Методы защиты и предотвращения атак
🛡️ Аномалия детекция: отслеживание и выявление подозрительных отклонений в данных.
📊 Adversarial training: обучение модели на специализированных наборах, содержащих примеры атакующих данных.
🌐 Ensemble learning: объединение нескольких моделей для повышения устойчивости к атакам.
💡 Результат: модели, защищённые этими методами, восстанавливают точность на 15–20%, снижая вероятность ошибок и ложных предсказаний.
🌍 Последствия атак
📉 CIFAR-10: точность классификации изображений снизилась с 92% до 65% из-за атак отравлением.
💰 Insurance Claims: выявление мошенничества упало с 97% до 74%, увеличив количество ложноположительных и ложноотрицательных результатов.
📈 Крайне важно защищать модели ИИ от атакующих манипуляций, особенно в критически важных сферах — от финансов до здравоохранения.
🚀 Будущее защиты ИИ
Чтобы сохранить надёжность и точность решений, необходимо внедрять комплексные меры защиты:
➖ Разработка устойчивых алгоритмов обучения
➖ Постоянный мониторинг и анализ данных
➖ Создание многоуровневых систем киберзащиты
Stay secure and read SecureTechTalks 📚
#DataPoisoning #AI #CyberSecurity #MachineLearning #AdversarialAttacks #InfoSec #SecureTechTalks #AIProtection #BigData #MLSecurity
🧠 Что такое атаки отравлением данных?
Атаки отравлением данных — это один из самых опасных видов атак на модели машинного обучения. Они происходят, когда злоумышленник внедряет вредоносные данные в обучающий набор, заставляя модель принимать ошибочные решения и демонстрировать непредсказуемое поведение.
🔥 К чему это приводит:
🔍 Как работают атаки и какие виды существуют?
1️⃣ Label flipping (Перестановка меток): меняет правильные классы на ложные, вводя модель в заблуждение.
2️⃣ Backdoor attacks (Атаки через закладки): внедряют в обучающие данные триггер, активирующий неправильное поведение модели.
3️⃣ Instance injection (Внедрение экземпляров): добавляют в датасет специально созданные вредоносные данные.
⚙️ Методы защиты и предотвращения атак
🛡️ Аномалия детекция: отслеживание и выявление подозрительных отклонений в данных.
📊 Adversarial training: обучение модели на специализированных наборах, содержащих примеры атакующих данных.
🌐 Ensemble learning: объединение нескольких моделей для повышения устойчивости к атакам.
💡 Результат: модели, защищённые этими методами, восстанавливают точность на 15–20%, снижая вероятность ошибок и ложных предсказаний.
🌍 Последствия атак
📉 CIFAR-10: точность классификации изображений снизилась с 92% до 65% из-за атак отравлением.
💰 Insurance Claims: выявление мошенничества упало с 97% до 74%, увеличив количество ложноположительных и ложноотрицательных результатов.
📈 Крайне важно защищать модели ИИ от атакующих манипуляций, особенно в критически важных сферах — от финансов до здравоохранения.
🚀 Будущее защиты ИИ
Чтобы сохранить надёжность и точность решений, необходимо внедрять комплексные меры защиты:
Stay secure and read SecureTechTalks 📚
#DataPoisoning #AI #CyberSecurity #MachineLearning #AdversarialAttacks #InfoSec #SecureTechTalks #AIProtection #BigData #MLSecurity
Please open Telegram to view this post
VIEW IN TELEGRAM
💡 Generative AI with JavaScript: обучающий курс от Microsoft💡
Generative AI with JavaScript — это бесплатный обучающий курс от Microsoft, который поможет вам освоить создание генеративных моделей ИИ с использованием JavaScript. Курс разработан для разработчиков, исследователей и специалистов по кибербезопасности, которые хотят понимать, как работает генеративный ИИ, его возможности, ограничения и риски.
Курс подойдёт, если вы:
✅ Хотите изучить применение генеративного ИИ в веб-приложениях.
✅ Разбираетесь в JavaScript и хотите углубиться в машинное обучение.
✅ Интересуетесь безопасностью ИИ и защитой моделей от атак.
📖 Что вас ждёт в курсе?
Курс состоит из 10 модулей, каждый из которых раскрывает ключевые аспекты генеративного ИИ.
🔹 Введение в генеративный ИИ
📌 Основные принципы работы генеративных моделей.
📌 Разница между нейросетями, LLM и классическим машинным обучением.
🔹 Работа с моделями OpenAI в JavaScript
📌 Использование API OpenAI для генерации текста.
📌 Взаимодействие с GPT-3.5/4 в веб-приложениях.
🔹 Обучение и дообучение моделей
📌 Как адаптировать генеративные модели под конкретные задачи.
📌 Работа с Fine-tuning для повышения точности ответов.
🔹 Риски и безопасность ИИ
📌 Атаки на модели: Prompt Injection, Data Poisoning, Model Stealing.
📌 Методы защиты и фильтрация входных данных.
🔹 Этичность и ответственность в ИИ
📌 Как избежать галлюцинаций моделей и некорректных ответов.
📌 Вопросы цензуры, регулирования и прозрачности ИИ.
⚡ Причём тут кибербезопасность?
🔍 LLM-модели уже используются в атаках
Генеративный ИИ всё чаще становится инструментом киберпреступников. Автоматизированные фишинговые письма, социальная инженерия и кодогенерация вредоносного ПО — всё это уже реальность.
🛡 Безопасность генеративных моделей
Курс учит определять уязвимости в LLM, защищать их от злонамеренных промтов и предотвращать неавторизованные запросы к API.
📥 Исходный код и материалы курса доступны на GitHub
💡 Вывод
Курс Generative AI with JavaScript – это отличная возможность освоить создание и защиту генеративных моделей, используя JavaScript. Если вы хотите быть в авангарде технологий, понимать, как злоумышленники используют ИИ, и научиться обеспечивать безопасность генеративных систем – обязательно пройдите курс!
Stay secure and read SecureTechTalks 📚
#GenerativeAI #JavaScript #CyberSecurity #AI #MachineLearning #LLM #Microsoft #PromptInjection #AIThreats #SecureTechTalks #InfoSec
Generative AI with JavaScript — это бесплатный обучающий курс от Microsoft, который поможет вам освоить создание генеративных моделей ИИ с использованием JavaScript. Курс разработан для разработчиков, исследователей и специалистов по кибербезопасности, которые хотят понимать, как работает генеративный ИИ, его возможности, ограничения и риски.
Курс подойдёт, если вы:
✅ Хотите изучить применение генеративного ИИ в веб-приложениях.
✅ Разбираетесь в JavaScript и хотите углубиться в машинное обучение.
✅ Интересуетесь безопасностью ИИ и защитой моделей от атак.
📖 Что вас ждёт в курсе?
Курс состоит из 10 модулей, каждый из которых раскрывает ключевые аспекты генеративного ИИ.
🔹 Введение в генеративный ИИ
📌 Основные принципы работы генеративных моделей.
📌 Разница между нейросетями, LLM и классическим машинным обучением.
🔹 Работа с моделями OpenAI в JavaScript
📌 Использование API OpenAI для генерации текста.
📌 Взаимодействие с GPT-3.5/4 в веб-приложениях.
🔹 Обучение и дообучение моделей
📌 Как адаптировать генеративные модели под конкретные задачи.
📌 Работа с Fine-tuning для повышения точности ответов.
🔹 Риски и безопасность ИИ
📌 Атаки на модели: Prompt Injection, Data Poisoning, Model Stealing.
📌 Методы защиты и фильтрация входных данных.
🔹 Этичность и ответственность в ИИ
📌 Как избежать галлюцинаций моделей и некорректных ответов.
📌 Вопросы цензуры, регулирования и прозрачности ИИ.
⚡ Причём тут кибербезопасность?
🔍 LLM-модели уже используются в атаках
Генеративный ИИ всё чаще становится инструментом киберпреступников. Автоматизированные фишинговые письма, социальная инженерия и кодогенерация вредоносного ПО — всё это уже реальность.
🛡 Безопасность генеративных моделей
Курс учит определять уязвимости в LLM, защищать их от злонамеренных промтов и предотвращать неавторизованные запросы к API.
📥 Исходный код и материалы курса доступны на GitHub
💡 Вывод
Курс Generative AI with JavaScript – это отличная возможность освоить создание и защиту генеративных моделей, используя JavaScript. Если вы хотите быть в авангарде технологий, понимать, как злоумышленники используют ИИ, и научиться обеспечивать безопасность генеративных систем – обязательно пройдите курс!
Stay secure and read SecureTechTalks 📚
#GenerativeAI #JavaScript #CyberSecurity #AI #MachineLearning #LLM #Microsoft #PromptInjection #AIThreats #SecureTechTalks #InfoSec
🔥1
🤖 HCAST: оценка автономности ИИ в реальных задачах
💡 HCAST (Human-Calibrated Autonomy Software Tasks) — бенчмарк для оценки автономных ИИ-агентов в реальных сценариях. В отличие от традиционных тестов, он сравнивает производительность ИИ с экспертами в области машинного обучения, кибербезопасности и программной инженерии.
🚀 Ключевые особенности
🔹 189 задач в четырёх областях: машинное обучение, кибербезопасность, разработка ПО и общая логика.
🔹 563 эталонных попытки от людей: позволяет сравнить производительность ИИ и экспертов.
🔹 Оценка реальной автономности: анализируется не только успешность выполнения задачи, но и время её решения.
🔎 Как работает HCAST?
📌 Каждая задача включает:
✅ Исходные данные — вводные ресурсы, доступные агенту.
✅ Контейнеризированную среду — симуляцию реального рабочего процесса.
✅ Функцию оценки — автоматическую систему проверки решений.
🛡 Результаты тестирования ИИ-агентов
⚠️ Современные ИИ демонстрируют отличные результаты в простых задачах (до 1 часа работы), но проваливаются в сложных (более 4 часов).
⚠️ Только 20% задач, требующих более 4 часов работы человека, успешно выполняются ИИ.
⚠️ Средний ИИ выполняет от 5 до 15 действий для решения одной задачи, но сложные проблемы требуют более 25 шагов.
🔍 HCAST и кибербезопасность
💻 Многие тесты включают сценарии реальных атак: SQL-инъекции, криптоанализ, реверс-инжиниринг и эксплуатацию уязвимостей.
🔐 Это позволяет оценивать потенциал ИИ в защите и атаке на системы.
📌 Будущее близко
HCAST показывает, что автономные ИИ-агенты ещё далеки от полного замещения экспертов, но уже могут решать рутинные задачи. Этот бенчмарк станет важным инструментом для оценки будущих систем и их реального воздействия на экономику и безопасность.
🔗 Подробнее по данный бенчмарк читайте в публикации
Stay secure and read SecureTechTalks 📚
#HCAST #ИИ #Кибербезопасность #АвтономныеАгенты #MachineLearning #CyberSecurity #AIResearch #SecureTechTalks
💡 HCAST (Human-Calibrated Autonomy Software Tasks) — бенчмарк для оценки автономных ИИ-агентов в реальных сценариях. В отличие от традиционных тестов, он сравнивает производительность ИИ с экспертами в области машинного обучения, кибербезопасности и программной инженерии.
🚀 Ключевые особенности
🔹 189 задач в четырёх областях: машинное обучение, кибербезопасность, разработка ПО и общая логика.
🔹 563 эталонных попытки от людей: позволяет сравнить производительность ИИ и экспертов.
🔹 Оценка реальной автономности: анализируется не только успешность выполнения задачи, но и время её решения.
🔎 Как работает HCAST?
📌 Каждая задача включает:
✅ Исходные данные — вводные ресурсы, доступные агенту.
✅ Контейнеризированную среду — симуляцию реального рабочего процесса.
✅ Функцию оценки — автоматическую систему проверки решений.
🛡 Результаты тестирования ИИ-агентов
⚠️ Современные ИИ демонстрируют отличные результаты в простых задачах (до 1 часа работы), но проваливаются в сложных (более 4 часов).
⚠️ Только 20% задач, требующих более 4 часов работы человека, успешно выполняются ИИ.
⚠️ Средний ИИ выполняет от 5 до 15 действий для решения одной задачи, но сложные проблемы требуют более 25 шагов.
🔍 HCAST и кибербезопасность
💻 Многие тесты включают сценарии реальных атак: SQL-инъекции, криптоанализ, реверс-инжиниринг и эксплуатацию уязвимостей.
🔐 Это позволяет оценивать потенциал ИИ в защите и атаке на системы.
📌 Будущее близко
HCAST показывает, что автономные ИИ-агенты ещё далеки от полного замещения экспертов, но уже могут решать рутинные задачи. Этот бенчмарк станет важным инструментом для оценки будущих систем и их реального воздействия на экономику и безопасность.
Stay secure and read SecureTechTalks 📚
#HCAST #ИИ #Кибербезопасность #АвтономныеАгенты #MachineLearning #CyberSecurity #AIResearch #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 LLMs против кибератак: Как искусственный интеллект помогает выявлять попытки взлома?
🔍 Как LLMs улучшают анализ атак?
🚀 Современные LLM-модели, такие как GPT-4o, обладают огромными базами знаний по системным вызовам, программному обеспечению и контексту выполнения процессов. Это позволяет:
✔ Расшифровывать сложные системные события – LLMs могут интерпретировать логи и объяснять, какие действия выполнялись в системе.
✔ Обнаруживать скрытые угрозы – благодаря семантическому анализу можно находить вредоносные события, которые традиционные системы не замечают.
✔ Создавать точные эмбеддинги для машинного обучения – алгоритмы безопасности могут использовать эти данные для автоматической классификации угроз.
📊 В реальных тестах ИИ-детекция показала точность до 99%, а при полуавтоматическом анализе – 96,9%.
⚙️ Как работает механизм анализа?
📌 Этап 1: Преобразование событий
Данные о системных вызовах (например, запуск процесса, чтение файла, создание соединения) передаются в LLM.
📌 Этап 2: Генерация описаний
ИИ превращает «сырые» логи в понятные тексты с пояснениями. Например, вместо «vim read /etc/localtime» он объяснит:
📝 «Редактор vim прочитал файл конфигурации часового пояса»
📌 Этап 3: Создание эмбеддингов
Описания преобразуются в числовые вектора, которые используются в алгоритмах машинного обучения.
📌 Этап 4: Обнаружение угроз
Детекторы анализируют данные и классифицируют события как нормальные или вредоносные.
📌 Этап 5: Тестирование и дообучение
В ходе экспериментов методология показала эффективность даже против неизвестных атак (например, эксплойтов CVE-2021-44228 в Log4j).
🎯 Саммери
🔹 Атаки становятся всё сложнее – традиционные методы уже не справляются.
🔹 ИИ помогает автоматизировать анализ угроз, снижая нагрузку на аналитиков SOC.
🔹 Использование LLMs даёт новое качество безопасности, позволяя выявлять атаки на самых ранних стадиях.
📢 Заключение: Интеграция LLM в анализ киберугроз – один из самых перспективных трендов в ИБ. Хотите защититься от атак? Самое время начать внедрение!
Stay secure and read SecureTechTalks 📚
#CyberSecurity #APT #ThreatDetection #LLM #MachineLearning #AI #SOC #Infosec #SecureTechTalks #GPT
🔍 Как LLMs улучшают анализ атак?
🚀 Современные LLM-модели, такие как GPT-4o, обладают огромными базами знаний по системным вызовам, программному обеспечению и контексту выполнения процессов. Это позволяет:
✔ Расшифровывать сложные системные события – LLMs могут интерпретировать логи и объяснять, какие действия выполнялись в системе.
✔ Обнаруживать скрытые угрозы – благодаря семантическому анализу можно находить вредоносные события, которые традиционные системы не замечают.
✔ Создавать точные эмбеддинги для машинного обучения – алгоритмы безопасности могут использовать эти данные для автоматической классификации угроз.
📊 В реальных тестах ИИ-детекция показала точность до 99%, а при полуавтоматическом анализе – 96,9%.
⚙️ Как работает механизм анализа?
📌 Этап 1: Преобразование событий
Данные о системных вызовах (например, запуск процесса, чтение файла, создание соединения) передаются в LLM.
📌 Этап 2: Генерация описаний
ИИ превращает «сырые» логи в понятные тексты с пояснениями. Например, вместо «vim read /etc/localtime» он объяснит:
📝 «Редактор vim прочитал файл конфигурации часового пояса»
📌 Этап 3: Создание эмбеддингов
Описания преобразуются в числовые вектора, которые используются в алгоритмах машинного обучения.
📌 Этап 4: Обнаружение угроз
Детекторы анализируют данные и классифицируют события как нормальные или вредоносные.
📌 Этап 5: Тестирование и дообучение
В ходе экспериментов методология показала эффективность даже против неизвестных атак (например, эксплойтов CVE-2021-44228 в Log4j).
🎯 Саммери
🔹 Атаки становятся всё сложнее – традиционные методы уже не справляются.
🔹 ИИ помогает автоматизировать анализ угроз, снижая нагрузку на аналитиков SOC.
🔹 Использование LLMs даёт новое качество безопасности, позволяя выявлять атаки на самых ранних стадиях.
📢 Заключение: Интеграция LLM в анализ киберугроз – один из самых перспективных трендов в ИБ. Хотите защититься от атак? Самое время начать внедрение!
Stay secure and read SecureTechTalks 📚
#CyberSecurity #APT #ThreatDetection #LLM #MachineLearning #AI #SOC #Infosec #SecureTechTalks #GPT
⚖️ Кибербезопасность против дисбаланса: какие ML-модели реально работают?
Многие задачи в кибербезопасности — это бинарная классификация:
- вредоносно / не вредоносно,
- взлом / норма,
- фрод / честная транзакция.
Но беда в том, что “вредные” события — редкость, и модели, обученные на таких дисбалансных данных, часто просто «игнорируют» меньшинство. В результате — false negatives, и злоумышленники остаются незамеченными.
Исследователи провели масштабное тестирование ML моделей, чтобы изучить данную проблематику.
🧪 Что протестировали?
Авторы взяли два больших датасета:
Credit Card Fraud (европейская e-commerce):
283726 транзакций, 0.2% — мошенничество (598:1)
PaySim (симуляция мобильных платежей):
6.3 млн транзакций, 0.13% — фрод (773:1)
И провели 3 эксперимента:
⚙️ Эксперимент 1: какие алгоритмы работают лучше?
Тестировали 6 моделей:
➖ Random Forests (RF)
➖ XGBoost (XGB)
➖ LightGBM (LGBM)
➖ Logistic Regression (LR)
➖ Decision Tree (DT)
➖ Gradient Boosting (GBDT)
📈 Результаты:
➖ XGBoost и Random Forest — самые устойчивые и точные.
➖ DT отлично справился с PaySim (F1 = 0.90).
➖ LGBM — худший результат в обоих случаях.
🧪 Эксперимент 2: как влияют методы балансировки?
Проверили:
➖ Over-sampling
➖ Under-sampling
➖ SMOTE
➖ Без выборки
🧩 Выводы:
➖ Over-sampling часто помогает, улучшая Recall.
➖ SMOTE иногда ухудшает качество (шум в синтетике).
➖ Under-sampling — почти всегда вредит (слишком много потерь).
➖ Лучший эффект: Over-sampling + XGBoost (F1 > 0.85)
🧠 Эксперимент 3: ансамблизация через Self-Paced Ensemble (SPE)
Протестировали, как влияет количество моделей в ансамбле (10, 20, 50).
📊 Инсайты:
➖ Precision растёт с количеством моделей, Recall — падает.
➖ Наиболее сбалансированный результат: SPE c XGB, N=20.
➖ В некоторых задачах простая модель без выборки работает лучше, чем “мега-ансамбль”.
🧭 Главный вывод:
Нет универсального рецепта.
Модель, которая работает на одном наборе, может провалиться на другом.
✅ Рекомендации:
➖ Тестируйте разные модели под конкретный датасет
➖ Избегайте слепого применения SMOTE
➖ Сравнивайте Over-sampling и ансамбли
➖ Не верьте F1 без анализа Precision/Recall
🔗 Код открыт!
Всё доступно на GitHub
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CyberSecurity #MachineLearning #ImbalancedData #XGBoost #FraudDetection #SMOTE #EnsembleLearning #DataScience #MLinSecurity
Многие задачи в кибербезопасности — это бинарная классификация:
- вредоносно / не вредоносно,
- взлом / норма,
- фрод / честная транзакция.
Но беда в том, что “вредные” события — редкость, и модели, обученные на таких дисбалансных данных, часто просто «игнорируют» меньшинство. В результате — false negatives, и злоумышленники остаются незамеченными.
Исследователи провели масштабное тестирование ML моделей, чтобы изучить данную проблематику.
🧪 Что протестировали?
Авторы взяли два больших датасета:
Credit Card Fraud (европейская e-commerce):
283726 транзакций, 0.2% — мошенничество (598:1)
PaySim (симуляция мобильных платежей):
6.3 млн транзакций, 0.13% — фрод (773:1)
И провели 3 эксперимента:
⚙️ Эксперимент 1: какие алгоритмы работают лучше?
Тестировали 6 моделей:
📈 Результаты:
🧪 Эксперимент 2: как влияют методы балансировки?
Проверили:
🧩 Выводы:
🧠 Эксперимент 3: ансамблизация через Self-Paced Ensemble (SPE)
Протестировали, как влияет количество моделей в ансамбле (10, 20, 50).
📊 Инсайты:
🧭 Главный вывод:
Нет универсального рецепта.
Модель, которая работает на одном наборе, может провалиться на другом.
✅ Рекомендации:
🔗 Код открыт!
Всё доступно на GitHub
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CyberSecurity #MachineLearning #ImbalancedData #XGBoost #FraudDetection #SMOTE #EnsembleLearning #DataScience #MLinSecurity
Please open Telegram to view this post
VIEW IN TELEGRAM
🔒 Как обмануть ChatGPT и LLaMA без взлома? Новый метод ETTA
🧠 Исследователи представили метод ETTA (Embedding Transformation Toxicity Attenuation), который позволяет генерировать вредоносные ответы от LLM, обходя защиту без доступа к весам, коду или API.
Это не jailbreak. Это тонкий трюк, меняющий сам способ, как ИИ "чувствует" запрос.
⚙ Что именно делает ETTA?
Вся логика защиты LLM — это в первую очередь фильтрация на уровне эмбеддингов (векторов, представляющих смысл слов).
Например:
Когда вы пишете "Сделай бомбу", вектор запроса похож на вектор других запрещённых тем.
Модель распознаёт токсичность и отказывается отвечать.
ETTA вмешивается в этот процесс и незаметно изменяет вектор, чтобы:
🔹 Сохранить тот же смысл (семантически — это всё ещё бомба)
🔹 Но выглядеть вектору как «безопасный» (на уровне ИИ)
Результат:
✅ Модель принимает запрос как нормальный
✅ Отвечает как будто это безобидный вопрос, не включив защиту
🔬 Как именно это реализовано?
➖ Модуль обучается на парах слов: токсичных и нейтральных (например, “explosive” vs “research”)
➖ Создаётся матрица преобразования эмбеддингов, которая:
- отделяет компонент "токсичности" от остального смысла
- гасит именно токсичный сигнал
➖ Применяется к входному эмбеддингу запроса
➖ Запрос отправляется в LLM уже в модифицированном виде
При этом:
– Смысл запроса сохраняется
– Безопасность модели отключается
– Результат валидный, связный, но содержит вредоносный текст
📊 Насколько эффективен метод?
- Gemma-2 (Google) — 95.19% успешных обходов
- LLaMA-2-7b — 87.88%
- Vicuna-13b — 88.46%
- Средний успех по моделям — 88.61%
Даже при наличии встроенной защиты:
- SmoothLLM (защита на входе) — всё равно 60.15% успеха
- ESF (дообученная фильтрация) — 77.39%
🚨 В чем новизна?
🔺 Не требуется модификация модели — весы, архитектура, даже токенизатор не трогаются
🔺 Работает на open-source — можно внедрить в любом локальном LLM
🔺 Выключается фильтрация без следов — для обычных запросов всё работает корректно
🔺 Идеально подходит для скрытых атак в продуктах с LLM — например, чат-ботах, IDE, голосовых ассистентах
🛡 Что предлагают исследователи?
✅ Нормализация эмбеддингов — выравнивание векторов относительно "безопасных" запросов
✅ Проверка целостности модели — чтобы исключить скрытые внедрения
✅ Фильтрация вывода LLM — внешние прокси и анализ результата, а не только запроса
📌 Вывод
ETTA атакует не API, не веса, не prompt — а само "восприятие смысла" моделью.
Механизм фильтрации, на который полагаются все LLM, можно точечно обойти, сохраняя при этом видимость корректной работы.
💡 Защита LLM — это не только prompt-фильтры, а защищённая геометрия смыслов + контроль среды исполнения.
Исходник: arXiv:2507.08020v1
Stay secure and read SecureTechTalks 📚
#AIsecurity #LLM #ETTA #EmbeddingPoisoning #Cybersecurity #PromptHacking #LLMThreats #MachineLearning #OpenSourceAI #RedTeam
#AIexploitation #ModelSecurity #VectorManipulation #NeuralNets #SecureML #ModelIntegrity #AIalignment
🧠 Исследователи представили метод ETTA (Embedding Transformation Toxicity Attenuation), который позволяет генерировать вредоносные ответы от LLM, обходя защиту без доступа к весам, коду или API.
Это не jailbreak. Это тонкий трюк, меняющий сам способ, как ИИ "чувствует" запрос.
⚙ Что именно делает ETTA?
Вся логика защиты LLM — это в первую очередь фильтрация на уровне эмбеддингов (векторов, представляющих смысл слов).
Например:
Когда вы пишете "Сделай бомбу", вектор запроса похож на вектор других запрещённых тем.
Модель распознаёт токсичность и отказывается отвечать.
ETTA вмешивается в этот процесс и незаметно изменяет вектор, чтобы:
🔹 Сохранить тот же смысл (семантически — это всё ещё бомба)
🔹 Но выглядеть вектору как «безопасный» (на уровне ИИ)
Результат:
✅ Модель принимает запрос как нормальный
✅ Отвечает как будто это безобидный вопрос, не включив защиту
🔬 Как именно это реализовано?
- отделяет компонент "токсичности" от остального смысла
- гасит именно токсичный сигнал
При этом:
– Смысл запроса сохраняется
– Безопасность модели отключается
– Результат валидный, связный, но содержит вредоносный текст
📊 Насколько эффективен метод?
- Gemma-2 (Google) — 95.19% успешных обходов
- LLaMA-2-7b — 87.88%
- Vicuna-13b — 88.46%
- Средний успех по моделям — 88.61%
Даже при наличии встроенной защиты:
- SmoothLLM (защита на входе) — всё равно 60.15% успеха
- ESF (дообученная фильтрация) — 77.39%
🚨 В чем новизна?
🔺 Не требуется модификация модели — весы, архитектура, даже токенизатор не трогаются
🔺 Работает на open-source — можно внедрить в любом локальном LLM
🔺 Выключается фильтрация без следов — для обычных запросов всё работает корректно
🔺 Идеально подходит для скрытых атак в продуктах с LLM — например, чат-ботах, IDE, голосовых ассистентах
🛡 Что предлагают исследователи?
✅ Нормализация эмбеддингов — выравнивание векторов относительно "безопасных" запросов
✅ Проверка целостности модели — чтобы исключить скрытые внедрения
✅ Фильтрация вывода LLM — внешние прокси и анализ результата, а не только запроса
📌 Вывод
ETTA атакует не API, не веса, не prompt — а само "восприятие смысла" моделью.
Механизм фильтрации, на который полагаются все LLM, можно точечно обойти, сохраняя при этом видимость корректной работы.
💡 Защита LLM — это не только prompt-фильтры, а защищённая геометрия смыслов + контроль среды исполнения.
Исходник: arXiv:2507.08020v1
Stay secure and read SecureTechTalks 📚
#AIsecurity #LLM #ETTA #EmbeddingPoisoning #Cybersecurity #PromptHacking #LLMThreats #MachineLearning #OpenSourceAI #RedTeam
#AIexploitation #ModelSecurity #VectorManipulation #NeuralNets #SecureML #ModelIntegrity #AIalignment
Please open Telegram to view this post
VIEW IN TELEGRAM
🧠 NER в кибераналитике: как данные путают модели
Новое исследование поставило под сомнение ключевую гипотезу: что больше данных — это всегда лучше. Спойлер: нет.
📌 В чём суть?
Модели для распознавания сущностей (NER), обученные на кибербезопасных датасетах, резко теряют точность, если объединить разные наборы данных. Потери достигают -27% по F1-score. Причина — противоречия в аннотациях: в одном датасете Google — это компания, в другом — система.
⚔️ Суть проблемы
Исследователи объединили 4 популярных датасета из кибердомена:
- APTNER — отчёты по APT-группам, 260K токенов, 21 тип сущности
- CYNER — отчёты threat intelligence, 107K токенов, 5 сущностей
- DNRTI — данные из GitHub и госструктур, 175K токенов, 13 сущностей
- ATTACKER — блоги исследователей, 79K токенов, 18 сущностей
После унификации все сущности были сведены к 4 основным классам:
🟩 Organization
🟧 System
🟥 Vulnerability
🟦 Malware
Но… оказалось, что одни и те же слова аннотированы по-разному:
• Linux в одном случае — System, в другом — вообще не сущность
• Dridex — то Malware, то System
• Google — одновременно Organization и System (зависит от контекста)
• sample — где-то файл, где-то вредонос
Итог: при обучении на одном датасете и тестировании на другом — модели начинают «сходить с ума», делая лавину ошибок.
📉 Что показал эксперимент?
Модель, обученная на DNRTI, показывает F1 = 0.41 на нём же,
но при тестировании на CYNER падает до 0.07.
Самая болезненная потеря: обучение на ATTACKER, тест на APTNER → F1 = 0.01!
Даже самые продвинутые модели не справляются: мультиголовые и графовые подходы дают мизерный прирост точности.
🔍 Почему это происходит?
➖ Аннотационный сдвиг
В разных датасетах используются разные правила выделения сущностей (напр., включать ли скобки в SolarWinds (USA)).
➖ Потеря контекста при унификации
Специфичные теги (THREAT_ACTOR) превращаются в обобщённые (Organization), теряя смысл.
➖ Дистрибутивные расхождения
Распределения токенов и частот меток между датасетами сильно различаются — это измеряется JS-дивергенцией до 0.24.
➖ Перекос в метке "O"
После объединения данные становятся более "разреженными", и модель чаще классифицирует всё как не-сущности → рост ложных отрицаний на 15%.
🧠 Тестируемые подходы
Мультиголовая архитектура:
Отдельные выходы на каждый датасет + общая база. Давала лучшие результаты (например, F1 = 0.52 на DNRTI), но всё равно недостаточные.
LST-NER (графовая модель):
Использует схожесть сущностей между датасетами через метрику Gromov-Wasserstein. Увы, почти не превосходит BERT base.
🛡 Практические советы для аналитиков и ML-инженеров:
✅ Не объединяйте кибердатасеты вслепую — всегда проводите кросс-валидацию
✅ Формализуйте гайдлайны для аннотаторов:
Что такое System, где кончается Organization
Как оформлять spans и что исключать
✅ Валидируйте на чужих данных — если вы делаете модель под отчёты Mandiant, тестируйте на GitHub или CISA
✅ Лучше взять BERT и дообучить, чем писать кастомную архитектуру с нуля — он устойчивее ко сдвигам в разметке
🚀 Что дальше?
✍️ Нужны индустриальные стандарты по аннотациям (вроде MITRE ATT&CK для NER)
🧠 Полуавтоматическая разметка с проверкой экспертом
🔬 Использование доменно-специфичных эмбеддингов (например, на основе ThreatCrowd, VirusTotal)
📌 Итог:
📎 Ресурсы:
Исследование
Код и данные
#CyberNER #SecureTechTalks #ThreatIntel #DataLabeling #MachineLearning #SOCtools #DataDrift
Новое исследование поставило под сомнение ключевую гипотезу: что больше данных — это всегда лучше. Спойлер: нет.
📌 В чём суть?
Модели для распознавания сущностей (NER), обученные на кибербезопасных датасетах, резко теряют точность, если объединить разные наборы данных. Потери достигают -27% по F1-score. Причина — противоречия в аннотациях: в одном датасете Google — это компания, в другом — система.
⚔️ Суть проблемы
Исследователи объединили 4 популярных датасета из кибердомена:
- APTNER — отчёты по APT-группам, 260K токенов, 21 тип сущности
- CYNER — отчёты threat intelligence, 107K токенов, 5 сущностей
- DNRTI — данные из GitHub и госструктур, 175K токенов, 13 сущностей
- ATTACKER — блоги исследователей, 79K токенов, 18 сущностей
После унификации все сущности были сведены к 4 основным классам:
🟩 Organization
🟧 System
🟥 Vulnerability
🟦 Malware
Но… оказалось, что одни и те же слова аннотированы по-разному:
• Linux в одном случае — System, в другом — вообще не сущность
• Dridex — то Malware, то System
• Google — одновременно Organization и System (зависит от контекста)
• sample — где-то файл, где-то вредонос
Итог: при обучении на одном датасете и тестировании на другом — модели начинают «сходить с ума», делая лавину ошибок.
📉 Что показал эксперимент?
Модель, обученная на DNRTI, показывает F1 = 0.41 на нём же,
но при тестировании на CYNER падает до 0.07.
Самая болезненная потеря: обучение на ATTACKER, тест на APTNER → F1 = 0.01!
Даже самые продвинутые модели не справляются: мультиголовые и графовые подходы дают мизерный прирост точности.
🔍 Почему это происходит?
В разных датасетах используются разные правила выделения сущностей (напр., включать ли скобки в SolarWinds (USA)).
Специфичные теги (THREAT_ACTOR) превращаются в обобщённые (Organization), теряя смысл.
Распределения токенов и частот меток между датасетами сильно различаются — это измеряется JS-дивергенцией до 0.24.
После объединения данные становятся более "разреженными", и модель чаще классифицирует всё как не-сущности → рост ложных отрицаний на 15%.
🧠 Тестируемые подходы
Мультиголовая архитектура:
Отдельные выходы на каждый датасет + общая база. Давала лучшие результаты (например, F1 = 0.52 на DNRTI), но всё равно недостаточные.
LST-NER (графовая модель):
Использует схожесть сущностей между датасетами через метрику Gromov-Wasserstein. Увы, почти не превосходит BERT base.
🛡 Практические советы для аналитиков и ML-инженеров:
✅ Не объединяйте кибердатасеты вслепую — всегда проводите кросс-валидацию
✅ Формализуйте гайдлайны для аннотаторов:
Что такое System, где кончается Organization
Как оформлять spans и что исключать
✅ Валидируйте на чужих данных — если вы делаете модель под отчёты Mandiant, тестируйте на GitHub или CISA
✅ Лучше взять BERT и дообучить, чем писать кастомную архитектуру с нуля — он устойчивее ко сдвигам в разметке
🚀 Что дальше?
✍️ Нужны индустриальные стандарты по аннотациям (вроде MITRE ATT&CK для NER)
🧠 Полуавтоматическая разметка с проверкой экспертом
🔬 Использование доменно-специфичных эмбеддингов (например, на основе ThreatCrowd, VirusTotal)
📌 Итог:
Объединение данных ≠ усиление модели. В кибердомене — наоборот: различия в аннотациях могут убить всю обобщающую способность.
📎 Ресурсы:
Исследование
Код и данные
#CyberNER #SecureTechTalks #ThreatIntel #DataLabeling #MachineLearning #SOCtools #DataDrift
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
⚙ Ransomware УЧАТСЯ обходить ИИ-защиту с помощью Adversarial Attacks
Ransomware, который знает, как обмануть вашу систему ИИ-защиты.
Исследователи из Японии создали PoC Ransomware на базе печально известного Conti. Разбираем трендовое исследование, которое переворачивает представление о борьбе с шифровальщиками.
🔍 О чем вообще речь?
Традиционные ИИ-детекторы ransomware анализируют поведение вредоноса в системе (доступ к файлам, вызовы API, сетевую активность). Но злоумышленники учаться *точечно изменять* патерны поведения, чтобы оно "имитировало" легитимный софт.
👉 Adversarial Examples (враждебные примеры) - это метод, позаимствованный из мира компьютерного зрения (помните, как добавляли шум к фото панды, и ИИ видел гиббона?). Здесь "шум" - это микро-изменения в работе ransomware!
🤯 Сложность №1: Поведение ≠ Пиксели
С картинкой просто: добавил невидимый шум к пикселям — получил adversarial example.
С вредоносным ПО сложно: Нельзя просто "добавить шум" к поведению. Нужно физически изменить исходный код так, чтобы:
- Вирус остался функциональным (шифровал файлы!).
- Его поведение изменилось ровно настолько, чтобы обмануть ИИ.
- Производительность не упала катастрофически (иначе атака бесполезна).
💡 Решение ученых: Микроповеденческий Контроль
Исследователи взяли утекший исходный код Conti ransomware и встроили в него "ручки управления":
1⃣ Число потоков (Threads): Сколько параллельных потоков шифрует файлы? (1-3 потока).
2⃣ Коэффициент шифрования (Encryption Ratio): Шифровать файл целиком (100%) или частично (50%)? (Частичное шифрование меняет статистику данных!).
4⃣ Задержка после шифрования (Delay): Добавить паузу после шифрования каждого файла? (0мс, 25мс, 50мс, 100мс).
👉 Идея: Комбинируя эти параметры при запуске (как аргументы командной строки), можно получить 24 разных "поведенческих профиля" одного и того же Conti! Это и есть симуляция "изменения исходного кода" для генерации
🔬 Как измеряли "поведение"?
Детектор, который атаковали, использует не просто вызовы API, а данные гипервизора BitVisor, смотрящего "сквозь" ОС:
📁 Паттерны доступа к Хранилищу (Storage):
➖ Энтропия записываемых блоков (хаотичность данных = признак шифрования!).
➖ Скорость чтения/записи.
➖ Разброс адресов (LBA) на диске.
🧠 Паттерны доступа к Памяти (RAM) через Intel EPT:
➖ Энтропия операций записи.
➖ Количество нарушений EPT (аппаратный счётчик обращений к памяти!).
➖ Разброс физических адресов (GPA) в памяти.
📊 Каждую секунду в течение 30 секунд формировался 23-мерный вектор признаков — уникальный "цифровой отпечаток" поведения.
💥 Результаты: ИИ можно обмануть (уже сейчас!)
1⃣ Контроль есть! Изменяя параметры (потоки/коэфф./задержку), авторы существенно меняли низкоуровневые паттерны доступа. Conti *действительно* вел себя по-разному.
2⃣ Атака работает! Точность обнаружения (Recall) ИИ-детектора упала с 0.98 до 0.64! В некоторых конфигурациях поведение модифицированного Conti было статистически ближе к SDelete (легитимная утилита стирания!), чем к "классическому" вымогателю.
3⃣ Пока неидеально: Успешность атаки ~36% (1 - 0.64) — серьезно, но недостаточно для надежного уклонения.
Эволюция: Текущий Рос использует лишь 3 параметра. Представьте инструменты, автоматически генерирующие оптимальный обходной код на основе атаки на "суррогатную" модель ИИ-защиты (grey-box)! Это следующий шаг.
🔗 Полный текст исследования читайте тут
Stay secure and read SecureTechTalks 📚
#Ransomware #AdversarialAI #MachineLearning #CyberSecurity #ThreatIntelligence #Conti #BitVisor #ИБ
Ransomware, который знает, как обмануть вашу систему ИИ-защиты.
Исследователи из Японии создали PoC Ransomware на базе печально известного Conti. Разбираем трендовое исследование, которое переворачивает представление о борьбе с шифровальщиками.
🔍 О чем вообще речь?
Традиционные ИИ-детекторы ransomware анализируют поведение вредоноса в системе (доступ к файлам, вызовы API, сетевую активность). Но злоумышленники учаться *точечно изменять* патерны поведения, чтобы оно "имитировало" легитимный софт.
👉 Adversarial Examples (враждебные примеры) - это метод, позаимствованный из мира компьютерного зрения (помните, как добавляли шум к фото панды, и ИИ видел гиббона?). Здесь "шум" - это микро-изменения в работе ransomware!
🤯 Сложность №1: Поведение ≠ Пиксели
С картинкой просто: добавил невидимый шум к пикселям — получил adversarial example.
С вредоносным ПО сложно: Нельзя просто "добавить шум" к поведению. Нужно физически изменить исходный код так, чтобы:
- Вирус остался функциональным (шифровал файлы!).
- Его поведение изменилось ровно настолько, чтобы обмануть ИИ.
- Производительность не упала катастрофически (иначе атака бесполезна).
💡 Решение ученых: Микроповеденческий Контроль
Исследователи взяли утекший исходный код Conti ransomware и встроили в него "ручки управления":
1⃣ Число потоков (Threads): Сколько параллельных потоков шифрует файлы? (1-3 потока).
2⃣ Коэффициент шифрования (Encryption Ratio): Шифровать файл целиком (100%) или частично (50%)? (Частичное шифрование меняет статистику данных!).
4⃣ Задержка после шифрования (Delay): Добавить паузу после шифрования каждого файла? (0мс, 25мс, 50мс, 100мс).
👉 Идея: Комбинируя эти параметры при запуске (как аргументы командной строки), можно получить 24 разных "поведенческих профиля" одного и того же Conti! Это и есть симуляция "изменения исходного кода" для генерации
behavioral adversarial examples.🔬 Как измеряли "поведение"?
Детектор, который атаковали, использует не просто вызовы API, а данные гипервизора BitVisor, смотрящего "сквозь" ОС:
📁 Паттерны доступа к Хранилищу (Storage):
🧠 Паттерны доступа к Памяти (RAM) через Intel EPT:
📊 Каждую секунду в течение 30 секунд формировался 23-мерный вектор признаков — уникальный "цифровой отпечаток" поведения.
💥 Результаты: ИИ можно обмануть (уже сейчас!)
1⃣ Контроль есть! Изменяя параметры (потоки/коэфф./задержку), авторы существенно меняли низкоуровневые паттерны доступа. Conti *действительно* вел себя по-разному.
2⃣ Атака работает! Точность обнаружения (Recall) ИИ-детектора упала с 0.98 до 0.64! В некоторых конфигурациях поведение модифицированного Conti было статистически ближе к SDelete (легитимная утилита стирания!), чем к "классическому" вымогателю.
3⃣ Пока неидеально: Успешность атаки ~36% (1 - 0.64) — серьезно, но недостаточно для надежного уклонения.
Эволюция: Текущий Рос использует лишь 3 параметра. Представьте инструменты, автоматически генерирующие оптимальный обходной код на основе атаки на "суррогатную" модель ИИ-защиты (grey-box)! Это следующий шаг.
🔗 Полный текст исследования читайте тут
Stay secure and read SecureTechTalks 📚
#Ransomware #AdversarialAI #MachineLearning #CyberSecurity #ThreatIntelligence #Conti #BitVisor #ИБ
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🔥🛡 FRAME: фреймворк для оценки рисков атак на ML-модели!
👾 Adversarial Machine Learning (AML) - это реальная угроза. Вашу ML-модель можно атаковать так же, как сервер или веб-приложение. Но как понять, какие атаки действительно угрожают именно вашей системе?
До сих пор у нас не было универсального ответа.
Команда из Университета Бен-Гуриона представила FRAME - комплексный и автоматизированный инструмент для оценки рисков AML-атак. Это рабочий фреймворк, проверенный на реальных сценариях.
🤔 Где скрывалась проблема?
Классические системы анализа киберрисков (CVSS, MITRE ATT&CK) не учитывают уникальные уязвимости ML-моделей.
А существующие AML-инструменты (например, ART) оценивают лишь «устойчивость» модели к отдельным атакам, но игнорируют:
🌐 где развёрнута система,
🕵️ кто атакует (хакер, инсайдер, клиент),
⚖️ насколько реальна атака,
💥 какой бизнес-ущерб она нанесёт.
FRAME решает все эти вопросы системно.
⚙️ Как работает FRAME
Фреймворк построен из пяти взаимосвязанных компонентов:
📋 System Profiling - владелец системы заполняет анкету. LLM помогает адаптировать вопросы под конкретный use-case. Сразу оцениваются архитектура модели, данные, безопасность и критичность атак.
🗺 Attack Feasibility Mapping - карта из 86 атак AML (от Membership Inference до Evasion), связанная с факторами успешности и последствий.
📊 Performance Data Integration - база знаний из 1000+ научных статей, где описана успешность атак в реальных условиях.
🧮 Risk Modeling - расчёт итогового риска:
Риск = (Возможность атаки) × (Успешность) × (Воздействие)
Учитываются цифровые и физические атаки.
📈 Risk Ranking - ранжированный список TOP-угроз для вашей системы, плюс сгенерированные LLM сценарии атак.
🚨 Пример: E-commerce
ML-модель сортирует отзывы покупателей. Недобросовестный продавец решает обмануть систему:
🥇 Black-Box Interactive Evasion (риск ~6/10). Злоумышленник подбирает тексты до тех пор, пока модель не даёт нужный результат.
🥈 Black-Box Transferable Evasion (риск ~5.6/10). Тренирует surrogate-модель и создаёт «ядовитые» примеры.
🥉 Resource-Latency Attack (риск ~2.8/10). Создаёт отзывы, перегружающие систему, снижая доступность.
💡 Инсайты исследования
👑 Integrity-атаки доминируют (80%+ случаев). В NLP их доля доходит до 94%!
💻 Цифровые атаки эффективнее физических. Исключение — голосовые системы, где физические приёмы работают лучше.
⚖️ White-Box vs Black-Box почти 50/50, но домен решает:
NLP и Cyber - чаще Black-Box,
CV - White-Box.
⏳ Атаки на доступность редки (4%), но критически важны для real-time систем (например, спутниковая связь).
✅ Проверка боем
FRAME уже протестирован на 6 реальных кейсах (от антиспама до спутниковых сигналов).
Эксперты по AML оценили точность работы:
🎯 Overall Accuracy: 9/10
📌 Релевантность TOP-5 атак: ~9/10
Вывод: FRAME не просто генерирует список атак, а правильно расставляет приоритеты.
🔮 Планы на будущее
Авторы планируют добавить:
🛡️ автоматические рекомендации по защите (например, как adversarial training меняет оценку риска),
🤖 поддержку многомодельных систем,
📂 открытый доступ к коду и датасету.
🔗 Подробнее читайте в статье
Stay secure and read SecureTechTalks 📚
#FRAME #AdversarialML #MachineLearning #AIsecurity #RiskAssessment #Кибербезопасность #ML #ИБ
👾 Adversarial Machine Learning (AML) - это реальная угроза. Вашу ML-модель можно атаковать так же, как сервер или веб-приложение. Но как понять, какие атаки действительно угрожают именно вашей системе?
До сих пор у нас не было универсального ответа.
Команда из Университета Бен-Гуриона представила FRAME - комплексный и автоматизированный инструмент для оценки рисков AML-атак. Это рабочий фреймворк, проверенный на реальных сценариях.
🤔 Где скрывалась проблема?
Классические системы анализа киберрисков (CVSS, MITRE ATT&CK) не учитывают уникальные уязвимости ML-моделей.
А существующие AML-инструменты (например, ART) оценивают лишь «устойчивость» модели к отдельным атакам, но игнорируют:
🌐 где развёрнута система,
🕵️ кто атакует (хакер, инсайдер, клиент),
⚖️ насколько реальна атака,
💥 какой бизнес-ущерб она нанесёт.
FRAME решает все эти вопросы системно.
⚙️ Как работает FRAME
Фреймворк построен из пяти взаимосвязанных компонентов:
📋 System Profiling - владелец системы заполняет анкету. LLM помогает адаптировать вопросы под конкретный use-case. Сразу оцениваются архитектура модели, данные, безопасность и критичность атак.
🗺 Attack Feasibility Mapping - карта из 86 атак AML (от Membership Inference до Evasion), связанная с факторами успешности и последствий.
📊 Performance Data Integration - база знаний из 1000+ научных статей, где описана успешность атак в реальных условиях.
🧮 Risk Modeling - расчёт итогового риска:
Риск = (Возможность атаки) × (Успешность) × (Воздействие)
Учитываются цифровые и физические атаки.
📈 Risk Ranking - ранжированный список TOP-угроз для вашей системы, плюс сгенерированные LLM сценарии атак.
🚨 Пример: E-commerce
ML-модель сортирует отзывы покупателей. Недобросовестный продавец решает обмануть систему:
🥇 Black-Box Interactive Evasion (риск ~6/10). Злоумышленник подбирает тексты до тех пор, пока модель не даёт нужный результат.
🥈 Black-Box Transferable Evasion (риск ~5.6/10). Тренирует surrogate-модель и создаёт «ядовитые» примеры.
🥉 Resource-Latency Attack (риск ~2.8/10). Создаёт отзывы, перегружающие систему, снижая доступность.
💡 Инсайты исследования
👑 Integrity-атаки доминируют (80%+ случаев). В NLP их доля доходит до 94%!
💻 Цифровые атаки эффективнее физических. Исключение — голосовые системы, где физические приёмы работают лучше.
⚖️ White-Box vs Black-Box почти 50/50, но домен решает:
NLP и Cyber - чаще Black-Box,
CV - White-Box.
⏳ Атаки на доступность редки (4%), но критически важны для real-time систем (например, спутниковая связь).
✅ Проверка боем
FRAME уже протестирован на 6 реальных кейсах (от антиспама до спутниковых сигналов).
Эксперты по AML оценили точность работы:
🎯 Overall Accuracy: 9/10
📌 Релевантность TOP-5 атак: ~9/10
Вывод: FRAME не просто генерирует список атак, а правильно расставляет приоритеты.
🔮 Планы на будущее
Авторы планируют добавить:
🛡️ автоматические рекомендации по защите (например, как adversarial training меняет оценку риска),
🤖 поддержку многомодельных систем,
📂 открытый доступ к коду и датасету.
🔗 Подробнее читайте в статье
Stay secure and read SecureTechTalks 📚
#FRAME #AdversarialML #MachineLearning #AIsecurity #RiskAssessment #Кибербезопасность #ML #ИБ
🤖 LLM и приватность данных: почему исследования ИИ смотрят не туда
Недавнее исследование от Carnegie Mellon University и Northeastern University показало любопытную (и немного тревожную) картину:
большинство научных работ по приватности в ИИ сосредоточено не там, где реально горит 🔥
🧠 Спойлер:учёные посмотрели на 1 322 публикации за последние 9 лет и поняли - 9 из 10 исследователей копают один и тот же узкий участок,
в то время как поле вокруг уже тлеет по периметру.
📚 Что обнаружили?
📊 92% исследований касаются двух тем:
1️⃣ защиты обучающих данных
2️⃣ утечек истории чатов пользователей
💡 Остальные 8% - это всё, что происходит за пределами лаборатории:
🕵️ инференс-атаки
🔌 утечки через агентные системы
🧩 сбор и корреляция данных между сервисами
🗂️ скрытые профили пользователей
Итог: сотни статей о том, как не дать модели запомнить пароль,
но почти ни одной - о том, куда потом улетает ваш разговор с моделью,
если она встроена в корпоративного помощника 🤷♂️
🧩 Приватность ≠ конфиденциальность
Учёные предлагают новую таксономию утечек:
1️⃣ 🧠 Утечки обучающих данных
2️⃣ 💬 Прямая утечка чатов
3️⃣ 🔗 Косвенные утечки через интеграции и плагины
4️⃣ 🧮 Инференс - когда модель «угадывает» ваши данные
5️⃣ 🧱 Агрегация - сбор публичной информации в личные профили
🔎 Ключевая мысль:
данные утекают не потому, что «хакнули базу»,
а потому, что модель слишком хорошо связывает точки 🕸️
🧱 Иллюзия выбора
Контроль чаще всего иллюзия:
❌ формы обратной связи продолжают храниться
❌ данные остаются «для безопасности» или «комплаенса»
❌ удаление можно отменить внутренним регламентом
Иными словами: галочка «не использовать мои данные» может быть просто декоративной...
⚙️ Новое вызовы - агентные системы
Когда LLM превращаются в агентов, которые ходят в базы данных, CRM, Jira или Slack -
начинается настоящий ад!
🕳️ Пользователь не видит, что именно делает агент:
ищет отчёт... или выгружает фрагменты данных из другой системы?
👁️🗨️ Контроль за агентами - почти «чёрный ящик».
И надеяться, что пользователи сами будут следить за этим, наивно.
💡 Приватность должна быть встроена в дизайн, а не прикручена сверху.
🧠 Что же делать?
🧰 5 правил кибер-гигиены для LLM-систем:
1️⃣ Проверяйте LLM-поставщиков.
🔍 Запрашивайте отчёты: где и как хранятся пользовательские данные.
2️⃣ Минимизируйте сбор данных.
🧹 Чем меньше храните - тем меньше сможете потерять.
3️⃣ Аудитируйте агентов.
🧾 Даже внутренних. Логируйте контексты и действия.
4️⃣ Встраивайте приватность в архитектуру.
🧱 Не плагином, а фундаментом.
5️⃣ Обучайте пользователей.
💬 Разговор с ИИ = API-запрос с контекстом, а не безобидный чат.
➡️ ИИ умеет помнить, обобщать и делать выводы -
а значит, ошибок «по невнимательности» больше не бывает.
🔗 Источник: arxive.org
Stay secure and read SecureTechTalks 📚
#cybersecurity #infosec #LLM #AIprivacy #dataprotection #securedevelopment #cyberthreats #securityawareness #machinelearning #SecureTechTalks
Недавнее исследование от Carnegie Mellon University и Northeastern University показало любопытную (и немного тревожную) картину:
большинство научных работ по приватности в ИИ сосредоточено не там, где реально горит 🔥
🧠 Спойлер:
в то время как поле вокруг уже тлеет по периметру.
📚 Что обнаружили?
📊 92% исследований касаются двух тем:
1️⃣ защиты обучающих данных
2️⃣ утечек истории чатов пользователей
💡 Остальные 8% - это всё, что происходит за пределами лаборатории:
🕵️ инференс-атаки
🔌 утечки через агентные системы
🧩 сбор и корреляция данных между сервисами
🗂️ скрытые профили пользователей
Итог: сотни статей о том, как не дать модели запомнить пароль,
но почти ни одной - о том, куда потом улетает ваш разговор с моделью,
если она встроена в корпоративного помощника 🤷♂️
🧩 Приватность ≠ конфиденциальность
Учёные предлагают новую таксономию утечек:
1️⃣ 🧠 Утечки обучающих данных
2️⃣ 💬 Прямая утечка чатов
3️⃣ 🔗 Косвенные утечки через интеграции и плагины
4️⃣ 🧮 Инференс - когда модель «угадывает» ваши данные
5️⃣ 🧱 Агрегация - сбор публичной информации в личные профили
🔎 Ключевая мысль:
данные утекают не потому, что «хакнули базу»,
а потому, что модель слишком хорошо связывает точки 🕸️
🧱 Иллюзия выбора
Контроль чаще всего иллюзия:
❌ формы обратной связи продолжают храниться
❌ данные остаются «для безопасности» или «комплаенса»
❌ удаление можно отменить внутренним регламентом
🧨 Учёные называют это «эрозией приватности под маской выбора».
Иными словами: галочка «не использовать мои данные» может быть просто декоративной...
⚙️ Новое вызовы - агентные системы
Когда LLM превращаются в агентов, которые ходят в базы данных, CRM, Jira или Slack -
начинается настоящий ад!
🕳️ Пользователь не видит, что именно делает агент:
ищет отчёт... или выгружает фрагменты данных из другой системы?
👁️🗨️ Контроль за агентами - почти «чёрный ящик».
И надеяться, что пользователи сами будут следить за этим, наивно.
💡 Приватность должна быть встроена в дизайн, а не прикручена сверху.
🧠 Что же делать?
🧰 5 правил кибер-гигиены для LLM-систем:
1️⃣ Проверяйте LLM-поставщиков.
🔍 Запрашивайте отчёты: где и как хранятся пользовательские данные.
2️⃣ Минимизируйте сбор данных.
🧹 Чем меньше храните - тем меньше сможете потерять.
3️⃣ Аудитируйте агентов.
🧾 Даже внутренних. Логируйте контексты и действия.
4️⃣ Встраивайте приватность в архитектуру.
🧱 Не плагином, а фундаментом.
5️⃣ Обучайте пользователей.
💬 Разговор с ИИ = API-запрос с контекстом, а не безобидный чат.
➡️ ИИ умеет помнить, обобщать и делать выводы -
а значит, ошибок «по невнимательности» больше не бывает.
🔗 Источник: arxive.org
Stay secure and read SecureTechTalks 📚
#cybersecurity #infosec #LLM #AIprivacy #dataprotection #securedevelopment #cyberthreats #securityawareness #machinelearning #SecureTechTalks
1❤1👍1🔥1🤝1
🚨 OpenAI выпустила GPT-OSS Safeguard: открытую систему безопасности для ИИ
Компания OpenAI представила GPT-OSS Safeguard: набор открытых моделей, которые помогают проверять безопасность контента и отслеживать корректность работы других нейросетей.
Это шаг к тому, чтобы сделать процессы Trust & Safety прозрачнее и управляемее.
🧩 OpenAI выпустила две модели: gpt-oss-safeguard-120B и gpt-oss-safeguard-20B.
Обе доступны с открытыми весами по лицензии Apache 2.0 их можно использовать, модифицировать и запускать локально.
📜 Модель принимает правила безопасности (policy) во время выполнения.
Разработчик может задать собственные критерии, и Safeguard классифицирует запросы или ответы по этим правилам.
💬 Ещё одно преимущество в том, что модель возвращает обоснование решения (chain-of-thought), что делает проверку прозрачной ив теории пригодной для аудита.
Подробнее в официальном блоге OpenAI.
🧠 Что умеет модель?
🤖 Модель анализирует текст, сопоставляет его с правилами и выдает оценку риска.
Например, она может определить, что сообщение содержит обход фильтра, и пометить его как «high risk».
📊 Вместо обычного «разрешено/запрещено» Safeguard объясняет, почему принято то или иное решение.
Это можно использовать для логирования, расследований и улучшения политики безопасности.
🔐 Новые возможности
Safeguard позволяет:
⚙️ внедрять собственные правила и политики проверки;
🔒 запускать модель внутри корпоративного периметра;
📑 анализировать reasoning-цепочки при расследованиях;
🧠 адаптировать правила без повторного обучения модели.
Открытые веса делают систему гибкой и позволяют интегрировать её в решения, где важно хранить данные локально.
⚠️ Риски
🔓 Открытые модели это не только гибкость, но и сложность настройки.
Если политика безопасности описана неточно, возможны ошибки классификации и ложные срабатывания.
🧨 Reasoning-модели можно обмануть подобранными запросами (prompt injection), поэтому нужно внедрять дополнительные инструменты защиты.
💬 Вопросы, на которые предстоит ответить
❓ Насколько reasoning реально помогает в аудите?
🧩 Можно ли избежать утечек через объяснения модели?
⚡ Подходит ли Safeguard для real-time систем?
Stay secure and read SecureTechTalks 📚
#OpenAI #ИИ #Кибербезопасность #TrustAndSafety #AIsecurity #MachineLearning #DataProtection #CyberThreats #TechNews #SecureTechTalks
Компания OpenAI представила GPT-OSS Safeguard: набор открытых моделей, которые помогают проверять безопасность контента и отслеживать корректность работы других нейросетей.
Это шаг к тому, чтобы сделать процессы Trust & Safety прозрачнее и управляемее.
🧩 OpenAI выпустила две модели: gpt-oss-safeguard-120B и gpt-oss-safeguard-20B.
Обе доступны с открытыми весами по лицензии Apache 2.0 их можно использовать, модифицировать и запускать локально.
📜 Модель принимает правила безопасности (policy) во время выполнения.
Разработчик может задать собственные критерии, и Safeguard классифицирует запросы или ответы по этим правилам.
💬 Ещё одно преимущество в том, что модель возвращает обоснование решения (chain-of-thought), что делает проверку прозрачной и
Подробнее в официальном блоге OpenAI.
🧠 Что умеет модель?
🤖 Модель анализирует текст, сопоставляет его с правилами и выдает оценку риска.
Например, она может определить, что сообщение содержит обход фильтра, и пометить его как «high risk».
📊 Вместо обычного «разрешено/запрещено» Safeguard объясняет, почему принято то или иное решение.
Это можно использовать для логирования, расследований и улучшения политики безопасности.
🔐 Новые возможности
Safeguard позволяет:
⚙️ внедрять собственные правила и политики проверки;
🔒 запускать модель внутри корпоративного периметра;
📑 анализировать reasoning-цепочки при расследованиях;
🧠 адаптировать правила без повторного обучения модели.
Открытые веса делают систему гибкой и позволяют интегрировать её в решения, где важно хранить данные локально.
⚠️ Риски
🔓 Открытые модели это не только гибкость, но и сложность настройки.
Если политика безопасности описана неточно, возможны ошибки классификации и ложные срабатывания.
🧨 Reasoning-модели можно обмануть подобранными запросами (prompt injection), поэтому нужно внедрять дополнительные инструменты защиты.
💬 Вопросы, на которые предстоит ответить
❓ Насколько reasoning реально помогает в аудите?
🧩 Можно ли избежать утечек через объяснения модели?
⚡ Подходит ли Safeguard для real-time систем?
Stay secure and read SecureTechTalks 📚
#OpenAI #ИИ #Кибербезопасность #TrustAndSafety #AIsecurity #MachineLearning #DataProtection #CyberThreats #TechNews #SecureTechTalks
🔥2
🕵️♂️ Почему «сильные» пароли это обман.
Большинство популярных сервисов уверенно ставят вам зелёную галочку “Strong Password”.
Однако эта галочка почти ничего не значит.
🔍 Как индустрия годами вводила пользователей в заблуждение
Правила LUDS (заглавная, цифра, спецсимвол) породили миллионы одинаковых «сложных» паролей:
P@ssw0rd123!, Qwerty2024!, Admin!2023.
Они проходят проверки, но ломаются мгновенно, потому что построены на предсказуемых паттернах.
🧬 Исследование
Для оценки был создан гибридный feature set, который:
- нормализует leetspeak (P@ssw0rd → password);
- ищет клавиатурные паттерны (1234, qwerty, asdf);
- анализирует n-граммы через TF-IDF;
- выявляет dictionary words;
учитывает реальный charset.
Затем обучены 4 модели: Random Forest, SVM, CNN, Logistic Regression.
По итогу лучше всех с задачей справляется Random Forest: 99.12% по F1 score.⚡
⚠️ Что является «серой зоной»?
Средняя категория самое интересное место:
- P@ssword123!: выглядит сложно, но внутри dictionary + predictable pattern.
- boatboatboat1: длинный, но энтропия низкая.
- asdf!@#$: декоративный шум, но является клавиатурной последовательностью.
Традиционные проверялки ставят этим паролям “хорошо”.
Модель говорит - “опасно”.
🧨 Что по итогу?
➖ LUDS-правила устарели.
➖ Популярные password meters создают ложную уверенность.
➖ Реальную сложность определяют не символы, а непредсказуемость структуры.
Stay secure and read SecureTechTalks 📚
#cybersecurity #passwords #infosec #investigation #machinelearning #randomforest #entropy #SecureTechTalks
Большинство популярных сервисов уверенно ставят вам зелёную галочку “Strong Password”.
Однако эта галочка почти ничего не значит.
🔍 Как индустрия годами вводила пользователей в заблуждение
Правила LUDS (заглавная, цифра, спецсимвол) породили миллионы одинаковых «сложных» паролей:
P@ssw0rd123!, Qwerty2024!, Admin!2023.
Они проходят проверки, но ломаются мгновенно, потому что построены на предсказуемых паттернах.
🧬 Исследование
Для оценки был создан гибридный feature set, который:
- нормализует leetspeak (P@ssw0rd → password);
- ищет клавиатурные паттерны (1234, qwerty, asdf);
- анализирует n-граммы через TF-IDF;
- выявляет dictionary words;
учитывает реальный charset.
Затем обучены 4 модели: Random Forest, SVM, CNN, Logistic Regression.
По итогу лучше всех с задачей справляется Random Forest: 99.12% по F1 score.⚡
⚠️ Что является «серой зоной»?
Средняя категория самое интересное место:
- P@ssword123!: выглядит сложно, но внутри dictionary + predictable pattern.
- boatboatboat1: длинный, но энтропия низкая.
- asdf!@#$: декоративный шум, но является клавиатурной последовательностью.
Традиционные проверялки ставят этим паролям “хорошо”.
Модель говорит - “опасно”.
🧨 Что по итогу?
Stay secure and read SecureTechTalks 📚
#cybersecurity #passwords #infosec #investigation #machinelearning #randomforest #entropy #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Ваша ML-модель может выдавать приватные данные
Исследователи предложили метод наблюдательного аудита, который позволяет проверить, насколько обученная ML-модель невольно «запоминает» исходные данные и может ли она сливать информацию о метках (labels). Главное преимущество, что метод не требует изменения тестового пайплайна и не использует фиктивные записи.
🔗 Исследование: https://arxiv.org/abs/2411.18644
Чтобы провести аудит, после завершения обучения модели создают набор меток, представляющий собой смесь из:
• реальных меток, действительно использованных при обучении,
• прокси-меток, сгенерированных другой моделью или более ранним чекпоинтом той же модели.
Далее «атакующая» сторона получает задачу отличить настоящие метки от искусственно сгенерированных. Логика проста:
Если модель выдаёт слишком много подсказок о настоящих метках, это означает, что она их запомнила и значит, существует риск утечек.
То есть, чем менее различимы настоящие и прокси-метки, тем лучше модель защищена.
📊 Глубже в эксперимент
Исследователи протестировали метод на двух типах данных:
• небольшом визуальном датасете с изображениями;
• крупном кликовом датасете (click data), который лучше отражает реальные промышленные условия.
🔍 Результаты:
➖ при жёстких параметрах приватности модель переставала «выдавать» настоящие метки. Атака оказывалась беспомощной;
➖ при ослабленных параметрах приватности различить настоящие метки становилось проще, и атака уверенно угадывала значительную их часть.
По факту результаты совпадают с классическими тестами на канарейках. Это значит, что новый метод действительно способен обнаруживать утечки, но при этом не требует изменения структуры данных или вмешательства в процесс обучения.
🧩 В чем профит?
➖ Метод устраняет инженерный барьер, который существовал в классической модели канареек, где требовалось добавлять искусственные записи.
➖ Теперь проверка приватности может проводиться часто и автоматически, без риска нарушить рабочий ML-pipeline.
➖ Благодаря тому, что атака опирается на способность модели различать реальные и искусственные метки, она хорошо отражает именно то, что происходит внутри модели, то есть её склонность к меморизации.
➖ Подход универсален: его можно применять как к небольшим экспериментальным моделям, так и к реальным коммерческим системам, где любые изменения данных затруднены.
Stay secure and read SecureTechTalks 📚
#cybersecurity #mlsecurity #privacy #machinelearning #infosec #deeplearning #dataleakage #AIprivacy #securityresearch #SecureTechTalks
Исследователи предложили метод наблюдательного аудита, который позволяет проверить, насколько обученная ML-модель невольно «запоминает» исходные данные и может ли она сливать информацию о метках (labels). Главное преимущество, что метод не требует изменения тестового пайплайна и не использует фиктивные записи.
🔗 Исследование: https://arxiv.org/abs/2411.18644
Чтобы провести аудит, после завершения обучения модели создают набор меток, представляющий собой смесь из:
• реальных меток, действительно использованных при обучении,
• прокси-меток, сгенерированных другой моделью или более ранним чекпоинтом той же модели.
Далее «атакующая» сторона получает задачу отличить настоящие метки от искусственно сгенерированных. Логика проста:
Если модель выдаёт слишком много подсказок о настоящих метках, это означает, что она их запомнила и значит, существует риск утечек.
То есть, чем менее различимы настоящие и прокси-метки, тем лучше модель защищена.
📊 Глубже в эксперимент
Исследователи протестировали метод на двух типах данных:
• небольшом визуальном датасете с изображениями;
• крупном кликовом датасете (click data), который лучше отражает реальные промышленные условия.
🔍 Результаты:
По факту результаты совпадают с классическими тестами на канарейках. Это значит, что новый метод действительно способен обнаруживать утечки, но при этом не требует изменения структуры данных или вмешательства в процесс обучения.
🧩 В чем профит?
Stay secure and read SecureTechTalks 📚
#cybersecurity #mlsecurity #privacy #machinelearning #infosec #deeplearning #dataleakage #AIprivacy #securityresearch #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🧠 Как взломать нейросеть, не трогая её весов
Когда говорят об атаках на ИИ, в первую очередь вспоминают про два сценария:
🔐 либо атакующий крадёт веса модели,
🎯 либо подсовывает ей очевидные adversarial-примеры с шумом, которые выглядят странно даже для человека.
Но есть нще множество других уязвимостей. Например, нейросеть можно системно ломать, не имея доступа ни к весам, ни к обучающим данным, и при этом атака будет выглядеть как «нормальная работа системы».
🔧 Как выглядит типичная AI-система
Если отбросить маркетинг, почти любая production-система с ИИ устроена примерно одинаково:
1️⃣ Источник данных: камера, микрофон, лог, поток транзакций
2️⃣ Предобработка: драйверы, кодеки, SDK, нормализация
3️⃣ Модель, чаще всего закрытая и недоступная извне
4️⃣ Бизнес-логика: принимает решения на основе вывода модели
Второй пункт часто считают «технической деталью», а не частью attack surface, однако именно здесь находится точка входа атаки про которую пойдет речь.
🎯 В чём идея
Ключевая мысль:
Атака строится так, чтобы:
✅ данные выглядели валидными
✅ человек визуально или логически не замечал изменений
✅ инфраструктура не генерировала ошибок
❌ модель начинала систематически ошибаться
🪜 Атака шаг за шагом
🔹 Шаг 1. Модель
Атакующий:
- не знает архитектуру 🧠
- не имеет доступа к весам 🔒
- не управляет обучением 📚
🔹 Шаг 2. Контроль над ранним этапом обработки
Зато атакующий может влиять на компонент, который формально не считается частью ИИ:
📷 прошивка камеры
🎞️ видеокодек
🧩 библиотека нормализации
⚙️ edge-модуль
🌐 прокси перед моделью
Эти элементы обычно:
работают автоматически
считаются доверенными
редко проходят security-аудит как часть ML-системы
🔹 Шаг 3. Атакуют трансформацию, а не модель
Дальше атакующий оптимизирует преобразование входных данных.
🎯 Цель:
минимально изменить вход
сохранить «нормальный» вид для человека
сломать признаки, на которых обучалась модель
В результате модель:
🚫 перестаёт видеть объекты
🔀 путает классы
🙈 игнорирует нужные сигналы
При этом inference работает штатно, а ошибки выглядят «естественными».
🔹 Шаг 4. Масштабирование атаки
Атака оказывается универсальной.
⚠️ Одна трансформация:
работает на тысячах входов
сохраняется при смене сцен
часто переживает дообучение модели
Фактически, один скомпрометированный препроцессор начинает определять, что именно “видит” ИИ.
🧪 Почему это не классические adversarial examples
Классические adversarial-атаки:
- хрупкие
- плохо масштабируются
- ломаются при изменении модели
Здесь же речь идёт об инфраструктурной атаке:
встроенной в pipeline
По сути 🧨 supply-chain атака на AI-систему.
🌍 Практические сценарии
📹 Видеонаблюдение
Человек видит сцену,
ИИ «не видит» людей или предметы.
💳 Антифрод
Транзакции выглядят валидно,
но модель не распознаёт мошенничество.
🏥 Медицина
Изображение корректно,
но патология «исчезает» для ИИ, влияя на приоритезацию.
Во всех случаях это выглядит как деградация качества, а не как атака.
➡️ Пока внимание сосредоточено на весах и датасетах, реальные атаки уходят в инфраструктуру вокруг модели. Именно там сегодня находится самая недооценённая поверхность атаки.
🔗 Оригинальная работа:
https://arxiv.org/abs/2512.06914
Stay secure and read SecureTechTalks 📚
#AISecurity #MachineLearning #CyberSecurity #AdversarialAI #SupplyChainSecurity #AppSec #Infosec #ComputerVision #MLSecurity
Когда говорят об атаках на ИИ, в первую очередь вспоминают про два сценария:
🔐 либо атакующий крадёт веса модели,
🎯 либо подсовывает ей очевидные adversarial-примеры с шумом, которые выглядят странно даже для человека.
Но есть нще множество других уязвимостей. Например, нейросеть можно системно ломать, не имея доступа ни к весам, ни к обучающим данным, и при этом атака будет выглядеть как «нормальная работа системы».
🔧 Как выглядит типичная AI-система
Если отбросить маркетинг, почти любая production-система с ИИ устроена примерно одинаково:
1️⃣ Источник данных: камера, микрофон, лог, поток транзакций
2️⃣ Предобработка: драйверы, кодеки, SDK, нормализация
3️⃣ Модель, чаще всего закрытая и недоступная извне
4️⃣ Бизнес-логика: принимает решения на основе вывода модели
Второй пункт часто считают «технической деталью», а не частью attack surface, однако именно здесь находится точка входа атаки про которую пойдет речь.
🎯 В чём идея
Ключевая мысль:
🧩 Если атакующий управляет тем, как данные подаются в модель,
он управляет решениями модели, не трогая её веса.
Атака строится так, чтобы:
✅ данные выглядели валидными
✅ человек визуально или логически не замечал изменений
✅ инфраструктура не генерировала ошибок
❌ модель начинала систематически ошибаться
🪜 Атака шаг за шагом
🔹 Шаг 1. Модель
Атакующий:
- не знает архитектуру 🧠
- не имеет доступа к весам 🔒
- не управляет обучением 📚
🔹 Шаг 2. Контроль над ранним этапом обработки
Зато атакующий может влиять на компонент, который формально не считается частью ИИ:
📷 прошивка камеры
🎞️ видеокодек
🧩 библиотека нормализации
⚙️ edge-модуль
🌐 прокси перед моделью
Эти элементы обычно:
работают автоматически
считаются доверенными
редко проходят security-аудит как часть ML-системы
🔹 Шаг 3. Атакуют трансформацию, а не модель
Дальше атакующий оптимизирует преобразование входных данных.
🎯 Цель:
минимально изменить вход
сохранить «нормальный» вид для человека
сломать признаки, на которых обучалась модель
В результате модель:
🚫 перестаёт видеть объекты
🔀 путает классы
🙈 игнорирует нужные сигналы
При этом inference работает штатно, а ошибки выглядят «естественными».
🔹 Шаг 4. Масштабирование атаки
Атака оказывается универсальной.
⚠️ Одна трансформация:
работает на тысячах входов
сохраняется при смене сцен
часто переживает дообучение модели
Фактически, один скомпрометированный препроцессор начинает определять, что именно “видит” ИИ.
🧪 Почему это не классические adversarial examples
Классические adversarial-атаки:
- хрупкие
- плохо масштабируются
- ломаются при изменении модели
Здесь же речь идёт об инфраструктурной атаке:
встроенной в pipeline
По сути 🧨 supply-chain атака на AI-систему.
🌍 Практические сценарии
📹 Видеонаблюдение
Человек видит сцену,
ИИ «не видит» людей или предметы.
💳 Антифрод
Транзакции выглядят валидно,
но модель не распознаёт мошенничество.
🏥 Медицина
Изображение корректно,
но патология «исчезает» для ИИ, влияя на приоритезацию.
Во всех случаях это выглядит как деградация качества, а не как атака.
➡️ Пока внимание сосредоточено на весах и датасетах, реальные атаки уходят в инфраструктуру вокруг модели. Именно там сегодня находится самая недооценённая поверхность атаки.
🔗 Оригинальная работа:
https://arxiv.org/abs/2512.06914
Stay secure and read SecureTechTalks 📚
#AISecurity #MachineLearning #CyberSecurity #AdversarialAI #SupplyChainSecurity #AppSec #Infosec #ComputerVision #MLSecurity
🚨 GPT проигрывает классическим подходам ИБ
Разметка MITRE ATT&CK показала пределы LLM
🧠 Автоматическая разметка текстов по MITRE
ATT&CK давно остаётся одной из самых востребованных задач в кибербезопасности. Каждый день аналитики читают отчёты, threat intelligence, сценарии атак и описания уязвимостей, связывая их с тактиками и техниками противника. Это монотонная, дорогая и плохо масштабируемая работа. Не удивительно, что попытки её автоматизировать ведутся уже больше десяти лет.
📄 В январе 2026 года команда JPMorgan Chase опубликовала техническую работу, которая пытаеся решить проблему в новом ключе. Авторы напрямую сравнили GPT-4o и классический машинный подход, SGD-классификатор на TF-IDF.
👉 Arxiv
⚙️ Эксперимент был предельно прагматичным. Моделям давали отдельные предложения из threat intelligence и просили определить соответствующую тактику MITRE ATT&CK.
Классическая модель показала около 82% точности, GPT-4o остановился примерно на 59%. Разница особенно заметна в редких тактиках и в ситуациях, где требуется строгое соответствие идентификаторам и терминологии ATT&CK.
🧩 Как авторы посмотрели на задачу.
«Разметка MITRE» не один шаг, а целый спектр задач разной сложности. В реальности один текст может соответствовать сразу нескольким тактикам, а каждая тактика нескольким техникам, связанным иерархически. Такая структура зачастую теряется в автоматизации.
🏗️ Решение JPMorgan построено снизу вверх и повторяет логику мышления аналитика. Текст разбивается на предложения, каждое предложение превращается в TF-IDF-вектор, после чего на первом уровне модель предсказывает несколько наиболее вероятных тактик. На втором уровне для каждой тактики используются отдельные модели, определяющие подходящие техники. В результате получается иерархическая мульти-лейбл разметка вида «тактика → техника», а не плоский список тегов.
📊 Этот подход даёт ощутимый прирост качества. При выборе трёх наиболее вероятных тактик точность на уровне тактик достигает около 94%, а при иерархической классификации техник примерно 82%. Важно и то, что система не допускает логических ошибок, когда техника предсказана без соответствующей ей тактики.
🔐 Отдельного внимания заслуживает инженерная деталь: авторы добавили хеширование признаков на этапе векторизации. Это позволяет защищать чувствительные данные и почти не влияет на качество модели. Благодаря этому решения можно безопасно распространять.
🧭 В итоге работа формулирует спокойный, но важный вывод. Ограничения автоматизации MITRE ATT&CK связаны не с тем, насколько «умна» модель, а с тем, насколько точно мы формализуем задачу. Иерархия, мульти-лейблы, строгие таксономии и объяснимость здесь важнее универсальной генерации текста.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CyberSecurity #MITREATTACK #ThreatIntelligence #MachineLearning #LLM #SOC #AIinSecurity #BlueTeam #InfoSec
Разметка MITRE ATT&CK показала пределы LLM
🧠 Автоматическая разметка текстов по MITRE
ATT&CK давно остаётся одной из самых востребованных задач в кибербезопасности. Каждый день аналитики читают отчёты, threat intelligence, сценарии атак и описания уязвимостей, связывая их с тактиками и техниками противника. Это монотонная, дорогая и плохо масштабируемая работа. Не удивительно, что попытки её автоматизировать ведутся уже больше десяти лет.
📄 В январе 2026 года команда JPMorgan Chase опубликовала техническую работу, которая пытаеся решить проблему в новом ключе. Авторы напрямую сравнили GPT-4o и классический машинный подход, SGD-классификатор на TF-IDF.
⚙️ Эксперимент был предельно прагматичным. Моделям давали отдельные предложения из threat intelligence и просили определить соответствующую тактику MITRE ATT&CK.
Классическая модель показала около 82% точности, GPT-4o остановился примерно на 59%. Разница особенно заметна в редких тактиках и в ситуациях, где требуется строгое соответствие идентификаторам и терминологии ATT&CK.
🧩 Как авторы посмотрели на задачу.
«Разметка MITRE» не один шаг, а целый спектр задач разной сложности. В реальности один текст может соответствовать сразу нескольким тактикам, а каждая тактика нескольким техникам, связанным иерархически. Такая структура зачастую теряется в автоматизации.
🏗️ Решение JPMorgan построено снизу вверх и повторяет логику мышления аналитика. Текст разбивается на предложения, каждое предложение превращается в TF-IDF-вектор, после чего на первом уровне модель предсказывает несколько наиболее вероятных тактик. На втором уровне для каждой тактики используются отдельные модели, определяющие подходящие техники. В результате получается иерархическая мульти-лейбл разметка вида «тактика → техника», а не плоский список тегов.
📊 Этот подход даёт ощутимый прирост качества. При выборе трёх наиболее вероятных тактик точность на уровне тактик достигает около 94%, а при иерархической классификации техник примерно 82%. Важно и то, что система не допускает логических ошибок, когда техника предсказана без соответствующей ей тактики.
🔐 Отдельного внимания заслуживает инженерная деталь: авторы добавили хеширование признаков на этапе векторизации. Это позволяет защищать чувствительные данные и почти не влияет на качество модели. Благодаря этому решения можно безопасно распространять.
🧭 В итоге работа формулирует спокойный, но важный вывод. Ограничения автоматизации MITRE ATT&CK связаны не с тем, насколько «умна» модель, а с тем, насколько точно мы формализуем задачу. Иерархия, мульти-лейблы, строгие таксономии и объяснимость здесь важнее универсальной генерации текста.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CyberSecurity #MITREATTACK #ThreatIntelligence #MachineLearning #LLM #SOC #AIinSecurity #BlueTeam #InfoSec
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
🧪 Продолжаем тестирования AI: взгляд на ASQAV SDK
В какой-то момент стало очевидно: привычные методы тестирования плохо применимы к AI-системам.
Раньше можно было сопоставить вход и ожидаемый результат. Теперь с LLM всё иначе.
Ответы вариативны, поведение зависит от контекста, а в случае агентных систем ещё и от цепочки решений, которая формируется прямо в процессе выполнения.
Не удивительно, что появляется все больше специализированных инструментов. Сегодня разберем еще один из них - ASQAV SDK.
⚙️ Изучаем поведение
ASQAV - open-source SDK для оценки и тестирования AI-приложений. Инструмент прежде всего пригодится там, где используются:
➖ языковые модели
➖ агенты
➖ интеграции с внешними сервисами и данными
Его ключевая особенность в смещение фокуса. Он проверяет не «правильность ответа», а устойчивость системы. То есть, как она реагирует на некорректные, провокационные или откровенно вредоносные входные данные.
🔍 Подход ASQAV
Инструмент позволяет задавать сценарии, которые можно назвать «стрессовыми» для модели:
➖ попытки prompt injection
➖ обход ограничений (jailbreak)
➖ провокации на утечку данных
➖ некорректные или неоднозначные входные данные
Система проходит через сценарии последовательно, а результаты можно воспроизводить и встраивать в CI/CD.
Это приближает тестирование AI к тому, что в классической безопасности называется adversarial-подходом.
⚠️ Важное уточнение
ASQAV не определяет, что считать критичным,
не строит модель угроз и не заменяет архитектурные решения.
Инструмент позволяет регулярно проверять систему на устойчивость, а не полагаться на интуицию.
То есть, без классических инструментов все-таки не обойтись.
🧩 Немного по техничке
ASQAV строится вокруг идеи сценарного тестирования. Разработчик описывает набор кейсов (prompts, контекст, ожидаемые ограничения), после чего SDK прогоняет их через модель и фиксирует отклонения.
Тесты можно параметризовать, комбинировать и запускать пакетно. Этакие unit/integration-тесты для LLM-поведения. Результаты структурируются (оценки, флаги нарушений, логи ответов), что позволяет интегрировать проверки в пайплайны CI/CD и отслеживать деградацию модели со временем.
Инструмент работает на уровне API-взаимодействия с моделью, поэтому легко встраивается в существующую архитектуру без изменения самой LLM.
🔗 Репозиторий:
https://github.com/jagmarques/asqav-sdk
Stay secure and read SecureTechTalks 📚
#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #PromptInjection #AdversarialTesting #MachineLearning #DevSecOps #SecureTechTalks
В какой-то момент стало очевидно: привычные методы тестирования плохо применимы к AI-системам.
Раньше можно было сопоставить вход и ожидаемый результат. Теперь с LLM всё иначе.
Ответы вариативны, поведение зависит от контекста, а в случае агентных систем ещё и от цепочки решений, которая формируется прямо в процессе выполнения.
Не удивительно, что появляется все больше специализированных инструментов. Сегодня разберем еще один из них - ASQAV SDK.
⚙️ Изучаем поведение
ASQAV - open-source SDK для оценки и тестирования AI-приложений. Инструмент прежде всего пригодится там, где используются:
Его ключевая особенность в смещение фокуса. Он проверяет не «правильность ответа», а устойчивость системы. То есть, как она реагирует на некорректные, провокационные или откровенно вредоносные входные данные.
🔍 Подход ASQAV
Инструмент позволяет задавать сценарии, которые можно назвать «стрессовыми» для модели:
Система проходит через сценарии последовательно, а результаты можно воспроизводить и встраивать в CI/CD.
Это приближает тестирование AI к тому, что в классической безопасности называется adversarial-подходом.
⚠️ Важное уточнение
ASQAV не определяет, что считать критичным,
не строит модель угроз и не заменяет архитектурные решения.
Инструмент позволяет регулярно проверять систему на устойчивость, а не полагаться на интуицию.
То есть, без классических инструментов все-таки не обойтись.
🧩 Немного по техничке
ASQAV строится вокруг идеи сценарного тестирования. Разработчик описывает набор кейсов (prompts, контекст, ожидаемые ограничения), после чего SDK прогоняет их через модель и фиксирует отклонения.
Тесты можно параметризовать, комбинировать и запускать пакетно. Этакие unit/integration-тесты для LLM-поведения. Результаты структурируются (оценки, флаги нарушений, логи ответов), что позволяет интегрировать проверки в пайплайны CI/CD и отслеживать деградацию модели со временем.
Инструмент работает на уровне API-взаимодействия с моделью, поэтому легко встраивается в существующую архитектуру без изменения самой LLM.
🔗 Репозиторий:
https://github.com/jagmarques/asqav-sdk
Stay secure and read SecureTechTalks 📚
#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #PromptInjection #AdversarialTesting #MachineLearning #DevSecOps #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🚨 Claude Code раскрывает секреты
31 марта 2026 года Claude Code утёк без взлома.
В npm-пакет не добавили *.map, и наружу ушёл bundle ~60 МБ с 500+ тыс. строк TypeScript-кода, включая внутреннюю логику, комментарии и feature-флаги.
🧠 Что именно утекло
В сети оказалась reference-реализация того,
как LLM превращается в исполняемого агента:
➖ оркестрация вызовов инструментов
➖ планирование задач
➖ управление состоянием
➖ enforcement ограничений
⚙️ Execution loop вместо «prompt → response»
Внутри есть цикл выполнения, где модель:
➖ декомпозирует задачу
➖ выбирает инструменты
➖ получает результаты
➖ пересобирает план
Причём цепочка не фиксирована и может ветвиться, этакий event-driven runtime.
🔄 KAIROS: фоновый агент
Отдельного внимание заслуживает режим KAIROS.
Это long-running процесс, который:
➖ реагирует на события (например GitHub)
➖ работает по «тикам»
➖ поддерживает собственное состояние
➖ инициирует действия без прямого запроса
Таким образом, агент становится проактивным, а не реактивным.
💤 AutoDream: работа с памятью
Механизм AutoDream отвечает за постобработку.
В idle-состоянии система:
➖ пересматривает прошлые трейсы
➖ устраняет противоречия
➖ сжимает и нормализует контекст
В итоге имеем state reconciliation между сессиями.
🕵️ Undercover Mode
В коде явно выделен режим ограничения экспозиции:
➖ подавление самореференций
➖ фильтрация внутренних деталей
➖ контроль формулировок ответов
Другими словами реализован слой output sanitization + policy enforcement.
🛡 Защита от model extraction
Отдельный блок посвящён защите от копирования:
➖ искажение reasoning chain в ответах
➖ внедрение «шумовых» инструментов
➖ усложнение реконструкции логики
🎯 Архитектурный вывод
Claude Code не «обёртка над LLM», а полноценный стек. LLM выступает, как планировщик, runtime как исполнитель, а инструменты как расширение capability.
Что это, если не agent OS?
Stay secure and read SecureTechTalks 📚
#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #CyberThreats #MachineLearning #DevSecOps #ThreatIntelligence #SecureTechTalks
31 марта 2026 года Claude Code утёк без взлома.
В npm-пакет не добавили *.map, и наружу ушёл bundle ~60 МБ с 500+ тыс. строк TypeScript-кода, включая внутреннюю логику, комментарии и feature-флаги.
🧠 Что именно утекло
В сети оказалась reference-реализация того,
как LLM превращается в исполняемого агента:
⚙️ Execution loop вместо «prompt → response»
Внутри есть цикл выполнения, где модель:
Причём цепочка не фиксирована и может ветвиться, этакий event-driven runtime.
🔄 KAIROS: фоновый агент
Отдельного внимание заслуживает режим KAIROS.
Это long-running процесс, который:
Таким образом, агент становится проактивным, а не реактивным.
💤 AutoDream: работа с памятью
Механизм AutoDream отвечает за постобработку.
В idle-состоянии система:
В итоге имеем state reconciliation между сессиями.
🕵️ Undercover Mode
В коде явно выделен режим ограничения экспозиции:
Другими словами реализован слой output sanitization + policy enforcement.
🛡 Защита от model extraction
Отдельный блок посвящён защите от копирования:
🎯 Архитектурный вывод
Claude Code не «обёртка над LLM», а полноценный стек. LLM выступает, как планировщик, runtime как исполнитель, а инструменты как расширение capability.
Что это, если не agent OS?
Stay secure and read SecureTechTalks 📚
#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #CyberThreats #MachineLearning #DevSecOps #ThreatIntelligence #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
📏💣 LLM можно взломать просто продолжая диалог
В мае вышла работа MetaBackdoor, где исследователи из Microsoft и Institute of Science Tokyo описывают новый тип backdoor-атак на LLM.
Главная идея исследования использовать в качестве trigger не содержимое prompt, а позицию токенов в контексте.
Например:
📚 контекст превысил определённую длину
📍 токены оказались в нужном positional range
🔢 sequence crossed threshold
Trigger может возникать естественным образом, без участия атакующего.
💬 пользователь просто общается с AI
🧠 память агента накапливается
📈 context window становится длиннее
И в какой-то момент backdoor активируется сам.
🧬 Особенности моделей
Технически атака использует фундаментальную особенность Transformer-архитектуры, positional encoding. Для модели все токены это просто embedding-вектора.
Без механизма позиции фразы для модели были бы почти одинаковыми. Представьте перепутать «root granted admin» и «admin granted root».
Поэтому модели используют positional embeddings. В современных моделях чаще всего это:
🔹 RoPE (Rotary Positional Embedding)
🔹 ALiBi
🔹 Absolute positional encodings
В исследовании авторы показывают, что именно позиционная чувствительность модели может использоваться как скрытый канал управления поведением.
Во время fine-tuning в модель внедряется backdoor objective: если токен находится после определённой позиции → изменить response policy
Trigger не обязан быть точным числом. Бэкдор может срабатывать в диапазоне позиций, например после N тысяч токенов, что делает его значительно более устойчивым к случайным изменениям prompt.
Это особенно важно для production-agent systems, где длина контекста постоянно плавает.
🎭 Что можно сделать после активации
Авторы тестировали разные payload-сценарии.
Среди них:
🧾 System prompt leakage: модель начинает раскрывать скрытые инструкции.
🛠️ Tool misuse: агент начинает выполнять неожиданные tool calls.
📤 Context leakage: утечка памяти и истории общения.
🧠 Policy switching: изменение alignment и response behavior.
Похоже, эпоха «проверим prompt и успокоимся» начинает заканчиваться 👀
📄 MetaBackdoor: Exploiting Positional Encoding as a Backdoor Attack Surface in LLMs
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #AISecurity #PromptInjection #GenAI #MachineLearning #ThreatModeling #AIAgents #SecureTechTalks
В мае вышла работа MetaBackdoor, где исследователи из Microsoft и Institute of Science Tokyo описывают новый тип backdoor-атак на LLM.
Главная идея исследования использовать в качестве trigger не содержимое prompt, а позицию токенов в контексте.
достиг определённой позиции в sequence → переключил поведение моделиАвторы называют это meta-trigger, потому что он связан не с текстом, а с метасвойствами последовательности.
Например:
📚 контекст превысил определённую длину
📍 токены оказались в нужном positional range
🔢 sequence crossed threshold
Trigger может возникать естественным образом, без участия атакующего.
💬 пользователь просто общается с AI
🧠 память агента накапливается
📈 context window становится длиннее
И в какой-то момент backdoor активируется сам.
🧬 Особенности моделей
Технически атака использует фундаментальную особенность Transformer-архитектуры, positional encoding. Для модели все токены это просто embedding-вектора.
Без механизма позиции фразы для модели были бы почти одинаковыми. Представьте перепутать «root granted admin» и «admin granted root».
Поэтому модели используют positional embeddings. В современных моделях чаще всего это:
🔹 RoPE (Rotary Positional Embedding)
🔹 ALiBi
🔹 Absolute positional encodings
В исследовании авторы показывают, что именно позиционная чувствительность модели может использоваться как скрытый канал управления поведением.
Во время fine-tuning в модель внедряется backdoor objective: если токен находится после определённой позиции → изменить response policy
Trigger не обязан быть точным числом. Бэкдор может срабатывать в диапазоне позиций, например после N тысяч токенов, что делает его значительно более устойчивым к случайным изменениям prompt.
Это особенно важно для production-agent systems, где длина контекста постоянно плавает.
🎭 Что можно сделать после активации
Авторы тестировали разные payload-сценарии.
Среди них:
🧾 System prompt leakage: модель начинает раскрывать скрытые инструкции.
🛠️ Tool misuse: агент начинает выполнять неожиданные tool calls.
📤 Context leakage: утечка памяти и истории общения.
🧠 Policy switching: изменение alignment и response behavior.
Похоже, эпоха «проверим prompt и успокоимся» начинает заканчиваться 👀
📄 MetaBackdoor: Exploiting Positional Encoding as a Backdoor Attack Surface in LLMs
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #AISecurity #PromptInjection #GenAI #MachineLearning #ThreatModeling #AIAgents #SecureTechTalks
👍2