Repository navigation
[BUG] ESCU CS fields LogonType and TargetUserName #2869
Description
Describe the bug
There are some CS that are not using the correct field name using the last version of the "Splunk Add-on for Microsoft Windows".
Expected behavior
Some CS need to be change to the correct field names.
Field Original Name > New Name
LogonType > Logon_Type
TargetUserName > Target_User_Name > user
https://github.com/search?q=repo%3Asplunk%2Fsecurity_content+LogonType&type=code
https://github.com/search?q=repo%3Asplunk%2Fsecurity_content+TargetUserName&type=code
https://github.com/search?q=repo%3Asplunk%2Fsecurity_content+Target_User_Name&type=code
App Version:
Splunk Version 9.0.4.1
ES Content Updates 4.12.0
Enterprise Security 7.1.1
Activity
hampusstrom commentedon Nov 13, 2023
After spending countless hours troubleshooting issues of this character i can conclude the following:
This is not a bug related to only the mentioned fields but a major issue across all of ESCU/Windows TA if you make use of XML formatted WinEventLog.
My experience from every version of the Windows TA and ESCU that I have used is that only a handful of fields actually have aliases or evals that convert from the PascalCase names found in XmlWinEventlog to the classic WinEventLog Snake_Case correctly and that most if not all ESCU searches make use of the classic WinEventLog field names.
The result is that many if not all the ESCU searches you activate in your XmlWinEventLog environment will never work, because the fields simply do not exist for XmlWinEventLog events.
To this you might respond "Why would you use Xml then?"
Language packs. Language packs, is the reason.
The alternative in an international or mixed language environment is that you will have to manually translate most if not all field extractions and evals to support all the languages in your environment.
Otherwise the result, again, is that few or none of the ESCU searches will work in your environment.
It is not a valid alternative.
In an english only environment i totally get it.
I have encountered this same issue across multiple production environments so I am pretty sure this is not an isolated case, and googling similar issues return multiple splunk community discussions on this exact topic.
My suggestion to fix these issue for good is for all fields names used in ESCU searches to be inventoried.
For each of these, create a field alias from the XmlEventLog equivalent value to the one used in the ESCU searches.
When this is done once, build a test suite to ensure that field aliases exist for any WinEventLog field name used so that these issues are never reintroduced.
Examples:
And so on
ulwur commentedon Nov 14, 2023
I can not stress enough how right hampusstrom is in his assesment of this problem. This problem makes Enterprise Security more or less useless for our clients of many languages.
josehelps commentedon Jan 23, 2024
Thank you so much for raising this up .. definitely a pain point we are now keenly aware of .. not sure what the exact plan for fix is yet but will make sure I come back to you once we have a fix.