Windows Log Output to Event Viewer or Text File

[Jason A. Donenfeld]

Hi Frank,

On Thu, Oct 14, 2021 at 3:45 PM Frank Wayne
<frank.wayne at northwestern.edu> wrote:
> The service approach is interesting, too. It would be simpler to ingest.

I started writing this, and got something basically working, but got a
bit tripped up in annoying lifetime issues of registering an event log
"source" in the registry, and the boggling configurability there. I'm
kind of shying away from it after an initial stab...

To answer the more concrete questions about a tail approach:

> Will every host have WireGuard installed? Forever?

This is a tougie, I guess in the same way that scooping up
non-streamed file-based logs are: at some point you have to do a sweep
to see if there are new files to grab, or in this case, if wireguard
has been installed. So on one hand, "polling" is pretty gnarly, but on
the other hand, you do that anyway for file-based logs I imagine.
There are probably other SCM-based or MSI-event based ways of doing
this without polling that are more complicated.

Does Splunk have any condition logic like, "do this collection routine
if file F exists; otherwise wait to do it until it exists"? If that
kind of thing is built in, then you're done. If not I agree this is an
annoying point.

> Is wireguard.exe in the PATH? For the user that Splunk runs under?

Yes. It's added to the system PATH.

> Should the script check the registry for the executable's location if it's not in the path?

No. The installer always sets PATH.

> Does that user have permissions to the WireGuard program directory?

Hmm. Here indeed is where the granular decoupled permission system of
Event Log comes in handy, I suppose. But in theory you should be able
to do the same for wireguard's log:
"%PROGRAMFILES%\wireguard\data\log.bin" is just a file path like any
other, and you can adjust its permissions accordingly. By default its
parent directory is O:SYG:SYD:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA), but
you could set a more particular ACL for log.bin itself.

> Can we run that script on endpoints without checking each team's security policy regarding in-house software running executables outside of its scope?

I imagine probably so in the sense that wireguard.exe is already
executed several times in a few different funny roles, so things might
already be sufficiently permissive. Have you seen any wireguard.exe
policies being passed around places? If you've got a link, I'd be
curious to see what people are doing.

Jason