Fix stale TA field names in XML WinEventLog detections - #4290
Closed
Varshith-Kali wants to merge 1 commit into
Closed
Varshith-Kali wants to merge 1 commit into
Varshith-Kali wants to merge 1 commit into
Conversation
The Splunk Add-on for Microsoft Windows extracts snake_case field names (Logon_Type, Target_User_Name) from XmlWinEventLog events via its REPORT extractions; the PascalCase names (LogonType, TargetUserName) are stale. 35 detections still referenced the stale names, so they silently stopped matching on current TA versions. Rename LogonType -> Logon_Type and TargetUserName -> Target_User_Name in search and drilldown SPL across 35 detections, following the convention already used by migrated detections (e.g. windows_rdp_login_session_was_established, the 4648 Target_User_Name detections). EventCode 4781's OldTargetUserName / NewTargetUserName have no snake_case variant in the TA and are left untouched. Prose documentation is unchanged to keep the diff reviewable. Version bumped and modification_date updated per repo convention. Fixes splunk#2869. Signed-off-by: Varshith Puli <pulivarshit@gmail.com>
Varshith-Kali
requested review from
P4T12ICK,
RavenTait,
ljstella,
nasbench,
onurmerdogan,
patel-bhavin,
pyth0n1c,
rosplk and
tccontre
as code owners
September 24, 2026 15:12
Contributor
|
Hey @Varshith-Kali thanks for opening this PR. Unfortunately, the fix that you are proposing is not the right one we would like to see. Basically, the issue is between XML/Non-XML logs. The way certain fields are represented changes between the 2, and more importantly one is localized while the other is not. We have some content written against the different source types which led to this issue. The fix is to actually re-generate logs for the non XML versions and use that instead, because that is what we opted towards many years ago. I am working on an actual fix, so no worries on that regard. Meanwhile. I will be closing this PR for now |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes #2869.
The Splunk Add-on for Microsoft Windows extracts snake_case field names (
Logon_Type,Target_User_Name) fromXmlWinEventLogevents via sourcetype-wide REPORT extractions, so 35 detections still referencing the stale PascalCase names (LogonType,TargetUserName) silently stopped matching on current TA versions.Changes
LogonType→Logon_TypeandTargetUserName→Target_User_Nameinsearchanddrilldown_searchesSPL across 35 detections, including thefindingblock (titletoken andentity.field) inwindows_domain_admin_impersonation_indicator.ymlso drilldowns and finding metadata stay consistent.version+1 and setmodification_date: 2026-09-24in each changed file per repo convention.OldTargetUserName/NewTargetUserName(no snake_case variant exists in the TA) and prose documentation — kept the diff reviewable.Tests
yamllint -c .yamllinton all changed files: clean.search,drilldown_searches, orfindingblock.contentctl-ng test(functional unit tests) requires Docker/Splunk infra not available here — will run in CI.