$EventType in `im_wseventing` incorrectly parsed
Tags:
#1
RAZR
Hi,
I'm testing Nxlog EE trial
And configured nxlog as WEC with im_wseventing module,
but for some reason `$EventType` field Parsed to simple "`AUDIT`" not `AUDIT_SUCCESS` or `AUDIT_FAILURE`
In doc Possible values are: `CRITICAL, ERROR, AUDIT_FAILURE, AUDIT_SUCCESS, INFO, WARNING, and VERBOSE`.
Example of Event:
``` json
Jun 14 15:13:33 SRVTEST-00.test Microsoft-Windows-Security-Auditing[648]:
{
"MessageID": "uuid:1DB8B636-E34C-4DB5-951D-EEE30FD8F837",
"SourceName": "Microsoft-Windows-Security-Auditing",
"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",
"EventID": 4634,
"Version": 0,
"LevelValue": 0,
"EventType": "AUDIT",
"SeverityValue": 2,
"Severity": "INFO",
"OpcodeValue": 0,
"Keywords": "0x8020000000000000",
"EventTime": "2019-06-14 15:13:33",
"RecordNumber": 3437460,
"ExecutionProcessID": 648,
"ExecutionThreadID": 4980,
"Channel": "Security",
"Hostname": "SRVTEST-00.test",
"TargetUserSid": "S-1-5-18",
"TargetUserName": "SRVTEST-00$",
"TargetDomainName": "TEST",
"TargetLogonId": "0x2b06461",
"LogonType": "3",
"Message": "An account was logged off.\n\nSubject:\n\tSecurity ID:\t\tS-1-5-18\n\tAccount Name:\t\tSRVTEST-00$\n\tAccount Domain:\t\tTEST\n\tLogon ID:\t\t0x2B06461\n\nLogon Type:\t\t\t3\n\nThis 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.",
"Level": "Information",
"Task": "Logoff",
"Opcode": "Info",
"EventReceivedTime": "2019-06-14 15:13:35",
"SourceModuleName": "wseventin",
"SourceModuleType": "im_wseventing",
"HostIP": "192.168.5.5"
}
```
My nxlog config:
```
User nxlog
Group nxlog
Panic Soft
# default values:
PidFile /opt/nxlog/var/run/nxlog/nxlog.pid
CacheDir /opt/nxlog/var/spool/nxlog
ModuleDir /opt/nxlog/libexec/nxlog/modules
SpoolDir /opt/nxlog/var/spool/nxlog
define LOGDIR /opt/nxlog/var/log/nxlog
define MYLOGFILE %LOGDIR%/nxlog.log
LogFile %MYLOGFILE%
Module xm_syslog
Module xm_json
Module xm_resolver
Module xm_fileop
# Check the size of our log file hourly, rotate if larger than 5MB
Every 1 hour
if ( file_exists('%MYLOGFILE%') and
(file_size('%MYLOGFILE%') >= 5M) )
{
file_cycle('%MYLOGFILE%', 8);
}
# Rotate our log file every week on Sunday at midnight
When @weekly
Exec if file_exists('%MYLOGFILE%') file_cycle('%MYLOGFILE%', 8);
Module im_wseventing
Address http://srvtest-12.test:80/wsman
ListenAddr 0.0.0.0
Port 80
SubscriptionName testing
Exec $HostIP = name_to_ipaddr($Hostname);
Exec log_info(to_json());
*
*
*
Module om_file
File '/opt/nxlog/var/log/nxlog/winevent.log'
CreateDir TRUE
Exec $Message = to_json(); to_syslog_bsd();
Path wseventin => tofile
```
Is it bug or trial restrictions?
#1
RAZR
Hi,
I'm testing Nxlog EE trial
And configured nxlog as WEC with im_wseventing module,
but for some reason $EventType field Parsed to simple "AUDIT" not AUDIT_SUCCESS or AUDIT_FAILURE
In doc Possible values are: CRITICAL, ERROR, AUDIT_FAILURE, AUDIT_SUCCESS, INFO, WARNING, and VERBOSE.
Example of Event:
<14>Jun 14 15:13:33 SRVTEST-00.test Microsoft-Windows-Security-Auditing[648]:
{
"MessageID": "uuid:1DB8B636-E34C-4DB5-951D-EEE30FD8F837",
"SourceName": "Microsoft-Windows-Security-Auditing",
"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",
"EventID": 4634,
"Version": 0,
"LevelValue": 0,
"EventType": "AUDIT",
"SeverityValue": 2,
"Severity": "INFO",
"OpcodeValue": 0,
"Keywords": "0x8020000000000000",
"EventTime": "2019-06-14 15:13:33",
"RecordNumber": 3437460,
"ExecutionProcessID": 648,
"ExecutionThreadID": 4980,
"Channel": "Security",
"Hostname": "SRVTEST-00.test",
"TargetUserSid": "S-1-5-18",
"TargetUserName": "SRVTEST-00$",
"TargetDomainName": "TEST",
"TargetLogonId": "0x2b06461",
"LogonType": "3",
"Message": "An account was logged off.\n\nSubject:\n\tSecurity ID:\t\tS-1-5-18\n\tAccount Name:\t\tSRVTEST-00$\n\tAccount Domain:\t\tTEST\n\tLogon ID:\t\t0x2B06461\n\nLogon Type:\t\t\t3\n\nThis 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.",
"Level": "Information",
"Task": "Logoff",
"Opcode": "Info",
"EventReceivedTime": "2019-06-14 15:13:35",
"SourceModuleName": "wseventin",
"SourceModuleType": "im_wseventing",
"HostIP": "192.168.5.5"
}
My nxlog config:
User nxlog
Group nxlog
Panic Soft
# default values:
PidFile /opt/nxlog/var/run/nxlog/nxlog.pid
CacheDir /opt/nxlog/var/spool/nxlog
ModuleDir /opt/nxlog/libexec/nxlog/modules
SpoolDir /opt/nxlog/var/spool/nxlog
define LOGDIR /opt/nxlog/var/log/nxlog
define MYLOGFILE %LOGDIR%/nxlog.log
LogFile %MYLOGFILE%
<Extension _syslog>
Module xm_syslog
</Extension>
<Extension json>
Module xm_json
</Extension>
<Extension _resolver>
Module xm_resolver
</Extension>
<Extension _fileop>
Module xm_fileop
# Check the size of our log file hourly, rotate if larger than 5MB
<Schedule>
Every 1 hour
<Exec>
if ( file_exists('%MYLOGFILE%') and
(file_size('%MYLOGFILE%') >= 5M) )
{
file_cycle('%MYLOGFILE%', 8);
}
</Exec>
</Schedule>
# Rotate our log file every week on Sunday at midnight
<Schedule>
When @weekly
Exec if file_exists('%MYLOGFILE%') file_cycle('%MYLOGFILE%', 8);
</Schedule>
</Extension>
<Input wseventin>
Module im_wseventing
Address http://srvtest-12.test:80/wsman
ListenAddr 0.0.0.0
Port 80
SubscriptionName testing
Exec $HostIP = name_to_ipaddr($Hostname);
Exec log_info(to_json());
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Application">*</Select>
<Select Path="Security">*</Select>
<Select Path="System">*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
<Output tofile>
Module om_file
File '/opt/nxlog/var/log/nxlog/winevent.log'
CreateDir TRUE
Exec $Message = to_json(); to_syslog_bsd();
</Output>
<Route wec_to_file>
Path wseventin => tofile
</Route>
Is it bug or trial restrictions?
This shouldn't be a trial restriction. I would suggest taking off the Exec $Message = to_json(); to_syslog_bsd(); from your Output and see if this information is indeed captured through WEF.
Once you have taken that off, please update this post and we can see if this might be a bug.
