Google Workspace Custom Admin Role Created

  1[metadata]
  2creation_date = "2020/11/17"
  3integration = ["google_workspace"]
  4maturity = "production"
  5updated_date = "2026/05/29"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles
 11allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may
 12create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a
 13compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying
 14security controls, granting OAuth access, or changing mail routing.
 15"""
 16false_positives = [
 17    """
 18    Custom Google Workspace admin roles may be created by system administrators. Verify that the configuration change
 19    was expected. Exceptions can be added to this rule to filter expected behavior.
 20    """,
 21]
 22from = "now-130m"
 23index = ["filebeat-*", "logs-google_workspace.admin-*"]
 24interval = "10m"
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "Google Workspace Custom Admin Role Created"
 28note = """## Triage and analysis
 29
 30### Investigating Google Workspace Custom Admin Role Created
 31
 32Google Workspace allows administrators to create custom admin roles with granular privileges across services such as
 33Users, Groups, Gmail, Drive, and Security. Custom roles are often used for delegated administration, but they can also
 34be abused to establish persistence: an adversary may create a role with only the privileges they need, then assign it to
 35a compromised account or group without modifying well-known prebuilt roles. Because role creation alone does not grant
 36access, determining whether the new role was assigned, and what privileges it contains, is a critical part of triage.
 37
 38This rule identifies when a custom administrative role is created in the Google Admin console.
 39
 40### Possible investigation steps
 41
 42- 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.
 43- Identify the role created by reviewing `google_workspace.admin.role.name`.
 44- Determine whether the role creation is expected and authorized:
 45  - Validate there is an approved change request/ticket and that the actor account is authorized to create custom admin roles.
 46  - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign.
 47- Review role permissions in the Google Admin console:
 48  - Navigate to Account > Admin roles.
 49  - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details.
 50  - Review the Privileges tab to confirm which administrative permissions were granted.
 51  - Review the Admins tab to see which users or groups are currently assigned the role.
 52- Search Kibana for role assignments to identify principals that received the new role:
 53  - Search Google Workspace admin logs with a time range starting at the role creation timestamp.
 54  - Use the following KQL example, replacing `<ROLE_NAME>` with the value from `google_workspace.admin.role.name`:
 55    ```
 56    data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "<ROLE_NAME>"
 57    ```
 58  - Review `user.target.email` and `user.target.name` for user/group assignments.
 59  - Expand the time range if needed; role assignment may occur shortly after creation or during a later persistence step.
 60- Scope for related role activity by searching for:
 61  - `event.action: ADD_PRIVILEGE` or `event.action: UPDATE_ROLE` filtered on the same `google_workspace.admin.role.name` to identify privilege changes after creation.
 62  - The same `user.email` (actor) performing other IAM actions such as `ASSIGN_ROLE`, `CREATE_USER`, or security policy changes.
 63- Evaluate whether assigned users (or members of assigned groups) performed suspicious activity after receiving the role:
 64  - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes.
 65
 66### False positive analysis
 67
 68- Verify the role creation aligns with approved administrative duties, an authorized change window, and the organization’s access governance process.
 69- Confirm the initiating admin account is legitimate and not creating roles from unusual IPs, devices, or locations.
 70- 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.
 71
 72### Response and remediation
 73
 74- Initiate the incident response process based on triage findings.
 75- If the role is not clearly authorized, delete or disable the custom role and remove any user/group assignments while the investigation proceeds.
 76- For suspected compromise of the initiating admin account:
 77  - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence.
 78  - Validate recovery email/phone settings and account security posture.
 79- Review whether assigned principals require the granted privileges, and replace broad custom roles with narrower delegated roles where feasible.
 80- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
 81- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
 82- 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).
 83
 84## Setup
 85
 86The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 87
 88### Important Information Regarding Google Workspace Event Lag Times
 89- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
 90- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
 91- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
 92- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
 93- See the following references for further information:
 94  - https://support.google.com/a/answer/7061566
 95  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
 96references = [
 97    "https://support.google.com/a/answer/2406043?hl=en",
 98    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
 99    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
100]
101risk_score = 47
102rule_id = "ad3f2807-2b3e-47d7-b282-f84acbbe14be"
103severity = "medium"
104tags = [
105    "Domain: Cloud",
106    "Data Source: Google Workspace",
107    "Use Case: Identity and Access Audit",
108    "Resources: Investigation Guide",
109    "Tactic: Persistence",
110    "Tactic: Privilege Escalation",
111]
112timestamp_override = "event.ingested"
113type = "query"
114
115query = '''
116data_stream.dataset:google_workspace.admin and event.action:CREATE_ROLE
117'''
118
119[rule.investigation_fields]
120field_names = [
121    "source.ip",
122    "user.name",
123    "user.email",
124    "event.action",
125    "google_workspace.admin.role.name",
126]
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[[rule.threat.technique]]
132id = "T1098"
133name = "Account Manipulation"
134reference = "https://attack.mitre.org/techniques/T1098/"
135
136[[rule.threat.technique.subtechnique]]
137id = "T1098.003"
138name = "Additional Cloud Roles"
139reference = "https://attack.mitre.org/techniques/T1098/003/"
140
141[rule.threat.tactic]
142id = "TA0003"
143name = "Persistence"
144reference = "https://attack.mitre.org/tactics/TA0003/"
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148
149[[rule.threat.technique]]
150id = "T1098"
151name = "Account Manipulation"
152reference = "https://attack.mitre.org/techniques/T1098/"
153
154[[rule.threat.technique.subtechnique]]
155id = "T1098.003"
156name = "Additional Cloud Roles"
157reference = "https://attack.mitre.org/techniques/T1098/003/"
158
159[rule.threat.tactic]
160id = "TA0004"
161name = "Privilege Escalation"
162reference = "https://attack.mitre.org/tactics/TA0004/"