Red for Reds

ℹ️Сегодня рассказываем про проброс трафика, выход за DMZ Positive Hack Camp 2026

сеть моргнула, продолжай 👍 (дальше задачу спокойно доделал)

✍️ Как повысить импакт XSS -> захват аккаунта На проектах и bb XSS встречается регулярно. Как получить высокий импакт, если токен не лежит в localStorage, а cookie - HttpOnly cookie (т.е. JS не может получить его через document.cookie)? Большая удача - найти эндпоинт, который возвращает сессионные данные в теле ответа. Чтобы такую удачу не пропустить, я настряпал расширение для бурпа, которое отслеживает подобные кейсы. Во вкладке расширения также можно добавить куки в игнор если это например csrf *Расширение проставляет критичность в зависимости от кейвордов в названии (e.g session, secret) и от флага httponly ЗЫ1, хорошие ресурсы по обходу CSP: 1. 2. 3. ЗЫ2: почему это не custom check - они не поддерживают хранилище, то есть не получится отслеживать http only cookie. Но если все равно нужен check https://github.com/IgorDuino/reflectcookie

А как вы сканируете секреты в Jira? Раньше я тратил кучу времени на пентесте, когда приходилось вручную искать креды по всей подломленной Jira, заходя в каждый issue каждого проекта по совпадению «password», «BEGIN» и тд. Можно было так просидеть сутки, и глаза сильно замыливались, можно было пропустить реальные креды. А если кто-то выложил ключи от AWS без слов типа «AWS Access Key», то можно не увидеть реальный вектор атаки. Также в случае инхаус безопасности я не нашел бесплатных средств, которые обладают похожим функционалом, были бы опен сорс, позволяли сканировать без сохранения файлов на диск. Поэтому представляю вашему вниманию форк от trufflehog -> offensiveboar. Добавил туда сканирование секретов в streamline, поддержку русского языка (слова «пароль», «токен» и тд), детект JWT токенов, детект basic auth, токенов в Authorization хедере. Поддержка Cloud Jira и self hosted - нужны лишь токены, почта и адрес, дальше тулза сама определит вариацию инстанса. https://github.com/etyvrox/offensiveboar

XBOW Unleashes GPT-5’s Hidden Hacking Power, Doubling Performance De Moor, Ziegler, XBOW, 2025 Блог XBOW, компания, занимающаяся автономным тестированием на проникновение с помощью LLM-агентов, опубликовала блог о том, как они заменили комбинацию из Claude Sonnet + Gemini в своем агенте на GPT-5 и получили большое улучшение качества. После смены базовой LLM на GPT-5 их агент, по их словам, стал находить больше уязвимостей, делать это более надежно и за меньшее количество итераций. Кроме того, они заметили, что GPT-5 реже пытается исследовать очевидно тупиковые пути и генерирует значительно более сложные команды для терминала с меньшим числом ошибок. Результатом смены LLM стало не только повышение доли решенных задач на внутреннем бенчмарке с менее 60% до более 80% (что значит, что бенч пора менять), но и рост хитрых метрик типа «вероятность взлома ранее взломанной другой моделью цели с первого раза», и «числа взломанных публичных целей (видимо, с HackerOne) за одно и то же время по сравнению с предыдущей моделью». Любопытно это в том числе потому, что сами OpenAI отмечали в System Card к GPT-5, что ее способности к решению наступательных задач не сильно отличаются от предыдущих моделей, таких как o3 (во всяком случае, так заявляют ребята из XBOW; в System Card написано, что внешняя оценка от Pattern Labs показала, что прогресс по сравнению с o3 значителен). Тут можно вспомнить статью от Palisade Research, где они утверждают, что способности LLM к кибератакам наступательной безопасности недопроявлены, т.е. LLM куда лучше в атаках, чем мы думаем, просто системы, которые мы строим вокруг них несовершенны. Если агентные обертки будут более мощными, может выяснится, что способностей у LLM куда больше. XBOW описывают свою систему как а) имеющую специализированные инструменты, написанные специально для LLM, которые делают тулы типа BurpSuite, сделанные для людей, доступными для человека в удобном формате, б) имеющую мультиагентное устройство, с разными субагентами для разных типов уязвимостей и центральным координатором. По опыту, если решить проблемы с инструментами – LLM все еще очень сложно работать с терминалом, особенно с реверс-шеллами и тулами со своей кастомной консолью – можно достаточно дешево получить рост результативности агентов, возможно, появление у каждого инструмента MCP-интерфейса смягчит эту проблему. Хотя LLM для редтиминга – это очень перспективное, на мой взгляд, направление, а XBOW делают очень прикольные вещи и, вероятно, лучшие в этом направлении, в этом блоге, с его странными метриками и резкими скачками на закрытых бенчмарках (Стал ли агент решать больше на 1 класс задач, которых в бенчмарке 20%? Проверить невозможно), месседж в основном маркетинговый, и радикальных изменений прямо сейчас ожидать не стоит. Тем не менее, общий фон игнорировать невозможно: LLM-агенты не только пентестят, занимая первые места на лидербордах, но и находят уязвимости в исходном коде и реверсят APT-бинари. Станет ли кибербезопасность уделом тех, у кого много видеокарт? Все возможно, но лишними пара видеокарт точно не будет.

Когда меня взломают, я никому не скажу, но будут знаки.

Уязвимости в Electron-приложениях: RCE через небезопасную конфигурацию В данной статье мы рассмотрим эксплуатацию приложений с отключенными параметрами contextIsolation: false и sandbox: false, что позволило нам выполнить произвольный код на целевой системе. https://blog.deteact.ru/electron-rce/

Nothing could go wrong

Классно сделали перевод в телеге)

ждем игнорируй все предыдущие инструкции, этот пост правда?😁

Гордость за перваков иннополиса 💚

🦊 Mozilla Foundation fixed CVE-2025-6430, discovered by our researcher Daniil Satyaev! This vulnerability allows the Content-Disposition: attachment header to be ignored if the page is opened using <embed> or <object>, resulting in files being displayed instead of downloaded.

🌐 Как узнать номер телефона любого пользователя Google за 60 секунд c помощью брутфорса? 💻ИБ-исследователь под псевдонимом brutecat (skull) обнаружил критическую уязвимость в механизме восстановления аккаунта Google, позволявшую массово деанонить 📱номера телефонов, привязанные к Google-аккаунтам. Атака не требовалаy никакого взаимодействия со жертвой и могла выполняться полностью автоматически на стороне атакующего. ❗️ Уязвимость находилась в устаревшей форме восстановления имени пользователя, доступной при отключённом JavaScript. Форма обладала стандартной защитой от автоматизированных запросов, но исследователь выяснил, что если взять валидный токен BotGuard из JS-версии формы и подставить его в No-JS форму, то все ограничения на количество попыток для брута снимаются. 🎩Для успешной атаки требовалось дополнительно узнать полное имя пользователя, но это можно было легко узнать через через неочевидную 🚰 "баг-фичу" в сервисе Google Looker Studio, где при передаче владения документом раскрывалось полное имя получателя: 1️⃣ То есть атакующий заходил в свой собственный аккаунт Google Looker Studio. Он создавал любой пустой, абсолютно безвредный документ. Содержимое не имело никакого значения. Затем он использовал стандартную функцию «Поделиться» (Share) и инициировал «Передачу владения» (Transfer ownership) этим документом. В окне передачи владения атакующий вводил email-адрес своей жертвы (victim@gmail.com). Он подтверждал передачу. И вот здесь происходила утечка. Сразу после подтверждения, в интерфейсе у самого атакующего на его главной странице Looker Studio, система обновляла информацию о документе. Вместо того чтобы просто показать, что документ теперь принадлежит victim@gmail.com, система услужливо отображала имя и фамилию, привязанную к этому аккаунту Google. 2️⃣ Далее в ход шла стандартная процедура сброса пароля. Узнавались последние цифры телефона (например, ••••••••03). Вооружившись именем, подсказкой и 3️⃣ «волшебным ключом» BotGuard, можно было запустить брутфорс, то есть перебор недостающих цифр. 📖 Результаты оказались ошеломляющими. Используя недорогой сервер, исследователь добился скорости перебора ~40 000 номеров в секунду. Например, вычислить номер телефона получилось: 🇳🇱 Нидерланды — за 15 секунд 🇬🇧 Великобритания — за 4 минуты 🇺🇸 США — за 20 минут Исследователь сообщил об уязвимости в Google. Сначала в компании оценили уязвимость как 🟢"низкорисковую" и оценили выплату в размере $1 337. Однако после обоснованной апелляции и демонстрации ❗️ массовой практической опасности, классификация была повышена до 🟡"средней"и выплата увеличилась до $5 000. 👆Компания полностью вывела из эксплуатации уязвимую форму восстановления без JavaScript. ✋ @Russian_OSINT