FakeGit Campaign Reactivates with 17,600+ Malicious GitHub Repositories

The FakeGit malware campaign has reactivated in force, deploying over 17,600 malicious GitHub repositories designed to distribute the SmartLoader dropper and deliver secondary payloads, including the StealC information stealer. Security researchers at Apiiro observed a massive surge in activity starting October 4, during which the threat actor pushed more than 13,000 repositories in a 34-hour window, peaking at an influx of 2,999 repositories per hour.

Rather than building fresh repositories from scratch, the operator relies on pre-staged infrastructure across throwaway accounts and approximately 700 compromised legitimate developer accounts. By re-aiming existing repositories rather than creating new ones, the campaign bypasses automated creation-based anomaly detection while using the reputation of hijacked developer profiles to look authentic.

Campaign Mechanics and Re-Aiming Infrastructure

The FakeGit operational model relies on simple social engineering lures embedded directly within repository documentation. In a sample analyzed by Apiiro, 97% of the commits modified only the repository’s README.md file, and 88% directed a prominent “Download” button to a ZIP archive containing the SmartLoader payload.

This modular structure allows the threat actor to pivot payloads or external download locations in minutes without altering the surrounding repository context. The campaign was first dubbed “FakeGit” in July by researchers at enterprise browser platform Island, who documented 7,600 fraudulent repositories distributing SmartLoader. That earlier cluster notably included roughly 800 repositories masquerading as Model Context Protocol (MCP) servers and AI skills designed to appear in public AI registries and developer catalogs.

While earlier waves focused on delivering various malware strains dating back to January, recent October activity has concentrated heavily on deploying SmartLoader to subsequently drop the StealC infostealer onto target endpoints.

Why Defenses and Takedowns Struggle to Scale

Security teams and platforms face severe operational hurdles when attempting to neutralize the FakeGit campaign. Takedowns relying on static domain blocklists or file-based signatures consistently fail due to the following factors:

• Pervasive Mirroring: Malicious ZIP archives are distributed across multiple GitHub storage features, including repository forks, older commit histories, release assets, issue attachments, and dedicated payload-hosting repositories. If a hosting link is taken down, the threat actor simply updates the README button to point to a backup copy elsewhere on GitHub.
• Incomplete Threat Intelligence Coverage: Prior to Apiiro’s report, 71% of the infrastructure utilized by the fleet was entirely missing from public blocklists like URLhaus.
• Inability to Apply Domain-Level Blocks: Enterprise network perimeter controls cannot apply domain-level DNS or URL blocks against single malicious assets on github.com without inadvertently shutting down access to legitimate software development operations nationwide.

Because defenders must take down individual links manually while the attacker can update thousands of pointers programmatically within seconds, traditional takedown mechanisms fail to suppress the fleet.

Blast Radius for Enterprise and AI Supply Chains

The underlying technique behind FakeGit represents a widespread supply-chain and social engineering threat vector targeting technical users, automated build pipelines, and emerging AI workflows.

When a developer or system administrator falls for a FakeGit lure—whether seeking a developer utility, a code library, or an AI skill module—executing the downloaded ZIP runs SmartLoader in the context of the user’s local workstation. Once dropped, infostealers like StealC scan the system for sensitive data, harvesting:

• Local browser credentials, session cookies, and saved credit card details.
• Cloud provider API keys, AWS/GCP access tokens, and SSH private keys.
• Stored Git tokens, personal access tokens (PATs), and active session cookies for enterprise repositories.

The blast radius extends beyond a single compromised endpoint. Stolen developer tokens permit threat actors to move laterally into corporate source code management (SCM) platforms, push backdoor code into continuous integration (CI/CD) pipelines, and compromise internal production environments. Furthermore, as developers increasingly integrate Model Context Protocol (MCP) servers and autonomous AI tools into their local workflows, ingesting unverified GitHub repositories exposes AI agents to arbitrary code execution within corporate network perimeters.

Recommended Mitigation and Incident Response

Organizations should enforce strict verification requirements across all software procurement and developer activities to mitigate FakeGit lures:

• Enforce Strict Origin Verification: Require developers to download code, utilities, AI skills, and MCP servers exclusively from official vendor repositories or verified, signed package registries. Explicitly instruct engineering teams to verify repository owner identities before executing release assets or following setup scripts in repository README files.
• Treat SmartLoader Execution as Account Compromise: If SmartLoader or StealC execution is detected on a workstation, isolate the endpoint immediately and treat the event as a complete credential and platform compromise.
• Revoke Active GitHub Sessions and Tokens: Immediately invalidate all active user sessions, OAuth application authorizations, SSH keys, and Personal Access Tokens (PATs) associated with any compromised developer profile.
• Transition to Hardware-Bound Passkeys: Enforce FIDO2/WebAuthn hardware passkeys for all internal developer platforms and GitHub accounts. Passwordless hardware authentication prevents threat actors from reusing session tokens or intercepted multi-factor authentication (MFA) prompts harvested by infostealers.