Расширения браузера — слепая зона вашего SOC

Один скомпрометированный аккаунт разработчика — и доверенный корпоративный плагин превращается в инструмент кражи данных. Именно так произошло с расширением Cyberhaven в конце 2024 года: атакующие через social engineering и OAuth token abuse опубликовали вредоносное обновление, а механизмы проверки Chrome Web Store это спокойно проглотили. И это не единичный случай — по данным «Лаборатории Касперского», с 2020 по 2022 год более 4,3 миллиона пользователей установили вредоносное ПО под видом браузерных расширений.

🔎Почему это так опасно? Браузерное расширение — это JavaScript-код с привилегированным доступом к DOM, cookies, хранилищу и API браузера. Атакующему не нужно обходить EDR или эксплуатировать уязвимость ОС — код уже работает внутри доверенного процесса. Расширение с permissions cookies + <all_urls> читает все cookies любого домена, включая HttpOnly, недоступные через document.cookie. Кража session cookie от SSO-портала = компрометация учётки без пароля и без MFA.

Manifest V3 спасёт? Не совсем. На DEF CON 32 исследователи SquareX продемонстрировали, что даже V3-расширения способны красть cookies, перехватывать видеопотоки и вытаскивать учётные данные. MV3 убрал eval() и удалённые скрипты, но content scripts по-прежнему имеют полный доступ к DOM, а service worker сохраняет доступ к Extension API. Так что фраза «мы на V3, нам не страшно» — опасное заблуждение.

➡️С чего начинается пентест расширения?

1. Извлечение исходного кода — файлы .crx по сути обычный ZIP. Распаковываем и получаем manifest.json плюс JS-файлы.

2. Аудит манифеста — первый и главный шаг. Смотрим permissions, host_permissions, externally_connectable, web_accessible_resources. Расширение с matches: ["*://*/*"] запускается на всех сайтах — это красный флаг.

3. Анализ контекстов выполнения — background script (самый привилегированный), content script (доступ к DOM, но изолированный JS-мир) и popup. Каждый контекст — отдельная поверхность атаки.

🛡Для SOC здесь критичный момент: в большинстве корпоративных SIEM нет корреляционных правил для мониторинга расширений. Атакующие это знают и активно используют. В терминах MITRE ATT&CK вредоносные расширения покрывают сразу несколько тактик: от Persistence через автообновление (T1176) до Credential Access через кражу cookies (T1539) и кейлоггинг (T1056.001).

В полной статье — разбор конкретных уязвимостей с кодом, методология анализа и готовые правила корреляции для detection.

https://codeby.net/threads/pentest-brauzernykh-rasshirenii-metodologiya-analiza-uyazvimosti-i-detection-dlya-soc.94355/

🔁 Пятничный опрос

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

🚩 Новые задания на платформе HackerLab!

🌍 Категория Веб — Northstar Records

Приятного хакинга!

📹Cameradar

Инструмент с открытым исходным кодом для аудита безопасности RTSP-камер видеонаблюдения. Он предназначен для поиска IP-камер в сети, определения доступных RTSP-потоков и проверки их на использование слабых или стандартных учетных данных.

🔗Основные возможности
▶️Обнаруживает открытые RTSP-порты на доступных целях.
▶️Определяет модель устройства, транслирующего RTSP-поток.
▶️Попытка обнаружения потоковых маршрутов (например, /live.sdp).
▶️Попытка обнаружения распространенных логинов и паролей камеры на основе словаря.
▶️Формирование отчета о результатах.
▶️Поддерживает уменьшение количества ложных срабатываний с помощью флага --framecheck.
▶️Имеет два бэкенда для обнаружения RTSP: nmap и masscan.

⬇️Установка
⏺️Пример запуска и установки через docker-контейнер.

docker run --rm -t --net=host ullaakut/cameradar --targets 192.168.100.0/24

⏺️Если Docker недоступен, можно установить бинарную версию через Go.

go install github.com/Ullaakut/cameradar/v6/cmd/cameradar@latest

После установки исполняемый файл инструмента будет доступен в каталоге $GOPATH/bin.

Принцип работы
1️⃣Пользователь указывает цель (IP-адрес, диапазон адресов, подсеть или имя хоста).
2️⃣Cameradar сканирует стандартные RTSP-порты (по умолчанию 554, 5554 и 8554, а также некоторые дополнительные порты в новых версиях).
3️⃣Обнаруживает RTSP-сервисы.
4️⃣Проверяет тип аутентификации.
5️⃣Выполняет словарную проверку маршрутов и учетных данных.

#cameras #tools #recon

🔗 Все наши каналы 🔁Все наши чаты 🪧Для связи с менеджером

❗️По итогам первого полугодия 2026 года количество заражений мобильных устройств в России выросло на 70% год к году. Основной угрозой остается банковский троян Mamont, под ударом — около 1,5 млн. Android-устройств.

⏺️По данным систем мониторинга киберугроз «МегаФона», число выявленных заражений мобильных устройств увеличилось на 70% по сравнению с аналогичным периодом 2025 года. Первый значительный всплеск активности вредоносного ПО был отмечен еще в марте 2025 года, когда количество инцидентов выросло в 6,6 раза по сравнению с предыдущим месяцем.

По оценкам экспертов F6, примерно 1,5% всех Android-устройств в России (около 1,5 млн) скомпрометированы. Совокупный ущерб российских пользователей от действий мошенников в цифровых каналах в 2025–2026 годах превысил 600 млрд рублей.

⏺️Одной из главных угроз остается банковский Android-троян Mamont. Если в прошлом году на него приходилось 10–12% всех выявленных заражений, то в текущем году его доля достигла 15%. Троян после установки получает доступ к обработке СМС-уведомлений, а также платежной и личной информации. Основная слабость Mamont заключается в том, что пользователю нужно самостоятельно его установить себе на телефон, поэтому злоумышленникам приходится придумывать методы обмана — от социальной инженерии до массовых рассылок.
▶️Дмитрий Ермаков, руководитель департамента Fraud Protection компании F6, отмечает, что активные кампании с использованием этого трояна проводятся с 2023 года:

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

⏺️Дополнительным индикатором роста активности стало увеличение числа управляющих серверов (С2 — централизованные системы злоумышленников для удаленного управления вредоносным софтом на скомпрометированных устройствах).

- В первом полугодии 2025 года специалисты выявляли лишь несколько десятков серверов Mamont.
- Осенью их среднемесячное количество превысило 100.
- В марте 2026 года — 200.

По оценке «МегаФона», это свидетельствует о противодействии злоумышленников обнаружению и нацеленности на массовые атаки.

⏺️Антон Башарин, старший управляющий директор AppSec Solutions, связывает рост активности злоумышленников с изменением привычек пользователей:

«В условиях недоступности ряда иностранных приложений в официальных магазинах установка APK-файлов из сторонних источников стала для многих нормой. Пользователь регулярно ставит APK-файлы из ссылок в мессенджерах и поисковиках. Этим пользуются злоумышленники, создавая поддельный «банк» или «обновление приложения»».

Дополнительным фактором, по его словам, стал интерес к ИИ-сервисам, под видом которых распространяются трояны.

⏺️В отношении угроз для iOS-устройств эксперты F6 отмечают, что они традиционно менее подвержены массовым атакам из-за сложности разработки вредоносного ПО. Однако за последний год как минимум два iOS exploit kit — DarkSword и Coruna — были замечены в арсенале преступных группировок, нацеленных на кражу финансовой информации.

В «Лаборатории Касперского» подтверждают, что инструменты для кибершпионажа, такие как Coruna, могут со временем получать более широкое распространение. При этом говорить о выходе более сложных и дорогих решений (Pegasus или Predator) в массовый сегмент пока оснований нет.

Источник: https://www.kommersant.ru/doc/8779737

#кибербезопасность #Mamont #Android #трояны #мобильныеугрозы #МегаФон #F6 #AppSecSolutions #news

🔗 Все наши каналы 🔁Все наши чаты 🪧Для связи с менеджером

k8scout — инструмент с открытым исходным кодом для моделирования и анализа потенциальных путей атаки в кластерах Kubernetes.

⬇️Скачать инструмент можно со страницы релизов и затем выполнить сборку из исходного кода.

git clone https://github.com/hac01/k8scout
cd k8scout
make build         
make build-linux    
make build-all      

❗️Инструмент полезен на стадии, когда специалист уже скомпрометировал один из подов и хочет посмотреть дальнейшие пути развития. k8scout автоматически определяет, на что способна скомпрометированная служебная учетная запись пода, составляет карту RBAC и отслеживает многоэтапные пути атаки от вашего текущего положения до наиболее ценных целей.

Запускается в двух режимах:
➡️Наступательный режим (режим по умолчанию) — запуск из скомпрометированного пода. Определяет права доступа и все доступные пути эскалации с текущего положения.
➡️Режим проверки (--reviewer-mode) — запуск с помощью служебной учетной записи только для чтения для аудита всей поверхности атаки кластера на предмет всех идентификаторов.

❓Что может обнаружить инструмент
k8scout строит взвешенный граф разрешений и выполняет поиск пути на основе алгоритма Дейкстры, чтобы выявить реалистичные многоэтапные цепочки атак: под для администратора кластера, выход контейнера на узел, боковое перемещение, кража секретов и учетных данных, эскалация облачного IAM, цепочки олицетворения, изменение рабочей нагрузки, внедрение Webhook, злоупотребление оператором GitOps, обнаружение неправильной конфигурации. 

Каждый обнаруженный элемент включает в себя идентификаторы техник MITRE ATT&CK, оценку риска и пошаговый путь атаки с указанием задействованных узлов графа. Всего 50 правил обнаружения.

Режимы использования
1️⃣Из скомпрометированного пода (основной сценарий использования)

# Скопировать бинарный файл в под
kubectl cp k8scout-linux-amd64 <ns>/<pod>:/tmp/k8scout

# Запустить
kubectl exec -it <ns>/<pod> -- chmod +x /tmp/k8scout
kubectl exec -it <ns>/<pod> -- /tmp/k8scout --out /tmp/result.json

# Извлечь результаты
kubectl cp <ns>/<pod>:/tmp/result.json ./result.json

Двоичный файл автоматически определяет, что он запущен в кластере, идентифицирует модуль и сервис-аккаунт и начинает поиск пути от вашей точки входа.

2️⃣С локального компьютера

# Использует ~/.kube/config или $KUBECONFIG
k8scout --all-namespaces --out result.json

# Цель на одно пространство имен
k8scout --namespace production --out result.json

3️⃣Режим проверки (полный аудит кластера)

# Разверните RBAC и задание, доступные только для чтения
kubectl apply -f deploy/rbac.yaml
kubectl apply -f deploy/job.yaml

# Или доступен запуск напрямую с разрешениями 
k8scout --reviewer-mode --all-namespaces --out result.json

#k8s #tools #graphs

🔗 Все наши каналы 🔁Все наши чаты 🪧Для связи с менеджером

🎇Главная идея DevSecOps: безопасность перестаёт тормозить разработку.

Вместо проверок «после релиза» всё встроено в пайплайн: код проходит SAST, контейнеры сканируются, инфраструктура проверяется на комплайенс. В итоге релизы выходят быстрее и при этом безопаснее.

Этому и учит курс DevSecOps от Академии Codeby на практике:

⏺️9 модулей, 48 занятий, 90% практики
⏺️Стек: Docker, Kubernetes, Terraform, Vault, Ansible, Prometheus
⏺️Финальный экзамен в стиле OSCP — только реальные задачи
⏺️Авторы — практики: внедрение Zero Trust, построение SOC, разработка DevSec-инструментов под Burp Suite

Инженеры, которые умеют встраивать безопасность в CI/CD, сегодня в дефиците на стыке ИБ и DevOps — компании поняли, что «сначала сделать, потом чинить» обходится дороже.

👉 Запись на текущий поток открыта до 16 июля

➡️️Программа и регистрация

Бесплатная консультация — @CodebyAcademyBot

Злоумышленники изучают уязвимость Docker в Gitea спустя 13 дней после её обнаружения

Речь идёт об уязвимости CVE-2026-20896 (оценка CVSS: 9.8), которая возникает из-за того, что платформа DevOps доверяет заголовку "X-WEBAUTH-USER" от любого исходного IP-адреса, что фактически позволяет неаутентифицированному интернет-клиенту получить расширенный доступ.

В заявлении, отправленном The Hacker News по электронной почте, исследователь безопасности Али Мустафа, которому приписывают обнаружение и сообщение об уязвимости, сообщил, что образы Docker Gitea поставлялись с шаблоном "app.ini", в котором по умолчанию жёстко задано значение "REVERSE_PROXY_TRUSTED_PROXIES = *". Файл "app.ini" является основным конфигурационным файлом для управления параметрами сервера, подключениями к базам данных, поведением безопасности и настройками приложения.

При включенном обратном прокси-сервере этот подстановочный знак доверяет каждому IP-адресу источника, поэтому любой, кто может получить доступ к порту, может отправить заголовок X-WEBAUTH-USER и пройти аутентификацию как любой пользователь, без пароля и токена, — объяснил Мустафа. При включенной автоматической регистрации имя пользователя admin дает право доступа admin.

Стоит отметить, что документированное безопасное значение для внутренней переменной "REVERSE_PROXY_TRUSTED_PROXIES" - "127.0.0.0/8,::1/128", что означает, что в качестве доверенного прокси-сервера разрешен только localhost, то есть интерфейс обратной связи. Однако в официальном образе Docker это значение по умолчанию не используется, вместо него жестко задан символ "*". Другими словами, проверка в списке разрешенных серверов фактически отсутствует.

Уязвимость затрагивает версии образов Docker Gitea до 1.26.2 включительно. Она была устранена в версии 1.26.3, выпущенной в конце прошлого месяца, где был удален символ подстановки "*", а аутентификация через обратный прокси-сервер стала необязательной.

Источник: https://thehackernews.com/2026/07/threat-actors-probe-gitea-docker-flaw.html

#news #docker #vuln #gitea #proxy

🔗 Все наши каналы 🔁Все наши чаты 🪧Для связи с менеджером

Почему helpdesk — самая недооценённая точка входа для атакующих

Два крупных инцидента за полгода — Crunchyroll и Discord — и один вектор: Zendesk. Не zero-day, не RCE, не эксплойт в коде. Обычная компрометация агентского аккаунта через аутсорсера. И вот что пугает: оба раза это сработало.

🔑Схема до неприличия проста. Атакующие ломают не саму платформу, а сотрудника BPO-провайдера — аутсорсинговой компании, которая обслуживает поддержку. Фишинговая страница под Okta, перехват OTP, регистрация своего устройства — и злоумышленник сидит в Zendesk с полными правами агента. В случае Discord доступ удерживался около 58 часов. За это время атакующие заявили о выгрузке 1.6 ТБ данных: 8.4 миллиона тикетов, сканы паспортов, платёжная информация. Discord признала инцидент, но оспорила масштаб.

А теперь главное — почему это вообще возможно.

➡️Zendesk — не «просто тикет-система». Это хранилище PII с прямым доступом к именам, email, телефонам, платёжным данным, IP-адресам. Плюс интеграции с Okta, Slack, внутренними API. По данным Rescana, через Zendesk можно было делать миллионы API-запросов к внутренней базе Discord — платформа поддержки работала как прокси к данным, которые сама компания никогда не экспонировала наружу.

И вот ключевое слепое пятно: Zendesk API позволяет авторизованному агенту запрашивать эндпоинты /api/v2/tickets, /api/v2/search, /api/v2/ticket_audits без архитектурного ограничения на объём выгрузки. Rate limits рассчитаны на защиту от перегрузки, а не от авторизованной эксфильтрации. Разница между «агент смотрит один тикет» и «агент выгружает миллионы записей» по умолчанию не контролируется.

🎇Что проверить прямо сейчас, если у вас есть Zendesk:

• У BPO-агентов FIDO2/WebAuthn или только OTP? Стандартный OTP перехватывается фишинг-китом за секунды
• Настроен ли мониторинг аномального объёма API-запросов от одного агента в SIEM?
• Есть ли алерт на bulk-экспорт через Incremental Exports API?
• Проверены ли SPF/DKIM/DMARC на домене, привязанном к Zendesk? Без них атакующий может получить доступ к тикетам через spoofed email

Финансовые ставки высоки: группа SLH предположительно запросила у Discord $5 млн выкупа. Для компании, чья поддержка хранит сканы паспортов, это инцидент категории «критический» под GDPR, CCPA и 152-ФЗ одновременно.

В полной статье — детальный kill chain по MITRE ATT&CK, готовые detection-правила для SIEM и чеклист, который можно передать команде SOC сегодня.

https://codeby.net/threads/utechka-dannykh-cherez-zendesk-kill-chain-detection-gap-i-cheklist-dlya-soc.94540/

Чем опасна атака MouseJack?

MouseJack — это класс уязвимостей, обнаруженный в 2016 году и затрагивающий беспроводные клавиатуры и мыши без поддержки Bluetooth. Эти периферийные устройства «подключаются» к компьютеру с помощью радиопередатчика (небольшой USB-адаптер). Поскольку соединение беспроводное, а движения мыши и нажатия клавиш передаются по воздуху, можно взломать компьютер жертвы, передавая специально созданные радиосигналы с помощью специального устройства (например, Flipper Zero или CrazyRadio).

🔗Причина возникновения
Эксплойт MouseJack основан на внедрении незашифрованных нажатий клавиш на целевой компьютер. Движения мыши обычно передаются в незашифрованном виде, а нажатия клавиш часто шифруются (чтобы злоумышленники не могли подслушать, что именно печатается).

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

❗️Последствия
Злоумышленник может получить контроль над целевым компьютером, не находясь физически перед ним (атака доступна на расстоянии 100 метров), и вводить произвольный текст или отправлять команды по сценарию.

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

🔑Обнаружение
Исследовательская группа Bastille Threat Research Team, обнаружившая данную уязвимость в далеком 2016, также выпустила инструмент с открытым исходным кодом, который поможет обнаружить беспроводные мыши и клавиатуры, уязвимые для MouseJack.

Как защититься?
1️⃣Прежде всего необходимо отдавать предпочтение Bluetooth-устройствам, использующим современные версии протокола и актуальные обновления безопасности.
2️⃣ Использовать современные устройства, где обмен между клавиатурой/мышью и приемником аутентифицируется и шифруется.
3️⃣ В случае использования уязвимых моделей, необходимо обновить прошивку.

P.S. Несмотря на то, что уязвимость была обнаружена в 2016 году, на текущий момент все равно находится уязвимые устройства, для которых атака все так же является актуальной, что помогает специалистам по тестированию на проникновение "пробиться" за периметр.

#mouse #Flipper #vulnerabilities

🔗 Все наши каналы 🔁Все наши чаты 🪧Для связи с менеджером

19% сотрудников сдали пароль за 4 часа — после «обучения» по ИБ

Логистическая компания, 1200 человек. Полгода назад провели корпоративный тренинг по безопасности — двухчасовой вебинар, 40 слайдов, галочка в compliance. Мы запустили фишинговую кампанию через GoPhish — письмо от «службы кадров» про новый ДМС-полис. Результат: каждый пятый сотрудник ввёл корпоративный логин и пароль на поддельной странице.

Почему так происходит? Потому что awareness-программы строят HR и compliance-офицеры, а не те, кто реально атакует.

➡️Несколько цифр, которые отрезвляют:

• По Verizon DBIR 2025, 68% утечек связаны с человеческим фактором — ошибки и социальная инженерия
• Генерация фишингового письма через GenAI занимает в 11 раз меньше времени, чем ручное написание, при сопоставимом качестве
• 75% вторжений в 2024 году использовали действительные учётные данные — те самые, что сотрудники вводят на фишинговых страницах

Атакующий генерирует письма быстрее, чем ваш HR успевает согласовать следующий вебинар. Вот в чём проблема.

Что делает пентестер иначе? Он строит процесс от данных, а не от презентации:

1. Baseline без предупреждения. Тихая фишинговая кампания до любого обучения. Замеряем четыре метрики: open rate, click rate, credential harvest rate и report rate. Типичный baseline в компании без программы: 50-60% открытий, 25-35% кликов, 15-25% сданных паролей, и жалкие 2-5% сообщений в SOC.

2. Сегментированное обучение. Тех, кто ввёл пароль, учим интенсивно — показываем конкретно их письмо и что атакующий делает дальше: lateral movement, доступ к файловым шарам, эскалация до доменного админа. Тех, кто кликнул, но не ввёл данные, учим распознавать URL-индикаторы. Тех, кто не кликнул, — знакомим с новыми векторами: вишинг, QR-фишинг.

3. Маппинг на MITRE ATT&CK. Каждая симуляция привязана к конкретной технике — T1566.001, T1566.002, T1656. SOC видит, что детектировать, руководство видит, какие TTP закрыты людьми, а какие — только техникой.

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

Ежегодный вебинар с картинками про «не открывайте подозрительные вложения» формирует не навык, а иллюзию защищённости. Полный pipeline — от первой симуляции до измеримого изменения поведения — разобрали в статье.

https://codeby.net/threads/security-awareness-programma-kak-pentester-vystraivayet-kul-turu-kiberbezopasnosti-v-kompanii.94631/

💫Одна история о том, как идеальная защита перестала быть идеальной.

Стены стоят. Стража на месте. Но что-то пошло не так.

Как называется эта атака? Пишите свои догадки в комментариях!💫

🔗 Все наши каналы 🔁Все наши чаты 🪧Для связи с менеджером

Пентест за доллар: почему AI-агенты ломают экономику наступательной безопасности

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

🔎С марта 2023 года (выход GPT-4) появились десятки open-source инструментов, которые превращают языковые модели в автономных пентестеров. RapidPen заявляет получение shell за минуты при стоимости меньше доллара. Excalibur — полноценный Active Directory engagement с lateral movement за десятки долларов. Ручной тест аналогичного масштаба обходится в тысячи и десятки тысяч.

Ключевой сдвиг — переход от последовательной работы к параллельной. Живой пентестер работает серийно: сканирует, ждёт, интерпретирует, выбирает следующий шаг. AI-агент запускает разведку по всем поддоменам, портам и сервисам одновременно. Не теряет контекст, не отвлекается, не жертвует одной целью ради другой.

↗️Один из самых интересных примеров архитектуры — фреймворк T3MP3ST. Его главная идея: не строить собственную модель, а оркестрировать уже существующие AI-агенты (Claude Code, Codex) для задач red-teaming. Внутри — три специализированных роли:

• Reconnaissance-агент — перечисляет поверхность атаки: поддомены, порты, стек технологий
• Exploitation-агент — формирует гипотезы и тестирует их
• Verification-агент — подтверждает находки и генерирует воспроизводимый PoC

Каждый работает в отдельном инстансе. Это не один чат с LLM — это параллельная работа нескольких агентов с разделением ответственности. По MITRE ATT&CK один такой агент покрывает сразу пять тактик — от Reconnaissance до Execution.

↗️Но вот где начинается реальность. Оркестрационный код T3MP3ST бесплатен (лицензия AGPL-3.0), однако настоящие расходы прячутся в токенах. При параллельном запуске нескольких агентов бюджет API-вызовов растёт нелинейно. Трёхагентная конфигурация за час сканирования средней цели может съесть $20–40 — и это без агрессивного fan-out. Заявленный «пентест за доллар» быстро превращается в десятки долларов на практике.

🎯И главная проблема — верификация. Ни один из перечисленных фреймворков не прошёл независимую проверку результатов. Авторы публикуют впечатляющие бенчмарки, но воспроизвести их в чужих условиях — отдельный квест. Модели галлюцинируют, путают false positive с реальными уязвимостями, а без человека-верификатора отчёт AI-агента — не более чем набор гипотез.

Тем не менее объём наступательных операций теперь ограничен не трудозатратами, а инфраструктурными расходами. И для защитников это уже не теория.

Полный разбор архитектур, сравнение фреймворков и реальные подводные камни — в статье на форуме.

https://codeby.net/threads/ai-agenty-dlya-poiska-uyazvimostei-kak-rabotayet-t3mp3st-i-drugiye-nastupatel-nyye-ai-freimvorki.94629/

🪧 Пятничный опрос

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