Windows 2012r2 (and possibly others) NXLog parsing issue?
nwalters
Hello,
We are using NXLog extensively and just recently started seeing some parsing issues, so far specifically on Windows 2012r2 using Windows Event Forwarding, but could be others. It appears to be something with processing self-closed tags at first glance, but I've done a little bit of testing myself and couldn't directly reproduce the problem (so far), so figured I'd come here for guidance. Specific details are included below.
**Current Behavior**
NXLog appears to be improperly parsing empty, self-closed XML tags.
**Expected Behavior**
NXLog properly ignores empty, self-closed XML tags.
**NXLog Version**: nxlog-ce-2.10.2150
**NXLog Configuration File**:
```
## NXLog configuration file
define ROOT C:\Program Files (x86)\nxlog
define LOGFILE %ROOT%\data\nxlog.log
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %LOGFILE%
# Rotate agent logs on the local system such that only the last 4 files are kept
Module xm_fileop
# Check the size of our log file every hour and rotate if it is larger than 1M
Every 1 hour
Exec if (file_size('%LOGFILE%') >= 1M) file_cycle('%LOGFILE%', 4);
# Rotate our log file every week on sunday at midnight
When @weekly
Exec file_cycle('%LOGFILE%', 4);
Module xm_syslog
Module xm_json
# Agent logs
Module im_internal
# OS logs
Module im_msvistalog
# Drop EventID 5156 logs when application name is nxlog.exe
Exec if ($SourceName == 'Microsoft-Windows-Security-Auditing')\
AND ($EventID == 5156)\
AND ($Application =~ /nxlog.exe$/)\
drop();
Module im_msvistalog
Query \
\
*\
\
# SIEM port 3514 is listening for JSON-encoded IETF style syslog messages
# OutputType Syslog_TLS required to enable the octet-framing described in RFC5425
Module om_tcp
Host XXX.XXX.XXX.XXX
Port 3514
OutputType Syslog_TLS
Exec $Message = to_json();
# Remove param-value pairs from structured data header with names > 32 characters.
Exec if ($SourceName == 'Microsoft-Windows-GroupPolicy') {\
if ($EventID == 5017) OR ($EventID == 6017) OR ($EventID == 7017)\
delete($OperationElaspedTimeInMilliSeconds);\
if ($EventID == 5116) OR ($EventID == 6116) OR ($EventID == 7116)\
delete($GpsvcInitTimeElapsedInMilliseconds);\
if ($EventID == 5126) OR ($EventID == 6126) OR ($EventID == 7126)\
delete($GPODownloadTimeElapsedInMilliseconds);\
if ($EventID == 5257) OR ($EventID == 6257) OR ($EventID == 7257)\
delete($PolicyDownloadTimeElapsedInMilliseconds);\
if ($EventID == 5351) OR ($EventID == 6351) OR ($EventID == 7351)\
delete($WinlogonReturnTimeElapsedInMilliseconds);\
}
Exec to_syslog_ietf();
Path internal, eventlog, forwardedEvents => out
```
**Windows Version**: Windows 2012r2 (potentially others, but confirmed for sure on this one)
**Example Exported XML from EventViewer**
```
4688201331200x80200000000000005238702734Securityhostname.domainS-1-5-18workstation$DOMAIN0x3e70x1754C:\Windows\System32\wbem\WmiApSrv.exe%%19360x2f8S-1-0-0--0x0A new process has been created...InformationProcess CreationInfoSecurityMicrosoft Windows security auditing.Audit Success
```
**Example Data as Received on the wire**:
```
1 2019-10-21T15:44:36.650065-04:00 hostname.domain Microsoft-Windows-Security-Auditing 4 - [NXLOG@14506 Keywords="-9214364837600034816" EventType="AUDIT_SUCCESS" EventID="4688" ProviderGuid="{54849625-5478-4994-A5BA-3E3B0328C30D}" Version="2" Task="13312" OpcodeValue="0" RecordNumber="355111132" ThreadID="5020" Channel="Security" Category="Process Creation" Opcode="Info" SubjectUserSid="S-1-5-18" SubjectUserName="workstation$" SubjectDomainName="DOMAIN" SubjectLogonId="0x3e7" NewProcessId="0x13a8" NewProcessName="C:\\Windows\\System32\\wbem\\WmiPrvSE.exe" TokenElevationType="%%1936" CommandLine\'/>