Alexander,
Typically, when message= information is missing from the event payload, this typically indicates an issue that the Windows Subscription itself (WEF/WEC) is not configured to use the following values:
- ContentFormat: RenderedText
- Locale: en-US
You can use this post to help confirm your settings (see the answered/check marked post as the information below is troubleshooting the issue): https://developer.ibm.com/answers/questions/466122/wincollect-sysmon-process-message-fields-are-blank/
If you have additional support/troubleshooting questions you are going to be best off asking here: https://ibm.biz/wincollectforums or opening a case with Support. As this forum link sorted by the WinCollect tag has better visibility to both support and the WinCollect development team.
You'll need to look at your configuration for your WEF/WEC setting in Windows as mentioned in that post as that is the most common issue with message= fields being blank/not containing data as expected.
------------------------------
Jonathan Pechta
QRadar Support Content Lead
Support forums: ibm.biz/qradarforums
jonathan.pechta1@ibm.com------------------------------
Original Message:
Sent: Wed July 31, 2019 02:48 PM
From: Alexander Halbarth
Subject: WinCollect: Windows Forwarded events missing Information in QRadar
Hello,
We are using Windows Event Forwarding to send all Events via a GPO to a central server which has the WinCollect Agent installed to send them to QRadar, since we cannot install Agents on all the Hosts themself.
We are currently evaluating the detection of malicious processes starts, but the messages of the forwarded events are empty in QRadars RAW logs and therefore also the custom fields are empty. The same events from the local machine that runs the WinCollect Agent are having all the information in the RAW logs and they get parsed like intended by the sysmon package.
This is a Log from the local machine that runs WinCollect:
<13>Jul 31 19:44:08 192.168.0.1AgentDevice=WindowsLog AgentLogFile=Security PluginVersion=7.2.9.72 Source=Microsoft-Windows-Security-Auditing Computer=WIN-AMK7SI37.testenv.domain OriginatingComputer=WIN-AMK7SI37.testenv.domain User= Domain= EventID=4688 EventIDCode=4688 EventType=8 EventCategory=13312 RecordNumber=914807 TimeGenerated=1564594930 TimeWritten=1564594930 Level=Log Always Keywords=Audit Success Task=SE_ADT_DETAILEDTRACKING_PROCESSCREATION Opcode=Info Message=A new process has been created. Creator Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: WIN-AMK7SI37$ Account Domain: TESTENV Logon ID: 0x3E7 Target Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Process Information: New Process ID: 0x2e48 New Process Name: C:\Program Files (x86)\TeamViewer\TeamViewer_Desktop.exe Token Elevation Type: %%1936 Mandatory Label: Mandatory Label\System Mandatory Level Creator Process ID: 0x1ec Creator Process Name: C:\Program Files (x86)\TeamViewer\TeamViewer_Service.exe Process Command Line: "C:\Program Files (x86)\TeamViewer\TeamViewer_Desktop.exe" --IPCport 5939 Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy. Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account. Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group. Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.
You can see that the message property is filled here and all forwarded events from other machines of the same Windows Event ID look like this:
<13>Jul 31 19:50:09 Win8.testenv.domain AgentDevice=WindowsLog AgentLogFile=Security PluginVersion=7.2.9.72 Source=Microsoft-Windows-Security-Auditing Computer=Win8.testenv.domain OriginatingComputer=Win8.testenv.domain User= Domain= EventID=4688 EventIDCode=4688 EventType=8 EventCategory=13312 RecordNumber=7873 TimeGenerated=1564595261 TimeWritten=1564595261 Level=Log Always Keywords=Audit Success Task=SE_ADT_DETAILEDTRACKING_PROCESSCREATION Opcode=Info Message=
You can see that a RecordNumber is here and the same Record in the Windows Events on the WinCollect Machine exists and has information in it, which is missing here.
Is there maybe any pitfall in configuring WinCollect with forwarded events?
Kind regards,
Alexander Halbarth