GhostAction Expands Attack: phishing to steal credentials and persistence in VS Code

A group behind the GhostAction campaign - already known for infiltrating GitHub Actions workflows into open source projects - has expanded its arsenal: in addition to installing malicious workflows in committed repositories, it now sends supplanting emails to capture credentials and delivers an information charger disguised as a source (.woff2) that acts as an infostealer with persistence in developer teams. This evolution, reported by OpenSourceMalware and reproduced by security means, shows a transition from the pure exploitation of automatic execution in CI to a combination of social engineering, abuse of OAuth and persistence in the development environment.

Facts confirmed: OpenSourceMalware researchers identified a registered domain as my-github [.] com that points to IP 193.32.204 [.] 199 - the same IP used by the campaign to exfilter data - and observed that the domain was used in a phishing mail that imitated a GitHub security notice to capture passwords and 2FA codes. The fraudulent page acted as a proxy inverse: it stole credentials and executed JavaScript that automatically authorized an OAuth application and completed the GitHub device flow to get a token with repo, workflow and read: org permissions. This token allows you to modify files under .github / workflows / and reinject malicious workflows. In addition, a second stage was detected in 94 repositories: inclusion of a .vscode / tasks.json with trigger runOn: folderOpen, a public / fonts / fa-solid-400.woff2 file containing the payload to steal credentials (AWS, PyPI, npm, Kubernetes, SSH, tokens from IA suppliers) and a backup workflow that, if the first track does not run the thief, launches the extraction and installs a crone that executes the attacking code every five minutes; the same filter occurs to the HT80 / 80TP.

How the attack chain works technically: the reported combined sequence can be summarized in this way. First, the actor commits repositories and adds a malicious workflow that, if run on GitHub Actions, collects accessible secrets (GitHub tokens, credentials on the repo) and sends them to a controlled server. To remove blocks in workflows, the attacker uses phishing directed: a domain similar to GitHub is recorded and used to send a false login notice. The proxy page steals credentials and, through scripts, automates the GitHub device flow to get a reuseable token without conscious user interaction. With that token the actor can write new workflows or files in repositories. If the performance control of Actions is limited by GitHub, the adversary adds components that are executed locally in the developer's machine (VS Code tasks and binary files disguised as sources) to persist and steal local secrets, also installing a cron to maintain regular access.

Who is affected and why it is relevant: the main target are open source project maintainers and developers with access to vulnerable or abandoned repositories. OpenSourceMalware accounted for 94 affected repositories belonging to 66 owners; many repositories were inactive (most without commitments in more than a year). The combination of unguarded repositories and excessive permissions in GitHub tokens facilitates lateral expansion: with a repository token the attacker can affect integration, packages and downstream users who trust those repositories.

The practical consequences include loss of reusable tokens that allow to modify code and CI flows, exposure of cloud credentials and supplier records (AWS, npm, PyPI), SSH key theft and IA APIs secrets - all data that allow from infrastructure abuse to malware distribution through legitimate artifacts. In addition, local persistence through a file that is activated when opening the project in VS Code increases the risk: developing with a compromised repository can turn the workstation into a back door.

Confirmed vs. uncertain: is a verified fact, according to reports, that the my-github [.] com domain was used for phishing and that the above IP served as an exfiltration point. The technical design of the device flow automation for tokens is also confirmed. It is not clear - according to the researchers themselves - whether other domains with similar names (e.g. my-gitlab [.] com) belong to the same operator: records, registrators and CRYPTO / DNS devices do not show a direct connection. The attribution of the actor remains unconfirmed and the exact motivation (financial, espionage, concept evidence) has not been established publicly.

Interpretation and context: The tactic reveals two known but more aggressively combined trends: (a) abuse of the OAuth / Device flow mechanism to achieve persistent credentials without explicit user intervention, and (b) use of persistence vectors in development tools (VS Code) that are not always audited by CI controls. GitHub's response - blocking the execution of the malicious workflow - reduced the effectiveness of the first stage, but the actor responded in a matter of days with a design that avoids the dependence of the runner. This illustrates the offensive-defensive dynamics in which attackers adapt their infrastructure after each mitigation measure.

Specific measures to be taken by developers and administrators today: revoke all of GitHub's tokens and authorizations from a clean device and rotate all of the credentials that may have been accessible to workflows (cloud keys, package tokens, registration credentials). Review and remove unknown OAuth applications on the setting page > Authorized OAuth apps and in the organization's tokens management. Auditing repositories by suspicious files (.github / workflows with common CI names, .vscode / tasks.json, unusual sources in public / fonts) and by any scheduled cron or task in developer workstations. Search for outgoing connections to 193.32.204 [.] 199 and domains my-github [.] com and block them at network level. Enable policies that limit workflow permits to what is strictly necessary and require manual reviews for changes in .github / workflows; use protection tools such as GitHub Actions security hardening and Require approval for third- party access in organizations. For high-value credentials (cloud, IA providers) consider immediate rotation and use of short-term credentials and secret management services. Finally, to increase the protection against phishing of OAuth, promote phishing-resistant authentication mechanisms (FIDO security keys) and specific education on social engineering using proxy pages and automatic flows.

For more technical information on how the device flow and preventive measures work in Actions, see GitHub's official documentation on the Device Flow and the Action Hardening Recommendations: https: / / docs.github.com / en / apps / oauth-apps / building-oauth-apps / authorizing-oauth-apps # devicu-flow and https: / / docs.github.com / en / actions / security-guides / security-hardening-for-github-actions. You can also follow research and samples in the analysis repository of OpenSourceMalware: https: / / opensourcemalware.org /.

In short, the GhostAction operation has demonstrated the ability to quickly adapt and mix supply-chain, OAuth phishing and local persistence techniques. Open source developers and maintenance organizations must assume that any repository with a history of inactive or recently unaudited commitments could be a vector and act with priority in the revocation, rotation and hardening of permits.