diff --git a/rules/integrations/google_workspace/impact_google_workspace_admin_role_deletion.toml b/rules/integrations/google_workspace/impact_google_workspace_admin_role_deletion.toml index 836fc780c12..ced19ebab13 100644 --- a/rules/integrations/google_workspace/impact_google_workspace_admin_role_deletion.toml +++ b/rules/integrations/google_workspace/impact_google_workspace_admin_role_deletion.toml @@ -2,13 +2,15 @@ creation_date = "2020/11/17" integration = ["google_workspace"] maturity = "production" -updated_date = "2026/04/10" +updated_date = "2026/05/29" [rule] author = ["Elastic"] description = """ -Detects when a custom admin role is deleted. An adversary may delete a custom admin role in order to impact the -permissions or capabilities of system administrators. +Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to +disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the +privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an +active investigation. """ false_positives = [ """ @@ -17,7 +19,7 @@ false_positives = [ """, ] from = "now-130m" -index = ["filebeat-*", "logs-google_workspace*"] +index = ["filebeat-*", "logs-google_workspace.admin-*"] interval = "10m" language = "kuery" license = "Elastic License v2" @@ -26,38 +28,58 @@ note = """## Triage and analysis ### Investigating Google Workspace Admin Role Deletion -Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where further domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. - -Deleted administrator roles may render some user accounts inaccessible or cause operational failure where these roles are relied upon to perform daily administrative tasks. The deletion of roles may also hinder the response and remediation actions of administrators responding to security-related alerts and events. Without specific roles assigned, users will inherit the permissions and privileges of the root organizational unit. - -This rule identifies when a Google Workspace administrative role is deleted within the Google Admin console. - -#### Possible investigation steps - -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- Identify the role deleted by reviewing `google_workspace.admin.role.name` in the alert. -- With the user identified, verify if he has administrative privileges to disable or delete administrative roles. -- To identify other users affected by this role removed, search for `event.action: ASSIGN_ROLE`. - - Add `google_workspace.admin.role.name` with the role deleted as an additional filter. - - Adjust the relative time accordingly to identify all users that were assigned this admin role. +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Deleting a custom role removes it from the tenant and revokes the associated +privileges for all users and groups that held the role. Threat actors may delete roles to disrupt security operations, +remove delegated admin access, or cover tracks after privilege escalation. Because the role no longer exists in the +Admin console after deletion, determining who was assigned the role and what privileges it contained requires reviewing +historical audit logs. + +This rule identifies when a custom administrative role is deleted in the Google Admin console. + +### Possible investigation steps + +- Identify the initiating (actor) account that deleted the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role deleted by reviewing `google_workspace.admin.role.name`. +- Determine whether the deletion is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to delete custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Confirm the role is deleted in the Google Admin console: + - Navigate to Account > Admin roles. + - Search for the role name from `google_workspace.admin.role.name` and confirm it no longer appears in the role list. +- Search Kibana for principals previously assigned the role to determine blast radius: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range before the deletion timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Search for `event.action: "UNASSIGN_ROLE"` with the same role name to identify recent removals before deletion. +- Search Kibana for privileges the deleted role contained: + - Use the following KQL example to review any privileges that were granted to the role before deletion: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "" + ``` + - Review `google_workspace.admin.privilege.name` values to understand what access was removed from assigned principals. +- Scope for related role activity by searching for the same `user.email` (actor) performing other IAM actions such as `DELETE_ROLE`, `ADD_PRIVILEGE`, `ASSIGN_ROLE`, or security policy changes within the last 48 hours. +- Evaluate whether the deletion coincides with other suspicious activity: + - Review admin/audit events around the deletion time for security control changes, additional role deletions, or attempts to modify Super Admin assignments. ### False positive analysis -- After identifying the user account that disabled the admin role, verify the action was intentional. +- Verify the role deletion aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not deleting roles from unusual IPs, devices, or locations. +- Validate whether the role was deprecated or consolidated into another role as part of planned IAM cleanup. ### Response and remediation -- Initiate the incident response process based on the outcome of the triage. -- Discuss with the user the affected users as a result of this action to mitigate operational discrepencies. -- Disable or limit the account during the investigation and response. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Assess the criticality of affected services and servers. - - Work with your IT team to identify and minimize the impact on users. - - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - - Identify any regulatory or legal ramifications related to this activity. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the deletion is not clearly authorized, recreate the role with equivalent privileges and reassign affected users or groups while the investigation proceeds. +- Identify affected users and groups from historical `ASSIGN_ROLE` events and confirm they retain necessary administrative access through other roles. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether the deleted role contained security-relevant privileges (for example, audit log access or security settings management) that could impair detection or response if removed. - Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). @@ -87,15 +109,24 @@ tags = [ "Data Source: Google Workspace", "Use Case: Identity and Access Audit", "Tactic: Impact", + "Tactic: Defense Evasion", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "query" query = ''' -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:DELETE_ROLE +data_stream.dataset:google_workspace.admin and event.action:DELETE_ROLE ''' +[rule.investigation_fields] +field_names = [ + "source.ip", + "user.name", + "user.email", + "event.action", + "google_workspace.admin.role.name", +] [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/google_workspace/persistence_google_workspace_admin_role_assigned_to_user.toml b/rules/integrations/google_workspace/persistence_google_workspace_admin_role_assigned_to_user.toml index 088da13977e..2bcec8c1dae 100644 --- a/rules/integrations/google_workspace/persistence_google_workspace_admin_role_assigned_to_user.toml +++ b/rules/integrations/google_workspace/persistence_google_workspace_admin_role_assigned_to_user.toml @@ -2,15 +2,16 @@ creation_date = "2020/11/17" integration = ["google_workspace"] maturity = "production" -updated_date = "2026/04/10" +updated_date = "2026/05/29" [rule] author = ["Elastic"] description = """ -Assigning the administrative role to a user will grant them access to the Google Admin console and grant them -administrator privileges which allow them to access and manage various resources and applications. An adversary may -create a new administrator account for persistence or apply the admin role to an existing user to carry out further -intrusion efforts. Users with super-admin privileges can bypass single-sign on if enabled in Google Workspace. +Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including +access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign +administrator roles to an existing account or a newly created account/group to establish persistence, facilitate +privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges +can bypass single sign-on (SSO) if it is enabled in Google Workspace. """ false_positives = [ """ @@ -19,52 +20,57 @@ false_positives = [ """, ] from = "now-130m" -index = ["filebeat-*", "logs-google_workspace*"] +index = ["filebeat-*", "logs-google_workspace.admin-*"] interval = "10m" language = "kuery" license = "Elastic License v2" -name = "Google Workspace Admin Role Assigned to a User" +name = "Google Workspace Admin Role Assigned to a User or Group" note = """## Triage and analysis -### Investigating Google Workspace Admin Role Assigned to a User - -Google Workspace roles allow administrators to assign specific permissions to users or groups. These assignments should follow the principle of least privilege (PoLP). Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created when prebuilt roles are not sufficient. - -Administrator roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Administrative roles also give users access to the admin console, where domain-wide settings can be adjusted. Threat actors might rely on these new privileges to advance their intrusion efforts and laterally move throughout the organization. Users with unexpected administrative privileges may also cause operational dysfunction if unfamiliar settings are adjusted without warning. - -This rule identifies when a Google Workspace administrative role is assigned to a user. - -#### Possible investigation steps - -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. - - The `user.target.email` field contains the user who received the admin role. -- Identify the role given to the user by reviewing the `google_workspace.admin.role.name` field in the alert. -- After identifying the involved user, verify their administrative privileges are scoped properly. -- To identify other users with this role, search the alert for `event.action: ASSIGN_ROLE`. - - Add `google_workspace.admin.role.name` with the role added as an additional filter. - - Adjust the relative time accordingly to identify all users that were assigned this admin role. -- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. - - Add `user.email` with the target user account that recently received this new admin role. -- After identifying the involved user, create a filter with their `user.name` or `user.target.email`. Review the last 48 hours of their activity for anything that may indicate a compromise. +### Investigating Google Workspace Admin Role Assigned to a User or Group + +Google Workspace roles allow administrators to assign specific permissions to users or groups. Because these roles can +grant broad administrative control over identity, devices, and security settings, role assignments should follow the +principle of least privilege (PoLP) and be carefully controlled. Threat actors may assign high-privilege roles (for +example, Super Admin or other *_ADMIN_ROLE roles) to establish persistence, expand access, and perform follow-on actions +such as creating OAuth tokens, modifying security controls, changing mail routing, or altering SSO settings. Unexpected +admin privileges can also lead to operational impact if changes are made unintentionally. + +This rule identifies when a Google Workspace administrative role is assigned to a user or a group. + +### Possible investigation steps + +- Identify the initiating (actor) account that performed the change by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the target principal that received the role assignment: + - For assignments, review `user.target.email` and `user.target.name`. + - For group assignments, determine which users are members of that group at the time of assignment. +- Identify the role assigned by reviewing `google_workspace.admin.role.name`. +- Determine whether the assignment is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to grant this level of access. + - If the role is high privilege (for example, Super Admin), treat as urgent until proven benign. +- Scope for additional role assignments by searching for `event.action: ASSIGN_ROLE` over an expanded time window and filtering on: + - The same `user.email` (actor) to find other role changes performed by the same account. + - The same `google_workspace.admin.role.name` to identify other principals granted the role. + - The same target (`user.target.email`) to identify multiple roles granted to the same principal. +- Evaluate whether the target user (or group members) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + - If available, correlate with sign-in events for unusual geolocation, impossible travel, unfamiliar devices, or sign-ins from the `source.ip`. +- Determine whether the target user account was recently created by searching for `event.action: CREATE_USER` and filtering for `user.target.email`. ### False positive analysis -- After identifying user account that added the admin role, verify the action was intentional. -- Verify that the target user who was assigned the admin role should have administrative privileges in Google Workspace. -- Review organizational units or groups the target user might have been added to and ensure the admin role permissions align. +- Verify the role assignment aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not performing role assignments from unusual IPs, devices, or locations. +- For group assignments, verify the group is intended for administrative delegation and validate recent membership changes that could expand who effectively received the privilege. ### Response and remediation -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Assess the criticality of affected services and servers. - - Work with your IT team to identify and minimize the impact on users. - - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - - Identify any regulatory or legal ramifications related to this activity. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the assignment is not clearly authorized, remove the role assignment from the user/group and/or place the target account(s) under administrative restriction while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review the permissions assigned to the implicated user/group to ensure PoLP is being followed, and consider replacing broad roles with narrower delegated roles where feasible. - Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). @@ -94,16 +100,27 @@ tags = [ "Data Source: Google Workspace", "Use Case: Identity and Access Audit", "Tactic: Persistence", + "Tactic: Privilege Escalation", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "query" query = ''' -data_stream.dataset:"google_workspace.admin" and event.category:"iam" and event.action:"ASSIGN_ROLE" - and google_workspace.event.type:"DELEGATED_ADMIN_SETTINGS" and google_workspace.admin.role.name : *_ADMIN_ROLE +data_stream.dataset:"google_workspace.admin" and event.action:"ASSIGN_ROLE" + and google_workspace.admin.role.name : *_ADMIN_ROLE ''' +[rule.investigation_fields] +field_names = [ + "source.ip", + "user.name", + "user.email", + "event.action", + "google_workspace.admin.role.name", + "user.target.name", + "user.target.email", +] [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/google_workspace/persistence_google_workspace_custom_admin_role_created.toml b/rules/integrations/google_workspace/persistence_google_workspace_custom_admin_role_created.toml index c7ffd426836..18281dbc22f 100644 --- a/rules/integrations/google_workspace/persistence_google_workspace_custom_admin_role_created.toml +++ b/rules/integrations/google_workspace/persistence_google_workspace_custom_admin_role_created.toml @@ -2,13 +2,16 @@ creation_date = "2020/11/17" integration = ["google_workspace"] maturity = "production" -updated_date = "2026/04/10" +updated_date = "2026/05/29" [rule] author = ["Elastic"] description = """ -Detects when a custom admin role is created in Google Workspace. An adversary may create a custom admin role in order to -elevate the permissions of other user accounts and persist in their target’s environment. +Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles +allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may +create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a +compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying +security controls, granting OAuth access, or changing mail routing. """ false_positives = [ """ @@ -17,7 +20,7 @@ false_positives = [ """, ] from = "now-130m" -index = ["filebeat-*", "logs-google_workspace*"] +index = ["filebeat-*", "logs-google_workspace.admin-*"] interval = "10m" language = "kuery" license = "Elastic License v2" @@ -26,43 +29,54 @@ note = """## Triage and analysis ### Investigating Google Workspace Custom Admin Role Created -Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt administrator roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. - -Roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Threat actors might create new admin roles with privileges to advance their intrusion efforts and laterally move throughout the organization if existing roles or users do not have privileges aligned with their modus operandi. Users with unexpected privileges from new admin roles may also cause operational dysfunction if unfamiliar settings are adjusted without warning. Instead of modifying existing roles, administrators might create new roles to accomplish short-term goals and unintentionally introduce additional risk exposure. - -This rule identifies when a Google Workspace administrative role is added within the Google Workspace admin console. - -#### Possible investigation steps - -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- Identify the role added by reviewing the `google_workspace.admin.role.name` field in the alert. -- After identifying the involved user, verify if they should have administrative privileges to add administrative roles. -- To identify if users have been assigned this role, search for `event.action: ASSIGN_ROLE`. - - Add `google_workspace.admin.role.name` with the role added as an additional filter. - - Adjust the relative time accordingly to identify all users that were possibly assigned this admin role. -- Monitor users assigned the admin role for the next 24 hours and look for attempts to use related privileges. - - The `event.provider` field will help filter for specific services in Google Workspace such as Drive or Admin. - - The `event.action` field will help trace what actions are being taken by users. +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Custom roles are often used for delegated administration, but they can also +be abused to establish persistence: an adversary may create a role with only the privileges they need, then assign it to +a compromised account or group without modifying well-known prebuilt roles. Because role creation alone does not grant +access, determining whether the new role was assigned, and what privileges it contains, is a critical part of triage. + +This rule identifies when a custom administrative role is created in the Google Admin console. + +### Possible investigation steps + +- Identify the initiating (actor) account that created the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role created by reviewing `google_workspace.admin.role.name`. +- Determine whether the role creation is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to create custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which administrative permissions were granted. + - Review the Admins tab to see which users or groups are currently assigned the role. +- Search Kibana for role assignments to identify principals that received the new role: + - Search Google Workspace admin logs with a time range starting at the role creation timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Expand the time range if needed; role assignment may occur shortly after creation or during a later persistence step. +- Scope for related role activity by searching for: + - `event.action: ADD_PRIVILEGE` or `event.action: UPDATE_ROLE` filtered on the same `google_workspace.admin.role.name` to identify privilege changes after creation. + - The same `user.email` (actor) performing other IAM actions such as `ASSIGN_ROLE`, `CREATE_USER`, or security policy changes. +- Evaluate whether assigned users (or members of assigned groups) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. ### False positive analysis -- After identifying the user account that created the role, verify whether the action was intentional. -- Verify that the user who created the role should have administrative privileges in Google Workspace to create custom roles. -- Review organizational units or groups the role may have been added to and ensure the new privileges align properly. -- Create a filter with the user's `user.name` and filter for `event.action`. In the results, check if there are multiple `CREATE_ROLE` actions and note whether they are new or historical. +- Verify the role creation aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not creating roles from unusual IPs, devices, or locations. +- Compare the custom role’s privileges against the stated business need; overly broad privileges (for example, Super Admin–equivalent access) warrant closer review even if the creation was authorized. ### Response and remediation -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Assess the criticality of affected services and servers. - - Work with your IT team to identify and minimize the impact on users. - - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - - Identify any regulatory or legal ramifications related to this activity. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the role is not clearly authorized, delete or disable the custom role and remove any user/group assignments while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether assigned principals require the granted privileges, and replace broad custom roles with narrower delegated roles where feasible. - Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). @@ -93,14 +107,23 @@ tags = [ "Use Case: Identity and Access Audit", "Resources: Investigation Guide", "Tactic: Persistence", + "Tactic: Privilege Escalation", ] timestamp_override = "event.ingested" type = "query" query = ''' -data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:CREATE_ROLE +data_stream.dataset:google_workspace.admin and event.action:CREATE_ROLE ''' +[rule.investigation_fields] +field_names = [ + "source.ip", + "user.name", + "user.email", + "event.action", + "google_workspace.admin.role.name", +] [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/google_workspace/persistence_google_workspace_role_modified.toml b/rules/integrations/google_workspace/persistence_google_workspace_role_modified.toml index 471e4de2531..e0d468f4f34 100644 --- a/rules/integrations/google_workspace/persistence_google_workspace_role_modified.toml +++ b/rules/integrations/google_workspace/persistence_google_workspace_role_modified.toml @@ -2,13 +2,15 @@ creation_date = "2020/11/17" integration = ["google_workspace"] maturity = "production" -updated_date = "2026/04/10" +updated_date = "2026/05/29" [rule] author = ["Elastic"] description = """ -Detects when a custom admin role or its permissions are modified. An adversary may modify a custom admin role in order -to elevate the permissions of other user accounts and persist in their target’s environment. +Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand +privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly +assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying +role permissions can silently expand access across multiple accounts. """ false_positives = [ """ @@ -26,45 +28,62 @@ note = """## Triage and analysis ### Investigating Google Workspace Role Modified -Google Workspace roles allow administrators to assign specific permissions to users or groups where the principle of least privilege (PoLP) is recommended. Admin roles in Google Workspace grant users access to the Google Admin console, where more domain-wide settings are accessible. Google Workspace contains prebuilt admin roles for performing business functions related to users, groups, and services. Custom administrator roles can be created where prebuilt roles are not preferred. Each Google Workspace service has a set of custodial privileges that can be added to custom roles. - -Roles assigned to users will grant them additional permissions and privileges within the Google Workspace domain. Threat actors might modify existing roles with new privileges to advance their intrusion efforts and laterally move throughout the organization. Users with unexpected privileges might also cause operational dysfunction if unfamiliar settings are adjusted without warning. - -This rule identifies when a Google Workspace role is modified. - -#### Possible investigation steps - -- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. -- Identify the role modified by reviewing the `google_workspace.admin.role.name` field in the alert. -- Identify the privilege that was added or removed by reviewing the `google_workspace.admin.privilege.name` field in the alert. -- After identifying the involved user, verify administrative privileges are scoped properly. -- To identify other users with this role, search for `event.action: ASSIGN_ROLE` - - Add `google_workspace.admin.role.name` with the role added as an additional filter. - - Adjust the relative time accordingly to identify all users that were assigned this role. -- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. -- If a privilege was added, monitor users assigned this role for the next 24 hours and look for attempts to use the new privilege. - - The `event.provider` field will help filter for specific services in Google Workspace such as Drive or Admin. - - The `event.action` field will help trace actions that are being taken by users. +Google Workspace allows administrators to modify custom admin roles by adding, removing, or updating privileges across +services such as Users, Groups, Gmail, Drive, and Security. Threat actors may expand privileges on an existing role to +establish persistence or escalate access for accounts already assigned that role, without triggering role assignment +alerts. Selecting a privilege category in the Admin console (for example, Organization Units) can add multiple related +privilege groups in a single action, each logged as a separate `ADD_PRIVILEGE` event. + +This rule identifies when a Google Workspace role is modified via `ADD_PRIVILEGE` or `UPDATE_ROLE` events. Alert +suppression groups alerts by `user.email`, `google_workspace.admin.role.name`, and `source.ip` within a 130-minute window +(matching the rule lookback) so analysts receive one alert per role modification session instead of one alert per privilege. + +### Possible investigation steps + +- Identify the initiating (actor) account that modified the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role modified by reviewing `google_workspace.admin.role.name`. +- Identify the privilege changed by reviewing `google_workspace.admin.privilege.name`. Because suppression may group multiple events, search for all related changes in the same session (see Kibana steps below). +- Determine whether the modification is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to modify admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which permissions were added or removed and whether they align with the organization's delegation model. + - Review the Admins tab to identify which users or groups currently hold the role and will inherit the modified privileges. +- Search Kibana for all privileges changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("ADD_PRIVILEGE" or "UPDATE_ROLE") and google_workspace.admin.role.name: "" + ``` + - Optionally filter on the actor with `user.email` to isolate changes from the same administrator. + - Review all `google_workspace.admin.privilege.name` values returned to understand the full scope of the modification. +- Search Kibana for principals recently assigned the role to determine blast radius: + - Use the following KQL example: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. +- Scope for related activity by searching for the same `user.email` (actor) performing other IAM or security actions such as `ASSIGN_ROLE`, `CREATE_ROLE`, `CREATE_USER`, or security policy changes within the last 48 hours. +- Evaluate whether principals assigned the modified role performed suspicious activity after the change: + - Review admin/audit events for security control changes, user or group changes, and Gmail configuration changes. ### False positive analysis -- After identifying the user account that modified the role, verify the action was intentional. -- Verify that the user is expected to have administrative privileges in Google Workspace to modify roles. -- Review organizational units or groups the role might have been added to and ensure the new privileges align properly. -- Use the `user.name` to filter for `event.action` where `ADD_PRIVILEGE` or `UPDATE_ROLE` has been seen before to check if these actions are new or historical. +- Verify the role modification aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not modifying roles from unusual IPs, devices, or locations. +- Selecting a privilege category in the Admin console can add multiple related privileges in one action; alert suppression should consolidate these into a single alert. +- Compare the modified role's privileges against the stated business need; overly broad privileges warrant closer review even if the change was authorized. ### Response and remediation -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Assess the criticality of affected services and servers. - - Work with your IT team to identify and minimize the impact on users. - - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - - Identify any regulatory or legal ramifications related to this activity. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, revert the role privileges to their prior state and/or remove the role assignment from affected users or groups while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether principals assigned the modified role require the new privileges, and replace broad custom roles with narrower delegated roles where feasible. - Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). @@ -95,6 +114,7 @@ tags = [ "Use Case: Identity and Access Audit", "Resources: Investigation Guide", "Tactic: Persistence", + "Tactic: Privilege Escalation", ] timestamp_override = "event.ingested" type = "query" @@ -103,6 +123,20 @@ query = ''' data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:(ADD_PRIVILEGE or UPDATE_ROLE) ''' +[rule.alert_suppression] +group_by = ["user.email", "google_workspace.admin.role.name", "source.ip"] +duration = {value = 130, unit = "m"} # match lookback window +missing_fields_strategy = "suppress" + +[rule.investigation_fields] +field_names = [ + "source.ip", + "user.name", + "user.email", + "event.action", + "google_workspace.admin.role.name", + "google_workspace.admin.privilege.name", +] [[rule.threat]] framework = "MITRE ATT&CK"