Bug hunters *

Представьте себе «Матрицу» – сервис, где создана иллюзия безопасности путем обмана пользователей. Через юридидические документы, которые должны защищать пользователей, но по факту все наоборот: они защищают создателя сервиса.

В «Матрице» обещают данные на «защищенных серверах», но хранят их в публичном облаке. Пишут «только для совершеннолетних», но почти половина анкет – дети и подростки.

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

12340 анкет, 24 тысячи чужих файлов на 7 GB – все оказалось доступным без единого взлома.

Результат – весьма неожиданный…

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

Всем привет, меня зовут Влад, aka Arkeil. Довольно часто решаю таски на платформе Standoff 365  и совсем недавно мне удалось попасть в топ-25 атакующих по итогам первого сезона на Standoff Hackbase.

Эта статья посвящена разбору хоста Portal на Standalone. Нам было нужно реализовать утечку персональных данных клиентов. Чтобы выполнить задание, необходимо получить информацию о клиенте с ID=2.

Перед началом поиска уязвимостей сканируем хост на открытые порты.

Всем привет!

Меня зовут Игорь Панарин, я же m0nr0e21. Руковожу направлением анализа защищённости инфраструктуры в Дирекции по информационной безопасности РАНХиГС. Мы работаем с распределённой инфраструктурой: офисы, филиалы, ЦОДы — много площадок и зон ответственности. В такой среде важно не просто находить уязвимости, а наводить порядок в процессах, выстраивать понятное управление и делать безопасность системной, а не точечной.

В этой статье я разберу, как проходил взлом банковского сегмента на полигоне Standoff Hackbase, какие векторы атак сработали и какие практические выводы из этого стоит сделать специалистам по безопасности. Мы делаем большую системную работу — и иногда полезно выйти «в поле», чтобы убедиться, что защита действительно готова к бою.

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

По данным исследования Positive Technologies, в  период с июля 2024-го по сентябрь 2025 года на Россию пришлось от 14% до 16% всех успешных кибератак в мире. По итогам 2025 года общее количество успешных кибератак вырастет на 20–45% по сравнению с предыдущим годом, в котором их число достигло практически 500, а в 2026-м может увеличиться еще на 30–35%. 

Админы интернет-ресурсов — публика скрытная, им бы все прятать и прятать. То адмику, спрячут, то пароли доступа.

Но мы же не за паролями пришли? На что они нам? Давайте посмотрим, что спрятано от поисковых систем и от нас, но так, чтобы по-быстрому.

Привет, Хабр! Сегодня хочу поделиться историей о том, как желание автоматизировать рутинную работу привело меня к созданию собственного инструмента FullMute и, как следствие, к первым серьезным выплатам на платформах bug bounty.

Как многие начинающие исследователи, я начал с хаотичного ручного поиска уязвимостей: проверял заголовки, искал известные пути к админкам, пытался угадать версии CMS. Это было неэффективно, медленно и сильно зависело от везения. Мне нужен был «компас», который бы проводил первоначальную разведку за меня и давал четкие цели для атаки. Так родилась идея FullMute.

Сегодня мы продолжим исследование Bindlink API для вмешательства в работу антивирусных решений и EDR. На этот раз воспользуемся драйвером «bindflt.sys», чтобы предотвратить запуск службы антивируса/EDR при инициализации Windows.

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

Всем привет, я Daytrift Newgen, и вот моя простая и весьма смешная история обнаружения байпаса от начала исследований до патча и advisory.

Как пробить многоуровневую защиту LLM-агента, обученную на 80+ млн атаках?

В декабре 2025 я вошел в топ-10 глобального рейтинга Lakera Agent Breaker. В этой статье - не просто обзор решения, а детальный разбор уязвимостей современных LLM-систем и архитектура кастомного фаззинг-пайплайна.

Всем привет!

Меня зовут Алексей Медведев. Первый раз я участвовал в кибербитве Standoff в 2022 году. Далее стал капитаном синей команды (Command and Defend, которая впоследствии сменила название на Ctrl+Alt+Defend) и возглавлял ее на протяжении пяти битв подряд. На Standoff 16 я передал эту ответственную должность и стал своеобразным наставником команды. Расскажу о том, как мы защищали и как нас ломали.

В этот раз, на октябрьском Stаndoff, наша команда защищала город. Эта довольно обширная инфраструктура, включающая в себя несколько сегментов, а также 14 уникальных критических событий (события, реализация которых приводит к нанесению значительного ущерба компании, далее — КС). Перед соревнованиями мы подготовили схему сети, на которой отметили все КС, а также отобразили сетевые взаимодействия между сегментами.

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

Я обнаружил уязвимость в механизме OAuth аутентификации популярного десктоп-приложения, позволяющую похитить учетную запись любого пользователя всего в один клик. Основные причины проблемы: отсутствие проверки состояния (state validation), хранение долгоживущих токенов после перенаправления (loopback redirect) и слепое доверие параметру remote_key. В данном посте я подробно расскажу обо всех этапах атаки, почему она сработала настолько эффективно, и каким образом разработчики могут устранить данную проблему.

Несколько месяцев назад я решил заняться поиском уязвимостей в десктоп-приложениях. Для ясности поясню: говоря о поиске ошибок в десктоп-программах, я имею в виду взаимодействие приложений с веб-сервисами (процесс аутентификации, обмен данными или любые точки интеграции). Целью моего исследования стала известная компания, и я не вправе раскрывать ее название, поэтому на протяжении всей статьи буду использовать redacted.com.

За долгий период существования IT в прод уходила не одна тысяча багов. Большинство из них были безобидными и исчезали после следующего патча. Но отдельные приводили к катастрофам. Буквально. Анализируя тему крупных техногенных провалов, я удивился одному: за большинством этих инцидентов стояли не сложные цепочки событий, а маленькие, пустяковые на первый взгляд детали. Вот тут что-то забыли дописать, тут понадеялись, что пронесет, там решили что «и так сойдет». А итог — многомиллионные убытки, удар по репутации и потерянные жизни.

Рассмотрим на примерах, почему не стоит недооценивать баги.

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

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

Привет, Хабровчане!

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

Для начала немного расскажу о себе. Опыт в ИБ у меня обширный и разнообразный. В данной сфере я уже чуть более 13 лет. Поработал на многих участках кибербеза, начиная от так называемого "папирсека" (специалист, отвечающий за подготовку всех необходимых документов по ИБ) до application security инженера. Работал и в органах государственной власти, и в компаниях с государственным участием и в чистой коммерции. В общем небольшое представление об ИБ имею.

Привет! Меня зовут Лера, я продуктовый дизайнер, последние годы работаю с облачными платформами и сложными интерфейсами. Я пишу как человек, который впервые продавал товар на Авито — и как продуктовый дизайнер, работающий с UX-паттернами и пользовательскими сценариями.

Контекст и справка

В 2025 году по данным ЦБ:

• Q1 2025: 296 600 мошеннических операций, ущерб ~6,9 млрд ₽
• Q2 2025: 273 100 операций, ущерб ~6,3 млрд ₽
• Q3 2025: 460 100 операций — +51% к среднему, ущерб ~8,2 млрд ₽

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

Я впервые размещала объявление на Авито. У меня не было предыдущего опыта продажи, и, как типичный новый пользователь, я не знаю:

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

И именно на этом незнании построена актуальная мошенническая схема.

Отправная точка: я — новый продавец, ко мне пршёл идеальный покупатель.

Через некоторое время после публикации объявления в Авито‑чате пишет «покупатель». Профиль минимально оформлен, но выглядит безобидно.

Не понимаете, что такое SCA?

Устали триажить ложные срабатывания опенсорсных инструментов SCA?

Хотите повысить безопасность ПО и любите бесплатные сервисы?

Привет! Меня зовут Артур, я специалист по пентестам в компании Xilant. В этой статье разберём одну из наиболее опасных уязвимостей, обнаруженных в XWiki — CVE-2024-31982, которая позволяет добиться удалённого выполнения произвольного кода (RCE) через, казалось бы, безобидную функциональность поиска.

XWiki давно занимает ключевое место среди корпоративных Wiki-платформ благодаря гибкой архитектуре и мощной системе шаблонов. Однако именно эта гибкость сыграла против неё: некорректная обработка пользовательского ввода в механизме рендеринга шаблонов привела к появлению критической SSTI-уязвимости.

В материале я покажу, как устроена брешь, как она эксплуатируется и как выглядит автоматизированный PoC, который я написал на основе анализа опубликованного исследования автора jacaba с портала Vicarius.io.

У мошенников нет ничего святого! Хакеры взялись за Google: подделка подписей теперь не обязательна, ведь можно заставить Google подписывать фишинговые письма валидным DKIM самостоятельно. Если раньше опытный ИБ-специалист мог сходу разобраться, где фишинговое письмо, а где — нет, сейчас это сделать в разы сложнее. И дело вовсе не в популярных нейронках, изощренном социальном инжиниринге или слитых базах.

Несем вам горячий кейс о том, как мошенники научились злоупотреблять настройкой OAuth-приложений, используя официальные инструменты Google для отправки поддельных писем от no-reply@accounts.google.com.

Спойлер: хотя Google уже устранил возможность вставлять произвольный текст в название OAuth-приложений, сама техника повторного использования легитимной DKIM-подписи никуда не делась. На её основе по-прежнему можно реализовать сценарии, позволяющие обходить DKIM-аутентификацию.

На одной из предыдущих работ нужно было собрать свои достижения в области кибербеза. У меня были различные найденные уязвимости. Но, я даже не знал: были ли им присвоены CVE? Я этим не занимался. Занимались ли вендоры - не в курсе. Тогда я вспомнил ситуацию с выявлением мной уязвимости в антивирусе Agnitum и взгрустнул: CVE не был зарегистрирован. Год назад я вспомнил эту историю и задумался: а можно ли оформить CVE сейчас, спустя 12 лет после обнаружения уязвимости? Ситуация осложнялась тем, что вендора уже много лет как нет. И его сайта, конечно, тоже. Но, раз вы читаете этот текст - то мне это удалось (за этот кейс я попал в топ-10 Pentest award 2025 - номинация "Раз bypass, два bypass"). Но, путь занял почти год. И вот как это было (спойлер: помог сервис WayBack).