De Gheist-campagne gebruikt gehackte GitHub-accounts om via GitHub Actions geheime credentials te stelen uit private repositories.
Een bedreigingsactor die bekendstaat als Gheist zet gecompromitteerde GitHub-accounts in als platformen voor het verzamelen van inloggegevens. Door kwaadaardige GitHub Actions workflows in private repositories te plaatsen, kunnen de aanvallers repository- en omgevingsgeheimen blootleggen en deze via de GitHub API ophalen, waarna ze sporen van hun activiteiten wissen.
Wiz Research volgt deze campagne sinds 15 september en heeft meer dan 13.500 kwaadaardige branches ontdekt binnen ruim 850 gehackte accounts, verspreid over persoonlijke projecten en private bedrijfsrepositories. De aanvalsmethode maakt gebruik van GitHub Actions, de automatiseringsdienst van GitHub, waarmee de aanvallers toegang omzetten in gestolen credentials. De workflow creëert een branch, voegt een taak toe genaamd "sync-check" die probeert geheimen in de uitvoeringslogs te printen, haalt deze logs via de GitHub API op en verwijdert de workflow-run kort daarna. Omdat de geheimen via de eigen API van GitHub worden uitgelekt, is er geen uitgaand netwerkverkeer naar een aanvallersdomein dat geblokkeerd kan worden, aldus de onderzoekers in een blogpost.
GitHub heeft een controle ingevoerd die potentieel kwaadaardige workflow-runs in publieke repositories tegenhoudt totdat een medewerker ze goedkeurt. Deze maatregel bleek effectief tegen Gheist-activiteiten in publieke repositories, maar biedt geen bescherming voor private repositories of GitHub Enterprise Server, waar de aanvallen wel succesvol werden uitgevoerd.
De aanvallers maken gebruik van een zwakte in het geheim-maskeringsmechanisme van GitHub Actions. Normaal gesproken worden geheimen die letterlijk in logs verschijnen gemaskeerd, maar Gheist codeert deze geheimen eerst in base32 voordat ze worden gelogd. Hierdoor komen de geheime waarden onverminderd in de logs terecht. In repositories met deployment-omgevingen, zoals productie, richt Gheist zich op omgevingsspecifieke geheimen, waardoor niet alleen repositorygeheimen maar ook gevoelige credentials voor productiesystemen worden blootgesteld.
De campagne is geëvolueerd en richt zich nu ook op zelfgehoste GitHub Actions runners. De toegevoegde "sync-host" taak zoekt op deze hosts naar API-tokens, private sleutels, omgevingsbestanden, cloudcredentials en andere gevoelige data. Daarnaast probeert de taak toegang te krijgen tot de Docker-socket, cloud instance metadata en Kubernetes service-account tokens. Hoewel deze variant nog implementatiefouten bevat, betekent dit niet dat elke poging tot credential-extractie mislukt.
Wiz constateerde dat cloudcredentials van getroffen organisaties kort na de kwaadaardige workflows werden gebruikt om AWS Secrets Manager te doorzoeken. CloudTrail-logs tonen aan dat workflows op door aanvallers aangemaakte branches AWS-rollen aannamen, wat bewijst dat de aanvallen ook buiten GitHub-logs om werden uitgevoerd. De onderzoekers koppelen de bron van de gestolen credentials aan infostealer-logs en tokens die eerder zijn blootgesteld bij supply-chain aanvallen, waaronder de Trivy-compromittering in maart. Ook is er overlap met andere kwaadaardige activiteiten, zoals het hernoemen van repositories om cracked software te verspreiden en pogingen om GitHub Actions te misbruiken voor gratis rekenkracht.
Beveiligingsteams wordt geadviseerd te zoeken naar branches met namen die beginnen met "ci-sync-" gevolgd door zes willekeurige tekens, commits met de titel "ci: sync config" en workflow-runs die snel worden voltooid en verwijderd. Ook moeten zij cloudrol-assumpties die met deze branches samenhangen onderzoeken, gecompromitteerde tokens intrekken en alle repository-, organisatie- en omgevingsgeheimen roteren die toegankelijk zijn voor de getroffen workflows. Het verwijderen van een branch of run herstelt niet de blootstelling van credentials, waarschuwen de onderzoekers.
