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

nldcsc_elastic_rules/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a
+special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use
+service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud
+Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a
+security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions
+assigned to that account and evade detection.
+"""
+false_positives = [
+    """
+    Service account keys may be created by system administrators. Verify that the configuration change was expected.
+    Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Service Account Key Creation"
+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 GCP Service Account Key Creation
+
+In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation.
+- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks.
+- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously.
+- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation.
+- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations.
+- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities.
+
+### False positive analysis
+
+- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata.
+- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels.
+- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved.
+- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts.
+- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context.
+
+### Response and remediation
+
+- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool.
+- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited.
+- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise.
+- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk.
+- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future.
+- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://cloud.google.com/iam/docs/service-accounts",
+    "https://cloud.google.com/iam/docs/creating-managing-service-account-keys",
+]
+risk_score = 21
+rule_id = "0e5acaae-6a64-4bbc-adb8-27649c03f7e1"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccountKey and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[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/"
+

nldcsc_elastic_rules/rules/integrations/gcp/persistence_gcp_service_account_created.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a new service account is created in Google Cloud Platform (GCP). A service account is a special type of
+account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to
+make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users
+through domain-wide delegation. If service accounts are not tracked and managed properly, they can present a security
+risk. An adversary may create a new service account to use during their operations in order to avoid using a standard
+user account and attempt to evade detection.
+"""
+false_positives = [
+    """
+    Service accounts can be created by system administrators. Verify that the behavior was expected. Exceptions can be
+    added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Service Account Creation"
+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 GCP Service Account Creation
+
+In GCP, service accounts enable applications and VMs to interact with APIs securely. While essential for automation, they can be exploited if improperly managed. Adversaries might create service accounts to gain persistent access without detection. The detection rule monitors audit logs for successful service account creations, flagging potential unauthorized activities for further investigation.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateServiceAccount to identify the time and source of the service account creation.
+- Check the identity of the user or service that initiated the service account creation to determine if it aligns with expected administrative activities.
+- Investigate the permissions and roles assigned to the newly created service account to assess if they are excessive or unusual for its intended purpose.
+- Correlate the service account creation event with other recent activities in the environment to identify any suspicious patterns or anomalies.
+- Verify if the service account is being used by any unauthorized applications or VMs by reviewing recent API calls and access logs associated with the account.
+
+### False positive analysis
+
+- Routine service account creation by automated deployment tools or scripts can trigger false positives. Identify and document these tools, then create exceptions in the monitoring system to exclude these known activities.
+- Service accounts created by trusted internal teams for legitimate projects may also be flagged. Establish a process for these teams to notify security personnel of planned service account creations, allowing for pre-approval and exclusion from alerts.
+- Scheduled maintenance or updates that involve creating temporary service accounts can result in false positives. Coordinate with IT operations to understand their schedules and adjust monitoring rules to accommodate these activities.
+- Third-party integrations that require service accounts might be mistakenly flagged. Maintain an inventory of authorized third-party services and their associated service accounts to quickly verify and exclude these from alerts.
+
+### Response and remediation
+
+- Immediately disable the newly created service account to prevent any unauthorized access or actions.
+- Review the IAM policy and permissions associated with the service account to ensure no excessive privileges were granted.
+- Conduct a thorough audit of recent activities performed by the service account to identify any suspicious or unauthorized actions.
+- Notify the security team and relevant stakeholders about the potential security incident for further investigation and coordination.
+- Implement additional monitoring and alerting for service account creations to detect similar activities in the future.
+- If malicious activity is confirmed, follow incident response procedures to contain and remediate any impact, including revoking access and conducting a security review of affected resources.
+- Document the incident and response actions taken to improve future detection and response capabilities.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/iam/docs/service-accounts"]
+risk_score = 21
+rule_id = "7ceb2216-47dd-4e64-9433-cddc99727623"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccount and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1136"
+name = "Create Account"
+reference = "https://attack.mitre.org/techniques/T1136/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml

@@ -0,0 +1,90 @@
+[metadata]
+creation_date = "2023/08/29"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be
+used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository.
+Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized
+changes could be used to lower your organization's security posture and leave you exposed for future attacks.
+"""
+from = "now-9m"
+index = ["logs-github.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "GitHub Protected Branch Settings Changed"
+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 Protected Branch Settings Changed
+
+GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific changes made to the protected branch settings, focusing on entries where event.dataset is "github.audit" and github.category is "protected_branch".
+- Determine the user account responsible for the changes by examining the audit log details, and verify if the account has a legitimate reason to modify branch protection settings.
+- Check the timing of the changes to see if they coincide with any other suspicious activities or known incidents within the organization.
+- Investigate the context of the change by reviewing recent pull requests or commits to the affected branch to assess if the changes align with ongoing development activities.
+- Communicate with the repository owner or relevant team members to confirm if the changes were authorized and necessary for current project requirements.
+- Evaluate the impact of the changes on the repository's security posture and consider reverting the changes if they were unauthorized or pose a security risk.
+
+### False positive analysis
+
+- Routine updates by trusted team members may trigger alerts. To manage this, create exceptions for specific users or teams who regularly update branch protection settings as part of their role.
+- Automated tools or scripts that modify branch settings for legitimate reasons can cause false positives. Identify these tools and whitelist their activities in the monitoring system.
+- Scheduled maintenance or policy updates might lead to expected changes in branch protection settings. Document these events and adjust the detection rule to ignore changes during these periods.
+- Changes made by administrators during onboarding or offboarding processes can be mistaken for unauthorized activity. Ensure these processes are well-documented and communicated to the security team to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revert any unauthorized changes to the protected branch settings to restore the original security posture.
+- Conduct a review of recent commits and merges to the affected branch to identify any unauthorized code changes that may have occurred during the period of altered settings.
+- Temporarily restrict access to the repository for users who made unauthorized changes until a full investigation is completed.
+- Notify the security team and relevant stakeholders about the incident for further analysis and to determine if additional security measures are needed.
+- Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities.
+- Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings.
+- Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans."""
+risk_score = 47
+rule_id = "07639887-da3a-4fbf-9532-8ce748ff8c50"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+configuration where event.dataset == "github.audit"
+  and github.category == "protected_branch" and event.type == "change"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/github/execution_github_app_deleted.toml

@@ -0,0 +1,80 @@
+[metadata]
+creation_date = "2023/10/11"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = "Detects the deletion of a GitHub app either from a repo or an organization.\n"
+from = "now-9m"
+index = ["logs-github.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "GitHub App 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 App Deleted
+
+GitHub Apps are integrations that extend GitHub's functionality, often used to automate workflows or manage repositories. Adversaries might delete these apps to disrupt operations or remove security controls. The detection rule monitors audit logs for app deletions, flagging potential unauthorized actions. By focusing on specific event types and categories, it helps identify suspicious deletions that could indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event type "deletion" within the "integration_installation" category to identify the exact GitHub app that was deleted.
+- Determine the user or account responsible for the deletion by examining the associated user information in the audit logs.
+- Check the timing of the deletion event to see if it coincides with any other suspicious activities or anomalies in the repository or organization.
+- Investigate the role and permissions of the user who performed the deletion to assess if they had legitimate access and authorization to delete the app.
+- Look into the history of the deleted GitHub app to understand its purpose, usage, and any dependencies it might have had within the organization or repository.
+- Communicate with the team or organization members to verify if the deletion was intentional and authorized, or if it was unexpected and potentially malicious.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger app deletions. Verify with the team responsible for GitHub app management to confirm if the deletion was planned.
+- Automated scripts or tools used for managing GitHub apps might inadvertently delete apps during updates or reconfigurations. Review the scripts and ensure they have proper safeguards to prevent accidental deletions.
+- Organizational policy changes might lead to the removal of certain apps. Check if there have been recent policy updates that could explain the deletion.
+- Exclude specific users or service accounts known to perform legitimate app deletions regularly by creating exceptions in the detection rule.
+- Monitor for patterns of deletions that align with scheduled maintenance windows and adjust the rule to ignore these timeframes if they consistently result in false positives.
+
+### Response and remediation
+
+- Immediately revoke any compromised credentials or tokens associated with the deleted GitHub app to prevent unauthorized access.
+- Restore the deleted GitHub app from a backup or re-install it to ensure continuity of operations and security controls.
+- Conduct a thorough review of recent changes and activities in the affected repositories or organization to identify any unauthorized actions or data alterations.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
+- Implement additional monitoring on the affected repositories or organization to detect any further suspicious activities or attempts to delete apps.
+- Review and tighten permissions for GitHub apps to ensure only authorized personnel have the ability to delete or modify app installations.
+- Escalate the incident to higher-level security management if there is evidence of a broader compromise or if the deletion is part of a larger attack campaign."""
+risk_score = 21
+rule_id = "fd01b949-81be-46d5-bcf8-284395d5f56d"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1648"
+name = "Serverless Execution"
+reference = "https://attack.mitre.org/techniques/T1648/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml

@@ -0,0 +1,93 @@
+[metadata]
+creation_date = "2023/10/11"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects a high number of unique private repo clone events originating from a single personal access token within a short
+time period.
+"""
+from = "now-6m"
+index = ["logs-github.audit-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "High Number of Cloned GitHub Repos From PAT"
+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 High Number of Cloned GitHub Repos From PAT
+
+Personal Access Tokens (PATs) facilitate automated access to GitHub repositories, enabling seamless integration and management. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive code. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the specific personal access token (PAT) involved in the alert to determine its owner and associated user account.
+- Analyze the event logs for the PAT to identify the number and names of private repositories cloned, focusing on any unusual or unauthorized access patterns.
+- Check the access history of the PAT to see if there are any other suspicious activities or anomalies, such as access from unfamiliar IP addresses or locations.
+- Contact the owner of the PAT to verify if the cloning activity was authorized and to gather additional context about the usage of the token.
+- Investigate the security posture of the affected repositories, including reviewing access permissions and recent changes to repository settings.
+- Consider revoking the compromised PAT and issuing a new one if unauthorized access is confirmed, and ensure the user updates any systems or scripts using the old token.
+
+### False positive analysis
+
+- Legitimate automated processes or CI/CD pipelines may trigger multiple clone events. Review and whitelist known IP addresses or tokens associated with these processes to prevent false alerts.
+- Developers working on multiple projects might clone several private repositories in a short period. Identify and exclude these users or their tokens from triggering alerts by maintaining a list of frequent cloners.
+- Organizational scripts or tools that require cloning multiple repositories for updates or backups can cause false positives. Document these scripts and create exceptions for their associated tokens.
+- Scheduled maintenance or migration activities involving repository cloning can be mistaken for suspicious activity. Coordinate with relevant teams to anticipate such events and temporarily adjust detection thresholds or exclude specific tokens.
+
+### Response and remediation
+
+- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access to private repositories.
+- Notify the repository owners and relevant stakeholders about the potential breach to assess the impact and initiate internal incident response procedures.
+- Conduct a thorough review of the cloned repositories to identify any sensitive or proprietary information that may have been exposed.
+- Implement additional access controls, such as IP whitelisting or two-factor authentication, to enhance security for accessing private repositories.
+- Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials.
+- Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised.
+- Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future."""
+risk_score = 21
+rule_id = "fb0afac5-bbd6-49b0-b4f8-44e5381e1587"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Use Case: UEBA",
+    "Tactic: Execution",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:"github.audit" and event.category:"configuration" and event.action:"git.clone" and
+github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
+github.repository_public:false
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1648"
+name = "Serverless Execution"
+reference = "https://attack.mitre.org/techniques/T1648/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+
+[rule.threshold]
+field = ["github.hashed_token"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "github.repo"
+value = 10
+
+

nldcsc_elastic_rules/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml

@@ -0,0 +1,88 @@
+[metadata]
+creation_date = "2023/12/14"
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule is part of the "GitHub UEBA - Unusual Activity from Account Pack", and leverages alert data to determine when
+multiple alerts are executed by the same user in a timespan of one hour. Analysts can use this to prioritize triage and
+response, as these alerts are a higher indicator of compromised user accounts or PATs.
+"""
+from = "now-60m"
+index = [".alerts-security.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GitHub UEBA - Multiple Alerts from a GitHub Account"
+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 UEBA - Multiple Alerts from a GitHub Account
+
+User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts or tokens. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period. This detection rule flags such anomalies by monitoring for multiple alerts from the same user within an hour, aiding in prioritizing potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details in the security dashboard to identify the specific user account associated with the multiple alerts.
+- Check the recent activity logs for the identified user in GitHub to determine the nature and frequency of actions performed within the alert timeframe.
+- Investigate any recent changes to the user's permissions or access levels that might have facilitated unusual activity.
+- Correlate the alert data with other security tools or logs to identify any additional suspicious behavior or related alerts involving the same user.
+- Contact the user to verify if the actions were legitimate or if they suspect their account or personal access token (PAT) might be compromised.
+- If a compromise is suspected, initiate a password reset and revoke any active PATs for the user, and monitor for any further suspicious activity.
+
+### False positive analysis
+
+- High-frequency automated workflows or CI/CD pipelines may trigger multiple alerts within an hour. Review these workflows to ensure they are legitimate and consider adding exceptions for known, non-threatening automation.
+- Developers or teams working on time-sensitive projects might perform numerous actions in a short period, leading to false positives. Identify these users or teams and create exceptions to prevent unnecessary alerts.
+- Scheduled tasks or scripts that interact with GitHub repositories can generate multiple alerts. Verify the legitimacy of these tasks and exclude them from the rule if they are deemed safe.
+- Frequent use of GitHub Actions or bots that perform repetitive tasks could be misinterpreted as suspicious activity. Confirm their purpose and add them to an allowlist if they are part of normal operations.
+- Consider implementing a review process for alerts that involve known trusted users or service accounts to quickly dismiss false positives without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected GitHub account by revoking all active sessions and tokens to prevent further unauthorized actions.
+- Conduct a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Review recent activity logs for the affected account to identify any unauthorized changes or data exfiltration, and revert any malicious modifications.
+- Notify the account owner and relevant security teams about the potential compromise to ensure awareness and coordinated response efforts.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional accounts or systems are affected.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Update and refine access controls and permissions for the affected account to minimize the risk of future unauthorized actions."""
+risk_score = 47
+rule_id = "929223b4-fba3-4a1c-a943-ec4716ad23ec"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Use Case: UEBA",
+    "Tactic: Execution",
+    "Rule Type: Higher-Order Rule",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+
+[rule.threshold]
+field = ["user.name"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "signal.rule.name"
+value = 5
+
+

nldcsc_elastic_rules/rules/integrations/github/execution_new_github_app_installed.toml

@@ -0,0 +1,85 @@
+[metadata]
+creation_date = "2023/08/29"
+integration = ["github"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a new GitHub App has been installed in your organization account. GitHub Apps extend GitHub's
+functionality both within and outside of GitHub. When an app is installed it is granted permissions to read or modify
+your repository and organization data. Only trusted apps should be installed and any newly installed apps should be
+investigated to verify their legitimacy. Unauthorized app installation could lower your organization's security posture
+and leave you exposed for future attacks.
+"""
+from = "now-9m"
+index = ["logs-github.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "New GitHub App Installed"
+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 App Installed
+
+GitHub Apps enhance functionality by integrating with repositories and organization data, requiring careful scrutiny upon installation. Adversaries may exploit these apps to gain unauthorized access or manipulate data. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations, thus safeguarding organizational security.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset "github.audit" and event.action "integration_installation.create" to identify the newly installed GitHub App.
+- Verify the identity of the user or service account that performed the installation to ensure it aligns with expected behavior and authorized personnel.
+- Check the permissions requested by the newly installed app to assess the level of access it has to your repositories and organization data.
+- Cross-reference the app with a list of approved or trusted applications within your organization to determine if it is authorized.
+- Investigate the app's developer or vendor to ensure they are reputable and have a history of secure and reliable applications.
+- Communicate with the team or individual responsible for the installation to confirm the app's purpose and necessity within the organization.
+
+### False positive analysis
+
+- Frequent installations of trusted internal apps may trigger alerts. To manage this, maintain a list of approved internal apps and create exceptions for these in the detection rule.
+- Automated deployment tools that integrate with GitHub might cause false positives. Identify these tools and exclude their installation events from triggering alerts.
+- Regular updates or re-installations of existing apps can be mistaken for new installations. Track app version updates separately and adjust the rule to differentiate between updates and new installations.
+- Development or testing environments often install and remove apps frequently. Consider excluding these environments from the rule or setting up a separate monitoring process for them.
+
+### Response and remediation
+
+- Immediately revoke the permissions of the newly installed GitHub App to prevent any unauthorized access or data manipulation.
+- Notify the security team and relevant stakeholders about the unauthorized app installation for awareness and further investigation.
+- Conduct a review of recent repository and organization changes to identify any unauthorized modifications or data access that may have occurred.
+- If malicious activity is detected, initiate a rollback of affected repositories to a secure state prior to the app installation.
+- Escalate the incident to higher-level security management if the app installation is linked to a broader security breach or if sensitive data has been compromised.
+- Implement stricter access controls and approval processes for future GitHub App installations to prevent unauthorized installations.
+- Update detection mechanisms to include additional indicators of compromise related to GitHub App installations, enhancing future threat detection capabilities."""
+risk_score = 47
+rule_id = "1ca62f14-4787-4913-b7af-df11745a49da"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Github",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+configuration where event.dataset == "github.audit" and event.action == "integration_installation.create"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1072"
+name = "Software Deployment Tools"
+reference = "https://attack.mitre.org/techniques/T1072/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+