Winlogbeat New ECS Fields and security module questions

I've been working on events 4624 (An account was successfully logged on), 4634 (An account was logged off), 4672 (Special privileges assigned to new logon) in order to correlate logon information about Administrators users logged in our Domain Controllers.
When trying to fit those events into ECS I found that there are some fields needed for correlation that are not populated.

  1. field is populated from TargetUserName (4624 and 4634) and from SubjectUserName (4672)
    In this case the field in ECS exists (, but how do I map event 4672? Should I to add a new convertAuthentication function in the winlogbeat-security.js? How is the best way to do it? How it should be according to the module design?

  2. In order to correlate Logons/Logout session I found that the fields TargetLogonID (4624 and 4634) and SubjectUserName (4672) must be populated in a common field.
    The logonID enables to correlates logon with logoff, for example, from Microsoft documentation

It may be positively correlated with a “4624: An account was successfully logged on.” event using the Logon ID value.

What is the correct way to introduce new fields in the ECS?


Thank you

I propose that we create as a new field for Winlogbeat. And then we'll set it appropriately based on the SubjectLogonID or TargetLogonID.

And we'll add support for event 4672 to the Security module.

How does that proposal sound? If good I can put a PR together.

Hi Andrew!
It sounds good to me!. If you want I can create the PR.
Only one question.
For Event 4624

  • TargetLogonID ->
    For Event 4672
  • SubjectLogonID ->

Can I put this into the same convert function?

        {from: "winlog.event_TargetLogonID", to: ""},
        {from: "winlog.event_SubjectLogonID", to: ""},

Or do we have to create a new convertion function for event 4672

Thank you

No, you shouldn't put them both in the same convert processor because it's configured with mode: rename. In the case of 4624 then a configuration like this

        {from: "winlog.event_data.SubjectLogonId", to: ""},
        {from: "winlog.event_data.TargetLogonId", to: ""},

would result in the correct value, but it would effectively delete the value of winlog.event_data.SubjectLogonId since SubjectLogonId is moved to then is overwritten by winlog.event_data.TargetLogonId.

I'm thinking it might be good to put both values in the same field so that you can quickly find all events associated with a logon ID. I've started a draft PR and did some more refactoring:

1 Like

Hi Andrew,
Thank you. I'll wait then.
It is a good idea to "chain" processors in order to reuse

In the meanwhile I wrote a new conversion function in order to be able to ingests the events and correlate. Now I have a dashboard with the admin logins, correlating 4624, 4672 and 4634 events so IT staff can track down the adm logins.

I'm doing some improvements on it, but at least they have all the information

Thank you

Hi Andrew,
I have been reading the modifications in the winlogbeat-security.js and I have a comment when populating the

var addLogonIds = function(evt) {
    var id = evt.Get("winlog.event_data.SubjectLogonId");
    if (id) {
        evt.AppendTo("", id);
    id = evt.Get("winlog.event_data.TargetLogonId");
    if (id) {
        evt.AppendTo("", id);

There are events, like 4624 that has both winlog.event_data.SubjectLogonId and winlog.event_data.TargetLogonId.
In this case as winlog.event_data.TargetLogonId is the last one assigned to so it has the proper information; but I do not know if there are others events in which this approach may not work


What problem will this cause? This uses AppendTo so it will create [1, 2] when there is more than one in logon ID the event.

So, in case of two LogonIDs (Subject and Target) will create a list with both logon ids?

Yes, I think this will be helpful when running queries where you want to find any information related to a given logon ID.

Thank you Andrew.

I'll test if in this way I can correlate between all events.
(For example now I'm correlating the initial logonID from 4624 with later events related to user management, so you can know in which login session and administrator made modifications, for example)

Hi @andrewkroh,
I've tested the function, and I get this

Events 4624 (Logon Success) has in a list with [TargetLogonId,SubjectLogonID] If I want to know which from those Logons are from privileged users, I filter from and both conditions are selected

but not direct correlation with the Administrator logon
(If I remove the second filter then the admin logon appears, but you have to know which one to remove).
Personally I think is better to have direct correlation...

What do you think?
Thank you

That method of filtering (circled in red) is going to be very restrictive as it's effectively an AND query looking for events that have both values. I would expect users trying to search for any one logon ID to be able to search one field like 0x3e7.

If you need to specifically search for a SubjectLogonId or TargetLogonId you can still do that directly too since we are retaining those fields.

What do you mean specifically? Like only copying a single logon ID to

Hi Andrew,
Yes I know that is a restrictive and condition and it is automatically set when in a search (for example) you want to filter by that field. Then in the case of the list, both values are filtered... so you must know then which want to exclude later in order to have the proper information.

Yes, put only the value that has sense/meaning in the context of the event and use that value to correlate.
For example, I'm thinking in users working with a dashboard and filtering winlog.logon,id image in order to easily find all related activity to an specific logon, without having the knowledge what the SubjectLogonID or TargetLogonID means in that event.
In my opinion, that analysis (of determine which LogonID is relevant) is what the must do when parsing and converting the event into ECS.
Of course that for deeper investigation you can still search by SubjectLogonID and TargetLogonID
Does it makes sense?


Ok, that makes sense to me. I think the area I was struggling with was determining what the best value is to use when populating the field. Sounds like you have a good understanding of what is the best value to populate that field with. Do you want to modify the script to do this?