nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/google_workspace/google_workspace_alert_center_promotion.toml

@@ -0,0 +1,76 @@
+[metadata]
+creation_date = "2023/01/15"
+integration = ["google_workspace"]
+maturity = "production"
+promotion = true
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert
+center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning
+of a potential security issue that Google has detected.
+"""
+false_positives = [
+    """
+    To tune this rule, add exceptions to exclude any google_workspace.alert.type which should not trigger this rule.
+    """,
+    "For additional tuning, severity exceptions for google_workspace.alert.metadata.severity can be added.",
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Forwarded Google Workspace Security Alert"
+note = """## Setup
+
+## Triage and analysis
+
+This is a promotion rule for Google Workspace security events, which are alertable events per the vendor.
+Consult vendor documentation on interpreting specific events.
+"""
+references = [
+    "https://workspace.google.com/products/admin/alert-center/",
+    "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 = "f1a6d0f4-95b8-11ed-9517-f661ea17fbcc"
+rule_name_override = "google_workspace.alert.type"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Use Case: Log Auditing",
+    "Use Case: Threat Detection",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: google_workspace.alert
+'''
+
+
+[[rule.severity_mapping]]
+field = "google_workspace.alert.metadata.severity"
+operator = "equals"
+severity = "low"
+value = "LOW"
+
+[[rule.severity_mapping]]
+field = "google_workspace.alert.metadata.severity"
+operator = "equals"
+severity = "medium"
+value = "MEDIUM"
+
+[[rule.severity_mapping]]
+field = "google_workspace.alert.metadata.severity"
+operator = "equals"
+severity = "high"
+value = "HIGH"
+
+

nldcsc_elastic_rules/rules/integrations/google_workspace/impact_google_workspace_admin_role_deletion.toml

@@ -0,0 +1,112 @@
+[metadata]
+creation_date = "2020/11/17"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2024/09/23"
+
+[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.
+"""
+false_positives = [
+    """
+    Google Workspace admin roles may be deleted by system administrators. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Google Workspace Admin Role Deletion"
+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.
+
+### False positive analysis
+
+- After identifying the user account that disabled the admin role, verify the action was intentional.
+
+### 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.
+- 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).
+
+## 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/2406043?hl=en",
+    "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 = 47
+rule_id = "93e63c3e-4154-4fc6-9f86-b411e0987bbf"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:DELETE_ROLE
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1531"
+name = "Account Access Removal"
+reference = "https://attack.mitre.org/techniques/T1531/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/google_workspace/impact_google_workspace_mfa_enforcement_disabled.toml

@@ -0,0 +1,116 @@
+[metadata]
+creation_date = "2020/11/17"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2024/09/23"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when multi-factor authentication (MFA) enforcement is disabled for Google Workspace users. An adversary may
+disable MFA enforcement in order to weaken an organization’s security controls.
+"""
+false_positives = [
+    """
+    MFA policies may be modified by system administrators. Verify that the configuration change was expected. Exceptions
+    can be added to this rule to filter expected behavior.
+    """,
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Google Workspace MFA Enforcement Disabled"
+note = """## Triage and analysis
+
+### Investigating Google Workspace MFA Enforcement Disabled
+
+Multi-factor authentication is a process in which users are prompted during the sign-in process for an additional form of identification, such as a code on their cellphone or a fingerprint scan.
+
+If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate.
+
+For more information about using MFA in Google Workspace, access the [official documentation](https://support.google.com/a/answer/175197).
+
+This rule identifies the disabling of MFA enforcement in Google Workspace. This modification weakens the security of the accounts and can lead to the compromise of accounts and other assets.
+
+#### Possible investigation steps
+
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Contact the account and resource owners and confirm whether they are aware of this activity.
+- Check if this operation was approved and performed according to the organization's change management policy.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+
+### False positive analysis
+
+- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain.
+
+### 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.
+- Reactivate the multi-factor authentication enforcement.
+- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
+- 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).
+
+## 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/9176657?hl=en#",
+    "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 = 47
+rule_id = "cad4500a-abd7-4ef3-b5d3-95524de7cfe1"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Use Case: Configuration Audit",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:google_workspace.admin and event.provider:admin
+  and event.category:iam and event.action:ENFORCE_STRONG_AUTHENTICATION
+  and google_workspace.admin.new_value:false
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1531"
+name = "Account Access Removal"
+reference = "https://attack.mitre.org/techniques/T1531/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/google_workspace/initial_access_external_user_added_to_google_workspace_group.toml

@@ -0,0 +1,122 @@
+[metadata]
+creation_date = "2023/02/16"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2024/09/23"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user
+accounts as a means to intercept shared files or emails with that specific group.
+"""
+false_positives = [
+    """
+    Administrators may add external users to groups to share files and communication with them via the intended
+    recipient be the group they are added to. It is unlikely an external user account would be added to an
+    organization's group where administrators should create a new user account.
+    """,
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "eql"
+license = "Elastic License v2"
+name = "External User Added to Google Workspace Group"
+note = """## Triage and analysis
+
+### Investigating External User Added to Google Workspace Group
+
+Google Workspace groups allow organizations to assign specific users to a group that can share resources. Application specific roles can be manually set for each group, but if not inherit permissions from the top-level organizational unit.
+
+Threat actors may use phishing techniques and container-bound scripts to add external Google accounts to an organization's groups with editorial privileges. As a result, the user account is unable to manually access the organization's resources, settings and files, but will receive anything shared to the group. As a result, confidential information could be leaked or perhaps documents shared with editorial privileges be weaponized for further intrusion.
+
+This rule identifies when an external user account is added to an organization's groups where the domain name of the target does not match the Google Workspace domain.
+
+#### Possible investigation steps
+- Identify user account(s) associated by reviewing `user.name` or `user.email` in the alert
+  - The `user.target.email` field contains the user added to the groups
+  - The `group.name` field contains the group the target user was added to
+- Identify specific application settings given to the group which may indicate motive for the external user joining a particular group
+- With the user identified, verify administrative privileges are scoped properly to add external users to the group
+  - Unauthorized actions may indicate the `user.email` account has been compromised or leveraged to add an external user
+- To identify other users in this group, search for `event.action: "ADD_GROUP_MEMBER"`
+  - It is important to understand if external users with `@gmail.com` are expected to be added to this group based on historical references
+- Review Gmail logs where emails were sent to and from the `group.name` value
+  - This may indicate potential internal spearphishing
+
+### False positive analysis
+- With the user account whom added the new user, verify this action was intentional
+- Verify that the target whom was added to the group is expected to have access to the organization's resources and data
+- If other members have been added to groups that are external, this may indicate historically that this action is expected
+
+### 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.
+- Reactivate multi-factor authentication for the user.
+- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
+- Implement security defaults [provided by Google](https://cloud.google.com/security-command-center/docs/how-to-investigate-threats).
+- 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.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/33329",
+    "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 = 47
+rule_id = "38f384e0-aef8-11ed-9a38-f661ea17fbcc"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+iam where event.dataset == "google_workspace.admin" and event.action == "ADD_GROUP_MEMBER" and
+  not endsWith(user.target.email, user.target.group.domain)
+'''
+
+
+[[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/"
+

nldcsc_elastic_rules/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml

@@ -0,0 +1,112 @@
+[metadata]
+creation_date = "2020/11/17"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[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*"]
+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 = 21
+rule_id = "00678712-b2df-11ed-afe9-f661ea17fbcc"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:google_workspace.admin and event.category:iam 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/"
+