Self-Hosted-Runner — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/self-hosted-runner/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jan 2024 14:30:00 +0000GitHub Self-Hosted Runner Configuration Changes Detectedhttps://feed.craftedsignal.io/briefs/2024-01-github-runner-changes/Wed, 03 Jan 2024 14:30:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-github-runner-changes/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

  1. 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.
  2. The attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).
  3. The attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).
  4. Alternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).
  5. The attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).
  6. 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.
  7. The attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.
  8. 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.
]]>lowadvisorygithubself-hosted-runneraudit-logdevopssupply-chain