I am running into an issue where the TaskCategory field extracted by the Splunk Add-On for Windows does not match the TaskCategory on the generating system.
I am using Splunk 9.4.3 in standalone mode.
Splunk Add-On for Windows 9.1.1 is installed on Splunk Enterprise and deployed to UniversalForwarders on Windows 11.
My inputs are:
[WinEventLog://Security]
disabled = 0
renderXml=false
index = ta_windows
For some reason Splunk is ignoring the TaskCategory in the event and overriding the value with (in many cases) the same value when using Classic event format. In the screenshots, "Process Termination" is used for all events where there should be 5 unique categories.
Experimenting with inputs configurations, I noted that this problem does not exist when renderXML is set to true. I have tried this in a couple different environments (all 9.x for Splunk and Add-On) observing the same behavior in each.
Any thoughts on why this is happening and how to fix it?
I pulled _raw (Show Source) for the events in my screenshot and the "TaskCategory" value matches the table output, no "Task" field to be found though. I also checked the text-based versions of logs on the generating host and the "TaskCategory" values for the original events track with what I would expect them to be, so the issue seems to be between the UF and Indexer.
11/21/2025 08:28:19 AM LogName=Security EventCode=4689 EventType=0 ComputerName=DESKTOP-1VBIRTE SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=291156 Keywords=Audit Success TaskCategory=Process Termination OpCode=Info Message=A process has exited. Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: DESKTOP-1VBIRTE$ Account Domain: WORKGROUP Logon ID: 0x3E7 Process Information: Process ID: 0x714 Process Name: C:\Windows\System32\svchost.exe Exit Status: 0x0
11/21/2025 08:28:19 AM LogName=Security EventCode=4688 EventType=0 ComputerName=DESKTOP-1VBIRTE SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=291155 Keywords=Audit Success TaskCategory=Process Termination OpCode=Info Message=A new process has been created. Creator Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: DESKTOP-1VBIRTE$ Account Domain: WORKGROUP Logon ID: 0x3E7 Target Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Process Information: New Process ID: 0x2728 New Process Name: C:\Windows\System32\svchost.exe Token Elevation Type: TokenElevationTypeDefault (1) Mandatory Label: Mandatory Label\System Mandatory Level Creator Process ID: 0x338 Creator Process Name: C:\Windows\System32\services.exe Process Command Line: ...[truncated for brevity]
11/21/2025 08:28:19 AM LogName=Security EventCode=4672 EventType=0 ComputerName=DESKTOP-1VBIRTE SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=291153 Keywords=Audit Success TaskCategory=Process Termination OpCode=Info Message=Special privileges assigned to new logon. Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: SYSTEM Account Domain: NT AUTHORITY Logon ID: 0x3E7 Privileges: SeAssignPrimaryTokenPrivilege SeTcbPrivilege SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeBackupPrivilege SeRestorePrivilege SeDebugPrivilege SeAuditPrivilege SeSystemEnvironmentPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
11/21/2025 08:28:19 AM LogName=Security EventCode=4670 EventType=0 ComputerName=DESKTOP-1VBIRTE SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=291154 Keywords=Audit Success TaskCategory=Process Termination OpCode=Info Message=Permissions on an object were changed. Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: DESKTOP-1VBIRTE$ Account Domain: WORKGROUP Logon ID: 0x3E7 Object: Object Server: Security Object Type: Token Object Name: - Handle ID: 0x860 Process: Process ID: 0x338 Process Name: C:\Windows\System32\services.exe Permissions Change: Original Security Descriptor: D:(A;;GA;;;SY)(A;;RCGXGR;;;BA) New Security Descriptor: D:(A;;GA;;;SY)(A;;RC;;;OW)(A;;GA;;;NT SERVICE\gpsvc)
11/21/2025 08:28:19 AM LogName=Security EventCode=4627 EventType=0 ComputerName=DESKTOP-1VBIRTE SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=291152 Keywords=Audit Success TaskCategory=Process Termination OpCode=Info Message=Group membership information. Subject: Security ID: S-1-5-18 Account Name: DESKTOP-1VBIRTE$ Account Domain: WORKGROUP Logon ID: 0x3E7 Logon Type: 5 New Logon: Security ID: S-1-5-18 Account Name: SYSTEM Account Domain: NT AUTHORITY Logon ID: 0x3E7 Event in sequence: 1 of 1 Group Membership: BUILTIN\Administrators Everyone NT AUTHORITY\Authenticated Users Mandatory Label\System Mandatory Level ...[truncated for brevity]
11/21/2025 08:28:19 AM LogName=Security EventCode=4624 EventType=0 ComputerName=DESKTOP-1VBIRTE SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=291151 Keywords=Audit Success TaskCategory=Process Termination OpCode=Info Message=An account was successfully logged on. Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: DESKTOP-1VBIRTE$ Account Domain: WORKGROUP Logon ID: 0x3E7 Logon Information: Logon Type: 5 Restricted Admin Mode: - Remote Credential Guard: - Virtual Account: No Elevated Token: Yes Impersonation Level: Impersonation New Logon: Security ID: NT AUTHORITY\SYSTEM Account Name: SYSTEM Account Domain: NT AUTHORITY Logon ID: 0x3E7 Linked Logon ID: 0x0 Network Account Name: - Network Account Domain: - Logon GUID: {00000000-0000-0000-0000-000000000000} Process Information: Process ID: 0x338 Process Name: C:\Windows\System32\services.exe Network Information: Workstation Name: - Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: Advapi Authentication Package: Negotiate Transited Services: - Package Name (NTLM only): - Key Length: 0 ...[truncated for brevity]
Interesting. I'd go to the source UF and check its Event Log Viewer - what do the events look like there. Does the <Task> code differs between events in the XML view? Does the rendered view contain different Task Categories? Or all contain the same one? I don't think UF does anything with the events on its own.
I used the "Copy Details as Text" option in Event Viewer for an arbitrary event on the source UF to view the Classic and XML formatted version of the event.
The XML version contains an integer for the Task value, which I understand is used by the TA to obtain the TaskCategory via lookup table. The Classic version contains the "Task Category" field by default. Poking through the TA's props.conf, I don't see any destructive logic that would cause "Task Category" in Classic to be overwritten, just field aliasing as far as I can tell.
Exactly. That's why it's puzzlling. If you felt very inquisitive you could disable encryption on the UF outgoing communication and peek into the traffic or increase debug on the UF and see what is going out of the UF.
I ran a packet capture with Wireshark and learned that the TaskCategory is being manipulated on the UF side.
Note the TaskCategory of "Process Termination" where it should have been "Logon".
Wireshark:
Event Viewer:
Event Viewer (Copy Details as Text):
Yup. Seems like either windows returns wrong contents to UF's subscription or UF does something strange on its own but that would be even more puzzling.
The last two things I'd check before raising a support case is how windows returns events if you return them with powershell. And raise debug level on the UF and see in its logs what's happening. (but that's gonna be messy)
Hmm... With XML-rendered windows events the TaskCategory field comes from an automatic lookup which maps the numerical value from the Task field onto a meaningful description.
I haven't dealt with "classic" windows logs for a long time so I don't remember whether the Task Category is included in the event itself or is it also mapped from somewhere.
Check your raw data if and see if it contains fields Task and TaskCategory (and if so, what are their values).
Don't search | table - just look into raw event.