Привет, меня зовут Антон Калинин, я руководитель группы аналитиков центра мониторинга информационной безопасности и реагирования на компьютерные инциденты CyberART, ГК Innostage. Этой осенью мы принимали участие в киберучениях The Standoff в качестве Blue Team. Для нашего SOC это стало одним из самых интересных событий года, по горячим следам мы уже проделали много чего внутри нашего центра, теперь же хочется делиться опытом с более широкой аудиторией. Кому более комфортно не читать, а смотреть (или слушать), в конце статьи кину ссылку на вебинар на ютубе, который мы провели неделю назад.

«Условия противостояния будут приближены к реальной жизни» — с этих слов началось наше участие в The Standoff в этом году. Под словами «наше» я имею в виду команду нашего центра мониторинга и реагирования на компьютерные инциденты CyberART. И действительно, подготовка к этому мероприятию была максимальна похожа на реалии подключения заказчика на сервис мониторинга (в отличии от основного этапа киберучений) Но давайте об всем по порядку.

Начать надо с того, что участие в The Standoff было для нас неожиданным, и если у остальных команд защитников доступ к полигону появился за 4 недели до начала боевых действий, то у нас было чуть больше 10 дней чтобы подготовиться. С одной стороны это архисложная задача, с другой стороны — война есть война — о нападении никогда не предупреждают, поэтому это задача потребовала от нас максимальной концентрации с первого же дня. В этих условиях основной нашей задачей было быстро понять, что за объект мы контролируем, т.е. провести инвентаризацию активов, анализ защищенности, навести максимально порядок в инфраструктуре в части закрытия явных брешей безопасности или нивелировать эти угрозы средствами защиты, а вот остаток времени выделить на адаптацию нашего контента сценариев мониторинга для выявления возможных инцидентов. В идеальной картине мира план был за день до начала битвы быть в состоянии максимальной боевой готовности. Однако как это обычно бывает, все пошло не совсем по плану.

Объектом защиты нашей команды стала компания, управляющая городским хозяйством: «Парк аттракционов», «Бизнес-центр» и «Сеть управления светофорами» являлись критичными и имели целый ряд бизнес-рисков. Из технических входных данных был предоставлен список подсетей с описанием их ролей, остальное – темный лес.

Для мониторинга и защиты нам был предоставлен следующий набор систем и технологий:
- веб-приложения, расположенные на периметре, были «под присмотром» PT Application Firewall (PT AF);
- анализ сетевого трафика, выявление сетевых атак, аномалий и подозрений можно было выполнять с использованием PT Network Attack Discovery;
- за динамический анализ образцов вредоносного ПО отвечал PT Sandbox;
- также был доступен сканер защищенности MaxPatrol 8;
- ядром SOC выступала система MaxPatrol SIEM
- в качестве межсетевого экрана использовался CheckPoint.

Также для исследования сети мы использовали привнесенные уже нами самими сканеры Nmap и дистрибутив kali linux.

Отмечу, что по правилам киберполигона не допускалось использование антивирусных решений, а модули NGFW и EDR разрешалось использовать только в режиме мониторинга.

Итак, вооружившись этим инструментарием, мы пошли исследовать нашу инфраструктуру. Как Христофор Колумб открывал Америку, так и мы с каждым шагом открывали для себя глубины нашего объекта. На основании первых сканирований наша команда составила схему сети и расположила на ней все найденные активы. 67 хостов было выявлено на нашем объекте. Таблицы маршрутизации в CheckPoint-е подсказали нам, где можно провести большее сегментирование и фильтрацию между сетями.

Далее был долгий и мучительный анализ отчетов от Max Patrol 8. Легенда киберучений подразумевает, что в инфраструктуре присутствуют риски (уязвимости, настройки доступа, особенности конфигурации), которые нельзя исправить и их наличие необходимо учитывать. Однако такого огромного количества рисков мы не предполагали. Кроме того, правила соревнований запрещали обновлять Linux-подобные ОС и бизнес-приложения вендоров, отличных от Microsoft.

Имеющийся в нашей сети WSUS был всего лишь репликой для вышестоящего сервера обновлений без права внесения изменений, поэтому критичные обновления (тот же самый нашумевший MS17-010) мы в итоге бегали обновлять ручками.

Общение с организаторами показало, что по опыту предыдущих лет бывали случаи максимального закрытия защищаемого объекта средствами защиты так, что атакующие просто не могли пробить эту линию обороны, что шло в минус Blue Team, ведь основная задача для них — мониторинг. Поэтому у нашей команды возникали принципиальные вопросы «А вдруг мы сейчас все захардерим, закроем весь веб Web Application Firewall-ом и так нас никто и не пробьет». Как же мы ошибались в тот момент! Однако, заведение всего имеющегося веба на периметре за PT AF, наверное, было одним из лучших наших решений при подготовке к противостоянию.

Организаторы киберучений, выступали для нас также в виде некой роли ИТ-подразделения заказчика. И, как это бывает в реальной практике, когда SOC пытается побольше узнать об инфраструктуре, задавая вопросы ИТ-службе, последняя не всегда раскрывает все тайны. В связи с этим роли некоторых сервисов просто оставались для нас загадкой и поэтому 50% времени было уделено ручному исследованию имеющихся приложений для понимания структуры их работы, наличию ошибок конфигурации и возможных входных векторов компрометации систем.

К концу первых 7 дней, что у нас были на подготовку, мы знали 90% защищаемого объекта. Как в компьютерных стратегиях в тумане войны оставался сегмент СКАДы, так как доступ туда был лишь у организаторов. Они же и рассказали нам, какие хосты и системы там присутствуют и как они работают. Оставалось поверить им на слово и отразить их иконками на нашей глобальной схеме инфраструктуры. Также внутри уже известных сетей были спящие сервисы, которые не были нами замечены и проявили они себя уже только в ходе битвы.

Впереди было подключение оставшихся журналов приложений, ОС и средств защиты в SIEM, адаптация и настройка контента сценариев мониторинга, настройка решающих политик на NGFW, приведение в порядок правил на PT AF, а также попытки ответить на все большее число возникающих вопросов. Как вы понимаете реализовать все это за три дня было практически невозможно, поэтому многое делалось уже на ходу прямо во время соревнований.

На время участия в битве наша команда разделилась на две ГРИИБ (Группы реагирования на инциденты ИБ) по 7 человек в каждой. В каждой присутствовал так называемый капитан группы, который руководил и координировал действия всех член команды, а также 3 аналитика и 3 инженера мониторинга. Группы работали по 24 часа сутки через сутки с изменением смены в 8 часов утра. За день до начала The Standoff группой аналитиков нашего SOC началась тактическая подготовка ведения боя. Мы разработали пошаговый план мониторинга, разделили DMZ-зону на блоки критичности и распределили направления threat hunting. В средствах мониторинга были подготовлены фильтры, отслеживающие необходимые сработки правил по блокам критичности. Реагирование не являлось первоочередной целью для защищающей стороны в ходе кибербитвы, поэтому имело ряд ограничений. Так, например, нельзя было блокировать IP адреса атакующих команды, нельзя закрывать доступы на ресурсы в случае атак или менять код работы приложений, потому что одной из задач защитников являлось сохранение работоспособности сервисов защищаемых объектов как в части доступности целевым пользователям, так и в части сохранения функциональности. Поэтому был составлен список инструментов для возможного реагирования и принято решение динамически противодействовать атакующим уже по ходу пьесы.

Опыт участия в подобных мероприятиях был для нас новым, поэтому было изначально выдвинуто два предположения по началу атак. Первое – мягкая распределенная разведка и подготовка к наступлению, второе – шквал огня с использованием всего возможного арсенала Red Team.

Именно второй вариант и реализовался. Атакующие пошли в бой с первых минут противостояния и сохраняли натиск на протяжении всего соревнования. Благо в первые часы почти 100 процентов попыток сканирования и атак были задетектированы и заблокированы PT AF. Помните, я говорил, что заведение за PT AF всего было отличным решением? Так вот это правда Блицкриг не удался, поэтому до вечера первого дня атакующие, изучив доступные извне сервисы, стали искать более тонкие способы атак. В нашем случае самым лакомым куском для Red Team был сайт городского портала. На нем возможно было осуществить сбой продажи билетов в парк аттракционов, а также изменить информацию о штрафах граждан города.

Именно с городского портала начались первые пробития нашей инфраструктуры. Для проверки информации по штрафам на сайт необходимо было загрузить фотографию условных документов. Вечером первого дня были зафиксированы успешные попытки эксплуатации уязвимости CVE-2019-11043 (PHP-FPM Remote Code Execution) на сайте городского портала путём загрузки эксплоита php-страницы, позволяющей выполнить произвольные команды на уязвимом сервере, просто обращаясь к специально созданному URL-адресу. Её эксплуатация не требует глубоких технических познаний и серьезной подготовки. Данная проблема была устранена в новых релизах PHP, однако не забываем, что патчинг был запрещен.

В связи с этим наша команда в кратчайший срок написала простейший скрипт на проверку и удаление php-файлов в директории изображении. Таким образом мы немного замедлили развитие атаки, но не предотвратили её. Одновременно с этим группа мониторинга наблюдала за большим поток событий безопасности и сработок правил корреляции на других сервисах и формировала первые зафиксированные инциденты. Глубокой ночью уже большинство команд атакующих знали о наличии уязвимости и активно пытались её эксплуатировать. Одна из команд Red Team нашла способ обойти нашу маленькую заглушку, далее выполнила разведку на хосте и загрузила с внешнего сайта PHP-shell "p0wny". Здесь необходимо сделать примечание, что база данных сайта находилась на отдельном сервере во внутренней сети, но в каталоге сайта на веб-сервере хранился дамп структуры БД. Так вот атакующие просто сдампили весь каталог сайта и на некоторое время затихли, видимо уйдя изучать логику и структуру работы городского портала.

При этом дежурная группа мониторинга наблюдала за действиями злоумышленников практически в режиме реального времени. Оставалось дождаться завершающей фазы и в короткие сроки сформировать отчет о расследовании, ведь все события были зафиксированы. Но не тут-то было… Согласно многочисленным суевериям и мифам пятница 13ое является днем неприятностей. Не обошел этот день и нашу команду. 13ого ноября в 4 часа утра без объявления войны одна из команд атакующих, изучив структуру базы данных городского портала, сформировала SQL-запрос к таблице с информацией по штрафам и задолженностям граждан и удалила штрафы одного из пользователей. Таким образом был реализован первый бизнес-риск на нашем объекте.

Буквально за 15 минут после реализации риска мы подготовили отчет о расследовании со всеми событиями и скриншотами и в этот момент на игровом портале появилось сообщение о второй успешной реализации того же самого риска.

Отчет-то мы сдали, однако глобальный SOC полигона сообщил, что некоторые события из отчета были реализованы другой командой атакующих и нужно распределить правильно между отчетами цепочку событий. Оказалось, что в один и тот же период времени, используя одни и те же техники и тактики и эксплуатируя примерно одни и те же инструменты нас атаковали две команды и реализовали риск одним и тем же способом. И в этом была основная сложность в расследовании данной атаки. Следующие 8 часов аналитики дежурной группы посвятили распутыванию следов злоумышленников между собой и к концу дня оба наших отчета были приняты. Параллельно с этим группа мониторинга зарегистрировала 6 инцидентов, продолжала фиксировать множество попыток реализации атак (больше 100 в минуту) как автоматизированными, так и ручными методами.

В один из дней противостоянии в нашей инфраструктуре реализовали риск на городском портале, связанный со сбоем в работе онлайн-касс. Проводя расследование, наши аналитики дошли до определенной стадии цепочки и попали в тупик. А все дело в том, что команда Red Team реализовала риск таким методом, который изначально не был заложен в условия соревнования. Онлайн-кассы парка развлечений на городском портале в своей работе использовали API платёжного сервиса партнеров мероприятия — RBK.money. Как мы помним, атакующие сдампили все файлы сайта городского портала. Ну а дальше было дело техники. Достав API-ключ для процессинга и Bearer-ключ аутентификации, злоумышленники обратились на ААА-сервис Keycloak по API с имеющимся ключом для сброса пароля административной УЗ, после чего вызвали метод, позволяющий приостановить сервис онлайн-оплаты. Подробнее об этом можно почитать в статье RBK.money.

Вообще, на кибербитву мы шли ради проверки нашего контента сценариев мониторинга, улучшения процессов Threat Hunting-а в рамках жестких условий работы, а также повышения навыков и опыта в части расследования сложных таргетированных инцидентов. И, надо сказать, опыта набрали немало. 85% правил корреляции, установленных нашей командой в SIEM-систему, были отработаны и показали свою эффективность при выявлении инцидентов информационной безопасности. Часть экспериментальных правил также прошла обкатку, адаптацию и обновление решающей логики. Также по результатам участия в киберполигоне мы разработали новые правила детектирования вредоносной активности, с которой ранее не встречались в боевых условиях. Благодаря имеющемуся контенту сценариев, наша команда фактически следила за продвижением хакерской группировки в одной из самых запутанных и долгих атак – остановке работы колеса обозрения. Вся цепочка работы Red Team в этой атаке заслуживает отдельной статьи, но тем не менее не могу отказать себе в удовольствии кратко пробежаться по тактикам и техникам, которые использовали атакующие при реализации этого бизнес-риска; Получение первоначального доступа произошло из-за особенностей обработки входных данных веб-приложением, работающем на Java (T1190:Exploit Public-Facing Application). Используя поля ввода данных о показаниях счетчика на сайте управляющей компании, злоумышленники смогли загрузить на сервер powershell-скрипт, обфусцированный Base64 (T1027:Obfuscated Files or Information). Данный скрипт интерпретировал DNS-запросы, которые обращались на подконтрольный C&C сервер, в исполняемые команды на Windows-сервере (T1572:Protocol Tunneling). С помощью DNS туннелирования злоумышленники смогли загрузить шелл и закрепиться на скомпрометированном хосте. Далее необходимо было продвинуться вглубь инфраструктуры. Обнаружив доменный сервер с Microsoft SQL базой данных, атакующие смогли подобрать логин и пароль к базе данных (T1110.001 Brute Force: Password Guessing), после чего, используя хранимую процедуру mssql xp_cmdshell (T1505.001:Server Software Component: SQL Stored Procedures), произвели закачку полезной нагрузки meterpreter, с помощью утилиты certutil (T1059.003 Command and Scripting Interpreter: Windows Command Shell)

Так злоумышленники оказались в доменной инфраструктуре. Ну а дальше был дамп хэша пароля администратора домена, сессия которого была на вышеуказанном сервере MS SQL и использование атаки Pass-the-Hash (T1550.002 Use Alternate Authentication Material: Pass the Hash). К этому моменту атакующие уже знали, где находится искомый хост со SCADA, управляющей колесом обозрения. Получив до SCADA-сервера доступ через shell, они открыли RDP и создали локальную учетную запись с правами администратора.

Изучив логику работы SCADA, атакующая команда сформировала команду на контроллер управления для остановки работы колеса обозрения (T1565 Data Manipulation)

По итогам 6 дней The Standoff у нашего объекта был один из самых высоких показателей доступности ИТ-инфраструктуры — 96%. Наша команда «КиберТатары и Московские Мастера» зафиксировала 49 инцидентов — это второй показатель среди защитников, завершила наибольшее число расследований, верифицированных глобальным SOC – по каждому из 8 реализованных бизнес-рисков. Нам важно было прокачать свои скиллы по расследованию инцидентов, потому что это наша реальность – нас вызывают, к сожалению, не только устанавливать противопожарную сигнализацию, но и тушить пожар. Суммарно 20 часов расследований сложных, целенаправленных и подготовленных компьютерных атак – это тот опыт, который получили наши ребята на площадке. С собой для изучения и тренировки новых специалистов мы забрали большой набор кейсов и артефактов.

Также хочется отметить, что в условиях киберполигона начинаешь по-другому воспринимать время. У хакеров нет перерывов на обед, нет выходных, нет какого-то перемирия. Большинство реализованных рисков пришлось на субботу и воскресенье или на ночные часы. Это еще раз подтверждает то, что к атакам любая организация и команда ее защищающая должны быть готовы всегда. Информационной безопасностью нужно заниматься 24 часа 365 дней в году.

А такие учения — отличный способ применения своей экспертизы и тренировки навыков, и должны быть доступны на постоянной основе, ведь новые риски появляются каждый день.

Надеюсь, это было интересно (ну, как минимум, познавательно).

Как и обещал, в конце ссылка на наш вебинар.

Всем спасибо и с Новым годом! Берегите себя и свою инфраструктуру!

Оригинал статьи размещен здесь