Identify svc account impersonation using chronicle rule

Question

Unintended service account impersonation is a significant concern when it comes to service account abuse.

While reviewing logs to detect when one service account impersonates another, I noticed that Chronicle does not parse the impersonator service account into a separate field.

Instead, the impersonator’s service account email is added to the principal.email_addresses repeated field.

This creates challenges in fully detecting impersonation activities, as the impersonator email is not consistently placed in the same order within the repeated field. Even if we assume that the last email in the list could be the impersonator's, it’s difficult to pinpoint the last index when writing detection rules.

This makes it challenging to create effective rules for identifying service account impersonation. Has anyone encountered this issue, or does anyone have alternative solutions (other than creating a custom parser)?

cmorris · Accepted Answer

If not parsing into a separate field, you can submit a support case to have the parser updated or create a parser extension to map the account to another field.

AfvanJaffer · Answer

If not parsing into a separate field, you can submit a support case to have the parser updated or create a parser extension to map the account to another field.

I have created the parser extension in some cases like this, but when you prepare to add a separate field, I believe we only have a chance to replace it with some already present field, or add it to an existing repeating field(but that will require us to create(merge everything) the whole array back with the earlier default parsed fields and then the new item)

is this approach correct ?

do you have any example that you can provide based on this use case ?

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded