Event Tracing

Purpose

Event Tracing for Windows (ETW) provides application programmers the ability to start and stop event tracing sessions, instrument an application to provide trace events, and consume trace events. Trace events contain an event header and provider-defined data that describes the current state of an application or operation. You can use the events to debug an application and perform capacity and performance analysis.

This documentation is for user-mode applications that want to use ETW. For information about instrumenting device drivers that run in kernel mode, see WPP Software Tracing and Adding Event Tracing to Kernel-Mode Drivers in the Windows Driver Kit (WDK).

Where applicable

Use ETW when you want to instrument your application, log user or kernel events to a log file, and consume events from a log file or in real time.

Developer audience

ETW is designed for C and C++ developers who write user-mode applications.

Run-time requirements

ETW is included in Microsoft WindowsВ 2000 and later. For information about which operating systems are required to use a particular function, see the Requirements section of the documentation for the function.

Process ETW traces in .NET code

You can use the .NET TraceProcessing API to analyze ETW traces for your applications and other software components. This API is used internally at Microsoft to analyze ETW data produced the Windows engineering system, and it is also used to power several tables in Windows Performance Analyzer. This API is available as a NuGet package.

About Event Tracing

Event Tracing for Windows (ETW) is an efficient kernel-level tracing facility that lets you log kernel or application-defined events to a log file. You can consume the events in real time or from a log file and use them to debug an application or to determine where performance issues are occurring in the application.

ETW lets you enable or disable event tracing dynamically, allowing you to perform detailed tracing in a production environment without requiring computer or application restarts.

The Event Tracing API is broken into three distinct components:

• Controllers, which start and stop an event tracing session and enable providers
• Providers, which provide the events
• Consumers, which consume the events

The following diagram shows the event tracing model.

Controllers

Controllers are applications that define the size and location of the log file, start and stop event tracing sessions, enable providers so they can log events to the session, manage the size of the buffer pool, and obtain execution statistics for sessions. Session statistics include the number of buffers used, the number of buffers delivered, and the number of events and buffers lost.

Providers

Providers are applications that contain event tracing instrumentation. After a provider registers itself, a controller can then enable or disable event tracing in the provider. The provider defines its interpretation of being enabled or disabled. Generally, an enabled provider generates events, while a disabled provider does not. This lets you add event tracing to your application without requiring that it generate events all the time.

Although the ETW model separates the controller and provider into separate applications, an application can include both components.

For more information, see Providing Events.

Types of Providers

There are four main types of providers: MOF (classic) providers, WPP providers, manifest-based providers, and TraceLogging providers. You should use a manifest-based provider or a TraceLogging provider if you are writing applications for WindowsВ Vista or later that do not need to support legacy systems.

MOF (classic) providers:

• Use the RegisterTraceGuids and TraceEvent functions to register and write events.
• Use MOF classes to define events so that consumers know how to consume them.
• Can be enabled by only one trace session at a time.

WPP providers:

• Use the RegisterTraceGuids and TraceEvent functions to register and write events.
• Have associated TMF files (compiled into a binary’s .pdb) containing decoding information inferred from the preprocessor’s scan of WPP instrumentation in source code.
• Can be enabled by only one trace session at a time.

Manifest-based providers:

• Use EventRegister and EventWrite to register and write events.
• Use a manifest to define events so that consumers know how to consume them.
• Can be enabled by up to eight trace sessions simultaneously.

TraceLogging providers:

• Use TraceLoggingRegister and TraceLoggingWrite to register and write events.
• Use self-describing events so that the events themselves contain all required information for consuming them.
• Can be enabled by up to eight trace sessions simultaneously.

All event providers fundamentally use the Event Tracing family of APIs (TraceEvent for legacy technologies and EventWrite/EventWriteEx for newer ones). Event providers simply differ in what field types they store in event payloads and where they store the associated event decoding information.

Consumers

Consumers are applications that select one or more event tracing sessions as a source of events. A consumer can request events from multiple event tracing sessions simultaneously; the system delivers the events in chronological order. Consumers can receive events stored in log files, or from sessions that deliver events in real time. When processing events, a consumer can specify start and end times, and only events that occur in the specified time frame will be delivered.

For more information, see Consuming Events.

Missing Events

Perfmon, System Diagnostics, and other system tools may report on missing events in the Event Log and indicate that the settings for Event Tracing for Windows (ETW) may not be optimal. Events can be lost for a number of reasons:

The total event size is greater than 64K. This includes the ETW header plus the data or payload. A user has no control over these missing events since the event size is configured by the application.

The ETW buffer size is smaller than the total event size. A user has no control over these missing events since the event size is configured by the application logging the events.

For real-time logging, the real-time consumer is not consuming events fast enough or is not present altogether and then the backing file is filling up. This can result if the Event Log service is stopped and started when events are being logged. A user has no control over these missing events.

When logging to a file, the disk is too slow to keep up with the logging rate.

For any of these reasons, please report these problems to the provider of the application or service that is generating the events. These issues can only be fixed by the application developer or the service logging the events. If the missing events are being reported in the Event Log Service, this may indicate a problem with the configuration of the Event Log service. The user may have some limited ability to increase the maximum disk space to be used by the Event Log Service which may reduce the number of missing events.

Трассировка событий

Назначение

Трассировка событий для Windows (ETW) предоставляет программистам приложений возможность запускать и прекращать сеансы трассировки событий, инструментировать приложение для предоставления событий трассировки и использовать события трассировки. События трассировки содержат заголовок события и определяемые поставщиком данные, описывающие текущее состояние приложения или операции. События можно использовать для отладки приложения и выполнения анализа емкости и производительности.

Эта документация предназначена для приложений пользовательского режима, которые хотят использовать ETW. Сведения об инструментировании драйверов устройств, выполняемых в режиме ядра, см. в разделе Трассировка программного обеспечения WPP и Добавление трассировки событий для Kernel-Mode драйверов в наборе драйверов Windows (WDK).

Где применимо

Используйте ETW, если требуется инструментировать приложение, записывать события пользователя или ядра в файл журнала и использовать события из файла журнала или в режиме реального времени.

Аудитория разработчиков

Трассировка событий Windows разработана для разработчиков на C и C++, которые пишут приложения пользовательского режима.

Требования к среде выполнения

ETW входит в состав Microsoft Windows 2000 и более поздних версий. Сведения о том, какие операционные системы требуются для использования определенной функции, см. в разделе «требования» документации по функции.

Обработка трассировок трассировки событий Windows в коде .NET

Вы можете использовать API .NET трацепроцессинг для анализа трассировок трассировки событий Windows для приложений и других программных компонентов. Этот API внутренне используется в корпорации Майкрософт для анализа данных ETW, созданных в системе разработки Windows, а также для включения нескольких таблиц в анализаторе производительности Windows. Этот API доступен в виде пакета NuGet.

Event Tracing for Windows на стороне зла. Но это не точно

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

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

Работа с ETW

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

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

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

Посмотреть список провайдеров, которые подключены к определенному процессу 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

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

Читайте также:  Windows счетчики производительности диск

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Простейший анализ можно провести при помощи командной утилиты wevtutil.exe. Например, для просмотра 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 их вполне можно привести к читаемому виду.

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

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

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

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

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

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

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

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

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

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