В первой части нашего материала мы представили алгоритмы решения двух страшно интересных заданий. С наступлением темноты разбираем еще три жуткие задачи.
«В темноте», «Профиль безопасности», «СОКобан», так же как «Копай глубже» и «Пропавший мастер», могли бы стать отличными названиями фильмов ужасов, но команда главного онлайн-кэмпа по практической кибербезопасности 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 баллов.
ссылка на оригинал статьи https://habr.com/ru/articles/863380/
Добавить комментарий