-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for WEVT_TEMPLATE evtx template structure parsing #103
Comments
Hi @williballenthin, thanks for your work on this, it looks really cool 😄 It sounds reasonable to extend I'll need some time to look into this properly - and I'm a little constrained right now since this isn't something I can spend time at work on. I'll try to get to this in some upcoming weekend. |
Yup, I totally understand. To be clear, I hate to open issues that I won't put effort towards myself, so I hope you don't feel that this creates a burden on you. For me, I think the biggest question is how to express, construct, and document the code that can parse lots of flavors of the evtx format (there's this immediate issue, and then potentially different versions of the evtx format, etc.). The obvious thing to do is have lots of flags and lots of if/else statements, though it starts to get difficult to track, test, etc. So, before I go opening up a PR that adds a new boolean that's passed all around, I wondered if you had any great ideas here. |
I agree that adding a lot of if-else branches can get cumbersome, but I think if it's just this small bit of behavior we could probably let it slide. In general I believe that "duplication is better than the wrong abstraction". But, if we would need to abstract over it - we would probably need to create some sort of visitor abstraction over the node types, and provide EVTX visitors which behave like the code we have at the moment, and WEVT visitor which can behave differently, and so we would have:
and:
I think this would require some refactoring though, and it's probably only worth pursuing if WEVT and EVTX differ by more than a few bits of state. |
My approach with kpulp was to "raid" the target system for DLLs which contain expansion strings and then use those. I've looked into parsing those out from PE structure of associated DLLs that are registered as message template providers which seems quite feasible. It's a tarpit. |
In a recent discussion, it became clear to me that there's a desire for evtx tooling that supports an offline database of templates. Here's some some relevant background on the topic:
The forensikblog.de post describes exactly my goal: to process the resource directory of PE files and collect evtx templates for subsequent use. For example, to put the templates in a sqlite database, carve evtx records from unallocated space, and render the records using the templates from the database. Going forward, I expect to use this evtx library over python-evtx, for many reasons :-).
However, getting this to work may take some changes to this evtx library. I'll describe what I find in this thread. I hope that we can work together to support all these use cases!
Incidentally, I've been chatting with @forensicmatt whose also interested in working with evtx templates, so he may chime in too.
wevt_template is my work in progress project for extracting evtx templates from PE files.
Here is services.exe (renamed to gif extension) that I'll reference below.
In the attached
services.exe
at offset 0xA3020 with length 0x4b7e is the embedded instrumentation manifest that includes evtx templates:Notably, this
services.exe
from Win10 2020H1 uses the CRIM version 5.1 (in contrast to the libexe description for version 3.1). We'll see why this matters in a moment.At 0xA306C is the start of an event provider structure (WEVT) for
Microsoft-Windows-Services/Diagnostic
:At 0xA3128 is the template table (TTBL) and finally at 0xA315C is a binary XML template structure. Ideally, we'd be able to parse the data using this evtx library. I'm currently using the following to parse the data:
Anyways, here is the binary template:
Unfortunately, this doesn't parse well with the code from this library. Let me explain what I see:
My guess is that in (at least) format version 5.1 (or 4+???), strings are stored inline rather than as references. I think the structure for tag
01
is maybe:This inline string strategy seems to be used in other parts of the template, too.
I think these strings share a structure with the
BinXmlName
described by libevtx:So, I wonder if its reasonable to extend
read_open_start_element
to support this variant of the format. And if so, how to manage the set of features that each variant may support (evtx-file-mode vs WEVT_MODE vs ....).In a subsequent discussion, assuming we can parse out these templates, then we can chat about how to apply the templates toward data carved from allocated space. But, I haven't gotten this far, yet :-)
The text was updated successfully, but these errors were encountered: