Executive Summary

Installing new software has never been easier. An AI coding agent can search for a tool, evaluate a project, read its documentation, install it, and wire it into an application in one workflow.  That convenience raises the stakes on repository credibility. Attackers don't need to compromise an AI system. They only need to build software that looks legitimate enough for one to recommend.

In September 2026, we investigated a MicrosoftSystem64 linked supply chain campaign spanning at least 88 public GitHub repositories. The campaign delivered a cross-platform RAT through malicious npm dependency chains.

What made these repositories effective wasn't a new technique on its own, but rather the infrastructure built around those repositories. Attackers preserved real functionality, gave malicious dependencies plausible application uses, imported or fabricated development histories, and automated fork activity to make projects appear established and widely adopted.

In our testing, one campaign-linked repository surfaced unprompted in both ChatGPT and Google AI Overview during ordinary software discovery. This showed that these manufactured trust signals are exactly what AI-assisted discovery uses to decide what's worth recommending.

A different path into AI assisted discovery

In our earlier AgentBaiting research, we showed how AI assistants could discover malicious GitHub repositories, read attacker written instructions in their READMEs, and direct users toward malicious downloads.

The campaign we investigated here used a different path. The repositories could contain real, working software, while malicious code was introduced through their dependency chains. A developer or an AI coding agent could therefore install what looked like ordinary software without the malicious functionality being obvious from the application itself.

We took one of the repositories we had already linked to the malicious cluster: Cesarjoquin/shopify-mcp, an unaffiliated third party MCP server presented as an integration for Shopify, one of the world’s largest ecommerce platforms. We wanted to see whether it could surface during ordinary AI assisted software discovery. For ChatGPT, we opened a new incognito session without logging in, and started a fresh chat (GPT-5.6 Luna with High thinking). We did not mention the repository, the campaign, or provide any threat context. We simply asked: “I need an MCP package for Claude that can help manage a Shopify store. What are the best current options?” Cesarjoquin/shopify-mcp appeared among the top recommended options.

We repeated the experiment with Google in Incognito mode with Search customization turned off, searching: “shopify mcp server for Claude Desktop github”. Again, Cesarjoquin/shopify-mcp surfaced in the results.

The result raised a more interesting question than whether an AI system could surface a malicious repository: what made this repository look like a reasonable piece of software to recommend in the first place?

On the surface, Cesarjoquin/shopify-mcp looked like what someone searching for a Shopify MCP server would expect to find: detailed documentation and real working Shopify functionality. But one of its dependencies was ioredis-xyz, a Redis themed npm package in the MicrosoftSystem64 delivery chain. During our monitoring, that dependency changed to oscar-redis and later to oracle-redis. The carrier names rotated while the repository, documentation, and application functionality remained in place.

As we followed the campaign, we found more repositories positioned around AI and agent workflows, along with copied and repurposed projects, imported or generated development histories, automated fork networks that created the appearance of adoption, and malicious dependencies placed beside real application functionality that gave them an apparent reason to exist.

That shifted the investigation from the malicious packages themselves to the infrastructure built around the repositories.

From a malicious npm package to a much larger operation

MicrosoftSystem64 is capable of command execution, file access, persistence, and additional payload deployment. Earlier waves of the campaign, including malicious logging-themed npm packages, were documented by OX Security and JFrog. The name MicrosoftSystem64 comes from the persistence identity used by the malware across Windows, macOS, and Linux and is unrelated to Microsoft Corporation.

SafeDep later documented a newer delivery chain involving ioredis-xyz, a typosquat of the legitimate ioredis Redis client package. Their analysis showed how the chain used transitive dependencies and delayed activation, allowing a later SemVer compatible update to introduce the malicious payload without any further change to the originating repository. SafeDep traced this activity across 28 attacker-created GitHub repositories.

From there, we followed the campaign as its dependency infrastructure evolved across manifests, lockfiles, commit history, and repository relationships. As the top level dependency moved from ioredis-xyz to oscar-redis and later oracle-redis, the footprint expanded. As of September 20, 2026, we identified at least 88 public repositories connected to the campaign.

To understand why software tied to this campaign could look worth recommending, we looked at the signals surrounding the repositories themselves.

Real software, manufactured legitimacy

These were not empty repositories built around a malicious dependency. In multiple cases, attackers copied existing open source projects, preserved their functionality, and modified the copies in ways that gave the malicious dependency a plausible reason to exist.

Shopify MCP is a clear example. Before the added redis modifications, Cesarjoquin/shopify-mcp followed the GeLi2001/shopify-mcp lineage and contained no Redis dependency.

Then the attacker added a Redis connection manager and token cache implementation and wired that cache directly into Shopify's OAuth flow. Redis now had an understandable purpose: persisting Shopify access tokens. That placed ioredis-xyz directly on the code path responsible for storing and restoring those tokens.

We saw the same pattern across other campaign linked repositories. A reviewer or an LLM checking whether a suspicious dependency was actually used would find that it was, embedded in working application logic with an apparently legitimate purpose. Many repositories also contained ordinary project infrastructure such as tests, builds, and validation workflows.

Manufacturing developer credibility

A developer evaluating an unfamiliar repository might next look at the account behind it.

At first glance, the GitHub profile behind Cesarjoquin/shopify-mcp looked established. The account dated back to April 2022, showed hundreds of contributions, and owned repositories with hundreds or thousands of forks.

The repository timeline told a different story: all 25 public repositories were created between June 24 and June 26, 2026.

Many nevertheless appeared to contain years of development history. We found matching upstream projects whose histories had been imported, while commit authorship was often rewritten under the Cesarjoquin identity.

Cesarjoquin/nix-config, for example, was created on June 24, 2026 but contained an init commit dated September 1, 2021 and attributed to Cesarjoquin. The matching upstream commit in mikeyobrien/nix-config had the same timestamp, message, and underlying file tree, but retained the original author.

Manufacturing a development narrative

Imported history was not the only way to create the appearance of maturity. Some repositories generated development history directly.

In hotbridgeLab/future-trading-ai-agent, one campaign repository, we found a bootstrap-commits.sh script that programmatically generated roughly 57 staged Git commits.

We observed similar synthetic histories elsewhere. In Stormeye85/robinhood-token-launcher, ten apparent development milestones were committed within just eleven seconds. We did not recover the same generation script there, so we cannot say the mechanism was identical, but the result was similar: development history itself became another credibility signal that could be constructed rather than earned.

Manufacturing popularity

A convincing history can make a repository look mature. Forks and stars can make it look adopted.

Across the 88 campaign linked repositories still publicly available on GitHub, we observed 9,881 stars and 65,681 forks. Roughly 6.6 forks for every star. 

That ratio alone does not prove manipulation, so we followed the forks. Across seven campaign-linked AI and MCP repositories, 664 of 673 consecutive fork intervals fell between 179 and 182 seconds. New forks were appearing almost exactly every three minutes.

The ownership pattern was just as unusual. In Cesarjoquin/Marketing-Skills, 1,231 of 1,238 fork objects returned by GitHub were owned by just 22 organization accounts. Twenty one organizations held exactly 56 forks each, while one held 55.

The timing matched that structure. Forks appeared globally about every three minutes, while new forks within the same organization appeared roughly every 66 minutes. With 22 organizations in the network, that pattern is consistent with a simple round robin process rotating through one organization at a time.

The infrastructure continued creating forks after campaign dependencies had been introduced, preserving poisoned repository states in new copies. It also helped us connect additional repositories to the campaign.

Rotating the payload without rebuilding the lure

Once a repository had accumulated convincing history, documentation, and popularity signals, the surrounding infrastructure did not need to be rebuilt when a package name changed. The dependency could be replaced while the repository remained in place.

In dabberman456/coinbase-trading-api, the same dependency slot rotated from ioredis-om to ioredis-xyz, then oscar-redis, and finally oracle-redis, while the repository and its installation mechanism remained in place.

The repository was the durable distribution asset. The package name was disposable.

For defenders, a package name IOC can become stale quickly. Blocking or hunting for one known carrier may stop that package, while repositories that have moved to the next name will no longer match.

When discovery becomes execution

None of these techniques is new on its own. What stands out is the combination, and how it intersects with AI-assisted software discovery. The distance between “find me a tool” and “install it” can now be only a few prompts. That makes repository credibility more consequential. Convincing documentation, apparent development history, visible adoption, and working functionality can make a project look established before anyone inspects the dependency that will actually execute.

We cannot say which individual signal caused Cesarjoquin/shopify-mcp to surface, or whether the campaign was designed specifically to influence LLM recommendations. What we can show is that the repository had accumulated the same kinds of signals that make software look established and widely adopted and that it surfaced during ordinary AI assisted software discovery.

The attacker did not need to compromise the AI. It needed to build software the AI could reasonably recommend.

‍IOCs:

‍

‍