Сотрудник центра мониторинга информационной безопасности и реагирования на компьютерные инциденты CyberART группы компаний Innostage принял участие в киберучениях The Standoff, в рамках которых были протестированы системы обеспечения информационной безопасности MaxPatrol SIEM, PT Application Firewall и PT Network Attack Discovery (PT NAD). Он делится своими впечатлениями после тестирования возможностей системы PT Application Firewall с точки зрения специалиста первой линии.
Введение
Осенним утром я вернулся домой после ночной смены в SOC. При классическом раскладе я бы сразу пошёл спать, однако этим утром всё пошло не так, как обычно. На часах — 10:00, начинается онлайн-совещание. Тема ещё неизвестна, но однозначно чувствуется важность повестки. Три, два, один, поехали:
«Мы участвуем в The Standoff».
Оставшиеся полтора часа совещания прошли в полном недоумении, но при этом максимально эффективно, так как в это время была изложена вся вводная информация по инфраструктуре, с которой мы будем работать, и по средствам защиты, которые будет необходимо мониторить во время проведения кибербитвы. К этим данным впоследствии мы не раз обращались во время «войны».
Подготовка к учениям
Наш отдел был поделён на две ГРИИБ (группы реагирования на инциденты в информационной безопасности). Мониторингом занимались сутки через сутки на протяжении всех соревнований. Перед нами как специалистами первой линии стояла задача мониторить представленные системы ИБ:
- MaxPatrol SIEM
- PT Application Firewall
- PT Network Attack Discovery (PT NAD)
Если о первом мы знали не понаслышке и успешно работали с ним, то с остальными двумя ситуация была гораздо запутаннее. Разбираться и работать в них было гораздо интереснее. Поэтому и было решено поделиться в этой статье небольшим, но продуктивным опытом работы с таким инструментом, как межсетевой экран уровня веб-приложений PT Application Firewall, с точки зрения специалиста первой линии. Для наглядности приведу примеры того, на какие инциденты мы обращали внимание в первую очередь, и поясню, почему всё было именно так.
В рамках соревнований было выстроено простое, но при этом весьма эффективное взаимодействие первой и второй линий. Мы занимались поиском инцидентов и аномалий в системах ИБ, а в случае нахождения передавали всю найденную информацию аналитикам второй линии, которые в дальнейшем углублённо разбирали инциденты и пытались предотвратить возможную угрозу или справиться с её последствиями. Далее будет приведён список инцидентов, по которым мы формировали отчёты и список первичной информации, передававшейся аналитикам для её дальнейшего разбора.
Так как веб-ресурсы находились в DMZ (зоне общедоступных сетевых сервисов. — Прим. ред.), о ней и пойдёт речь. Первые два дня, пока мы (команда «синих») и «красные» входили в кондицию, мы ловили не так много инцидентов. Средства защиты информации, которыми мы пользовались при работе с событиями из DMZ: PT Application Firewall и MaxPatrol SIEM. Тут мы обращали больше всего внимания на активы, в которых могли быть реализованы различные бизнес-риски, например по утечке конфиденциальной информации и персональных данных. Такими активами были «Сайт городского портала» и «Сайт управляющей компании».
Рисунок 1. Схема DMZ
Работа с PT Application Firewall
Итак, ближе к теме разговора.
На протяжении всего The Standoff мы ловили попытки автоматического и ручного сканирования нашей DMZ на PT Application Firewall. Их было настолько много, что для разграничивания событий приходилось выстраивать огромные фильтры изо всевозможных исключений.
После всех манипуляций мы стали получать не такой большой поток с уже реальными событиями нарушения безопасности импровизированной информационной системы. В первую очередь нас, конечно же, интересовало поле «Клиент», где содержалась информация об источнике подключения. Так как своих мы «знали в лицо», а если точнее — по имени учётной записи, все остальные логины на ресурсах, где это не было предусмотрено, считались нарушением.
Как, например, на следующем скриншоте. Имя пользователя «qwer» с паролем «123456» явно создавалось на скорую руку, да и сам клиент находится в подсети «красных» и уже из этого можно сделать вывод, что что-то тут нечисто.
Рисунок 2. Подозрительное событие аутентификации
На следующем скриншоте представлено срабатывание PT Application Firewall, которое показалось странным из-за GET-запроса. Информация была передана аналитику, и оказалось, что это — действительно инцидент. «Эксплуатация уязвимостей. Выполнение деструктивных действий» — так он был охарактеризован.
Рисунок 3. GET-запрос, содержащий ссылку на эксплойт
Злоумышленники эксплуатировали уязвимость CVE-2019-11043 (PHP-FPM Remote Code Execution) на сайте городского портала, позволяющую выполнить произвольный PHP-код путём подготовки и отправки на сервер специального запроса, интерпретируемого NGINX и PHP-FPM по-разному. В результате разницы в интерпретации запроса злоумышленник смог выполнить команду SQL-кода:
exec master..xp_cmdshell 'ping 172.10.1.255'--INSERT INTO requests VALUES (null, ?, ?, null, ?, 1, null)
Рисунок 4. SQL-команда
Из вышесказанного можно сделать вывод, что поле «Текст запроса» также содержит много полезной информации. Ещё один пример приведён на скриншоте ниже, на котором мы видим, что «email» и «password» имеют весьма странные значения.
Рисунок 5. Странные значения для «email» и «password»
Также PT Application Firewall активно показывал успешные попытки входа под нашими учётными записями. Таким образом мы определяли, чьи учётные данные уже были скомпрометированы, а чьи пока ещё находятся в целости и сохранности.
Рисунок 6. Вход под скомпрометированной учётной записью
Само собой, большинство срабатываний приходило из PT Application Firewall в MaxPatrol SIEM, где их находил ответственный специалист; далее шёл их поиск в Application Firewall для уточнения информации, формирования отчёта и передачи его аналитикам. На скриншоте ниже приведён пример такого срабатывания из MaxPatrol SIEM. Кто-то узнавал информацию о текущем пользователе системы городского портала.
Рисунок 7. Пример представления срабатываний из PT Application Firewall в MaxPatrol SIEM
На следующем скриншоте показан инцидент, где злоумышленник пытается получить API-ключ к сервису городского портала. В первую очередь смотрели на «client», откуда получили информацию об атакующем, а затем в поле «request» обнаружили, что это — POST-запрос, и в итоге нашли тот самый ключ в «query».
Рисунок 8. API-ключ, содержащийся в поле «query»
Выводы
Я рад, что мне выпала возможность поучаствовать в таком масштабном мероприятии, как The Standoff. Опыт, полученный во время работы с реальными техниками и тактиками проведения атак на информационные системы, — неоценим. Были отработаны и получены новые компетенции в сфере информационной безопасности, причём как со стороны защиты, так и со стороны атаки.
Было весьма интересно работать с решениями компании Positive Technologies, как с уже проверенными, так и с абсолютно новыми. PT Application Firewall и PT NAD стали настоящим открытием для меня.
PT Application Firewall действительно защищает веб-ресурсы организации на 360 ⁰ и имеет высокую точность детектирования угроз. Однако, как и в любой системе защиты, всегда найдётся слабое место и атакующие смогут продвинуться дальше, за пределы DMZ. Поэтому потребность в специалистах, работающих в центрах мониторинга и реагирования на компьютерные инциденты, становится всё более и более актуальной с каждым днём.
