В темной-темной комнате… Разбираем самые страшные задания киберучений CyberCamp 2024. Часть II
В первой части нашего материала мы представили алгоритмы решения двух страшно интересных заданий. С наступлением темноты разбираем еще три жуткие задачи.
«В темноте», «Профиль безопасности», «СОКобан», так же как «Копай глубже» и «Пропавший мастер», могли бы стать отличными названиями фильмов ужасов, но команда главного онлайн-кэмпа по практической кибербезопасности CyberCamp 2024 была быстрее и использовала их для своих заданий. На этот раз пытаемся выяснить причину отключения света в целом районе, сконфигурировать профиль защиты IPS, разгрести завалы из событий в SIEM и прочее.
«В темноте»
Задание от «АйТи Бастион»
Количество баллов: 220
Фракция: Blue Team
Время на выполнение: 80 минут
Что случилось?
Что делать?
Разберитесь в причинах произошедшего инцидента и ответьте на вопросы, используя доступные средства защиты информации и накопленные в них данные:.
• СКДПУ НТ «Шлюз доступа» и «Модуль поведенческого анализа», обеспечивающие контроль удаленного доступа к АРМ Оператора АСУТП и выявление аномалий;
• Kaspersky Industrial CyberSecurity for Networks (KICS for Networks), обеспечивающее фиксацию подозрительного поведения в промышленной сети.
Действуем!
Определим IP-адрес устройства злоумышленника, с которого было выполнено несанкционированное подключение к АРМ Оператора АСУТП.
Необходимо обратить внимание на инциденты, зарегистрированные в СКДПУ НТ «Модуль поведенческого анализа». В перечне инцидентов присутствовало большое количество попыток подключения к АРМ Оператора АСУТП напрямую (Прямой логин / Direct_Login), в обход СКДПУ НТ «Шлюз доступа»:
При детальном изучении зарегистрированных инцидентов можно обнаружить IP-адрес устройства злоумышленника, с которого выполнялись подключения к АРМ Оператора АСУТП напрямую. А поле dst_ip_port указывало на, то что злоумышленник использовал для подключения к АРМ Оператора протокол удаленного доступа (RDP):
В этом также можно было убедиться, изучив сработки IDS-правил в KICS for Networks:
Если выполнить фильтрацию событий по подозрительному IP-адресу (в нашем случае это 10.31.117.139), мы также найдем признаки появления в промышленной сети нового устройства и последовавшего за ним сканирования промышленной сети:
Таким образом, мы убедились в том, что источником нелегитимной активности в промышленной сети является устройство с IP-адресом 10.31.117.139.
Укажем точное время появления устройства злоумышленника в промышленной сети.
Перейдем в KICS for Networks в раздел «Активы» и найдем там устройство с обнаруженным ранее IP-адресом злоумышленника. При детальном изучении карточки актива видны данные о первом его появлении в промышленной сети (26.09.2024 11:15:56).
Определим метод получения злоумышленником пароля от АРМ Оператора.
Можно пойти двумя путями.
Первый — с использованием СКДПУ НТ «Модуль поведенческого анализа». Ранее при нахождении ответа на первый вопрос среди зарегистрированных инцидентов попыток подключения к АРМ Оператора АСУТП в обход СКДПУ НТ «Шлюз доступа» можно было обнаружить инцидент (Инцидент DL-1000197) по сработавшему правилу Signs of a brute-force password attack on RDP.
Второй — с использованием KICS for Networks. Изучив в KICS for Networks активность, связанную с IP-адресом устройства злоумышленника, можно обнаружить зарегистрированное событие Rule from the bruteforce (system rule set) was triggered для запросов в сторону АРМ Оператора (SCADA Redkit Server).
Оба пути приводят к верному ответу — злоумышленник использовал BruteForce.
Определим, по каким промышленным протоколам осуществляется обмен данными между АРМ Оператора и PLC.
В KICS for Networks необходимо перейти в раздел «Карта сетевых взаимодействий» и ознакомиться с информацией об используемых протоколах взаимодействия между АРМ Оператора (SCADA Redkit Server) и PLC (SIMATIC S7–1200):
Верный ответ: Modbus TCP; Siemens S7common-plus; PROFINET.
В результате атаки злоумышленник сменил пароль доступа к АРМ Оператора для затруднения восстановления. Определим точное время, когда удалось сбросить пароль и вернуть контроль над АРМ Оператора с помощью СКДПУ.
Изучим историю смены пароля учетной записи оператора АСУТП в СКДПУ НТ «Шлюз доступа» и найдем событие легитимного сброса пароля от конечной системы. Точное время: 26.09.2024 11:31:10.
Определим тип злонамеренного вмешательства в технологический процесс.
Поскольку злоумышленнику удалось добраться до АРМ Оператора, минуя PAM, для поиска ответа будем пользоваться KICS for Networks. На СКДПУ мы видим, что в 11:20 нет активных сеансов легитимного управления PLC, однако в KICS зафиксирована передача команд от АРМ Оператора в сторону контроллера:
Последствия внесенных злоумышленником изменений в конфигурацию PLC команды могли заметить в СКДПУ НТ «Шлюз доступа» в записи легитимной сессии удаленного доступа к АРМ Оператора:
Определим точное время прогрузки PLC.
Под прогрузкой PLC понимается время заливки в контроллер новой программы управления. Такое событие можно найти в KICS for Networks среди зарегистрированных: Suspicious active (MITRE: Program Upload). Время регистрации (11:19:31) найденного события и есть верный ответ.
8. Определим, какой блок c данными PLC был изменен.
Следом за загрузкой новой программы управления в PLC мы видим алерт об изменении Memory Block: INSERT NEW PLC MEMORY Block command detected. Событие высокого уровня критичности, заглянем внутрь. Здесь мы и находим ответ на заключительный вопрос сценария:
Что это было?
В результате расследования инцидента мы восстановили полную цепочку атаки на промышленную сеть. Злоумышленник, проникнув на территорию объекта поставщика электроэнергии, подключился к промышленной сети для сканирования ее на наличие активных устройств. Обнаружив активное устройство (АРМ Оператора) с открытым портом удаленного доступа (RDP), злоумышленник методом brute force выполнил подбор пароля учетной записи для доступа к АРМ Оператора. Получив удаленный доступ к АРМ Оператора и проанализировав конфигурацию PLC, злоумышленник внес в нее деструктивные изменения и загрузил в контроллер. Злоумышленник сменил пароль от учетной записи оператора с целью затруднения устранения последствий атаки.
Максимальное количество баллов за это задание получили четыре команды: EXE1sior из студенческой лиги и «ГИД», Dream_SOC, FYI — из корпоративной.
«Профиль безопасности»
Задание от «Код Безопасности»
Количество баллов: 220
Фракция: Yellow Team
Время на выполнение: 60 минут
Что случилось?
Что делать?
Изучите «модель угроз» для защищаемой инфраструктуры и настройте релевантный ей профиль защиты детектора атак «Континент 4» на своем шлюзе безопасности. В распоряжении каждой команды имеется выделенный экземпляр детектора атак.
Действуем!
Перед настройкой самого профиля СОВ приведем в порядок переменные, используемые при работе сигнатур.
Большинство команд правильно указали защищаемую сеть HOME_NET, за что получили 10 баллов. Однако здесь была возможность заработать дополнительные 10 баллов, если заметить, что в HTTP-портах пропущен 80-й, и вернуть его на законное место (Переменная HTTP_PORTS).
Изучим описание атак, от которых необходимо выстроить защиту путем выбора корректных сигнатур.
Участники удивлялись, зачем выбирать только 20 сигнатур, ведь можно выбрать все. Однако суть задания была именно в осознанном выборе правил в соответствии с защищаемой инфраструктурой — зачастую такой подход позволяет снизить нагрузку на устройство за счет освобождения его оперативной памяти от лишних сигнатур.
Инфраструктурная часть «Модели угроз» выглядела так:
В первом блоке, касающемся защиты инфраструктурных сервисов, речь идет о нескольких популярных уязвимостях высокого уровня опасности.
Уязвимость в RDS под названием BlueKeep, подробнее о которой можно почитать здесь. Выбираем соответствующую ей сигнатуру в базе решающих правил (БРП):
RCE-уязвимость в Exchange Control Panel. Найти ее несложно, ее идентификатор CVE-2020–0688, по нему и добавляем сигнатуру из БРП:
Уязвимость в популярном плагине для WordPress под названием Bricks Builder. Уязвимость была опубликована 16.02.2024 и актуальна до версии 1.9.6. Найдем нужные сигнатуры по CVE и добавим их в наш профиль защиты:
Далее следует дополнительная часть «модели угроз»:
Распознаем вредоносы и добавим правила их блокировки в создаваемый профиль.
Под «издателем RE» скрыта серия компьютерных игр Resident Evil, издателем которой является японская компания Capcom. Ее активы были зашифрованы вредоносом Ragnar Locker, добавляем его в профиль:
Второй тип Ransomware найти несложно — на вход выдавался хэш. Поиск по нему в общедоступных базах, например VT, выводит на шифровальщик Exorcist. Ищем и добавляем соответствующие сигнатуры:
Необходимо распознать атаку, совершенную в октябре 2023 года на компанию Boeing. Злоумышленники использовали LockBit и требовали выкуп в размере $200 млн. Выберем соответствующие сигнатуры:
У нас остались два пункта «модели угроз», перейдем к ним. Под популярным лоадером, использующим автоматизатор Autoit для выполнения зловредных действий, скрывается ВПО Dark Gate. Почитать подробный его разбор можно в этой статье. Для выявления Dark Gate в базе имеется довольно много сигнатур, нас интересует лишь одна (о чем указано в задании) — она выделена на скриншоте:
В заключительном пункте обнаружим отсылку к другому заданию CyberCamp 2024 — «Игра TI-аналитика». В нем плотно изучали стилер Lumma, собирая о нем информацию во всех доступных источниках. Здесь можно получить дополнительные баллы, если ранее удавалось верно определить актуальный для зловреда С2.
Определялся он следующим образом.
• По хэшу выходим на tria.ge, где среди различных индикаторов находим ссылку на профиль steam, являющийся оригинальным способом передачи вредоносом информации о текущем активном домене:
Имя домена постоянно меняется и в текущий момент выглядит так:
• Значение кодируется алгоритмом Цезаря, что по итогам обратного преобразования дает нам значение:
Далее на основе полученного домена создаем собственную сигнатуру. Делается это в два шага:
— находим имеющуюся в базе сигнатуру для детектирования обращения к C2 Lumma Stealer, например эту:
— создаем на ее основе собственную, меняя значение content на добытое ранее:
Добавляем ее в профиль блокировки, за что получаем 20 дополнительных баллов.
Что это было?
Таким образом, мы изучили «модель угроз» для защищаемой инфраструктуры и настроили релевантный ей профиль защиты детектора атак «Континент 4» на своем шлюзе безопасности.
Результирующий профиль безопасности выглядит так:
Он включает 19 сигнатур — 18 штук по 10 баллов за каждую и одну кастомную за 20 баллов. Один слот в профиле оставался резервным, на случай, если команда случайно «зацепит» лишнюю сигнатуру.
По условиям задания, выбранные в профиле сигнатуры обязательно должны были быть переведены в режим «Блокировать» (см. рисунок выше), иначе весь труд умножался на ноль. Командам, успешно собравшим профиль защиты из необходимых сигнатур, но не сменившим действие по ним на блокировку, начисляли 0 баллов, поскольку такой профиль безопасности оказывался бесполезным и от атак не защищал. Важно отметить, что далеко не все команды были на входе знакомы с интерфейсом решения, однако, проявив пытливость, смогли легко найти документацию и видеогайд по настройке детектора атак «Континент 4» и получить высокий результат.
В этом задании максимальное количество баллов не набрал никто, но ближе всех были команды из корпоративной лиги CITRUS и «дядя_Серёжа» — у них по 200 баллов из 220 возможных.
«СОКобан»
Задание от R-Vision
Количество баллов: 240
Фракция: Yellow Team
Время на выполнение: 60 мин
Что случилось?
Что делать?
Помните игру Sokoban, двухмерную компьютерную игру-головоломку, в которой игроку необходимо расставить ящики по обозначенным местам лабиринта? Это аналогичное задание — ононацелено на получение инженерного опыта настройки средства защиты. Нужно разгрести завалы из событий в R-Vision SIEM, построить свой конвейер обработки данных и навести порядок в системе.
Конвейер обработки событий
Конвейер обработки событий — компонент коллектора, представляющий собой упорядоченную последовательность взаимосвязанных элементов, выполняющих различные этапы обработки событий. В процессе работы конвейера происходит прием событий, их нормализация, перенаправление, обогащение данными, фильтрация, агрегация, корреляционный анализ и отправка как отдельных, так и сгруппированных или коррелированных событий для хранения и/или передачи во внешние системы.
Действуем!
Чтобы SIEM-система могла эффективно собирать, анализировать и интерпретировать события из различных источников, а также для того, чтобы эта информация была представлена в стандартизированном и понятном формате, существует важный процесс — нормализация. Нормализация приводит данные, называемые событиями, из различных источников к единой структуре путем извлечения (парсинг) и распределения важных значений атрибутов события в унифицированный набор полей, что позволяет SIEM-системе и ее пользователям работать с ними независимо от их источника исходных данных.
Парсинг
Парсинг (или синтаксический разбор) — это процесс извлечения ключевой информации (полей) из сырых логов, которые поступают в SIEM-систему. Логи могут поступать из различных источников: сетевых устройств (например, межсетевых экранов, маршрутизаторов), операционных систем, серверов, приложений, систем безопасности и т.д. Форматы логов могут сильно отличаться в зависимости от производителя и типа устройства, поэтому SIEM-системе необходимо «разобрать» эти логи, чтобы извлечь из них значимую информацию.
Нормализация
Нормализация — это процесс приведения данных к единому стандарту или формату, который используется SIEM-системой для обработки и анализа. Поскольку логи могут поступать из разных источников и иметь различные форматы, нормализация помогает унифицировать информацию и сделать ее пригодной для сопоставления и корреляции.
После того как данные были распарсены, их необходимо нормализовать, чтобы привести к общему стандарту. Это важно, потому что разные устройства могут по-разному называть одни и те же параметры.
Специфика внедрения SIEM-решений такова, что «из коробки» не все события от поддерживаемых источников хорошо парсятся и нормализуются, а для неподдерживаемых решений нужно писать свой пользовательский парсер.
В задании в R-Vision SIEM поступают события от пяти источников: VMware vCenter, Cisco ASA, Checkpoint, PTAF, Confluence. Часть событий некорректно нормализовались после базового подключения источников. Приведем несколько примеров некорректной работы с событиями.
В событиях от VMware vCenter нормализовались не все значения. Нужно было достать недостающие атрибуты: пользователя в поле suser, домен в поле sntdom, время в поле rt в формате »%Y --%m dT%H:%M:%S%, адрес устройства в поле shost. В некоторых событиях от Cisco ASA не хватало нормализации полей, нужно было добавить пользователя в поле suser, IP-адрес в поле src и преобразовать его к типу IPv6. В нормализованном событии от PTAF есть поле deviceProcessName, которое содержит лишнюю информацию:» Send to syslog, Block, Log to db ». Нужно оставить в deviceProcessName только второе значение после запятой, исходную строку нужно разместить в поле cs5, а также заполнить поле cs5Label=«Actions».
Отличительная особенность решения в том, что оно использует графический конструктор, который систематизирует поступившую информацию и направляет ее на хранение или дальнейший анализ. Совокупность визуализации и языка VRL (Vector Remap Language — это язык на основе выражений, разработанный для безопасной и эффективной работы с данными наблюдения, такими как журналы и метрики) дает возможность легко обрабатывать события и управлять ими в зависимости от решаемых задач.
В этом конструкторе нужно было построить цепочку передачи событий от источника данных в область их хранения, добавить фильтры для каждого источника и VRL-трансформацию. Фильтр на входе принимает событие, проверяет его по условию фильтрации и направляет на выход только в том случае, если условие выполняется. В противном случае событие отсеивается и не участвует в дальнейшей обработке, что позволяет оптимизировать утилизацию аппаратных ресурсов, например хранилища событий. VRL-трансформация на входе принимает события и проводит их преобразование, на выходе выдает преобразованные события.
VRL-трансформация позволяет задать простые правила преобразования событий на языке VRL без предварительного создания правил нормализации и привязки к ним. VRL-трансформация удобна в тех случаях, когда требуется провести несложные модификации в структуре событий: например, использовать одну или несколько функций для упрощения дальнейшей работы с событиями или добавить/изменить/удалить какое-нибудь поле в структуре событий.
На рисунке ниже видно, как просто настроить разбиение события на несколько и их размещение в нужные поля. При этом не требуется корректировка самих файлов нормализации:
С помощью функционала VRL-песочница можно в несколько кликов проверить созданный код на реальных данных, это позволит понять, насколько корректно был разработан код для нормализации, и применять уже гарантированно корректный:
После произведенных настроек события корректно нормализуются:
Что это было?
В результате выполнения задания мы повысили информативность событий, поступающих в SIEM. В реальной жизни это позволит сократить время поиска необходимых событий и упростит создание правил корреляции для своевременного выявления инцидентов.
Правила корреляции
Правила корреляции — это наборы условий и логик, которые позволяют анализировать события из множества источников и выявлять потенциальные угрозы безопасности на основе взаимосвязи этих событий.
Команда K0TN, которая заняла второе место в студенческой лиге на CyberCamp 2024, полностью выполнила это задание, заработав 240 баллов.