The user thought they were downloading OpenClaw.
The malware ran before they ever reached the product.
That is why this story matters.
The sharpest lesson from the fake OpenClaw installer wave is not that attackers used malware. That part was ordinary. The revealing part is where they positioned it: inside the path people used to figure out what counted as official.
By early March 2026, the reporting chain had settled into focus. Huntress published the primary investigation on March 4, 2026. Malwarebytes, TechRadar, and The Register then clarified the same pattern for a wider audience: malicious GitHub repositories posing as OpenClaw installers were live between February 2 and February 10, 2026; one victim Huntress investigated had searched “OpenClaw Windows” in Bing; Bing’s AI answer linked directly to a fake GitHub repository; and the installer delivered infostealers plus, in some cases, GhostSocks proxy malware instead of the product.
That sequence sounds like a malware story. It is one. But it is also more specific than that. The interesting failure did not begin in OpenClaw’s runtime, package manager, or source tree. It began earlier, where a user decides which search result, which repo, which installer, and which setup instruction deserves to be treated as normal.
The counterfeit path looked close enough to feel official
OpenClaw’s official install page is narrow about where users are supposed to start. It points readers to the documented install flow through openclaw.ai/install.sh or openclaw.ai/install.ps1, and it links back to the official openclaw/openclaw GitHub repository. It also warns against third-party one-click images in favor of installing from a clean base image and the official installer script.
That matters because the fake-installer wave occupied almost the same mental space without actually sharing the same trust chain.
Huntress says the malicious repo presented itself as openclaw-installer under a matching GitHub organization name. At a glance, that structure did the first half of the scam’s work. A user did not need to see a perfect copy of the official product. They only needed to see a repo name, an organization name, and a platform they already trusted for legitimate OpenClaw activity.
The rest of the trick was even more cynical. Huntress found that the visible source was largely copied from Cloudflare’s moltworker project and that the real malware sat in the releases section inside a 7-Zip archive as OpenClaw_x64.exe. The repo did not need to be a real OpenClaw project. It only needed to survive a hurried glance, a ranking pass, and maybe an AI summary.
That is a different kind of counterfeit operation. The target was not only the user. It was the discovery machinery around the user.
GitHub identity did the first trust work
One reason this story stuck is that the attackers did not rely on a sketchy file host or a blatant typo domain. They borrowed legitimacy from GitHub itself.
Huntress reports that the account behind the fake installer joined GitHub in September 2025, stayed largely inactive, then surfaced on January 30, 2026 by opening issues on the official OpenClaw repository to promote another repo under the organization molt-bot. Those issues were closed as spam. The same account linked to a nonexistent X profile in its bio and used someone else’s photo to look more established.
None of that proves some grand influence campaign. It does show patient counterfeit identity work. The repo name, the organization shell, the copied code, the release artifact, and the public issue spam were all doing the same job: making a fake installer look native to the ecosystem instead of obviously adjacent to it.
That is why the GitHub angle matters so much. People do not treat GitHub as just another random website. In fast-moving open source projects, GitHub is often where legitimacy first becomes visible. Users expect forks, experiments, helper repos, release mirrors, and tooling wrappers to live there. Attackers were not breaking that expectation. They were hiding inside it.
Bing removed the last hesitation
The Bing piece needs careful boundaries.
The documented fact is narrow: Huntress says the infected user searched “OpenClaw Windows” in Bing and clicked an AI-generated suggestion that linked directly to the malicious GitHub repo. The public reporting does not show intent or cooperation from Microsoft, and this page is not making that claim. The attack surface here was recommendation and ranking, not motive.
Even with that boundary, the Bing detail changes the meaning of the whole episode.
GitHub can make a fake repo look plausible. A search engine or AI answer can make it feel selected.
That last step matters because the typical install moment is not a formal verification exercise. It is a momentum exercise. A user searches, sees a result that looks compatible with the product’s existing GitHub-centered identity, notices that the answer appears to have already done some filtering for them, and keeps moving. Bing did not need to invent the fake installer. It only had to remove one last reason to hesitate.
The Register captured that dynamic cleanly: GitHub trust plus Bing AI ranking made the fake installer unusually believable. That is the non-interchangeable part of this story. A cloned repo on its own is one kind of scam. A cloned repo recommended through a mainstream discovery surface is a different class of distribution event.
The malware handoff raised the stakes, but the real story stayed upstream
The Windows payload chain was serious on its own terms. Huntress says the fake executable deployed multiple Rust loaders designed to run infostealers in memory, including Vidar, while Malwarebytes and TechRadar highlighted cases where GhostSocks also landed on the victim machine. Huntress describes GhostSocks as a way for threat actors to route traffic through the victim’s own system so anti-fraud and MFA checks are less likely to flag the activity as foreign.
That is ugly enough without any OpenClaw-specific framing.
The story becomes more important when you remember who the victims were trying to become. They were not random curiosity-clickers downloading a novelty wallpaper app. They were users on their way to installing an agent platform that many secondary reports correctly described as broad in local authority and rich in connected secrets. Malwarebytes makes that point directly: if users wire OpenClaw into their digital life, the machine can end up holding access to sensitive data and services.
In other words, the fake installer was not only stealing from an endpoint. It was intercepting a user at the exact moment that user was preparing to grant a lot of future trust to software.
That makes the GhostSocks and infostealer chain feel less like a separate technical appendix and more like the consequence layer of the discovery failure. The counterfeit repo got the user in the door. The payloads monetized what that trust posture was about to make available.
The macOS branch showed this was not one sloppy Windows-only fake
Huntress also found a separate macOS branch. The fake repo’s install method for macOS pointed to another newly created GitHub organization, puppeteerrr, and a repo named dmg, where a bash one-liner downloaded and ran a binary Huntress says strongly resembled Atomic macOS Stealer (AMOS) behavior.
That matters for narrative shape even if Windows got more of the headline attention.
This was not a single poisoned .exe accidentally surfacing in one search result. It was a broader counterfeit installer operation spanning discovery surfaces, GitHub shells, release artifacts, and platform-specific delivery. Huntress even documented additional lookalike organizations, including an install-openclaw clone that appeared a day after the original account and repo were removed.
Once the pattern starts regenerating that quickly, the incident stops looking like one bad download. It starts looking like an attack on the category of “how people find and install the thing.”
What is documented, and what this page is inferring
The documented layer is strong enough to hold the core story:
- Huntress published the primary investigation on March 4, 2026 after analyzing an infection tied to a fake OpenClaw installer surfaced through Bing.
- The fake GitHub installer infrastructure was live between February 2 and February 10, 2026.
- The malicious repo used GitHub organization and repository naming that looked close to an official installer surface.
- The visible source code was largely unrelated legitimate code, while the malware lived in the release artifact.
- The Windows chain included in-memory infostealer delivery and sometimes GhostSocks.
- The macOS path led to a separate GitHub-hosted one-liner and an AMOS-like binary.
- OpenClaw’s official install docs define a legitimate path through
openclaw.aiscripts and the officialopenclaw/openclawrepo.
The bounded editorial inference is narrower than “the internet is unsafe” and narrower than “Bing caused malware.”
It is this: in fast-moving open-source ecosystems, discovery surfaces such as search results, AI answers, and repo identity can become the first meaningful security boundary long before product trust engineering is mature enough to contain impersonation at the edge.
One more boundary matters here too. I did not find primary reporting tying Lumma Stealer specifically to this OpenClaw/Bing fake-installer case. The source chain for this incident supports Vidar on Windows, GhostSocks in some Windows infections, and an AMOS-like path on macOS. This page stays with that reporting rather than blending adjacent fake-installer malware stories together.
The consequence landed before the install completed
That is the line worth keeping from this episode.
The first exploit was not inside OpenClaw’s codebase. It was inside the route users took to arrive there.
Counterfeit legitimacy outran product trust engineering. GitHub identity made the fake installer feel native. Bing’s AI answer made it feel pre-vetted. The malware chain then converted that borrowed trust into theft and proxy access before many users ever touched the official path.
For security-aware operators, that is the durable judgment.
When a tool goes mainstream fast, the first exploit often is not a runtime bug, a dependency compromise, or a zero-day in the product itself. It is the moment search, repo identity, and install momentum start deciding what feels official before the official product has fully earned control over those surfaces.
That is why this case should be remembered as more than a malware bulletin.
It was a discovery-path compromise, and for a brief stretch in February 2026, discovery was the real installer.