top of page

Return of the ANUSFRAGGER: We Audited Our Own Takedown List, Got Two Wrong, and Found the Replacement Farm Hiding on GitHub Pages

Writer: Patrick Duggan
Patrick Duggan
6 hours ago
6 min read

In November 2025 we documented a GitHub supply-chain crew that used aged, dormant accounts to drop infostealers into issue trackers. We called it ANUSFRAGGER. In January, Zscaler named the same thing NodeCordRAT.


Today we went back and audited our own work: every account we named, checked against what GitHub actually decided. We got most of it right, we got two of them wrong, and in the course of checking we walked into the operation that replaced it.


This post is all three, in that order, because the part where we were wrong is what produced the detection method in the part where we were right.



What happened to the accounts we named


We named eleven accounts across that work. Months later, GitHub has adjudicated all of them independently of us. Eight are gone — suspended or deleted. Our reports held up against a reviewer we do not control and cannot lobby.


Three are still standing. That is the interesting part, and the three do not look alike.


Two are one-repo accounts with no display name and almost no followers, whose malware repositories are still live today. One of those was last updated the morning we wrote this. GitHub has not acted on either, which means our April report has two open items nobody chased, including a remote-access tool that is being actively developed right now.


The third is a person.



The two we got wrong


One account we named belonged to somebody whose GitHub was compromised and used without their authorization. They told us so, in a comment on the post, in August. They were polite, they described their evidence, and they said they had appealed to GitHub. We did not answer, because nobody was reading the pending-comment queue. Two months of silence from a shop whose entire credibility rests on correcting itself faster than anyone else.


Their account is still live. The other account in that same cluster is suspended. GitHub reviewed both and split them, which is the outcome you would expect if one was an operator and one was a victim.


Here is the uncomfortable part, and it is a methodology failure rather than a typo. Our evidence was that the account had been dormant for 104 days and then suddenly became active. We read that as proof of a premeditated sleeper. But "dormant, then abruptly active" is also the exact signature of an account that has just been stolen. From the outside, from issue-tracker activity alone, a purpose-built sleeper and a hijacked real account produce identical telemetry. We had a fact that was consistent with two stories and we published the one that names a person.


The second account we got wrong is a security student. Their repository came down — GitHub removed it, and we are not arguing with that. But their account survived review, and when you look at what else is on it you can see why: more than twenty original projects, offensive and defensive side by side. They had written an EDR and an EDR evasion technique. A malware classifier and malware. That is a learning portfolio. We are not naming them, because naming them is the mistake we are here to correct, and doing it twice in one week would be its own kind of answer.


Commenters told us both of these things at the time. We treated the whole thread as a brigade — and some of it was, eleven comments on one post in a single day, with handles like "Elon Musk" and "Donald Trump" — and we missed that two of the complaints were specific, checkable, and correct.



The filter we did not have


Both mistakes have the same shape: we could not cheaply tell a throwaway account from a real person. So we built the test we were missing, and it turns out to be almost free.


Look at stars against followers.


A real project with fifty-plus stars sits on an account somebody follows. The author has a history, a name, an audience. When we checked a well-known researcher whose tool appears in the same search results, the numbers were ordinary: twenty-nine repositories, one thousand seven hundred and fifty-two followers, eight stars on the tool in question.


Now look at what we found today:




Seventy stars and zero followers. Fifty-seven stars and zero followers. That does not happen. Nobody stars a repository from an account they have never heard of, in those numbers, without a single one of them clicking follow. The stars are bought or farmed, and the ratio gives it away in one API call.


This is the same instinct as everything else we publish: compare the thing against what you already hold, rather than buying a list of what to fear. Followers are free to check. So is repository count. So is whether the account has bothered to set a display name.



The farm that replaced it


Applying that filter to a single search for recently-updated stealer repositories surfaced four accounts immediately. Then the fingerprint got much better than a ratio.


Two of them present as completely unrelated projects. One is a forensics and reverse-engineering toolkit for a well-known infostealer. The other is a Roblox session-protection tool. Different audiences, different cover stories, no obvious connection.


They are the same files.


Both contain exactly four things: a README, an index page, and two SVG images with randomized hexadecimal filenames. No source code at all. And the file sizes line up — the two README files are within a hundred bytes of each other, the two index pages are close, and the two large SVGs are within twelve bytes. One pair differs by eight. These are not similar projects. They are the same template with the serial numbers filed off and a new story written on top.


The READMEs are generated security prose, the kind that reads fluently and says nothing: a "bundle" to acquire, "Network Signature Patterns" to derive, a "local-only sink server," a reassurance that none of this violates any laws.



Where the payload actually lives


Here is the part worth copying into your own detection, because it defeats the obvious checks.


The repository contains no malware. There is nothing to scan. The "Download" button in the README is one of those SVG images, and it links out to a GitHub Pages site on github.io belonging to the same account. So the delivery host is GitHub itself, which is trusted by every proxy, every filter and every person.


And the Pages site contains no malicious link either. We pulled it: twenty-five kilobytes of HTML with zero outbound URLs in the text. The destination is base64-encoded in the page and assembled by JavaScript at click time — atob, twice.


So: scan the repository, find a README. Scan the landing page for bad URLs, find none. The address only exists after a browser runs the script, in the moment someone clicks. Every static check passes and the victim still gets the file.


We did not decode and visit the destination. The chain is demonstrable without touching the end of it, and we would rather describe a mechanism than fetch somebody's payload to decorate a post.



And ANUSFRAGGER itself?


By our own data, it stopped existing on 6 March 2026. That is the date of our most recent indicator for it.


Which is almost certainly false. What actually happened is that the industry renamed it in January and we never adopted the alias. We had zero records under the name everyone else uses. Our corpus could not see activity reported under its current name, so a crew we discovered became invisible to us the moment somebody else named it. We fixed that today — searching the new name now returns our profile — but the alias only makes the file findable. It does not retrieve eight months of indicators we were not collecting.


That is the quiet version of the same error as the account attribution: a confident answer produced by an instrument that was not looking at the right thing.



What to do


If you run a security program that consumes GitHub as a source, add the ratio. Stars far exceeding followers, on an account with no display name and one repository, is a strong and nearly free signal. It will not catch everything and it will occasionally flag a genuine new project, which is why it is a flag and not a block.


If you are about to name a person in a report, ask what else that account has done. Twenty original repositories and a portfolio spanning both sides of the discipline is a student. One repository, no name, no followers and a stealer is not.


And if somebody comments on your work to say you got it wrong about them, read it. We did not, for two months, and they were right.


Call the whole thing 95% confident. Something here is wrong too, and the comment box is directly below.



Sources


  • GitHub REST API, account and repository status for every handle named in our own prior coverage, checked 2026-10-27. First-party.

  • Repository file listings and README contents retrieved via the GitHub API; the landing page retrieved over HTTPS and inspected as text. No payload was decoded or executed.

  • Our prior coverage: the November 2025 ANUSFRAGGER documentation and the April 2026 repository scoring post, both of which this post corrects in part.



Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.


Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page