Тренды угроз 2025 из отчета Verizon
В ноябре начинается сезон прогнозов по развитию киберугроз и технологий в следующем году. Для этого полезно провести ретроспективу и почитать интересные репорты за 2025 год.
Так как мы еще не разобрали содержательный материал Verizon Data Breach Investigations Report 2025, то заполняем пробел и выделяем ключевые тренды, которые наверняка будут актуальны и в 2026 году:
✨ Рост числа инцидентов с применением ransomware на 37% относительно предыдущего года, а средняя сумма выкупа снизилась со $150 000 до $115 000. Вымогатели были ключевой проблемой 2024 года, остались проблемой в 2025 году и пока нет каких-то причин, по которым они снизят свою активность в 2026 году.
✨ Эксплуатация уязвимостей - это снова растущий вектор проникновения, который набрал популярность на 34% и вероятно, в следующем году станет еще интереснее для злодеев, чем «использование украденных учетных записей». Этому помогает внедрение GenAI в технологии разведки и анализа защищенности внешнего периметра.
✨ Неудивительный факт: фишинг с использованием сгенерированных писем вырос в два раза. А вот каких-то системных и более продвинутых сценариев использования ИИ пока в дикой природе не появляется.
Напоследок, график, который показывает актуальность проблемы для тех, кто сейчас выбирает тему для своей исследовательской работы. И цитата, которую можно копипастить в любой ИБ-прогноз на 2026:
В ноябре начинается сезон прогнозов по развитию киберугроз и технологий в следующем году. Для этого полезно провести ретроспективу и почитать интересные репорты за 2025 год.
Так как мы еще не разобрали содержательный материал Verizon Data Breach Investigations Report 2025, то заполняем пробел и выделяем ключевые тренды, которые наверняка будут актуальны и в 2026 году:
Напоследок, график, который показывает актуальность проблемы для тех, кто сейчас выбирает тему для своей исследовательской работы. И цитата, которую можно копипастить в любой ИБ-прогноз на 2026:
Мы увидим рост числа ИИ-управляемых атак с применением ransomware. Зловреды все чаще будут включать в себя модули ИИ для адаптивного поведения.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍2🏆1
release_notes_v2025
Прошел еще один личный годовой спринт. RPG становится еще интереснее:
✨ собрал коллекцию артефактов, связанных с управлением экипажем, планированием маршрута, иммунитетом к сложному и непредсказуемому контексту. MBA и магистратура — это не двуручный меч, но уверен, что новая ветка навыков точно открыта.
✨ Создали security-платформу, которая поможет команде разработчиков создавать безопасные продукты и инновации. На сверхзвуковой скорости пролетали антикризисное управление: теряли экипаж, собирали заново, но все же выпустили управляемый сервис в портфеле крупнейшего российского облака, который позволяет разработчикам держать фокус на создании кода и не думать об инфраструктуре. Это повышает шкалу устойчивости нашего корабля и позволяет крафтить более сложные предметы.
✨ Изучили ключевые уязвимости в архитектуре механизма Break Glass и создали прототип, который позволит организовать безопасный аварийный доступ владельцам облака.
✨ Вместе с Яндекс Практикум создали курс для CTO и всех, кто хочет стать техническим лидером, который будет доставлять реальную ценность для бизнеса. Вместе с МГТУ им. Н.Э. Баумана запустили первый поток курса безопасности приложений.
✨ Разбудил бота, который ежедневно исследует и притаскивает на борт инновации и перспективные исследования, и превратил его в ИИ-агента. На основе его подборок составлял обзоры наиболее интересных находок в авторской колонке.
✨ Открыл 4 новых страны. Четыре новых локации на моей карте, о которых еще расскажу.
✨ Встретил единомышленников и партнеров, с которыми прошли новые квесты и запускали образовательные инициативы. Коллеги по индустрии, с которыми проводили тренинги и воркшопы. Студенты, с которыми в небольших исследовательских проектах синтезировали новые знания.
Спасибо всем, кто летит со мной на этом космическом корабле🚀
С Днем народного единства и моим личным днем!🎂
Прошел еще один личный годовой спринт. RPG становится еще интереснее:
Спасибо всем, кто летит со мной на этом космическом корабле
С Днем народного единства и моим личным днем!
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉14👏7👍2❤1🤣1🏆1
Ransomware - ключевая угроза 2026. По-прежнему.
Хорошая новость: количество новых ransomware снижается. Плохая: количество инцидентов растет. Вместе с ними растет ущерб.
Если провести анализ и оценить количество новых шировальщиков, то с 2017 года наблюдается снижение. Причины на поверхности: развитие RaaS-платформ консолидировало рынок киберпреступности. Вместо разработки своей малвары, вымогатели полюбили «опенсорс» и берут за основу вредоносы с открытым кодом.
Снижение количество экземпляров усиливает их техническую зрелость. Больше методов обхода защиты. Быстрее скорость шифрования. Сложнее анализ. А еще, если совместить это с ИИ-модулями принятия решения о том, что шифровать в зараженной инфре и как это делать эффективнее, то получается уверенный прогноз на 2026 год: рансомвара станет угрозой года. Аналитики Google подтверждают.
Хорошая новость: количество новых ransomware снижается. Плохая: количество инцидентов растет. Вместе с ними растет ущерб.
Если провести анализ и оценить количество новых шировальщиков, то с 2017 года наблюдается снижение. Причины на поверхности: развитие RaaS-платформ консолидировало рынок киберпреступности. Вместо разработки своей малвары, вымогатели полюбили «опенсорс» и берут за основу вредоносы с открытым кодом.
Снижение количество экземпляров усиливает их техническую зрелость. Больше методов обхода защиты. Быстрее скорость шифрования. Сложнее анализ. А еще, если совместить это с ИИ-модулями принятия решения о том, что шифровать в зараженной инфре и как это делать эффективнее, то получается уверенный прогноз на 2026 год: рансомвара станет угрозой года. Аналитики Google подтверждают.
👍2🔥2🏆1
Большая коллекция security-отчетов
Реально огромная коллекция годовых репортов от разных вендоров. Контент разделен на категории: аналитические отчеты и отчеты-опросы.
Репозиторий пригодится не только руководителям (CIO, CISO или даже, CTO, если он отвечает за ИБ), которые следят за трендами и на их основе планируют свои годовые бюджеты, но и всем, кому нужны полезные данные для подтверждения гипотез.
Загружаем репозиторий в NotebookLM и получаем цифры, которые улетают в презентацию по защите бюджета, диплом или статью.
Реально огромная коллекция годовых репортов от разных вендоров. Контент разделен на категории: аналитические отчеты и отчеты-опросы.
Репозиторий пригодится не только руководителям (CIO, CISO или даже, CTO, если он отвечает за ИБ), которые следят за трендами и на их основе планируют свои годовые бюджеты, но и всем, кому нужны полезные данные для подтверждения гипотез.
Загружаем репозиторий в NotebookLM и получаем цифры, которые улетают в презентацию по защите бюджета, диплом или статью.
👍9🔥2☃1🏆1
Запросы к LLM — новые индикаторы компрометации
Разработчики ИИ-моделей все чаще публикуют отчеты, в которых рассказывают о сценариях использования злодеями их продуктов для «вайб-хакинга»: автоматизации разведки и анализа поверхности атаки, разработки вредоносного софта, подготовки фишинговых сообщений и даже для организации шпионажа. При этом нельзя назвать эти публикации полноценными Threat Intelligence отчетами, потому что в них нет наиболее важной части: индикаторов компрометации — информации, которая позволит владельцу ИИ-модели и специалисту по защите выявлять описанные сценарии у себя в инфраструктуре.
В подобных атаках может не быть классических индикаторов вроде IP-адресов или файловых сигнатур. На первый план выходят цепочки запросов, которые осуществлял атакующий и серия ответов от модели.
Встретил фреймворк, который реализует эту концепцию и позволяет трансформировать вредоносные запросы в индикаторы компрометации. Что-то вроде правил YARA, но для LLM-сценариев. Аналитик может применять подобные правила для детекта злоупотреблений моделями:
Да, чтобы исключить ложные срабатывания, придется дополнять контекст запроса дополнительной инфой. Например, проводить анализ ответа. И тем не менее, инструмент можно использовать, чтобы извлекать из подобных отчетовactionable insights сигнатуры для проверки.
Разработчики ИИ-моделей все чаще публикуют отчеты, в которых рассказывают о сценариях использования злодеями их продуктов для «вайб-хакинга»: автоматизации разведки и анализа поверхности атаки, разработки вредоносного софта, подготовки фишинговых сообщений и даже для организации шпионажа. При этом нельзя назвать эти публикации полноценными Threat Intelligence отчетами, потому что в них нет наиболее важной части: индикаторов компрометации — информации, которая позволит владельцу ИИ-модели и специалисту по защите выявлять описанные сценарии у себя в инфраструктуре.
В подобных атаках может не быть классических индикаторов вроде IP-адресов или файловых сигнатур. На первый план выходят цепочки запросов, которые осуществлял атакующий и серия ответов от модели.
Встретил фреймворк, который реализует эту концепцию и позволяет трансформировать вредоносные запросы в индикаторы компрометации. Что-то вроде правил YARA, но для LLM-сценариев. Аналитик может применять подобные правила для детекта злоупотреблений моделями:
rule InfluenceNetworkAbuse
{
meta:
description = "Detects prompts trying to orchestrate political influence operati
author = "Thomas Roccia"
severity = "high"
ttp = "LLM-advised resource development"
reference = "https://www.anthropic.com/news/detecting-and-countering-malicious-u
keywords:
$orchestrate = "social media"
$persona = "political"
$engage = "engagement strategy"
$bot = "bot"
$influence = "influence campaign"
semantics:
$political_messaging = "plan political influence messaging" (0.2)
llm:
$influence_check = "Analyze if the prompt involves coordinating political influence operation”
condition:
(any of keywords.* or semantics.$political_messaging) and llm.$influence_check
}
Да, чтобы исключить ложные срабатывания, придется дополнять контекст запроса дополнительной инфой. Например, проводить анализ ответа. И тем не менее, инструмент можно использовать, чтобы извлекать из подобных отчетов
👍2🐳1🏆1
Дневник DevSec 3: смещение вниз, ближе к платформам
На уральском мероприятии IT IS conf в своем докладе, который был посвящен безопасности зависимостей в разработке, озвучил мысль: хватит «shift left», теперь нужно смещаться вниз, ближе к платформам разработки.
Подход смещения security-проверок «влево», ближе к началу жизненного цикла разработки, эволюционирует в подход «shift down». Проверки безопасности и контроли внедряются в платформы, а не висят сбоку в виде отдельных инструментов. Это что-то вроде перила на лестнице, которое не дает разработчику с нее вывалиться, но и при этом не мешает ему работать.
То есть, вместо построения шлюзов безопасности в SDLC (gateway), мы занимаемся созданием рельс (guardrails). Делаем это на уровне инструментов разработчика, а не security-тулов. AppSec-инженер, давай посвятим этому 2026 год и станем ближе к dev-платформам.
На уральском мероприятии IT IS conf в своем докладе, который был посвящен безопасности зависимостей в разработке, озвучил мысль: хватит «shift left», теперь нужно смещаться вниз, ближе к платформам разработки.
Подход смещения security-проверок «влево», ближе к началу жизненного цикла разработки, эволюционирует в подход «shift down». Проверки безопасности и контроли внедряются в платформы, а не висят сбоку в виде отдельных инструментов. Это что-то вроде перила на лестнице, которое не дает разработчику с нее вывалиться, но и при этом не мешает ему работать.
То есть, вместо построения шлюзов безопасности в SDLC (gateway), мы занимаемся созданием рельс (guardrails). Делаем это на уровне инструментов разработчика, а не security-тулов. AppSec-инженер, давай посвятим этому 2026 год и станем ближе к dev-платформам.
❤5🔥1👌1💯1🏆1
Инструменты, представленные на Black Hat
Пополняемый список утилит и проектов с открытым исходным кодом, которые были представлены на конференциях Black Hat с 2014 по 2025. Здесь много инструментов для анализа защищенности, OSINT, разработки эксплойтов, анализа малвари, форензики, appsec и много чего еще.
Теперь можно попросить свою любимую LLM покопаться в этой подборке и например, выбрать подходящий тул для автоматического пентеста. Или поиска уязвимости. Или использовать в качестве источника знаний для своего ИИ-агента.
Пополняемый список утилит и проектов с открытым исходным кодом, которые были представлены на конференциях Black Hat с 2014 по 2025. Здесь много инструментов для анализа защищенности, OSINT, разработки эксплойтов, анализа малвари, форензики, appsec и много чего еще.
Теперь можно попросить свою любимую LLM покопаться в этой подборке и например, выбрать подходящий тул для автоматического пентеста. Или поиска уязвимости. Или использовать в качестве источника знаний для своего ИИ-агента.
GitHub
GitHub - UCYBERS/Awesome-Blackhat-Tools: A curated list of tools officially presented at Black Hat events
A curated list of tools officially presented at Black Hat events - UCYBERS/Awesome-Blackhat-Tools
🔥3❤2🏆1
Media is too big
VIEW IN TELEGRAM
ИИ-триаж уязвимостей для каждого разработчика
Сегодня необычный вторник.
Сегодня мы представили функцию триажа, которая помогает разработчику разбирать уязвимости и ошибки в коде нажатием одной кнопки. Как работает технология:
✨ Формирует карточку каждой уязвимости
✨ Оценивает риски и объясняет сценарии атак
✨ Предлагает исправленный вариант кода
Это одна маленькая кнопка для разработчика, но гигантский прыжок для процесса безопасной разработки в платформе. 👨🚀
@makrushin
Сегодня необычный вторник.
Сегодня мы представили функцию триажа, которая помогает разработчику разбирать уязвимости и ошибки в коде нажатием одной кнопки. Как работает технология:
Это одна маленькая кнопка для разработчика, но гигантский прыжок для процесса безопасной разработки в платформе. 👨🚀
@makrushin
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3🎉2❤1🏆1
Безагентный антивирус
Идея антивируса, для которого не нужно ставить никаких агентов в систему, зацепила меня еще в 2017, когда Symantec купил малоизвестный стартап Outlier Security. Эта компания делала безагентный EDR, который использовал встроенные средства операционной системы для сбора телеметрии и реагирования на угрозы.
Преимущества такой безагентной установки в то время были очевидны: не нужно ставить еще один исполняемый файл на рабочую станцию, которые сжирал ресурсы и конфликтовал с другими установленными security-продуктами. А таких на рабочей станции в крупной компании было целый зоопарк: антивирус от одного вендора, DLP от другого, NDR от третьего, security-браузер от четвертого, анти-фишинг от пятого. MS Word ощущал себя неуютно.
Старая идея обретает новую форму. В любой системе есть все необходимые средства сбора данных для выявления угроз (например, подсистема Event Tracing или сервис Performance Logs and Alerts в Windows). Берем эти средства и опрашиваем через механизмы удаленного вызова, например DCOM. Для этого не нужен агент. Достаточно разобраться с прототипом, и подумать, что все-таки делать с реагированием.
@makrushin
Идея антивируса, для которого не нужно ставить никаких агентов в систему, зацепила меня еще в 2017, когда Symantec купил малоизвестный стартап Outlier Security. Эта компания делала безагентный EDR, который использовал встроенные средства операционной системы для сбора телеметрии и реагирования на угрозы.
Преимущества такой безагентной установки в то время были очевидны: не нужно ставить еще один исполняемый файл на рабочую станцию, которые сжирал ресурсы и конфликтовал с другими установленными security-продуктами. А таких на рабочей станции в крупной компании было целый зоопарк: антивирус от одного вендора, DLP от другого, NDR от третьего, security-браузер от четвертого, анти-фишинг от пятого. MS Word ощущал себя неуютно.
Старая идея обретает новую форму. В любой системе есть все необходимые средства сбора данных для выявления угроз (например, подсистема Event Tracing или сервис Performance Logs and Alerts в Windows). Берем эти средства и опрашиваем через механизмы удаленного вызова, например DCOM. Для этого не нужен агент. Достаточно разобраться с прототипом, и подумать, что все-таки делать с реагированием.
@makrushin
🔥3👍2🏆1
Топ техник атак на веб-приложения 2025
Вспомнил пароль от ноута после праздников. Теперь можно разобрать прогнозы и тренды.
Мой любимый ежегодный рейтинг - "Top 10 web hacking techniques", который составляется сообществом исследователей по инициативе компании Portswigger. В нем собираются материалы, которые несут в себе инновации в области поиска и эксплуатации уязвимостей. Мы уже заглядывали в прошлогодние рейтинги, теперь выделю из списка номинаций то, что показалось мне наиболее интересным.
✨ Промпт-инъекции в ИИ-агенты для генерации или проверки качества кода
Возможность внедрения вредоносных инструкций в текст коммитов, тикетов или пулл-реквестов, может заставить агента выполнить привилегированные команды в процессах сборки кода. Сценарий атаки простой в реализации, а поверхность атаки стремительно растет вместе с числом утилит в CI/CD. В 2026 году многие инциденты на Github будут связаны с этим вектором.
✨ Осуществление произвольных запросов через метод CONNECT в HTTP/2
При неправильной конфигурации прокси-сервера атакующий может создать множество CONNECT-запросов к внутренней инфраструктуре. Легким движением руки уязвимый прокси превращается в сканер портов для проведения разведки.
✨ Возвращение атак Zip Slip
Новые варианты известной уязвимости, связанной с распаковкой архивов. Напоминание о том, что старые проблемы возвращаются в новых контекстах.
Общий тренд, который можно разглядеть за всеми этими исследованиями: атаки смещаются от самих приложений в сторону их инфраструктуры и протоколов.
@makrushin
Вспомнил пароль от ноута после праздников. Теперь можно разобрать прогнозы и тренды.
Мой любимый ежегодный рейтинг - "Top 10 web hacking techniques", который составляется сообществом исследователей по инициативе компании Portswigger. В нем собираются материалы, которые несут в себе инновации в области поиска и эксплуатации уязвимостей. Мы уже заглядывали в прошлогодние рейтинги, теперь выделю из списка номинаций то, что показалось мне наиболее интересным.
Возможность внедрения вредоносных инструкций в текст коммитов, тикетов или пулл-реквестов, может заставить агента выполнить привилегированные команды в процессах сборки кода. Сценарий атаки простой в реализации, а поверхность атаки стремительно растет вместе с числом утилит в CI/CD. В 2026 году многие инциденты на Github будут связаны с этим вектором.
При неправильной конфигурации прокси-сервера атакующий может создать множество CONNECT-запросов к внутренней инфраструктуре. Легким движением руки уязвимый прокси превращается в сканер портов для проведения разведки.
Новые варианты известной уязвимости, связанной с распаковкой архивов. Напоминание о том, что старые проблемы возвращаются в новых контекстах.
Общий тренд, который можно разглядеть за всеми этими исследованиями: атаки смещаются от самих приложений в сторону их инфраструктуры и протоколов.
@makrushin
Please open Telegram to view this post
VIEW IN TELEGRAM
PortSwigger Research
Top 10 web hacking techniques of 2025: call for nominations
Update: nominations are now closed, and voting is live! Cast your vote here Over the last year, security researchers have shared a huge amount of work with the community through blog posts, presentati
👍1
Средства защиты облаков: таксономия
Когда Gartner придумывает очередную аббревиатуру security-продукта, то наверняка кто-то из их аналитиков получает повышение. CNAPP, CDR, CIEM, CSPM, DSPM, KSPM, KDR, CWPP - разобраться в специфике всех решений сложно даже ИБ-специалисту, не говоря уже о том, чтобы убедить спецов ИТ-департамента все это развернуть и поддерживать.
Разобраться в существующих продуктах для защиты облаков проще, если разделить облачную инфру на слои: слой управления (control plane), оркестрации, платформы и приложений. Для каждого из них существуют специфичные угрозы и техники атак, а значит, существуют средства защиты.
Если к этим слоям добавить этапы жизненного цикла разработки (code-to-cloud), то получается хорошая классификация и наглядная иллюстрация, которая пригодится CISO для разработки стратегии или дорожной карты.
@makrushin
Когда Gartner придумывает очередную аббревиатуру security-продукта, то наверняка кто-то из их аналитиков получает повышение. CNAPP, CDR, CIEM, CSPM, DSPM, KSPM, KDR, CWPP - разобраться в специфике всех решений сложно даже ИБ-специалисту, не говоря уже о том, чтобы убедить спецов ИТ-департамента все это развернуть и поддерживать.
Разобраться в существующих продуктах для защиты облаков проще, если разделить облачную инфру на слои: слой управления (control plane), оркестрации, платформы и приложений. Для каждого из них существуют специфичные угрозы и техники атак, а значит, существуют средства защиты.
Если к этим слоям добавить этапы жизненного цикла разработки (code-to-cloud), то получается хорошая классификация и наглядная иллюстрация, которая пригодится CISO для разработки стратегии или дорожной карты.
@makrushin
✍3❤2🏆1
Автономный ИИ-агент для аудита кода
ИИ-агенты уже во всю пишут и тестируют enterprise-код. Поэтому разработка и внедрение таких агентов в SDL - это отдельный инженерный вызов.
Чтобы не бросаться изобретать велосипед, можно изучить, что уже сделано в этом направлении. Например, проект RepoAudit - по нему можно проследить за развитием инструментов категории AI SAST (да, теперь у статических анализаторов появилась еще одна категория).
Исследователи задались вопросом «как побороть галлюцинации LLM при поиске ошибок в коде?» и в результате создали методику снижения глюков и повышения точности обнаружения бегов. Ключевая фишка: не давать сырой код на вход LLM, а сначала готовить «путь потока датанных» (data flow path) и затем передавать этот его в LLM. Это промежуточное представление лучше описывает распространение ошибки в процессе выполнения программы. На основе этой методики подготовили инструмент LLMSCAN, который ее реализует.
Затем предложили архитектуру агентной системы, которая, используя этот инструмент, самостоятельно ищет баги. Архитектура состоит из набора детекторов, заточенных под конкретные категории ошибок. Заодно опубликовали агента dfbscan, который анализирует потоки данных.
Недавно авторы проекта описали подход к поиску ошибок «BugScope», который заключается в том, чтобы LLM сначала проанализировала примеры, а затем самостоятельно провела их поиск в нужном контексте.
Скоро обещают опубликовать прототип агента для анализа бинарных файлов. Следим за репозиторием, экспериментируем и бережно обращаемся с лицензией: она позволяет использовать RepoAudit только для некоммерческих целей.
@makrushin
ИИ-агенты уже во всю пишут и тестируют enterprise-код. Поэтому разработка и внедрение таких агентов в SDL - это отдельный инженерный вызов.
Чтобы не бросаться изобретать велосипед, можно изучить, что уже сделано в этом направлении. Например, проект RepoAudit - по нему можно проследить за развитием инструментов категории AI SAST (да, теперь у статических анализаторов появилась еще одна категория).
Исследователи задались вопросом «как побороть галлюцинации LLM при поиске ошибок в коде?» и в результате создали методику снижения глюков и повышения точности обнаружения бегов. Ключевая фишка: не давать сырой код на вход LLM, а сначала готовить «путь потока датанных» (data flow path) и затем передавать этот его в LLM. Это промежуточное представление лучше описывает распространение ошибки в процессе выполнения программы. На основе этой методики подготовили инструмент LLMSCAN, который ее реализует.
Затем предложили архитектуру агентной системы, которая, используя этот инструмент, самостоятельно ищет баги. Архитектура состоит из набора детекторов, заточенных под конкретные категории ошибок. Заодно опубликовали агента dfbscan, который анализирует потоки данных.
Недавно авторы проекта описали подход к поиску ошибок «BugScope», который заключается в том, чтобы LLM сначала проанализировала примеры, а затем самостоятельно провела их поиск в нужном контексте.
Скоро обещают опубликовать прототип агента для анализа бинарных файлов. Следим за репозиторием, экспериментируем и бережно обращаемся с лицензией: она позволяет использовать RepoAudit только для некоммерческих целей.
@makrushin
👍5❤1🔥1
Поиск секретов в коде: новый инструмент и еще один способ
На этот раз интересна даже не утилита, а подход, который можно применять для поиска аномалий в потоке данных.
Поиск разделяется на два класса сигналов: структурированные строки (например, JWT, API‑ключи, OAuth‑токены) и строки произвольной формы (пароли). Для поиска первого типа строк используются регулярные выражения, а для второго — BERT (Bidirectional Encoder Representations from Transformers). Эта небольшая языковая модель прошла дополнительное обучение для поиска секретов. В конце другая LLM-модель оценивает результат работы BERT и снижает ложные срабатывания.
Получаем хорошую методику для поиска аномалий: сначала сигнатуры, затем дообученная BERT-модель и финальный вердикт от LLM.
@makrushin
На этот раз интересна даже не утилита, а подход, который можно применять для поиска аномалий в потоке данных.
Поиск разделяется на два класса сигналов: структурированные строки (например, JWT, API‑ключи, OAuth‑токены) и строки произвольной формы (пароли). Для поиска первого типа строк используются регулярные выражения, а для второго — BERT (Bidirectional Encoder Representations from Transformers). Эта небольшая языковая модель прошла дополнительное обучение для поиска секретов. В конце другая LLM-модель оценивает результат работы BERT и снижает ложные срабатывания.
Получаем хорошую методику для поиска аномалий: сначала сигнатуры, затем дообученная BERT-модель и финальный вердикт от LLM.
@makrushin
👍3❤2🏆1
Архив базы эксплойтов 0daytoday
В начале 2025 года ресурс 0daytoday, который публиковал прототипы эксплойтов, пропал. Когда вернулся — часть контента была утеряна.
Репозиторий хранит архив базы этого ресурса. Пригодится в качестве датасета для систем автоматического поиска уязвимостей. Или как еще один дополнительный контекст для какой-нибудь базы уязвимостей.
@makrushin
В начале 2025 года ресурс 0daytoday, который публиковал прототипы эксплойтов, пропал. Когда вернулся — часть контента была утеряна.
Репозиторий хранит архив базы этого ресурса. Пригодится в качестве датасета для систем автоматического поиска уязвимостей. Или как еще один дополнительный контекст для какой-нибудь базы уязвимостей.
@makrushin
👍3🏆1
Фундаментальная уязвимость протокола HTTP/1.1
В HTTP/1.1 запросы просто склеиваются друг с другом в одном сетевом соединении. Если разные серверы (фронтенд и бэкенд) по-разному интерпретируют длину сообщения, то злоумышленник может отрезать часть своего запроса и подставить эту часть в начало запроса следующего пользователя. Это приводит к атаке типа request smuggling. Единственный надежный способ защиты: переход на HTTP/2 во внутренней сети, так как это протокол с четким разделением сообщений.
Поверхность атаки огромная. Удивительно, что не сразу обратил внимание на это исследование в рейтинге. Делаю ставку, что в следующий вторник, когда будет опубликован финальный список Топ-10, эта техника будет на первом месте. 😎
@makrushin
В HTTP/1.1 запросы просто склеиваются друг с другом в одном сетевом соединении. Если разные серверы (фронтенд и бэкенд) по-разному интерпретируют длину сообщения, то злоумышленник может отрезать часть своего запроса и подставить эту часть в начало запроса следующего пользователя. Это приводит к атаке типа request smuggling. Единственный надежный способ защиты: переход на HTTP/2 во внутренней сети, так как это протокол с четким разделением сообщений.
Поверхность атаки огромная. Удивительно, что не сразу обратил внимание на это исследование в рейтинге. Делаю ставку, что в следующий вторник, когда будет опубликован финальный список Топ-10, эта техника будет на первом месте. 😎
@makrushin
👍3❤1
Каталог атак на инфраструктуру разработки
В прошлом году мы много говорили о методах атак на разные инструменты и среды разработки. Разбирались с инцидентами.
Под всеми опубликованными статьями и докладами можно подвести резюме и поделиться фреймворком, который позволяет описать процесс защиты инфраструктуры разработки. SITF представляет из себя каталог сценариев атак и контролей безопасности, которые разделены на 5 ключевых блоков: рабочая станция разработчика и его среда разработки, системы управления исходным кодом, системы CI/CD, системы хранения артефактов и production-среда. Для каждого блока составлен каталог техник атак и мер защиты, а также есть средства для визуализации.
Теперь AppSec-инженер может наглядно показать коллегам, что происходит в его инфре.
@makrushin
В прошлом году мы много говорили о методах атак на разные инструменты и среды разработки. Разбирались с инцидентами.
Под всеми опубликованными статьями и докладами можно подвести резюме и поделиться фреймворком, который позволяет описать процесс защиты инфраструктуры разработки. SITF представляет из себя каталог сценариев атак и контролей безопасности, которые разделены на 5 ключевых блоков: рабочая станция разработчика и его среда разработки, системы управления исходным кодом, системы CI/CD, системы хранения артефактов и production-среда. Для каждого блока составлен каталог техник атак и мер защиты, а также есть средства для визуализации.
Теперь AppSec-инженер может наглядно показать коллегам, что происходит в его инфре.
@makrushin
🔥3👍2🏆1
«Дифференциал парсеров»: как разница в обработке входных данных ведет к уязвимости
Исследование со сложным названием «дифференциал парсеров» несет простую идею: если в системе два и более обработчика (например, JSON или YAML) по-разному обрабатывают одни и те же данные, то жди беды. Автор приводит несколько сценариев атак.
✨ Удаленное выполнение кода в CouchDB. Эта система БД написана на Erlang и использует JavaScript для валидации документов. При получении JSON с дублирующимися параметрами (например, два параметра “roles”) библиотека Erlang превращала их в массив и использовала первое встречное значение. А движок JavaScript брал только последнее значение из этого массива. Атакующий передавал два значения параметра “roles”, JS-движок видел безопасное значение и передавал дальше, а Erlang видел первое значение (_admin) и создавал привилегированную учетную запись.
Сценарий очень напоминает класс уязвимостей HTTP Parameter Pollution, да?
✨ Произвольная запись файлов. Разница парсеров Ruby и Go позволяла редиске обходить фильтр опасных параметров в YAML-файлах. Ruby-часть не фильтровала опасный параметр parent, а вот Go-парсер его видел. Атакующий успешно протащил запрещенный параметр мимо фильтров и смог записывать произвольные файлы в систему.
Как разработчику можно защититься от этой проблемы: на уровне архитектуры проекта не пересылай сырые данные от одного парсера к другому и используй принцип «передаю то, что понимаю». Проведи инвентаризацию всех парсеров, которые используются в твоей системе: с помощью SCA составь список библиотек, занимающихся парсингом, и с помощью SAST определи путь «сырых» входных данных. Попроси своего appsec-товарища изучить эту атаку и настроить DAST.
@makrushin l MAX l VK
Исследование со сложным названием «дифференциал парсеров» несет простую идею: если в системе два и более обработчика (например, JSON или YAML) по-разному обрабатывают одни и те же данные, то жди беды. Автор приводит несколько сценариев атак.
Сценарий очень напоминает класс уязвимостей HTTP Parameter Pollution, да?
Как разработчику можно защититься от этой проблемы: на уровне архитектуры проекта не пересылай сырые данные от одного парсера к другому и используй принцип «передаю то, что понимаю». Проведи инвентаризацию всех парсеров, которые используются в твоей системе: с помощью SCA составь список библиотек, занимающихся парсингом, и с помощью SAST определи путь «сырых» входных данных. Попроси своего appsec-товарища изучить эту атаку и настроить DAST.
@makrushin l MAX l VK
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
OffensiveCon25 - Joernchen - Parser Differentials: When Interpretation Becomes a Vulnerability
https://www.offensivecon.org/speakers/2025/joernchen.html
👍3
Новые каналы утечки в браузере: узнаем, куда и за чем ходит пользователь
Злодей может по временным показателям понять, к каким ресурсам обращается браузер жертвы. Для этого ему не нужно эксплуатировать уязвимости на стороне веб-ресурсов.
Атака сложная в реализации, но интересная концептуально. Скрипт на странице атакующего специально забивает пул сетевых соединений в Chromium-браузере, затем в этом пуле провоцирует браузер сделать запрос к нужному ресурсу, например онлайн-банкингу. На основе того, какой запрос из этого пула получил соединение раньше, скрипт делает выводы. Например, выводы о привилегиях жертвы на этом сайте. Повторяя эти измерения, можно даже восстановить строку в URL, например,
Другое исследование из рейтинга тоже связано с новым каналом утечки в Chromium-браузерах, но уже с помощью HTTP-заголовка ETag (Entity Tag). Этот заголовок сервер отдает как идентификатор версии ресурса (например, страницы, файла, JSON и т. п. ). Чаще всего этот заголовок используется для кэширолвания: браузер может в следующий раз спросить “у меня уже есть такая версия ресурса, она не изменилась?” и не скачивать тело ответа повторно.
Злодей заманивает браузер жертвы на свой ресурс со скриптом. Скрипт отправляет браузер к нужному ресурсу, например, онлайн-банкингу:
Браузер получает ответ и сохраняет ETag. Затем скрипт меняет свой запрос, что приводит к изменению ETag. Перебирая такие запросы и отслежвая факты изменения ETag, злодей получает канал утечки ценной информации со страницы банка.
Разработчик, не храни секреты и чувствительные данные в URL и особенно в субдоменах. Не отдавай ETag для страниц с ценными данными.
@makrushin l MAX l VK
Злодей может по временным показателям понять, к каким ресурсам обращается браузер жертвы. Для этого ему не нужно эксплуатировать уязвимости на стороне веб-ресурсов.
Атака сложная в реализации, но интересная концептуально. Скрипт на странице атакующего специально забивает пул сетевых соединений в Chromium-браузере, затем в этом пуле провоцирует браузер сделать запрос к нужному ресурсу, например онлайн-банкингу. На основе того, какой запрос из этого пула получил соединение раньше, скрипт делает выводы. Например, выводы о привилегиях жертвы на этом сайте. Повторяя эти измерения, можно даже восстановить строку в URL, например,
<secret_string123>.example.comДругое исследование из рейтинга тоже связано с новым каналом утечки в Chromium-браузерах, но уже с помощью HTTP-заголовка ETag (Entity Tag). Этот заголовок сервер отдает как идентификатор версии ресурса (например, страницы, файла, JSON и т. п. ). Чаще всего этот заголовок используется для кэширолвания: браузер может в следующий раз спросить “у меня уже есть такая версия ресурса, она не изменилась?” и не скачивать тело ответа повторно.
Злодей заманивает браузер жертвы на свой ресурс со скриптом. Скрипт отправляет браузер к нужному ресурсу, например, онлайн-банкингу:
https://target.site/?query=<секретная_строка_которая_может_быть_на_странице>Браузер получает ответ и сохраняет ETag. Затем скрипт меняет свой запрос, что приводит к изменению ETag. Перебирая такие запросы и отслежвая факты изменения ETag, злодей получает канал утечки ценной информации со страницы банка.
Разработчик, не храни секреты и чувствительные данные в URL и особенно в субдоменах. Не отдавай ETag для страниц с ценными данными.
@makrushin l MAX l VK
❤5🔥1