Getting Data In

Splunk Add-On for Windows - Incorrect TaskCategory

nixhydra
Explorer

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.

Screenshot 2025-11-21 083052.png

Screenshot 2025-11-21 083136.png

Any thoughts on why this is happening and how to fix it?

 

 

0 Karma

nixhydra
Explorer

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]

0 Karma

PickleRick
SplunkTrust
SplunkTrust

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.

nixhydra
Explorer

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.

nixhydra_0-1764104502445.png

nixhydra_1-1764104532619.png

 

0 Karma

PickleRick
SplunkTrust
SplunkTrust

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.

0 Karma

nixhydra
Explorer

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:

nixhydra_0-1764360111281.png

Event Viewer:

nixhydra_1-1764360410888.png

Event Viewer (Copy Details as Text):

nixhydra_2-1764360497965.png

 

0 Karma

PickleRick
SplunkTrust
SplunkTrust

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)

0 Karma

PickleRick
SplunkTrust
SplunkTrust

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.

Get Updates on the Splunk Community!

Index This | What is broken 80% of the time by February?

December 2025 Edition   Hayyy Splunk Education Enthusiasts and the Eternally Curious!    We’re back with this ...

Unlock Faster Time-to-Value on Edge and Ingest Processor with New SPL2 Pipeline ...

Hello Splunk Community,   We're thrilled to share an exciting update that will help you manage your data more ...

Splunk MCP & Agentic AI: Machine Data Without Limits

Discover how the Splunk Model Context Protocol (MCP) Server can revolutionize the way your organization uses ...