GitHub Self-Hosted Runner Configuration Changes Detected
Detection of changes to self-hosted runner configurations in GitHub environments can indicate potential impact, discovery, collection, persistence, privilege escalation, initial access, or stealth activities.
This threat brief focuses on detecting changes to self-hosted runner configurations within GitHub environments. Self-hosted runners are systems deployed and managed by users to execute jobs from GitHub Actions, providing flexibility and control over the execution environment. Monitoring these runners is crucial because unauthorized modifications can lead to various malicious activities, including data collection, persistence, privilege escalation, or even initial access. The rule provided detects such changes based on audit logs, requiring administrators to validate the changes through the GitHub UI for complete context. Detecting these modifications early can help prevent or mitigate potential security breaches.
Attack Chain
- An attacker gains unauthorized access to a GitHub organization or repository with permissions to manage self-hosted runners. This could be achieved through compromised credentials (T1078.004) or exploiting a vulnerability.
- The attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).
- The attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).
- Alternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).
- The attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).
- The attacker uses the compromised runner or runner group to execute malicious code within the GitHub Actions workflow, potentially collecting sensitive data or escalating privileges.
- The attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.
- The attacker exploits the compromised runner to gain initial access to other systems or networks connected to the GitHub environment.
Impact
Compromised self-hosted runners can lead to a range of impacts, including data exfiltration, code injection, and privilege escalation within the targeted GitHub environment. Successful attacks could result in unauthorized access to sensitive repositories, modification of code, or deployment of malicious software. The impact can vary depending on the scope of the compromised runner and the permissions associated with it. The effects could extend beyond the GitHub environment if the compromised runner has access to other systems or networks.
Recommendation
- Enable the audit log streaming feature in GitHub to capture events related to self-hosted runner modifications, as required by the logsource definition.
- Deploy the Sigma rule “Github Self Hosted Runner Changes Detected” to your SIEM and tune for your specific environment to detect suspicious configuration changes.
- Regularly review the audit logs in the GitHub UI to validate any detected changes to self-hosted runners and runner groups to ensure legitimate modifications.
- Implement strict access control policies for managing self-hosted runners, limiting permissions to only authorized personnel.
Detection coverage 3
GitHub Self-Hosted Runner Creation Detected
lowDetects the registration of new self-hosted runners in a GitHub repository, which could indicate malicious activity.
GitHub Self-Hosted Runner Removal Detected
lowDetects the removal of self-hosted runners from a GitHub repository or organization, which could indicate malicious activity or an attempt to cover tracks.
GitHub Self-Hosted Runner Group Changes Detected
lowDetects changes to runner groups such as creation, removal, or modification.
Detection queries are kept inside the platform. Get full rules →