Visualização de leitura

GlassWorm attack installs fake browser extension for surveillance

GlassWorm hides inside developer tools. Once it’s in, it steals data, installs remote access malware, and even a fake browser extension to monitor activity. While it starts with developers, the impact can quickly spread. With stolen credentials, access tokens, and compromised tools, attackers can launch wider supply chain attacks, putting companies and everyday users at risk.

How the infection starts

GlassWorm is usually distributed through developer channels. That means that programmers get their systems compromised by downloading malicious packages from code repositories like npm, GitHub, PyPI, and so on. These can be new malicious packages or altered packages from once-trusted, but now compromised, accounts.

The developer installs or updates a trusted or popular npm/PyPI package or VS Code extension, but the maintainer’s account or supply chain has been compromised.

What happens after installation

Once the package is pulled, a preinstall script or invisible Unicode loader runs and fingerprints the machine. If it finds a Russian locale, execution stops. If not, the script waits a few hours and then quietly contacts the Solana blockchain to discover where to fetch stage two of the infection. Rather than hardcoding a link that could be taken down, the attacker stores this information in the memo field of a Solana transaction.

Stage two: Data theft

The stage two payload is an infostealer that targets browser extension profiles, standalone wallet apps, and .txt/image files likely holding seeds or keys, along with npm tokens, git credentials, VS Code secrets, and cloud provider credentials. After gathering this information, it sends it to a remote server via a POST request.

Stage three: Full system compromise

After that, it’s on to stage three. The malware fetches two main components: the Ledger/Trezor phishing binary aimed at users with a Ledger or Trezor device plugged in, and a Node.js Remote Access Trojan (RAT) with several modules, including browser credential stealers and a Chrome‑extension installer. It gains persistence by setting up scheduled tasks and Run registry keys so that the RAT comes back on every reboot.

How the malware stays hidden and connected

The RAT does not hardcode its main command and control (C2) address. Instead, it performs a distributed hash table (DHT) lookup for the pinned public key. DHT is a distributed system that provides a lookup service similar to a hash table. Key–value pairs are stored in a DHT and can be used to retrieve the value associated with a given key. If this method fails, the RAT goes back to the Solana blockchain to fetch a new IP address.

Browser surveillance and tracking

The RAT also force-installs a Chrome extension (in the example described by Aikido, it pretends to be “Google Docs Offline”), which acts as an onboard session surveillance. Besides stealing cookies, localStorage, the full Document Object Model (DOM) tree of the active tab, bookmarks, screenshots, keystrokes, clipboard content, up to 5,000 browser history entries, and the installed extensions list, it can also be used to take screenshots and act as a keylogger.

What this looks like to the victim

From the victim’s point of view, all this happens very stealthily. If they’re paying close attention, they may see a few suspicious outgoing connections, the startup entries, and the new browser extension.

Who’s at risk, and how this could spread

The current setup appears to focus on developers who may have cryptocurrency assets, but many of these components and the stolen information can be used to initiate supply chain attacks or target other groups of users.

How to stay safe

Because of the stealthy nature of this infection chain, there are two main strategies to stay safe:

  • Prefer known‑good, pinned versions, and treat sudden ownership changes, new maintainers, or big code rewrites in minor releases as review triggers.
  • Regularly audit browser extensions, remove anything you don’t recognize, and be suspicious of “Google Docs Offline”‑style clones or duplicates.
  • Check your scheduled tasks and registry startup locations for unexpected entries.
  • Use an up-to-date, real-time anti-malware solution to detect and block malicious connections and the downloaded malware.

IOCs (Indicators of Compromise)

IP addresses:

45.32.150[.]251

217.69.3[.]152

217.69.0[.]159

45.150.34[.]158

Malwarebytes blocks the IP address 45.32.150.251 used for stage 2 payload delivery, and the stage three WebSocket RAT
Malwarebytes blocks the IP address 45.32.150.251 used for stage 2 payload delivery, and the stage three WebSocket RAT

Registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\UpdateApp 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\UpdateLedger

Scheduled Task:

Name: UpdateApp which runs: AghzgY.ps1

Browser extension:

Display name: Google Docs Offline (version 1.95.1)

Windows extension directory name :jucku

macOS extension directory name: myextension


We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

GlassWorm Campaign Expands Through Malicious Open VSX Extensions

GlassWorm

A large-scale malicious campaign tied to GlassWorm has expanded within the ecosystem of open VSX extensions, introducing a method of spreading malware through developer tools. Researchers identified at least 72 additional malicious open VSX extensions beginning January 31, 2026, including several that function as transitive GlassWorm loader extensions aimed at developers.  Rather than reappearing as a completely new operation, GlassWorm has evolved its tactics. Recent analysis shows a notable escalation in how the campaign spreads through open VSX extensions, shifting from directly embedding malicious code into every extension to exploiting the extension relationship mechanisms within the Visual Studio Code ecosystem. 

GlassWorm Exploits Extension Relationships

The campaign abuses two extension manifest fields commonly used by open VSX extensions and compatible editors: extensionPack and extensionDependencies. These fields allow one extension to automatically install additional extensions when the primary extension is installed.  Both settings are declared inside an extension’s package.json file and reference other extensions using the publisher.name identifier. In legitimate scenarios, this functionality provides convenience for developers. For example, extension packs can bundle multiple tools together so that a developer setting up a particular environment can install them all at once.  A legitimate example cited in official documentation shows how a PHP development pack might bundle debugging and language tooling: 
{  "extensionPack": ["xdebug.php-debug", "zobo.php-intellisense"] } 
However, GlassWorm operators have repurposed this functionality to distribute malware indirectly through open VSX extensions.  Because these manifest fields do not require extensions to share the same publisher or namespace, any extension author can reference any other extension. This design allows attackers to publish seemingly harmless extensions that later become indirect malware installers. 

Transitive Delivery Expands the GlassWorm Attack Surface 

Unlike earlier iterations where malicious code was embedded directly in extensions, the newer GlassWorm approach enables transitive malware delivery. A benign-looking extension can later be updated to include an extensionPack or extensionDependencies entry that installs a separate malicious extension.  One confirmed example involves otoboss.autoimport-extension, where version 1.5.7 includes an extensionPack reference to oigotm.my-command-palette-extension, while version 1.5.6 references federicanc.dotenv-syntax-highlighting, which has been confirmed as GlassWorm-linked.  Additional live cases were also identified, including: 
  • twilkbilk.color-highlight-css 
  • crotoapp.vscode-xml-extension 
These examples illustrate how open VSX extensions that initially appear harmless can later become indirect malware distribution points. This approach reduces visibility of the malicious component and complicates detection efforts.  The strategy also undermines traditional extension reviews. Security teams can no longer rely on examining only the initial release of an extension, since malicious dependencies may be introduced in later updates. 

Inflated Downloads and Impersonated Tools 

Many of the malicious open VSX extensions in the GlassWorm campaign impersonate widely used developer tools to increase credibility. These include utilities such as linters, formatters, code runners, and language tools for frameworks, including Angular, Flutter, Python, and Vue.  Other impersonated tools include: 
  • vscode-icons 
  • WakaTime 
  • Better Comments 
The campaign also targets AI development tools, including extensions related to Claude Code, Codex, and Antigravity.  Some extensions showed download counts in the thousands, likely manipulated by the threat actor to make the packages appear legitimate. One example, twilkbilk.color-highlight-css, displayed 3.5K reported downloads while impersonating the legitimate color-highlight extension.  In another case, daeumer-web.es-linter-for-vs-code uses a publisher name that is a typosquat of the legitimate ESLint publisher dbaeumer.  As of March 13, 2026, the Open VSX registry removed many of the transitively malicious extensions. However, some listings, including twilkbilk/color-highlight-css and crotoapp/vscode-xml-extension, were still active at the time of analysis, indicating that takedown efforts were ongoing. 

GlassWorm Loader Evolution and Infrastructure Changes 

While the distribution method has evolved, the underlying GlassWorm loader retains several recognizable characteristics.  The latest variants still rely on: 
  • Staged JavaScript execution 
  • Russian locale and timezone geofencing 
  • Solana transaction memos used as dead drops 
  • In-memory follow-on code execution 
However, several operational changes indicate an effort to improve resilience and evade detection.  For example, the campaign rotated Solana wallet infrastructure from: 
  • BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC 
to 
  • 6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ 
The operation also introduced additional command-and-control IP addresses, including: 
  • 45.32.151.157 
  • 70.34.242.255 
At the same time, it continues to reuse 45.32.150.251, suggesting continuity with earlier GlassWorm activity.  Other technical modifications include: 
  • Continued use of the Solana memo program MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr 
  • Replacement of the earlier static AES-wrapped loader with heavier RC4, base64, and string-array obfuscation 
  • Relocation of decryption keys from the extension code into HTTP response headers, specifically ivbase64 and secretkey 
Security analysts also highlighted embedded cryptographic indicators, such as: 
  • AES key: wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz
  • AES IV: c4b9a3773e9dced6015a670855fd32b
❌