Unexpected ci-sync Branch on GitHub? What to Check and Rotate
A ci-sync- branch with a sync-check.yml file appeared in your repository, but no matching Actions run shows up. Is it Gheist, and which credentials need rotating?
- An unfamiliar
ci-sync-branch containingsync-check.ymlwarrants investigation against the Gheist indicators. - Contain malicious execution and credential access while preserving available evidence.
- The end of an Actions job does not invalidate every external credential it could read.
Check the workflow before treating the branch as routine maintenance
Wiz’s October 25 Gheist report identifies branches beginning with ci-sync- and six additional characters, adding .github/workflows/sync-check.yml with the commit message ci: sync config. Correlate the name with the file change and actor; the name alone is not proof.
Wiz says the campaign uses stolen tokens to plant workflows, retrieves secret-bearing logs through GitHub’s API, then deletes the runs. Do not approve a suspicious held run to find out what it does.
GitHub’s response guide calls for preserving available evidence while containing the threat: revoke abused credentials, cancel malicious runs and remove confirmed malicious branches. Containment should not wait for a complete forensic reconstruction.
A missing run is an investigation lead
Look for workflows.delete_workflow_run audit events and correlate them with pushes and branch activity. GitHub’s investigation reference describes how workflow and audit records complement each other.
Access depends on your plan, role and prior configuration. Organization owners can inspect organization audit logs; enterprise administrators can inspect enterprise logs. Workflow output also omits activity that never writes to standard output. An empty Actions view cannot establish that credentials stayed private.
Distinguish entry credentials from credentials exposed by the job
A token that pushed the workflow and an API key available inside that workflow are separate response targets.
| Credential or system | Response |
|---|---|
| Token used for the malicious push | Revoke it to stop further access. |
| Reachable repository, organization and environment secrets | Revoke or replace potentially exposed values at their issuing services, then update the stored secrets. |
| External credentials obtained during execution | Check the issuer’s expiry and revocation mechanisms. |
| Self-hosted runner that executed the malicious branch | Include the host and its instance role in the incident scope. |
GitHub distinguishes the job-scoped GITHUB_TOKEN, which expires when the job ends, from credentials with independent lifecycles. A PAT, app token or third-party key may remain valid until its own expiry or revocation. For Gheist specifically, Wiz advises treating an affected self-hosted machine and instance role as compromised.
Log masking does not control who can read a secret
GitHub’s secure-use guidance warns that transformations can defeat automatic redaction. Masking helps keep ordinary output clean; it does not replace least-privilege credentials or restrictions on which jobs receive them.
Environment protection rules offer a stronger access condition. With required reviewers configured, a job cannot read that environment’s secrets before approval. On Free, Pro and Team plans, required reviewers are limited to public repositories, so check plan support before designing that control for private repositories.
Record what was revoked and replaced, then check for unfamiliar workflows, webhooks, runners and app authorizations. Removing the visible branch is only one part of closing the attacker’s access.