Gheist: Stolen GitHub Tokens Used to Inject Secret-Stealing Actions Workflows

1. Basic Information

• Article: Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles
• Source: Wiz Research
• Published: October 25, 2026
• Original: Wiz Research
• Related Sources: GitHub: Environment Protection and Secrets, GitHub: Scope of Actions Secrets, GitHub: Workflow File Modification Permissions, Dark Reading, GitHub Workflow Protection
• Related Malware, Threat Groups, CVE, Products: Gheist, Unattributed Operator, GitHub Actions, GitHub Enterprise Server, AWS Secrets Manager
• Severity: Urgent

2. Executive Summary

Gheist is an ongoing attack campaign that uses illicitly obtained GitHub tokens to inject workflows into accessible repositories, logging and exfiltrating secrets. Wiz identified over 850 compromised accounts and more than 13,500 malicious branches. Executions in public repositories investigated by Wiz were blocked by GitHub's approval hold feature. In private repositories and GitHub Enterprise Server (GHES) environments, Wiz reported completed and deleted workflow runs, as well as subsequent AWS Secrets Manager enumeration using cloud credentials from the same organization. These findings do not mean that workflows ran successfully or secrets were stolen on every identified branch.

3. Attack Flow

In addition to the primary path abusing the GitHub API and Actions logs, there is a branching path involving jobs that explore assets on self-hosted runners. Note that self-hosted runner exploration and subsequent cloud operations have not been confirmed in all repositories.

Secret Exfiltration via GitHub-Hosted Runners

1. The attacker authenticates to the GitHub API using stolen tokens to enumerate and clone repositories with write permissions. Injecting a workflow requires permissions to add and edit workflow files in addition to standard write access.
2. The attacker creates a branch with a ci-sync- prefix followed by a six-character suffix and commits .github/workflows/sync-check.yml with the commit message ci: sync config.
3. The workflow triggered by the push base32-encodes environment variables from the execution environment and the secrets context accessible to the job, outputting them to the Actions execution log. Only organization secrets made available to the target repository are accessible. Environment secrets require the job to reference that environment and satisfy its protection rules. Note that setting permissions: {} on a job restricts the permissions of GITHUB_TOKEN; it does not block access to the secrets context.
4. The attack tool downloads the execution logs via the GitHub API and deletes the workflow run within seconds of log retrieval to eliminate traces. Direct communication with an external C2 server is not required in this step.
5. Wiz observed that in some affected organizations, the exfiltrated cloud credentials of the same organization were used hours later to enumerate AWS Secrets Manager. Separately, evidence was confirmed where the victim organization's existing workflows were triggered on attacker-created branches, assuming AWS roles via OIDC. OIDC role assumption alone does not prove that secret values were stolen.

Exploration Branch to Self-Hosted Runners

1. The sync-host job, introduced on October 19, runs on self-hosted runners when they are available to the targeted repository.
2. Its collection logic gathers host information and searches process environments, 31 token formats, SSH private keys, .env files, Terraform state, shell histories, cloud metadata, runner credentials, and Kubernetes service account tokens.
3. If it can access the Docker socket, it launches a container with the host's root filesystem mounted and attempts further searches on the host.
4. Collected information is aggregated into execution logs. However, this refers to the implementation capabilities of the collection tool and does not imply successful retrieval across all targets. Wiz verified errors in target paths for runner credential searches, flaws in regular expressions for URL credentials, and the absence of GCP or Azure token collection.

The following table summarizes implementations, observation results, and investigation perspectives. It does not indicate that all processes executed or succeeded across all branches.

Attack Stage	Attacker Action / Technique	Tools / Communications	Defensive Identifiers (Prerequisites / Traces)
Initial Access & Reconnaissance	Uses stolen GitHub tokens to access the GitHub API, enumerating writable repositories and permission scopes.	GitHub REST API, stolen PAT/OAuth tokens, user agent gheist	Unusual source IP, time window, unknown User-Agent accessing the API, rapid enumeration of numerous repositories
Malicious Branch Creation & Workflow Injection	Creates a predictably named branch and commits/pushes a malicious workflow for secret output.	git push, branch ci-sync-[0-9a-z]{6}, .github/workflows/sync-check.yml	Requires repository write access and workflow modification permissions. Non-standard branch creation, unsigned commits, ci: sync config
Workflow Execution (Hosted Environment)	Triggered Actions job base32-encodes environment variables and accessible secrets, writing them to logs.	GitHub Actions Runner, base32 encoding	The run must not be blocked by an approval hold, and only secrets available to the job can be accessed. Environment secrets require an environment reference and satisfied protection rules. Base32 strings or run completion alone do not prove exfiltration
Exploration Expansion (Self-Hosted Environment)	Launches sync-host on self-hosted runners to explore host environment variables, files, cloud metadata, and the Docker socket.	sync-host job, IMDS endpoint queries, Docker socket mounting	Requires available self-hosted runners and socket reachability for Docker exploration. Collection implementation contains flaws; successful retrieval of all targets is unconfirmed
Secret Recovery & Anti-Forensics	Retrieves execution logs via the GitHub API and deletes the corresponding run within one minute of completion.	GitHub API, run deletion request	Run deletion event immediately following workflow completion, deletion record in audit logs
Subsequent Compromise & Cloud Abuse	Wiz separately observed enumeration using cloud credentials from the same organization and OIDC role assumption by existing workflows on attacker branches. The latter alone does not prove secret-value theft.	Secrets Manager API, OIDC AWS role assumption	Unexpected IP calling AWS Secrets Manager, OIDC role assumption with ci-sync- in subject

4. Attacker Position and Execution Location

The attacker connects and authenticates to legitimate GitHub API endpoints from the external internet. Secret enumeration processes run inside GitHub-hosted runners or self-hosted runners managed by the victim organization, and collected data is output to GitHub Actions execution logs.

5. Perspective of Victims and Administrators

• Developers: Commits may appear under the token owner's name, but they lack commit signatures and are created on ci-sync-* branches that do not exist in normal operations.
• Administrators: Detected via the creation of new workflows, workflow runs that complete and are deleted shortly afterward, repeated use of multiple user or automation tokens, and histories of cloud role assumptions originating from attacker-created branches.

6. Success and Failure Conditions

Success Conditions

• A valid GitHub token is stolen, granting write permissions to target repositories as well as permissions to add and modify workflow files (classic PATs and OAuth tokens require the workflow scope).
• The pushed workflow executes without being blocked by approval holds or environment reviewer configurations.
• At least one of the following is accessible from the executed workflow: repository secrets, environment secrets, OIDC trust relationships, or sensitive assets on self-hosted runners.

Failure Conditions and Mitigations

• Protection mechanisms for public repositories on GitHub.com place potentially malicious executions in an approval hold state (action_required), preventing execution (all executions in public repositories investigated by Wiz were halted, but this automatic hold does not apply to private environments or GHES).
• Promptly revoke compromised tokens and migrate to least-privilege (fine-grained) and short-lived credentials.
• Use required environment reviewers and deployment branch restrictions where supported by your GitHub plan, and limit OIDC trust policy subjects to approved branches and environments (protecting only the default branch does not prevent execution of workflows pushed to new branches or access to repository secrets).
• Configure self-hosted runners to be ephemeral and strictly restrict reachability to Docker sockets and cloud metadata endpoints.

7. What Happens Upon Success

Secrets available to the job—including repository secrets, organization secrets made available to the repository, and secrets from referenced environments whose protection rules are satisfied—may be exposed or stolen. Private source code readable with the stolen token may also be copied. Additionally, unauthorized use of cloud credentials or OIDC role assumption through existing workflows with relaxed branch conditions could expand the compromise into cloud infrastructure. On self-hosted runners, impacts may extend to host systems, containers, Kubernetes environments, and API tokens for AI service providers.

8. Observable Logs

The following includes investigation ideas (Inference). Accessible logs depend on products and configuration settings, and matching identifiers alone does not confirm successful information exfiltration.

• Email: No email-initiated activities specific to this campaign have been reported.
• Proxy / SWG / DNS: Because GitHub API is used without requiring a dedicated external C2 server for secret retrieval, relying solely on outbound traffic monitoring to attacker domains is insufficient for detection (this does not mean no traffic occurs).
• Endpoint / EDR: Script traces such as .gdmp_pat, .gdmp_patg, .gdmp_sweep, and gdmp-pivot, alongside container launches mounting the host filesystem.
• Identity / IdP: GitHub API usage histories from token owners showing unusual locations, unusual times of day, or unknown User-Agents.
• SaaS / Cloud: Branch creation matching ^ci-sync-[0-9a-z]{6}$, sync-check.yml, commit message ci: sync config, run deletion within one minute of completion, User-Agent gheist, and cloud role assumption with ci-sync- in the subject.
• Network: Suspicious traffic from self-hosted runners to cloud metadata endpoints or unknown external resources.

9. Attack Success Assessment

• The mere existence of a branch or workflow file does not confirm the successful execution of a malicious payload. Once file creation via a stolen token is confirmed, it is determined that GitHub authentication succeeded and repository modification was established.
• The public-repository runs examined by Wiz were held at action_required; their malicious payloads did not execute.
• While workflow completion and deletion events are important investigative clues, they do not independently confirm the success of secret output processing. Verify the success or failure of jobs and individual steps alongside the contents of preserved logs.
• Evaluate evidence of actual secret values output to execution logs separately from evidence of the attacker downloading and obtaining those logs. If a step successfully writes secret values to a log, treat those values as exposed to anyone with access to that log. Unauthorized use of the same credentials on the cloud side serves as independent evidence supporting subsequent session compromise.
• OIDC role assumption originating from an attacker branch provides evidence that a workflow ran on that branch and acquired a cloud role. This alone neither confirms nor rules out theft of values from the secrets context.

10. Investigation Playbook

1. Trigger: Detect ci-sync-* branches, sync-check.yml, commit message ci: sync config, and User-Agent gheist.
2. Initial Verification: Confirm the branch creator, token type and scope, affected repositories, workflow execution results, presence of environment references, and run deletion timestamps.
3. Endpoint Investigation: Check for infostealer infection traces on the token owner's device, helper files on self-hosted runners, container launches, and process exploration traces.
4. Authentication & Cloud: Correlate GitHub audit logs with cloud audit logs to track OIDC subjects, role assumption history, and Secrets Manager enumeration operations.
5. Subsequent Action Tracking: Identify cloning of private repositories, creation of additional workflows or branches, and cloud secret usage histories.
6. Containment: Revoke compromised tokens, rotate all accessible secrets, isolate and delete malicious branches, rebuild runner environments, and correct OIDC trust policies.
7. Evaluation Categories: Assess branch creation, workflow holds, workflow execution, secret output, log acquisition, and subsequent cloud activity as distinct phases.

11. Defense and Detection Ideas

• Single Events: Alerts for added sync-check.yml, commit ci: sync config, User-Agent gheist, and gdmp-pivot.
• Timeline Correlation: Correlate the sequence from token authentication -> repository enumeration and cloning -> branch push -> workflow completion -> run deletion -> cloud role assumption.
• Threat Hunting: Search across all repositories for ci-sync-* branches or known workflow blob SHAs, prioritizing private repositories and GHES environments.
• Log Retention Considerations: Because execution logs are deleted rapidly, maintaining a mechanism for long-term archiving of organization audit logs and cloud-side audit logs to secure external storage is essential.
• Prioritized Controls: Use least-privilege, short-lived tokens, apply environment reviewers, design OIDC trust policies restricted to specific branches, operate ephemeral self-hosted runners, and maintain rapid secret rotation capabilities.

12. Facts / Inference / Hypothesis

Facts

• Wiz confirmed over 850 compromised accounts, more than 13,500 malicious branches, workflow executions in private and enterprise environments, and AWS Secrets Manager enumeration activities using cloud credentials from the same organization.
• Target executions identified in public repositories were entirely blocked by GitHub's approval hold feature.

Inference

• Because the attack methodology does not rely on dedicated external C2 communications, integrated correlation analysis of GitHub audit logs and cloud-side audit logs is key to defense.
• Based on Wiz's recommendations, if a malicious job actually runs on a self-hosted runner, it is recommended as a proactive containment measure to treat the host environment and instance role as potentially compromised. However, the completion of workflows or success of jobs on GitHub-hosted runners alone should not be presumed to indicate that a self-hosted runner host was compromised.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Unresolved Items and Further Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1078	Valid Accounts	high	Authenticates to legitimate API endpoints using stolen legitimate GitHub tokens to perform repository writes.
T1552.001	Unsecured Credentials: Credentials In Files	high	Jobs targeting self-hosted runners contain implementations to explore credential files such as .env, private keys, Terraform state, and shell histories. This does not imply successful retrieval across all targets.
T1552.005	Unsecured Credentials: Cloud Instance Metadata API	high	Jobs targeting self-hosted runners include implementations to explore cloud metadata, although per Wiz reports, GCP and Azure tokens are not collected. This mapping does not uniformly indicate successful exfiltration across all providers.
T1005	Data from Local System	medium	Jobs targeting self-hosted runners contain implementations to explore host filesystems and process environment variables. Host exploration via the Docker socket requires socket reachability, and successful retrieval across all targets remains unconfirmed.

14. Unresolved Items and Further Investigation

• The complete initial pathways for GitHub token theft, the exact percentage of accounts where workflows actually executed, and detailed correlations between individual secret outputs and subsequent cloud operations remain unconfirmed.
• Account overlaps with decoy repositories, cryptomining, PolinRider, and Megalodon have been observed, but this does not prove operation by the same threat group.
• The creation of a branch in public repositories cannot be counted as successful secret exfiltration.

15. Impact on SOCs and Organizations

Organizations using GitHub Actions should prioritize inspecting private repositories and GHES environments alongside public repositories. Long-lived Personal Access Tokens (PATs), environments without protection settings, OIDC trust relationships lacking branch restrictions, and persistent self-hosted runners significantly expand the impact scope of a compromise.

16. Summary by Target Audience

• For SOCs: Monitor and correlate branch creation, workflow execution, run deletion, User-Agent, and cloud role assumption events on a unified timeline.
• For Administrators: Promptly revoke compromised tokens, rotate accessible secrets, and advance the hardening of OIDC trust relationships and runner environments.
• For Users: Promptly report signs of infostealer infections on devices utilizing tokens or unexpected modifications to repositories to administrators.