Bug hunters *

За долгий период существования 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).

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

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

По сути, атака умело сочетает две техники: принуждение к локальному исполнению (ClickFix/FileFix) и контрабанду кэша (Cache Smuggling). В статье я подробно разберу каждый из этих приемов и покажу, как можно сделать доставку полезной нагрузки еще более незаметной.

В ходе проведения оценки безопасности наша команда обнаружила критическую уязвимость удалённого выполнения кода (RCE), возникшую вследствие неправильно настроенной конечной точки API, за выявление которой была выплачена премия в размере $25,000. Однако данная проблема оказалась не единичным случаем: она была частью масштабной ситуации, связанной с несколькими API, лишёнными надлежащей аутентификации и проверки ввода.

В данном отчёте подробно описаны шаги, приведшие к обнаружению RCE: от начальной разведки и поиска уязвимости, до создания рабочего эксплойта. Мы продемонстрируем, как небезопасные шаблоны проектирования в сочетании с API без аутентификации, могут привести к компрометации всей системы даже без взаимодействия с пользователями.

(Puppy) — машина с площадки HTB для симуляция аудита безопасности Windows Active Directory. Начнем с имеющихся учётных данных сотрудника отдела кадров (HR), который стал жертвой фишинга. Этот пользователь имеет права на изменение состава группы «разработчиков», что позволяет добавить туда собственную учётную запись и получить доступ к сетевым ресурсам (SMB-шарам), где хранится база паролей KeePassXC. После расшифровки секрета с помощью John, пройдем аутентификацию от имени второго пользователя, который состоит в группе старших разработчиков, участники которой имеют  право GenericAll над новым пользователем. Поменяем пароль этого пользователя и подключимся через WinRM. На хосте найдем резервную копию сайта, а в ней пароль от последней УЗ. Подключение через WinRM под новым пользователем даст доступ к DPAPI-хранилищу, что в конечном итоге приведет нас к флагу администра.

Что это такое

Для тех кто не знает - OSCP - это самая первая и известная прикладная сертификация по пентесту от создателей Kali Linux. 

Представляет из себя 24-часовой экзамен, в котором даётся VPN-подключение к тестовой лаборатории и хосты для взлома. Да-да, надо именно получить удалённый доступ через какую-то уязвимость и повысить привилегии до админа или рута, чтобы получить заветный скрытый файл. За каждый такой файл начисляются балы для успешной сдачи.

То есть, это своего рода CTF, но с более реальным целями. Здесь я хочу рассказать не только что это за зверь и с чем его едят, но и как к нему подготовиться.

Подготовка

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

Сей путь я начал с нуля ещё в 2020 году. Купил тогда пак на 90 дней лабы и на экзамен. За эти деньги даётся ещё 500 страничная электронная книга в помощь падаванам.

Скачал заветный openvpn конфиг и сразу ринулся в бой. На начальном этапе сразу определилась моя основная проблема - отсутствие чёткой методики действий. Да, у меня уже был годовой опыт джуна за плечами и я даже находил пару критических уязвимостей до этого. Но то было скорее результатом рандомных действий, так называемого “творческого подхода”: погуглил там, подёргал сям и что-то вышло.   

Тут я наткнулся на канал IppSec на Youtube.

Всех приветствую! Ещё год назад я играл в CTF и работал как SOC-аналитик L1, а сегодня в компании «Газинформсервис» занимаюсь тестированием веб-ресурсов. В свободное время багханчу, и больше слов о моих успехах скажет статистика в профиле амбассадора Standoff. На Standoff Talks я выступил с докладом об эффективном поиске уязвимостей и хочу поделиться этим опытом здесь.

Привет! Я Никита, инженер-инсталлятор в Selectel. Представьте ситуацию: вы нашли уязвимость и понимаете, что ее можно воспроизвести. Цель — помочь владельцу сервиса закрыть дыру быстро и безопасно. Но до контакта важно остановиться и взвешенно проанализировать собственные действия. Чтобы вам было чуть проще сориентироваться «на месте», собрали ключевые советы и рекомендации под катом. 

Когда сервис, созданный для обновлений безопасности, становится самой большой уязвимостью — это уже ирония уровня Microsoft. В середине октября стало известно о критическом RCE-баге в WSUS (Windows Server Update Services), получившем CVE-2025-59287 и оценку 9,8 по CVSS. Достаточно лишь доступа к портам 8530 или 8531, чтобы без авторизации выполнить код на сервере и получить контроль над доменом.

И если вы думаете, что защищены, потому что ваш WSUS «спрятан» во внутренней сети, — не спешите выдыхать. Угроза уже ушла в паблик, эксплоиты на GitHub, а появление малвари под неё — вопрос времени.

С этим секретным трюком хакеры зарабатывают 💸 $XX,000+ — теперь твоя очередь.

Введение

При Internationalized Domain Name (IDN) homograph атаках используются символы разных языков, которые выглядят практически одинаково, например, латинская «a» и кириллическая «а». На первый взгляд результат выглядит как обычный домен или адрес электронной почты, но на самом деле происходит подмена на похожие, но технически разные Unicode символы.

Например:

Электронная почта в Unicode кодировке: аdmin@example.com

В формате Punycode: xn — dmin-7cd@example.com

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

Задание "Watcher" начинается с сервера Zabbix. Воспользуемся уязвимостью CVE-2024-22120 (слепая SQL инъекция), чтобы украсть сессию администратора и получить удалённое выполнение команд (RCE). Затем зайдем как администратор и найдем пользователя, который входит каждый минуту, обновим исходный код PHP файла аутентификации таким образом, чтобы все учетные данные сохранялись в файл. Полученные учетные данные подойдут для локального TeamCity, куда мы сможем зайти как администратор и злоупотребить конвейером сборки для исполнения команд от имени суперпользователя (root).

Кейс новичка о «пробах» в роли бахгхантера на примере MAX + Bug bounty платформы Standoff365 

Статья о личном опыте и выявленных системных проблемах взаимодействия исследователя с вендором и арбитражем в российской bug bounty‑экосистеме: как игнорируются критические уязвимости в «национальном мессенджере» MAX, отчёты закрываются как «дубликаты» без доказательств с подменой понятий, искажением фактов (и даже манипуляциями по искусственному созданию "дубликатов"), а правила меняются постфактум..

Что остаётся делать этичному хакеру, когда внутренние каналы арбитража исчерпаны и нет внешних, и почему в России у белого хакера - нет прав.

Всем привет! Меня зовут Ян, я старший специалист по пентестам в компании Xilant. Сегодня предлагаю вместе разобраться с довольно сложным CTF-заданием, посвящённому слепой LDAP-инъекции (Blind LDAP Injection).

Оно будет особенно интересным, ведь его смогли решить всего около 50 человек из примерно 500. Мне удалось получить флаг одним из первых десяти участников — за 2 часа, причём без глубокого опыта работы с LDAP протоколами.

Решение и код лежат также на моём Github (ни один чат-бот не пострадал).

Как выглядит реалистичная банковская среда для тренировок по кибербезопасности? На полигоне Standoff мы развернули инфраструктуру с платежным хабом и адаптером для подключения к системе быстрых платежей, которые были предоставлены компанией eKassir. Участники отрабатывают реализацию критических событий — от кражи базы платежей до подмены плательщика — с настоящим банковским ПО.

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