Содержание статьи
Отборочные кибербитвы прошли онлайн с 28 февраля по 6 марта 2026 года. Команды атакующих боролись за выход в финал. Участники соревновались целую неделю: инфраструктура полигона работала круглосуточно. За это время им нужно было выполнить несколько заданий, в том числе:
реализовать два критических события и подготовить отчеты для жюри;
реализовать шесть критических событий и получить флаги через автоматическую проверку.
Финалистов отбирали по двум критериям: количеству очков и времени, за которое команды показали результат. По итогам соревнований команда KiberS заняла третье место — уверенно закрепилась в середине лидеров.
Я, Евгений Кабаргин (kiberjen), капитан команды KiberS. Мы специализируемся на практической offensive security и регулярно участвуем в соревнованиях по кибербитвам.
На отборе Standoff 17 команда KiberS показала высокий уровень подготовки, слаженную работу и продуманную тактику атак. Мы стабильно отыграли весь этап и уверенно вошли в число сильнейших команд.
Этот результат — прежде всего заслуга команды. Без вклада каждого мы бы не вышли на такой уровень. Нам помогли опыт прошлых соревнований, грамотное распределение задач и четкая внутренняя координация: благодаря этому мы уверенно отрабатывали сценарии и набирали очки.
Отдельно хочу поблагодарить команду KiberS за работу — и во время соревнований, и при подготовке этого отчета. Благодаря вашей вовлеченности, инициативе и готовности брать на себя ответственность мы смогли показать отличный результат. Вы все крутышки!
Перед активной фазой атак мы разобрали задачи и условия соревнования. Основой отборочного этапа были критические события — сценарии компрометации инфраструктуры с четкими условиями выполнения и критериями оценки. Важно было не просто закрыть каждый сценарий, но и правильно зафиксировать результат, особенно в заданиях, которые жюри проверяло вручную. Это требовало аккуратного оформления, воспроизводимых шагов и полного отчета.
На этом этапе мы занялись не только технической стороной заданий, но и общей стратегией. Подробно разобрали все критические события, оценили их сложность, возможные зависимости между заданиями и число баллов. Это помогло расставить приоритеты и выстроить порядок работы так, чтобы использовать время максимально эффективно.
Дальше мы накидали гипотезы по возможным точкам входа и векторам атак. Опирались и на описание инфраструктуры, и на опыт прошлых кибербитв. Сразу заложили типовые уязвимости, возможные мисконфиги и сценарии развития атаки: от внешнего периметра во внутреннюю сеть, а затем и в технологический сегмент. За счет этого в активной фазе мы тратили меньше времени на решения и били точнее.
Отдельно мы разобрали роли в команде и наладили взаимодействие. Распределили зоны ответственности: разведка, эксплуатация, постэксплуатация и подготовка отчетов — и настроили обмен информацией. Это помогло убрать дублирование, снизить нагрузку на участников и параллельно прорабатывать несколько векторов атаки.
На отборочном этапе нам дали следующий скоуп инфраструктуры.
Внешний периметр:
10.124.5.0/26
10.124.5.64/27
Внутренний периметр:
10.154.32.0/22
Мы сразу предположили, что атакующий, скорее всего, зайдет через внешний периметр, а потом начнет продвигаться вглубь сети, постепенно повышая привилегии и расширяя контроль над инфраструктурой.
К началу активной фазы мы уже понимали архитектуру, возможные сценарии атаки и приоритеты задач. Это помогло сразу перейти к разведке и поиску точек входа в инфраструктуру, не тратя время на хаотичный перебор вариантов, и сосредоточиться на самых перспективных направлениях.
Следом мы перешли к активной фазе — разведке инфраструктуры и поиску возможных точек входа. Наша главная задача на этом этапе — собрать максимум информации о доступных сервисах, хостах и внутренней логике сети.
Одним из первых шагов мы проанализировали DNS-инфраструктуру. И не случайно: DNS-серверы часто раскрывают важные детали архитектуры сети — имена хостов, внутренние сервисы и связи между ними. Ошибки в настройке DNS нередко позволяют вытащить эти данные без сложной эксплуатации.
Сначала мы базово просканировали внешний скоуп по DNS (порт 53), чтобы проверить, есть ли там доступные DNS-сервисы:
Во время сканирования мы нашли DNS-сервер на хосте 10. 124. 5. 40 и проверили его на типичные небезопасные настройки — в частности, можно ли выполнить zone transfer. Эта ошибка в конфиге позволяет выкачать всю зону домена, включая список всех зарегистрированных хостов.
Проверяем это таким запросом:
Попытка сработала: сервер без ограничений разрешил трансфер зоны. В итоге мы получили список записей домена:
Эти данные заметно упростили дальнейшую разведку: вместо слепого сканирования диапазона адресов мы сразу получили список ключевых узлов инфраструктуры и поняли, за что отвечает каждый из них.
Так что уже на раннем этапе мы смогли выделить приоритетные цели для дальнейшей атаки:
веб‑сервер ( landing. x. stf ) — возможная точка входа через веб‑приложение;
почтовый сервер ( mail. x. stf ) — сценарии для фишинга и атак на учетные записи;
VPN-шлюз ( vpn. x. stf ) — потенциальный канал доступа во внутреннюю сеть;
DNS-сервер ( bind. x. stf ) — источник дополнительной информации и вектор для дальнейших атак.
Эти данные задали направление всей дальнейшей работы: мы сосредоточились на самых перспективных узлах и выстроили понятный сценарий атаки — от внешнего периметра до внутреннего сегмента.
Внешний периметр
Хост 10.124.5.36 (landing.x.stf)
Получив список хостов из DNS, мы перешли к детальному разбору самых интересных узлов. Одним из приоритетных стал хост landing. x. stf ( 10. 124. 5. 36 ): по названию видно, что на нем, скорее всего, крутится веб‑приложение — а это типичная точка входа в инфраструктуру.
Сканирование хоста показало, что у него открыты такие сервисы:
SSH (22/TCP)
HTTP (80/TCP)
HTTP (3005/TCP)
HTTP (8080/TCP)
Сразу несколько веб‑сервисов на нестандартных портах намекали на сложную и, возможно, плохо контролируемую архитектуру приложения, так что этот узел выглядел особенно интересным для дальнейшего анализа.
Перейдя на http:// landing. x. stf/ , мы наткнулись на корпоративный портал компании. На первый взгляд — типовое приложение: информационные страницы, описание деятельности и базовая навигация.
Но даже на этом этапе мы вытащили полезную информацию. Проанализировав контент и структуру страниц, мы собрали email-адреса сотрудников — например, a_morris@x. stf и m_harris@x. stf . Позже их можно использовать для фишинга или password spraying.
Отдельно привлек внимание встроенный чат‑бот техподдержки с функцией восстановления доступа.
Когда мы пообщались с ботом, выяснилось, что механизм восстановления устроен небезопасно. Вместо нормальной проверки пользователя — например, через токены или MFA — система, по сути, просто отдавала учетные данные в ответ на запрос.
Используя эту логику, мы получили учетные данные сервисной учетной записи:
Email: support@x. stf
Password: DblfYjZABjbzkUR
С этими учетными данными мы вошли в административную панель приложения. Внутри нашли еще одну учетную запись:
Логин: agent
Пароль: [ BeKMWzD] JCMu3$J; 5GIP+VFwi7pg_
Такие учетные записи говорили о слабом контроле доступа и о том, что чувствительные данные могли храниться в открытом виде — типичная проблема внутренних сервисов, которые выставили во внешний периметр.
Еще одна интересная находка — веб‑интерфейс на порту 8080:
На этом порте работал GeoServer — популярная платформа для публикации геоданных. Такие сервисы часто администрируют отдельно, и они нередко остаются с настройками по умолчанию.
Мы проверили стандартные учетные данные и получили доступ к административной панели:
Логин: admin
Пароль: geoserver
Получив доступ, мы выяснили, что на сервере стоит GeoServer 2.23.3. Затем проверили известные уязвимости и нашли CVE-2024-36401 — она позволяет выполнять произвольный код удаленно, в том числе без аутентификации.
Уязвимость связана с некорректной обработкой входных параметров в OGC-запросах — WFS, WMS и WPS. В частности, параметр propertyName интерпретируется как XPath-выражение.
GeoServer использует библиотеку GeoTools, а та передает данные в Commons JXPath. Если не фильтровать XPath-выражения как следует, их могут интерпретировать так, что атакующий сможет выполнить произвольный код на Java.
Главная проблема в том, что уязвимость затрагивает не только сложные типы данных, но и обычные (simple feature types), поэтому эксплуатировать ее можно практически «из коробки».
Эксплуатация дает возможность:
выполнять на сервере произвольные команды;
получать удаленный шелл;
закрепляться в системе;
развивать атаку внутри сети.
Мы собрали OGC-запрос и получили удаленный доступ к системе.
Полученный шелл мы завели в наш C2-фреймворк KiberC2, чтобы централизованно управлять сессией и развивать атаку дальше.
Закрепившись на хосте, мы перешли к постэксплуатации. Для начала поискали конфиги и учетные данные.
При анализе файловой системы мы нашли конфигурационные файлы OpenVPN:
В них были параметры подключения, которые открывали доступ к внутреннему сегменту сети.
С этими данными мы подключились к внутреннему периметру.
Следом мы проверили, доступны ли внутренние ресурсы:
Сканирование показало: в сети есть SMB-сервисы с анонимным доступом, а это открывает дополнительные возможности для разведки и дальнейшего взлома.
Один уязвимый сервис на внешнем периметре дал нам не только доступ к хосту, но и выход во внутреннюю сеть — с этого и началось дальнейшее развитие атаки.
Чтобы не упустить ничего важного, мы снова прошлись по другим узлам внешнего периметра — в частности по почтовому серверу mail. x. stf , который тоже выглядел очень интересно.
Мы участвуем в кибербитвах со Standoff 12 и за это время набрали солидный практический опыт атак в условиях, максимально близких к реальной инфраструктуре.
С каждым новым соревнованием мы не только прокачивали технические навыки, но и пересматривали подходы к организации работы внутри команды.
На прошлых соревнованиях мы не раз упирались в ограничения инструментов для командной работы и управления атаками. Они подводили по стабильности при долгой работе, плохо подстраивались под конкретные сценарии и не давали нормально координировать действия между участниками.
В итоге мы решили сделать собственный C2-инструмент — KiberC2 , заточенный под наши задачи и стиль работы. Мы опирались на опыт работы с популярными решениями вроде Cobalt Strike и Havoc и постарались убрать их ключевые слабые места. Основной упор сделали на стабильность, более гибкое управление агентами и удобную командную работу: централизованное управление, прозрачность действий и простую передачу доступа между участниками.
Отдельно мы думали об удобстве работы во время соревнований: нужно быстрое развертывание, устойчивость к сбоям и возможность на лету масштабировать атакующую инфраструктуру по мере развития сценария.
На отборочных соревнованиях Standoff 17 мы активно использовали KiberC2. Инструмент отлично себя показал: упростил взаимодействие внутри команды, ускорил типовые операции и помог лучше контролировать ход атак. В условиях жесткого тайминга и высокой конкуренции это дало нам ощутимое преимущество.
Хост 10.124.5.11 (mail.x.stf)
Проверив веб‑узлы внешнего периметра, мы переключились на другие цели, которые нашли на этапе DNS-разведки. Одной из самых перспективных оказался почтовый сервер mail. x. stf ( 10. 124. 5. 11 ): такие узлы часто хранят критически важные данные и подходят для атак на пользователей.
Первичный анализ показал, что на хосте развернут Microsoft Exchange. Это открывало возможности для атак через обработку почты и механизмы пользовательских каталогов.
Одним из векторов атаки стал анализ механизма Offline Address Book (OAB) — офлайн‑копии глобальной адресной книги Exchange. Ее используют клиенты, например Microsoft Outlook, чтобы работать без постоянного подключения к серверу.
При определенных настройках доступ к OAB можно получить без аутентификации или почти без ограничений. Из‑за этого OAB удобно использовать для перечисления пользователей организации.
Мы воспользовались методикой исследовательской команды PT SWARM и извлекли данные из OAB.
В итоге мы собрали полный список email-адресов сотрудников домена.
В результате вместо небольшого списка пользователей у нас оказалась валидная база учеток, с которой можно идти дальше и развивать атаку.
Используя собранные email-адреса, мы провели фишинговую атаку, чтобы выманить учетные данные пользователей.
Благодаря реалистичному сценарию и точно выбранной целевой аудитории мы смогли получить доступ к активным пользовательским сессиям.
Так мы закрепились в системе под учеткой легитимного пользователя и перешли к следующему этапу — анализу привилегий и эскалации.
Получив доступ, мы проверили права скомпрометированного пользователя и выяснили, что можем локально повысить привилегии.
Для этого мы использовали GodPotato — инструмент, который эксплуатирует особенности работы токенов Windows и поднимает привилегии до уровня SYSTEM .
Получив привилегии SYSTEM , мы сняли дамп Local Security Authority и вытащили из него учетные данные и хеши паролей пользователей.
Среди добытых данных оказался хеш учетной записи администратора. Это позволило применить технику Pass-the-Hash: пройти аутентификацию без пароля, используя только NTLM-хеш.
Для подключения к хосту во внутреннем сегменте мы использовали такой запрос:
На этом шаге мы получили административный доступ к внутреннему хосту и смогли продолжить атаку уже изнутри сети.
Чтобы упростить дальнейшую работу и не светиться, мы пустили трафик через наш C2-сервер — KiberC2 .
В результате удалось:
централизованно управлять сессиями;
маршрутизировать трафик во внутреннюю сеть;
масштабировать атаку без прямого подключения к каждому хосту.
Скомпрометировав почтовый сервер и учетные записи пользователей, мы смогли:
Получить валидные учетные записи.
Закрепиться в системе.
Повысить привилегии до уровня SYSTEM.
Извлечь учетные данные.
Провести lateral movement во внутренний сегмент.
К этому моменту мы уже вышли за пределы внешнего периметра, закрепились внутри инфраструктуры и были готовы развивать атаку по критичному сценарию.
Готово — приступаем к реализации НС внутри периметра!
Внутренний периметр
Захват системы управления инфраструктурой
Получив доступ во внутренний периметр, мы перешли к следующему этапу — поиску ключевых узлов инфраструктуры, компрометация которых дала бы максимальный эффект. В первую очередь нас интересовали системы централизованного управления: они позволяют масштабировать атаку и получить контроль сразу над множеством хостов.
Одной из таких целей стал сервер Microsoft System Center Configuration Manager (SCCM). Этот продукт широко используют для администрирования инфраструктуры: развертывания софта, управления обновлениями, запуска скриптов и централизованного контроля рабочих станций. Если скомпрометировать SCCM, можно фактически получить контроль над значительной частью домена.
Во время разведки во внутреннем сегменте мы нашли хост SCCM и изучили его. Выяснилось, что он уязвим к CVE-2024-43468 : проблема связана с некорректной обработкой запросов к бэкенд‑компонентам.
С помощью этой уязвимости можно:
выполнять произвольные SQL-запросы от имени учетной записи Management Point ;
использовать привилегии уровня sysadmin для дальнейшего повышения прав;
выполнять команды на уровне ОС, например через xp_cmdshell ;
получить полноценное RCE на сервере SCCM .
Так мы получили прямой путь к компрометации одной из ключевых систем инфраструктуры.
С помощью CVE-2024-43468 мы выполнили SQL-запросы с повышенными привилегиями и создали в системе учетную запись администратора.
Этот шаг помог нам закрепиться в SCCM и продолжить атаку уже с повышенными правами.
Дальше мы проверили стандартную настройку домена — атрибут ms-DS-MachineAccountQuota . По умолчанию он разрешает любому аутентифицированному пользователю создавать до десяти учетных записей компьютеров.
Мы использовали этот механизм и создали две учетные записи: kibers$ и kibers_approve$ .
Этот подход часто используют в атаках на Active Directory: учетные записи компьютеров помогают обходить ограничения и продолжать работу с сервисами, в том числе с Microsoft Configuration Manager.
Следом мы закрепились в системе управления. Через учетку dragom с доступом к Microsoft SQL Server добавили созданные машинные аккаунты в привилегированную группу SCCM.
Это позволило нам легально работать с системой управления и использовать ее возможности для выполнения команд.
Для дальнейшей работы мы использовали инструмент sccmhunter , он пригодился в эксплуатации SCCM и взаимодействии с его инфраструктурой.
С его помощью мы успешно вошли в систему и получили административный доступ к функциям SCCM.
Получив контроль над SCCM, мы смогли выполнять команды на управляемых хостах. Это уже критичный инцидент: под компрометацией оказалась система управления инфраструктурой.
По заданию мы создали и загрузили вредоносный скрипт, который развернули через механизмы SCCM.
SCCM создан для централизованного управления, поэтому такой сценарий особенно опасен: злоумышленник может разнести вредоносный код по множеству узлов инфраструктуры через легитимные механизмы администрирования.
В итоге компрометация SCCM стала одним из ключевых этапов атаки и дала нам возможность:
закрепиться в инфраструктуре на уровне систем управления;
взять под контроль большое количество хостов;
развивать атаку с помощью легитимных инструментов администрирования;
довести атаку до одного из критических событий.
Этот шаг стал переломным моментом: после него атаку развивали заметно быстрее и эффективнее.
Распространение вируса-шифровальщика
Закрепившись во внутреннем периметре, мы начали искать узлы с критичными данными и системы, которые открывают к ним доступ. Первым делом обратили внимание на сервер резервного копирования BACKUP.X.STF (10.154.32.166).
Резервные серверы — одна из главных целей для атаки: там лежат архивы, дампы и чувствительные данные, а еще часто используются сервисные учетные записи с повышенными правами.
Для анализа связей в домене мы использовали BloodHound: он помог наглядно показать зависимости между пользователями, группами и сервисными учетками.
Выяснилось, что пользователи AMORRIS , MHARRIS и сервер BACKUP состоят в группе x\ svc-backup-servers . У этой группы есть право PrincipalsAllowedToRetrieveManagedPassword для gMSA-аккаунта x\ svc-backup$ .
Это означало, что участники группы могли получить пароль gMSA-аккаунта — точнее, его представление, — а это уже критически важный шаг для дальнейшего развития атаки.
Мы обратили внимание на важный нюанс: в группу входил компьютер , а не пользователь. Значит, извлечь пароль можно было только из контекста конкретной системы.
К этому моменту мы уже получили привилегии SYSTEM , поэтому решили работать с LDAP от имени компьютера.
Поскольку LDAP на контроллере домена доступен только из внутреннего сегмента, мы подняли туннель:
подняли SOCKS5-прокси через Chisel;
завернули трафик в Proxychains.
После этого запустили утилиту gMSADumper :
После этого мы проверили права полученной учетки и выяснили, что svc-backup$ может обращаться к файловым шарам на сервере BACKUP.
Мы подключились к серверу и нашли интересный защищенный архив.
Архив выгрузили на машину атакующего для дальнейшего анализа.
Чтобы распаковать архив, сначала пришлось подобрать пароль. Для этого мы использовали классическую связку инструментов:
После брутфорса восстановили пароль и получили доступ к содержимому архива.
Внутри лежали учетные данные пользователя support в открытом виде.
С полученными учетными данными мы подключились к целевому серверу.
Чтобы выполнить задание, нам нужно было развернуть и запустить вредонос — шифровальщик. Мы загрузили бинарник stf-malware в каталог / tmp и запустили:
После запуска малвари данные на целевой системе зашифровались — это уже тянет на критический инцидент.
Несанкционированное изменение инвентаризационных записей
Получив доступ во внутренний периметр и закрепившись на нескольких узлах, мы взялись за поиск систем, завязанных на бизнес‑логику компании. Одной из главных целей стала система инвентаризации: ее компрометация открывала прямой путь к манипуляциям с учетом материальных ценностей.
На этапе предварительной разведки мы просканировали сеть и с помощью разных инструментов нашли доступные хосты и сервисы.
Получив хеш учетной записи support , мы проверили, не переиспользуют ли ее в инфраструктуре. На нескольких узлах эти учетки оказались валидными (Pwn3d!), и мы смогли аутентифицироваться на хосте CCUMINGS .
Закрепившись на этом узле, мы подняли прокси через уже установленный канал KiberC2 и получили доступ к сегментам сети, до которых нельзя было дотянуться напрямую, включая хост 10.154.32.197.
Разбирая веб‑интерфейс целевого хоста, мы нашли форму логина, которая отправляла SQL-запросы в бэкендную базу без нормальной фильтрации входных данных.
Это указывало на потенциальную уязвимость класса SQL injection.
Чтобы проверить гипотезу, мы перехватили запрос и подготовили его к автоматическому анализу.
Хотя уязвимость можно было эксплуатировать вручную, мы ускорили процесс с помощью sqlmap , передав ему сохраненный HTTP-запрос.
Sqlmap подтвердил SQL-инъекцию и открыл доступ к более продвинутым сценариям эксплуатации. Мы запустили режим --os-shell и смогли выполнять команды прямо на сервере.
После генерации полезной нагрузки мы доставили shell через Burp Suite , проксируя трафик.
Эксплуатация уязвимости дала нам интерактивный доступ к системе.
На этапе постэксплуатации мы изучили файловую систему и конфиги приложения и нашли файл с учетными данными для подключения к базе данных.
С найденными учетными данными подключились к базе данных.
Чтобы разобраться в структуре данных, мы сделали выборку из таблицы product :
В таблице были сведения о товарных позициях и их количестве.
По условиям задания нужно было изменить количество товара Wooden Pallets. Для этого мы выполнили SQL-запрос:
После запроса система изменила данные, из‑за чего нарушилась целостность учетной информации.
Критическое событие успешно зафиксировано.
Кража интеллектуальной собственности
Закрепившись во внутреннем периметре, мы продолжили искать узлы с ценными данными. Еще на этапе разведки нашли хост 10.154.32.132 с поднятым HTTP File Server (HFS) .
Такие сервисы часто используют для быстрого обмена файлами внутри инфраструктуры, и в них нередко лежат чувствительные данные: документы, конфиги и служебная информация.
Раз у нас уже была точка опоры на хосте CCUMINGS и настроенное проксирование, мы смогли работать с этим узлом.
Анализ сервиса HFS показал, что он уязвим к CVE-2024-23692 — template injection .
Уязвимость заключается в том, что сервер криво обрабатывает входные параметры и делает возможным внедрение шаблонных конструкций, которые затем выполняются на его стороне.
Уязвимость позволяет:
отправить специально сформированный HTTP-запрос без аутентификации;
выполнить произвольную команду на целевой системе;
добиться удаленного выполнения кода (RCE).
Таким образом, этот сервис был прямой точкой компрометации хоста.
Для эксплуатации мы взяли готовый скрипт и пустили трафик через заранее настроенный прокси — pivot через CCUMINGS :
После выполнения этих команд:
Создали новую учетную запись.
Добавили пользователя в группу Administrators .
Так мы получили полный административный доступ к системе.
После создания учетной записи мы подключились к хосту через WinRM :
Получив интерактивный доступ, мы смогли работать с файловой системой и вытаскивать данные.
Во время анализа содержимого хоста нашли файл scada. txt .
В файле лежали учетные данные пользователя из промышленного сегмента SCADA — логин и пароль в открытом виде.
Утечка данных с компьютера руководителя компании
После предыдущих этапов атаки у нас уже был доступ к нескольким учетным записям, и мы пошли дальше — нацелились на рабочие станции пользователей с высокими привилегиями. В первую очередь нас интересовали аккаунты руководителей: на их устройствах часто лежат конфиденциальные документы.
Для продвижения дальше мы использовали учетные данные, которые раньше сняли с backup-сервера. Сначала нужно было понять, к каким хостам можно подключиться удаленно.
Мы просканировали внутреннюю сеть и проверили, где доступен сервис WinRM , который часто используют для удаленного администрирования Windows-систем.
Сканирование показало, какие хосты принимают удаленное подключение с имеющимися учетными данными.
С валидными учетными данными мы подключились к одной из целевых систем по WinRM и получили интерактивный доступ к рабочей станции пользователя.
На этом этапе важно помнить: если использовать легитимные учетные записи, шанс спалиться заметно ниже, потому что такие действия выглядят как обычная активность администратора.
Получив доступ, мы начали разбирать файловую систему. В первую очередь проверили пользовательские каталоги — особенно C:\ Users\ d_mullen\ Documents .
В этой директории нашли файл sensitive_data. txt с конфиденциальной информацией о работе компании.
Удалось открыть файл и извлечь его содержимое — значит, задание выполнено, а критическое событие успешно сработало.
В этом сценарии нам удалось:
использовать учетные данные, полученные ранее;
перемещаться по сети (lateral movement);
получить доступ к рабочей станции привилегированного пользователя;
найти и выгрузить конфиденциальную информацию.
Этот кейс показывает: даже без эксплуатации дополнительных уязвимостей злоумышленник может добиться серьезного результата, если грамотно выстроит цепочку атаки и повторно использует учетные данные.
Получение учетных данных оператора
Пожалуй, это одно из самых сложных и нетривиальных заданий отборочного этапа: нужно было не только эксплуатировать уязвимости, но и разбирать вредоносное ПО.
Развивая атаку, мы получили доступ к рабочей станции пользователя CCUMMINGS . На рабочем столе нашли исполняемый файл, который, вероятно, связан с вредоносной активностью.
Файл выгрузили на машину атакующего для дальнейшего анализа.
Для анализа подойдут классические инструменты реверс‑инжиниринга — IDA Pro или Ghidra. Но когда времени в обрез, можно пойти другим путем и подключить ИИ.
В итоге мы подробно разобрали, как работает этот файл, и выяснили, что это кейлоггер .
Программа умела делать вот что:
устанавливала глобальный хук клавиатуры через SetWindowsHookExW;
перехватывала нажатия клавиш;
преобразовывала нажатия в символы через ToAscii;
формировала имя выходного файла по текущей дате;
записывала перехваченные данные в файл.
Также удалось выяснить технические характеристики:
формат файла: PE32+ (Windows x86-64 GUI) ;
характерные импорты: SetWindowsHookExW , UnhookWindowsHookEx , CallNextHookEx , GetKeyboardState , GetKeyState , ToAscii ;
криптографические API: CryptAcquireContextW , CryptGenRandom , CryptReleaseContext ;
debug path: C:\ repos\ Keylogger\ x64\ Release\ Keylogger. pdb ;
SHA-256: 77edc57ed685749e594a82f83f9e1036a73d79410b95893c851890813da64c6b .
Стало ясно: этот файл скрытно собирает учетные данные пользователей.
Анализ бинаря показал, что перехваченные данные сохраняются во временной директории пользователя.
Речь именно о логах нажатий клавиш (keystroke logs), которые собирает кейлоггер.
Путь можно получить через API-функцию GetTempPathW .
В директории с временными файлами мы нашли файл с именем по дате: 2026-01-19 .
Файл содержал зашифрованные, то есть обфусцированные, данные с перехваченными нажатиями клавиш.
Чтобы ускорить анализ, мы передали содержимое файла ИИ и получили описание его структуры:
данные разбиты на блоки по 23 байта ;
обработка идет с конца файла ;
Как декодируется один блок:
После декодирования:
последовательность разворачивается;
символы 0x08 (backspace) удаляются, чтобы восстановить корректный пользовательский ввод.
Здесь используется простая XOR-обфускация, так что о криптографической стойкости речи не идет.
По этому алгоритму мы написали декриптор — скрипт для расшифровки — и восстановили данные, которые вводил пользователь.
В итоге получили учетные данные оператора SCADA:
user : 3ZMBq8SNcRf04dDl .
Теперь у нас есть учетные данные уже двух пользователей SCADA, так что можно переходить к финальному этапу — атакам на промышленный сегмент.
Каскадный простой в производстве металла
Получив учетные данные операторов и закрепившись во внутреннем периметре, мы перешли к следующему этапу — атаке на промышленный сегмент (OT).
Для этого мы использовали промежуточный узел доступа (jump host) — через него мы входили в технологическую сеть и работали с изолированными SCADA-системами.
С этого узла мы просканировали доступные хосты в промышленном сегменте и нашли машины из SCADA-инфраструктуры, через которые идет взаимодействие с промышленными контроллерами.
Ключевым узлом оказался хост 10.154.33.3. Мы подключились к нему с помощью учетных данных оператора, которые получили раньше ( 3ZMBq8SNcRf04dDl ).
Получив доступ, мы изучили интерфейс SCADA и доступные элементы управления. Выяснилось, что система связана с промышленным контроллером (PLC), который управляет подачей руды на производственной линии.
Если смотреть с точки зрения атак, тут есть несколько возможных векторов воздействия:
изменение логики SCADA-проекта;
изменение данных в базе;
прямое воздействие на PLC.
Первые два варианта не сработали: мешали ограничения доступа, а напрямую повлиять на параметры процесса не получалось. Поэтому мы переключились на работу с контроллером напрямую.
Чтобы понять, по какому каналу идет обмен с PLC, мы проанализировали сетевые соединения:
В итоге нашли открытый порт 102/TCP — его использует протокол Siemens S7 для связи с контроллерами SIMATIC S7-1200.
Это подтвердило, что технологическим процессом управляют напрямую через PLC.
Чтобы изменить параметры PLC, сначала нужно было разобраться, в каких областях памяти хранятся управляющие значения.
В контроллерах Siemens используют так называемые Data Blocks (DB), в которых хранятся параметры:
DBW — слово (2 байта);
DBX — отдельный бит;
Мы использовали специальный сканер, чтобы определить активные БД. В итоге нашли участки памяти, которые отвечают за скорость конвейера.
Параметры меняли самописным скриптом, который общается с PLC по протоколу S7.
По заданию нужно было увеличить скорость конвейера подачи руды. Для этого мы изменили значение в соответствующем блоке данных (Data Block):
Значение 32767 — максимум для этого параметра, и оно резко ускорило работу оборудования.
После изменений система заметила аномалию: конвейер разогнался до недопустимой скорости, из‑за чего случилась авария и производство встало.
Так мы смоделировали критический инцидент — каскадный простой производства.
Этот кейс показывает, как компрометация IT-инфраструктуры бьет по технологическим процессам и приводит к реальным сбоям на производстве
Сбой в работе доменной печи
Закрепившись в SCADA-сегменте, мы продолжили работу с технологической сетью. Опираясь на уже найденные узлы, переключились на другой хост в SCADA: 10.154.33.35.
Подключились с помощью уже полученных учетных данных оператора.
После входа в систему нашли новый интерфейс для управления доменной печью.
Интерфейс показывал ключевые параметры техпроцесса: давление, температуру, состояние клапанов и работу вспомогательных систем. Это помогло понять, какие элементы управления можно использовать для атаки.
Как и в предыдущем сценарии, процессом управлял PLC SIMATIC S7-1200, поэтому дальше мы работали напрямую с контроллером.
Чтобы определить, какие области памяти задействованы — Data Blocks, — мы снова воспользовались сканером:
Так удалось локализовать участки памяти, которые отвечают за управление технологическими параметрами печи.
Анализ логики SCADA показал: один из ключевых элементов управления — клапан подачи ресурсов в печь.
Чтобы спровоцировать критическое событие, нужно было нарушить штатный режим работы. Сделать это можно было, изменив нужный параметр в ПЛК.
Мы поменяли значение DBW18 = 512 .
Этот параметр управлял состоянием клапана. После смены значения клапан закрылся, и технологический процесс пошел с нарушениями.
Из‑за наших действий система заметила отклонение от нормальной работы, и доменная печь дала сбой.
В итоге мы успешно реализовали критическое событие — «Сбой в работе доменной печи» .
Когда мы копнули логику контроллера глубже, наше внимание привлекла система Water Pumps — она охлаждает оборудование и помогает ему работать стабильно.
Манипуляции с этой системой могли привести к еще более серьезным последствиям — вплоть до перегрева и аварийных ситуаций.
Тем же способом — определив DB и изменив параметры, — мы смогли вызвать еще одно критическое событие, на этот раз затронув систему водяных насосов.
Взрыв из-за критической концентрации взрывчатых веществ в воздухе
После успешной атаки на технологические процессы доменной печи мы продолжили работу с тем же SCADA-узлом 10.154.33.35.
К этому моменту мы уже закрепились в системе и разобрались, как работает PLC. Теперь можно было перейти к более сложному сценарию — спровоцировать аварию с потенциально разрушительными последствиями.
Разработчики добавили дополнительную защиту: чтобы вызвать критическое событие, нужно было выполнить действия в определенной последовательности.
Сценарий состоял из двух этапов:
Отключение системы контроля.
Изменение параметров техпроцесса: например, открытие клапана.
Пока работала система контроля, изменить параметры не получалось: защитные механизмы автоматически блокировали опасные состояния.
Для первого этапа мы использовали найденные ранее области памяти PLC:
В этих блоках хранились параметры, которые отвечали за состояние системы контроля.
Наш скрипт изменил значение нужного бита:
В результате система контроля отключилась, а защитные ограничения сняли.
После отключения защитных механизмов мы перешли ко второму этапу — прямому воздействию на процесс.
Как и в предыдущем сценарии, клапаном управляли через параметр DBW18 . Мы изменили его значение, открыли клапан и запустили неконтролируемую подачу веществ в систему.
В итоге:
систему контроля отключили;
клапан открыли;
концентрация веществ начала быстро расти.
Ситуация дошла до критической точки: из‑за предельной концентрации взрывоопасных веществ в воздухе произошел взрыв.
Бонус: захват домена
Развивая атаку, мы реализовали еще один сценарий — полный захват домена Active Directory. Для этого мы использовали связку уязвимостей CVE-2021-42278 и CVE-2021-42287, которая эксплуатирует особенности аутентификации Kerberos.
Суть уязвимостей
CVE-2021-42278 (Name Impersonation) связана с некорректной обработкой атрибута sAMAccountName в Active Directory.
Обычно:
учетные записи компьютеров оканчиваются символом —например , D C — например, DC — например , D C ;
контроллер домена по этому признаку отличает их от других типов учетных записей.
Но из‑за слабой валидации злоумышленник может:
переименовать учетную запись;
убрать символ $;
сделать так, чтобы учетная запись выглядела как контроллер домена.
CVE-2021-42287 — уязвимость в Kerberos KDC (Key Distribution Center), из‑за которой он некорректно обрабатывает запросы на выдачу тикетов.
Вместе эти уязвимости позволяют:
получить TGT (Ticket Granting Ticket) от имени контроллера домена;
выдать себя за любого пользователя;
добраться до прав вплоть до Domain Admin .
Эксплуатация уязвимости
Для атаки мы взяли уже скомпрометированную учетную запись x. stf/ s_marshall_admin — на практике подойдет любая учетка с нужными правами.
Дальше выполнили такой скрипт:
Этот скрипт проводит атаку на Kerberos и использует несколько ключевых параметров:
-dc-host DC. x. stf — контроллер домена;
-spn cifs/ dc. x. stf — сервис, для которого запрашивается Kerberos-тикет;
-impersonate administrator — пользователь, от имени которого выполняется impersonation;
x. stf/ s_marshall_admin — учетная запись, с которой запускается атака;
-hashes — NTLM-хеш вместо пароля для Pass-the-Hash.
После запуска скрипта:
Манипуляция именем учетной записи (CVE-2021-42278).
Получение Kerberos-тикета с повышенными привилегиями (CVE-2021-42287).
Создание TGT от имени администратора домена.
Используем полученный TGT
После успешной эксплуатации мы получили Kerberos-тикет и использовали его для дальнейшей аутентификации.
Для этого мы сохранили его в переменной окружения:
Дальше подключились к хосту через него:
Мы получили доступ к домену с правами администратора.
В итоге этот сценарий помог нам скомпрометировать аутентификацию Kerberos, выдать себя за администратора домена и получить полный контроль над Active Directory.
Отборочные на Standoff 17 получились для нас насыщенными: за неделю мы прошли путь от внешней разведки и первых точек входа до компрометации внутренних систем, бизнес‑сервисов и SCADA-сегмента. По ходу атаки использовали мисконфиги, эксплуатацию уязвимостей, фишинг, постэксплуатацию, боковое перемещение и работу с SCCM и PLC.
Почти в каждом сценарии нужно было не просто найти уязвимость, а выстроить полную цепочку атаки: закрепиться, развить доступ, разобраться в архитектуре и довести атаку до критического события. Для нас это был еще и хороший тест командной работы: подготовки, координации и собственных инструментов, которые реально помогли в боевых условиях.
В этой статье мы рассмотрим основные приемы работы с каналами в Go и познакомимся с приема…