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

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

«В темноте»

Задание от «АйТи Бастион»

Количество баллов: 220

Фракция: Blue Team

Время на выполнение: 80 минут

Что случилось?

Что делать?

Разберитесь в причинах произошедшего инцидента и ответьте на вопросы, используя доступные средства защиты информации и накопленные в них данные:.
• СКДПУ НТ «Шлюз доступа» и «Модуль поведенческого анализа», обеспечивающие контроль удаленного доступа к АРМ Оператора АСУТП и выявление аномалий;
• Kaspersky Industrial CyberSecurity for Networks (KICS for Networks), обеспечивающее фиксацию подозрительного поведения в промышленной сети.

Действуем!

1. Определим IP-адрес устройства злоумышленника, с которого было выполнено несанкционированное подключение к АРМ Оператора АСУТП.

   Необходимо обратить внимание на инциденты, зарегистрированные в СКДПУ НТ «Модуль поведенческого анализа». В перечне инцидентов присутствовало большое количество попыток подключения к АРМ Оператора АСУТП напрямую (Прямой логин / Direct_Login), в обход СКДПУ НТ «Шлюз доступа»:

   

   При детальном изучении зарегистрированных инцидентов можно обнаружить IP-адрес устройства злоумышленника, с которого выполнялись подключения к АРМ Оператора АСУТП напрямую. А поле dst_ip_port указывало на, то что злоумышленник использовал для подключения к АРМ Оператора протокол удаленного доступа (RDP):

   

   В этом также можно было убедиться, изучив сработки IDS-правил в KICS for Networks:

   

   Если выполнить фильтрацию событий по подозрительному IP-адресу (в нашем случае это 10.31.117.139), мы также найдем признаки появления в промышленной сети нового устройства и последовавшего за ним сканирования промышленной сети:

   

   Таким образом, мы убедились в том, что источником нелегитимной активности в промышленной сети является устройство с IP-адресом 10.31.117.139.

2. Укажем точное время появления устройства злоумышленника в промышленной сети.

   Перейдем в KICS for Networks в раздел «Активы» и найдем там устройство с обнаруженным ранее IP-адресом злоумышленника. При детальном изучении карточки актива видны данные о первом его появлении в промышленной сети (26.09.2024 11:15:56).

   

3. Определим метод получения злоумышленником пароля от АРМ Оператора.

   Можно пойти двумя путями.

   Первый — с использованием СКДПУ НТ «Модуль поведенческого анализа». Ранее при нахождении ответа на первый вопрос среди зарегистрированных инцидентов попыток подключения к АРМ Оператора АСУТП в обход СКДПУ НТ «Шлюз доступа» можно было обнаружить инцидент (Инцидент 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.

4. Определим, по каким промышленным протоколам осуществляется обмен данными между АРМ Оператора и PLC.

   В KICS for Networks необходимо перейти в раздел «Карта сетевых взаимодействий» и ознакомиться с информацией об используемых протоколах взаимодействия между АРМ Оператора (SCADA Redkit Server) и PLC (SIMATIC S7-1200):

   

   Верный ответ: Modbus TCP; Siemens S7common-plus; PROFINET.

5. В результате атаки злоумышленник сменил пароль доступа к АРМ Оператора для затруднения восстановления. Определим точное время, когда удалось сбросить пароль и вернуть контроль над АРМ Оператора с помощью СКДПУ.

   Изучим историю смены пароля учетной записи оператора АСУТП в СКДПУ НТ «Шлюз доступа» и найдем событие легитимного сброса пароля от конечной системы. Точное время: 26.09.2024 11:31:10.

   

6. Определим тип злонамеренного вмешательства в технологический процесс.

   Поскольку злоумышленнику удалось добраться до АРМ Оператора, минуя PAM, для поиска ответа будем пользоваться KICS for Networks. На СКДПУ мы видим, что в 11:20 нет активных сеансов легитимного управления PLC, однако в KICS зафиксирована передача команд от АРМ Оператора в сторону контроллера:

   

   Последствия внесенных злоумышленником изменений в конфигурацию PLC команды могли заметить в СКДПУ НТ «Шлюз доступа» в записи легитимной сессии удаленного доступа к АРМ Оператора:

   

7. Определим точное время прогрузки 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» на своем шлюзе безопасности. В распоряжении каждой команды имеется выделенный экземпляр детектора атак.

Действуем!

1. Перед настройкой самого профиля СОВ приведем в порядок переменные, используемые при работе сигнатур.

   Большинство команд правильно указали защищаемую сеть HOME_NET, за что получили 10 баллов. Однако здесь была возможность заработать дополнительные 10 баллов, если заметить, что в HTTP-портах пропущен 80-й, и вернуть его на законное место (Переменная HTTP_PORTS).

   

2. Изучим описание атак, от которых необходимо выстроить защиту путем выбора корректных сигнатур.

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

   Инфраструктурная часть «Модели угроз» выглядела так: 

   

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

   Уязвимость в RDS под названием BlueKeep, подробнее о которой можно почитать здесь. Выбираем соответствующую ей сигнатуру в базе решающих правил (БРП):

   

   RCE-уязвимость в Exchange Control Panel. Найти ее несложно, ее идентификатор CVE-2020-0688, по нему и добавляем сигнатуру из БРП:

   

   Уязвимость в популярном плагине для WordPress под названием Bricks Builder. Уязвимость была опубликована 16.02.2024 и актуальна до версии 1.9.6. Найдем нужные сигнатуры по CVE и добавим их в наш профиль защиты:

   

   Далее следует дополнительная часть «модели угроз»:

   

3. Распознаем вредоносы и добавим правила их блокировки в создаваемый профиль.

   Под «издателем RE» скрыта серия компьютерных игр Resident Evil, издателем которой является японская компания Capcom. Ее активы были зашифрованы вредоносом Ragnar Locker, добавляем его в профиль:

   

   Второй тип Ransomware найти несложно — на вход выдавался хэш. Поиск по нему в общедоступных базах, например VT, выводит на шифровальщик Exorcist. Ищем и добавляем соответствующие сигнатуры:

   

   Необходимо распознать атаку, совершенную в октябре 2023 года на компанию Boeing. Злоумышленники использовали LockBit и требовали выкуп в размере $200 млн. Выберем соответствующие сигнатуры:

   

   У нас остались два пункта «модели угроз», перейдем к ним. Под популярным лоадером, использующим автоматизатор Autoit для выполнения зловредных действий, скрывается ВПО Dark Gate. Почитать подробный его разбор можно в этой статье. Для выявления Dark Gate в базе имеется довольно много сигнатур, нас интересует лишь одна (о чем указано в задании) — она выделена на скриншоте:

   

4. В заключительном пункте обнаружим отсылку к другому заданию 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-решений такова, что «из коробки» не все события от поддерживаемых источников хорошо парсятся и нормализуются, а для неподдерживаемых решений нужно писать свой пользовательский парсер.

В задании в 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 баллов.