Winlogbeat: best practice for 2003 logs only

Elastic Stack Beats
1

Questions Up Top:
-Is there any value in placing these logs onto a 2003 server instead of the Win10 laptop? As in, would Winlogbeat do a better job parsing into ECS if the logs were of the same format as the OS?
-Any other helps would be great

Use Case:
We have several 2003 servers to monitor. As they are 2003, nobody wants to add/change the servers so the only method is to grab the logs from the server. This ‘almost’ works as 20% of the logs are ECS parsed. Most of the SIEM does not populate. We are wondering if a better method might parse more info. We understand that this is a very unique use-case

Summary of Current Method:
Place these 2003 logs onto a Win10 laptop with winlogbeat pointed to the log locations

Details of Current Method:
As you know we currently have Elastic, Kibana and Winlogbeats installed on our win10 laptop. We have successfully pulled logs from the 2003 servers and placed them on our laptop where we combine all the logs (application, sec, system etc) into one EVTX file. This file has a custom name associated to the server and date

We then run winlogbeat –e –E EVTX={“FilePath”} which points winlog to this file and it gets ingested accordingly.

With that said… some issues we are finding is winlog.event_dataparam associated with random information and important information in the message is not being ID’d.

While I understand the winlog.event_dataparm(1-18) may not be resolved I am wondering if extracting information from the messages of event logs would…

In addition, I noticed that the winlog.API is set to wineventlog instead of the eventloggin API (which is said to be the API for Windows Server 2003).

According to Elastic the winlog.API is set automatically. I’m assuming it is choosing this API because of the win10 laptop?

First, would having it use the correct API fix some of these data.param and message problems?

If so, is there a way to change it via YML?

2

Winlogbeat is not supported on Windows 2003. It's written in Go and Go has stopped supporting 2003 (Windows · golang/go Wiki · GitHub).

The difference between running Winlogbeat on the machine that generated the logs and running it elsewhere is that some of the enrichments like SID to username may not work if the users differ between machines.

If you read an evtx on another machine then you should archive the evtx such that it includes the localized message strings from the source machine. Otherwise it will have to use message strings from the reader machine which might differ due to it being a different OS version and has different software installed.

The ECS mappings won't change based on the OS. Each event ID that is supported a module has its own mapping. Only the event IDs listed on the module's doc page will get transformed by the module. If not handled by the module then it will have the regular winlog fields and will not have event.module populated.

Yes, this is because the runtime OS supports the Windows Event Log API (wineventlog). (We are removing the eventlogging API support since Winlogbeat doesn't support any of the OSes that required it.)

No, this won't change the content of the messages. That's controlled by the thing that generated the message not the API used to read it.

3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.