first of all, sorry to bother you with a question that might be easy for you, but im a bit lost.

I would like to know if NXlog is compatible with WEF ?


Long story made short, I plan on using NXlog to output to my SIEM Security logs of Windows Domain Controller following this guide : 


wich as you can see, is to configured windows event forwarding ( to reduce the number of nxlog installation on critical server )


Once that first part done, I would like to know what config I should set to be able to "fetch" all of the "Forwarded Event" on my "windows log collector" ?



Thank you !


AskedSeptember 13, 2017 - 6:52pm

Answer (1)

The im_msvistalog does not currently parse the full data when received from Forwarded Events but it still does work:

<Input eventlog>
  Module      im_msvistalog
     <Query Id="0"> 
        <Select Path="ForwardedEvents">*</Select>

The NXLog Enterprise Edition comes with a module called im_wseventing that can be used to receive Windows Eventlog forwarded over WEF and this works on all platforms not only on Windows.

Note that WEF is limited to Windows Eventlog and you cannot forward files or ETW so in many cases it still makes sense to use NXLog deployed as an agent.

See the NXLog User Guide about collecting Windows Eventlog.

Comments (12)

  • gh0stid's picture



    thank you for the reply, just making sure to understand, what exactely do you mean by "not parsing" ? it will be sent to my logstash "raw" ? wont be able to "index the data" ?

  • sejoneshull's picture


    Hope you don't mind me bumping this. I'm new (as of this week new!) to NXLog as we're evaluating Alienvault for our SIEM needs, with a view to moving from our present platform using its own native agents. Our present SIEM has been hassle but one of the things it has done very well has been Forwarded Events from our Domain Controllers into a single load balanced pool of event collectors - using the MS recommended approach of Windows Event Forwarding and Event Collection, and utilising subscriptions to keep a subset of those events we want to keep whilst dropping those that have little security event use.

    I did try msvistalog but the lack of bringing over the EventData part of the events is a problem. So, I've just downloaded a trial of NXLog Enterprise to test out wseventing.

    Would anyone be kind to post a working NXLog config? I'm getting into a bit of a mess trying to do so. Also, do you have to use certificates for https when running NXLog wseventing on a Windows collector? As it stands, we use http/5986 currently, and for the purpose of evaluating/testing the trial, and that I'm having to do this alongside keeping our live Windows Event Forwarding/Collection running uninterrupted, it would make it easier. Some of the examples seem to suggest so, but I get an error about it in NXLog. Our Domain Controllers and Event Collectors are both 2012R2, and Windows/domain members - can I not just use Kerberos for this?

    Thanks in advance!

  • Zhengshi's picture

    In regards to your WEF collection, yes Kerberos is supported along with HTTPS.
    It is a lot to read, but there is some great information and even some kerberos examples in the manual.

  • sejoneshull's picture

    Thanks Zhenghsi,

    I've read that, but it sets it out in detail for when Kerberos is used with a Linux-based collector in conjunction with a Windows forwarder (i.e. domain controllers), but rather than Windows collector and forwarder together.

    I tried to build my NXLog config like so (redacting the HTTPS/cert entries):


    SuppressRepeatingLogs FALSE

    <Extension json>
    Module xm_json

    <Input wseventing>
    Module im_wseventing
    Address https://<collectoraddress>:5985/wsman
    Port 5985
    Exec log_info(to_json());
    <Query Id="0" Path="Application">
    <Select Path="Application">*</Select>
    <Select Path="Security">*</Select>
    <Select Path="System">*</Select>
    <Select Path="ForwardedEvents">*</Select>

    <Output out_wsevents>
    Module om_udp

    #Use the following line for debugging (uncomment the fileop extension above as well)
    #Exec file_write("C:\\Program Files (x86)\\nxlog\\data\\nxlog_output.log", $raw_event);

    <Route route_wsevents>
    Path wseventing => out_wsevents

    But that generates the following in the data log:

    2018-12-07 13:52:20 ERROR https is required for im_wseventing without kerberos support at C:\Program Files\nxlog\conf\nxlog.conf:265
    2018-12-07 13:52:20 WARNING no functional input modules!
    2018-12-07 13:52:20 ERROR module 'wseventing' has configuration errors, not adding to route 'route_wsevents' at C:\Program Files\nxlog\conf\nxlog.conf:295
    2018-12-07 13:52:20 ERROR route route_wsevents is not functional without input modules, ignored at C:\Program Files\nxlog\conf\nxlog.conf:295
    2018-12-07 13:52:20 INFO nxlog-4.1.4108-trial started
    2018-12-07 13:52:20 WARNING not starting unused module out_wsevents
    2018-12-07 13:52:20 WARNING not starting unused module wseventing

    (I've tried both http:5985, and https:5986).
    If I have to use certificates, then we do have an AD enterprise/root CA which I could do so, but for Windows collectors and forwarders in the same domain, it just seemed like an additional overhead we wouldn't need?!

    Any help/working configs for this sort of scenario would be really welcome!

  • b0ti's picture

    Unfortunately the windows build of im_wseventing does not support kerberos mode so your only option with that is via HTTPS currently. I understand that certificate management in this situation would be an additional overhead.

    Work is in progress to implement the parsing of <RenderingInfo> so that im_msvistalog would be able to correctly read from ForwardedEvents. This is expected in a later version of the NXLog Enterprise Edition.

  • sejoneshull's picture

    Thanks b0ti, that's useful to know, as being able to simply pull in events from ForwardedEvents would make integrating into existing solutions much easier.

    For the timebeing, we've managed to workaround this, by utilising our existing forwarder/collector set-up from AD domain controllers to load balanced event collectors, on 5985. Then, we're using the Alienvault built-in event sensor app on 5986, which appears to support im_wseventing, so we could simply set it up to read from the ForwardedEvents log. This appears to be parsing and processing data properly within Alienvault so we can resolve username, source ip/hostname, destination ip/hostname (e.g. client > domain controller, or service > domain controller), with the event ID, etc.

    I'm going to continue to play with NXLog Enterprise trial for now, as we'll still likely utilise it for some of our needs, but although the above is a little bit of a workaround in two parts, it does allow us to fit around our existing environment.


  • b0ti's picture

    Another thing to be aware of is that DCs can produce a lot of data and WEF needs resources to ship that. If you would be fetching data from ForwardedEvents this just fuels that fire. Based on customer feedback using NXLog as an agent is the most efficient in such a scenario.

  • sejoneshull's picture

    Thanks, yes, should say at present we're already filtering the existing event forwarder/collectors through subscriptions to only the events that we've identified are useful to us - to remove the noise and sheer amount of data. If we, and its very likely in the last day or so based on conversations with colleagues, that we will move to NXLog local installs to achieve greater control on individual level (i.e. server/dc/desktop and what we're wanting to collect from each of them).

    Appreciate all your input on this, b0ti!