Security Vision
Впервые слово килчейн (точнее, несколько слов: The Cyber Kill Chain) как термин появилось в далеком 2011 году, когда американская компания Lockheed-Martin впервые предложила выстроить зафиксированные в инфраструктуре события в единую цепочку атаки. Цепочка была довольно проста и включала в себя всего 7 звеньев: разведка, вооружение, доставка, эксплуатация, инсталляция, управление, действие. По сути, это было ответом на усложнившиеся хакерские атаки, которые использовали всё более изощренный инструментарий и многоходовые тактики атаки.
Подход, делящий атаку на некие этапы, оказался очень востребован, но не был лишен недостатков. Например, килчейн от Lockheed-Martin совершенно не учитывал внутреннего злоумышленника, атакующего изнутри инфраструктуры. Соответственно, другие игроки постарались развить и улучшить это метод. Так, уже в 2013 MITRE предложила свой вариант, представив последовательность из 14-ти тактик. Позже экспертом в области кибербезопасности Полом Поллзом (Paul Polls) был предложен гибридный вариант, объединяющий и расширяющий методики от Lockheed-Martin и MITRE, известный как The Unified Kill Chain.
Давайте порассуждаем о плюсах, минусах и подводных камнях килчейна как такового, а также попробуем разобрать реальный пример построения цепочки атаки.
Подходы и методики построения таймлайна атаки
Киллчейн базируется на таймлайне атаки, который является его важнейшей составляющей. Следовательно, в процессе реагирования на инциденты ИБ необходимо определить хронологию действий злоумышленника, поверхность атаки (скомпрометированные узлы, учетные записи), используемые злоумышленником уязвимости, инструменты и TTP. Итоговый таймлайн атаки выстраивается посредством связывания задействованных в атаке инцидентов ИБ по ключевым атрибутам: IP адреса/имена атакующих и скомпрометированных узлов, скомпрометированные учетные записи, уязвимости на хостах, хакерский инструментарий, ВПО.
На сформированный таймлайн накладывается матрица атак MITRE ATT@CK, что позволяет в конечном счете выстроить итоговый киллчейн атаки посредством сопоставления каждого этапа таймлайна атаки с соответствующей тактикой/техникой матрицы MITRE ATT@CK.
Выстраивать киллчейн атаки можно автоматизированным и ручным способом. В первом случае это сделают продукты класса SOAR/XDR, которые помимо выполнения активных действий по сдерживанию, ликвидации последствий атаки, скоррелируют между собой обнаруженные инциденты ИБ за счет оркестрации и агрегации данных, полученных из всевозможных источников. К таким источникам относятся: SIEM системы, логи СЗИ (МЭ, IDS/IPS, WAF, прокси-сервера, почтовые шлюзы, антивирусы, песочницы, DLP, IDM/PAM, NAC и др.), системные (Windows Eventlog, Linux auditd/syslog), прикладные логи (веб-сервера, почтовые, файловые сервера, СУБД, ERP, CRM и т.д.), а также логи коммутационного оборудования (коммутаторы, маршрутизаторы, Wi-Fi точки доступа).
Упомянутые выше системы класса SOAR/XDR проведут всю необходимую аналитику и выстроят итоговые таймлайн и киллчейн атаки в удобном виде, а также приведут рекомендации по реагированию на каждый этап атаки. Далее на примерах мы можем в этом убедиться.
Автоматизированный подход
На данном примере видно, как развивалась атака от стадии получения первоначального доступа (эксплуатация критической уязвимости Log4Shell) до компрометации контроллера домена (эксплуатация критической уязвимости PrintNightmare) с последующей попыткой запуска шифровальщика во всем домене с правами учетной записи из группы Domain Admins.
В результате сопоставления каждого этапа таймлайна атаки с матрицей MITRE ATTACK был получен следующий киллчейн.
Ручной подход
Когда под рукой не оказывается подобных решений, предстоит решить данную задачу вручную. Для этого необходимо прибегнуть к следующим подходам ручного выстраивания таймлайна атаки:
1) Анализ и связывание инцидентов ИБ, полученных от SIEM, по общим ключевым атрибутам.
В данном случае SIEM выдаст перечень инцидентов ИБ за рассматриваемый период времени, сгруппирует однотипные. В карточке инцидентов ИБ будут подсвечены ключевые атрибуты (IP адреса/имена узлов, учетные записи, уязвимости и т.д.), по которым необходимо логически связать инциденты и выстроить их в единую хронологию атаки.
2) Ретроспективный поиск поведенческих индикаторов угроз в логах SIEM, основанный на знаниях наиболее актуальных TTP, уязвимостей, индикаторов хакерского инструментария злоумышленников и ВПО, т.н. индикаторов атак (Threat Hunting). Подход базируется на выстраивании гипотез наличия поведенческих индикаторов (хостовые, сетевые) в логах с последующим подтверждением или опровержением данных гипотез до момента полного выстраивания таймлайна атаки.
К хостовым поведенческим индикаторам относятся характерные ключи реестра, строки запуска процессов, именнованные каналы, службы, задачи планировщика, названия библиотек, запрошенные права доступа к процессу и т.д. К сетевым поведенческим индикаторам относятся характерные паттерны (наличие обфусцированного, закодированного, шифрованного содержимого) в заголовках и теле пакетов сетевого трафика, размер сетевых пакетов и их заголовков, периодичность их отправки, параметры хэндшейка при установлении шифрованной сессии с вредоносными C&C серверами и т.д.
Нередки случаи, когда логов SIEM оказывается недостаточно, особенно когда имеем дело с опытным злоумышленником, способным скрывать свои действия и уклоняться от обнаружения СЗИ. В данной ситуации для выявления индикаторов атак приходится прибегать к низкоуровневому анализу артефактов ОС, таких как файловая система, реестр, память скомпрометированных хостов, логи и журналы ОС, сетевой трафик (если его запись ведется средствами МЭ либо NTA системами). Темы хостовой и сетевой форензики требуют отдельного внимания, чему будут посвящены следующие статьи.
На практике данный подход применяется ограниченно ввиду своей большой трудоемкости и требований высокой экспертизы аналитика, которая заключается в знаниях наиболее актуальных тактик, техник и инструментов атак злоумышленников, умении выявлять и коррелировать их следы в «сыром» потоке хостовых и сетевых событий, а также в умениях пользоваться инструментами компьютерной форензики.
Комбинированный подход
Наиболее эффективный на наш взгляд подход, который рассмотрим далее на примере, имевшим место быть в реальной практике.
В контролируемой сети средствами SIEM были зарегистрированы инциденты в виде массовых попыток эксплуатации уязвимостей с узла 93.38.176.186. Через некоторое время был зарегистрирован инцидент в виде исходящего с контролируемого узла 83.1.1.100 DMZ зоны сетевого обращения к вредоносному IP 185.202.174.91. Оба узла 93.38.176.186, 185.202.174.91 посредством загруженных в SIEM TI фидов был атрибутированы как C&C сервера хакерского ПО Cobalt Strike. Было необходимо провести оценку поверхности заражения с последующим выстраиванием таймлайна атаки, при этом отсутствовали какие-либо другие признаки заражения данным ВПО, вследствие чего было принято решение провести Threat Hunting по Cobalt Strike.
Используя многочисленные гайды по обнаружению Cobalt Strike, были выделены следующие индикаторы атак, по которым был осуществлен ретроспективный поиск в логах SIEM в окрестности обнаруженных инцидентов, в результате чего был получен следующий таймлайн атаки.
Далее приведены запросы поиска индикаторов атак на языке Elastic (KQL)
1) Запуск системного процесса Rundll32 без параметров (журнал безопасности Windows Eventlog, событие создание процесса): стадия Execution, техника Command and Scripting Interpreter (T1059) по матрице Mitre Attack:
event.provider:Microsoft-Windows-Security-Auditing and event.action:created-process and process.name: rundll32.exe and process.command_line : *\\rundll32.exe
2) Повышение привилегий до системной учетной записи NT AUTHORITY\SYTEM посредством техники Named Piped Impersonation (журнал безопасности Windows Eventlog, событие создания процесса) с целью вероятной дальнейшей компрометации учетных записей: стадия Privilege Escalation, техника Access Token Manipulation (T1134):
event.provider:Microsoft-Windows-Security-Auditing and event.action:created-process and process.name: rundll32.exe and process.command_line : C\:\\Windows\\system32\\cmd.exe /c echo * \>; \\\\.\\pipe\\*
3) Горизонтальное распространение методом psexec с созданием службы и характерной powershell командной строкой в файловом пути службы (журнал безопасности Windows System, событие создания службы, код события 7045): стадия Lateral Movement, техника Remote Services (T1045):
event.provider:Service Control Manager and event.code:7045 and winlog.event_data.ImagePath :%COMSPEC% /b /c start /b /min powershell -nop -w hidden -encodedcommand*
4) Командное взаимодействие с центральной нодой и управляющим C&C сервером через именованные пайпы (журнал Windows Sysmon, событие создания именованного пайпа, код события 17): стадия Command and Control, техника Application Layer Protocol (T1071):
event.provider:Microsoft-Windows-Sysmon and event.code:17 and file.name : (\\msagent_* OR \\MSSE-*-server OR \\postex_* OR \\status_* OR \\mypipe-f* OR \\mypipe-h*)
Выводы
Для того, чтобы выстроить цепочку атаки, нужна информация о попытках несанкционированного взаимодействия с инфраструктурой и инструменты, с помощью которых эту информацию можно получить и обработать. В идеальном случае это системы классов SOAR/IRP или XDR, которые большую часть информации обрабатывают в автоматическом режиме.
Например, IRP от Security Vision в автоматическом режиме анализирует поток событий от SIEM, сама группирует их, выстраивая цепочку предполагаемой атаки, и даже сама определяет, к каким разделам MITRE ATT&CK могут относиться выявленные инциденты, и предоставляет рекомендации по устранению угрозы. Человеку остается только вникнуть в ситуацию и либо прямо в интерфейсе карточки атаки выполнить необходимые действия по реагированию на угрозу, либо выяснить, что действия были легитимными и пометить атаку как False Positive. К слову сказать, часть действий по реагированию может быть выполнено в автоматическом режиме в соответствии с настройками политик безопасности.
Использованные материалы
Cyber Kill Chain® | Lockheed Martin
How to detect stealthy Cobalt Strike activity in your enterprise (logpoint.com)