Всем привет! Я Полина Спиридонова, product owner двух продуктов для подготовки специалистов по защите информации — Standoff Cyberbones и Standoff Defend.
В статье я расскажу, как мы прошли путь от формулирования идеи из вопроса «Как создать полигон для синих команд?» до запуска Standoff Defend — инструмента, который помогает командам SOC становиться сильнее. Давайте погрузимся в детали и узнаем, как все начиналось и к чему мы пришли.
Когда речь идёт о безопасности, процесс сброса пароля — одно из тех мест, где разработчики не могут позволить себе ошибаться. Одна единственная уязвимость может открыть дверь к критическим багам.
Недавно, тестируя приложение Redacted.com, я обнаружил уязвимость перечисления пользователей. Честно говоря, многие программы помечают подобные проблемы как информационные или не входящие в область тестирования. Но иногда то, что кажется «бесполезным», может скрывать серьёзные последствия.
Это история о том, как я начав с «бесполезного» бага пришёл к обнаружению 0-click ATO (account takeover).
Пентесты помогают выявить и устранить слабые места в защите компании до того, как ими воспользуются злоумышленники. Но чтобы такая проверка действительно принесла пользу, важно понимать, зачем вы ее проводите, по какой методологии, и что будете делать с результатами.
В этой статье мы разберемся:
• чем отличаются методологии «черного», «серого» и «белого ящика»;
• какую из них выбрать под конкретные риски;
• как подготовиться к тестированию, чтобы не тратить деньги впустую;
• и почему даже «зеленый» отчет сам по себе — не повод выдыхать.
Всё самое интересное из мира кибербезопасности /** с моими комментариями.
На этой неделе новости про то, как и зачем хакеры сами исправляют уязвимости во взломанных системах, Hyundai делает уязвимое ПО, чтобы потом зарабатывать на патчах, Microsoft по доброте душевной сливал PoC в Китай, но сейчас передумал и другие только самые важные и интересные новости из мира информационной безопасности.
Традиционные методы фишинга уже не работают, а современные системы, для повышения безопасности, поддерживают многофакторную аутентификацию (MFA). Однако злоумышленники развиваются и используют новые методы, такие как Evil-noVNC — современная атака Browser-in-the-Browser (BitB), которая применяет noVNC для проведения чрезвычайно правдоподобных фишинговых кампаний.
Evil-noVNC позволяет киберпреступникам воспроизводить реальные страницы входа прямо в браузере жертвы, отображая подлинные страницы аутентификации таких сервисов, как Gmail, Microsoft 365 и Okta. Эта передовая атака типа Adversary-in-the-Middle (AiTM) перехватывает не только логины и пароли, но и токены многофакторной аутентификации с активной сессионной кукой, что позволяет полностью скомпрометировать аккаунт даже при включённой MFA.
В этой статье разберемся, как работает Evil-noVNC, почему это растущая угроза в 2025 году и как защититься от этой фишинговой техники.
Содержание
- Обзор
- Требования
- Настройка
- Запуск
- Меры защиты
- Заключение
Однажды мы со Standoff 365 договорились сделать крутой конкурс для начинающих багхантеров и представить его на PHDays Fest. Каково же было наше удивление, когда за первые 5 минут в конкурсе зарегистрировались 17 человек, всего же было 74 участника и 10 победителей. Еще больше удивило то, что багхантеры были вовсе не начинающие: в конкурсе участвовали сильнейшие хакеры страны. В этой статье разберем, какие были задания.
Мы приняли решение сделать конкурс в формате CTF. Для этого с нуля в ChatGPT была разработана платформа. Как показала практика, код, который написала нейросеть, оказался неидеальным в плане безопасности, но в целом после исправления некоторых проблем все стало работать стабильно.
С виду все просто: дали пентестерам доступ в сеть, они пошарились по серверам, нашли пару уязвимостей, написали отчет. Профит. Но на деле плохо подготовленная проверка легко превращается в хаотичный квест с непредсказуемым финалом.
В лучшем случае вы получите бесполезный список из сотни мелких «дыр» в принтерах и кофемашинах. В худшем — пентестеры случайно обрушат производственную линию или устроят DDoS на Active Directory. А между этими крайностями лежит целый спектр проблем: от юридических рисков, если в документе не очертить скоуп и команда выйдет за рамки дозволенного, до банального несовпадения ожиданий и результатов.
Однако всех этих неприятностей легко избежать, если подойти к планированию внутреннего пентеста основательно. В этой статье разберем, почему техническое задание — не формальность, а жизненно важный документ, и покажем, как его правильно составить. Кто-то возразит, что это утопия, и в реальности все работают иначе, но нам бы хотелось это изменить. Поверьте: оно того стоит.
Всё самое интересное из мира кибербезопасности /** с моими комментариями.
На этой неделе много новостей в моей любимой связке - AI + кибербез: Альман дал интервью и рассказал про риски, Googдe продолжает развивать свои кибербез-инструменты, GPT5 - новая звезда в AI-пентесте и другие только самые важные и интересные новости из мира информационной безопасности.
Пошаговое руководство по идентификации и эксплуатации неправильно настроенных AWS бакетов.
Введение
Amazon S3 (Simple Storage Service) является одним из самых популярных решений для облачного хранения, но неправильные настройки могут привести к серьезным проблемам с безопасностью. В этом руководстве мы рассмотрим, как провести аудит S3-сред, обнаружить открытые бакеты, проанализировать разрешения и минимизировать риски безопасности. Используя инструменты AWS и сканеры, вы научитесь выявлять уязвимости, прежде чем они станут угрозами.
Всё самое интересное из мира кибербезопасности /** с моими комментариями.
На этой неделе новости про новый вектор атаки из BIOS, который нельзя обнаружить антивирусами, Минцифры придумали особый формат интернета в условиях ограничений, Электронный документооборот - новый эффективный канал распространения вирусов, за месяц в MAX обнаружили минимум 79 уязвимостей, а в Linux более года скрывался умный вирус и другие только самые важные и интересные новости из мира информационной безопасности.
В мире этичного хакинга, быть невидимым зачастую так же важно, как и получить первичный доступ. Подумайте сами: если вы проникнете в систему, но оставите за собой следы в логах, идентификаторах процессов и временных метках файлов, то практически оставите свою подпись на месте преступления.
Этот гайд посвящен скрытности и bash-скриптингу. Мы говорим не о супер эксплойтах, а о низкоуровневой невидимости, которая заставит команду криминалистов чесать затылки.
В этом отчете я делюсь историей о том, как простая страница входа привела к получению полного административного доступа. Всё началось с базовой разведки и превратилось в одну из самых серьезных уязвимостей, которые я обнаружил. Вот как это произошло.
Каждый баг в проекте проходит определенный жизненный цикл — от момента обнаружения до полного устранения. В новой статье мы подробно рассматриваем ключевые этапы этого процесса, уделяя особое внимание рабочим статусам багов в системе JIRA, таким как «Open», «Blocked», «Closed» и «Rejected».
Автор делится практическими примерами из реального опыта, чтобы показать, как стандартизация процессов помогает улучшить коммуникацию внутри команды, повысить качество продукта и упростить управление ошибками. Узнайте, почему единый подход к работе с багами — это не просто формальность, а важный инструмент для эффективного ведения проекта.
В прошлой статье мы рассказывали о HD Moore — хакере, который подарил миру фреймворк, навсегда изменивший практику пентестов. Теперь на очереди сам Metasploit: в прошлом — настоящий «швейцарский нож» пентестера, ныне — скорее вспомогательный инструмент с отдельными рабочими лезвиями.
Чем был Metasploit для индустрии в нулевые, что представляет из себя сейчас, и почему пентестеры продолжают использовать его даже спустя двадцать лет? Разбираем историю эволюции легендарного фреймворка, которому в этом июле исполняется 22 года.
Привет, я nav1n0x — администратор баз данных по профессии, исследователь безопасности, а также баг-хантер по призванию, с фокусом на уязвимости, которые часто остаются незамеченными. Мне нравится исследовать логику приложений, забытые параметры и превращать свои предположения в критические находки (как эта SQL-инъекция, скрытая в баннере с согласием на использование файлов cookie). Моя цель — делиться практическими техническими статьями, которые помогают исследователям и разработчикам понять, откуда берутся эти уязвимости — и, что более важно, как их предотвратить.
17 июля я сдал анализы крови в компании Гемотест. Спустя полтора дня мне пришёл email с результатами на адрес, который я указал перед сдачей. К счастью, с анализами было всё хорошо: у меня нет ВИЧ, гепатита B, гепатита C, сифилиса, ура! PDF с анализами было заверено приложенной электронной подписью с инструкцией по проверке. Было внутри даже такое:
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: Это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
А потом ещё и то же самое на английском. Ну кайф. Вроде всё хорошо, можно не волноваться. Но одна вещь всё-таки лишила меня покоя.
Привет, Хабр! На связи Сергей Зыбнев aka poxek. Начинал свой путь в багбаунти как сисадмин, потом заведовал WAF'ами в МТС, затем несколько пентестерских компаний, а теперь работаю в Бастионе и профессионально ломаю то, что раньше защищал. Последние четыре года веду Telegram-канал Похек, где рассказываю про найденные уязвимости и про то, как можно было предотвратить их эксплуатацию.
В этой статье — главные инструменты для поиска уязвимостей, которые я использую в ежедневной работе. Это не подборка ради подборки: для каждого инструмента приведу пример из собственной практики, чтобы было понятно, где и как их применять.
Если хотите понять, какие инструменты выбрать и как эффективно применять их в реальных пентестах — добро пожаловать под кат!
Сегодня я расскажу вам об интересной уязвимости, которую я нашёл в одном закрытом баг-баунти проекте: простая HTML-инъекция превратилась в полноценную SSRF с утечкой учетных данных AWS.
Заварите себе кофе, и давайте начнем! 😉
Пошаговый разбор того, как простая уязвимость IDOR раскрыла конфиденциальные личные данные, позволила несанкционированное отправление отзывов и сделала возможной отмену билетов на рейсы, что затронуло пассажиров по всей Индии.
Статьи про багхантинг часто говорят о пользе для резюме, багбаунти, повышении безопасности продуктов, доступе на закрытые мероприятия. Информация о проблемах во взаимодействии с разработчиками в процессе багхантинга упоминается лишь изредка (и часто - вскользь). Но, это тоже важная часть багхантинга: начинающим бахгантерам полезно знать, с какой реакцией разработчиков они могут столкнуться. Всё-таки, это определённая психологическая нагрузка. Я хочу показать на личном примере прекрасную иллюстрацию того, насколько различны в оценке проблемы разработчики и багхантер. Случай уникален тем, что мне удалось задокументировать многие тезисы разработчиков в их первоначальном виде (в т.ч. попытку отозвать CVE). И подсветить важный момент: уже сам факт оформления CVE по проблеме, которую вендор не признаёт, может вызвать раздражение у вендора.
В статье покажу этапы, очень похожие на стадии принятия Кюблер-Росс (отрицание, гнев, торг, депрессия и принятие), которые я наблюдал у разработчиков в процессе нашего с ними общения. Мы пройдём путь от отрицания наличия проблемы, через благодарность за информирование (о проблеме) до негодования в адрес MITRE (и мой адрес, не стесняясь выражений).
Дисклеймер: в статье приведены скриншоты из моих личных переписок с разработчиками. Публикация таких переписок одной из сторон не требует согласия другой (согласно законодательства РФ).
