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

nldcsc_elastic_rules/rules/integrations/github/impact_github_repository_deleted.toml

@@ -0,0 +1,84 @@
+[metadata]
+creation_date = "2023/08/29"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a GitHub repository is deleted within your organization. Repositories are a critical component
+used within an organization to manage work, collaborate with others and release products to the public. Any delete
+action against a repository should be investigated to determine it's validity. Unauthorized deletion of organization
+repositories could cause irreversible loss of intellectual property and indicate compromise within your organization.
+"""
+from = "now-9m"
+index = ["logs-github.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "GitHub Repository Deleted"
+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 GitHub Repository Deleted
+GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to confirm the repository deletion event by checking for entries where event.module is "github", event.dataset is "github.audit", and event.action is "repo.destroy".
+- Identify the user account associated with the deletion event and verify their access permissions and recent activity to determine if the action was authorized.
+- Contact the user or team responsible for the repository to confirm whether the deletion was intentional and documented.
+- Check for any recent changes in user access or permissions that could indicate a compromised account or unauthorized access.
+- Investigate any other suspicious activities or alerts related to the same user or repository around the time of the deletion event to identify potential patterns of malicious behavior.
+- Assess the impact of the repository deletion on ongoing projects and data availability, and initiate recovery procedures if necessary.
+
+### False positive analysis
+
+- Routine repository clean-up activities by authorized personnel may trigger alerts. To manage this, maintain a list of users or teams responsible for such tasks and create exceptions for their actions.
+- Automated scripts or tools used for repository management might delete repositories as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Test or temporary repositories that are frequently created and deleted during development cycles can cause false positives. Implement naming conventions for these repositories and configure the rule to ignore deletions matching these patterns.
+- Scheduled repository deletions as part of a lifecycle management policy can be mistaken for unauthorized actions. Document these schedules and adjust the detection rule to accommodate these planned activities.
+
+### Response and remediation
+
+- Immediately revoke access for any user account associated with the unauthorized repository deletion to prevent further malicious actions.
+- Restore the deleted repository from backups or snapshots, if available, to recover lost data and minimize operational disruption.
+- Conduct a thorough review of recent access logs and user activities to identify any other suspicious actions or potential indicators of compromise.
+- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and awareness.
+- Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future.
+- Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected.
+- Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors."""
+risk_score = 47
+rule_id = "345889c4-23a8-4bc0-b7ca-756bd17ce83b"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Use Case: UEBA",
+    "Tactic: Impact",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/github/persistence_github_org_owner_added.toml

@@ -0,0 +1,90 @@
+[metadata]
+creation_date = "2023/09/11"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a new member is added to a GitHub organization as an owner. This role provides admin level privileges. Any
+new owner roles should be investigated to determine it's validity. Unauthorized owner roles could indicate compromise
+within your organization and provide unlimited access to data and settings.
+"""
+from = "now-9m"
+index = ["logs-github.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "New GitHub Owner Added"
+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 New GitHub Owner Added
+
+GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific user account that was added as an owner, focusing on the event.action "org.add_member" and github.permission "admin".
+- Verify the identity and role of the newly added owner by cross-referencing with internal HR or user management systems to confirm if the addition was authorized.
+- Check the activity history of the newly added owner account for any suspicious actions or changes made to repositories or settings since their addition.
+- Contact the individual or team responsible for managing GitHub organization permissions to confirm if they were aware of and approved the new owner addition.
+- Investigate any recent changes in the organization's membership or access policies that might explain the addition of a new owner.
+- Assess the potential impact of the new owner's access by reviewing the repositories and sensitive data they now have administrative control over.
+
+### False positive analysis
+
+- Legitimate organizational changes: New owners may be added during legitimate restructuring or team expansions. Regularly review and document organizational changes to differentiate between authorized and unauthorized additions.
+- Automated processes: Some organizations use automated scripts or tools to manage GitHub permissions, which might trigger this rule. Identify and whitelist these processes to prevent unnecessary alerts.
+- Temporary access requirements: Occasionally, temporary owner access might be granted for specific projects or tasks. Implement a process to track and review these temporary changes, ensuring they are reverted once the task is completed.
+- Onboarding of new senior staff: When new senior staff members join, they might be added as owners. Establish a clear onboarding process that includes notifying the security team to avoid false positives.
+- Cross-functional team collaborations: In some cases, cross-functional teams may require owner-level access for collaboration. Maintain a list of such collaborations and review them periodically to ensure they remain necessary and authorized.
+
+### Response and remediation
+
+- Immediately revoke the admin privileges of the newly added GitHub owner to prevent further unauthorized access.
+- Conduct a thorough review of recent changes and activities performed by the unauthorized owner to identify any potential data breaches or malicious actions.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
+- Reset credentials and enforce multi-factor authentication for all existing GitHub organization owners to enhance security.
+- Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel.
+- Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly.
+- If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach."""
+risk_score = 47
+rule_id = "24401eca-ad0b-4ff9-9431-487a8e183af9"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Use Case: UEBA",
+    "Tactic: Persistence",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1136"
+name = "Create Account"
+reference = "https://attack.mitre.org/techniques/T1136/"
+[[rule.threat.technique.subtechnique]]
+id = "T1136.003"
+name = "Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1136/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/github/persistence_organization_owner_role_granted.toml

@@ -0,0 +1,88 @@
+[metadata]
+creation_date = "2023/09/11"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a member is granted the organization owner role of a GitHub organization. This role provides
+admin level privileges. Any new owner role should be investigated to determine its validity. Unauthorized owner roles
+could indicate compromise within your organization and provide unlimited access to data and settings.
+"""
+from = "now-9m"
+index = ["logs-github.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "GitHub Owner Role Granted To User"
+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 GitHub Owner Role Granted To User
+
+In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating privileges to maintain persistence or exfiltrate data. The detection rule monitors audit logs for changes in member roles to 'admin', signaling potential unauthorized access or privilege escalation attempts, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event where the member's role was changed to 'admin' to identify the user who made the change and the user who received the new role.
+- Verify the legitimacy of the role change by contacting the user who was granted the owner role and the user who performed the action to confirm if the change was authorized.
+- Check the organization's recent activity logs for any unusual or suspicious actions performed by the user who was granted the owner role, such as changes to repository settings or data access.
+- Investigate any recent changes in the organization's membership or permissions that could indicate a broader compromise or unauthorized access.
+- Assess the potential impact of the role change by identifying sensitive repositories or data that the new owner role could access, and determine if any data exfiltration or unauthorized changes have occurred.
+
+### False positive analysis
+
+- Role changes due to organizational restructuring or legitimate promotions can trigger alerts. Regularly update the list of expected role changes to minimize unnecessary alerts.
+- Automated scripts or integrations that manage user roles might inadvertently trigger the rule. Identify and whitelist these scripts to prevent false positives.
+- Temporary role assignments for project-specific tasks can be mistaken for unauthorized access. Implement a process to document and pre-approve such temporary changes.
+- Changes made by trusted administrators during routine audits or maintenance may be flagged. Maintain a log of scheduled maintenance activities to cross-reference with alerts.
+- Onboarding processes that involve granting admin roles to new employees can generate alerts. Ensure that onboarding procedures are documented and known exceptions are configured in the detection system.
+
+### Response and remediation
+
+- Immediately revoke the owner role from the user account identified in the alert to prevent further unauthorized access or changes.
+- Conduct a thorough review of recent activities performed by the user with the elevated privileges to identify any unauthorized changes or data access.
+- Reset the credentials and enforce multi-factor authentication for the affected user account to secure it against further compromise.
+- Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process.
+- Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited.
+- Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future."""
+risk_score = 47
+rule_id = "9b343b62-d173-4cfd-bd8b-e6379f964ca4"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Use Case: UEBA",
+    "Tactic: Persistence",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.003"
+name = "Additional Cloud Roles"
+reference = "https://attack.mitre.org/techniques/T1098/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/google_workspace/collection_google_drive_ownership_transferred_via_google_workspace.toml

@@ -0,0 +1,119 @@
+[metadata]
+creation_date = "2022/08/24"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2024/09/23"
+
+[rule]
+author = ["Elastic"]
+description = """
+Drive and Docs is a Google Workspace service that allows users to leverage Google Drive and Google Docs. Access to files
+is based on inherited permissions from the child organizational unit the user belongs to which is scoped by
+administrators. Typically if a user is removed, their files can be transferred to another user by the administrator.
+This service can also be abused by adversaries to transfer files to an adversary account for potential exfiltration.
+"""
+false_positives = [
+    """
+    Administrators may transfer file ownership during employee leave or absence to ensure continued operations by a new
+    or existing employee.
+    """,
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Google Drive Ownership Transferred via Google Workspace"
+note = """## Triage and analysis
+
+### Investigating Google Drive Ownership Transferred via Google Workspace
+
+Google Drive is a cloud storage service that allows users to store and access files. It is available to users with a Google Workspace account.
+
+Google Workspace administrators consider users' roles and organizational units when assigning permissions to files or shared drives. Owners of sensitive files and folders can grant permissions to users who make internal or external access requests. Adversaries abuse this trust system by accessing Google Drive resources with improperly scoped permissions and shared settings. Distributing phishing emails is another common approach to sharing malicious Google Drive documents. With this approach, adversaries aim to inherit the recipient's Google Workspace privileges when an external entity grants ownership.
+
+This rule identifies when the ownership of a shared drive within a Google Workspace organization is transferred to another internal user.
+
+#### Possible investigation steps
+
+- From the admin console, review admin logs for involved user accounts. To find admin logs, go to `Security > Reporting > Audit and investigation > Admin log events`.
+- Determine if involved user accounts are active. To view user activity, go to `Directory > Users`.
+- Check if the involved user accounts were recently disabled, then re-enabled.
+- Review involved user accounts for potentially misconfigured permissions or roles.
+- Review the involved shared drive or files and related policies to determine if this action was expected and appropriate.
+- If a shared drive, access requirements based on Organizational Units in `Apps > Google Workspace > Drive and Docs > Manage shared drives`.
+- Triage potentially related alerts based on the users involved. To find alerts, go to `Security > Alerts`.
+
+### False positive analysis
+
+- Transferring drives requires Google Workspace administration permissions related to Google Drive. Check if this action was planned/expected from the requester and is appropriately targeting the correct receiver.
+
+### 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.
+- 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/1247799?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 = "07b5f85a-240f-11ed-b3d9-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Tactic: Collection",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:"google_workspace.admin" and event.action:"CREATE_DATA_TRANSFER_REQUEST"
+  and event.category:"iam" and google_workspace.admin.application.name:Drive*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1074"
+name = "Data Staged"
+reference = "https://attack.mitre.org/techniques/T1074/"
+[[rule.threat.technique.subtechnique]]
+id = "T1074.002"
+name = "Remote Data Staging"
+reference = "https://attack.mitre.org/techniques/T1074/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+

nldcsc_elastic_rules/rules/integrations/google_workspace/collection_google_workspace_custom_gmail_route_created_or_modified.toml

@@ -0,0 +1,119 @@
+[metadata]
+creation_date = "2022/09/13"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2024/09/23"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a custom Gmail route is added or modified in Google Workspace. Adversaries can add a custom e-mail route
+for outbound mail to route these e-mails to their own inbox of choice for data gathering. This allows adversaries to
+capture sensitive information from e-mail and potential attachments, such as invoices or payment documents. By default,
+all email from current Google Workspace users with accounts are routed through a domain's mail server for inbound and
+outbound mail.
+"""
+false_positives = [
+    """
+    Administrators may create custom email routes in Google Workspace based on organizational policies, administrative
+    preference or for security purposes regarding spam.
+    """,
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Google Workspace Custom Gmail Route Created or Modified"
+note = """## Triage and analysis
+
+### Investigating Google Workspace Custom Gmail Route Created or Modified
+
+Gmail is a popular cloud-based email service developed and managed by Google. Gmail is one of many services available for users with Google Workspace accounts.
+
+Threat actors often send phishing emails containing malicious URL links or attachments to corporate Gmail accounts. Google Workspace identity relies on the corporate user Gmail account and if stolen, allows threat actors to further their intrusion efforts from valid user accounts.
+
+This rule identifies the creation of a custom global Gmail route by an administrator from the Google Workspace admin console. Custom email routes could indicate an attempt to secretly forward sensitive emails to unintentional recipients.
+
+#### Possible investigation steps
+
+- Identify the user account that created the custom email route and verify that they should have administrative privileges.
+- Review the added recipients from the custom email route and confidentiality of potential email contents.
+- Identify the user account, then review `event.action` values for related activity within the last 48 hours.
+- If the Google Workspace license is Enterprise Plus or Education Plus, search for emails matching the route filters. To find the Gmail event logs, go to `Reporting > Audit and investigation > Gmail log events`.
+- If existing emails have been sent and match the custom route criteria, review the sender and contents for malicious URL links and attachments.
+- Identified URLs or attachments can be submitted to VirusTotal for reputational services.
+
+### False positive analysis
+
+- This rule searches for domain-wide custom email routes created in the admin console of Google Workspace. Administrators might create custom email routes to fulfill organizational requirements.
+
+### 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.
+- 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/2685650?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 = "9510add4-3392-11ed-bd01-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Tactic: Collection",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:"google_workspace.admin" and event.action:("CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING")
+  and google_workspace.event.type:"EMAIL_SETTINGS" and google_workspace.admin.setting.name:("EMAIL_ROUTE" or "MESSAGE_SECURITY_RULE")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1114"
+name = "Email Collection"
+reference = "https://attack.mitre.org/techniques/T1114/"
+[[rule.threat.technique.subtechnique]]
+id = "T1114.003"
+name = "Email Forwarding Rule"
+reference = "https://attack.mitre.org/techniques/T1114/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+

nldcsc_elastic_rules/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml

@@ -0,0 +1,120 @@
+[metadata]
+creation_date = "2023/03/21"
+integration = ["google_workspace"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google
+Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do
+not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on
+behalf of users.
+"""
+false_positives = [
+    """
+    A user may generate a shared access link to encryption key files to share with others. It is unlikely that the
+    intended recipient is an external or anonymous user.
+    """,
+]
+from = "now-130m"
+index = ["filebeat-*", "logs-google_workspace*"]
+interval = "10m"
+language = "eql"
+license = "Elastic License v2"
+name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
+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 Drive Encryption Key(s) Accessed from Anonymous User
+
+Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings.
+
+### Possible investigation steps
+
+- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query.
+- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity.
+- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history.
+- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized.
+- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access.
+- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks.
+
+### False positive analysis
+
+- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users.
+- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account.
+- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts.
+- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts.
+- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats.
+
+### Response and remediation
+
+- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users.
+- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise.
+- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use.
+- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts.
+- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
+- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links.
+
+## 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/drive/answer/2494822",
+    "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 = "980b70a0-c820-11ed-8799-f661ea17fbcc"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Google Workspace",
+    "Use Case: Configuration Audit",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where event.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and
+    google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and
+    file.extension: (
+        "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key",
+        "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt",
+        "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+[[rule.threat.technique.subtechnique]]
+id = "T1552.004"
+name = "Private Keys"
+reference = "https://attack.mitre.org/techniques/T1552/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+