🛠 Reconmap: весь пентест в одной платформе

В поиске инструмента, который объединит планирование, исполнение, отчётность и хранение результатов тестов на проникновение?

Знакомьтесь — Reconmap.
Это не просто тулза, это полноценная SOC-платформа с возможностью командной работы, API, шифрованием данных и подключением кастомных скриптов.

🔍 Что умеет Reconmap?

🧩 Управление проектами и задачами
Создавайте пентест-проекты, делите их на задачи, назначайте исполнителей и отслеживайте прогресс.

📋 Хранение улик и данных
Загружайте файлы, результаты сканирования, записи команд и уязвимости в рамках каждого проекта.

📊 Автоматическая отчётность
Экспортируйте структурированные отчёты (PDF/HTML) — настраивайте шаблоны, подключайте CWE, CVSS и MITRE ATT&CK.

💻 CLI и API
Запускайте команды из терминала и автоматизируйте отчётность через REST API. Отлично интегрируется в CI/CD пайплайны.

🔐 RBAC и изоляция данных
Права доступа на уровне пользователей и команд. Безопасность и конфиденциальность прежде всего.

🧠 Почему стоит попробовать?

✅ Бесплатно и с открытым исходным кодом
✅ Поддержка скриптов и плагинов на Python и Bash
✅ Web-интерфейс, адаптированный под мобильные устройства
✅ Возможность хостить у себя или в облаке
✅ Совместим с такими тулзами как Nmap, Nikto, sqlmap, Burp Suite

⚙️ Use-case: SOC + RedTeam

🤝 Reconmap подходит как для одиночных ресерчеров, так и для больших команд с несколькими пентестерами, аналитиками и менеджерами.

Используется как:
➖ЦУП для Offensive Security проектов
➖Хранилище артефактов и отчётов
➖Инструмент для соблюдения compliance (ISO 27001, PCI DSS и пр.)

🌐 Где взять?

🔗 GitHub: github.com/reconmap/reconmap
📦 Установка через Docker
📚 Документация и API reference внутри репозитория

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #Reconmap #Pentest #RedTeam #CyberSecurity #OpenSource #SOCtools #OffSec #VulnerabilityManagement #PenetrationTesting #InfoSecTools

🔒 Как утекают персональные данные через промты для AI ассистентов

Разоблачение скрытой угрозы от "безобидных" ИИ-ассистентов. 

🌐 Суть проблемы 

Пользовательские промты — даже помеченные как "конфиденциальные" — массово собираются платформами ИИ для обучения моделей и передачи третьим лицам. 

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

🔍 Механизм утечки 

1⃣ Ловушка "Улучшения сервиса" 
При первом запуске вас просят согласиться на "анонимный сбор данных". Галочка стоит по умолчанию, а формулировки намеренно размыты. 

2⃣ Миф об "анонимности" 
Даже если логины удаляются, контекст промта позволяет идентифицировать: 
- Организацию (через профессиональную терминологию) 
- Личность (по стилистике и уникальным деталям) 
- Геолокацию (через упоминания локальных реалий) 

3⃣ Цепочка компрометации 
Ваш промт → Серверы ИИ-платформы → Дата-центры партнёров → Открытые датасеты → Dark Web. 

Реальный пример: Инженер оптимизировал SQL-запрос через ИИ — через 3 недели код появился у конкурента на GitHub. 

💥 Риски для бизнеса 
- Утечка патентов и ноу-хау 
- Компромат на закрытые переговоры 
- Нарушение GDPR/NIST/ФЗ-152 (штрафы до 20 млн €) 
- Восстановление архитектуры внутренних систем 

💥 Риски для частных лиц 
- Шантаж личными переписками 
- Кража цифровой личности 
- Таргетированный фишинг под ваш стиль общения 
- Утечка биометрических данных 

Громкий кейс: В 2024 году через слитые промты хакеры реконструировали IT-инфраструктуру канадского банка. 

🛡️ Инструкция по защите 

➖ Жёсткие настройки приватности 
Немедленно отключите "Обучение на моих данных" в профиле. Гайды для платформ: CNET

➖ Цензура промтов 
Никогда не вводите: 
- Паспортные данные и биометрию 
- Ключи API и сертификаты 
- Названия внутренних корпоративных систем 
- Код с комментариями об уязвимостях 

➖ Инструменты-посредники 
- PrivateGPT (офлайн-обработка на вашем ПК) 
- Docker-контейнеры с изолированным ИИ (GitHub)
- Шифрование промтов (плагины типа GhostPrompt) 

➖ Корпоративные меры 
- Запрет на ввод данных класса "Совершенно секретно" в ИИ 
- VPN с анализом трафика на утечки промтов 
- Регулярные аудиты истории запросов 

🔮 Грядущее регулирование

ЕС разрабатывает "AI Data Shield Act", который потребует: 
- Явного подтверждения для сбора КАЖДОГО промта 
- Штрафов до 8% глобального оборота компании за нарушения 
- Публичных аудитов алгоритмов

💎 Ключевой вывод: 

ИИ — мощный инструмент, но слепое доверие к его конфиденциальности — прямой путь к катастрофе. Относитесь к каждому промту как к ключу от сейфа с вашими секретами.

🔔 Экстренный чек-лист: 

1⃣ Проверьте историю своих промтов 
2⃣ Удалите всё, что содержит конфиденциальные данные 
3⃣ Обновите пароли к ИИ-аккаунтам 

📌 Источники для глубокого погружения: 

➖Как защитить промт
➖Доклад Black Hat 2025 об атаках через ИИ

Stay secure and read SecureTechTalks 📚

#ИИБезопасность #УтечкаДанных #КиберБезопасность #ИИ #DataLeak #SSH #TerrapinAttack #ЗащитаДанных #ИнформационнаяБезопасность #TechNews #SecureTechTalks #Промт #DarkWeb #GDPR #КиберУгрозы #ИИЭтика

💢 12 КРИТИЧЕСКИХ ПРОБЛЕМ ВНЕДРЕНИЯ RAG

Разбираем "подводные камни" RAG-систем, выявленные при работе с реальными проектами.

➖OCR-шум: Тихий убийца точности 

⚙ Проблема: Распознавание сканированных PDF (отчёты, документы инцидентов) даёт до 37% ошибок → эмбеддинги мусорных фрагментов → ложные ответы. 

🛡Решение: Каскадная очистка через Tesseract + easyOCR + regex-фильтры + ручная верификация *ключевых документов*. 

➖Чанкинг: Невидимая грань сбоя 

⚙ Проблема:
- Чанки <200 токенов = фрагментация контекста (потеря связей IoC-тактик) 
- Чанки >500 токенов = высокие латенции

🛡 Вывод: 200-500 токенов — золотая середина. Меньше = лаги, больше = потеря контекста»

➖ FAISS: Магия, которая ломается в scale 

⚙ Проблема: При >10 000 эмбеддингов время поиска растёт экспоненциально (с 50 мс до 1.2 сек!). 

🛡Решение: Жёсткая фильтрация по метатегам (тип документа, дата, критичность)

➖Многоязычные провалы 

⚙ Проблема: GPT-4o/Claude игнорируют нюансы локалей → ошибки в терминах типа «стековый буфер» (RU) vs «stack buffer» (EN). 

🛡 Решение: DeepSeek-R1 для русского + кастомные эмбеддинг-модели, дообученные на доменных глоссариях. 

➖Ад зависимостей 

⚙ Проблема: Конфликты версий PyTorch + FAISS + OCR-libs → падения в продакшене. 

🛡 Решение: Docker-контейнеризация с фиксацией версий + тестирование на совместимость перед обновлениями. 

💻 Операционные Косяки 

➖Хрупкость scraping-пайплайнов

⚙ Проблема: Изменения структуры сайтов (например, порталов киберугроз) ломают 68% парсеров.

🛡 Решение: Приоритет API (где есть) + Scrapy + Selenium с ежедневным мониторингом сломанных XPath. 

➖GDPR/Compliance-ловушка 

⚙ Проблема: Облачные LLM (OpenAI и т.д.) = риски утечки sensitive data (лог-файлы, метаданные атак).

🛡 Решение: Самохостинг Ollama/Llama.cpp + шифрование эмбеддингов AES-256-GCM. 

➖Токсичные данные 

⚙ Проблема: Дупликаты, устаревшие IoC, битые PDF в корпусе → ложные паттерны угроз. 

🛡 Решение: Скрипты дедупликации + периодическая реиндексация + инструменты типа Great Expectations для валидации. 

➖Слепота без логов 

⚙ Проблема: Без анализа запросов/ответов невозможно выявить уязвимости RAG (например, утечка контекста). 

🛡 Решение: SQLite + Grafana для трекинга: пользователь, промт, рейтинг ответа, источник данных. 

⚖ Этичные и Системные Риски 

➖Дилемма прозрачности

⚙ Проблема: Показ источников → риски OSINT-разведки злоумышленниками. 

🛡 Решение: Динамическая политика (показ источников для SOC, скрытие для threat hunting). 

➖ Смещение данных → ложные выводы 

⚙ Проблема: Перекос в источниках (например, 80% отчётов Red Team) → RAG недооценивает Blue Team тактики. 

🛡 Решение: Балансировка весов документов + re-ranking с приоритетом сбалансированных источников. 

➖Иллюзия "умного" ИИ
 
⚙ Проблема: Пользователи переоценивают точность RAG → принятие решений на основе ошибо. 

🛡 Решение: Жёсткие предупреждения в интерфейсе + Evaluation Agent (автопроверка ответов перед показом). 

💎 Вывод: 
RAG — сложная инфраструктура, успех зависит от: 
1⃣ Качества данных (нет OCR-шума, актуальные IoC) 
2⃣ Инженерных решений (чанкинг, метатеги, логи) 
3⃣ Этичного проектирования («что скрыть» важнее чем «что показать») 

Stay secure and read SecureTechTalks 📚

#RAG#Кибербезопасность #AI #LLM #DisarmRAG #ThreatIntelligence #DataEngineering #GDPR #MLOps #SecureTechTalks #ИскусственныйИнтеллект

🛠️ Вспоминаем, что такое джейлбрейк ChatGPT — и как его остановить

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

🤖 Джейлбрейк простыми словами

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

Обычно всё начинается с безобидного запроса, а потом подсовывается скрытая команда — и LLM перестаёт следовать инструкциям разработчиков.

🎭 Какие методы используют?

➖Prompt injection — внедрение вредных инструкций прямо в запрос
➖Ролевые сценарии — модель разыгрывает роль и игнорирует запреты
➖Многошаговые цепочки — медленное подталкивание к запрещённой теме
➖Искажения символов — чтобы обойти фильтры
➖JSON-контексты — использование структурированных данных вместо текста
➖Визуальные трюки — скрытые команды в картинках

🧪 А насколько защищены современные LLM?

Тесты показывают, что даже передовые облачные и локальные модели вроде GPT‑4, Claude, Grok подвержены обходам. В частности, комбинированные многошаговые атаки и визуальные подсказки (например, стеганография) могут обмануть фильтры.

➖Модель GPT‑4o и аналогичные взламывались при грамотном промпте
➖Визуальные инъекции срабатывают примерно в 16% случаев
➖Открытые модели типа qwen или gemma почти не имеют защиты

🛡️ Способы защиты

✅ Ужесточение системных фильтров
✅ Обучение с помощью RLHF и модераторов
✅ Встроенные ограничения на уровне весов модели (weight-level suppression)
✅ Использование дополнительных LLM‑обёрток для проверки запроса
✅ Тестирование на многошаговые атаки и визуальные обходы

🔎 Саммери

🔸 Джейлбрейки — это не просто хакерская забава. Это реальный риск, если LLM применяется для корпоративных решений, автоматизации и даже в продуктах с доступом к конфиденциальным данным.
🔸 Понимание техник джейлбрейка помогает строить более надёжные, этичные и безопасные AI-системы.
🔸 Без комплексных защит LLM можно превратить в оружие — даже без участия разработчика.

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

Stay secure and read SecureTechTalks 📚

#SecureTechTalks #LLM #Jailbreak #PromptInjection #VisualPrompt #CyberSecurity #AISecurity #EthicalAI #SafeLMs #AIthreats

🎯 РФ вводит новый порядок работы с обезличенными ПДн

Правительство утвердило Постановление № 961 — ключевые правила формируют обезличенные выборки и управляют доступом к ним. Нормы вступают в силу с 1 сентября 2025 года.

🧩 Как это будет работать

1⃣ Формирование: уполномоченный орган (Минцифры + ФСБ) в течение 30 рабочих дней собирает обезличенные данные, группирует их по признакам (возраст, регион и т.п.).

2⃣ Анонимность: выборки создаются так, чтобы исключить возможность связывания данных с конкретным человеком или восстановления исходных значений.

3⃣ Доступ: запросы через личный кабинет с ЭЦП → рассмотрение за 5 дней → уточнение или отказ возможны. Хранение данных и доступ к ним ограничены четким контролем.

4⃣ Ограничения: доступ запрещён некоторым категориям (по постановлению № 538), и может быть приостановлен при угрозе людям, экологии, безопасности или культуре.

🌐 Контекст и защита данных

🔤Постановление реализует ФЗ‑233 (август 2024) — создание государственной системы “озеро обезличенных данных”.
🔤 Минцифры и Роскомнадзор готовят детальные методики обезличивания: перемешивание, декомпозиция, изменение структуры — чтобы исключить де‑анонимизацию.                                                    

🚀 Итоги коротко

➖ С 1 сентября 2025 — обязательная подача обезличенных выборок по запросу
➖Контроль — строгий и персонализированный
➖Операторы — штрафы и блокировка за нарушение
➖Киберсообщество — шанс использовать безопасные данные в threat intelligence и ML-проектах

Stay secure and read SecureTechTalks 📚

#кибербезопасность #обезличивание #персональныеданные #ПДн #анонимизация #ФГИС #Минцифры #ИБ #compliance #SecureTechTalks

🕷️ Новый взгляд на Black Hat: полный каталог инструментов безопасности

🔥 Готовы к настоящему арсеналу? Вышла обновлённая подборка Awesome Black Hat Tools — коллекция всех знаковых инструментов, которые когда-либо анонсировали на легендарных конференциях Black Hat!

Внутри вас ждёт:

✅ строгая структура по странам проведения Black Hat
✅ группировка по годам
✅ и, конечно, деление на ключевые категории:
➖Red Teaming 🟥
➖Blue Teaming 🟦
➖OSINT & Recon 🛰️
➖Exploit Development 💣
➖Malware Analysis 🦠
➖DFIR & Forensics 🕵️
➖Threat Intelligence 🔍
➖ICS/IoT/SCADA ⚙️
➖AppSec 🛡️

🔎 Впечатления

🎯 Во-первых, всё собрано в одном месте, без беготни по слайдам и видосам с конференций.
🎯 Во-вторых, структура позволяет за секунды найти инструменты под вашу задачу, будь вы пентестером, аналитиком, DFIR-специалистом или исследователем ICS.
🎯 В-третьих, каталог живой, его постоянно пополняют, и вы тоже можете внести свой вклад через pull request.

💥 Кому стоит заглянуть?

🔸 Red Team — чтобы подхватить последние атаки и методы обхода
🔸 Blue Team — чтобы не отставать в защите
🔸 Threat Hunters — чтобы видеть, с какими инструментами придут к вам завтра
🔸 Малваре-исследователям — для изучения трендов
🔸 Разработчикам AppSec — чтобы понять, какие новые угрозы в ПО демонстрировали на Black Hat

🌐 Где это лежит?

📎 GitHub-репозиторий: github.com/UCYBERS/Awesome-Blackhat-Tools

✅ В итоге

Black Hat давно превратилась в главный подиум мирового offensive и defensive инструментариума, а этот проект — идеальная карта сокровищ, чтобы не потеряться среди сотен наработок.

Если хотите разбирать, тестировать или просто быть в курсе, что обсуждает ИБ-сообщество, то данный репозиторий must-have.

Stay secure and read SecureTechTalks 📚

#blackhat #redteam #blueteam #osint #threatintel #forensics #malware #appsec #cybertools #SecureTechTalks

🔥 Локальное повышение привилегий в sudo — CVE‑2025‑32463

Эксперты обнаружили опасный баг в утилите sudo, который позволяет любой программе получить root-доступ, из-за того, что разворачивается chroot. Уязвимость CVE‑2025‑32463, включает все версии sudo с 1.9.14 по 1.9.17.

🛠 Механика

1⃣ Уязвимость активируется при использовании опции sudo -R <директория>, которая делает chroot на указанный каталог.
2⃣ Если в этом каталоге пользователь размещает собственный файл etc/nsswitch.conf, sudo подхватывает именно его — вместо системного.
3⃣ В nsswitch.conf можно прописать загрузку внешних NSS-библиотек (например, libnss_custom.so).
4⃣ Sudo загружает эти библиотеки в root-контексте до снятия префиксов, и они могут выполнить код с флагами root — атака готова

🎯 Влияние

➖Дистрибутивы с системным NSS и /etc/nsswitch.conf: Ubuntu 24.04, Fedora 41, macOS Sequoia
➖Затронуты все версии sudo от 1.9.14 до 1.9.17 включительно. Остальные тоже уязвимы — если была поддержка chroot.
➖ Системы с sudo 1.9.17p1 и новее – уже защищены.

⏳ Оценка риска

➖CVSS 3.1: 9.3 — критический уровень, Local, No privileges, High impact .
➖Эксплоит не требует прав sudoers — достаточно chroot-права.
➖Возможность атаки при локальном доступе — эксплойт «на уровне домашней папки».

🛡 Как предотвратить

✅ Обновитесь до sudo версии ≥1.9.17p1
✅ \*\*Исключите использование -R\*\*можно временно отключить в sudoers, если не нужны chroot-фичи
✅ Мониторинг chroot каталога — если создается файл etc/nsswitch.conf

Stay secure and read SecureTechTalks 📚

#sudo #cve202532463 #root #linux #chroot #privilegeescalation #cybersecurity #incidentresponse #patchnow #SecureTechTalks

🤖 Cybersecurity AI: где кончается автоматизация и начинается настоящая автономия?

🔥 Мы живём в эпоху, когда маркетологи обещают «полностью автономные» киберзащитные ИИ-инструменты, которые якобы способны остановить любую атаку без участия человека. Но так ли это?

🧩 Немного ликбеза

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

В робототехнике это отличие давно считается азбукой, а вот в кибербезопасности его продолжают путать — и это создаёт ложное чувство безопасности.

🚀 6 уровней «умного» киберзащитного ИИ

В ИБ используется удобная шкалу, похожую на SAE для автопилотов:
0️⃣ Level 0 — никаких инструментов, всё руками.
1️⃣ Level 1 — минимальные скрипты, всё решения принимает человек.
2️⃣ Level 2 — помощь LLM для планирования, но весь контроль у оператора (например, PentestGPT).
3️⃣ Level 3 — полуавтоматические цепочки атак с контролем человека для валидации (AutoPT, Vulnbot).
4️⃣ Level 4 — максимальная автоматизация с минимальным вмешательством человека (CAI), но без полного доверия.
5️⃣ Level 5 — гипотетическая полная автономия: ИИ сам планирует, атакует, анализирует, закрывает уязвимости без участия человека. Пока что фантастика.

Большинство инструментов, которые называют «автономными», сегодня на самом деле сидят на уровне 3–4 и требуют человеческой проверки для сложных случаев.

📌 Если перепутать автоматизацию с автономией, можно:
➖ослабить надзор, когда он нужен больше всего
создать «слепую зону» для атак, которые система не умеет обрабатывать
➖переоценить возможности ИИ и стать уязвимыми

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

🧠 Human-In-The-Loop — зачем нужен человек?

Даже самые крутые ИИ-пентестеры, например система XBOW (рекордсмен HackerOne), используют человека для верификации результатов. XBOW позиционируется как «полностью автономный» продукт, но все найденные баги сначала проверяет команда инженеров, чтобы избежать ляпов.

🕵️‍♂️ Риски

⚡️ Фальшивые отчёты могут привести к потере времени и ресурсов
⚡️ Этические вопросы (например, как публиковать найденную уязвимость) требуют человеческого решения
⚡️ ИИ по-прежнему плохо справляется с нестандартными сценариями

🌟 Риски «разогретого хайпа»

Исследователи часто отмечают, что громкие лозунги «ИИ уже лучше любого хакера» слишком сильно упрощают реальность:
✅ за каждым «автономным» успехом стоят месяцы настройки
✅ тесты проходят под наблюдением
✅ итоговый отчёт всегда финализируется людьми
⚠️ Переоценка возможностей может привести к тому, что компании ослабят контроль, доверив всё машине — и тут их может ждать неприятный сюрприз.

🚀 Выводы

🔹 Полностью автономный ИИ в кибербезе — это пока фантастика
🔹 Реальные системы остаются полуавтоматическими, пусть и очень мощными
🔹 Человеческое участие и этическая экспертиза — обязательно
🔹 Точное определение слов («автоматизация» vs «автономия») — основа грамотного управления рисками
🔹 Будущее — это партнёрство человека и ИИ, а не их взаимозаменяемость

Stay secure and read SecureTechTalks 📚

#cybersecurity #ai #pentest #humanintheloop #autonomy #automation #vulnerabilitymanagement #xdr #responsibleai #SecureTechTalks

🧠🔐 Уязвимые языки: слабое звено в безопасности ИИ

Когда вы думаете о взломе языковых моделей (LLM), скорее всего, на ум приходят запросы на английском. Но что, если именно малая языковая группа является оружием?

Новое исследование показало: многоязычие = уязвимость, особенно для языков с низкими (LRL) и средними (MRL) цифровыми ресурсами. И это — не теоретический риск, а уже эксплуатируемая уязвимость современных ИИ.

🌍 Почему языковое разнообразие стало ахиллесовой пятой ИИ?

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

📌 Пример: на английском GPT-4 может остановить вредоносный запрос,
но тот же запрос на языке зулу успешно обходит фильтр в 79% случаев!

🧪 Что протестировали?

🔬 Учёные расширили атаки TextFooler и Round-Trip Translation до 70 языков:
- 29 языков с низкими ресурсами (LRL)
- 33 со средними (MRL)
- 8 с высокими (HRL)
Они проверили, насколько легко можно искусственно изменить текст, чтобы ввести в заблуждение ИИ, при этом сохранив его осмысленность и грамматичность.

🧨 Основные выводы

🔻 Маленькие монолингвальные модели (до 100 МБ) — наименее защищённые
🔺 Крупные многоязычные модели вроде XLM-R или Glot500 — устойчивее к атакам
🤔 Но, даже у Glot500 успех атак на LRL достигает 52%
📉 Простые методы, вроде машинного перевода туда и обратно (MT → Zulu → MT), не дают полной картины — они занижают риски, создавая иллюзию надёжности.

💡 Multilingual TextFooler vs Round-Trip Attack

🧬 TextFooler подбирает синонимы и заменяет ключевые слова → сбивает модель с толку
🌐 Round-Trip Translation изменяет структуру и стилистику через автоматический перевод
📊 На LRL и MRL TextFooler оказался вдвое эффективнее

🛡 Какие выводы?

➖Фильтры LLM, построенные под английский, дают сбои на других языках
➖Малые языки стали инструментом обхода запретов — даже непреднамеренно
➖Обычные подходы к защите (prompt-guard, jailbreaking-filter) не учитывают эту уязвимость

🧭 Как улучшить защиту?

✅ Увеличивать параметрические размеры моделей для малых языков
✅ Использовать модерируемые мульти-языковые датасеты (например, Taxi1500 и SIB200)
✅ Внедрять этические и культурно-чувствительные практики при тестировании LLM
✅ Включать экспертов в лингвистике, цифровых правах и этике в проектирование защиты

📌 Финальные мысли

Большинство LLM до сих пор создаются по принципу "English first", что прямо противоречит основам кибербезопасности: готовиться к худшему сценарию.

Stay secure and read SecureTechTalks 📚

#llm #cybersecurity #nlp #multilingual #textfooler #languageattack #adversarialml #SecureTechTalks #lowresourcelanguages #jailbreak

🎨 KANVAS — вредоносные PDF как искусство атак

🧠 Что, если у вас будет инструмент, который способен создавать и анализировать сложные PDF-файлы, обходящие большинство антифишинговых фильтров и EDR-систем?

Проект KANVAS от WithSecure Labs — это настоящий лабораторный стол для работы с PDF-инфекциями и уязвимостями на низком уровне.

🧬 Что умеет KANVAS?

➖ Генерация кастомных PDF-документов
➖ Встраивание JavaScript-инъекций и обфусцированных конструкций
➖ Манипуляции с XFA-форматами
➖ Создание вредоносных объектов с delayed execution
➖ Имитация известных CVE (с ручной интеграцией)
➖ Формирование нестандартной структуры PDF (xref, headers, streams)

📁 Включённые примеры

📌 XFA‑инъекции — обход стандартных JS-фильтров
📌 Обфусцированные payload’ы — встраиваются глубоко в структуру
📌 Модифицированные шаблоны — можно собрать от “белого” инвойса до “чёрного” тройного payload'а
📌 Fuzzed PDF‑потоки — для тестирования парсинговых движков

🛡 В заключение

⚠️ PDF до сих пор остаётся главным каналом фишинга
⚠️ XFA-структуры почти не анализируются большинством EDR/AV
⚠️ Сложные обфускации ломают даже sandbox-анализаторы
⚠️ KANVAS даёт шанс заглянуть внутрь PDF-хакинга безопасно и контролируемо

📎 Где найти?

🔗 GitHub: github.com/WithSecureLabs/Kanvas

Stay secure and read SecureTechTalks 📚

#pdf #malware #obfuscation #redteam #blueteam #xfa #cve #cybertools #infosec #SecureTechTalks

🧩 Open-source под атакой: взрывной рост вредоносных пакетов в 2025 году

🚨 В первом полугодии 2025 количество вредоносных библиотек в открытых репозиториях выросло на 188% по сравнению с прошлым годом!

Исследование Sonatype выявило 16 279 заражённых пакетов в PyPI и npm — абсолютный антирекорд.
Подробнее — в ITPro.

🛑 Что делают вредоносные пакеты?

55% из них ориентированы на кражу данных: пароли, токены, персональные данные, ключи API, MongoDB-строки, .git-credentials.

Некоторые запускают шифрованный бекдор, чтобы ускользнуть от анализаторов.

Удельный вес криптомайнеров снизился до 5%, но выросло число деструктивных payload’ов, намеренно нарушающих работу приложений (до 3%).

🎭 Атакующие маскируются под настоящих разработчиков

Один из кейсов — модуль crypto-encrypt-ts, замаскированный под популярную библиотеку CryptoJS. Он тайно воровал ключи и кошельки.

Были выявлены атаки от группировки Lazarus: более 100 вредоносных пакетов в npm, свыше 30 000 установок.
Цель — CI/CD‑среда. Упор делается на зависимые сборки и supply chain-интеграции, где пакеты автоматически устанавливаются без ручной валидации.

📦 npm — главный источник угроз

Почти 99% вредоносных библиотек найдены именно в npm.
Это объясняется огромным
количеством проектов на Node.js, особенно в Web3 и DevOps и отсутствием достаточной валидации новых пакетов

К тому же, злоумышленники используют shadow downloads — скачивание библиотек напрямую по URL, минуя менеджеры пакетов, что делает мониторинг почти невозможным. В 2024 таких загрузок было больше 15 миллиардов.

🤖 Атаки ускоряются благодаря ИИ

AI-инструменты используются хакерами для:
➖Генерации названий пакетов, похожих на популярные
➖Написания фейковых README и документации
➖Создания обфусцированных вредоносных скриптов
➖Массовой публикации сотен модулей в час

Так началась новая эра: ИИ против ИИ — атаки создаются автоматически, защиту тоже нужно автоматизировать.

✅ Кто виноват? Что делать?

➖Используйте системы сканирования зависимостей (например, Sonatype, Phylum, Snyk).
➖Настройте контроль CI/CD-процессов — запретите автоматическую установку пакетов без проверки.
➖Минимизируйте зависимости — каждое лишнее подключение — потенциальная точка взлома.
➖Следите за обновлениями: обновляйте уязвимые модули, особенно с критическими CVE.
➖Обучайте разработчиков — они первая линия обороны. Объясните, как выглядят опасные зависимости и фальшивые пакеты.

🔚 В заключение

📌 Open-source не просто «бесплатный код», а основной вектор атак на инфраструктуру разработки.
📌 Supply chain-компрометации - не гипотеза, а реальность, которую используют как APT-группы, так и одиночки.
📌 Время думать не только о CVE, но и о CVE-подобных инцидентах внутри цепочек поставок кода.

Stay secure and read SecureTechTalks 📚

#opensource #malware #supplychain #npm #pypi #devsecops #infosec #lazarus #aicscans #SecureTechTalks

🔐 PostgreSQL + pgcrypto: шифрование данных и его подводные камни

Когда речь заходит о защите конфиденциальных данных, большинство вспоминают про файрволы и VPN. Но мало кто думает о том, что утечка базы данных = утечка всего. PostgreSQL предоставляет мощное, но часто недооценённое средство — расширение pgcrypto, позволяющее шифровать и хешировать данные прямо в SQL-запросах.

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

🌟 Зачем вообще нужно шифровать внутри БД?

🛡 Data-at-rest защита — украли диск или дамп? Без ключа злоумышленник увидит только мусор.
📜 Соответствие стандартам — PCI DSS, HIPAA, GDPR требуют защиты на уровне отдельных полей.
⛔️ Снижение риска при SQL-инъекциях — даже если атакующий получит доступ, он не расшифрует данные без ключа.
🎯 Избирательное шифрование — не нужно защищать всю таблицу, можно только нужные поля.

🔧 pgcrypto: как начать и не облажаться

✅ Установка и изоляция:

CREATE EXTENSION pgcrypto SCHEMA crypto; REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA crypto FROM PUBLIC; GRANT EXECUTE ON FUNCTION crypto.encrypt(bytea, bytea, text) TO secure_user;

✅ Хеширование и HMAC:

SELECT digest('text', 'sha256'); SELECT hmac('data', 'secretkey', 'sha512');

✅ Пароли с солью:

SELECT crypt('пароль', gen_salt('bf')); 

💣 Плохие практики, которых стоит избегать

🚫 Хранить ключи в той же базе данных — если база скомпрометирована, ключ в таблице только усугубит ситуацию.
🚫 Захардкодить ключ в приложении — при утечке кода атака мгновенна.
🚫 Использовать режим шифрования ECB — он сохраняет паттерны и легко поддаётся анализу.
🚫 Раздавать EXECUTE-права на функции шифрования всем подряд — это прямой путь к злоупотреблениям.

🔐 Альтернатива: что такое pgTDE?

pgTDE (Transparent Data Encryption) — это расширение, которое обеспечивает шифрование данных на уровне ядра PostgreSQL. В отличие от pgcrypto, оно работает прозрачно: вам не нужно вручную вызывать encrypt() или decrypt() — все данные в таблице шифруются автоматически. Это полезно, если вы хотите защитить всю таблицу или базу целиком.

Также pgTDE:
➖Поддерживает работу с внешними системами управления ключами (например, HashiCorp Vault).
➖Совместим с индексами, в отличие от pgcrypto, где шифрование ломает возможность поиска.
➖Лучше подходит для защищённой работы в production, особенно при больших объёмах данных.

Проект пока не включён в официальный PostgreSQL, но развивается на GitHub: github.com/bcgit/pg_tde

✅ Выводы

🔒 pgcrypto отлично подходит для точечного шифрования (например, номеров карт, паспортов, токенов).
⚙️ Но требует внимательной настройки: от схемы доступа до правильных алгоритмов и ключевого хранилища.

🧰 Если вы хотите защищать всю БД или крупные таблицы без боли — обратите внимание на pgTDE.

👀 Главное: инструмент — это только половина дела. Всё зависит от того, как именно вы его внедряете.

Stay secure and read SecureTechTalks 📚

#postgresql #pgcrypto #pgTDE #databaseencryption #infosec #dataatrest #compliance #devsecops #SecureTechTalks #cybersecurity

🔓 Post-Quantum Threat Hunter: знакомьтесь с pqcscan

⚠️ Мир на пороге квантового рубежа, и однажды все RSA и ECC‑ключи рухнут. Но кое-что может случиться даже раньше: ваш код уже сейчас может хранить уязвимые пост-квантовые конфигурации.

👾 Чтобы не пропустить этот момент, команда AnvilSecure выпустила pqcscan — 🔍 инструмент для анализа исходного кода и поиска криптографии, уязвимой для квантового взлома.

🧠 Что делает pqcscan?

📂 Сканирует исходный код проекта (на Python, Java, C/C++, Go, JS, Rust и др.)
🔍 Ищет следы до-квантовой криптографии: RSA, DSA, ECDSA, DH, ECIES, AES-128, MD5, SHA1
🧱 Использует регулярные выражения и анализ AST для точной идентификации
🚨 Маркирует устаревшие алгоритмы и участки кода с риском «harvest now, decrypt later»
📦 Работает как CLI-инструмент — лёгкий в CI/CD-интеграции

🔐 Для чего все это?

Квантовые компьютеры (если/когда появятся в боевом виде) смогут:
➖за некоторые часы взломать ключи RSA‑2048 и ECC‑256
расшифровать
➖заархивированные данные, перехваченные заранее
➖полностью обнулить криптозащиту в supply chain'ах
💣 Даже если вы считаете, что у вас "ничего важного нет" — ваши ключи уже могут копироваться и архивироваться для дешифровки в будущем. Это называется "store now, break later".

🧰 Что умеет находить pqcscan?

🛠 Классы и функции из популярных библиотек:
➖Crypto.PublicKey.RSA, OpenSSL::PKey::RSA, java.security.KeyPairGenerator
➖любые вхождения openssl_*, ecdsa_*, dh_generate
➖статические вызовы к SHA1, MD5, AES
➖даже закопанные в файлах конфигурации поля типа "algorithm": "rsa"

📊 Выводит:
имя файла и строку
тип уязвимого алгоритма
критичность (high, medium, low)

⚙️ Как пользоваться?

git clone https://github.com/anvilsecure/pqcscan.git cd pqcscan pip install -r requirements.txt python pqcscan.py /path/to/your/codebase

🚀 Через несколько секунд вы получите отчёт:
- какие алгоритмы найдены
- сколько потенциальных проблем
- на что стоит заменить

🧩 Куда дальше?

📦 AnvilSecure обещают в будущем:
➖добавить YAML-профили для разных отраслей (финтех, госсектор, IoT)
➖поддержку автоматической оценки «заменимости» на NIST PQC
➖CI-плагины и GitHub Actions

🔗 Ссылки

🔤Инструмент доступен на GitHub

📌 Заключение

🧠 Мы все готовимся к post-quantum будущему. Но некоторые — пассивно.
С pqcscan вы получаете активную разведку внутри своего кода.

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

Stay secure and read SecureTechTalks 📚

#pqc #quantumresistance #cryptoanalysis #devsecops #rsa #ecc #nist #SecureTechTalks #infosec #opensource

🔒 Как обмануть 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

🧠💥 LLM + RFC = FlowFSM: ИИ-агенты теперь читают протоколы лучше нас

📡 Протоколы нервная система интернета, но пока одни ищут 0-day в бинарниках, другие решают фундаментальные задачи:  что, если просто автоматизировать разбор RFC и сразу строить конечный автомат?

Представляем FlowFSM — мультиагентный LLM-фреймворк, который сам читает RFC, извлекает команды, выстраивает допустимые состояния и собирает рабочую модель FSM, готовую к анализу и fuzzing-атакам.

🧠 ИИ-помощник, который реально работает

FlowFSM — это не просто один LLM-промпт. Это координируемая система агентов, где каждый отвечает за своё:
один читает структуру документа, другой находит команды, третий — выстраивает логику состояний, четвёртый собирает всё в единую модель.
И да, это уже работает.

📦 Разберёмся, как все устроенно

🧩 Шаг 1: Разбор RFC
RFC делится на логические блоки, вычищается от форматирования и готовится к чтению.

📜 Шаг 2: Извлечение команд и состояний
LLM выделяет ключевые команды (например, USER, PASS) и сопоставляет им состояния и зависимости:
что можно вызывать, что запрещено, в каком порядке.

🧠 Шаг 3: Сборка rulebook
Каждая команда получает профиль:
– в каком состоянии она допустима
– что делает
– какие переходы открывает
На выходе — структурированная FSM, пригодная для анализа, генерации тестов и автоматизированного поиска уязвимостей.

⚡ Насколько хорош результат?

FlowFSM протестировали на двух протоколах — FTP и RTSP. Результаты:

Для FTP: модель извлекла 90 правильных переходов, пропустила 12, и добавила 18 ложных

Для RTSP: 18 правильных, 3 пропущенных, 4 ошибочных

Это дало F1-метрику:
~85% для FTP
~84% для RTSP

💡 При этом:
➖FlowFSM работает автономно без ручной разметки
➖Обходит zero-shot GPT-4 и rule-based подходы по точности
➖Ошибается предсказуемо и понятно, легко отлаживается

🛠 Что под капотом?

1⃣ Используется CrewAI — open-source фреймворк для координации LLM-агентов
2⃣ Модель: LLaMA-3 70B, но можно подключить GPT, Claude, Mistral и др.
3⃣ Агентная архитектура легко адаптируется под новые протоколы
4⃣ Поддерживает подключение векторных БД и retrieval-механизмов

🔍 В чем новизна?

🚫 Больше не нужно вручную копаться в RFC на 120 страниц
⚙️ FSM можно сразу использовать в fuzzing и символьном анализе
📊 Можно масштабировать: от FTP до TLS и 5G
🔄 Обновления RFC? — просто перегоняешь через FlowFSM

🧭 Куда всё движется?

Разработчики планируют:
➖Поддержку новых сетевых протоколов
➖Интеграцию с фреймворками fuzzing/coverage-guided testing
➖Улучшение explainability для автоматической валидации FSM

🔗 Код: github.com/YoussefMaklad/FlowFSM

Stay secure and read SecureTechTalks 📚

#FlowFSM #FSM #ProtocolSecurity #LLM #Cybersecurity #CrewAI #PromptChaining #RFC #Fuzzing #LLMengineering
#AIinSecurity #ReverseEngineering #Automation #NLP #InfoSecTools #LLMagents #AIprotocols #SecurityAutomation #AIresearch #SecureTechTalks

🧠💥 Машинное «забывание» — как ИИ учится... не помнить?

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

Если пользователь требует удалить свои данные — что делать с моделью, которая уже "впитала" их в свои веса? Простое удаление из базы — не спасает. Модель может всё ещё «помнить» чувствительные шаблоны, и это серьёзная угроза для конфиденциальности.

🚨 Проблема: забыть — сложнее, чем обучить

Большинство ML-систем не спроектированы для стирания информации.
Полное переобучение модели без удалённых данных — возможно, но крайне ресурсоёмко и неудобно. А если у вас десятки моделей и непрерывные потоки данных?

💡 Решение: двухэтапный подход с приватностью по умолчанию

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

📦 Первичная фаза — модель обучается на обезличенных данных, с учётом приватности (например, через дифференциальную приватность).

🧠 Финетюнинг — проводится на полном датасете для максимальной точности.

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

Это позволяет:
➖Удалять следы конкретных пользователей
➖Сохранять точность
➖Уменьшить уязвимость к атакам по извлечению данных

📊 А это вообще работает?

Проверки показали:
➖Высокая точность сохраняется
➖Риск извлечения удалённых данных резко снижается
➖Метод оказался эффективнее SISA и других подходов, особенно на табличных и изображённых данных

⚠️ Что важно учитывать?

🔹 Метод работает лучше при статичном обучении, а не в режиме стриминга
🔹 Требуется аккуратная работа с анонимизацией, чтобы избежать искажений
🔹 Необходима прозрачная архитектура, которая позволяет проверить факт «забвения»

🔮 Куда всё это ведёт?

🔐 В будущем модели должны будут:
- Поддерживать запросы на удаление данных пользователей
- Документировать и гарантировать соблюдение приватности
- Уметь доказывать: «да, я больше не помню»

📌 Вывод

Машинное «забывание» не тренд, а фундаментальная часть ответственного ИИ.
Без этой способности — никакой комплаенс невозможен.
С ней появляется шанс сделать ИИ по-настоящему этичным и безопасным.

Stay secure and read SecureTechTalks 📚

#MachineUnlearning #PrivacyAI #DataProtection #AICompliance #ForgetMeNot #SecureAI #Cybersecurity #GDPR #AIethics #RightToBeForgotten
#ModelSecurity #DataGovernance #Infosec #AIprivacy #ResponsibleAI #PrivacyByDesign #MLCompliance #ModelUnlearning #LLMSecurity #SecureTechTalks

🐆 Calico: как защищать сеть Kubernetes 🔒

В современном мире DevSecOps и облачной инфраструктуры Kubernetes стал стандартом. Но с ростом микросервисов приходит и новая угроза — сетевые атаки внутри кластера.

🧠 Calico — это open-source решение для сетевой безопасности, маршрутизации и политики доступа в Kubernetes, OpenShift и других средах.
Но это не просто "сетевой плагин". Это целая экосистема безопасности для микросервисов, которая умеет:
🔹 Контролировать кто с кем может общаться
🔹 Обнаруживать и блокировать подозрительную активность
🔹 Визуализировать сетевые взаимодействия внутри кластера
🔹 Работать с нативной Linux маршрутизацией, BPF и IPtables

🔐 Что делает Calico особенным?

🚦 Сетевые политики уровня L3/L4
Можно тонко настроить доступ:
- по namespace
- по pod labels
- по CIDR, порту и протоколу
Например: разрешить доступ к базе только от backend-сервисов, но не от frontend.

📦 Поддержка eBPF
Для высокопроизводительных кластеров Calico использует eBPF — это позволяет обходиться без IPtables, минимизируя latency и увеличивая throughput.

🕸️ Маршрутизация без Overhead
Calico не требует оверхеда, как у некоторых SDN — он использует чистый IP-рейтинг, и легко масштабируется до тысяч узлов.

🔍 Flow Logs и IDS-интеграции
Calico может логировать весь сетевой трафик между pod'ами и даже работать с системами типа Falco, Suricata, SIEM для обнаружения вторжений.

🧪 Где Calico применяется на практике?
✅ Финтех — изоляция платёжных систем от аналитических сервисов
✅ Хелс-тек — контроль доступа к чувствительным API (медицинские записи)
✅ Энтерпрайз-кластеры — многокомандные среды с RBAC + сетевыми ограничениями
✅ Multi-Cloud — работает в AWS, Azure, GCP и bare-metal

🚀 Установка и запуск

Calico можно поставить
как:
🔹 CNI плагин — для управления сетями Kubernetes
🔹 Standalone BGP маршрутизатор — для традиционных сетей
🔹 NetworkPolicy движок — в дополнение к другим решениям
Установка в K8s:
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
👉 Подробности:
➖ официальная документация
➖репозиторий GitHub

🧠 Что ещё умеет Calico?

🌍 Поддержка IPv6
🔀 NAT-перехват и DNAT-правила
📈 Интеграция с Prometheus и Grafana
👮‍♂️ Enforcement политик в режиме zero-trust
☁️ Cloud-agnostic: AWS, GCP, Azure, OpenStack, bare metal

🔮 Будущее с Calico: Zero Trust + eBPF

Комбинация микросегментации, eBPF и observability превращает Calico в must-have инструмент безопасности для DevSecOps.

Stay secure and read SecureTechTalks 📚

#Calico #KubernetesSecurity #DevSecOps #ZeroTrust #CloudSecurity #OpenSourceSecurity #eBPF #NetworkPolicy #Microsegmentation #SecureK8s
#CloudNative #CNISecurity #Cybersecurity #ContainerSecurity #LLMResilience #NetworkObservability #K8sHardening #SecureInfrastructure #ProjectCalico