Modify Security Events for EventCode 4624)

[Kosyay]

Hello!

I have logs from Domain Controller Active Directory in Splunk and try to configure monitoring of user logons (EventCode=4624). Unfortunately, there are two fields with a name "Account Name"

example of a log:

06/25/2025 02:54:32 PM LogName=Security EventCode=4624 EventType=0 ComputerName=num-dc1.boston.loc SourceName=Microsoft Windows security auditing. Type=Information RecordNumber=881265691 Keywords=Audit Success TaskCategory=Logon OpCode=Info Message=An account was successfully logged on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Impersonation Level: Impersonation New Logon: Security ID: BOSTON\*** Account Name: *** Account Domain: BOSTON Logon ID: 0x135F601B51 Logon GUID: {12C0DD76-F92B-07E1-88A5-914C43F7D3D5}

Could you please advise if it’s possible to modify the fields before indexing, i.e., at the "input" stage? Specifically, I'd like to change the first field Subject: Account Name to Source Account Name and the second field New Logon: Account Name to Destination Account Name.

From what I understand, this would require modifications in props.conf and transforms.conf.

If anyone has ideas on how to achieve this, please share!

[PickleRick]

Probably the easiest thing would be to switch from "traditional" format to XML logging. Now you're gathering a plain-text representation of windows events. This format has some limitations (one you've just hit) and on average consumes more license than the XML-formatted events.

So you might simply want to switch to

renderXml=true
sourcetype=XmlWinEventLog

in your eventlog inputs. Provided that you're using TA-windows, the rest should happen automagically.

This will of course only affect events ingested after the change.

[Kosyay]

Good afternoon! The problem is that the logs record two values in the account name field: the workstation name and the user login. Is it possible to modify this behavior so that only the login is recorded, since the workstation name is already captured in a separate field?

[PickleRick]

That's one of the limitations of ingesting windows events in the "traditional" form.

Open Event Viewer on your windows computer. Open the Security log and find a 4624 event.

What you're ingesting at this point is what you can see in the bottom panel in the "General" tab - the event rendered to a human-readable text. It does contain fields named the same way (like Account Name) just differently "scoped" (indented a bit in sections regarding either Subject or New Logon).  So Splunk parses those fields as key/value pairs and simply gathers two different values of the same named field because the source data contains it. You could probably bend over backwards and try to write custom regexes to extract those specific values but it will be very ugly and fairly bad performance-wise.

If you switch to ingesting XML versions of events, apart from saving on space occupied by events (and license usage!), you get more unambiguous structure. You'd be ingesting the event as it's presented in the bottom Event Log panel in the Details tab in XML view. The structure might not be as readable here but Splunk can parse this XML much better and present it to you in a useful form. And here you have much more straightforward and unique field names - in your case it would be SubjectUserName and TargetUserName - two completely distinct fields.

[Kosyay]

Thank you very much for the information. Currently, we are forwarding logs using the Universal Forwarder ( inputs.conf:
start_from = oldest
checkpointInterval = 5
evt_resolve_ad_obj = 1
wec_event_format = raw_event
and the settings Splunk Indexer: props.conf: 
SHOULD_LINEMERGE = false
TRUNCATE = 0
TIME_PREFIX = EventTime=
TIME_FORMAT = %Y-%m-%d %H:%M:%S
MAX_TIMESTAMP_LOOKAHEAD = 25

We will plan to test the TA Windows.

[marycordova]

You should not modify the original raw event, just create a props to do searchtime representational changes to the data.  

The only time you should modify the raw data is if you are masking it to protect sensitive information such as credit card or identification numbers like social security here in the US.

Modifying raw log data before sending it to Splunk destroys forensic integrity, making it impossible to validate original events during investigations. It also breaks source consistency, impacting troubleshooting, compliance, and accurate analytics.

[marycordova]

Or...if you don't want to do a props you can use an eval statement inline:

| eval Source=mvindex('AccountName',0)
| eval Destination=mvindex('AccountName',1)

Replace Source/Destination with whatever you want the new name to be and AccountName with whatever the original names are.

Also, if you have the proper TA (Splunk Add-on for Microsoft Windows | Splunkbase) installed in all the places it should be, these evaluations (via props) should already be happening as src_* and dest_* as per CIM normalization (Overview of the Splunk Common Information Model | Splunk Docs)

[Kosyay]

Hello. We ended up choosing the Splunk_TA_Windows add-on, but some questions came up. During parsing, some field names are in uppercase (e.g., Target_User_Name, WorkstationName, Source_Workstation), while others are in lowercase (e.g., user, dvc_nt_host, dvc, src_user).

Could someone please explain:

1. Why are these additional lowercase fields needed?

2. Is it possible to hide or remove them?

Thanks in advance!

[malix_la_harpe]

Hello @Kosyay ,

Those additionnal lowercase fields are defined by the Splunk_TA_Windows add-on to be compliant with Splunk CIM. You can find the list of the CIM fieldnames here : https://help.splunk.com/en/splunk-cloud-platform/common-information-model/6.0/data-models/cim-fields...

The CIM helps you to normalize your data to match a common standard, using the same field names and event tags for equivalent events from different sources or vendors. So I'm not sure you want to remove those fields 😉

If you want to see where those fields are defined, open the add-on archive, and you will see the alias and eval definitions in the file "Splunk_TA_windows\default\props.conf"

[Kosyay]

"Sorry for the question, but is it possible to disable fields that we don't need for a specific sourcetype or index?"

[PickleRick]

You are thinking about this "backwards". These fields aren't "added" to your events in the sense that they are not stored anywhere additionally and taking up space and license. They are dynamically extracted and/or calculated when you are searching your data. If you are searching in verbose or smart mode, all possible fields will be extracted (unless you explicitly limit them with the "fields" or "table" command. But if you search in fast mode (which is the prefered approach because then searches run faster) only the fields you explicitly specify will be extracted. So you don't need to "remove" the fields. If you don't want to see them when searching in smart or verbose mode you can add

| fields - whatever_fields you want_removed

And you won't see them. @malix_la_harpe 's answer while techinically not wrong is not the way to go.

[malix_la_harpe]

If you absolutely want to remove some fields, as they are defined by the add-on, you have two choices :

- Edit the add-on by removing the corresponding lines in props.conf in the add-on folder, but you will have to patch that at each update of the add-on, that's generally not a good idea

- Add a custom eval for each field you want to delete, by defining a new stanza in your local props.conf :

[your_sourcetype]
EVAL-your_fieldname=null() 

[livehybrid]

Hi @Kosyay 

Yes, you can use props/transforms to extract fields from the event. I wouldnt recommend modifying the event at index-time though, as this might break other extractions that exist for this feed, instead you can create new fields for the data you want to extract. 

I havent validated this with my instance as I dont have WinEventLogs at the moment but you could try something like this:

You can extract and rename these fields at index time using props.conf and transforms.conf with appropriate regex. In props.conf, configure a stanza for your sourcetype and reference a transform. In transforms.conf, use regex to capture and rename the two "Account Name" fields.

Example configuration:

 === props.conf ===
[your_sourcetype]
TRANSFORMS-rename_account_names =extract_win_account_names

=== transforms.conf === [extract_win_account_names] REGEX = Subject:\s+Security ID:.*?Account Name:\s*([^\s]+).*?New Logon:.*?Account Name:\s*([^\s]+) FORMAT = Source_Account_Name::$1 Destination_Account_Name::$2

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing