Как меняются методы расследования на Standoff: кейс аналитика PT Expert Security Center

Всем привет! Меня зовут Юлия Фомина, в Positive Technologies я занимаюсь проактивным поиском и обнаружением угроз, что в профессиональной среде называется threat hunting. И все эти знания наша команда превращает в экспертизу продуктов Positive Technologies. И конечно же, мы не только обогащаем наши продукты уникальной экспертизой, но и в буквальном смысле пробуем каждый продукт в деле. Сегодня поговорим про мой опыт работы с одной из наших новейших разработок — автопилотом MaxPatrol O2, а также о том, как он упростил нам работу при анализе и расследовании активности белых хакеров во время двенадцатой кибербитвы Standoff .

Для начала напомню, что кибербитва проходила в ноябре прошлого года, 15 красных команд пытались реализовать более 120 возможных негативных сценариев, заложенных в инфраструктуру виртуальных организаций Государства F. А шесть команд защитников регистрировали атаки и расследовали инциденты.

Кстати, понаблюдать за очередной битвой можно будет уже в ближайшем мае в Москве, когда в Лужниках пройдет международный киберфестиваль Positive Hack Days 2. Впервые все гости PHDays Fest 2 смогут также увидеть кибербитву Standoff — противостояние команд этичных хакеров и защитников за ресурсы виртуального государства.

Специалисты PT Expert Security Center (PT ESC) традиционно во время кибербитвы выступали в роли глобального SOC. Наша задача не только верифицировать и принимать отчеты от команд атакующих и защитников, но и понимать, что происходит в инфраструктуре: где находится каждая из красных команд и как скоро им удастся реализовать недопустимое событие. Суммарно за время мероприятия нами было зафиксировано 20 500 инцидентов информационной безопасности, проверено более 200 отчетов атакующих и около 450 отчетов защитников.

На предыдущих кибербитвах Standoff для мониторинга инфраструктуры виртуального Государства F развертывались продукты Positive Technologies: MaxPatrol SIEM, PT Network Attack Discovery, PT Application Firewall, PT Sandbox. А в этот раз в глобальном SOC впервые полноценно развернули MaxPatrol O2 — метапродукт, который позволяет автоматически обнаружить и остановить злоумышленника до того, как компании будет нанесен неприемлемый ущерб. Было очень интересно, как изменится жизнь оператора SOC с приходом таких инноваций, поэтому я с головой окунулась в работу именно с MaxPatrol O2, чтобы проверить его в бою.

Кстати, в последний день мероприятия команда MaxPatrol O2 вышла в эфир в рамках Standoff Talks , где рассматривали интересные цепочки, которые выявил метапродукт. А в феврале этого года вместе с моим коллегой Антоном Исаевым мы провели экспертный вебинар , на котором разобрали интересные цепочки, в режиме реального времени отвечали на вопросы, а я делилась своими впечатлениями от использования продукта.

Standoff всегда был для нас с коллегами вызовом. На протяжении нескольких дней белые хакеры не стесняясь разгуливают по инфраструктурам виртуальных организаций Государства F. Они посылают фишинговые письма, используют всевозможные утилиты и эксплойты и делают все необходимое для достижения своих целей. Все это выливается в большое количество срабатываний средств защиты, которые фиксируют продукты Positive Technologies. Конечно, у нас не было цели выбивать хакеров из инфраструктуры, ведь это не входит в правила противостояния. Наша задача заключалась в том, чтобы успевать вовремя анализировать все срабатывания СЗИ, искать между ними связи и выстраивать их в логические цепочки.

Чтобы справиться с этой задачей раньше нам приходилось:

непрерывно следить за поступающими срабатываниями и верифицировать их в MaxPatrol SIEM и других продуктах Positive Technologies, чтобы выяснять, не являются ли они ложными;
часто обращаться к консолям других решений (PT Network Attack Discovery, PT Sandbox, PT Application Firewall), чтобы собирать дополнительный контекст атаки;
прибегать к использованию обычных листов бумаги, на которых мы выстраивали цепочки атаки. Вот так это выглядело от руки:

Рисунок 1. Цепочка атаки

И конечно же, мы ожидали, что MaxPatrol O2 сможет нас разгрузить благодаря:

связыванию и объедению атомарных срабатываний из MaxPatrol SIEM, PT Network Attack Discovery и PT Sandbox в единый граф активности хакера;
автоматическому сбору и предоставлению полного контекста атаки, достаточного для реагирования со стороны специалистов и остановки хакера в инфраструктуре;
динамической оценке уровня опасности выявляемых активностей;
прогнозированию приближения реализации недопустимых событий.

Чтобы понять, насколько хорошо это получилось у метапродукта, давайте разберем один из инцидентов в инфраструктуре логистической компании.

Сценарий распространения вируса-шифровальщика

В этом сценарии одна из команд атакующих реализовала недопустимое событие «Распространение вируса-шифровальщика».

Этапы их атаки:

Отправив фишинговое письмо с вредоносным вложением пользователю s_marks, команда белых хакеров получила доступ во внутреннюю сеть логистической компании.
Далее последовала локальная и доменная разведка, после чего атакующие продолжили развитие атаки.
Повысив привилегии на узле smarks.hvlogi.stf через SeImpersonatePrivilege, атакующие получили в свое распоряжение несколько доменных учетных записей, в том числе привилегированных, и продолжили свой путь внутри сети — на сервер резервного копирования.
Для закрепления на узле backup.hvlogi.stf был создан сервис EmbeddedModes32, который запускал туннель wwihost.exe с наивысшими привилегиями. Он позволял атакующим напрямую отправлять команды на backup.hvlogi.stf и открывал доступ в серверный сегмент.
Через этот туннель атакующие переместились на узел shpoint.hvlogi.stf, где уже из интерактивной сессии запустили вирус-шифровальщик.

Итак, в логистической компании Государства F на нашем киберполигоне произошел инцидент, инфраструктура зашифрована, работа остановилась, а бизнес несет миллионные потери. Давайте начнем наше расследование в интерфейсе MaxPatrol O2. Чтобы сделать рассказ еще более наглядным, я буду параллельно рассказывать и о том, как обычно действует оператор в классическом SOC без метапродукта: какие запросы ему приходится выполнять и какими стандартными плейбуками расследования он будет пользоваться при срабатывании правил корреляции.

Как выглядит активность хакера

Рисунок 2. Цепочка реализации недопустимого события в MaxPatrol O2

Открыв цепочку активности, мы видим верхнеуровневое представление действий атакующих:

узлы, по которым белые хакеры перемещались в инфраструктуре;
внешний адрес, на который они устанавливали соединение с каждого из захваченных узлов;
недопустимое событие, к которому они шли (и дошли).

Каждый узел можно раскрыть, чтобы посмотреть подробности происходящего.

Как вердикты от разных продуктов объединяются в единый граф активности

Основа работы для метапродукта — это данные от сенсоров. Получая множество срабатываний и вердиктов от других продуктов Positive Technologies, MaxPatrol O2 принимает решение о том, какие срабатывания связаны между собой, и строит цепочку атаки.

Сложность в том, что продукты работают на разных уровнях:

MaxPatrol SIEM регистрирует события операционных систем, приложений, процессов, служб.
PT NAD анализирует сетевое взаимодействие: система знает про узлы и трафик между ними, но ничего не знает о процессах.
PT Sandbox проверяет файлы, которые может извлекать из трафика или напрямую из почтовых вложений.

Чтобы собрать из этого общую картину происходящего, MaxPatrol O2 раскладывает каждое срабатывание, которым он оперирует, на ресурсы. Ресурсы — это основные сущности, с которыми работают аналитики SOC: узлы, сессии, процессы, службы, файлы, задачи, учетные записи и так далее. У каждого ресурса есть роль: атакующий, атакованный или захваченный. Учитывая тип ресурса, его роль и другие параметры, MaxPatrol O2 принимает решение о том, связаны ли срабатывания нескольких правил корреляции между собой и являются ли они деятельностью одного злоумышленника или группировки. Подробнее об этом мы писали в другой статье .

Рисунок 3. Представление атаки типа DCSync в инфраструктуре нефтегазовой компании Tube в результате комбинации событий от PT NAD и MaxPatrol SIEM

На киберполигоне во владении компании Tube находились объекты, связанные с нефтедобычей, нефтепереработкой, хранением, транспортировкой и сбытом нефтепродуктов. Как продукты выявили атаку на эту компанию:

PT NAD регистрирует информацию об атаке типа DCSync.
MaxPatrol O2 получает информацию об атакующем и атакуемом узле и сетевом взаимодействии между ними.
На основе имеющихся данных MaxPatrol O2 дозапрашивает недостающую информацию у MaxPatrol SIEM (какой процесс открыл соединение, какие учетные данные при этом использовались).

В итоге аналитик вместо четырех событий из двух разных консолей видит в интерфейсе MaxPatrol O2 (рис. 3), что пользователем m_marks на атакующем узле был запущен процесс agent.exe, который осуществил атаку типа DCSync на узел dc-2.tube.stf, используя учетные данные a_munoz_admin.

Как MaxPatrol O2 расследует перемещение злоумышленника внутри периметра

Теперь давайте вернемся к расследованию распространения вируса-шифровальщика. Начнем анализ с узла shpoint.hvlogi.stf, на котором и было реализовано недопустимое событие «Распространение вируса-шифровальщика».

Рисунок 4. Подробности происходящего на узле shpoint.hvlogi.stf

На рисунке 4 видно, что корнем дерева вредоносного процесса ransomware.exe был explorer.exe. Опытный аналитик SOC сразу скажет, что у атакующих был интерактивный доступ к узлу, скорее всего, по протоколу RDP (Remote Desktop Protocol). Чуть менее опытный обратится к плейбуку, чтобы разобраться, с какого узла атакующий развивал атаку.

Обычно для этого требуется выполнить три запроса и потратить несколько минут:

По номеру сессии нужно обнаружить событие входа пользователя, чтобы выяснить, с какого узла пришел атакующий (EventID 4624).
На атакующем узле необходимо найти событие сетевого соединения по порту (EventID 5156 или Sysmon 3). Это даст информацию об имени процесса, который инициировал вход.
Далее нужно узнать, какие события запустили процесс (EventID 4688 или Sysmon 1). Это позволит понять, кем и как был запущен процесс-туннель.

В MaxPatrol O2 такой алгоритм действий уже автоматизирован: при наличии интерактивной сессии метапродукт автоматически выполняет запросы в MaxPatrol SIEM.

Рисунок 5. Результат работы алгоритма расследования перемещения внутри периметра

В итоге система дополняет граф атаки, внося в него:

Атакующий процесс и его полный контекст, включая пользователя, сессию и полную цепочку запуска — wwihost.exe (рис. 5).
Узел, с которого развивалась атака. Именно благодаря этому происходящее на узлах backup.hvlogi.stf и shpoint.hvlogi.stf связалось вместе и оказалось в одной цепочке атаки.

Обратите внимание, что связь строится сразу от процесса к сессии. Такое наглядное представление связей позволяет не держать в голове весь контекст, в отличие от расследования вручную.

Важно отметить, что алгоритм работает итеративно, то есть если на атакующем узле также найдена интерактивная сессия, то алгоритм запустится и для нее. Например, вход в сессию 66258676 на узле backup.hvlogi.stf был совершен через процесс mstsc.exe (340) на узле smarks.hvlogi.stf. И благодаря алгоритму расследования перемещения внутри периметра на графе появляется узел smarks.hvlogi.stf (рис. 5).

Рисунок 6. Вектор начального проникновения

Кроме того, MaxPatrol O2 разбирает и визуализирует цепочки процессов. На рисунке 6 мы видим цепочку запуска процессов, которая содержит winword.exe. Это говорит о том, что пользователь открыл фишинговое письмо, содержащее файл Microsoft Office с вредоносным макросом. В этот момент метапродукт останавливает выполнение правила обогащения для обнаружения перемещения злоумышленника, так как уже дошел до точки проникновения атакующего в инфраструктуру.

На предыдущей кибербитве нам пришлось проделывать все эти действия вручную для каждого из узлов цепочки. И в зависимости от сложности атаки это могло занимать от нескольких минут до получаса. Мы подробно рассказывали об этом в статье «Письмо ценой катастрофы: расследуем атаку на Standoff, используя продукты Positive Technologies» .

Закрепление с помощью сервиса или запланированной задачи

Хочется сделать отдельный акцент на процессе wwihost.exe (7760) (рис. 7). Это туннель, который был прокинут на узле backup.hvlogi.stf и позволял атакующим перемещаться дальше внутри серверного сегмента и развивать атаку.

Рисунок 7. Срабатывание правила корреляции, обогащенное именем вредоносной службы и именем процесса, создавшего вредоносный файл

Представим, что у нас нет MaxPatrol O2 и мы только что нашли событие запуска процесса, расследуя инцидент вручную.

Благодаря правилам обогащения MaxPatrol SIEM мы бы увидели, что:

Процесс запущен от имени системной учетной записи.
Цепочка процессов в MaxPatrol SIEM указывает на то, что исполняемый файл создан с помощью powershell.exe.
Родительским процессом является services.exe.

Рисунок 8. Событие запуска процесса в MaxPatrol SIEM

Это значит, что атакующие смогли не просто проникнуть на узел, а уже успели получить максимальные права в системе и закрепиться в ней, создав службу Windows. Для аналитика это означает, что завершить процесс и удалить вредоносный файл будет недостаточно для эффективного реагирования на инцидент. Закрепление позволит злоумышленникам быстро вернуться в инфраструктуру сразу после перезапуска узла. И правильным решением в этом случае будет удаление недавно установленного сервиса.

Чтобы выяснить имя сервиса, стандартный плейбук оператора SOC предлагает выполнить запрос события EventID 7045 или 4697, используя фильтр по команде, на которую произошло срабатывание правила корреляции (C:WindowsSysWOW64WWIHost.exe).

MaxPatrol O2 в таком случае автоматически отправляет запрос в MaxPatrol SIEM с нужным фильтром, чтобы добавить имя установленной службы в цепочку. Триггером к этому будет появление в цепочке активности ресурса типа «процесс», родительским процессом которого является services.exe. В итоге оператор увидит в интерфейсе сразу полный контекст — имя сервиса EmbeddedModes32 (рис. 7), который необходимо удалить. Именно это действие метапродукт добавит в сценарий реагирования при его генерации. На графе также будет отображена вся цепочка запуска процессов. А от процесса powershell.exe (3680) идет связь типа «Захват» к ресурсу типа «файл» c:windowssyswow64wwihost.exe, так как именно через powershell.exe атакующие скачали вредоносный файл на узел.

Подобный механизм работает и для запланированных задач Windows. На рисунке 9 показан пример активности еще одной команды красных в другой инфраструктуре. Этот случай мы разбирали на вебинаре :

MaxPatrol SIEM среагировал на подозрительный запуск команды curl.exe.
По дереву процессов MaxPatrol O2 понял, что процесс запущен из запланированной задачи.
Метапродукт нашел не только имя самой задачи (BkyNFKjm), но и информацию о пользователе ( a_muroz_admin@tube.stf ) и сессии, в которой задача была создана.
Для нелегитимной сессии был сразу запущен алгоритм расследования перемещения внутри периметра, о котором мы уже говорили ранее.

Рисунок 9. Срабатывание правила корреляции в инфраструктуре компании Tube, обогащенное информацией об установке задачи по расписанию

Повышение привилегий

Рисунок 10. Визуальное отображение повышения привилегий

Осталось рассказать только о привлекающей внимание стрелке между coercedpotato.exe (11324) и powershell.exe (11484). Это не что иное как индикатор повышения привилегий.

По названию можно догадаться, что coercedpotato.exe — это эксплойт для повышения привилегий через известную уязвимость Windows. Но настоящий аналитик не отталкивается от название процесса. Стоит обратить внимание на то, что coercedpotato.exe запущен в пользовательской сессии. А в результате успешной эксплуатации его дочерний процесс запустился уже в системной сессии, тем самым атакующие получили максимальные права в системе (рис. 10).

Интеграция со сторонними сервисами

Рисунок 11. Проверка хеша поддельного файла mstsc.exe

В MaxPatrol O2 есть очень приятная интеграция с VirusTotal, которая позволяет аналитику быстро проверить хеш-сумму файла. Например, если изучить на рисунке 11 подробности процесса mstsc.exe (340), то станет ясно, что это не настоящий клиент RDP, а туннель атакующих. Это в разы ускоряет валидацию некоторых инцидентов. Наша команда очень ждет полноценную автоматизированную работу с IoC и фидами — вердиктами от PT Cybersecurity Intelligence и PT Sandbox .

Прогнозирование наступления недопустимого события

Кроме узлов на графе присутствует недопустимое событие, реализованное командой атакующих, — «Распространение вируса-шифровальщика».

Рисунок 12. Реализация НС

Как MaxPatrol O2 понимает, что цель достигнута? И поймет ли метапродукт, что цель еще не достигнута, но хакеры уже близко? Могут ли хакеры вообще дотянуться до критически важных систем? И за сколько шагов они смогут это сделать?

Ответы на все эти вопросы знает служба Threat Modeling Engine (TME), которая используется «под капотом» у метапродуктов Positive Technologies. О ее работе мы подробно рассказывали в статье «MaxPatrol O2. Как работает автопилот для кибербезопасности» .

TME получает на вход результаты сканирования: сетевую топологию, связанность, информацию об уязвимостях, а также данные о пользователях и их правах в системах и приложениях. Дальше происходит магия: TME строит большой граф всех возможных маршрутов атак, которыми могут воспользоваться злоумышленники для достижения заданной цели (например, реализации недопустимого события). Затем TME находит кратчайшие пути от периметра до защищенного сегмента, где располагается критически важная информационная система. TME учитывает всю полученную информацию и оценивает, в какие сегменты необходимо проникнуть хакеру, на какие узлы получить доступ, какие учетные записи должны оказаться в его руках и какими привилегиями они должны обладать. Кроме того, TME может прогнозировать дальнейшие шаги атакующих, зная, какие ресурсы уже были захвачены ранее.

Когда любое из СЗИ регистрирует атаку, MaxPatrol O2 превращает ее в ресурсы и связи, после чего передает эту информацию TME. Она анализирует захваченные хакерами ресурсы (узлы, учетные записи) и отвечает на вопросы, к какому из недопустимых событий хакеры находятся ближе всего и за сколько минимально шагов им удастся его реализовать.

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

Рисунок 13. Количество шагов до реализации недопустимого события

И чем меньше остается шагов, тем больше тянется мышь к кнопке «Реагировать». Для реагирования MaxPatrol O2 будет предлагать ресурсы (узлы, учетные данные, файлы, процессы), которые участвовали в атаке. В зависимости от типа ресурса метапродукт предложит разные действия (например, заблокировать учетную запись в домене или сбросить пароль, изолировать узел, удалить файл, завершить процесс) и построит такой сценарий реагирования, чтобы он был эффективным, но при этом не нарушал работу важных систем и бизнес-процессов компании.

Но то, как это происходит, пожалуй, достойно отдельной статьи, потому что от предлагаемых сценариев остановки злоумышленника будет напрямую зависеть, остановится ли продвижение хакеров в инфраструктуре.

На киберфестивале Positive Hack Days 2 мы планируем дать возможность командам атакующих проверить механизмы реагирования MaxPatrol O2 в режиме реального времени в инфраструктуре одной из виртуальных организаций Государства F, а потом поделимся с вами результатами.

Вместо заключения

На этом наше расследование окончено: риск реализован, работа компании парализована, MaxPatrol O2 показывает, что хакеры достигли своей цели. Конечно, в реальной жизни мы бы остановили эту атаку до того, как хакеры смогли реализовать недопустимое для бизнеса событие. Но по правилам нашей кибербитвы этого не требовалось. В конце концов, если бы эта атака была сразу же остановлена, то у нас не получилось бы показать вам такую красивую цепочку.

В реальной инфраструктуре происходит огромное количество действий каждый день, а СЗИ регистрируют множество срабатываний правил, в том числе и false positive. Как и аналитик SOC, на этапе получения идентичного алерта MaxPatrol O2 не может отличить ложноположительное срабатывание от реальной атаки. Но преимущество метапродукта в том, что вокруг каждого срабатывания он видит много контекста: другие связанные алерты, продвижение по инфраструктуре, развитие атаки. И он может принимать решение уже на основе всего контекста.

Пока атака не получит определенный уровень опасности, не превысит порог, цепочка будет продолжать собираться. Но как только атака получит развитие и алгоритмы примут решение о том, что это действие похоже на действие хакера, MaxPatrol O2 переведет цепочку в статус «Требует внимания» и построит сценарий реагирования. Это помогает сосредоточить внимание аналитика на действительно подозрительных активностях, которые происходят в инфраструктуре, а не рутинно разбирать тысячи однотипных инцидентов. Например, на рисунке 4 было видно, что создание файла temp.bat и запуск вируса-шифровальщика ransomware.exe являются активностью одной команды, хотя в SIEM-системах это два абсолютно независимых события, ниточку контекста между которыми может провести только аналитик.

Автоматизация расследования, реализованная в MaxPatrol O2, позволяет минимизировать человеческий фактор. Иногда случается так, что после длинной ночной смены глаз аналитика замыливается, а атакующий называет службу практически так же, как называется системная. И тогда очень велика вероятность того, что оператор ошибочно примет активность злоумышленника за системную и пропустит инцидент. Даже на Standoff, где атакующим необязательно скрывать свою деятельность, мы видели службы и задачи, которые маскируются под службу обновления Windows или Google Chrome.

Использование MaxPatrol O2 на Standoff провело нашу команду по пути от любопытства, что же за магический инструмент разработан для нас в нашей же компании, до понимая, что метапродукты реально ускоряют процесс расследования и обнаружения угроз, сокращают нагрузку на аналитиков SOC, повышают их эффективность, улучшают реакцию на инциденты и минимизируют потенциальный ущерб.

Несмотря на все преимущества, которые открывает MaxPatrol O2, мы не можем не задать себе вопрос: насколько эффективной может быть автоматизация в такой сложной и динамичной области, как обнаружение и остановка кибератак? И конечно, автопилоту есть куда развиваться, чтобы стать еще более универсальным и адаптивным.

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

Юлия Фомина, Руководитель группы экспертизы метапродуктов отдела обнаружения угроз экспертного центра безопасности Positive Technologies