[RFC] Multiple users in an event#914
Conversation
|
This PR is no longer marked as Draft :-) Ping @ebeahan @epixa @jamiehynds @leehinman @janniten @willemdh @neu5ron @vbohata @rw-access @P1llus I'll be adding simple Linux events in the "Source Data" section. However I would really appreciate if someone has real events they could share from AD or other, that capture some of the complex events with many users present in the event (e.g. "real" user + priv escalation + target user + changes to the user). |
|
Event ID 4732 in AD - 'administrator' has added 'bob' to the users group. A member was added to a security-enabled local group. Member: Group: Additional Information: Privileges: - Expiration time: - Event ID 4722 in AD - 'administrator' has enabled the 'john.locke' account. A user account was enabled. Subject: Security ID: ACME-FR\administrator Target Account: Security ID: ACME-FR\John.Locke |
|
Hi All, I'm working now with some events in which all users maybe appears (4670,4715) in one event. I'll let you know If I found the example that contains all the users. Oracle Auditory Event Example
Privilege Access Management Logs I have access to some Thycotik logs, but I'm not able to generate logs. I'll be looking for an example there also. |
|
Amazing, thank you @janniten |
|
AWS has an AssumedRole API, a simplified Cloudtrail entry would be: {
"eventName": "AssumeRole",
"requestParameters": {
"roleArn": "arn:aws:iam::111111111111:role/JohnRole2",
},
"resources": [
{
"ARN": "arn:aws:iam::111122223333:role/JohnRole2",
"accountId": "111111111111",
"type": "AWS::IAM::Role"
}
],
"responseElements": {
"assumedRoleUser": {
"arn": "arn:aws:sts::111111111111:assumed-role/test-role/Role2WithTags",
"assumedRoleId": "AROAIFR7WHDTSOYQYHFUE:Role2WithTags"
},
"userIdentity": {
"accessKeyId": "AKIAI44QH8DHBEXAMPLE",
"accountId": "111111111111",
"arn": "arn:aws:sts::111111111111:assumed-role/JohnDoe/JohnRole1",
"principalId": "AROAIN5ATK5U7KEXAMPLE:JohnRole1",
"type": "AssumedRole"
}
}
Also AWS can have AssumedRoles in the userIdentity: "userIdentity": {
"accessKeyId": "AKIAQRSTUVWXYZEXAMPLE",
"accountId": "777788889999",
"arn": "arn:aws:sts::777788889999:assumed-role/AssumeNothing/devdsk",
"principalId": "AIDAQRSTUVWXYZEXAMPLE:devdsk",
"sessionContext": {
"attributes": {
"creationDate": "2016-11-14T17:25:26Z",
"mfaAuthenticated": "false"
},
"sessionIssuer": {
"accountId": "777788889999",
"arn": "arn:aws:iam::777788889999:role/AssumeNothing",
"principalId": "AIDAQRSTUVWXYZEXAMPLE",
"type": "Role",
"userName": "AssumeNothing"
}
},
"type": "AssumedRole"
}
|
|
Event ID 4624 in Windows is used to capture when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command. A logon was attempted using explicit credentials. Subject: |
ebeahan
left a comment
There was a problem hiding this comment.
Excellent proposal 💯 . I have a few notes but overall this looks great.
Co-authored-by: Eric Beahan <ebeahan@gmail.com>
|
@webmat just wanted to check in and see if you need me to solicit more feedback (I think I'm the sponsor for this one)? |
|
@jonathan-buttner Thanks for asking. Yes, a thorough review from someone on the team would be welcome. Note that I still have a few tasks on my end before this is final, the main one being including concrete mapping examples based on Linux and Windows events (e.g. like those shared via comments here). This is unlikely to happen this week or the next. So a review in the meantime would be greatly appreciated, with the only caveat that the concrete examples are coming :-) |
jonathan-buttner
left a comment
There was a problem hiding this comment.
The proposal looks good to me. @rw-access any additional scenarios you can think of that would warrant additional fields?
|
@rylnd not sure if you've seen anything from the SIEM that we'd need to include with these changes as well? |
| "name": "bob.barker" | ||
| } | ||
| }, | ||
| "related": { "user": ["alice", "root", "bob", "bob.barker"] } |
There was a problem hiding this comment.
Apologies if this has already been addressed, but one concern that was raised by the detections team was the uniqueness of these names. If related.user is intended to be used programmatically, my (naive) sense is that id would be a better candidate here.
There was a problem hiding this comment.
Yes, this has been raised in the past. We haven't addressed it directly anywhere yet, however. One potential solution that has been floated would be that related.user could perhaps contain all seen usernames + user IDs.
The field is only meant to pivot and find a user, no matter where in the event they appeared. It's not meant to have semantic meaning.
This RFC is not meant to address this issue, however. We will tackle that issue separately.
…tion field... Even if it's unrelated to how user fields should be used
|
Ok I think this is ready for a final review for stage 2. @janniten Thanks so much for these events, they're the ones I used for the Windows examples. Note that it's fine if events don't actually need all the field nestings at the same time. They're all in the schema to support events that do need them all. But in many cases, the activity is spread out across multiple events, as you noted. So only the needed fields should be used in each such events :-) I've tried to demonstrate the various situations in the examples I've just added. @leehinman Thanks a lot for the Cloudtrail AssumeRole events. I modified one of the ARNs slightly, but I used your events in my cloud example :-) Can you confirm my mapping makes sense to you? Especially the last paragraph. Final note for reviewers: I took the liberty to use a "session" @ebeahan We have one additional merge task once this is approved:
|
ebeahan
left a comment
There was a problem hiding this comment.
LGTM 👍
I only noted a handful of tiny changes.
|
|
||
| - Stage: **2 (proposal)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html --> | ||
| - Date: **TBD** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. --> | ||
| - Date: **2020-09-02** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. --> |
LGTM. |


I'm opening this RFC with a target of stage 2. This is the first PR for this RFC, but a lot of discussion has already happened before on the subject. Notably in #809 and #589 (see this RFC's references links to for more past discussions).
Opening directly at stage 2 simply means we'll need to ensure all stage 1 and 2 criteria are satisfied before moving forward.
In this RFC I try to document all expected uses of the
userfields. This is not meant to be only a description of the new fields that will be introduced by #869.Since this RFC is meant to document all uses of the
userfields, there will also be discussion about potentially deprecating and removing user fields in places that don't have a clear purpose. Feedback is definitely welcome, if you disagree with these removals.TODO
Preview of the RFC