Google Workspace Suspended User Account Renewed

ELASTIC detection rule by Elastic · Elastic License v2

Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account.

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended
user account to maintain access to the Google Workspace organization with a valid account.
"""
false_positives = [
    """
    Google Workspace administrators may renew a suspended user account if the user is expected to continue employment at
    the organization after temporary leave. Suspended user accounts are typically used by administrators to remove
    access to the user while actions is taken to transfer important documents and roles to other users, prior to
    deleting the user account and removing the license.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Suspended User Account Renewed"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Google Workspace Suspended User Account Renewed

Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls.

### Possible investigation steps

- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action.
- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise.
- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal.
- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation.
- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization.

### False positive analysis

- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance.
- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation.
- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy.

### Response and remediation

- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings.
- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing.
- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts.
- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege.
- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised.
- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity.
- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future.

## 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.interval` is 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:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/1110339",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
]
risk_score = 73
rule_id = "00678712-b2df-11ed-afe9-f661ea17fbcc"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: google_workspace.admin and google_workspace.event.type: "USER_SETTINGS" and event.action: "UNSUSPEND_USER"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"


[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"


[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user.email",
    "source.ip",
    "google_workspace.actor.type",
    "user.target.email",
    "event.action",
    "cloud.account.id",
]

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

7608930e-2bde-4760-92e4-d3740af6b4ce

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion