Продвинутое логирование Windows. Ищем mimikatz

  • Tutorial

Всем привет. Сегодня рассмотрим пример, когда злоумышленнику удалось обойти Windows Defender, но не удалось — безопасника. Да, речь опять про mimikatz. Как, запуская mimikatz, обойти Windows Defender, можно почитать тут. А сегодня, как я и обещал, рассмотрим что-нибудь для «синей» команды. Если это хоть кому-нибудь поможет, значит — все не зря. Итак, поехали.

Про стек ELK (Elasticsearch, Logstash, Kibana) написано немало (в том числе и на хабре), и сегодня мы будем использовать его, а если быть точнее — допиленный под наши нужды ELK для threat hunting.

The Hunting ELK, или HELK


Схема HELK выглядит вот так:



Перейдем к установке.

В качестве сервера, где будет располагаться HELK, я выбрал, как и советует разработчик:

tomhunter@helk:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS" 

Установка проста и выполняется в 2 команды:

git clone https://github.com/Cyb3rWard0g/HELK
tomhunter@helk:~/HELK/docker$ sudo ./helk_install.sh

Примечание: возможно, вас попросят выделить больше ОЗУ для установки. Я использую 10 ГБ.

Из предложенных вариантов установки я выбрал KAFKA + KSQL + ELK + NGNIX + ELASTALERT. А теперь просто ждем. И, если мы все сделали правильно, мы увидим заветное:



С сервером закончили, давайте подготовим клиент. В качестве него будет выступать машина с ОС Windows 10. На него нам нужно установить Sysmon.

Так же нам нужен файл конфигурации:

 git clone https://github.com/olafhartong/sysmon-modular  

Сгенерируем конфиг:

 . .\Merge-SysmonXml.ps1
Merge-AllSysmonXml -Path ( Get-ChildItem '[0-9]*\*.xml') -AsString | Out-File sysmonconfig.xml

Выполним:

 PS C:\Users\Tomhunter\Documents\sysmon-modular> .\Sysmon64.exe -i .\sysmonconfig.xml 

Также установим winlogbeat, удалим файл winlogbeat.yml и создадим новый, скопировав в него
raw.githubusercontent.com/Cyb3rWard0g/HELK/master/configs/winlogbeat/winlogbeat.yml

Примечание: и здесь нам нужно поменять IP адрес на нужный (в моем случае hosts: [«192.168.31.97:9092»].



Установим:

 PS C:\Users\Tomhunter\Desktop\winlogbeat-7.6.2-windows-x86_64> .\install-service-winlogbeat.ps1 

Примечание: сервис нужно включить руками, либо перезагрузить систему.

Все готово, давайте посмотрим, что у нас получилось.

Запускаем mimikatz на Windows 10.



И, зайдя в кибану (в моем случае — это 192.168.31.97, учетные данные по дефолту: helk:hunting) мы видим алерт. В сыром виде он выглядит так:



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

Но нам гораздо интереснее, как это работает, давайте разбираться.

Немного теории


После запуска mimikatz c Windows 10 улетает такое сообщение:



Что же смутило правило, выдавшее алерт? (спойлер: не имя файла mimikatz.exe). Давайте взглянем на само правило:

sudo docker exec -it helk-elastalert bash
cat /opt/sigma/rules/windows/sysmon/sysmon_mimikatz_detection_lsass.yml



EventID: 10. Это у нас ProcessAccess.

TargetImage: C:\windows\system32\lsass.exe. 

Это хорошо, но mimikatz же не единственный кто обращается к lsass.



GrantedAccess: 0x1410 или 0x1010.

И вот тут все встает на свои места. Объясняю.

Давайте заглянем в исходный код mimikatz, а именно нас интересует файл kuhl_m_sekurlsa.c и функция kuhl_m_sekurlsa_acquireLSA()



Обратившись на сайт майкрософта, мы видим, что

PROCESS_QUERY_LIMITED_INFORMATION (0x1000)
PROCESS_VM_READ (0x0010)
PROCESS_QUERY_INFORMATION (0x0400)

Применяя побитовое “ИЛИ” мы получаем наш Granted Access
Примечание: ранее в правиле sigma был детект только 0x1410, вероятно, это связано с тем, что старые версии mimikatz делали оба запроса (PROCESS_QUERY_INFORMATION и PROCESS_QUERY_LIMITED_INFORMATION), однако пропускало mimikatz с 0х1010, в связи с чем нужно было самому корректировать правило. Сейчас такой проблемы уже нет, и все работает из коробки.

Таким образом, если в кибане мы поставим фильтр
event_id: 10 AND process_target_name: "*lsass.exe" AND process_granted_access: «0x1010», то у нас останется только наш mimikatz.



Из приятного: правила есть и для mimikatz_inmemory, mimikatz_trough_winrm, и даже для safetycatz (версия mimikatz на .NET со своими фишками).

Что еще можно?


Правила, естественно, не ограничиваются mimikatz, их очень много. Они разбиты на категории application, cloud, compliance, linux, network, proxy, web и windows. Категории разбиты на подкатегории. Например, windows делится на builtin, malware, other, powershell, process_creation, sysmon.

И кто знает, возможно, включив в GPO логирование powershell, вы будете получать алерты по этим правилам:



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

Похожие публикации

Комментарии 5

    0
    После запуска mimikatz c Windows 10 улетает такое сообщение:

    Дилетанский вопрос… А кто посылает это сообщение и куда?
      0
      посылает служба winlogbeat, посылает к нам на сервер где расположен HELK
      0

      Надо будет допилить mimikatz, чтобы использовал два хендла, или вообще запускать рой процессов с обменом в SHM ;)

        0
        война «красных» и «синих» никогда не кончится =)
          +1

          Мой комментарий больше про то, что описанный в статье подход позволяет отлавливать "атаки" уровня script kiddie, но не замечает тривиальных вариаций. Тем более, не заметит чуть менее чем любую целевую атаку.


          Соответственно, сбор логов в условный эластик — это конечно больше чем ничего, но для отлавливания более-менее серьезных атак нужен "настоящий" SIEM с "корреляцией" событий разнесенных по времени. Появление подобных продуктов в Open Source, к сожалению, по ряду причин не предвидится.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое