Как вырастить эффективную blue team? Наш опыт показывает, что для этого нужны три составляющие:
- Проверка базовых знаний в части ИТ и ИБ.
- Обучение по специальности с акцентом на практику и лабораторные работы.
- Оттачивание навыков на киберполигонах (с применением реальных данных о действиях хакеров).
Если с проверкой «базы» все понятно, то второй и третий пункты вызывают вопросы. Где взять материалы для практических заданий, да еще и не абстрактные примеры, а основанные на реальных атаках? Новичков на киберучения не отправишь: они рассчитаны на уже подготовленные команды и помогают оттачивать навыки в критических ситуациях. Для решения этой задачи мы разработали Standoff Cyberbones.
Что такое Standoff Cyberbones
Это онлайн-симулятор для практической подготовки ИБ-специалистов. Задания в нем формируются на основе реальных кейсов, собранных по итогам кибербитв Standoff.
Standoff Cyberbones в первую очередь нацелен на развитие практических навыков ИБ-специалистов. Задания в симуляторе группируются в соответствии с MITRE ATT&CK и сопровождаются кратким описанием задействованных объектов отраслевой инфраструктуры. Для создания заданий мы используем данные мониторинга, которые снимаем с СЗИ во время кибербитвы (SIEM, NTA, WAF, Sandbox и т. д.).
На данный момент в симуляторе представлены задания двух типов:
- Атомарный ИБ-инцидент. Здесь необходимо искать индикаторы компрометации. К примеру, название и FQDN хоста либо хеш файла, или же данные пользователя, который запустил вредоносный файл.
- Критическое событие представляет из себя набор атомарных инцидентов, которые реализовал злоумышленник в конкретной инфраструктуре. Для решения задания необходимо восстановить цепочку атаки и подготовить отчет по итогам расследования. Так через боль и страдания и формируются необходимые компетенции :)
Примеры заданий Standoff Cyberbones
Атомарный инцидент ИБ
Рассмотрим несколько примеров заданий по поиску атомарных инцидентов.
Пример 1: wtf.exe
В этом случае атакующие загрузили на один из узлов инфраструктуры файл wtf.exe. Необходимо обнаружить FQDN узла, на который был загружен файл. При этом известно, что временной интервал инцидента — с 10:00 22 ноября 2022 г. по 18:00 24 ноября 2022 г.
Задачу можно решить с использованием SIEM. Для начала выставим корректное время для поиска.
Далее нам необходимо узнать поле нормализации, по которому будет проще всего обнаружить первые упоминания файла wtf.exe в инфраструктуре. Это object.name. Проведем поиск по этому имени и применим сортировку по времени от старых событий к новым.
Первая сработка — событие с PT NAD, который тоже обнаружил данный файл. Сразу после него идет событие с comp-0660.city.stf — это и будет искомый FQDN. Заносим ответ в платформу — задание выполнено!
Пример 2: поиск вредоносного файла
В этом задании необходимо указать FQDN рабочей станции, на которой пользователь d_jensen запустил вредоносный файл, поступивший ему на почту. Есть информация, что событие произошло 23 ноября 2022 г.
Поскольку в этом примере расследуется фишинг и дана учетная запись виновника инцидента, необходимо подготовить фильтр для поиска действий учетной записи: subject.account.name = "d_jensen".
Самый простой способ понять, на каком хосте пользователь запускал файл, — посмотреть количество логов, в которых задействована его учетная запись. Для этого можно воспользоваться оператором группировки по event_src.host.
Отметим, что этот способ не всегда точно указывает на нужный ПК. Для точного определения, на какой машине пользователь запускал хоть какие-то процессы, необходимо дополнить фильтр: (subject.account.name = "d_jensen") AND (action = "start") AND (object = "process"). Это позволит найти все события запуска процессов от имени указанной учетной записи.
Теперь в группировке по хостам отображается только один актив, который и будет ответом к задаче.
Критическое событие
Рассмотрим пример задания по расследованию критического события. Для его выполнения необходимо расследовать киллчейн и затем заполнить отчет (с разбивкой всей цепочки событий на отдельные шаги).
Начнем с самого факта реализации критического события и разберем цепочку действий хакеров в обратном порядке.
Шаг 1. Реализация критического события
Злоумышленники получили доступ к файлу resfin.docx с хоста esoto.uf.city.stf через учетную запись пользователя r_hewwit_admin.
Задаем себе вопрос: как учетка r_hewitt_admin попала на хост? Точкой подключения является именно она, а не пользователь на хосте esoto (связанные с ним события не подходят, потому что они вызваны чекером).
Процесс winword.exe говорит о том, что пользователь открыл указанный в cmdline файл. Его название отображено в конце строки — resfin.docx.
Шаг 2. Получение доступа через RDP-сессию
Хакеры создали RDP-сессию от пользователя r_hewwit_admin на конечный хост esoto.uf.city.stf. По времени действия сессия совпадет с реализацией критического события.
Вопрос: откуда атакующие взяли учетные данные r_hewwit_admin, чтобы подключиться?
Шаг 3. Исследование процесса rr2.exe
Атакующие запустили cmd.exe от процесса rr2.exe с повышенными привилегиями.
3.1. Запуск cmd.exe, порожденного подозрительным процессом
Мы видим процесс rr2.exe, который не похож на системные процессы, а также что пользователь l_mayo не является привилегированным. При этом процесс cmd.exe, запущенный пользователем, обладал правами System. Нужно понять, как хакеры подняли себе привилегии.
3.2. Дамп LSASS
Мы видим событие, связанное с дампом и получением учетки r_hewitt_admin (делаем вывод о способе ее получения). Для этого нужны системные права: как хакеры их получили?
Дамп LSASS был получен при помощи той же подозрительной утилиты rr2.exe. Можно посмотреть, что еще она породила и как появилась.
3.3. Закачка подозрительного файла rr2.exe
В поле cmdline видим команду, с помощью которой атакующие выкачивают файл через wget и называют его rr2.exe. Адрес, с которого выкачивается файл, довольно подозрителен, что указывает на вероятную вредоносность rr2.exe.
Мы знаем, что с помощью утилиты rr2.exe злоумышленники загрузили дамп, однако нам все еще нужно найти событие, подтверждающее повышение привилегий. Дамп можно получить, обладая System-правами.
3.4. Порождение процессом rr2.exe файла chisel.exe
Видим еще одно доказательство вредоносности закачанного rr2.exe: атакующие создали файл chisel.exe, который можно использовать для построения туннеля.
3.5. Дополнительные команды
Мы можем найти всю цепочку команд злоумышленников: отображение списка файлов и подкаталогов каталога (через dir), а также управление запланированной задачей и запуск экзешника.
3.6. Повышение привилегий
Злоумышленники локально повысили себе права с помощью техники Named Pipe Impersonation.
Гуглим название техники и выясняем: аналогичная техника используется в Meterpreter для повышения прав с помощью getsystem.
3.7. Запуск rr2.exe
Изучаем процесс, порождающий создание файла rr2.exe на узле. Событие было сгенерировано после закачки этого файла на хост.
Шаг 4. Обнаружение фишинга
Через процесс winword.exe фиксируем открытие файла с именем cv_resume_1. Выполнение этого действия гарантирует, что злоумышленники получат оболочку, если в документе есть макросы.
С помощью песочницы ищем письмо с таким названием и обнаруживаем учетку, с которой было отправлено сообщение: rudnic@city.stf.
Перед нами вредоносное вложение: когда пользователь его открыл, злоумышленники получили доступ к хосту l_mayo.city.stf. Задача решена!
