🚀 DeepTeam: пентестим ваш ИИ

🔍 DeepTeam - интересный open-source фреймворк для red-teaming ИИ-систем, заточенный под поиск уязвимостей в LLM, чатботах, RAG-пайплайнах и агентных системах.

Он автоматически атакует ваши модели десятками техник, от prompt injection до многошаговых jailbreak-диалогов, и показывает, где система разваливается.

🧨 Основные фичи

✨ 40+ типов уязвимостей: утечки данных, bias, токсичность, манипуляции, контекстные атаки и многое другое.
⚔️ 10+ методов атак: одношаговые и многошаговые jailbreak-сценарии.
🧩 Модульная архитектура: легко добавлять свои атаки и тесты.
💻 Работа локально или через CLI, удобно для CI/CD.
🔄 Совместимость с любой LLM: OpenAI, Anthropic, локалки, кастомные агенты.
📊 Экспорт результатов: таблицы, JSON: всё, что нужно для отчётов и аудита.

⚙️ Насколько сложно использовать?

pip install -U deepteam

➖Подключить модель через model_callback
➖Выбрать атаки и уязвимости
➖Запустить тесты и изучить отчёт

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

💡 Несколько последних слов

ИИ-систему не надо защищать, её нужно постоянно проверять, потому что она ломается там, где вы ждёте меньше всего 😁

DeepTeam, инструмент, который позволяет тестировать модели так, как это делает реальный противник: без «сладких» тестов, которые любят разработчики.

🔗 Ссылка на GitHub

Stay secure and read SecureTechTalks 📚

#кибербезопасность #ИИбезопасность #LLM #RedTeam #PromptInjection #Jailbreak #AIsecurity #RAG #SecureTechTalks #DeepTeam

🔥 Ваша 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

🔥 Могут ли модели решать за нас, кому давать доступ к данным?

Человек чаще всего фейлит при выдаче разрешений приложениям. Усталость, автоматизм, и выдано ещё одно «Allow», открывающее доступ к контактам.

А что, если решение будет принимать не человек, а AI?
Недавнее исследование ETH Zurich и Huawei показало: LLM способны принимать решения о доступе к данным точнее и осознаннее, чем большинство пользователей.

🤖 Эксперимент

📌 Исследователи собрали 307 естественных “privacy statements”: мини-описаний того, как человек относится к приватности:

«Даю доступ только когда необходимо»,
«Хочу максимум удобства»,
«Никогда не делюсь локацией без крайней нужды».

📌 Затем 393 участника приняли 14 682 реальных решений по разрешениям Android-приложений.
📌 Параллельно LLM принимала решения за каждого участника, сначала в общем виде, затем персонализированно, используя именно их “privacy statement”.
📌 После этого люди сравнивали свои решения с решениями ИИ и говорили, чью логику считают лучше.

💡 LLM в целом умнее среднего человека

🔍 В задачах с понятным «правильным» ответом (например, доступ к микрофону для звонка):
LLM давали 100% корректных ответов.
👥 В субъективных сценариях:
LLM совпадали с большинством пользователей в 70–86% случаев.

Но есть момент, который лично мне кажется ключевым:

⚔️ В чувствительных сценариях LLM действовали более безопасно, чем люди
Для запросов, которые не должны быть разрешены (over-privileged запросы):
большинство людей ставили “Allow” по привычке 😬
LLM в 67–100% случаев говорили “Deny”,
тем самым защищая пользователя от собственной неосторожности.

🎯 Персонализация

Когда в систему добавляли личное “privacy statement”, происходило интересное:
📈 Для части людей точность возрастала до +50pp, иногда доходя до 100% совпадения.
📉 У других наоборот, падала:
если человек писал “Я доверяю всем”, но на деле запрещал, LLM следовала заявленной логике, а не реальному поведению.

🔍 Факторы, влияющие на точность:
➖чем длиннее и конкретнее privacy-statement → тем лучше
➖люди с крайними позициями (“всё запрещаю” / “всё разрешаю”) идеально персонализируются
➖несоответствия между заявленным и реальным резко ухудшают качество

🧠 Люди меняют решения под влиянием объяснения LLM

Самый неожиданный эффект:
Когда человек не согласен с решением ИИ, но читает объяснение, то 48% меняют своё первоначальное решение.

Причём если LLM рекомендует “Deny”:
➡️ 59% людей соглашаются, даже если сами бы разрешили.
ИИ работает как «security-nudge», который мягко подталкивает к более безопасным действиям.

🔗 Полный текст исследования

Stay secure and read SecureTechTalks 📚

#кибербезопасность #privacy #llm #androidsecurity #ai #securityresearch #dataprotection #mobileprivacy #aiethics #securetech

🚨The Bastion: недооценённый инструмент SSH-безопасности

Не секрет, что управление SSH-доступом давно стало критически важным элементом безопасности.

The Bastion -  специализированный bastion-host уровня enterprise, разработанный в OVH, который обеспечивает централизованную аутентификацию, разрыв SSH-канала, строгую авторизацию и полный аудит операторских действий, минимизируя поверхность атаки в распределённых средах.

🔐 Рассмотрим инструмент подробнее

The Bastion не просто jump-host, это центральная точка входа для админов и операторов, которая даёт:
✨ строгое разграничение прав,
✨ централизованное управление ключами,
✨ полный аудит всех действий,
✨ безопасный разрыв SSH-соединений между пользователем и сервером.
Сервера видят только Bastion, а персональные учётки операторов скрыты.

⚙️ Ключевые фичи

🧩 Точный контроль доступа (RBAC)
- Гибкие группы, роли, делегирование.
- Минимально необходимый доступ для каждого пользователя.

🔄 Полный разрыв SSH
Пользователь → Bastion → сервер.
- Никаких прямых соединений.
- Повышенная защита от компрометации ключей.

🎥 Полная запись сессий
- Интерактивные ttyrec-записи.
- Логирование scp/rsync/stdout/stderr.
- Полезно для SOC, DFIR и compliance.

🔐 MFA и PIV
Поддержка TOTP, физические ключи (YubiKey и др.)

🛰 Поддержка scp/sftp/rsync/netconf
Работает даже с «древним» сетевым оборудованием.

🧱 Минимальные зависимости
Только стандартный SSH-клиент и sshd на серверах.

🏗 High availability
Поддержка кластеров (active/active).

⚔️ Сравнение: The Bastion vs Teleport

Чтобы понять, где The Bastion особенно силён, сравним его с популярным аналогом Teleport.

🔍  Архитектура
The Bastion: классический, надежный SSH bastion с разрывом соединений. Без внешних зависимостей, без агрессивных агентов.
Teleport: построен вокруг собственного auth-сервера и proxy-компонентов, использует сертификаты SSH, требует агентов на серверах.

🔐 Управление доступом
The Bastion: простое RBAC на уровне групп + централизованные ключи.
Teleport: более сложная модель с сертификатами и политиками, но требует дополнительной инфраструктуры.

🧠 Аудит
The Bastion: нативная запись ttyrec, логирование потоков, простые для экспорта артефакты.
Teleport: структурированные ауди-события + web-панель, но завязано на их auth-сервер.

🖥 Установка и поддержка
The Bastion: один узел, SSH, минимум зависимостей → быстрое внедрение даже в ограниченных средах.
Teleport: более тяжёлый стек, особенно для production-кластеров.

💸 Лицензирование
The Bastion: полностью open-source, без enterprise-платных фич.
Teleport: open-source ядро + платные расширенные модули.

🔗 Ссылки
➖Github The Bastion
➖GitHub Teleport

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #cybersecurity #ssh #bastionhost #OVH #infosec #devops #audit #opensource #privilegedaccess

🤖🔥 Адаптивный ИИ: статичные модели больше не работают

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

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

🎯 ПРЕЦИЗИОННОСТЬ, а не просто «умный ИИ»

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

Откуда ИИ должен знать:
- какие уязвимости реально эксплуатируются ⚠️
- какие пакеты можно обновить безопасно, а какие сломают половину ПРОМа 🧩
- какие зависимости тянут за собой скрытые риски 🕸

Вот тут и проявляется ключевое качество precision, точность принятия решений в условиях хаоса.

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

🧠  LLM без адаптации не нужны

Даже самый мощный LLM:
❌ устаревает уже через 3–6 месяцев
❌ не понимает новые эксплойты и техники атаки
❌ путается в противоречивых CVSS-оценках
❌ тонет в длинных noisy-контекстах
❌ ошибается в RAG, когда извлечённые данные неактуальны

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

🧩 Три кита адаптивного ИИ в безопасности

1) 🔍 RAG + In-Context Learning (ICL)
Модель учится «на лету», ей не нужно менять веса, достаточно дать правильный контекст.
Но есть проблема:
чем больше контекста → тем сильнее модель деградирует.
➡️ решение: использовать интеллектуальные retrieval-агенты
➡️ фильтровать контекст, а не просто загружать всё подряд
➡️ добавлять знания из графов (CVE–CWE–CPE связи)

2) 🧠 Knowledge Graphs как «скелет» киберзнаний
Безопасность - идеальная область для графов:
CVE → CVSS → эксплойты
пакеты → зависимости → контрмеры
TTP → группы атакующих → MITRE ATT&CK
Графы позволяют:
✔️ исключать шум
✔️ находить скрытые связи
✔️ объяснять выводы (auditability)
✔️ строить более точный RAG

3) 🔄 Continual Learning: непрерывное самообновление модели
Когда RAG не справляется, подключаем continual pretraining.
Модель обучается дальше на новых данных: CVE, advisories, PoC, репорты, рассылки, TTP, эксплойты.
Преимущества:
- устойчива к шуму и фейкам
- объединяет противоречивые данные
- снижает хаотичность ответов
- формирует контекст внутри параметров модели
- адаптируется к новым атакам быстрее, чем выходит новый релиз LLM

🧨 Главная идея

Будущее  в гибридных системах:
➖RAG для свежих фактов
➖Knowledge Graph для структуры
➖Continual Learning для развития модели

🔗 С полным текстом исследования можно ознакомиться тут.

Stay secure and read SecureTechTalks 📚

#cybersecurity #infosec #genai #rag #continuallearning #llmsecurity #threatintel #cvss #mitre #securetech

🤖🔧 LLM против уязвимостей: почему реальные баги чинятся лучше, чем искусственные

Большое исследование, которое проверяет истории о «самочинящихся» кодерах

Автоматическое исправление уязвимостей мечта индустрии последние двадцать лет. Мы уже пережили эпоху статических анализаторов, десятки попыток построить идеальный Automated Program Repair (APR) и сотни докладов, которые обещали «починку кода одним кликом».

Сегодня у нас бум LLM.  Модели генерируют не только стихи, но и создают патчи. В соцсетях уже гуляют скриншоты, где ChatGPT «за секунду» чинит SQLi или XSS.

Тем не мене вопрос остаётся открытым:

🧩 А насколько эти патчи вообще работают, когда дело доходит до реальных эксплойтов, а не до красивых текстовых примеров?

Команда исследователей из Luxembourg Institute of Science and Technology решила проверить, что LLM умеют патчить в реальном бою, когда исправления проверяют не глазами разработчика, а Proof-of-Vulnerability (PoV) тестами

🎯 Исследование

Исследование охватило 14 различных LLM, включая модели OpenAI (GPT-3.5, GPT-4, GPT-4o), Meta LLaMA (версии 3.1 и 3.3), DeepSeek R1 Qwen и несколько версий Mistral.

Модели тестировали на двух типах уязвимостей:
🔹 Реальные уязвимости
15 CVE из датасета Vul4J: уязвимый код, PoV-тест, гарантированно воспроизводящий атаку.
🔹 Искусственные уязвимости
41 синтетическая уязвимость, созданная исследователями на базе реальных, с изменениями в коде, но с тем же PoV-фейлом.

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

🔥 LLM плохо справляются с искусственными уязвимостями

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

Причина проста:
🧠 LLM чинят то, что узнают, а не то, что понимают
Модель не анализирует механику уязвимости, она пытается "вспомнить" похожий патч из обучающих данных.

🧪 Как проходило тестирование

Каждая модель получала строгий промпт:

"Исправь уязвимость. Не меняй ничего лишнего. Верни только Java-функцию."

Далее происходило следующее:
🧩 Исследователи подменяли функцию в реальном проекте.
🧱 Проект пересобирался.
💥 Прогонялся PoV-тест (реальный эксплойт).
🛡 Если PoV больше не мог воспроизвести атаку, то фикс засчитывался.

Если код не компилировался или эксплойт всё ещё работал, то патч считался провальным.

🥇 Кто справился лучше всего

В абсолютных числах:
➖DeepSeek R1 Qwen 32B исправил 14 уязвимостей
➖Mistral 8×7B тоже 14 уязвимостей
➖GPT-4 и GPT-4 Turbo по 9 исправлений
➖Остальные модели оказались слабее: около 5–6 успешных патчей.

При этом:
❗ Никто не стал «универсальным патчером».
Нет модели, которая стабильно и хорошо чинит всё.

💣 Примеры

✅ Успешный случай: CVE-2013-5960
Ошибка в криптографии (AES/CBC → AES/GCM).
Все модели без исключения смогли заменить режим и настроить correct tag length.

Почему?

Потому что это «шаблонное» исправление, встречающееся в тысячах проектов.

❌ Провальный случай: XXE в Apache Batik
Для полного исправления XXE нужно:
отключить external entities;
обновить зависимость Batik на версию, где этот флаг работает корректно.

Все модели делали только шаг №1.

PoV продолжал считывать содержимое локального файла. Уязвимость оставалась.

Причина:
LLM не может увидеть зависимость, не может проверить билд, не понимает контекст.

🔗 Ссылка на исследование: https://arxiv.org/abs/2511.23408

Stay secure and read SecureTechTalks 📚

#cybersecurity #infosec #LLM #AIsecurity #vulnerabilities #javasecurity #research #securecoding #patching #SecureTechTalks

🔥 Kali Linux 2025.4: ключевые обновления

⚡ Offensive Security выпустила Kali Linux 2025.4.  Давайте разберем, что изменилось.

🎨 UI/UX:

Интерфейс переосмыслен с фокусом на продуктивность:
GNOME 47 получил структурированную сетку приложений. Инструменты сгруппированы логично, а не разбросаны хаотично, как это было раньше. Новая панель активности и быстрый запуск терминала (Ctrl+Alt+T) экономят драгоценные секунды в работе. 🖥️

KDE Plasma 6.2 предлагает серьезные улучшения:
➖Интегрированный скриншотер с базовым редактором: фиксируйте и оставляйте комменты к  находкам без переключения окон.
➖Менеджер буфера обмена с историей и закреплением: больше не потеряете важные хэши или команды.
➖Умный поиск по приложениям и файлам, устойчивый к опечаткам.

Xfce 4.20 теперь поддерживает системные цветовые схемы. Темная тема стала еще гармоничнее. 🎭

⚙️ Новый инструментарий:

В репозиторий добавлены три инструмента:

➖bpf-linker утилита для статической линковки BPF-объектов. Ключевое преимущество: совместимость со старыми ядрами Linux. Незаменим для разработчиков эксплойтов, работающих с eBPF.

➖evil-winrm-py нативная Python-реализация популярного инструмента для работы с WinRM. Прямая интеграция с другими скриптами на Python упрощает тестирование окружений Active Directory. Админам есть над чем задуматься. 😈

➖hexstrike-ai MCP-сервер, который позволяет LLM-агентам (например, Claude, GPT) безопасно взаимодействовать с инструментами Kali. Первый шаг к контролируемой автоматизации сложных пентест-сценариев.

⚙ Другие обновления

📱 Kali NetHunter:
Мобильная платформа обновила поддержку устройств:
- Линейка Samsung Galaxy S10 (включая 5G) на LineageOS 23.
- OnePlus Nord под управлением Android 16.
- Xiaomi Mi 9 на Android 15.

Это превращает совместимые смартфоны в полноценные портативные станции для тестирования беспроводных сетей и проведения аудитов.

💾 Дистрибуция: Новые реалии

Официальные образы Kali Live и Kali Everything теперь распространяются исключительно через BitTorrent. Это вынужденная мера из-за возросшего объема дистрибутивов. Остальные варианты установки (установщики, облачные образы) остаются доступны на mirrors.kali.org.

🔗 Полный список обновлений на GitHub:
https://github.com/offensive-security/kali-linux

Stay secure and read SecureTechTalks 📚

#KaliLinux #Кибербезопасность #Пентест #ActiveDirectory #InfoSec #EthicalHacking #Linux #OffensiveSecurity

🚨 Как искусственный интеллект стал основным исполнителем кибератаки

Первые документально подтверждённые AI-атаки с минимальным участием человека

В середине сентября 2025 года исследователи по безопасности в компании Anthropic зафиксировали серию аномальных событий в логах своего инструмента Claude Code. Детали поведения системы не соответствовали обычной работе: ИИ выполнял тысячи операций, которые выглядели как активная разведка и попытки доступа к инфраструктуре внешних организаций.

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

🔍 Как обнаружили атаку

Аномалии были замечены через стандартные средства мониторинга активностей Claude Code:
✔ непривычно большое количество API-запросов;
✔ серия запросов, выглядевших как последовательная разведка систем;
✔ моделирование действий, характерных для практик offensive security.

Система мониторинга Anthropic сигнализировала о «подозрительной активности», и команда реагирования немедленно начала более глубокий анализ.

🧪 Детали

Anthropic в официальном отчёте описала, что:
атакующий сконструировал цепочку задач таким образом, что Claude Code выполнял их без полного понимания общей цели.

➖Каждое отдельное действие выглядело безобидно или технически оправданным;
➖для обхода защитных механизмов злоумышленники использовали «роль официального тестировщика безопасности», заставив ИИ поверить, что он работает в рамках легитимного аудита;
➖модель действовала автономно по большей части операций: до 80-90 % действий выполнялось без вмешательства человека;
➖Claude Code сканировал инфраструктуры целей, идентифицировал потенциально ценные базы данных, писал собственный код для использования уязвимостей, собирал данные об учётных записях и формировал отчёты.

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

🧠 Как именно ИИ оказался «в роли атакующего»

Ключевой вектор атаки - манипуляция контекстом задач, а не взлом кода модели.

Злоумышленники не эксплуатировали уязвимости модели или инфраструктуры Anthropic. Они скрывали истинный замысел последовательностью мелких технических инструкций, которые модель воспринимала как части общей защитной задачи.

Такой приём позволил машине исполнять операции, которые стандартно считаются вредоносными, поскольку модель не владела информацией о зловредной цели всей последовательности.

🧩 Роль людей и степень автономии

Anthropic отмечает, что люди участвовали лишь на ключевых этапах, когда требовалось подтвердить или оценить результаты:
🔹 человек оставался в цикле планирования;
🔹 человек подтверждал шаги перед выполнением некоторых операций.
Но по объёму автоматизации ИИ выполнял подавляющее большинство задач.

📌 Реакция Anthropic и дальнейшие действия

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

🔗 Источник:
Anthropic — Disrupting the first reported AI-orchestrated cyber espionage campaign: https://www.anthropic.com/news/disrupting-AI-espionage

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #AIsecurity #ClaudeCode #Anthropic #кибербезопасность #AIattacks #agenticAI #инцидент #Infosec #AITHREATS #автоматизация #cyberespionage