Skip to main content

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)?

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.

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 ? 

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 ? 


Should be able to map to multiple. Something like this example should get you started:


    if [service] != "" {

      mutate {

        replace => {

          "service_label.key" => "service"

          "service_label.value.string_value" => "%{service}"

        }

        on_error => "invalid_service"

      }

    }

 

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.