Доклад о практической безопасности фемтосот — компактных базовых станций 3G/4G, которые оператор ставит в помещении абонента. Для сети это доверенный узел с собственными сертификатами и доступом к интерфейсам ядра. Для исследователя —обычное встраиваемое Linux-устройство, которое разбирается на столе.

На материале семи устройств шести вендоров (ip.access, NEC, Sercomm, Sagemcom, Alcatel, Baicells и операторские ребренды) показан полный цикл:

  - поиск точек входа — UART, U-Boot, JTAG;

  - извлечение памяти, когда консоль закрыта — SPI NOR/NAND, raw NAND, eMMC, eMCP;

  - разбор дампов, сборка образов, получение root;

  - что хранится внутри — ключи и сертификаты IKEv2/IPsec, адреса SeGW и HNB-GW, конфигурация TR-069;

  - подъём собственного ядра сети на Osmocom 

В докладе рассматривается практическое исследование уязвимостей в цифровых рекламных сервисах крупнейших мобильных операторов. Автор демонстрирует, как с помощью техники AdINT (Advertising Intelligence) рекламные идентификаторы позволяют деанонимизировать пользователей, получать их геолокацию, историю звонков и интересы через публичные API.

Слушатели узнают, как коммерческие механизмы таргетинга превращаются в инструмент глобальной слежки, позволяющий таргетировать конкретного абонента всего по одному звонку или переходу по ссылке. Исследование получило международное признание, включая благодарности на SANS Summit в США, и привело к закрытию критических брешей в безопасности телеком-гигантов.

В интерактивном режиме подготовим Trusting Trust закладку в компиляторе (на примере JDK), оценим сложность и проанализируем потенциальные векторы атаки злоумышленника. Проверим современные средства защиты (в.т.ч. ИИ) и сравним подходы к сканированию. Посмотрим, можно ли использовать LLM для ускорения/упрощения подготовки атаки.

У меня возник позыв перекладывать пакетики на сотнях тысяч RPS. На Python такое не напишешь, а C++ я последний раз трогал в 2007-м. Что-то быстрое, модное и безопасное на горячем пути? Ответ очевиден, это Rust.

Я начал вайбкодить с агентами и поймал первый Panic в собственном коде примерно там же, где закончилась вера в «memory safety by default». Перечитал OWASP Agentic SAMM и вспомнил золотое правило: доверять нельзя никому — ни агентам, ни людям, ни Rust.

Rust не удаляет баги — он их переселяет: из повреждения памяти в panic-DoS, исчерпание ресурсов, логику и доверие к десериализации. Доклад — о том, как проверка этой гипотезы превратилась в инструмент: я взял пайплайн Anthropic для поиска багов в C/C++, адаптировал его под Rust и натравил на фундамент экосистемы — включая парсеры, которыми вы разбираете чужие бинарники и ваши любимые reverse-proxy. По дороге — модель безопасности Rust, каталог реальных Rust-issue и разбор полётов.

Доклад повествует о исследовании механизма процессоров AMD — AMD Platform Configuration Blob (APCB). Я расскажу о том, что из себя представляют APCB, что они хранят, а также расскажу про уязвимость CVE-2025−54 502.

Этот доклад — не сухой отчёт в стиле «нашёл баг, отправил вендору, получил благодарность», а история полноценного исследования, которое началось с обычного любопытства. Мне хотелось понять, как устройство хранит, передаёт и воспроизводит музыку: как устроены кодеки SBC и AAC, как A2DP заворачивает аудиофреймы в RTP и как данные проходят через AVDTP, L2CAP и HCI.

Сначала проект казался мне неудачной попыткой поучаствовать в bug bounty: устройство было разобрано, найден UART, получены логи и прошивка, изучены web-обработчики, secure boot, сетевой стек и аудиомодем, но заметного результата не было. Спустя почти год я вернулся к оставшейся поверхности атаки — Bluetooth и медиаформатам — и начал с кодеков. SBC оказался удобной первой целью: формат простой и обязателен для A2DP. AAC, наоборот, оказался сложнее для понимания: падения были, но их пришлось отделять от ошибок harness’а, нехватки памяти и некорректных переходов состояния.

Я расскажу про то, как получилось разобраться во внутреннем устройстве кодеков и понять реализацию медиа-пайплайна в конкретном устройстве. Также я покажу, как ограничения доставки SBC-фреймов привела в самые глубины — в Bluetooth-стек. Я опишу, как можно без специального оборудования (ну почти) полностью управлять HCI-командами, L2CAP-каналами, AVDTP-сигналингом, AVRCP-ответами и медиапакетами.

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

Слушатели увидят не только финальные уязвимости, но и путь к ним: ошибки, неверные гипотезы, фаззинг, реверс-инжиниринг прошивки, отладку на живом устройстве, ручную работу с Bluetooth-стеком и несколько моментов, где вопрос «а что если я смотрю не туда?» и обычный исследовательский интерес оказались важнее любого инструмента.

Ресёрч closed source утилиты в кастомном u-boot для обхода secure boot и получения root доступа к роботам пылесосам Dreame от авторов Valetudo — опенсорсной замены облака для них.

Внутри реверс инжиниринг при помощи Ghidra с GhidraMCP кастомного u-boot и тикет системы, искуственно делающей данный способ рута зависимым от разработчиков Valetudo.

Разбор выгружаемого утилитой шифрованного архива, который предлагается отправить разработчикам — вычисляем ключ, расшифровываем, смотрим на свой пароль от Wi-Fi и фото с камеры робота.

В финале представлю PoC для вычисления тикета без серверов разработчиков Valetudo и получения root на роботах из любого региона без искуственных ограничений и передачи архива с данными из робота кому-либо.

Bootrom в системах‑на‑кристалле (SoC) семейства Qualcomm Snapdragon и MSM является критически важным компонентом мобильной системы безопасности, используемой в миллиардах смартфонов и IoT‑устройств по всему миру. Как встроенный и неизменяемый компонент, BootRom выступает корнем доверия для всей цепочки безопасной загрузки (Secure Boot Chain).

В нашем докладе представлено описание уязвимости CVE-2026−25 262 уровня Bootrom: уязвимости в режиме Emergency Download Mode (EDL) и его протоколе Sahara, которые позволяют обходить криптографическую проверку образов Secondary Boot Loader (SBL) и последующих уровней загрузки.

Но это лишь только начало: в процессе исследования нам удалось получить доступ к BootRom модема, активировать JTAG для каждого из ядер SoC, и даже переписать фьюзы на свои! Как нам это удалось? Обо всем этом мы расскажем в нашем докладе

SSTP (Secure Socket Tunneling Protocol) — VPN-протокол компании Microsoft, инкапсулирующий сетевой трафик в SSL/TLS-соединения (SSL VPN). Особенности ролевой модели Windows позволяют непривилегированным пользователям самостоятельно устанавливать VPN-подключения, что при определенных условиях может быть использовано для перехвата и перенаправления локального трафика на скомпрометированном хосте.

В докладе будет представлен Evil-SSTP — локальный SSTP-сервер, запускаемый непосредственно на целевой системе и позволяющий перенаправлять трафик до отдельных сервисов через контролируемый злоумышленником VPN-туннель. Такой подход открывает новые возможности для постэксплуатации: от повышения привилегий до обхода отдельных защитных механизмов и нарушения сетевой видимости средств мониторинга.

На практических примерах будут рассмотрены сценарии повышения привилегий через Zabbix Agent и WSUS, а также техники изоляции хоста от средств защиты за счет селективного перенаправления и блокирования трафика. Отдельное внимание будет уделено перспективам реализации Evil-SSTP в формате Isolated Web Apps, что потенциально расширяет возможности доставки и развертывания подобных инструментов.

В рамках доклада будут разобраны архитектурные особенности решения, требования к окружению, ограничения применимости, а также артефакты и методы обнаружения подобных атак со стороны защитников.

Security through Obscurity — один из самых распространённых подходов в мире embedded. Недокументированные регистры, скрытые режимы работы и proprietary-механизмы призваны защитить внутреннюю логику микроконтроллера от анализа. Но насколько эффективна такая защита, если исследователь готов выйти за рамки классического реверс-инжиниринга?

В этом докладе я расскажу, как исследование аппаратного AES-ускорителя в микроконтроллере Realtek привело к обнаружению недокументированного режима Scrambler. Традиционные методы анализа оказались бессильны, однако с помощью Side Channel Analysis (SCA) удалось восстановить внутренний алгоритм работы аппаратного блока и полностью воспроизвести его программную реализацию.

Весной 2026 года Александр Попов обнаружил и устранил необычную уязвимость в ядре Linux, которая была вызвана логической ошибкой в управлении сетевыми устройствами и присутствовала в коде ядра почти 5 лет. Ей был присвоен идентификатор CVE-2026−31 695. В своем докладе Александр детально расскажет об эксплуатации этой уязвимости с целью локального повышения привилегий на Fedora 44 Server для архитектуры x86₆₄.

Исследователь продемонстрирует, как он обошел средства защиты платформы и получил полный контроль над ОС с помощью подделки struct device. Кроме того, Александр покажет, как ему удалось сделать атаку абсолютно стабильной, несмотря на труднодостижимое состояние гонки при эксплуатации CVE-2026−31 695.

Рассказ о том, как от двух предположений о уязвимости из документации перейти к двум хардварным CVE внутри проприетарного чипа на странной архитектуре!
Доклад посвящен исследованию длинной в полгода касаемо безопасности внутри чипов Semtech семейства LR11xx, и о том, какими способами и методиками я нашел две уязвимости в них (и как не допустить схожих уязвимостей в будущем!).

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

В этом докладе мы разберем современные атаки на кроссчейн-мосты не как отдельные громкие инциденты, а как повторяющиеся классы уязвимостей. На примере Ronin, Wormhole, Nomad, Harmony Horizon, Multichain, Orbit Chain и других известных случаев рассмотрим, какие архитектурные решения чаще всего приводят к компрометации мостов, почему одни и те же ошибки продолжают повторяться и какие выводы из этого можно сделать.

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

COM — древняя технология Windows, которая до сих пор живёт во всех её уголках. Для разработчика это механизм интеграции, для атакующего — мощный инструмент, способный участвовать практически на каждом этапе кибератаки.

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

Руткиты живут в Linux-инфраструктуре дольше, чем принято думать. Они прячут процессы в памяти, подменяют системные вызовы, меняют ядро прямо во время работы. При этом техники непрерывно эволюционируют: каждый раз, когда защитники научились детектировать один подход, атакующие переходили к следующему поколению.

В этом докладе мы посмотрим на актуальные техники руткитов: от патчинга таблиц системных вызовов в ядре 6.9+ до самозащиты от инструментов анализа.

Что такое «enterprise-grade» защита для мобильного приложения и чем она отличается от обычных проверок на root-доступ? Чтобы ответить на данный вопрос, проведём анализ протектора Dexrotector — платного RASP-решения, которое используется для защиты многих отечественных Android-приложений.

В данном докладе реверс-инженеры Павел Князев и Сергей Борисов расскажут о том, как они анализировали механизмы защиты протектора Dexprotector для приложений ОС Android. Проверки на root-доступ, защита от хуков, сокрытие и обфускация DEX-файлов — будет интересно!

Спам эволюционирует. Классические фильтры, основанные на ключевых словах и эвристиках, давно превратились в игру в кошки-мышки — спамеры адаптируются быстрее, чем успевают обновляться контентные методы детектирования. Мы решили сменить подход: что, если модель будет не искать ключевые слова, а понимать смысл и намерение письма?

Так начался наш эксперимент по построению системы категоризации спама на основе LLM-эмбеддингов.

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

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

Сторонние плагины в B2B SaaS: как мы выстроили security review внешнего кода в Яндекс Трекере. Один плагин проверить несложно. Когда их десятки и каждый выходит новой версией — нужен процесс. Рассказываю как выглядит security review внешнего кода в Яндекс 360: AI в пайплайне, реальные находки, реальные промахи автоматики и где без человека не обойтись.

Представьте, что APT уже внутри, ходят по linux-серверам (SSH) как свои используя забытые ssh-ключи, проснифанные пароли, не шумят, перемещаются только по known_hosts. Классическим анализом логов такие горизонтальные перемещения не поймать, они неотличимы от легальных.

Поймать такие атаки можно с помощью графовых нейросетей (GNN AI).
В докладе расскажу, как это работает на пальцах, зачем граф вместо табличных логов и почему одна модель всегда слепа. Поделюсь результатами применения в крупной Linux инфраструктуре, где за год было 22 пентест и 1 суровый редтим — что реально сработало, что оказалось мусором и на какие грабли можно наступить.

GNN против современных APT — без хайпа и маркетинга. Будет жарко!

Фаззинг долгое время является одним из самых результативных способов поиска уязвимостей в приложениях, реализованных на C/C++. А с многократным увеличением сложности современного софта и кодовых баз также развивались технологии поиска уязвимостей в нём, в том числе и фаззинг, что отлично демонстрируют современные браузеры, являющиеся примером одного из самых сложных вариантов ПО в мире.

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

В докладе расскажем про:
* эволюцию различных фаззинг-технологий (от простого фаззинга парсеров и непростого фаззинга JS-движков до фаззинга мультипроцессных IPC, у которых есть свои состояния), которые использовали и используем, опыт их использования внутри inhouse-команды безопасности на примере Яндекс Браузера как «кастомного» chromium-based браузера;
* то, как используем LLM для поиска багов на примере собственной агентской системы;
* челленджи, с которыми столкнулись, делая агентскую систему и используя LLM для поиска багов в кодовой базе размера Chromium;

Также покажем и разберём примеры реальных багов, релевантных любому chromium-based браузеру, найденных разными способами, и попробуем оценить эффективность каждого из способов (обязательно обсудим token efficiency для LLM-based способов).

В больших системах моделирование угроз редко начинается с готовой архитектурной схемы. Чаще у AppSec-команды есть поток инженерных изменений: задачи, merge request-ы, страницы документации, обновления требований и другие артефакты. По отдельности они дают только фрагменты картины, но именно в них появляются сигналы о новой поверхности атаки, изменении потоков данных, границ доверия, модели доступа и чувствительных активов.

В докладе мы покажем, как связаны Oracul — наша система наблюдаемости за безопасностью продуктовых изменений — и ThreatOne, инструмент моделирования угроз на базе LLM. Oracul собирает и анализирует изменения, значимые с точки зрения безопасности, и формирует структурированные оценки: уровень риска, проблемы, рекомендуемые действия, уверенность, теги и доказательства. Эти оценки становятся входом для следующего слоя: подготовки контекста, декомпозиции системы на области анализа, использования исторических паттернов угроз и генерации гипотез угроз.

Фокус будет на инженерном процессе: как из потока изменений перейти к воспроизводимому моделированию угроз с доказательствами, трассируемостью и проверкой человеком.

Векторные базы данных стали стандартом де-факто для RAG-систем, а СУБД в целом массово уходят в Managed-платформы «по кнопке» с общим контрол-плейном и централизованной поддержкой. Превращение инструмента в платформу расширяет поверхность атаки и ужесточает требования к безопасности — проблема знакомая любому, кто строит внутренние платформы.

В докладе разберу опыт оценки безопасности платформенного Qdrant:
* Со стороны атакующего: две найденные RCE (одна запатчена без CVE) и вектора атак на платформенные БД.
* Со стороны защитника: архитектурные решения и харденинг для похожих платформ.

Вы узнаете про критические уязвимости в популярной векторной БД, типичные проблемы managed-решений и принципы построения защищённых платформ.

Доклад будет интересен Cloud Security архитекторам, AppSec-инженерам и Offensive-специалистам (в том числе багхантерам).

В докладе разберём модель доверия и привилегий JS-движка Acrobat, восстановим цепочку эксплуатации от загрязнения Object. prototype до вызова app. beginPriv () с подменённым контекстом, посмотрим на реальный ITW-семпл. Обсудим, какие ещё API Acrobat стоит ревизовать тем же подходом, как не допустить таких дыр на продакшене, и почему детект на уровне поведения работает там, где сигнатуры опаздывают.

Принтеры и МФУ редко входят в периметр, который тщательно тестируют и обновляют, — при этом у многих вендоров устройства годами хранят рабочие учётные данные от LDAP, SMTP, SMB и FTP.

В докладе будут рассмотрены pass-back-атаки — метод, позволяющий вынудить устройство передать сохранённые учётные данные на сервер атакующего, — на примерах HP, Brother, Lexmark и Kyocera, а также отдельно разобраны утечки через SNMP и уязвимость CVE-2022−1026 в Kyocera Net Viewer, позволяющая без аутентификации получить адресную книгу устройства с учётными данными, включая демонстрацию автоматизации массового сбора этих данных.

Исследование современных криптографических алгоритмов в СКУД, таких как AES-128/256 в режимах взаимной аутентификации, Triple DES, эллиптическая криптография ECC (ECDH/ECDSA), SHA-256, а также комбинированные схемы AES+ECC+SHA-256 и протоколы защищённого канала (SCP03, CCM, OSDP Secure Channel).

Большое исследование истории создания и развития СКУД — от кнопочных панелей до современных NFC-идентификаторов. Разберем механику работы, уязвимости, способы обхода и поразмышляем о будущем подобных систем.

В ИБ существует железное правило: не светить учетными данными. Но в физическом мире это правило систематически нарушается. Ключи оставляют на столах, выкладывают фото / видео в соцсети.

Парадокс в том, что техническая документация (Datasheet) на эти ключи существует у производителей десятилетиями. В ней описано всё: геометрия профиля, глубины кодовых дорожек, шаг нарезки, углы, радиусы, допуски. Но в практической работе исследователей и мастеров эти данные редко используются. Метод «на глаз» доминирует, хотя есть инструменты, превращающие его в инженерную задачу.

Доклад исправляет этот дисбаланс. Мы применяем подход из мира OpenAPI-спецификаций к физическим ключам.

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