[FR] Generate investigation guides (#4358)

rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -22,7 +22,7 @@ name = "GitHub Protected Branch Settings Changed"
 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"]
+tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Github", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
@@ -30,6 +30,40 @@ query = '''
 configuration where event.dataset == "github.audit"
   and github.category == "protected_branch" and event.type == "change"
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/execution_github_app_deleted.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -17,13 +17,48 @@ name = "GitHub App Deleted"
 risk_score = 21
 rule_id = "fd01b949-81be-46d5-bcf8-284395d5f56d"
 severity = "low"
-tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github"]
+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"
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -26,6 +26,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Execution",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
@@ -35,6 +36,40 @@ event.dataset:"github.audit" and event.category:"configuration" and event.action
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
 github.repository_public:false
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/14"
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Tactic: Execution",
     "Rule Type: Higher-Order Rule",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
@@ -34,6 +35,41 @@ type = "threshold"
 query = '''
 signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open"
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/execution_new_github_app_installed.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -23,13 +23,47 @@ name = "New GitHub App Installed"
 risk_score = 47
 rule_id = "1ca62f14-4787-4913-b7af-df11745a49da"
 severity = "medium"
-tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github"]
+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"
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/impact_github_repository_deleted.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -28,6 +28,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Impact",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -35,6 +36,39 @@ type = "eql"
 query = '''
 configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy"
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/persistence_github_org_owner_added.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Persistence",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -34,6 +35,41 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin"
 '''
+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."""
 
 
 [[rule.threat]]

rules/integrations/github/persistence_organization_owner_role_granted.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Persistence",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -34,6 +35,39 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin"
 '''
+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."""
 
 
 [[rule.threat]]