In January 2024, a single threat actor infected more than 1,300 victims in under four days by cloning a popular GitHub project and swapping in a malicious payload. Check Point Research (CPR) tracked the operator behind it — nicknamed "Stargazer Goblin" — running a network of over 3,000 fake GitHub accounts and 2,200-plus malicious repositories, a service CPR estimated generated roughly $8,000 a month and around $100,000 total by mid-2024. This is not npm or PyPI typosquatting, where a misspelled package name tricks a build tool. It's GitHub itself being used as the delivery surface: cloned READMEs, spoofed star counts, fake "exploit PoCs," and cracked-tool repackaging, all designed to survive just long enough for a human to click "Code" or download a release asset. Distinct campaigns since have distributed Atlantida Stealer, RisePro, Lumma Stealer, RedLine, and Rhadamanthys, and a February 2024 Apiiro report described more than 100,000 malicious repos created through automated forking and typosquatting at scale, not from one actor but a mass campaign pattern. This post walks through how these networks operate, three verified campaigns worth knowing by name, and the concrete heuristics developers and security teams can check before ever running git clone.
What is the Stargazers Ghost Network, and how did it evade takedowns?
The Stargazers Ghost Network, documented by Check Point Research in 2024, is a Distribution-as-a-Service operation built around a three-account split designed so that removing one account doesn't kill the campaign. One set of accounts hosts a phishing repository with a link to the payload; a second set stars and forks that repo to fake legitimacy and manipulate GitHub's trending signals; a third distributes the actual malware, often as a password-protected archive attached to a GitHub Release. CPR attributed the operator "Stargazer Goblin" to over 3,000 accounts and 2,200+ repositories feeding malware including Atlantida Stealer, RisePro, Lumma Stealer, RedLine, and Rhadamanthys. Because each account plays a narrow role, GitHub's abuse-detection systems banning the payload-hosting account leaves the starring/forking accounts and the phishing-repo accounts untouched, and the operator simply respins the missing piece. This modularity is why the network survived multiple takedown waves rather than collapsing after the first report.
Why did a network with hundreds of packages pivot from PyPI to GitHub?
Banana Squad, a threat cluster tracked by ReversingLabs, illustrates the pivot directly: it started with several hundred malicious PyPI packages that together drew roughly 75,000 downloads before pivoting to 67 trojanized GitHub repositories mimicking popular Python-based hacking tools, using identical names and file structures to the originals. The likely reason is economics of detection: registry security teams and automated scanners increasingly flag suspicious PyPI uploads on publish, while GitHub repo creation is functionally unlimited and unmoderated at upload time — a repo only gets reviewed if someone reports it. Cloning a well-known offensive-security tool's exact filename layout also means the malicious version shows up in the same search results and "awesome list" links as the real one, borrowing credibility the attacker didn't earn. The shift shows typosquatting isn't tied to one ecosystem; it follows wherever verification friction is lowest.
How are AI-generated fake exploit repos targeting security researchers?
Kaspersky's Securelist team reported in September 2025 on a campaign it called WebRAT: 15 GitHub repositories, which Kaspersky assessed as apparently AI-generated, posing as proof-of-concept exploits for known CVEs and specifically targeting junior security researchers and students searching for PoC code to learn from or reuse in coursework and CTFs. Separately, Trend Micro documented 2025 campaigns using AI-assisted fake repositories to distribute SmartLoader and Lumma Stealer. The targeting logic is deliberate: junior researchers are more likely to run unfamiliar PoC code directly, less likely to sandbox it first, and less likely to notice a README that reads slightly off because it was templated by an LLM rather than written by the tool's actual author. As PoC-search behavior increasingly starts with a GitHub search rather than a vetted feed, fake-exploit repos become a lower-effort initial-access vector than convincing someone to install a fake package via a build tool.
Can typosquatting reach GitHub Actions and CI pipelines directly?
Yes — and a 2025 case shows why the technique is dangerous even when it turns out not to be a criminal campaign. In October 2025, Veracode researchers found the npm package @acitons/artifact — a single-transposition typosquat of the official @actions/artifact package, which has 200,000-plus downloads and is used inside GitHub Actions workflows — configured to exfiltrate CI build tokens and use them to publish further malicious artifacts. It accumulated roughly 47,000 downloads before GitHub confirmed the package was actually part of a tightly controlled Red Team exercise it was running against its own infrastructure, not an external attacker's campaign. That confirmation doesn't make the underlying risk hypothetical: the mechanics Veracode documented — a typosquat landing mid-pipeline with elevated permissions and access to repository secrets — are exactly what a real attacker would need to poison every downstream build a compromised workflow produces, whether the token exfiltration is a red-team drill or the real thing.
What are the concrete signals a repo is cloned or malicious?
No single signal proves malice, but several together are a strong tell. Star and fork velocity anomalies — hundreds of stars appearing in hours from accounts created the same week — indicate bulk-created accounts rather than organic adoption, which is exactly the pattern CPR documented in the Stargazers network. Account-age-to-repo-age mismatch matters too: a brand-new account publishing a "mature" tool with a multi-year commit history graph should raise questions, as should the opposite — a repo with sparse, single-author commit history claiming to be a widely-maintained project. Check for a plagiarized README lifted verbatim from the real project (searchable phrase fragments are a fast check), release assets shipped as password-protected ZIP or RAR archives — a technique that specifically evades antivirus and GitHub's own malware scanning, since neither can inspect an encrypted archive's contents — and install or build scripts containing obfuscated code or base64-encoded blobs where a legitimate build step should be plain shell or Python. Also check the org or username itself for confusables: a hyphen swapped for an underscore, a lowercase "l" swapped for a capital "I," or a single added/dropped character from the canonical maintainer name. Finally, absence of verified (signed) commits and a license file that doesn't match the project's claimed identity are both cheap checks worth making standard practice before trusting a clone or fork.
How should developers verify a repo before cloning or running it?
Treat repository trust the same way you'd treat a package trust decision: verify the maintainer identity, not just the project name. Cross-reference the repo's URL against the official project's own documentation or website rather than trusting a search-engine result or a link shared in a forum or Discord, since attackers optimize exactly for those discovery paths. Diff a suspicious clone's README and file tree against the known-good upstream repo when the two claim to be the same project — legitimate forks diverge over time, while a same-day clone rarely does. Never run unaudited setup scripts, especially ones that shell out to decode a base64 blob or fetch a second-stage payload from an external host, and never extract a password-protected archive whose password is supplied only inside the repo's own README, since that's precisely the mechanism CPR documented Stargazers using to bypass GitHub's automated scanning. For any repo claiming to be a CVE PoC, cross-check the CVE identifier against the National Vulnerability Database and treat mismatched or vague technical detail as a red flag consistent with the WebRAT pattern Kaspersky documented. These checks take minutes; a stealer infection costs considerably more.
Repo-cloning campaigns work because they exploit a trust shortcut every developer relies on daily — that a repo with a familiar name, a healthy star count, and a polished README is what it claims to be. That shortcut is exactly what Stargazer Goblin, Banana Squad, and the WebRAT operators built their infrastructure to abuse. Verifying maintainer identity, commit signing, and release-asset integrity before running unfamiliar code isn't a niche precaution anymore — it's the same supply-chain discipline teams already apply to dependencies, extended to the platform those dependencies are hosted on.