https://feed.craftedsignal.io/tags/devops/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jan 2024 14:30:00 +0000https://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-chainhttps://feed.craftedsignal.io/briefs/2024-01-github-actions-runner-execution/Tue, 02 Jan 2024 10:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-github-actions-runner-execution/Adversaries compromising GitHub Actions workflows can execute arbitrary commands on runner hosts, leading to code execution, reconnaissance, credential harvesting, or network exfiltration.This threat focuses on the exploitation of GitHub Actions runners by malicious actors. By gaining the ability to modify or trigger workflows in a linked GitHub repository, attackers can execute arbitrary commands on the runner host. The attack leverages the Runner.Worker process or shell interpreters launched via runner entrypoint scripts. Successful exploitation can lead to malicious workflow activity, including code execution, reconnaissance, credential harvesting, and network exfiltration. This presents a significant risk, particularly for organizations relying on self-hosted runners, as it allows attackers to potentially compromise the underlying infrastructure and sensitive data. The Elastic detection rule aims to identify such malicious activity.

Attack Chain

1. An attacker gains unauthorized access to a GitHub repository linked to a self-hosted runner.
2. The attacker modifies an existing workflow or creates a new one to inject malicious commands.
3. The compromised workflow is triggered, initiating the Runner.Worker process on the runner host.
4. The Runner.Worker process executes a shell interpreter (e.g., bash, sh, zsh) via an entrypoint script.
5. The shell interpreter executes malicious commands specified in the compromised workflow, such as downloading a payload using curl or wget.
6. The downloaded payload is executed, establishing a reverse shell connection to an attacker-controlled server using nc or socat.
7. The attacker performs reconnaissance, credential harvesting, or lateral movement within the runner host and connected network.
8. Sensitive data is exfiltrated from the compromised runner host to the attacker’s infrastructure.

Impact

A successful attack can lead to the complete compromise of the self-hosted runner environment. This could result in the theft of sensitive source code, credentials, and other proprietary information. The attack can also be used as a stepping stone for further attacks on the organization’s internal network and infrastructure. Affected sectors include software development, DevOps, and any organization using GitHub Actions with self-hosted runners.

Recommendation

• Deploy the Sigma rule Execution via GitHub Actions Runner to your SIEM to detect suspicious commands executed by the GitHub Actions Runner.
• Monitor process creation events for commands like curl, wget, nc, socat, powershell.exe, cmd.exe, bash, and ssh spawned by Runner.Worker or shell interpreters with entrypoint.sh in their command line (see Sigma rule).
• Implement strict access control policies for GitHub repositories and workflows to prevent unauthorized modifications.
• Regularly review and audit GitHub Actions workflows for suspicious or unexpected commands.
• Isolate self-hosted runners in a segmented network to limit the impact of a potential compromise.
• Enable Sysmon process-creation logging to provide detailed process execution information for effective detection.

]]>mediumadvisorygithub-actionssupply-chainexecutiondevops