Google Workspace Admin Role Deletion
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.
Elastic rule (View on GitHub)
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 deleted in Google Workspace. Adversaries may delete a custom admin role to
11disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the
12privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an
13active investigation.
14"""
15false_positives = [
16 """
17 Google Workspace admin roles may be deleted by system administrators. Verify that the configuration change was
18 expected. Exceptions can be added to this rule to filter expected behavior.
19 """,
20]
21from = "now-130m"
22index = ["filebeat-*", "logs-google_workspace.admin-*"]
23interval = "10m"
24language = "kuery"
25license = "Elastic License v2"
26name = "Google Workspace Admin Role Deletion"
27note = """## Triage and analysis
28
29### Investigating Google Workspace Admin Role Deletion
30
31Google Workspace allows administrators to create custom admin roles with granular privileges across services such as
32Users, Groups, Gmail, Drive, and Security. Deleting a custom role removes it from the tenant and revokes the associated
33privileges for all users and groups that held the role. Threat actors may delete roles to disrupt security operations,
34remove delegated admin access, or cover tracks after privilege escalation. Because the role no longer exists in the
35Admin console after deletion, determining who was assigned the role and what privileges it contained requires reviewing
36historical audit logs.
37
38This rule identifies when a custom administrative role is deleted in the Google Admin console.
39
40### Possible investigation steps
41
42- 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.
43- Identify the role deleted by reviewing `google_workspace.admin.role.name`.
44- Determine whether the deletion is expected and authorized:
45 - Validate there is an approved change request/ticket and that the actor account is authorized to delete custom admin roles.
46 - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign.
47- Confirm the role is deleted in the Google Admin console:
48 - Navigate to Account > Admin roles.
49 - Search for the role name from `google_workspace.admin.role.name` and confirm it no longer appears in the role list.
50- Search Kibana for principals previously assigned the role to determine blast radius:
51 - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range before the deletion timestamp.
52 - Use the following KQL example, replacing `<ROLE_NAME>` with the value from `google_workspace.admin.role.name`:
53 ```
54 data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "<ROLE_NAME>"
55 ```
56 - Review `user.target.email` and `user.target.name` for user/group assignments.
57 - Search for `event.action: "UNASSIGN_ROLE"` with the same role name to identify recent removals before deletion.
58- Search Kibana for privileges the deleted role contained:
59 - Use the following KQL example to review any privileges that were granted to the role before deletion:
60 ```
61 data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "<ROLE_NAME>"
62 ```
63 - Review `google_workspace.admin.privilege.name` values to understand what access was removed from assigned principals.
64- 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.
65- Evaluate whether the deletion coincides with other suspicious activity:
66 - Review admin/audit events around the deletion time for security control changes, additional role deletions, or attempts to modify Super Admin assignments.
67
68### False positive analysis
69
70- Verify the role deletion aligns with approved administrative duties, an authorized change window, and the organization's access governance process.
71- Confirm the initiating admin account is legitimate and not deleting roles from unusual IPs, devices, or locations.
72- Validate whether the role was deprecated or consolidated into another role as part of planned IAM cleanup.
73
74### Response and remediation
75
76- Initiate the incident response process based on triage findings.
77- If the deletion is not clearly authorized, recreate the role with equivalent privileges and reassign affected users or groups while the investigation proceeds.
78- Identify affected users and groups from historical `ASSIGN_ROLE` events and confirm they retain necessary administrative access through other roles.
79- For suspected compromise of the initiating admin account:
80 - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence.
81 - Validate recovery email/phone settings and account security posture.
82- 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.
83- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
84- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
85- 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).
86
87## Setup
88
89The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
90
91### Important Information Regarding Google Workspace Event Lag Times
92- 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.
93- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
94- 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.
95- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
96- See the following references for further information:
97 - https://support.google.com/a/answer/7061566
98 - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
99references = [
100 "https://support.google.com/a/answer/2406043?hl=en",
101 "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
102 "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
103]
104risk_score = 47
105rule_id = "93e63c3e-4154-4fc6-9f86-b411e0987bbf"
106severity = "medium"
107tags = [
108 "Domain: Cloud",
109 "Data Source: Google Workspace",
110 "Use Case: Identity and Access Audit",
111 "Tactic: Impact",
112 "Tactic: Defense Evasion",
113 "Resources: Investigation Guide",
114]
115timestamp_override = "event.ingested"
116type = "query"
117
118query = '''
119data_stream.dataset:google_workspace.admin and event.action:DELETE_ROLE
120'''
121
122[rule.investigation_fields]
123field_names = [
124 "source.ip",
125 "user.name",
126 "user.email",
127 "event.action",
128 "google_workspace.admin.role.name",
129]
130
131[[rule.threat]]
132framework = "MITRE ATT&CK"
133
134[[rule.threat.technique]]
135id = "T1531"
136name = "Account Access Removal"
137reference = "https://attack.mitre.org/techniques/T1531/"
138
139[rule.threat.tactic]
140id = "TA0040"
141name = "Impact"
142reference = "https://attack.mitre.org/tactics/TA0040/"
143
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146
147[[rule.threat.technique]]
148id = "T1484"
149name = "Domain or Tenant Policy Modification"
150reference = "https://attack.mitre.org/techniques/T1484/"
151
152[rule.threat.tactic]
153id = "TA0005"
154name = "Defense Evasion"
155reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Google Workspace Admin Role Deletion
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.emailoruser.name, and note thesource.ipandevent.ingestedtimestamps. - 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.nameand 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
<ROLE_NAME>with the value fromgoogle_workspace.admin.role.name:1data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "<ROLE_NAME>" - Review
user.target.emailanduser.target.namefor 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:
1data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "<ROLE_NAME>" - Review
google_workspace.admin.privilege.namevalues to understand what access was removed from assigned principals.
- Use the following KQL example to review any privileges that were granted to the role before deletion:
- Scope for related role activity by searching for the same
user.email(actor) performing other IAM actions such asDELETE_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
- 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 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_ROLEevents 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 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).
Setup
The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
Important Information Regarding Google Workspace Event Lag Times
- 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.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- 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.
- By default,
var.intervalis set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). - See the following references for further information:
References
Related rules
- Google Workspace Admin Role Assigned to a User or Group
- Google Workspace Custom Admin Role Created
- Google Workspace Role Modified
- Application Removed from Blocklist in Google Workspace
- Google Workspace Bitlocker Setting Disabled