Hello everyone!
I noticed at least one field being processed incorrectly after updating our Elasticsearch and Winlogbeats to 9.4.3 (from 8.x.x). I do not have other findings yet, but I doubt this is the only case.
Applocker-Events include a field called winlog.user_data.FileHash which is a String with 64 characters. Since the update to 9.4.3 this field contains a string, that begins with the 64 character Filehash but then continues to include the raw content of the fields winlog.user_data.fqbn and winlog.user_data.FullFilePath in Hex-code. However the fields winlog.user_data.fqbn and winlog.user_data.FullFilePath still exist separately in the parsed document.
When checking the Windows Eventlog the FileHash-Field is unchanged and only includes the hash itself. For debugging purposes I enabled "include_xml" in the winlogbeat.yml and the FileHash-Field was then promptly parsed correctly again.
Here you see the difference in FileHash between Clients with Winlogbeat 8.19 and 9.4:
Example Document from winlogbeat 9.4.3:
You can see that the FileHash-Field contains the Hash and then further information in HEX, which translates to:
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\
MICROSOFT® WINDOWS® OPERATING SYSTEM\
WMIC.EXE\
10.0.20348.2849
<NUL>
SysC:\Windows\SYSTEM32\WBEM\WMIC.exe
<NUL>
15
Is this a bug related to: https://github.com/elastic/beats/pull/42275 ? As I said the behaviour returns to normal if include_xml is enabled in winlogbeat - however this produces a big overhead according to the documentation, so I do not want to use this as a workaround.