A field report on tracking coordinated inauthentic behavior through commit signatures, backdated git history, and an automation tool that left its process ID embedded in three README files.
This is Part 3 of an ongoing investigation. Part 1 documented the initial discovery — 8 accounts with Jaccard following-list similarity of 0.99+ across ~29,800 entries each, evading cross-follow detection entirely. Part 2 expanded the cluster to 9 accounts and attributed the generation pipeline to a specific GitHub identity: hajigur69.
This part covers an earlier operation by the same operator, running nine months before the follow botnet was provisioned. The hajigur69 co-author fingerprint is present in both. So is the fallback_ generator artifact. The infrastructure was already running.
It started with a string.
66867581+hajigur69
That number-plus-username combination kept appearing in Co-authored-by commit trailers across thousands of commits from dozens of different GitHub accounts. Not as an author. Not as a committer. Embedded in the trailer block, like a watermark — or a coordination mechanism the operator never rotated.
That string became the fingerprint for an entire network.
What I Was Looking At
The network — I'm calling it HAJINET — operates across six distinct layers:
-
Commit farming: Coordinated accounts mass-generate commits embedding the
hajigur69co-author signature to inflate contribution graphs - Repo spam: 400+ procedurally generated repositories with LLM-written READMEs targeting crypto/Web3 search terms
- Fake engagement: Purchased stars from a third-party service to boost GitHub and Google search ranking
- Follow spam: Mass-following (30,000+ on the primary account) to appear legitimate
-
SEO poisoning: Cloning the names of famous repos like
system-design-primeranddeveloper-roadmap - GitHub as persistence backend: Using a repository's commit history as a synthetic activity signal and data persistence mechanism — with fabricated timestamps going back seven months before the account existed
By the time I was done, I had 24 accounts, 33 confirmed star-service bot accounts, a root commit SHA proving a 213-day timeline impossibility, and three README files containing an automation tool's process ID that it forgot to strip before pushing.
Here's how I found it.
The 24 accounts: the 9-account follow botnet cluster (canestein, hazexone, domcomit, kylehyne, jaderytm, vierystein, hanyvert, mariwatts, lynewinter) plus Lyne6666, uhsr, mohammadtzs, and 12 additional commit-farming accounts identified via the hajigur69 co-author signature. Four of the botnet cluster accounts — canestein, hazexone, domcomit, and kylehyne — appear in both this operation and the follow botnet documented in Parts 1 and 2. They are the same operator's assets across both deployments.
The Commit Fingerprint
When the 66867581+hajigur69 string first appeared in search results, the volume was the tell. GitHub's commit search API showed it across thousands of commits from a cluster of 22 accounts — canestein, hazexone, domcomit, kylehyne, and 18 others — all generating commits in a tight July–August 2025 window:
2025-07-08..2025-07-14 : 1,738 hits
2025-07-15..2025-07-21 : 701 hits
2025-07-22..2025-07-31 : 949 hits
2025-08-01..2025-08-15 : 7,194 hits ← peak
2025-08-16..2025-08-31 : 0 hits ← hard stop
The August 16 cliff edge is significant. That's not a developer going on vacation. That's consistent with an account action or a deliberate operator pivot.
The hajigur69 account's GitHub ID is 66867581. That numeric ID embedded alongside the username in the co-author string is what made it searchable. Whoever set up the automation configured it once and never rotated the signature.
The Satellite Account
Following the commit graph led to Lyne6666, an account created May 3, 2025 with 163 public repositories — all created on July 9, 2025 at 18:55 UTC. Multiple commits in the same minute. I pulled the LICENSE SHA from a sample:
8aa26455d23acf904be3ed9dfb3a3efe3e49245a
Same SHA across all 163 repos. That's not a coincidence — it's a file copy from a template directory that never changed. Git hashes content, not filenames. Identical SHA means identical bytes, which means the same LICENSE was stamped into every repo from a single source.
The repo names followed a template: {Tech}{Testnet}{Function}{Suffix}. TPUTestnetSystemSolutionsNext. DAOTestnetAIKitPro. IoTTestnetPlatformLabsX. Every README had this in the install section:
pip install git+https://github.com/Lyne6666/{RepoName}.git
163 repos. 163 pip install vectors. No postinstall hooks confirmed yet, but the infrastructure is there.
The Primary Operator
The Lyne6666 repos had an email in the commit headers: uhsr@eteb.me. That's a private burner domain — one user, WHOIS privacy-shielded via Identity Digital. The account it led to, uhsr, was created July 10, 2025 — one day after Lyne6666's mass repo creation.
At the time of investigation: 237 public repos, 2,972 followers, 30,778 following.
That following-to-follower ratio — 10.4:1 — is a follow-spam pattern. Mass-follow enough accounts and some percentage follow back, which makes the account look organically connected to a real community.
uhsr's commit volume shows the operation's activity profile in four numbers:
July 2025: 1,382 commits (71% of all-time activity)
August 2025: 247 commits
September 2025: 21 commits
October 2025: 96 commits
71% of an account's entire commit history in a single month. That's not a developer. That's a deployment window.
The Impossible Timeline
uhsr/AssetMarket was the most interesting repository. It contained a .Logs file with ~365 entries running from January 1, 2025 through December 31, 2025. Daily entries, format: Logs: YYYY-MM-DD <8charToken>.
The repo was created August 2, 2025.
curl -s "https://api.github.com/repos/uhsr/AssetMarket" | python3 -c "
import json,sys; r=json.load(sys.stdin)
print(r['created_at'])
"
# 2025-08-02T16:29:22Z
So I pulled the commit history and paginated back to the earliest entries. The root commit:
SHA: 4f8f47697eb89c8818820ca92348be01c4544878
Message: Logs on 2025-01-01
Author date: 2025-01-01T14:47:47Z
Committer date: 2025-01-01T14:47:47Z
Author email: uhsr@eteb.me
Repo created: 2025-08-02T16:29:22Z
A commit dated January 1 in a repo that didn't exist until August 2. That's 213 days of fabricated git history.
The technique is worth noting: both GIT_AUTHOR_DATE and GIT_COMMITTER_DATE were overridden simultaneously. Naive backdating only sets the author date, leaving the committer date as the real push timestamp — a detectable mismatch. This operator knew that. They set both fields identically on every commit in the fabricated window. The .Logs file with its 8-character daily tokens appears synthetically generated rather than organically accumulated — consistent with a bulk scripted push using pre-generated identifiers, designed to make the contribution graph look like 7 months of continuous activity.
The repository is consistent with use as a synthetic activity signal and lightweight persistence backend, not legitimate version control.
The Tool That Left Its Name in the File
The high-value repositories — AssetMarket, SmartContract, DigitalWallet, TokenLab, BlockchainKit — all had longer, LLM-generated READMEs. While pulling the raw content of AssetMarket's README, I found this at the top:
<!-- fallback_AssetMarket_20250802163009_95172 -->
An HTML comment. Invisible on the rendered page. Accidentally left in by the generation script.
Breaking it down:
-
fallback— the secondary template fired because the primary LLM generation path failed -
AssetMarket— the repo name variable -
20250802163009— generation timestamp: August 2, 2025, 16:30:09 UTC -
95172— process ID from the generation script
I searched the rest of uhsr's repos and found two more:
uhsr/SmartContract → <!-- fallback_SmartContract_20250802162757_83653 -->
uhsr/TokenLab → <!-- fallback_TokenLab_20250802161931_80263 -->
Three repos, same machine, 38-minute window:
16:19:31 TokenLab PID 80263
16:27:57 SmartContract PID 83653
16:30:09 AssetMarket PID 95172
The PID gaps are irregular — consistent with a script iterating a repo list with API calls and sleep intervals between each generation run, with OS background processes accounting for the PID jumps. The fallback label on all three means the primary LLM path failed or timed out on all three in sequence, and the static fallback template was substituted. That's why every feature bullet in all three READMEs contains the identical filler string:
"Advanced implementation with optimized performance and comprehensive error handling"
That's the placeholder text for a template field that had no content. The script pushed it anyway.
The Star Service
The high-star repos had suspiciously uniform engagement. AssetMarket had 83 stars. SmartContract had 50. DigitalWallet had 49. Zero forks across all of them except one, which led to mohammadtzs — more on that shortly.
I pulled the stargazer lists and cross-referenced:
AssetMarket ∩ DigitalWallet ∩ SmartContract = 33 accounts
33 accounts starred all three repos. That's 67% of DigitalWallet's total star count. Organic discovery doesn't produce that overlap. This overlap pattern is consistent with a shared purchased-engagement pool being reused across repos.
The July 11 batch — 83 repos created in a single day — showed the purchase tier structure directly:
★2: 64 repos (77%)
★1: 19 repos (23%)
★0: 0 repos
Zero repos with zero stars. Every single one got at least one. The distribution has no organic variance. It reads like a bulk order: "2 stars each, downgrade 19 to 1."
The August 2 high-value repos got proportionally more investment: AssetMarket at 83, SmartContract at 50, BlockchainKit at 36. The star spend correlates exactly with the repos that have pip install vectors in their READMEs — the ones most likely to get actually installed by a developer who finds them in search results.
The cross-network link: Two accounts from the 33 — SAPH1TE and ahnshy — also appear in the stargazer lists for Lyne6666 repos. The uhsr cluster and the Lyne6666 cluster were deliberately siloed (no social graph overlap, different account creation dates, different repo naming patterns). But they used the same star purchase service. That vendor relationship is the infrastructure bridge between the two otherwise separate network segments.
mohammadtzs
The one fork of DigitalWallet came from mohammadtzs, whose bio reads "Ex-gamer turned full-time Web3 airdrop hunter." Created March 2025, 506 public repos, 100 forks — all from accounts that no longer exist (deleted or banned). The fork names included alork1, alork2, alork3, alorki1 — the cluster's {name}{number} account generation pattern.
And mohammadtzs appeared in the 33-account star service pool.
Not a victim who stumbled onto a fake repo. A participant in the same engagement ecosystem, likely forking cluster repos to build social graph signals for airdrop qualification while the cluster provides the fake stars that make the airdrop worthwhile.
The October Pivot
When the August ban wave hit, the activity dropped to near zero in September. October brought 96 commits — almost entirely from a single scripted run on October 20, 2025, between 05:04 and 05:19 UTC:
awesomepythonTech → impersonates vinta/awesome-python
freeprogrammingbooksHub → impersonates EbookFoundation/free-programming-books
publicapisAI → impersonates public-apis/public-apis
codinginterviewuniversityTools → impersonates jwasham/coding-interview-university
developerroadmapLab → impersonates kamranahmedse/developer-roadmap
systemdesignprimerCloud → impersonates donnemartin/system-design-primer
buildyourownxTools → impersonates codecrafters-io/build-your-own-x
Seven repos in 15 minutes, all named after repositories with 230,000–340,000 stars. None contain any actual content. The descriptions are raw template output — developerroadmapLab has "enterprise enterprise-grade" in its description, a doubled template token that made it through with no human review.
This is the operation's final documented phase: when the commit farming network got disrupted, the operator pivoted to pure SEO poisoning — trying to capture search traffic from developers looking for the real repositories.
What This Is
The full picture:
A scripted infrastructure generates accounts, populates them with LLM-written repositories targeting crypto and Web3 search terms, purchases stars to boost their GitHub search ranking, and mass-follows accounts to build a fake social graph. The high-value repos have pip install vectors ready. The primary operator's account carries 7 months of fabricated commit history to look established. And when the commit farming network gets disrupted, the operation pivots to SEO poisoning of the most-searched developer repositories on the platform.
The generator tool left its process ID in three README files. The star service reused the same 33 accounts across every repo. The co-author fingerprint never rotated. For a technically sophisticated operation, the operational security was consistently poor — but that's often how these get found.
Disclosure
This report has been submitted in full to GitHub Trust & Safety with API-verifiable evidence including the root backdated commit SHA (4f8f47697eb89c8818820ca92348be01c4544878), the generator artifact URLs, the 33-account star service fingerprint, and the complete account list.
All data was retrieved via the GitHub REST API v3 with authenticated requests. No accounts were accessed beyond their public API data. No systems were compromised.
The accounts canestein, hazexone, domcomit, and kylehyne documented here also appear in the follow botnet cluster identified in Parts 1 and 2. This report and those reports cover the same operator across two separate deployments.
If you recognize any of these accounts or have seen the hajigur69 co-author string in your own repos' commit histories, that's the network's fingerprint — and worth reporting.


























