« Machine Learning Detected a DNS Request Predicted to be a DGA Domain GitHub OAuth Application Authorized »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.37

GitHub Protected Branch Settings Changed

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

GitHub Protected Branch Settings Changed

edit

This rule detects protected branch setting changes on a GitHub repository originating from a user agent not previously seen performing protected branch changes in the last 7 days. Branch protection rules enforce workflows and requirements before a contributor can push changes to a branch. Unauthorized changes could be used to lower your organization’s security posture and leave you exposed for future attacks. Both push-time enforcement events (protected_branch.rejected_ref_update, a push blocked by branch protection) and administrative bypasses (protected_branch.policy_override) are retained, because a failed modification attempt and an admin override are each security-relevant indicators, particularly during CI/CD compromise once administrative access is obtained. Keying on a new user agent suppresses the recurring, expected automation that drives most of the event volume while surfacing changes from unfamiliar tooling or clients. If a specific user agent is noisy in a given environment, scope it with an exception rather than removing the action from the query.

Rule type: new_terms

Rule indices:

  • logs-github.audit-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Cloud
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: Github
  • Data Source: GitHub Audit Logs
  • Resources: Investigation Guide
  • Noise: High
  • Performance: Fast
  • Profile: Aggressive
  • Rule Type: New Terms
  • Platform: GitHub
  • Domain: SaaS

Version: 213

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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 query

edit
data_stream.dataset: "github.audit" and
    github.category: "protected_branch" and
    event.type: "change"

Framework: MITRE ATT&CKTM

« Machine Learning Detected a DNS Request Predicted to be a DGA Domain GitHub OAuth Application Authorized »