Cyberwave 2025 глазами CISOCLUB

Редакция CISOCLUB посетила Cyberwave 2025 — первую в Санкт-Петербурге конференцию по практической кибербезопасности, которая состоялась 29 апреля 2025 года в Планетарии №1. Место проведения, расположенное в здании старинного газгольдера и оснащённое мультимедийным куполом диаметром 37 метром, идеально вписалось в концепцию «неформальной лаборатории» ИБ-практиков: здесь под каждой проекцией рождались живые дискуссии, демонстрации техник и диагностика уязвимостей в «боевых» условиях.

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

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

Например, ИТМО организовал консультационные сессии с преподавателями и аспирантами, что сделало площадку по-настоящему междисциплинарной: студенты задавали вопросы практикам, а эксперты узнавали о свежих академических исследованиях. В фойе между выступлениями кипели обсуждения. Это не был стандартный кофебрейк, а скорее, живая лаборатория с обменом опыта по практической информационной безопасности.

Программа Cyberwave 2025 была выстроена по принципу «единого потока»: утренние панели с докладами плавно сменялись мастер-классами и практическими воркшопами, а послеобеденное время было отдано живому взаимодействию со спикерами и разбору собственных задач.

Каждый из этих докладов сопровождался живыми вопросами из зала и демонстрацией практических кейсов. Ниже представлен подробный обзор ключевых выступлений, которые сформировали ядро деловой программы Cyberwave 2025.

«Переход не туда: как злоупотребление симлинками ведет к LPE в Windows»

Михаил Жмайлов, ресечер из CICADA8, на конференции поделился исследованием уязвимостей Windows, связанных с символическими ссылками (симлинками) и их злоупотреблением. Его выступление было посвящено тому, как неправильная обработка симлинков высокопривилегированными процессами может приводить к локальному повышению привилегий (LPE) в Windows. Михаил выстроил доклад в четырех частях: сначала познакомил слушателей с видами симлинков и особенностями их создания, затем разобрал реальные эксплойты, показал нестандартные трюки с симлинками, и в заключение рассмотрел методы защиты от подобных атак.

Виды симлинков и базовые уязвимости. Для начала спикер напомнил, какие бывают символические ссылки в Windows и каковы ограничения при их создании. Он выделил три основных типа: мягкие (NTFS) ссылки, жесткие ссылки и «симлинки» в реестре. NTFS-ссылки — это стандартные символические ссылки на файлы или папки; для их создания обычно нужны права администратора или специальная привилегия SeCreateSymbolicLinkPrivilege (либо включенный режим разработчика Windows). Жесткие ссылки позволяют ссылаться напрямую на один и тот же файл с разных путей, однако их можно делать только для файлов (не каталогов) и только в пределах одного диска; тоже требуются права администратора. Наконец, существуют символические ссылки в реестре Windows – особые привязки в иерархии ключей (например, ссылка из одного раздела реестра на другой). Создавать такие ссылки в защищенных разделах (таких как HKLM) от лица низкопривилегированного пользователя невозможно. Михаил подчеркнул, что сами по себе эти механизмы были задуманы в системе для удобства, но при некорректной реализации могут стать лазейками: уязвимости, связанные с симлинками, позволяют злоумышленнику воздействовать на файлы, обходя ограничения, и добиваться повышения привилегий.

Эксплойты с использованием симлинков. В основной части доклада Жмайлов подробно разобрал, как именно симлинки эксплуатируются для эскалации прав. Он показал, как исследователь информационной безопасности может с помощью утилиты Process Monitor отследить моменты, когда привилегированный процесс (работающий с правами SYSTEM) обращается к файловой системе – и понять, можно ли подсунуть ему свой симлинк на этом этапе. Например, один из типичных сценариев – Arbitrary File Delete, произвольное удаление файла от имени SYSTEM. Спикер привёл кейс, когда антивирус или другой системный сервис, запущенный с высоким уровнем привилегий, можно обмануть через объектную подсистему Windows. Злоумышленник создаёт символьную ссылку в специальном именованном пространстве объектного менеджера (например, подвешивает свою папку к глобальному каталогу RPC Control) и добивается того, что системный процесс по этому пути удаляет защищённый файл. В результате системный компонент удаляет файл, доступ к которому у обычного пользователя был бы запрещён – происходит эскалация прав. Жмайлов сослался на ряд реальных уязвимостей, использующих подобный приём (например, CVE-2023-27470, CVE-2023-20178, CVE-2022-30206). Эти CVE демонстрируют, как злоупотребление симлинками приводило к повышению привилегий в разных сценариях, и все были обнаружены совсем недавно.

Другой сценарий, о котором рассказал докладчик, – Arbitrary File Move, произвольное перемещение (или переименование) файла. Этот приём позволяет подменить исполняемый файл или библиотеку, которую затем запустит привилегированный процесс. Механизм таков: атакующий добивается, чтобы система переместила файл из одного каталога в другой по его указанию, используя симлинки. На слайдах был показан пример, как можно перенаправить перемещение DLL-библиотеки – файл pwn.dll подменяет легитимный Legit.dll в системной службе – чтобы загрузить свой код с системными привилегиями. Ещё одна продвинутая техника – обход UAC (User Account Control bypass) с помощью симлинка на директорию. Михаил продемонстрировал случай, когда злоумышленник создаёт специальную папку с именем, имитирующим системный файл языковых настроек (например, C:WindowsSystem32c_1337.nls), а затем преобразует эту папку в NTFS Mount Point – символическую ссылку, указывающую не на папку, а на файл. После этого атака провоцирует запуск системной службы National Language Support, которая обращается к файлу с данным именем. Поскольку вместо файла ей подсунута ссылкой другая цель, служба невольно читает содержимое чужого файла и отображает его в память, предоставляя низкопривилегированному пользователю доступ к защищённым данным. Таким образом, через создание директории и её превращение в особый симлинк удалось превратить примитив создания папки в примитив чтения закрытого файла – фактически обойти UAC и повысить свои привилегии. Все эти примеры подтверждают: даже на актуальных версиях Windows механизмы симлинков могут быть использованы злоумышленниками для компрометации системы. Недаром, отметил Жмайлов, новые уязвимости такого рода появляются регулярно – последняя CVE с абьюзом симлинков вышла всего за неделю до конференции, что подчеркнуло актуальность темы.

После разбора эксплойтов Михаил рассказал о ещё двух видах символических ссылок, которые обычно не используются рядовыми пользователями, но представляют интерес для атакующих. Речь идёт о символических ссылках вида NTFS Mount Point и ссылках объектного менеджера (Object Manager symlinks). NTFS Mount Point– это символическая ссылка, связывающая один каталог с другим. Докладчик отметил важную деталь: такую ссылку может создавать даже пользователь с низкими привилегиями, в отличие от обычных NTFS-ссылок на файлы. Есть лишь два условия – исходная папка должна быть пустой, и у пользователя должны быть права записи в неё. Возможность создания junction-ссылок (точек монтирования) открывает первый «кирпичик» в цепочке эксплуатации для LPE, поскольку даёт атакующему контроль над перенаправлением целых каталогов. Второй тип – Object Manager symlink – еще более нетривиален. Object Manager в Windows – это глобальная объектная таблица, где пути вроде диска C: на самом деле являются символическими ссылками на устройства (DeviceHarddiskVolume2 и т.д.). Михаил пояснил, что в некоторых пространствах имён объектного менеджера (таких как упомянутый RPC Control или BaseNamedObjects) даже ограниченный пользователь может создавать свои объекты. Злоумышленники научились использовать это, создавая там симлинки, которые указывают привилегированным процессам на другие объекты файловой системы. В докладе привели пример цепочки, где комбинация NTFS Mount Point и Object Manager-ссылок позволила захватить файл C:Tempabcfile.txt, хотя изначально план атаки казался сложным. Подобные трюки лежат в основе известных уязвимостей Windows: в частности, спикер упомянул CVE-2020-0683, CVE-2023-21800 и CVE-2024-29404, связанных с некорректной обработкой симлинков в системных службах. Эти CVE следуют схожей последовательности: создание контролируемого объекта (папки или файла), его удаление или перемещение через симлинк привилегированным процессом, и в итоге – захват ресурса или выполнение кода с повышенными правами.

Методы защиты. В заключительной части выступления Михаил Жмайлов рассмотрел, как разработчикам программ под Windows, работающим с высокими привилегиями, защититься от описанных атак. Он выделил два основных механизма: Redirection Trust и Impersonation. Redirection Trust – встроенная функция Windows, которая при активации запрещает процессу с SYSTEM-правами переходить по символическим ссылкам, созданным пользователем с меньшими привилегиями. Докладчик отметил, что для включения этого механизма достаточно выставить определённый флаг (галочку) через вызов WinAPI. Если доверие к перенаправлению отключено, то высокопривилегированный процесс просто игнорирует симлинки, указывающие на чужие ресурсы – и атака с их использованием становится невозможна. Второй подход – Impersonation, или «воплощение» учетной записи – предполагает, что сервис или процесс с SYSTEM-правами временно выполняет файловые операции не от своего имени, а от имени обычного пользователя. Проще говоря, когда привилегированная служба обращается к файлу, она сначала понижает свой контекст до уровня пользователя, что нейтрализует опасность: даже если на пути встретится ловушка в виде симлинка, операция выполнится с низкими привилегиями и не нанесёт вреда системе. Михаил упомянул, что им самим создан инструмент (репозиторий) для проверки, включён ли механизм Redirection Trust в конкретном процессе. Также он сослался на существующий сторонний проект защиты на уровне ядра, который отслеживает попытки подобных «прыжков» по симлинкам и блокирует их в режиме реального времени. Эти решения помогают предотвратить LPE-атаки на основе симлинков.

В конце выступления Михаил подчеркнул, что злоупотребление симлинками остаётся актуальной и опасной техникой: практически каждый месяц обнаруживаются новые уязвимости в Windows, использующие подобные трюки. Он призвал разработчиков высокопривилегированных сервисов и системных приложений внедрять описанные механизмы защиты. При правильном подходе – отказе от небезопасных переходов по ссылкам и работе с файлами от имени пользователя – можно существенно сузить возможности атакующего и защитить Windows-системы от целого класса LPE-уязвимостей.

«Игра в скамера»

Следующий доклад представила Катя Тьюринг, специалист по киберразведке и цифровой криминалистике. Катя – резидент сообщества OSINT Mindset, кибердетектив с опытом работы руководителем направления антифрода в VK и Avito. В своём выступлении под названием «Игра в скамера» она рассмотрела проблему проверки эффективности антифрод-систем в компаниях и предложила подход «примерить шкуру мошенника» для тестирования защиты. По сути, речь шла о том, как оценить и укрепить корпоративные системы противодействия мошенничеству, применяя методы, которыми пользуются сами мошенники, и какие этические и практические сложности с этим связаны.

Масштабы современного мошенничества. В начале доклада Тьюринг привела статистику, характеризующую ситуацию с мошенническими хищениями денег. По данным Генпрокуратуры РФ, в 2024 году в стране было зафиксировано порядка 130 тысяч случаев мошенничества, а по оценкам РБК – до 486 тысяч случаев. Сбербанк оценивает ущерб от действий мошенников за год в диапазоне 250–300 млрд рублей, похищенных у россиян. При этом средний пострадавший лишился около 120 тысяч рублей, и лишь 30% жертв обращались в полицию – многие не верят, что злоумышленников удастся найти и наказать. «В 2024 всё было плохо» – констатировала она на слайде про фрод, подчёркивая резкий рост и разнообразие мошеннических схем. Эти цифры показывают, что от действий злоумышленников страдают массово и частные лица, и бизнес, а обнаруживается далеко не каждое преступление.

Далее спикер упомянула усилия государства и индустрии, направленные на борьбу с мошенничеством. Существует ряд законов и стандартов, призванных усложнить жизнь злоумышленникам:

1. Федеральный закон 115-ФЗ (об противодействии отмыванию доходов).
2. ГОСТ Р 57580.1 (защита финансовых организаций).
3. Закон 161-ФЗ (о национальной платёжной системе).
4. Положения ЦБ РФ 652-П (обеспечение ИБ в кредитных организациях) и 683-П (порядок приостановки подозрительных операций).

Эти нормативно-правовые акты требуют от банков и финорганизаций выстраивать системы мониторинга транзакций, выявлять подозрительные операции, обеспечивать безопасность платежей и приостанавливать сомнительные переводы. Банки действительно вкладываются в antifraud-решения и стараются оградить клиентов от хищений. Однако, как отметила Катя, все перечисленные меры в основном нацелены на телефонных мошенников – тех, кто звонит жертвам и выманивает деньги. Проблема же в том, что помимо телефонного обмана существует множество других мошеннических схем, которые сложнее подвести под действие стандартных правил и регламентов. И злоумышленники активно осваивают эти новые форматы «скама».

Разнообразие схем «скама». Докладчица перечислила впечатляющий перечень актуальных мошенничеств, выходящих за рамки привычных телефонных звонков. Например, злоумышленники могут взламывать сайты и размещать на них провокационный контент (дефейс), требуя плату за восстановление репутации. Распространены схемы, когда жертве предлагают заплатить за доступ к несуществующим базам данных или соблазняют сделать предоплату за товары/услуги, которые в итоге не будут предоставлены. Набирают обороты и высокотехнологичные махинации, такие как фальшивые проекты с NFT или сбор денег на фейковые благотворительные акции. Отдельно упомянуты мошенничества в онлайн-торговле и инвестициях: схемы P2P-арбитража, рассылка поддельных ссылок на оплату, выдаваемых за легитимные. Порой преступники играют на чувствах и суевериях – например, действуют коучи, обещающие выступить «целителями родовых травм» за вознаграждение, или «чёрные риелторы», обманывающие при сделках с недвижимостью. Не останавливаются мошенники и перед шоковыми тактиками: практикуется вымогательство под надуманной угрозой (в презентации иронично упоминалась «под угрозой ВСУ», отсылая к временам тревожных новостей), рассылки о якобы выписанных фиктивных штрафах или несуществующих долгах, предложения получить «наследство в Конго» или избежать ответственности по вымышленному «уголовному делу». Этот длинный список иллюстрирует: формы обмана эволюционируют, и помимо классических звонков от «банковских сотрудников» теперь есть десятки других способов выманить деньги. Катя Тьюринг подчеркнула, что все эти разрозненные на первый взгляд случаи – части огромной экосистемы современного скама, с которой приходится иметь дело специалистам по безопасности.

Антифрод как часть кибербезопасности бизнеса. Столкнувшись с таким многообразием угроз, компании пытаются выстроить собственные системы противодействия мошенничеству – антифрод. В крупных онлайн-сервисах (банках, маркетплейсах, соцсетях) антифрод-подразделения стали нормой. Спикер привела данные исследования Javelin Strategy & Research: у крупных онлайн-продавцов в среднем до 7,6% выручки теряется из-за мошенников, а две трети клиентов не возвращаются на платформу, где были обмануты. То есть, фрод бьёт и по доходам, и по лояльности пользователей. Поэтому бизнес заинтересован защититься – каждая большая компания внедряет антифрод-систему, как только масштабы ее деятельности это требуют. Катя отметила, что полноценный антифрод в крупной организации обычно включает четыре основных направления работы:

1. Противодействие несанкционированному доступу (защита аккаунтов клиентов от взлома и захвата),
2. Пресечение мошеннических операций (не дать злоумышленнику провести запрещённую транзакцию или реализовать схему обмана на платформе),
3. Расследование инцидентов, если фрод всё-таки произошёл,
4. Наказание/блокировка нарушителей.

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

Проблема оценки эффективности антифрода. При всем внимании к построению систем antifraud, существует большая сложность: как понять, хорошо ли работает ваша антифрод-система? Спикер отмечает отсутствие отраслевых стандартов и бенчмарков – нет единой «линейки», чтобы измерить успешность борьбы с мошенничеством. Компании вынуждены вырабатывать собственные метрики, но оцифровать полезность антифрода непросто: бизнесу нужно понять, сколько денег он сэкономил благодаря мерам защиты, а самим антифродщикам – сколько атак они предотвратили. Эти величины сложно посчитать, и зачастую внутри компании нет полноты данных о всех потерях от фрода. Более того, далеко не все виды злоупотреблений однозначно классифицируются: есть «серые» зоны нарушений, когда непонятно, считать ли действие мошенничеством или нет, и как за него наказывать. Добавляется и «политика тишины»: компании не спешат делиться друг с другом сведениями о выявленных мошенниках, схемах и уязвимых местах. Коммерческие организации и банки обычно замыкаются каждый в своём контуре, не раскрывая деталей инцидентов ни коллегам по рынку, ни тем более широкой публике. В итоге искажается большая картина: каждый видит только свой участок поля боя. Распутывать межкорпоративные цепочки мошенничества сложно, расследования упираются в отсутствие обмена данными. Всё это приводит к тому, что каждая компания в отдельности зачастую не знает, насколько эффективен её антифрод на самом деле.

Отдельно спикер обратила внимание на человеческий фактор и корпоративную культуру. По её словам, внутри компании есть две заинтересованные стороны в вопросах антифрода: бизнес (менеджмент) и само антифрод-направление. Бизнес часто не обладает экспертизой, чтобы оценить качество антифрода, — топ-менеджменту сложно разобраться, хорошо или плохо работает система, если нет явных инцидентов. А вот команда антифрода… порой «не хочет отвечать» на этот вопрос. Ни одно подразделение добровольно не признает собственную неэффективность. Антифрод-специалисты выстраивают метрики, показывающие их работу в выгодном свете, и психологически не расположены искать у себя недоработки. Требуется очень высокий уровень внутренней культуры и профессиональной зрелости, чтобы объективно оценивать свои провалы. Поэтому проверка устойчивости антифрод-системы силами только внутренней команды затруднительна – велика вероятность, что некоторые уязвимости останутся вне поля зрения или замалчиваются.

«Играть в мошенника»: этический вопрос и внешние проверки. Катя Тьюринг подвела аудиторию к главной теме: как же тестировать антифрод-систему на прочность? Возникает парадокс: чтобы проверить, как компания противостоит мошенникам, нужно самим стать на время мошенниками. Спикер прямо спросила: «Должны ли мы почувствовать себя в шкуре мошенника, чтобы проверить, как работает наша собственная антифрод-система?». Этот вопрос носит не только практический, но и этический характер. Имитация мошеннических действий внутри компании может вступать в противоречие с внутренними правилами или законом, а также с психологическим комфортом сотрудников. Тем не менее, зачастую иначе никак не понять, где дыры в обороне. Катя отметила, что изнутри компании выявлять уязвимости антифрода очень тяжело, поэтому необходима внешняя экспертиза. По её опыту, только независимые специалисты могут беспристрастно проверить защиту на прочность.

Спикер разделила внешнюю экспертизу антифрода на три условных направления.

Первое – консалтинг: внешние консультанты привлекаются, когда у компании уже что-то «сломалось» в сфере antifraud, произошёл инцидент или выявлена проблема, и нужно понять, как исправить ситуацию. Консультанты помогают выстроить процессы, если внутренних знаний не хватает.

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

Наконец, третья и самая глубокая проверка – пентест антифрода. Его применяют, если компания выстроила и настроила антифрод, и хочет убедиться, что он реально работает и ловит злоумышленников. По сути, это симуляция действий мошенников: приглашённые эксперты с разрешения компании пытаются провернуть различные аферы на её платформе, чтобы посмотреть, сможет ли внутренняя система их обнаружить и предотвратить. Именно о пентесте антифрода Катя рассказала наиболее подробно, подчеркнув, что это крайне нетривиальная задача.

Особенности пентеста антифрод-систем. В отличие от классического пентестинга, нацеленного на технические уязвимости (бага в коде, незакрытый порт, SQL-инъекция и т.п.), тестирование антифрода во многом сводится к поиску изъянов в логике продукта и бизнес-процессах. Мошенники редко эксплуатируют баги в привычном понимании – скорее, они ищут лазейки в правилах: где система проверки обходит стороной какой-то сценарий, какую комбинацию действий не предусмотрели аналитики. Поэтому внешнему специалисту, проводящему пентест антифрода, приходится детально разбираться в специфике бизнеса заказчика. Как подчеркнула Тьюринг, часто логические ошибки можно найти и исправить только изнутри, самим владельцам продукта, потому что они лучше знают все нюансы работы своей платформы. Внешней команде очень тяжело «с ходу» понять, на чем именно попытаться построить мошенническую схему. Тем не менее, есть типовые векторы атак, с которых обычно начинают проверку. Например, взлом аккаунтов: попытки несанкционированного доступа к чужим учетным записям. Пентестер имитирует действия злоумышленника, подбирающего учетные данные (атаки credential stuffing, bruteforce, password spraying), пробующего обход двухфакторной аутентификации или социальную инженерию для захвата аккаунта через поддержку. Другая линия атаки – мультиаккаунтинг: создание множества фейковых аккаунтов для получения выгоды. Здесь в ход идут специальные антидетект-браузеры, использования подставных лиц (дропов), автоматическая регистрация аккаунтов и т.д., цель – обойти механизмы, отслеживающие, что один и тот же пользователь заводит несколько аккаунтов. Ещё одно направление – обман бизнес-логики платформы: например, злоумышленник пытается эксплуатировать программу лояльности (дублировать купоны или промокоды, чтобы получить бонусы), либо проверяет, можно ли совершать нелегитимные платежи (покупки без оплаты, отменяя транзакции в нужный момент), злоупотреблять реферальными программами, заниматься киберсквоттингом, размещать запрещённые товары и услуги и т.д. Спикер отметила, что такие проверки – кропотливый процесс: нужно придумать и проиграть десятки сценариев, пытаясь превзойти бдительность антифрод-системы. Часто внешние специалисты работают в тесном контакте с внутренняя командой, обсуждают обнаруженные странности, чтобы верифицировать, является ли это уязвимостью или задуманный функционал. В процессе пентеста могут вскрыться организационные моменты, например, недостатки расследования инцидентов или неотрегулированность санкций за разные нарушения. Всё это тоже ценно: компания получает целостную картину, где слабые места – будь то в технологии, правилах или процессах.

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

Утечки информации: примеры, кейсы из бб/пентестов

Дмитрий Прохоров, сотрудник Positive Technologies, багхантер под ником ratel_xx, рассказал о рисках утечек данных и том, как их систематически искать. В начале выступления он шутливо ставит перед собой выбор «душнить или не душнить», намекая, что собирается глубоко погрузиться в детали утечек.

Дмитрий входит в топ-5 багхантеров BI.ZONE Bug Bounty и является автором записи в базе CVE, так что его опыт впечатляет. По его словам, утечки информации могут происходить не только из основного продукта компании, но и из множества сопутствующих процессов. Он перечисляет целый «ландшафт» потенциальных источников утечек: процессы внутри команды разработки, сторонняя разработка модулей, интеграции с внешними сервисами (плагины, расширения), хранение пользовательских и корпоративных данных (облако S3, Google Docs, базы данных), командные коммуникации (Slack, таск-трекеры вроде Kaiten, базы знаний в Notion), процессы тестирования и деплоя, взаимодействие с клиентом (чаты поддержки, другие SaaS-решения), обсуждение требований и обмен данными (мессенджеры, видеоконференции), а также хранение кода и технической документации (репозитории GitHub/GitLab, Confluence, Artifactory и пр.). Во всех этих точках могут скрываться чувствительные данные. Основная причина утечек – банальные ошибки конфигурации или контроля доступа, когда нечто, что должно быть приватным, оказывается публично доступно в интернете.

Инструменты поиска утечек. Для выявления таких слабых мест Дмитрий использует ряд утилит. Он упоминает скрипты для массовой пермутации доменных и поддоменных имен, например, well-known инструменты вроде Altdns и GoBuster, а также экспериментирует с генерацией вариаций через языковые модели (шутливо называет ChatGTP). Это помогает обнаруживать нестандартно названные субдомены компании (dev-серверы, тестовые стоянки и т.п.). Кроме того, применяются сканеры и сборщики URL-адресов (subfinder, waybackurls) для поиска следов внутренних ресурсов в открытых источниках, а также сценарии для активного перебора и проверки обнаруженных адресов. Такой подход систематически охватывает как основную зону (example.ru и связанные домены), так и внешние окружения компании.

Далее спикер переходит к практической части – серия кейсов из собственного опыта багбаунти и пентестов, демонстрирующих разнообразные утечки.

Кейс №1: «Переменные окружения на dev-серверах». В первом примере основной боевой сайт компании оказался хорошо защищён, но поддомены разработчиков – напротив, раскрывали критичные данные. Дмитрий обнаружил, что на сервисах разработчиков, доступных по неочевидным адресам, можно вытащить переменные окружения приложения. Иными словами, конфигурационные параметры (ключи API, строки подключения к БД, пароли и др.), которые приложение хранит в среде, стали видны внешнему пользователю. Такое случается, например, если в коде оставлен специальный URL для вывода debug-информации либо если файл с переменными (например, .env) случайно доступен через веб. В итоге, используя поиск по поддоменам и Web Archive, багхантер наткнулся на страницу, где при обращении выводился список переменных окружения – настоящая находка для злоумышленника. Получив подобный доступ, атакующий знает внутренние пароли и секретные токены приложения.

Бонус: В связке с этим кейсом Дмитрий упомянул случай с Bitrix OAuth: на одном из dev-доменов обнаружился открытый OAuth-интерфейс корпоративного портала Bitrix, где из-за неправильной настройки тоже могли утекать данные. Этот дополнительный пример подчёркивает: иногда проблема не только в собственном коде, но и во внешних решениях, развернутых в тестовой среде.

Кейс №2: «Логи приложения (Spring Boot)». Следующий случай – утечка через журналы логирования. В целевом веб-приложении на базе Spring Boot были закрыты очевидные /env, /mappings или /heapdump (стандартные endpoints Spring-actuator, которые часто по умолчанию выключают в продакшене). Однако один из endpoints остался доступен – а именно, просмотр логов (/logfile или аналогичный). Дмитрий показывает, что даже если напрямую конфиденциальных данных в логах не видно, атакующий может создать утечку, спровоцировав систему записать что-то ценное в журнал. Например, отправляя особые запросы, можно вызвать в логах записи об ошибках вместе с чувствительными данными (stack trace с ключами, SQL- запросы с паролями и т.д.). В этом кейсе через открытый доступ к логам удалось извлечь внутреннюю информацию. Дмитрий отмечает: «Если утечки нет — мы её создадим», то есть сам факт открытого логирования уже брешь, которой злоумышленник может воспользоваться творчески.

Кейс №3: «Пользовательские данные, защищённые лишь UUID». Здесь речь о распространённой проблеме: некоторые системы считают достаточной защитой длинный уникальный идентификатор (UUID) ресурса. Дмитрий описал ситуацию, когда API предоставляло доступ к данным пользователя по известному UUID без дополнительной аутентификации. В итоге, зная или подобрав UUID (например, через уязвимость типа «предсказуемый идентификатор» или из утечек логов того же приложения), можно было получить личные данные пользователя. Дмитрий подчёркивает: полагаться только на трудность угадывания ID – плохая практика безопасности. Один неверно настроенный ручной метод проверки – и конфиденциальная информация утечёт.

Кейс №4: «Корпоративные данные через CDN с коротким токеном». В этом примере утечка затронула мобильные приложения компании. И корпоративное, и пользовательское приложение использовали единый CDN-сервер для загрузки данных. Доступ к ресурсам CDN ограничивался токеном в URL, но проблема в том, что токен оказался слишком коротким – всего 5 символов ([A-Za-z0-9]{5}). Спикер выявил шаблон: адрес вида https://cdn.example.ru/d/abcde, где abcde – случайный пятисимвольный код. Такой код имеет ограниченное число комбинаций, и при желании его можно перебрать или обнаружить через утечки (например, в тех же логах или Web Archive). Проникнув в трафик мобильного приложения, исследователь получил один URL с токеном, а далее сумел подобрать другие, что открыло доступ к закрытым корпоративным данным на CDN. Вывод: слишком короткие токены или пароли – серьёзная слабость, особенно когда они напрямую встроены в ссылки.

Кейс №5: «Облачное хранилище (Yandex S3)». Один из самых показательных кейсов – утечка через неправильно защищённое облачное хранилище. Компания хранила данные в S3-хранилище Yandex Object Storage. Названия бакетов старались делать неочевидными, однако в открытом JavaScript-коде фронтенда нашлись упоминания домена *.storage.yandexcloud.net. Дмитрий собрал все скрипты с сайта и заметил подозрительный запрос к облачному адресу – как он выразился, получил «исчерпывающий ответ сервера». Это позволило вычислить точное имя бакета. Дальше – больше: используя сервис Web Archive, он нашёл сохранённые копии этого бакета и обнаружил, что доступ открыт на чтение и запись. То есть любой мог не только скачивать содержимое, но и загружать/перезаписывать файлы! В довесок, в URL бакета фигурировал фрагмент корпоративной почты компании, что подтвердило принадлежность хранилища. Этот инцидент демонстрирует классическую проблему: забытый публичным облачный бакет с критическими данными (резервные копии, документы) – фактически клад для злоумышленника.

Кейс №6: «Утечка через интеграцию чата технической поддержки». Многие компании подключают на сайт и в приложение виджеты поддержки пользователей от сторонних провайдеров. Такой SaaS-чат при неправильной интеграции тоже может стать окном утечки. Дмитрий рассказал об интеграции чата, где разработчики оставили пользовательские токены практически открытыми. В ходе исследования он обратил внимание на сетевые запросы чата – например, вызов истории сообщений: /api/client/history?…&token=XYZ. Путём удаления лишних параметров запроса и анализа ответов системы удалось получить доступ к истории переписки, хотя в идеале посторонний не должен её видеть. Далее, применив сбор публичной информации о субдоменах провайдера чата (через доркинг и Web Archive), специалист нашёл внутренний адрес, относящийся к компании, который возвращал еще больше данных. Иными словами, из-за некорректного обращения с токенами и конфигурацией SDK чата, конфиденциальные диалоги пользователей могли оказаться в руках третьих лиц.

Кейс №7: «Сторонняя разработка: уязвимый плагин». В этом примере проблема пришла со стороны внешнего подрядчика. Для интеграции с неким внешним API компания использовала плагин (видимо, речь о CMS-плагине). Код этого плагина содержал «интересные комментарии», как выразился Дмитрий. Обычно под этим подразумеваются оставленные разработчиком заметки, в которых могут фигурировать логины, пароли, ключи API или описания уязвимостей. Проанализировав исходный код плагина, Дмитрий нашёл подсказки, облегчившие компрометацию системы. Этот кейс подчёркивает риск доверия стороннему коду: в спешке интеграции внешние разработчики могут оставить дырявую логику или не удалить отладочные комментарии, что потом оборачивается утечкой для основного продукта.

Кейс №8: «Хранение кода – открытые проекты GitLab». Многие компании поднимают внутренние системы для хранения кода и DevOps, например, собственный GitLab. В одном из заданий багхантеру удалось нащупать субдомен GitLab, принадлежащий компании, и обнаружить, что функция Explore (обзор публичных проектов) включена. Это означало, что ряд проектов и репозиториев были помечены как публичные либо доступные для чтения без авторизации. В таких репозиториях нашлось немало ценного: исходный код с секретными ключами, конфигурации, а также резервные копии баз данных. Вероятно, разработчики не подозревали, что эти данные открыты всему интернету. Дмитрий продемонстрировал, как простое перечисление поддоменов и сервисов компании (например, dev.example.ru, git.example.ru и т.д.) вместе с дефолтными настройками приводит к серьёзной утечке корпоративной информации.

Кейс №9: «Утечка токена GitLab Runner». Ещё одна уязвимость, связанная с GitLab, но другого рода. Спикер рассказал, как при переборе поддоменов он наткнулся на открытый конфигурационный файл, содержащий регистрационный токен GitLab Runner – специального агентского приложения для CI/CD. Этот токен предназначен для подключения новых Runner-агентов к серверу GitLab. Утечка такого токена опасна: злоумышленник может зарегистрировать своего Runner’а в инфраструктуре компании. Далее он дождётся, пока CI-система выдаст на этот Runner задачи от разработчиков (сборка, тестирование кода), и перехватит все секреты, которые в этих задачах используются (например, доступ к исходникам, креденшлы к базам, внутренние API-ключи). Дмитрий ссылается на исследование Frichetten про атаку с подменой Runner’ов: зарегистрированный злоумышленником Runner способен получить токены pipeline и любые артефакты сборки. Таким образом, утечка даже одногослужебного токена обернулась бы полной компрометацией процесса разработки.

Кейс №10: «База знаний: утечка через Kaiten/Notion». Напоследок – утечка корпоративной документации. Многие используют облачные сервисы управления проектами и знаниями (Kaiten, Notion и т.д.). Удобно делиться ссылкой на доску или документ с коллегами, однако если ссылка утекает наружу, ею могут воспользоваться все. Спикер описал случай, когда приватные рабочие пространства оказались доступны через прямые ссылки, засветившиеся в Web Archive. Он применил любопытную тактику: сначала собрал названия всех программ компании и связанные домены/аббревиатуры (чтобы понять, как могут называться рабочие пространства), затем сгенерировал вариации URL для Kaiten/Notion с этими названиями и прогнал их через поиск и Web Archive. Результат – среди сгенерированных ссылок нашлись валидные URL, ведущие к открытой части внутренней базы знаний. Видимо, кто-то когда-то расшарил эту страницу по публичной ссылке, и роботы поисковиков или Web Archive успели её зафиксировать. Вывод очевиден: даже документы и доски, не предназначенные для чужих глаз, могут всплыть, если не соблюдать гигиену ссылок и не отключать индексацию.

Таким образом, Дмитрий Прохоров последовательно разобрал десять разных сценариев утечек информации – от инфраструктурных мелочей до стратегических просчётов. Каждый пример подкреплён реальными кейсами из его практики, что ясно показывает: утечки бывают самые разные, и защищать нужно не только периметр основного приложения, но и всю экосистему вокруг него, включая облака, инструменты разработки и коммуникации. Спикер завершает доклад призывом уделять внимание этим «скрытым» зонам риска.

Атака на защиту: лик хэшей и данных

Сергей Буреев, начальник отдела тестирования на проникновение T.Hunter,поделился техниками атак на защитные механизмы Windows-систем. Его доклад был посвящён так называемым coerce-атакам – методам, заставляющим систему жертвы добровольно выдать данные для аутентификации на стороне атакующего.

Вначале Сергей объясняет, что такое coerce атака. По сути, это способ удалённо вынудить Windows-машину подключиться к ресурсу, контролируемому злоумышленником. Злоумышленник отправляет системе специальные запросы через различные протоколы, и та «самая» машина инициирует ответное соединение (например, пытается авторизоваться на сервере атакующего). В контексте Windows это обычно выражается в захвате NTLM-аутентификации: машина жертвы подключается к фальшивому серверу SMB/HTTP, передавая ему свои учетные данные в виде хешей NTLM. Даже если пароли не передаются в открытом виде, перехваченные хеши можно попытаться взломать грубой силой или использовать в атаках типа «relay» (пересылка). Сергей перечислил распространённые варианты coerce атак, вошедшие в арсенал пентестеров за последние годы:

1. Известный метод PetitPotam (заставляет контроллер домена обратиться к атакующему через протокол EFSRPC).
2. Атака PrinterBug (через уязвимость службы печати, также известна как SpoolSample), свежие техники ShadowCoerce, DFSCoerce, WSPCoerce.
3. Утечки NTLM-хешей через файлы и ярлыки (например, специальные .SCF-файлы, темы оформления или вредоносные HTML-страницы, которые вызывают попытку загрузить ресурс с удаленного SMB).

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

Однако основной акцент доклада был на менее известном способе: RPC-интерфейс MS-EVEN. Сергей напоминает о существовании этого RPC-протокола, который «недостаточно привлёк внимание хакеров». Команда T.Hunter исследовала MS-EVEN и выяснила, как его можно обратить в пользу атакующего, особенно в сочетании с антивирусом. Да, это звучит парадоксально: обычно защитные средства мешают атаке, но здесь – помогают.

«Trigger Defender»: антивирус как союзник атакующего. Сергей описал необычную ситуацию: злоумышленнику выгодно, чтобы антивирус обнаружил его действие. На примере встроенного Windows Defender (хотя, оговаривается спикер, и другие антивирусы подвержены схожему поведению) показывается, что сработка антивируса может вызвать внутри системы такие процессы, которые сам атакующий использует. Важно отметить, что обсуждаемые атаки относятся к среде Windows в домене (Active Directory) либо на одиночной машине – то есть это не удалённый интернет-вектор, а скорее техника уже внутри корпоративной сети. Итак, в чём же суть?

Используя возможности MS-EVEN, можно заставить систему обратиться по заданному адресу UNC (сетевой путь вида атакующий-сервер…). Более того, этот путь может содержать переменные окружения Windows. Например, злоумышленник указывает UNC-путь <сервер атакера>%USERNAME% или другой env-переменной. Когда эксплуатируется уязвимость MS-EVEN, Windows пытается обратиться к ресурсу, подставляя реальные значения переменных – таким образом «утекают» важные сведения (имя пользователя, имя компьютера, домен и т.д. в составе пути запроса). Но главная цель – не просто узнать имя машины, а получить её учетные данные. И вот тут на сцену выходит Windows Defender. При определённых условиях, спровоцировав срабатывание антивируса (например, заставив его просканировать специальный файл или событие), можно инициировать обращение от имени защищаемой системы к удалённому ресурсу. Windows Defender, работая с высокими привилегиями, сам выполняет сетевой запрос к сервер_атакующего… – тем самым передавая в руки злоумышленника ценнейший NTLM-хеш учетной записи Local System или даже доменного админа, под чьим контекстом запущен сервис. Сергей иронично называет получившуюся комбинацию MS-EVEN и антивируса – EVILen Coerce Attack (игра слов «evil» и «Event»). Это по-настоящему изящная техника: использовать защиту системы (антивирус) против самой системы.

Чем опасны coerce-атаки? Спикер перечисляет впечатляющий перечень последствий, которые возможны после успешного принудительного захвата аутентификации. Во-первых, перехваченный NTLM-хеш можно попытаться расшифровать (брутфорсить) вне системы, что при слабом пароле даст злоумышленнику чистый логин/пароль. Во-вторых, актуальнее сценарий relay-атаки: вместо взлома хеша его можно в режиме реального времени переслать на другой сервис внутри сети, от имени жертвы. Сергей приводит примеры: если переслать NTLM на сервер Active Directory Certificate Services (ADCS), можно выпустить себе цифровой сертификат от имени учетной записи жертвы, а с ним получить Kerberos-токен и в конце концов извлечь NT-hash пароля (это путь к эскалации привилегий в домене). Другой вариант – релэй на LDAP-службу контроллера домена: это позволяет настроить так называемую Resource-based Constrained Delegation (RBCD) или добавить «теневые» учетные данные, чтобы потом захватывать контроль над учётными записями. По сути, через LDAP-релэй можно получить права для последующего проникновения на контроллер домена. Можно направить перехваченный NTLM на SMB-сервер – тогда атакующий получит доступ к файловым ресурсам, сможет вытянуть секреты (например, файл SAM с хешами паролей) или разместить бэкдор. Ещё в списке – релэй на WinRM (Windows Remote Management), что даст удалённый шелл от имени жертвы. Наконец, упомянут прямой бонус техники MS-EVEN: помимо хеша, утечка переменных окружения может содержать и другие конфиденциальные параметры среды, которые помогут в развитии атаки. Таким образом, одна успешно проведённая coerce-атака может развернуться в компрометацию всей инфраструктуры Windows.

Как защититься? Сергей Буреев подчеркивает, что Microsoft уже закрыла ряд векторов принудительной аутентификации патчами (например, в свежих обновлениях заблокирован PetitPotam на контроллерах домена, исправлены уязвимости spooler и др.). Тем не менее, появляются всё новые варианты – как продемонстрировано с MS-EVEN. Общие рекомендации сводятся к нескольким пунктам:

1. Устанавливать актуальные обновления безопасности на контроллеры домена и серверы (чтобы известные уязвимости RPC-интерфейсов были закрыты).
2. По возможности фильтровать RPC-запросы и SMB-трафик внутри сети (ограничивать, какие машины могут обращаться к критичным RPC-портам и файловым ресурсам).
3. Включать подписывание SMB-сессий (SMB signing затрудняет перехват сессии).
4. Использовать Channel Binding для NTLM.
5. По возможности перевести аутентификацию на Kerberos там, где это применимо (устраняя саму возможность NTLM Relay).

Спикер также упоминает, что в Windows Server 2025 Microsoft планирует добавить специальную политику, позволяющую административно ограничить использование уязвимого механизма (в частности, перевести тот же MS-EVEN RPC с режима «доступен для аутентифицированных пользователей» в режим «только для администраторов»). Эта настройка недоступна в Server 2022, но в новых версиях появится, что осложнит злоумышленникам жизнь.

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

Простым языком о сложных CVE

Алексей Морозов, основатель компании G-HACK, начал свой доклад с объяснения, что такое уязвимость и что такое CVE.

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

После теоретической части Алексей перешёл к «весёлой» практике — разбору реальных случаев. Один из них касался трекера задач Jira: уязвимость Blind JQL позволяла с помощью хитрого поискового запроса (JQL) извлечь из системы информацию, минуя проверку прав доступа. Другой пример — уязвимость в инфраструктурном ПО SaltStack (CVE-2018-15751): из-за некорректной обработки пустого пароля при LDAP-входе атакующий мог авторизоваться без знания настоящего пароля.

Следующие кейсы относились к платформе .NET. В библиотеке Newtonsoft.Json опасная настройка TypeNameHandling при десериализации JSON могла привести к выполнению кода на сервере (CVE-2020-20136): достаточно, чтобы приложение принимало JSON со специальным полем $type. Ещё одна .NET-уязвимость — в механизме Dynamic LINQ (CVE-2023-32571). При слабой фильтрации пользовательского ввода злоумышленник через динамически сформированный LINQ-запрос мог вызвать на сервере системную команду (например, запустить процесс через Process.Start()).

Отдельно докладчик остановился на уязвимостях логики авторизации. Одна из них — проблема mass assignment (массового присваивания) в веб-фреймворках. Если платформа автоматически связывает все поля входных данных с объектом пользователя без проверки прав, злоумышленник может добавить скрытые поля и таким образом получить повышенные привилегии (например, присвоить себе роль администратора). Другой пример – уязвимость в продуктах Atlassian (CVE-2023-36899), найденная исследователем Bo0oM. Добавив специальную последовательность символов в URL запроса, можно было обойти запрет на доступ и проникнуть в закрытый раздел приложения. Этот случай показал, что нестандартный символ или пробел способен сломать фильтр и открыть доступ к админ-панели.

Отдельное внимание было уделено резонансной уязвимости Log4Shell в библиотеке Log4j (CVE-2021-44228). Эта ошибка позволяла посредством специальной строки ${jndi:…} в пользовательском вводе заставить серверное приложение загрузить и выполнить произвольный код. Спикер продемонстрировал эксплуатацию Log4Shell, удалённо запустив на уязвимом сервере приложение (для примера – калькулятор). Он подчеркнул масштаб проблемы: уязвимость привела к массовым взломам по всему миру и вынудила компании в авральном порядке обновлять ПО.

В завершение докладчик затронул современный тренд — привлечение искусственного интеллекта к поиску багов. Он показал подход, при котором описание уязвимости и фрагмент исправленного кода передаются в большие языковые модели, чтобы те сгенерировали готовый эксплойт и выдала PoC (доказательство осуществимости концепции). Такой инструмент значительно ускоряет появление эксплуатационных примеров после раскрытия новых багов. Спикер отметил, что ИИ не заменит эксперта, но уже стал ценным помощником в разработке PoC для сложных уязвимостей.

Знаем свои зависимости мощно и быстро

Алексей Смирнов, основатель платформы безопасной CodeScoring, посвятил свой доклад контролю зависимостей и рискам open source.

Он отметил, что в современных проектах лишь около 20% кода пишется с нуля, а остальные 80% приходятся на сторонние библиотеки. При этом разработчики часто не ведут полного учёта таких компонентов: зависимости копируются прямо в проект или перечисляются без указания версий и сред. В результате команда порой не знает точно, какой код какой версии используется в продукте.

Он напомнил, что масштаб open source продуктов растет, а вместе с ним растут и угрозы. За последние годы число атак на цепочки поставок выросло в десятки раз. Ежемесячно находят сотни вредоносных пакетов (поддельных или заражённых), которые крадут переменные окружения, добавляют бэкдоры и т.д. Кроме того, регулярно выявляются новые уязвимости в популярных библиотеках.

Особое внимание Алексей уделил транзитивным зависимостям — вложенным библиотекам, которые тянут за собой другие пакеты. Уязвимость глубоко в цепочке ставит под угрозу всё приложение, хотя о ней можно не догадываться. На примере критической уязвимости Log4Shell (Log4j) он показал, что, когда она была обнаружена, некоторые команды пытались просто искать «log4j» в своём коде. Это не сработало: эксплойт скрывался глубоко в зависимостях. Урок в том, что если заранее не знать все используемые библиотеки и версии, то при всплытии проблемы очень трудно быстро найти уязвимый компонент.

Чтобы оценить масштаб проблемы, CodeScoring проанализировал популярные open-source продукты (на JavaScript, Java, .NET, Python). Выяснилось, что средний проект содержит десятки уязвимостей в сторонних компонентах — и большая часть из них приходит именно через транзитивные зависимости. Например, в типичном JavaScript-приложении лишь около 14% уязвимостей находятся в прямых пакетах, а остальные 86% — глубже по цепочке.

Первый шаг — составить полный перечень используемых компонентов, так называемый Software Bill of Materials (SBOM), для каждого продукта. Спикер отметил, что существуют стандарты описания состава ПО (например, SPDX и CycloneDX), задающие единый формат списка библиотек и их версий. Применение SBOM упрощает анализ безопасности: зная точный перечень зависимостей, команда может быстро проверить, какие из них уязвимы, и отслеживать выход исправлений.

Следующий шаг — внедрить практику Software Composition Analysis (SCA). Инструменты SCA автоматически сканируют файл зависимостей и сравнивают его с базами известных уязвимостей — как в прямых, так и транзитивных пакетах. Причём такие проверки нужно выполнять на всех этапах — от разработки (IDE, pre-commit) до сборки и деплоя в CI/CD. При обнаружении критичной уязвимости инструмент сообщит команде или даже остановит конвейер, чтобы в продакшн не ушёл небезопасный билд.

Наконец, Алексей призвал сделать управление зависимостями частью культуры разработки. Работа с внешними библиотеками должна вестись наравне с работой над собственным кодом. Командам следует регулярно обновлять компоненты, отслеживать новые уязвимости и быстро реагировать на проблемы в открытых пакетах. Так можно снизить риски, связанные с чужим кодом, и уберечь бизнес от неприятных сюрпризов вроде «бомбы» в транзитивной библиотеке.

Носок на СОК

Антон Лопаницын (Bo0oM), руководитель проектов отдела безопасности продуктов группы аудита и практического анализа защищенности дирекции информационной безопасности Согаз, подробно рассказал о техниках, с помощью которых злоумышленники обходят защитные механизмы, скрывают своё присутствие и надолго закрепляются в чужой системе.

Обход веб-фильтров. Атакующий может воспользоваться тем, что средства защиты информации (WAF/IDS/DLP) и само приложение порой по-разному разбирают входящий запрос. Если сформировать его особым образом, система защиты не узнает в нём опасную команду и пропустит её к серверу, где та выполнится без помех.

Маскировка веб-шелла. Спикер привёл пример, как можно спрятать веб-шелл: заставить сервер отвечать на запросы с кодом 404 («не найдено»), хотя файл на самом деле существует. Браузер в таком случае ничего не покажет, а сам атакующий по прямому URL или через собственный скрипт всё же получит содержимое. Так бэкдор-скрипт остаётся незаметен для посторонних.

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

Сокрытие процессов. Чтобы антивирус или администратор не обнаружили запущенную вредоносную программу, её стараются не оставлять на диске. Антон описал технику безфайлового выполнения: загрузить исполняемый код напрямую в память и запустить системным вызовом, без сохранения на диск — сканеру нечего обнаруживать. Похожим образом в Windows применяется DLL-hijacking: подмена библиотеки так, чтобы доверенный процесс загрузил чужой код с системными привилегиями. Также докладчик отметил, что новый механизм io_uring позволяет выполнять операции ввода-вывода, не вызывая типичных системных функций, поэтому такая активность может ускользнуть от аудита.

Чистка следов. Чтобы скрыть своё присутствие, атакующие часто очищают журналы и историю команд. Они могут отключить сохранение Bash-истории (или удалить её содержимое) и вычистить логи – удалить из них записи о недавних действиях (авторизация, ошибки, сетевые запросы и т.д.). В результате расследование инцидента сильно затрудняется, хотя заметное отсутствие данных само по себе может вызвать подозрения у специалистов SOC.

C&C-каналы. Для скрытой связи с подконтрольным сервером злоумышленники маскируют каналы под обычный трафик. Например, «обратный шелл» может подключаться через зашифрованный канал на порт 443, не отличимый от стандартного HTTPS. Также встречаются более хитрые способы: пересылка команд через Telegram (бота) или через GitHub-репозиторий – такой сетевой трафик сливается с легитимным фоновым. А вот простые ICMP- или DNS-туннели легко выявляются и считаются ненадёжными.

Аномальные признаки. В заключение Антон подчеркнул, что аномалии в нагрузке способны выдать атаку. Непривычный всплеск дисковых операций, загрузки CPU или сетевого трафика, например, при копировании базы или выгрузке большого объёма данных привлечёт внимание мониторинга. Таким образом, SOC может обнаружить присутствие злоумышленника даже без явных сигнатур атаки.

CTF Battle

После деловой части конференции участников ждал «CTF Battle» — динамичный турнир по-спортивному хакингу в формате single elimination. Участники соревновались в криптоанализе, форензике, веб-безопасности и реверс-инжиниринге.

На «сцену» приглашалось по 2 участника, они по очереди исключали темы, по котором не хотят соревноваться. Когда оставалась 1 тема – начиналась «битва за флаг». Необходимо было за 10 минут первым найти и захватить “флаг”. Если победитель не был определен за 10 минут, участники решали компьютерные тесты (капчу) на скорость, выигрывал тот, кто решил больше тестов. Выигравший участник продвигался дальше.

Победителем стал участник с ником y0r.

Зоны и воркшопы

На мероприятии работала зона «Online Hack Quest» — серия интеллектуальных челленджей, объединенных в цепочки заданий. Соревнующимся требовалось применить логику и технические навыки, чтобы найти уязвимости или «флаги» на специально подготовленных сайтах и продуктах в условиях, максимально приближенных к реальным.

Для любителей «железного» хакерства были открыты воркшопы в «Hardware Hack Zone». Гости практиковались во взломе физического оборудования, на котором исследователи и специалисты по информационной безопасности могли попробовать свои силы в поиске и эксплуатации аппаратных уязвимостей под руководством опытных наставников и практиков.

Не менее популярным оказался стенд RetroTech Squad — выставка ретротехники, где можно было вернуться в эпоху 90-х и zero-х: от головокружительных битв в Ultimate Mortal Kombat 3 на Sega Mega Drive до перестрелок в Tekken 3 на оригинальной PlayStation 1.

Награждение и Afterparty

После «CTF Battle» прошло награждение победителей CTF и воркшопов.

Закрывала программу афтепати под микс электронной музыки и культовых саундтреков из The Matrix, Hackers и Mr. Robot. Было много всего интересного, но, пожалуй, информацию о кулуарной части оставим в кулуарах ☺

P.S. редакции CISOCLUB удалось выяснить, что организатором Cyberwave 2025 выступила компания «Ти Хантер», предоставляющая комплекс услуг в области внедрения, обслуживания и защиты информационных систем, и Beam Emotional Marketing, известные на российском рынке своими яркими и необычными событиям. Команда проекта поделилась с нами своими планами:

«Когда коллеги из “Ти Хантера” обратились к нам с идеей создать новый бренд в сфере мероприятий по информационной безопасности, мы сразу увидели в этом потенциал для формирования сильной и актуальной концепции. Так появился Cyberwave – новая волна инфобез-событий, переосмысляющая привычный формат. Мы делаем ставку на нестандартные площадки, неожиданных спикеров и живую, вовлекающую атмосферу. Наша цель – создавать регулярные события, которые не только отвечают потребностям профессионального сообщества, но и задают новые ориентиры для рынка. В планах развитие Cyberwave на территории Петербурга и Северо-Запада», – подчеркнула организатор Cyberwave, директор и фаундер агентства Beam Emotional Marketing Ксения Корабельник.

Комментируя итоги первой конференции Cyberwave, ее организатор, директор по информационной безопасности «Ти Хантер» Александр Художилов отметил CISOCLUB, что информационная безопасность в Санкт-Петербурге постепенно возвращается в активную фазу.

«Мы в “Ти Хантер” видим свою задачу в том, чтобы объединять это профессиональное сообщество, задавать повестку и поддерживать развитие отрасли. Cyberwave для нас – это не просто мероприятие, а шаг к созданию устойчивой платформы для диалога, обмена опытом и формирования сообщества. Мы хотели, чтобы это было содержательно, по делу, и с прицелом на будущее. У “Ти Хантера” большие планы: регулярные мероприятия, работа с вузами, поддержка молодых специалистов и создание точек притяжения для профессионалов в ИБ», – подчеркнул Александр Художилов.

Реклама. ООО «Кей Маркетинг», ИНН: 7841090686, Erid: 2SDnjewrPfj