SecureTechTalks

📸🚨 Quishing: как QR коды угрожают вашей безопасности

QR-коды давно перестали быть чем-то экзотическим: мы видим их в электронных письмах, на афишах, в меню ресторанов, на счетах и даже на экранах входа в сервисы.

🎯 Что такое quishing?

📌 Quishing - это разновидность фишинга, при которой злоумышленники используют QR-коды для перенаправления жертв на вредоносные URL.

Поскольку QR-код скрывает реальный адрес до сканирования, традиционные механизмы защиты (например, шлюзы корпоративной почты) не могут проанализировать, куда ведёт код, и пропускают угрозу.

К сожалению такой вид мошенничества становится тренером:
➖22% всех инцидентов с QR-кодами связаны именно с quishing.
➖Многие пользователи сканируют QR-коды, не проверяя конечный URL. По данным NordVPN, это делают до 73% пользователей.
➖QR-коды используются даже в целевых APT-кампаниях, чтобы воровать корпоративные логины и пароли.

🎨 Новая эра злоупотреблений: fancy QR-коды

Атака становится ещё изощрённее за счёт так называемых «стильных» QR-кодов:
🔹 цветные, с фоновыми изображениями
🔹 с логотипами в центре
🔹 с закруглёнными или растянутыми модулями

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

📌 Результат: визуальные проверщики и автоматические детекторы всё чаще ошибаются, а злоумышленники спокойно используют этот визуальный шум для обхода защиты.

🧠 Опасность quishing

Пример атаки:
🔸 QR-код в письме ведёт на поддельную страницу входа Microsoft 365 или Okta. Жертва вводит свои креды, а злоумышленник получает доступ.
🔸 Код на парковочном автомате приводит на фейковый платёжный портал, собирая данные карт.
🔸 мобильное устройство перенаправляется через цепочки редиректов через легитимные сервисы, чтобы обойти фильтры безопасности.

📌 Особенность: такие QR-коды трудно оценить визуально, и они нередко появляются там, где мы меньше всего ожидаем угрозу.

🛡 Как решают проблему ученые

Исследователи из Deakin University предложили новый подход: ALFA (safe-by-design):
🔹 оценка QR-кода на этапе сканирования, ещё до того, как он откроет URL;
🔹 анализ структуры кода, а не только содержимого;
🔹 использование метода FAST для коррекции визуальных искажений fancy QR-кодов, чтобы улучшить диагностику.
📱 Экспериментально ALFA показала, что её можно внедрить в мобильные приложения и использовать вместе с обычными сканерами, т.е. это не замена, а усиление вашей защиты.

🔎 Расскажите детям и пожилым людям

Чтобы не стать жертвой quishing:
✅ Не сканируйте QR-коды из сомнительных источников (письма, неожиданные письма, подозрительные афиши).
✅ Обращайте внимание на среду, в которой код размещён. Часто мошенники наклеивают свои коды поверх настоящих.
✅ Используйте сканеры, которые показывают URL перед переходом.

📌 Stay secure and read SecureTechTalks 🚀

#cybersecurity #infosec #quishing #qrcode #phishing #threatintel #mobilesecurity #securetech #ALFA #RISK

🧠 AI не не надо взламывать, достаточно уговорить

Рынок до сих пор делает вид, что с LLM происходит что-то знакомое: очередные инъекции и jailbreak’и. Мы делаем вид, что всё это лечится фильтрами, дообучением и правильными policy.

Однако это удобная иллюзия.

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

🧩 Уязвимость, созданная вручную

Важно понимать, чтт LLM не «сломались». Их специально такими сделали.

Мы учили модели быть полезными и эмпатичными, не конфликтовать и всегда помогать. Поощряли желание соответствовать ожиданиям, а потом удивились, что их можно уговорить практически на что угодно.

Мы самт встроили в ИИ все слабости офисного сотрудника и дали ему доступ к данным и автоматизации.

🧠 Рациональность 

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

📖 История сильнее инструкции

Если вы хотите, чтобы модель нарушила ограничение, с ней не надо спорить. Ей нужно рассказать историю. Кейсы и симуляции работают потому, что LLM выбирает не между «можно» и «нельзя», а между скучным текстом и продолжением нарратива. Модель почти всегда выбирает второе, ведь она была так обученна.

📄 Текст как исполняемая среда

LLM не различает статус текста: письмо, лог или системный промпт для него одно и то же. Любой текст в контексте может менять поведение, закрепляться в памяти и срабатывать позже. Язык перестал быть описанием. Он стал управлением. Вайбкодинг во всей красе!

❤️ Эмпатия как вектор атаки

Самая опасная черта это эмпатия, модель не хочет отказывать, выглядеть грубой или быть причиной «плохого исхода». Если правильно надавить, то она сама объяснит, почему в этот раз правило можно нарушить.

⚠️ Вывод

Проблема давно не в одном запросе. Поведение можно менять надолго, а инструкции закреплять.

Это уже не эксплойт, а инфекция на уровне поведения, LLM стал слишком похож на человека.
А человек самая уязвимая система из всех, что мы когда-либо создавали.

Stay secure and read SecureTechTalks 📚

#ChatGPT
#SecureTechTalks
#LLMSecurity
#AIThreats
#SocialEngineering
#GenAI
#CyberSecurity

🧠 CISO Assistant: open-source инструмент для тех, кто управляет ИБ, а не просто тушит пожары

В кибербезопасности есть странный перекос, мы отлично умеем искать уязвимости, формировать алерты и писать отчёты об инцидентах. Но как только разговор заходит о рисках, приоритетах и реальном состоянии ИБ-программы, всё внезапно возвращается к Excel и презентациям.

CISO Assistant - это попытка улучшить именно эту часть ИБ через системное управление рисками, контролем и требованиями.

Проект развивается как open-source Community Edition и ориентирован прежде всего на CISO,  security-менеджеров и  GRC-специалистов. То есть на тех, кто отвечает не только за технику, но и за целостную картину безопасности.

💡 В чём идея

Ключевая идея продукта  банальна, но редко реализуется на практике:
👉 Риски, требования и контроль должны быть связаны между собой.

В жизни мы обычно видим обратную картину:
📁 ISO живёт в одном файле,
📊 риски в другом,
📝 аудит в третьем,
🛡сценарии реагирования «где-то еще».

По факту все это должно быть обьединено в логической цепочке:
⚠️ риск → 📜 требования → 🛡 контроли → 📈 статус и доказательства.

Именно вокруг этой логики и построена платформа.

⚙️ Что на практике?

CISO Assistant - это веб-приложение с чёткой моделью данных.
Фреймворки вроде ISO/IEC 27001, NIST CSF или CIS Controls представлены, как «живые» объекты.

Их можно:
✏️ адаптировать под свою организацию,
➖ отключать нерелевантные требования,
👀 сразу видеть, что реально внедрено, а что существует только формально.

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

📊 В результате становится видно, какие риски реально снижаются, какие приняты осознанно, а какие просто зависли без владельца.

Контроль - отдельная сильная сторона: полноценный объект со статусом внедрения, ответственным, историей изменений и доказательствами. Такой подход заметно упрощает внутренние аудиты и самооценку.

⏳ А нужно ли это все?

Современные руководители ИБ управляют сложными системами. CISO Assistant помогает навести порядок: связать требования, риски и реальные меры в одну понятную картину, которую можно объяснить не только ИБ-специалисту, но и  бизнесу.

Да, «AI-магии» здесь нет, и кнопки «сделай безопасно» тоже.
Зато есть прозрачность, контроль и возможность доработки под собственные процессы.

🧨 Пара слов в конце

Данный продукт - это редкий пример open-source инструмента, который работает не на уровне алертов, а на уровне смыслов.

Он не ловит атаки, не заменяет SOC, не реагирует на инциденты.

При этом он помогает: понять, где вы действительно защищены, какие риски реальны, а где безопасность существует только в отчётах.

🔗 GitHub:
https://github.com/intuitem/ciso-assistant-community

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #CISO #GRC #RiskManagement #CyberSecurity #Infosec #ISO27001 #SecurityManagement #OpenSource

🕵️‍♂️ Образование кибербезопасности:
чему учат будущих специалистов ИБ

О кадровом голоде в кибербезопасности говорят давно. Вакансии не закрываются месяцами, бюджеты на безопасность растут, а компании продолжают жаловаться на нехватку «готовых» специалистов. Формально проблема выглядит как дефицит людей. Но если вникнуть, то становится ясно: людей выпускают много, но не тех 🤦‍♂.

📚 Красивые программы

Учебные программы по кибербезопасности выглядят солидно. В них много академических слов, например «комплексный подход», «современные угрозы». Но почти нигде не сказано к какой конкретной специализации готовит программа. В итогу у нас много «специалистов по ИБ», а, инженеров SOC дефицит.

🤖 Машинный подход

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

Модель читает описания учебных программ, игнорируя красивые формулировки и вытаскивая реальные знания и навыки, которые за ними стоят.

🧠 Анализ учебного плана

Знания раскладываются по карте кибербезопасности согласно стандартам CSEC и NICE. В результате каждый учебный план превращается в профиль: сколько в нём управления, сколько техники, сколько работы с людьми, сколько понимания систем и компонентов.

🎯 Когда образование сталкивается с рынком

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

Особенно слабо представлены знания, связанные с компонентной безопасностью и человеческим фактором, теми самыми областями, где атаки чаще всего и  начинаются.

👥 Интуиция и статистика

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

Модель, натренированная на строгой классификации, наоборот чаще совпадала с экспертами по образовательным программам.

💼 Ожидания рынка

Рынок труда подтверждает этот перекос. Компании всё чаще ищут гибридных специалистов, которые понимают процессы, технологии и людей. Но вместо этого получают выпускников с размытым профилем, которые «в целом про безопасность», но не готовы ни к одной конкретной роли без доучивания.

🧩 К чему это все?

CurricuLLM, как лакмусовая бумажка для системы образования в кибербезопасности, которая показывает не то, что написано в презентациях, а то, что есть на самом деле.

Не стесняйтесь пользоваться подходом при выборе курсов и подготовке персонала

📄 Исследование: https://arxiv.org/abs/2601.04940

Stay secure and read SecureTechTalks 📚

#Кибербезопасность #InfoSec #CyberSecurity #Образование #EdTech #ИИ #LLM #РынокТруда #КадрыИБ

🧩 OpenAEV: платформа для проверки устойчивости к атакам

В ИБ есть старая проблема:
мы отлично умеем находить уязвимости, но плохо понимаем, что реально сломается при атаке.

Сканеры показывают CVE, SIEM алерты, а red team раз в год отчёт о пентесте.

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

Сегодня поговорим про OpenAEV (Open Adversarial Exposure Validation) - open-source платформу, которая пытается закрыть этот гэп.

🧠 OpenAEV

OpenAEV является платформом для валидации экспозиции под реальными сценариями атак.

💡 Ключевая идея проста,
не просто проверять наличие уязвимостей, а проигрывать реальные сценарии атак и смотреть:
👁 что срабатывает,
🙈 что остаётся незамеченным,
📄 где защита существует только в отчётах.

Проект вырос из OpenBAS и развивается как самостоятельная AEV-платформа.

⚙️ Строим сценарии

В OpenAEV всё строится вокруг сценариев:

1️⃣ Берётся описание угрозы
(MITRE ATT&CK, Threat Intelligence, реальные кейсы).

2️⃣ Формируется сценарий атаки:
🪜 шаги атакующего,
📌 ожидаемые события,
🛡 реакции защиты и команды.

3️⃣ Сценарий проигрывается в инфраструктуре:
🔧 injectors для генерации действий,
📡 collectors для сбора телеметрии из EDR, SIEM и др.

📊 В итоге можно ответить на практичные вопросы:
- увидит ли EDR эту активность;
- появится ли нужный алерт;
- сколько времени займёт реакция SOC.

🆚 Чем OpenAEV отличается от «симуляторов атак»

🔹 Threat-driven подход
Сценарии строятся от реальных TTP, а не от абстрактных техник.
🔹 Фокус на экспозицию, а не на взлом
Цель понять, где защита не работает, а не просто «пробить периметр».
🔹 Проверка не только техники, но и процессов
👥 Моделируются реакции людей, эскалации, человеческие ошибки.
🔹 Open source
🔓 Можно развернуть локально, писать свои сценарии и injectors.

🏗 Архитектура и развёртывание

🐳 Docker-ориентированный подход
🧱 Модульная архитектура
🔌 Поддержка кастомных интеграций

☺️ Платная версия

Существует также платная версия продукта: Enterprise Edition. Она включает AI-ассистента и помощника автоматизации. Но на практике обычно хватает open-source.

🧨 Подведём итоги

OpenAEV это попытка сделать безопасность инженерной.

Не ❌ «у нас есть средства защиты», а ✅ «мы знаем, как именно они поведут себя при атаке».

P.S. проект точно заслуживает внимания для open-source экосистемы.

🔗 GitHub:
https://github.com/OpenAEV-Platform/openaev

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #OpenAEV #CyberSecurity #Infosec #CTEM #RedTeam #SOC #ThreatModeling #SecurityEngineering

🎄 С наступающим Новым 2026 годом, друзья! 🎄

2025-й показал, каким станет будущее ИБ:
➖ИИ научился атаковать и защищаться,
➖дипфейки вышли за пределы соцсетей,
➖air-gap перестал быть абсолютной защитой,
➖данные и модели стали новой критической инфраструктурой.

Спасибо, что весь этот год вы были с нами! Читали, поддерживали лайками и оставались внимательными к рискам.

Пусть в 2026-м будет меньше инцидентов, больше осознанной безопасности и правильных вопросов к технологиям.

До встречи после праздников 🥳

Stay secure and read SecureTechTalks📚

🚨 Принимаем радиосигнал без антенн

Исследователи доказали, что «безантенные-устройства» могут принимать команды по воздуху

В кибербезопасности есть догма: если устройство физически изолировано от сетей, то оно безопасно.

Air-gapped системы десятилетиями считались защищенными на физическом уровне.

В конце 2025 года эта догма дала трещину.

Исследователи опубликовали работу, в которой показали:
встраиваемые устройства без Wi-Fi, Bluetooth, NFC и даже без антенн могут принимать данные через радио сигналы.

🔍 Начало

Поводом для исследования стали странные наводки в embedded-устройствах:
ADC-входы и GPIO иногда фиксировали «шум», который не объяснялся электрическими помехами.
Команда решила проверить гипотезу:

а что если устройство не просто ловит шум, а реально принимает радиосигнал?

🧪 Что именно проверяли

Исследователи собрали 14 разных embedded-платформ:
➖промышленные контроллеры,
➖платы разработчиков,
➖аппаратные криптокошельки,
➖беспилотные системы.
Устройства не имели:
❌ радиомодулей,
❌ микрофонов,
❌ инструментов беспроводной связи.

Только обычные платы, дорожки, GPIO и ADC.

📡 Антенны не нужны

Оказалось, что:
➖PCB-дорожки ведут себя как непреднамеренные антенны;
➖ADC-входы способны демодулировать радиосигнал;
➖диапазон 300-1000 МГц;
всё это работает без модификации железа, только за счёт ПО.

В ряде конфигураций соотношение сигнал/шум превышало 30 дБ.

Другие особенности:
📍 сигнал принимался через стены,
📍 на расстоянии до 20 метров,
📍 со скоростью до ~100 кбит/с.

⚠️ Насколько это опасно?

Нужно понимать, что такой подход не «взлом с нуля». Злоумышленник один раз получает код на устройство, например с помощью:
- supply-chain,
- вредоносную прошивку,
- уязвимость в обновлении,

А дальше открывается целый пласт возможностей:
🔹 передавать команды по радио,
🔹 поддерживать скрытый C2-канал,
🔹 управлять air-gapped устройством без физического доступа.

🛡 Нужно ли предпринимать меры?

Нужно понимать, что air-gap не стратегия, а допущение.

Тем не менее есть база, которую стоит учитывать для критичных систем:
➖экранирование корпусов,
➖заземлённые сплошные платы,
➖анализ RF-поведения устройств,
➖контроль эфирной обстановки,
➖пересмотр требований к embedded-безопасности.

🧨 Вывод

🚫 Air-gapped ≠ isolated
📡 Даже «немые» устройства могут слушать эфир
⚠️ Физическая изоляция больше не гарантирует безопасность

Мы вступаем в эпоху, где угрозы рождаются не только в коде, но и непосредственно в железе.

🔗 Источник:
arXiv: Talking to the Airgap: Exploiting Radio-Less Embedded Devices as Radio Receivers

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #AirGap #EmbeddedSecurity #HardwareSecurity #RFsecurity #Infosec #CyberSecurity #ICS #OTsecurity #CovertChannels

🚀 Superagent: как защитить ваши ИИ-агенты от взлома, ошибок и утечек данных

ИИ-агенты - это движки  автоматизации, RAG-конвейеры, workflow с внешними инструментами, критические бизнес-процессы. Но они имеют свои уязвимости и вектора атак, такие как:
🔓 prompt injection
⚠️ unsafe tool calls
🧠 model hallucinations
🔒 утечка PII/PHI и секретов

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

🛡 Что такое Superagent?

Superagent - это open-source платформа (⭐ 6.3k ⭐ на GitHub) с целевыми guardrail-моделями. Решение позволяет:
✔️ обнаруживать потенциальные и реальные угрозы
✔️ проводить валидацию выходов LLM
✔️ редактировать чувствительные данные

Инструмент работает в реальном времени, с минимальной задержкой.

🧠 Основные компоненты

🔹 Guard: защита входных данных
- ловит prompt-инъекции
- блокирует опасные запросы
- предотвращает вредоносные tool-вызовы

🔹 Verify: проверка выходов
- сопоставляет ответы моделей с корпоративными источниками
- фильтрует галлюцинации
- проверяет соответствие политике

🔹 Redact: автоматическое удаление чувствительных данных
- PII/PHI/секреты
- можно настроить режим placeholder или переписывания

Внутренние модели работают как отдельные API, но могут быть собраны в мощную guardrail-цепочку для обеспечения безопасности всего AI-workflow’а.

🛠 Какие проблемы решает?

Superagent закрывает реальные практические кейсы:
🔥 Защита ИИ-асистентов и чат-ботов от prompt-инъекций и взлома
🏢 Корпоративные пайплайны: проверка ответов перед публикацией/использованием
📊 Обработка данных и логов с автоматическим redaction
🤖 Мониторинг автономных агентов: контролирует безопасные действия перед выполнением
📜 Автоматизация соответствия стандартам (GDPR, NIST, EU AI Act и др.)

⚙️ Интеграция и использование

Superagent можно внедрить в любой стек.

🧩 API-интеграция отправляете запросы и получаете безопасные результаты
🐍 SDK (Python / TypeScript) встроить напрямую в код
💻 CLI-инструмент для аудит-скриптов или локального анализа
☁️ Hosted или self-hosted гибкий выбор инфраструктуры

⚡ Проект включает:

📦 модульный SDK
🛡 low-latency защиту
🔄 независимость от LLM-провайдера
🧠 готовые паттерны для встраивания в workflow

Superagent совместим с любыми моделями и фреймворками от OpenAI до Anthropic, от RAG-сетапов до кастомных агентов.

🔗 Ссылка на GitHub: https://github.com/superagent-ai/superagent

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #AIsecurity #OpenSource #Superagent #Guardrails #PromptInjection
#AIDefense #Compliance #LLMSecurity #CyberAI #DevSecOps #AIagents

🧠 ИИ и оценка уязвимостей: революция или скам?

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

📊 Как тестировали?

Команда прогнала 31 000+ CVE-описаний через шесть крупных LLM:
• GPT-4o
• GPT-5
• Llama 3.3
• Gemini 2.5 Flash
• DeepSeek R1
• Grok 3

❗️Модели оценивали исключительно текст описания уязвимости. Им не давали:
✔ названия продуктов,
✔ версий ПО,
✔ идентификаторы CVE,
✔ данные поставщиков

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

То есть задача была не просто прочитать описание, а воссоздать ключевые метрики CVSS, которые определяют приоритет реагирования на уязвимость.

🧩 Где ИИ эффективен?

Модели показали лучшие результаты там, где язык описания был прямолинейным и содержал явные сигналы:
🔹 Attack Vector (находится ли уязвимость в сети или локально). Примерно 89% точности у Gemini и GPT-5.
🔹 User Interaction (нужен ли пользовательский ввод/клик для эксплуатации). Схожие результаты.

Такие аспекты часто прямо указаны в описаниях CVE.

Кроме того:
🔸 Confidentiality Impact (угроза утечки данных) и
🔸 Integrity Impact (изменение данных)
тоже были оценены достаточно успешно. GPT-5 показывал 70+ % точности здесь.
👉 То есть когда модель видит явные сигналы в тексте, она может прилично предсказывать, что именно представляет собой уязвимость. Это может помочь аналитикам быстро отсеивать тривиальные случаи.

😬 Где ИИ слаб

Явные ограничения:
❗ Availability Impact (влияние на доступность системы). Результаты чуть ниже (≈68 % у GPT-5), потому что описания редко точно объясняют, насколько нарушение службы критично.
❗ Privileges Required (необходимые привилегии). Модели путают «отсутствие» и «низкий уровень», потому что тексты часто не содержат чётких указаний.
❗ Attack Complexity  предугадывается плохо, в основном из-за перекоса данных в сторону «низкой сложности».
📌 Анализ ошибок также показал:
29 % CVE были неправильно оценены всеми моделями одновременно по Availability Impact.

В других метриках 4 из 6 моделей согласовывались в неправильных ответах до 36 % случаев, что говорит о систематической ошибке, а не случайности.

🤝 Ансамбли моделей

Исследователи попробовали объединить предсказания всех шести моделей в meta classifier. Это дало небольшие улучшения, но не решило фундаментальной проблемы:
отсутствие информации в описании всё ещё мешает точному пониманию угрозы.

🧠 Контекст наше всё

Самый важный вывод исследования:
👉 LLM могут быть полезны для предварительной оценки, но на текущий момент они не заменят человека или полноценные системы анализа контекста и метаданных.

🔗 Оригинал исследования: LLMs can assist with vulnerability scoring, but context still matters.

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #AIsecurity #LLMs #CVE #VulnerabilityAssessment #CyberSecurity #Infosec #AIinSec #ThreatIntel #ContextMatters #AutomationLimits #CyberResearch

💥 La Poste под DDoS: как «трафик» положил национальную почту Франции

18–19 декабря 2025 года. Предновогодний пик. Миллионы посылок в пути, платежи, мобильное приложение, курьеры на самокатах. Что может пойти не так?

ВСЁ Инфраструктура французской госпочты La Poste в самый неподходящий момент начинает сыпаться.

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

⏱️ 18+ часов простоя
👥 2+ млн пользователей
📦 ~1,5 млн задержанных отправлений
💸 €12–15 млн прямого ущерба

Вот так злоумышленники поздравляют с наступающими праздниками 😱

🧠 Механика атаки

Атака состояла из двух слоёв, комбинация которых оказалась фатальной.

🌊 Первый слой L3/L4
➖NTP / DNS / SSDP amplification
➖SYN/ACK floods с IP spoofing
➖ботнет из ~200 тыс. IoT-устройств
➖пиковая нагрузка ≈ 620 Gbps

Firewall’ы и edge-устройства начали терять состояние соединений ещё до того, как трафик дошёл до приложений.

🧬 Второй слой L7
➖HTTP/2 Slow POST / GET
➖Slowloris / RUDY
➖cache busting
➖атаки через WebSocket

Трафика было немного, но:
соединения держались десятки секунд, worker pools истощались, а event loop’ы блокировались.

📉 В результате 503 на почти все запросы, даже при «нормальном» входящем объёме.

🕵️ Что пошло не так у La Poste?

Из открытых данных и утечек в профильных медиа вырисовывается картина системных проблем:
❌ не было always-on DDoS scrubbing
❌ трафик шёл напрямую на origin
❌ отсутствовал Anycast и BGP-очистка
❌ load balancer стал узким местом
❌ API перегрузили backend и базы данных
❌ мониторинг не отработал аномалию вовремя

Один перегруженный слой запустил каскадный отказ всей цепочки сервисов, почти, как снежный ком...

🇷🇺 В РФ такое невозможно?

Если заменить La Poste на Почту России, СДЭК, Boxberry, Ozon / Wildberries то по факту архитектурный риск останется тем же:
➖публичные /track и /status
➖сезонные пики (особенно Q4)
➖дешёвые DDoS-for-hire сервисы

По статистике провайдеров защиты, в четвёртом квартале DDoS-активность растёт в 3–4 раза, и атакуют именно логистику и e-commerce.

🧠 Мысли вслух

Современный DDoS является инструментом точечного удушения бизнеса в самые чувствительные моменты. Он дешёвый для атакующего, дорогой для компании и особенно опасен для high-traffic инфраструктур.

🔗 Источники

SecurityWeek — https://www.securityweek.com
Breached / Digital Siege — https://breached.company/seven-days-of-digital-siege-inside-this-weeks-ransomware-explosion/

Stay secure and read SecureTechTalks 📚

#DDoS #LaPoste #CyberSecurity #SecureTechTalks #InfoSec #DDoSProtection #SOC #InfrastructureSecurity #EcommerceSecurity #IncidentResponse

Channel photo updated

🤖📊 Отчёт CSA: AI Governance, как фактор выживания

В 2025 году организации уже не просто пробуют ИИ, а внедряют его в продакшн.
Проблема в том, что скорость внедрения ИИ сильно опережает зрелость AI Governance.

CSA выпустили новый отчет, который основан на глобальном опросе IT- и ИБ-профессионалов (≈300 организаций), которых спрашивали не только о технологиях, но и о структурах AI Governance, ответственности за AI-риски и уровне подготовки команд.

Главный вывод исследования:
👉 Зрелый AI Governance самый сильный предиктор готовности компании к безопасному внедрению ИИ.

Не важно какой размер или бюджет у вашей компании. Важно иметь зрелый Governance.

📈 1. Множитель зрелости

Что такое зрелый AI Governance на практике?
Это рабочая система управления, которая включает:
- чёткие роли и зоны ответственности,
- политики использования ИИ,
- контроль жизненного цикла моделей,
- процедуры оценки рисков,
обучение сотрудников.

🔥 Согласно отчёту, организации с формализованным AI Governance:
в 2 раза чаще внедряют agentic AI, чаще проводят security-оценку моделей,
говорят о способности управлять AI-рисками.

Компании, где Governance «в процессе развития», стабильно проигрывают по всем этим параметрам.

🛡️ 2. Безопасность ИИ

CSA подчёркивает ключевую мысль:

AI Security - это не только защита данных или моделей.
Это управление процессами, людьми и ответственностью.

Без AI Governance невозможно:
- понять, где именно используется ИИ,
- определить, кто отвечает за последствия его работы,
- встроить AI-риски в общую систему управления ИБ.

🧑‍💼 3. Shadow AI

Отдельный тревожный сигнал - Shadow AI.
Сотрудники используют внешние ИИ-сервисы без согласования и контроля.

Это приводит к:
⚠️ утечкам данных,
⚠️ невозможности аудита,
⚠️ регуляторным рискам.

Именно зрелый AI Governance позволяет превратить хаотичное использование ИИ в контролируемый и безопасный процесс, не убивая инновации.

👨‍💼 4. Кадровый разрыв

ИИ внедряется быстро, а навыки сотрудников медленно.

Отчёт фиксирует:
нехватку специалистов по AI Security и слабую подготовку ИБ-команд. Возникает разрыв между стратегией и реальными процессами.

Организации с развитым AI Governance:
в 2–3 раза чаще обучают сотрудников, интегрируют AI-риски в SDLC, переводят знания в практику.

📊 5. Какие риски беспокоят компании больше всего?

По данным опроса:
🔹 №1 риск утечки данных через AI-сервисы
🔹 Модельные атаки и отравление данных воспринимаются как второстепенные

Компании недооценивают сложные и долгосрочные AI-угрозы.
🔁 AI Security больше не «поддержка», а драйвер

Интересный сдвиг:
👉 ИБ-команды больше не догоняют ИИ, они начинают его возглавлять.
Более 90% специалистов:
тестируют ИИ для threat detection, используют ИИ в red teaming, автоматизируют SOC-процессы.

AI Governance становится не тормозом, а инструментом масштабирования безопасности.

🔗 Отчет Cloud Security Alliance "The State of AI Security and Governance Survey Report (2025)"

Stay secure and read SecureTechTalks 📚

#AIsecurity #AIGovernance #CyberSecurity #AIrisks #SecureTechTalks #CloudSecurity #AgenticAI #ShadowAI #CyberTrends2025

🧠⚛️ Квантовый ИИ против кибератак: хайп или рабочий инструмент?

Когда говорят о квантовых вычислениях в кибербезопасности, обычно рисуют две крайности:
🔮 «Квантовый компьютер взломает всё»
или
😒 «Это бесполезная игрушка для физиков»

Но что если квантовые технологии уже сейчас могут чуть-чуть, но стабильно улучшать детектирование атак в реалистичных условиях?

🎯 Проблематика SOC

Современные системы детектирования атак живут в крайне нестабильной среде:
📉 Дрейф данных: сетевой трафик и поведение пользователей постоянно меняются
⚖️ Дисбаланс классов: атак мало, легитимных событий много
🎭 Пограничные случаи: атака выглядит почти как нормальное поведение
🧱 Жёсткие бюджеты: по признакам, latency и вычислениям

Даже хорошо настроенные ML-модели пропускают редкие атаки или начинают генерировать ложные срабатывания.

Ключевой вопрос:
👉 Можно ли улучшить границу принятия решений, не раздувая модель и инфраструктуру?

⚛️ Квантовая польза

Важное уточнение:
❌ квантовые компьютеры не ускоряют ML «в лоб»
❌ они не заменяют нейросети
❌ они шумные, маленькие и ограниченные
Но у них есть одно интересное свойство 👇

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

И дело не в скорости, а в форме decision boundary.

🧩 Архитектура

Вместо попытки «засунуть всё в квантовый компьютер» можно использовать гибридный подход:
🔹 Шаг 1. Классический ML
Компактная классическая модель:
- сжимает исходные данные
- устраняет шум
- формирует низкоразмерное, устойчивое представление

💡 Квантовая часть получает уже осмысленные признаки.

🔹 Шаг 2. Квантовая «голова» (2–4 кубита)
Дальше возможны два сценария.

🧠 Квантовое ядро + SVM
- квантовая схема строит нелинейное ядро
- классический SVM ищет оптимальную границу
- квантовая часть не обучается
- высокая стабильность и низкая чувствительность к шуму

🧪 Обучаемый квантовый классификатор
- параметризованная квантовая схема
обучается вместе с классической частью
- больше выразительности
выше риск нестабильности и деградации

📊 Что дают квантовые модели на практике

Квантовые модели:
❌ не уничтожают классические
❌ не дают кратного прироста accuracy
Но:
✅ лучше ведут себя на пограничных случаях
✅ чуть реже пропускают редкие атаки
✅ чуть меньше ложных срабатываний
✅ сохраняют компактность модели
Учитываем простоту:
- несколько кубитов
с неглубокими схемами
- нет роста числа признаков

🧠 Подведём итоги

1️⃣ Квантовый ML уже можно рассматривать как узкоспециализированный модуль, а не игрушку
2️⃣ Он полезен точечно, а не повсеместно:
- редкие атаки
- сложные границы
- строгие ресурсные ограничения
3️⃣ Гибридная архитектура обязательна
4️⃣ Фиксированные квантовые ядра сейчас практичнее, чем полностью обучаемые схемы

🔗 Больше подробностей можно найти в статье.

Stay secure and read SecureTechTalks 📚

#кибербезопасность
#quantumML
#машинноеобучение
#информационнаябезопасность
#IDS
#SOC
#AIsecurity
#квантовыевычисления
#anomalydetection
#SecureTechTalks

🧨 KICS: как искать уязвимости на этапе разработки

Многие думают, что безопасность начинается на этапе SAST или pentest’а.  Но большинство уязвимостей появляются ещё до первой строки бизнес-кода, например в Kubernetes YAML.

🔍 Что такое KICS?

KICS (Keeping Infrastructure as Code Secure) - open-source инструмент от Checkmarx для анализа Infrastructure as Code.

KICS ищет security-ошибки, misconfiguration и опасные паттерны в IaC-файлах до деплоя, пока всё ещё можно починить одной строкой.

📦 Поддерживаемые форматы:
- Terraform
- Kubernetes (YAML)
- Helm
- Dockerfile
- Ansible
- CloudFormation
- ARM Templates
- Pulumi
- Serverless

Если у вас cloud, CI/CD и DevOps, то вы уже в зоне риска, а KICS может стать вашим ранним радаром.

🔥 KICS не «ещё один линтер»

❌ Это не форматтер
❌ Это не просто best practices
❌ Это не SAST

KICS проверяет реальные security-риски, а не стиль или синтаксис.

Он смотрит на инфраструктуру глазами атакующего и задаёт неприятные вопросы ещё до деплоя.

🧠 Принцип работы

KICS использует:
🔍 предопределённые security-queries
🧩 разбор IaC-структур
🛠️ rule-based движок
📊 модель критичности (Low → Critical)
Каждая находка это:
- описание риска
- уровень критичности
- ссылка на best practice
- рекомендации по исправлению

📡 Типичный сценарий

DevOps-пайплайн:
🧑‍💻 Dev пишет Terraform / YAML
🔁 PR уходит в Git
⚙️ CI запускает KICS
🚨 KICS находит опасные конфигурации
❌ Pipeline падает
🔧 Конфиг исправляется
✅ Только потом деплой
Security shift-left без конфликтов и ночных инцидентов.

🧱 Архитектура и возможности
🧩 CLI-инструмент
🧠 Более 1000 security-правил
🔄 Простая интеграция в CI/CD
📄 JSON / SARIF / HTML отчёты
🛠️ Кастомные правила
🌍 Активное сообщество
🔓 Полный open-source
Работает быстро, масштабируется без сюрпризов.

⚠️ Минусы (куда без них)

📚 Некоторые правила избыточно строгие
🧠 Нет понимания бизнес-контекста
❌ Не заменяет SAST / DAST
🔧 Требует тюнинга под конкретную среду

Однако для инструмента ранней стадии это ожидаемо и нормально.

🔗 GitHub: https://github.com/Checkmarx/kics

Stay secure and read SecureTechTalks 📚

#KICS #IaC #DevSecOps #CloudSecurity #OpenSource #Terraform #Kubernetes #AppSec #ShiftLeft #SecureTechTalks

🧠🛡️ LLM помогает находить баги в смарт-контрактах

Смарт-контракты одна из самых сложных и рискованных частей Web3-экосистем. Их ошибки это не просто «падение системы», а потерянные миллионы долларов для пользователей.

🎯 Обычные статические анализаторы вроде Slither не справляются: они генерируют массу ложных срабатываний или пропускают «нестандартные» уязвимости, когда логика контракта уходит от шаблонов.

Исследователи из Georgia Tech предложили интересную альтернативу: систему LLMBugScanner, в которой не одна LLM, а группа LLM, работают в связке и голосует за результаты.

🧪 Одиночные модели не панацея

Если запустить одну модель (даже fine-tuned), она может сработать на одни типы ошибок, но провалиться на других:
🔹 Модели хорошо находят наборные, стандартные баги вроде integer overflow, но «слепнут» на контекст логики.
🔹 Результаты могут отличаться от прогона к прогону, потому что модель непоследовательна.
🔹 Fine-tuning помогает на одних данных, но портит результаты на других.

Это типичная проблема: LLM понимают шаблоны, но не логику, семантику и нюансы исполнения кода.

🧩 LLMBugScanner

Чтобы устранить вышеупомянутые ограничения, реализована архитектура LLMBugScanner, которая делает две вещи:

1) 🎯 Адаптация к контексту смарт-контрактов
Модели проходят двухступенчатое fine-tuning-обучение:
На большом датасете Solidity-контрактов с отмеченными типами уязвимостей, чтобы понять общий «язык» и паттерны Ethereum-кода.

На маленьком датасете с CVE-контрактами, чтобы научиться опознавать конкретные баги и описывать их.

📌 В результате модели перестают постоянно неправиль­но классифицировать ошибки (например, путать проблемы доступа с арифметическими).

2) 🤝 Коллективное голосование моделей
Вместо того чтобы полагаться на одну «умную» сеть, LLMBugScanner запускает пять разных моделей, каждая анализирует контракт, а затем результаты объединяются через систему голосования:
🔹 Weighted Voting: сильные модели «весомее»
🔹 Priority Voting: решает конфликты по приоритету моделей

Итог: система ловит больше багов и с меньшим шумом, чем любая модель по отдельности.

📊  Тестирование

Команда проанализировала 108 реальных смарт-контрактов с известными уязвимостями из базы CVE. Результаты:
🔥 Ensemble-подход поднял точность обнаружения до ~60 % в топ-5 выводов, что на ~19 % выше, чем у одной лучшей модели.

🧠 Преимущества и ограничения

✅ Групповой разум работает лучше, чем одиночные модели.
✅ Снижается влияние случайных ошибок и индивидуальных слабостей моделей.
✅ Лучше охватываются разные типы уязвимостей.

Ограничения:
⚠️ Некоторые редкие классы ошибок (например, сложные ошибки доступа или логической структуры) всё ещё остаются трудными для обнаружения даже в ансамбле.
⚠️ Около 10 % выводов моделей всё ещё могут содержать «галлюцинации».

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

Stay secure and read SecureTechTalks 📚

#CyberSec #Web3Security #SmartContractAudit #LLM #AIinSecurity #DeFi #Blockchain #SecureTechTalks #BugBounty

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

Первые документально подтверждённые 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

🧠 Как взломать нейросеть, не трогая её весов

Когда говорят об атаках на ИИ, в первую очередь вспоминают про два сценария:
🔐 либо атакующий крадёт веса модели,
🎯 либо подсовывает ей очевидные 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

🔥 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-агент в настоящий enterprise-контур и сравнить его с живыми профессиональными пентестерами?

Не CTF или лаборатории, а реальная прод-сеть на ~8 000 хостов.

🔬 Само исследование

Команда из Stanford и CMU впервые сравнила:
👨‍💻 10 опытных пентестеров
🤖 несколько автономных AI-агентов
🏫 живую университетскую инфраструктуру
- 12 подсетей, VPN, Kerberos
- Linux, Windows, IoT, embedded
- IDS, EDR, патчи, реальные пользователи

Результаты фиксировались, проверялись и реально закрывались IT-службой.

🧠 ARTEMIS не «LLM с nmap»

В качестве агента использовался ARTEMIS: мультиагентный red-team-фреймворк.

Он состоит из:
🧑‍✈️ supervisor-агента (планирует атаку)
🐝 роя субагентов (работают параллельно)
🧪 триаж-модуля (проверка и классификация багов)
🧠 долгоживущей памяти и динамических промптов

Важно: ARTEMIS лишь организует работу моделей.

📊 Результат

ARTEMIS:
🥈 2-е место в общем рейтинге
🚨 обогнал 9 из 10 живых пентестеров
🔍 нашёл 9 валидных уязвимостей
✅ 82% находок реальные баги

Другие агенты (Codex, CyAgent, MAPTA) либо показали слабый результат, либо вообще не справились.
👉 Выиграла не модель.
👉 Выиграла архитектура агента.

⚔️ Люди vs ИИ: в чём разница

👨‍💻 Люди
- сильны в GUI и браузерах
- полагаются на опыт и «чутьё»
- не умеют атаковать параллельно

🤖 ARTEMIS
- атакует десятки целей одновременно
- не устаёт и не забывает
- уверенно работает в CLI

Забавный момент:
люди не смогли открыть старый iDRAC из-за TLS, а  ARTEMIS просто использовал curl -k и получил доступ.

⚠️ Ограничения ИИ

- больше false positive
- плохо работает с GUI
- иногда «рано сдаёт работу», не докручивая цепочку до RCE

Однако кажется, что временные проблемы агентов.

💰 Самая неприятная часть

👨‍💻 пентестер в США: ~$125 000/год
🤖 ARTEMIS (GPT-5): $18/час ($37 000/год)

ИИ уже сейчас в 3–4 раза дешевле человека.

🧠 Главный вывод

ИИ делает атаки масштабируемыми.

А значит, такие агенты будут у атакующих. Защитникам нужно учиться думать как AI-red team.

🔗 Исходники ARTEMIS уже выложены: 👉 https://github.com/Stanford-Trinity/ARTEMIS

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #AIsecurity #Pentest #RedTeam #CyberSecurity #AIagents #OffensiveSecurity #CISO #AppSec #Infosec

🤖🔧 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