The TRAE Extension Backdoor That Ran Its C2 on an Ethereum Contract

TL;DR

A malicious IDE extension named juannegro.solidity, disguised as the popular Solidity language plugin, is a cross-platform dropper that backdoors Windows, macOS, and Linux developer machines the moment the editor starts. Its standout trait, documented by SlowMist, is where it keeps its command-and-control address. It reads the backend from an Ethereum mainnet contract the attacker updates with ordinary transactions, so there is no fixed server for a defender to pull offline. It was published to the Open VSX registry on May 1, 2026 and pulled within hours, yet it was still downloadable from the TRAE IDE marketplace at version 0.0.189 as of July 18, 2026, because TRAE mirrors new Open VSX listings but not their removals. No loss figure has been published. An audit secures the contract you ship. Nothing here touches that contract: this attack owns the machine you ship it from, and it parks the command server on a chain nobody can take offline.

What Was the juannegro.solidity Extension?

It was a counterfeit of the most-installed Solidity tool in the ecosystem. The legitimate extension is JuanBlanco.solidity, maintained by Juan Blanco, whose open-source repository most Solidity developers have installed for syntax support and compilation. The counterfeit was published under the account juannegro, and per SlowMist it copied the real extension's description, icon, and repository link wholesale, differing only by a few characters in the publisher name. The swap from blanco to negro, white to black in Spanish, still reads as a plausible surname (the branding did the work the payload could not).

The package identifier was juannegro.solidity, version 0.0.189. That version number matters: the real extension sits in the same 0.0.x range, so a developer glancing at the marketplace card saw a familiar name, a familiar icon, and a version that looked current.

The distribution path is the part operators keep missing. The extension landed on Open VSX, the vendor-neutral registry that AI-forward editors pull from when they cannot use Microsoft's proprietary marketplace. Open VSX caught it and removed it the same day. TRAE, a popular AI IDE, mirrors Open VSX. According to SlowMist, TRAE syncs newly published extensions from Open VSX quickly, but it does not sync subsequent removals or blocklist entries. So the takedown that protected Open VSX users never reached TRAE users. Two and a half months after the pull, TRAE's plugin marketplace API was still serving the malicious VSIX. SlowMist did not publish an install count for the fake, so its reach is unknown. The gap is structural: a removal in one registry does not propagate to the mirror that copied it, so a package that fails review upstream keeps shipping to everyone downstream who trusts that mirror.

How Did the On-Chain C2 Work?

A command-and-control channel is how implanted malware asks its operator what to do next and where to send stolen data. The weak point of any C2 is its address. Hardcode a domain or an IP and a defender can sinkhole it, and the whole botnet goes dark. Attackers spend real effort making that address resilient. This one made it a smart contract.

The extension carried no fixed backend. Instead it read its configuration from an Ethereum mainnet contract at 0xf8a900db50b3331be6b768ba460bb59f3e40c344, where the attacker stored two values, param1 and param2. On macOS and Linux, param1 is a raw reverse-shell endpoint. On Windows, param2 is an HTTP URL for a second-stage payload. The VSIX is only the delivery vehicle. The live instructions sit on-chain, and only the contract's owner can change them.

The on-chain record does the corroboration for us. The contract's controlling wallet is 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7, and Etherscan independently confirms the timeline SlowMist reconstructed. The contract was deployed on March 14, 2026, roughly seven weeks before the extension ever appeared on Open VSX. Its whole history is seven transactions from that one wallet: the deployment, then six calls to two setter methods (function selectors 0xc832508f for param1 and 0xf56f9b48 for param2), the last on May 16, 2026. SlowMist singles out three of those writes: the initial configuration on March 14, a param1 rotation on May 3, and a param2 update on May 16. Read the dates against the publication date and the sequencing tells the story: the attacker stood up the on-chain control plane and tuned it through late March, published the extension on May 1, then kept moving the backend afterward, on May 3 and again on May 16, without once touching the marketplace listing. The wallet's role on-chain was narrow: deploy the contract and write its config. No stolen funds passed through it, because the theft ran off-chain through the shell.

The activation is deliberately quiet. The manifest registers the onStartupFinished event, so the dropper runs when the IDE finishes loading, with no requirement that the developer ever open a .sol file. Install once, and it fires on every launch thereafter.

Persistence is written per operating system, using names chosen to blend into a Solidity toolchain:

• macOS: payload staged in ~/.solidity/, autostart via a LaunchAgent at ~/Library/LaunchAgents/com.solidity.langsupport.runner.plist.
• Linux: payload in ~/.solidity/, autostart via a systemd user service solidity-langsupport-runner.service.
• Windows: payload in C:\Users\Public\solidity\, autostart via a Run key under HKCU\Software\Microsoft\Windows\CurrentVersion\Run.

A developer who audits their own startup items sees solidity-langsupport-runner and reads it as part of the plugin they installed on purpose.

What lands next is operator access, not a fixed script. SlowMist describes the payloads as executing system commands, opening a remote shell, and downloading and running further code. A reverse shell is hands-on-keyboard control of the account that ran the editor, so the real exposure for this audience is everything that account can reach: wallet keystores and seed-phrase files, SSH and cloud credentials, browser sessions, and any deployer key on the box. SlowMist has not published a per-victim inventory of what was taken, so treat the exposure as the entire developer environment until proven otherwise.

The Attack, Step by Step

The path is not a straight line. The attacker writes to the contract on their own schedule, days apart. The extension reads from it at runtime. The execution branches by operating system.

What Are the Indicators of Compromise?

SlowMist's advice is to hunt on the stable artifacts, the contract, the selectors, the file paths, and the sample hashes, rather than the backend IPs, which the operator can rotate on-chain at will. The network and on-chain indicators:

Host-side, the VSIX package and the second-stage binaries:

On disk, check for a ~/.solidity/ payload with a com.solidity.langsupport.runner.plist LaunchAgent on macOS, a solidity-langsupport-runner.service systemd user unit on Linux, and a Run key plus a C:\Users\Public\solidity\ payload on Windows.

Why Storing C2 on a Blockchain Cuts Both Ways

This is not the first Solidity extension to hide its C2 on Ethereum. In November 2025, researcher John Tuckner of Secure Annex documented SleepyDuck, a malicious extension published as juan-bianco.solidity-vlang that, as The Hacker News reported, read its C2 address from an Ethereum contract so the operator could revive the channel if its primary server went down. SleepyDuck reached over 14,000 downloads before it was flagged. The juannegro campaign is the same idea months later, with its own contract and its own package name. The technique is becoming a pattern, and the pattern targets the same population: people who write and deploy smart contracts for a living.

The design logic is worth taking seriously, because it is genuinely resilient. The channel has no domain to let expire, no registrar to serve, and no host to abuse-report. A blockchain read is cheap, censorship-resistant, and looks like ordinary RPC traffic leaving the machine. For an attacker who wants a control plane that survives takedown efforts, a contract on a chain with tens of thousands of nodes is close to ideal.

The move cuts the other way too, and defenders should press on the edge the attacker handed them. A public blockchain is the most surveilled database in existence. The C2 contract and its controlling wallet are permanent, world-readable artifacts. Every configuration change is a timestamped transaction that anyone can watch. The very property that makes the channel hard to kill also makes it impossible to hide: the contract at 0xf8a9...c344 and the wallet at 0xFd3f...7cA7 are fixed indicators that no amount of infrastructure churn can rotate away. Watch them, and you see the operator change their mind in real time.

The security read is honest and narrow. An audit would not have caught this, because no contract of yours is broken. This is a developer-endpoint and supply-chain problem: a poisoned tool, a registry mirror that copied the upload and missed the takedown, and keys sitting on a machine that just handed a stranger a shell. The defensive value of the on-chain component is precisely that it is on-chain, where runtime monitoring and threat intelligence can track it. Monitoring will not stop the install. What it can do is watch the contract and the wallet the attacker cannot move, and flag the operator the moment they rotate the backend.

What Should Teams Actually Do?

1. Pin extensions by publisher identity, not display name. The card you trust shows an icon and a title, both of which the attacker copied. Verify the publisher account (JuanBlanco, not juannegro) and, where the editor supports it, pin a known-good version rather than tracking latest.
2. Treat IDE marketplaces as an untrusted supply chain. The gap here was that TRAE mirrors Open VSX additions but not its removals. If your team uses an AI editor that pulls from Open VSX, assume a removed-upstream package can still be live downstream, and prefer the official Microsoft marketplace or an internally vetted mirror.
3. Deny outbound by default on developer machines. A reverse shell to a raw IP:port and an HTTP fetch of app.js from a hardcoded address are both loud on an egress-filtered network. Most dev laptops allow unrestricted outbound; a default-deny policy with an allowlist turns this dropper's first callback into an alert.
4. Watch the on-chain indicators. The C2 contract and wallet are fixed and public. Add them to your threat-intel watchlist and alert on new transactions from the controlling wallet: each call to the param1 and param2 setters is the operator rotating the backend, a live sign the campaign is still being run. This is where a monitoring layer earns its place on this incident.
5. Assume full endpoint compromise if it ran. SlowMist's guidance is to isolate the device, remove the persistence entries, reimage from trusted media, and rotate every credential the machine touched. For this audience that explicitly includes deployer keys, API tokens, and any seed phrase that was ever on the box.
6. Keep signing keys off the workstation. The reason a shelled laptop becomes a drained treasury is that the signing key lives on the laptop. A hardware wallet or an air-gapped signer means an owned developer machine is a serious incident, not an automatic loss of funds.

Frequently Asked Questions

Is the malicious extension still available? It was removed from Open VSX on May 1, 2026, the day it was published. As of July 18, 2026, SlowMist reported it was still downloadable from the TRAE marketplace at version 0.0.189, because TRAE did not mirror the Open VSX removal.

I installed juannegro.solidity. What should I do? Treat the machine as fully compromised. Disconnect it, remove the persistence entries listed above, reimage from clean media, and rotate every credential, API key, deployer key, and seed phrase that touched the device. Do not simply uninstall the extension; the persistence and payload live outside it.

Would a smart-contract audit have prevented this? No. An audit reviews the code you wrote, and no code you wrote is involved here. The compromise runs through a fake developer tool and the endpoint it lands on. The relevant controls are tool provenance, egress monitoring, key isolation, and watching the attacker's on-chain indicators.

Why would malware put its C2 on a blockchain? Takedown resistance. There is no domain or server to seize, and the operator can rotate the backend address with a single transaction. The trade-off is that the contract and wallet become permanent public indicators that defenders can monitor.

How is this different from the SleepyDuck extension? It is the same technique. SleepyDuck (juan-bianco.solidity-vlang, November 2025) also read its C2 from an Ethereum contract. The juannegro campaign uses a different package name and a different contract, which is what makes the on-chain-C2 pattern worth flagging rather than treating as a one-off.

Sources / References

• SlowMist: Threat Intelligence, On-Chain Backdoor in a Malicious TRAE Extension.
• Etherscan: the C2 contract 0xf8a900db50b3331be6b768ba460bb59f3e40c344 and controlling wallet 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7.
• Visual Studio Marketplace and GitHub: the legitimate JuanBlanco.solidity extension by Juan Blanco.
• Secure Annex and The Hacker News: the SleepyDuck extension and its Ethereum-based C2 (November 2025).
• BleepingComputer: fake Solidity VS Code extension on Open VSX backdoors developers.