microsoft-krabsetw/docs/UsingMessageAnalyzerToFindETWSources.md

# Using Microsoft Message Analyzer to Find New ETW Sources

In order to make use of krabsetw to consume an ETW provider, you'll first need
to identify the schema of the events therein. This can be achieved with several
different tools but we'll focus on [Microsoft Message
Analyzer](https://www.microsoft.com/en-us/download/details.aspx?id=44226) for
now. If you haven't already installed it, please download and install it from
the link.

When you open Message Analyzer, you should see a screen similar to the
following:

![](img/message-analyzer/1.PNG)

Click the **New Session** button, as highlighted in the image above. You should
then be presented with a dialog that looks like this:

![](img/message-analyzer/2.PNG)

Click the **Live Trace** button, as highlighted in the image above. You should
then be presented with a dialog that looks like this:

![](img/message-analyzer/3.PNG)

Click the **Add Providers** button, as highlighted in the image above. You
should then be presented with a dialog that looks like this:

![](img/message-analyzer/4.PNG)

This dialog allows you to select the provider you're interested in. Typically,
when searching for new sources of ETW events, we'll enter in keywords like
"wininet" or "powershell" and see what providers are available. In this example,
we'll use the PowerShell ETW provider. Once you've found the
Microsoft-Windows-PowerShell provider, select it and click the "Add To" button.

After clicking ok, you should then have a provider added and have a window that
looks as follows:

![](img/message-analyzer/5.PNG)

In the window above, there's an option to configure the provider. This is a bit
of a tricky area with providers. There is no predefined standard on how the
configuration of a provider works but it is comprised of two flags: "All" and
"Any". In other words, the flags are implementation specific. These flags will
allow you to configure what events are actually emit and you will have to play
with them for each provider in order to properly pair down the events emitted.

For now, let's not configure any settings on the "Any" and "All" flags. Click
the "start" button in Message Analyzer

Now open up a powershell window and define a function named "invoke-mimikatz" in
there, similar to the following: `function invoke-mimikatz {}`. Type
`invoke-mimikatz` and hit enter, then switch back to the Message Analyzer
window.

You should roughly have something that looks like the following:

![](img/message-analyzer/6.PNG)

Look for events in the Message Analyzer window where the summary says "Command
invoke-mimikatz is Started". These are the events generated that we're
interested.

When you select that line in Message Analyzer, you should see a window like
this:

![](img/message-analyzer/7.PNG)

Let's talk about the three sections at the bottom now:

* Bottom Left: This is the "message stack" which allows you to see what
"messages" are associated with the event. In general, this is usually just the
event metadata (the second message, "Etw") and the provider specific
information (the first message, "Microsoft_Windows_PowerShell").

* Bottom Center: This window shows the properties associated with the event. In
particular, when you select one of the two messages from the left window, it
will show the properties as associated with that message. The "Etw" message's
relevant fields never change on a given OS - that is, the "Etw" message will
always have the same properties such as: `Id`, `Opcode`, `Flags`, and so on. A
good place to see how these properties are exposed with krabsetw is in the
[EventRecordMetadata](https://github.com/Microsoft/krabsetw/blob/master/O365.Security.Native.ETW/EventRecordMetadata.hpp) class.

* Bottom Left: This windows shows the "field data" which is simply the relevant
value of the property on the event message. If the event property is a
`string` then it's the string value in there and so on.

Now that we've discussed the three panes on the bottom, let's discuss this
particular event that we've selected. This event (id 7937) only contains one
interesting property called `ContextInfo`. This is a reflection of poor event
schema design by the provider authors but that's a discussion for a different
place. You will find that there are other providers that are better at providing
distinct properties in better types than a large string blob.

Now select the `ContextInfo` property and note the content of the bottom right
pane. In there, you'll see `Host Application`, `Command Name`, and `User` which
are relatively self-explanatory and provide us with some particularly interesting pieces of info to parse:

* We can use `Host Application` to identify suspect processes hosting the
PowerShell runtime. In general, we'd only expect to see powershell.exe and
wsmprovhost.exe hosting the PowerShell runtime so any other value would be
suspect.

* The `Command Name` gives us the name of the function invoked. If we have a
prohibited or permitted list we can check whether the command name is
expected.

* The `User` is self-explanatory and gives us the user that started the hosting
process.

## Conclusion

In order to make use of the information above, we'll need to parse out these
lines from the `ContextInfo` string blob. If you're interested in a sample
project to start doing this, please check out the
[PowerShellMethodAuditor](https://github.com/zacbrown/PowerShellMethodAuditor)
project.

Hopefully this will help you explore ETW providers for interesting information.
Please file an issue on [Github](https://github.com/Microsoft/krabsetw/issues)
if you run into any problems with this guide.