Пупупу x2. Без негатива 💥

💎 Как zero-shot модель помогает мне искать реальные утечки секретов

Всё чаще секреты утекают не из кода, а из внутренних систем типа Confluence, Jira, корпоративных вики и мессенджеров (НЕ МАКСА). Пароли, токены, приватные ключи могут "скрываться" в комментариях, конфигурациях или прошлых версиях страниц. На самом деле, удивительно наблюдать на старые версии страниц, которые не затирают и в которых очень много интересного, но сейчас не об этом. Сегодня пойдет речь не про сам самописный инструмент, т.к. я думаю такое есть уже у всех компаний, а про хайповую тему с ЛЛМ (надеюсь ещё хайповую 👀)

⚙️ Как работает стандартный инструмент

1. Сканирование контента
2. Эвристика/шаблоны/LSP
3. Результат

Но с чем мы сталкиваемся, разбирая выхлоп?

- С проблемами😎

Да, вот и появляется куча FP и структуры, которые нам совершенно не подходят. Вот тут и появляется идея сделать фильтрацию через ИИ. Но упс, а что нам теперь, скармливать все наши данные в нейронку, даже если локальную, то представьте сколько это данных и контекста. Тут нам и приходят на помощь zero-shot модели.

💩 Локальная zero-shot модель

🔵 Используется pipeline("zero-shot-classification") с моделью typeform/mobilebert-uncased-mnli. Я протестировал с 20 различных моделей и остановился на ней.

🤗Ссылка - ТЫК

🔵 Модель решает задачу бинарной классификации: _secret_ vs _non-secret_

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

🔵 Финальное решение
- Кандидат признаётся "секретом", если:
- сработало сильное правило или высокая уверенность эвристики, или/и
- zero-shot модель оценила вероятность ≥ порога.

🥲 Зачем добавлять zero-shot

Регулярки и энтропия дают точные, но ограниченные результаты, они видят только то, что явно похоже на известные токены (GitHub, Slack, AWS и т.п.).

Zero-shot модель добавляет гибкость и контекст. Она умеет распознавать скрытые или "словесно замаскированные" секреты, например, когда пароль указан в тексте без префиксов или когда он указан как тестовый (ага, те самые тестовые пароли, идущие в прод 🧠)

В итоге, снижается число ложных срабатываний, не теряя полноты и без проблем с ложным информированием о тестовых данных.

↗️ О точности и оценке
Рекомендация простая - создать небольшой «золотой» набор размеченных страниц и посчитать precision / recall / F1 до и после включения пост-верификации.

На практике zero-shot модель даёт заметный прирост точности без серьёзной потери полноты при корректной настройке порога (на тестах мне удалось достичь точности определения валидного секрета, с отсеиванием тестовых и фп в 98.4%)

🖌Практические советы, после болезненных тестов и бессоных ночей
🟢 Расширяйте сигнатуры - это улучшает охват.
🟢 Подбирайте пороги:
🔘 ⬆️ повышает точность
🔘 ⬇️ повышает полноту
🟢Для LLM-валидации держите temperature=0 и контролируйте JSON-ответ.
🟢 Сохраняйте результаты и метрики, чтобы отслеживать эффект изменений.

⚠️ Ограничения
🟣 Не работает с изображениями и вложениями.
🟣 Большие дампы требуют препроцессинга.
🟣 Высокоэнтропийные, но безопасные строки всё ещё могут вызывать ложные срабатывания, но с меньшей вероятностью (1.99%-5%)

Zero-shot классификация не заменяет ручной контроль, но превращает поиск утечек в управляемый и воспроизводимый процесс, а не в хаотичный ручной grep по страницам. А как итог, отмечу, что Вы можете достаточно быстро привести ранее затруднительные задачи в ML-powered AppSec и без использования "нанытой видеокарты".

Спасибо за внимание и буду рад, если накидаете моделей на тесты ❤️

🔴 Zero-shot модели для поиска конф данных в логах

Долгое время я думал, что в AppSec и так хватает тем и я не буду залезать на поприща смежных тем, но тут, возникла идея - "А что если в сок добавить чуточку магии?" И именно тут, я начал глубоко изучать тему с классификаторами, секретами и ML в частности. Вот Вы и читаете этот пост.

Чтож, если раньше soc-аналитики вручную проверяли логи или через сиемки (тут могла быть стебная шутка про то, что если выключить сием, то они ничего сделать не смогут, но она не прошла цензор), искали токены, session-id и приватные данные в инцидентах, то сегодня это можно отдать ML-модели.

Не в смысле "заменить человека", а в смысле - сделать анализ логов осмысленным и контекстным.

Как мне кажется, zero-shot модели -естественный следующий этап эволюции взрослеющего SOC, который начинает или уже задумался о подключении логов приложений и тех, кто предоставляет эти услуги. (Я конечно не прошу процент с будущих успешных сделок, но вы всегда можете меня отблагодарить чашкой кофе)

⚙️ Почему именно логи

Логи - это огромный, сырой и несовершенный поток внутренней информации.

В них можно найти:
🔘 токены доступа и refresh-ключи,
🔘 user/session identifiers,
🔘 stack traces с чувствительными payload’ами,

Regex тут бессилен, слишком много форматов, а чувствительность не всегда выражена словами “password” или “secret”, есть также куча нюансов по тому, как попадают логи и в каком формате лежат. Без глубоких познаний в архитектуре приложения, наши бравые L1(алладины🧞), L2 и L3 не смогут быстро и точечно детектировать что что-то не так или быстро искать нужные данные при инцидентах.

Поэтому, вместо бесконечных фильтров, я решил попробовать применить zero-shot классификацию, как это было в предыдущем посте.

💡 Идея

Используем pipeline(zero-shot-classification) и ставим задачу:

"Определи, содержит ли этот лог чувствительные данные."

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

Классы - "contains sensitive data" и "safe".

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

🧃 Что это даёт SOC

🟢 Ловит контекстные утечки, которые regex игнорирует:

2025-10-07 03:12:45,212 [debug] Internal audit event: user=svc_billing_01 executed task "ExportMonthlySummary" 
using temp credentials issued via ephemeral STS session. 
Token issued for role arn:aws:iam::934812734812:role/BillingReportAccess expires in 900 seconds.

Тут у нас:
- Нет самого секрета
- Фраза «temp credentials» не уникальна
- Энтропия нулевая
- Regex-подход без контекста не отличит «audit info» от реальной утечки.

🟢 Ускоряет triage инцидентов - модель подсказывает, какие логи стоит анализировать вручную.
🟢 Снижает шум при корреляции алертов и артефактов.
🟢 Работает без переобучения, просто через inference.

⛏️ Практические нюансики

🟢 Модели, показавшие хорошие результаты:

Прошу простить вашего админа, так как я не имею доступа к реальным большим логам, чтобы всё протестировать более детально

typeform/mobilebert-uncased-mnli - ТЫК
MoritzLaurer/deberta-v3-large-zeroshot-v1 - ТЫК
facebook/bart-large-mnli - ТЫК

🟢 Для скорости — нарезайте логи на чанки и прогоняйте параллельно.

🟢 CPU-инференс чаще всего достаточно, GPU не обязателен.

🟢 Обязательно сохраняйте контекст вокруг найденной строки - иначе ревью превращается в угадайку.

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

🟣 Бинарные данные и hex без контекста не определяются
🟣 Модель может ошибаться на технических фразах ("token bucket", "auth middleware").
🟣 PII внутри сериализованных структур (JSON, Base64) требует дополнительного препроцессинга.

❓ Почему это важно

Zero-shot подход делает SOC-анализ умнее и масштабируемее, что помогает всему отделу безопасности. Из принципа, теперь можно не просто реагировать на сигнатуру, а понимать смысл лога и сразу видеть собранные/подходящие данные. И в этом, будет наша главная победа: от паттерн-matching-а к контекстному security-анализу.

Да, regex по-прежнему нужен, но теперь он не единственный инструмент на вооружении сока.

⚠️ CVE-2025-49844 (RediShell)

В Redis обнаружена критическая уязвимость CVE-2025-49844 (RediShell). Use-after-free в Lua-движке, присутствовавший в кодовой базе с момента встраивания Lua ~13 лет. Эксплуатация позволяет выполнить произвольный код в контексте процесса Redis при наличии права на запуск Lua-скриптов.

❌ Что ломается

🔘 Уязвимость связана с парсером Lua (функции вроде luaY_parser / chunk name handling) и тем, как chunk name управляется на стеке Lua до/после вызова. При обработке специально сконструированного скрипта парсер может вызвать garbage collector в момент, когда ссылка на строку уже считалась ненужной, но код парсера всё ещё держит указатель на эту строку. В результате возникает use-after-free или по нормальному - освобождённая TString используется повторно.

🔘 Опасность UAF состоит в том, что при корректной последовательности действий злоумышленник может управлять освобождённой областью и подменить управляемые структуры/указатели, что приводит к исполнению кода в процессе Redis, по сути - RCE.

✉️ Известные PoC

Тестировать только в изолированной среде

🔵 Лаба с практической средой и PoC-демо - raminfp/redis_exploit (ТЫК)
🔵 dwisiswant0/CVE-2025-49844 (ТЫК) - содержит разбор luaY_parser / chunk name GC-race

🧃 Конкретные индикаторы и артефакты soc

🔵 В логах Redis присутствуют непонятные EVAL/EVALSHA/SCRIPT LOAD вызовы от неизвестных клиентов, последовательности команд, которые загружают/исполняют скрипты
🔵 Необычные процессы/сигнатуры на хосте после взаимодействия с Redis (подмена процессов, новые сокеты, нетипичная сеть)
🔵 Вызовы EVAL с скриптами, содержащими необычные chunk-names или многократные попытки вызвать тяжелые парс-операции (triage: считать инцидентом)

📝 Митигейшены

🔘 Обновить Redis до версии с исправлением (Redis 8.2.2 или позже)
🔘 Если немедленный патч невозможен, то нужно отключить исполнение Lua - ограничить EVAL/EVALSHA через ACL (запретить соответствующие привилегии) или конфигурацию, пока не обновитесь

redis-cli ACL SETUSER service_user off >somepassword ~* -EVAL -EVALSHA -SCRIPT

🔘 Найти все инстансы (public и private), убедиться, что Redis не развернут публично без проксирования
🔘 Ротация учётных данных и ключей, если есть подозрение на компрометацию (особенно если Redis использовался для хранения сессий/токенов)
🔘 Добавить детекции в SIEM по EVAL/SCRIPT LOAD, аномалиям аутентификации и всплескам активности

🌐 Ссылки на источники

RediShell: Critical Remote Code Execution Vulnerability (CVE-2025-49844) in Redis, 10 CVSS score - ТЫК
Security Advisory: CVE-2025-49844 - ТЫК
CVE-2025-49844 Detail - ТЫК