Dear Community,
Did anyone manage to successfully transform or parse Windows Event Logs (System, Security) that are coming from a Snare Agent such that they can be correctly parsed with one of the default parsers, such as WINEVTLOG?
We currently have a situation where Snare is already rolled out to ~5000 Windows servers and it would be awesome to utilize the existing setup.
Snare supports a couple of log formats (SNARE, SYSLOG (RFC3164), etc.).
Here is a log sample with the format SYSLOG (RFC3164):
<14>May 06 19:12:14 dc01.test.internal MSWinEventLog 6 Security 17349 Mon May 06 19:12:13 2024 4624 Microsoft-Windows-Security-Auditing TEST.INTERNAL\DC01$ N/A Success Audit DC01.test.internal Logon An account was successfully logged on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Information: Logon Type: 3 Restricted Admin Mode: - Virtual Account: No Elevated Token: Yes Impersonation Level: Impersonation New Logon: Security ID: S-1-5-18 Account Name: DC01$ Account Domain: TEST.INTERNAL Logon ID: 0xEC0D8E5 Linked Logon ID: 0x0 Network Account Name: - Network Account Domain: - Logon GUID: {2d702045-d877-02ce-c5de-ae3a379bd22e} Process Information: Process ID: 0x0 Process Name: - Network Information: Workstation Name: - Source Network Address: ::1 Source Port: 50724 Detailed Authentication Information: Logon Process: Kerberos Authentication Package: Kerberos Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon session is created. It is generated on the computer that was accessed. The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network). The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on. The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The impersonation level field indicates the extent to which a process in the logon session can impersonate. The authentication information fields provide detailed information about this specific logon request. - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. 1
Obviously, the WINEVTLOG parser cannot parse the above log.
There is a way to convert Snare WinEvt logs to JSON using NXlog (described here: https://docs.nxlog.co/integrate/snare.html#windows-event-log).
However, the issue is that the last part in the log with important information such as Logon ID, Logon Type, etc. is not extracted to individual fields, as it is required for the default WINEVTLOG parser to work.
Here is the example of how such a log looks like after conversion with NXLog:
{
"MessageSourceAddress": "127.0.0.1",
"EventReceivedTime": "2024-05-06 16:19:10",
"SourceModuleName": "tcp_listen",
"SourceModuleType": "im_tcp",
"Hostname": "dc01.test.internal",
"EventLogType": "Success Audit",
"Criticality": 1,
"LogName": "Security",
"SnareCounter": 7145,
"DateTime": "2024-05-06 16:19:09",
"EventID": 4634,
"SourceName": "Microsoft-Windows-Security-Auditing",
"UserName": "TEST\\DC01$",
"SIDType": "N/A",
"ComputerName": "DC01.test.internal",
"CategoryString": "Logoff",
"ExpandedString": "An account was logged off. Subject: Security ID: S-1-5-18 Account Name: DC01$ Account Domain: TEST Logon ID: 0xE9165B7 Logon Type: 3 This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.",
"MD5Checksum": "47"
}
The above cannot be parsed with the WINEVTLOG parser, since important fields such as TargetLogonId are missing and not extracted from the ExpandedString field. One would need to extract all of the fields manually for all of the Event IDs.
Alternatives, such as changing to WEF/WEC (unfortunately a very error-prone Windows feature) or rolling out an NXlog agent to all Windows servers (not feasible to manage the agents without NXLog Enterprise) introduces an incredible amount of additional effort.
Any help or experience on how to deal with Snare WinEvent logs is GREATLY appreciated!
Thanks a lot!
LinkedIn
Twitter
