Hi,
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.
user.name field is populated from TargetUserName (4624 and 4634) and from SubjectUserName (4672)
In this case the field in ECS exists (user.name), 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?
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?
I propose that we create winlog.login.id 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.
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: "winlog.logon.id"},
{from: "winlog.event_data.TargetLogonId", to: "winlog.logon.id"},
would result in the correct value, but it would effectively delete the value of winlog.event_data.SubjectLogonId since SubjectLogonId is moved to winlog.logon.id then winlog.logon.id 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: https://github.com/elastic/beats/pull/12975
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.
Hi Andrew,
I have been reading the modifications in the winlogbeat-security.js and I have a comment when populating the logon.id
var addLogonIds = function(evt) {
var id = evt.Get("winlog.event_data.SubjectLogonId");
if (id) {
evt.AppendTo("winlog.logon.id", id);
}
id = evt.Get("winlog.event_data.TargetLogonId");
if (id) {
evt.AppendTo("winlog.logon.id", 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 winlog.logon.id so it has the proper information; but I do not know if there are others events in which this approach may not work
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)
Events 4624 (Logon Success) has in winlog.logon.is a list with [TargetLogonId,SubjectLogonID] If I want to know which from those Logons are from privileged users, I filter from winlog.logon.id and both conditions are selected
but not direct correlation with the Administrator logon
(If I remove the second winlog.id filter then the admin logon appears, but you have to know which one to remove).
Personally I think is better to have direct correlation...
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 winlog.logon.id: 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 winlog.logon.id?
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 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 winlog.logon.id 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?
Hi Andrew,
I'll modify the script and generate a PR, with this change and with the changes for processing the user management event during this week.
I'll let you know once finished
Thank you
Regards
Ana
I've removed the original function that was returning the list of LogonID and create two functions either to copy the SubjectLogonID or the TargetLogonID depending the event context/meaning.
Below two examples of how do I use that field to correlate that one user was enabled with which administrator login was the one performing the action.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
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.
