Consuming from Microsoft-Windows-Security-Auditing

[matterpreter]

I'm working on some research that requires reading security event log data from the provider. I've done a bit of reading and it looks like the Krabsetw devs have found a way of do so by opening a handle to the EventLog-Security trace sessions created by the OS via their UserTrace() class. I've reviewed the Ferrisetw code and it looks like a possibility via the open_trace() function. It looks like @daladim had some concerns about doing so, so I wanted to see if I could get some more details before I start working on a PR for this feature.

[daladim]

Hello.
I shifted focus and I'm no longer using ETW on a daily basis, so I may not be super helpful there :-/

I can try to collect my memories and answer your questions. If you're interested in this, can I ask you two questions first ?

• Can't you do what you describe already, using the Provider and KernelTrace (UserTrace?) that currently exist?
• what concerns did I had about this? I'm afraid I cannot remember :D

In case you end up doing an MR, it would surely be appreciated, but I'll let @n4r1b answer, as I'll probably have no way to review it, let alone test it.

[n4r1b]

I've looked a bit into this and the main "problem" is that we are propagating the error when trying to start a trace that already exists (ERROR_ALREADY_EXISTS) -- The case for this EventLog-Security trace -- which leads to the TraceBuilder failing hence we can't even get a trace.

krabsetw solves this with the following steps (see trace_manager::register_trace)

• If StartTrace fails with ERROR_ALREADY_EXISTS try to Stop trace.
• If can't stop check if we can do the sequence Open - Close trace, meaning we can process it.

Given the program doesn't throw an exception in any of those steps then they proceed to re-open the trace. (See trace_manager::open)

I would assume @daladim concerns had something to do with the fact that this approach hides the error and it can be a bit invasive. I would love to hear more thou I can't remember either 😅.

---

At the moment I don't have a clear idea on how to solve this in a cleaner way than using the same approach krabsetw is taking.
The main idea would be to handle the case where the call to start_trace during the TraceBuilder::start function returns EvntraceNativeError::AlreadyExist and proceed trying to open a handle to the trace regardless of this error.
Optionally, we could think of adding some flag to the TraceBuilder structure to mark this as a trace we want to Open instead of trying to start, hence we could directly skip the call to start_trace and just try to open a handle to it (This would require some testing to make sure we don't break anything 😄).
@daladim I know you have shifted focus from ETW, but I'd love to hear your opinion on this :)