GlassWorm Goes Mac: Fresh Infrastructure, New Tricks

Originally published December 29, 2025

Editor’s note: This article was originally published by Koi Security on December 29, 2025. Koi is now part of Palo Alto Networks, and this article has been adapted for the Palo Alto Networks blog. The technical findings and infrastructure observations reflect the December 2025 investigation and should not be interpreted as an assessment of the campaign’s current status.

GlassWorm’s fourth observed wave marked a significant change in the campaign: a shift from Windows to macOS, a new encrypted delivery mechanism and code designed to replace legitimate cryptocurrency wallet applications with attacker-controlled versions.

In the December 2025 investigation, Koi researchers identified three malicious extensions on the Open VSX marketplace with approximately 50,000 reported downloads combined. The extensions connected to infrastructure associated with earlier GlassWorm activity, including a previously observed command-and-control (C2) server. That download figure indicates potential exposure—not 50,000 confirmed infections.

The campaign illustrates how software supply chain attacks can reach organizations through the tools their developers install. A familiar marketplace or useful-looking extension does not establish that the underlying code is trustworthy.

Earlier waves concealed malicious code using invisible Unicode characters and later delivered compiled Rust binaries. This wave instead embedded AES-256-CBC-encrypted payloads in the extensions’ JavaScript code. It also introduced a 15-minute execution delay and macOS-specific functionality for persistence and credential collection.

The delivery changed. The underlying objective remained familiar: compromise a developer’s environment, collect sensitive information and use remotely controlled infrastructure to deliver additional functionality.

Key Takeaways

• The analyzed payload targeted macOS. It used AppleScript, LaunchAgents and macOS Keychain access rather than the Windows-specific techniques described in previous waves.
• Encrypted JavaScript and delayed execution changed the detection challenge. The loader combined AES-256-CBC encryption with a 15-minute delay before executing the decrypted payload.
• Solana remained part of the C2 discovery mechanism. A new blockchain address and reused server infrastructure connected the activity to earlier GlassWorm findings.
• Wallet application replacement was an observed code capability, not a confirmed successful deployment. During testing on December 29, 2025, the replacement endpoints returned empty files, preventing that installation path from completing.

From Windows to macOS: A Platform-Specific Payload

Previous GlassWorm waves documented by Koi targeted Windows. The fourth wave’s analyzed payload targeted macOS and incorporated techniques specific to that operating system.

AppleScript execution. The payload used AppleScript to run shell commands and interact with the system. One observed command invoked the macOS security utility to retrieve a named Keychain item.

LaunchAgent persistence. The payload used a LaunchAgent as its persistence mechanism, replacing the Windows-oriented persistence approaches described in earlier research.

Keychain database collection. The malware included functionality to copy the user’s login Keychain database:

~/Library/Keychains/login.keychain-db

These behaviors demonstrate a macOS-specific implementation rather than a simple reuse of the earlier Windows payload.

Collecting a Keychain database should not be confused with automatically decrypting every credential it contains. Access to protected secrets depends on the relevant passwords and access conditions. Nevertheless, suspicious processes reading Keychain files or invoking credential-access functions warrant investigation.

Encrypted JavaScript and a 15-Minute Delay

The fourth wave changed how GlassWorm concealed its malicious functionality.

Instead of relying on invisible Unicode characters or compiled Rust binaries, the extensions contained an encrypted payload in their JavaScript code. The loader used AES-256-CBC with a hardcoded encryption key and initialization vector. Researchers identified the same key across all three extensions, providing another connection among the samples.

The loader also contained a timer value of 9e5 milliseconds: 900,000 milliseconds, or 15 minutes. Execution of the decrypted payload was delayed until after that wait. The original code screenshot shows both the decryption routine and the delayed execution sequence.

That delay matters because sandboxing observes software behavior within a controlled analysis environment. A sandbox that stops monitoring before the 15-minute timer expires could miss the next stage. Delayed execution does not guarantee evasion, however; defenders can account for deferred behavior and combine dynamic analysis with code inspection.

However, delayed execution does not guarantee sandbox evasion, and it does not make static analysis ineffective. The encrypted data, hardcoded decryption material, execution logic and timer remain available for inspection. The defensive lesson is to combine code analysis with behavioral observation rather than treat an initially quiet execution as evidence that an extension is safe.

Solana-Based C2 Discovery and Reused Infrastructure

GlassWorm continued to use the Solana blockchain to discover its current command-and-control (C2) endpoint. C2 communications allow attackers to send instructions to compromised devices and direct additional malicious activity.

In the mechanism described by Koi, the attacker placed base64-encoded URLs in transaction memos. The malware queried the blockchain, decoded the endpoint information and contacted the referenced infrastructure.

The blockchain served as an address-discovery layer; the subsequent payload delivery and data collection still depended on other systems.

The fourth wave used the following Solana address:

BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC

The investigation traced a November 27, 2025 transaction to 217.69.11[.]60. By December, the referenced C2 endpoint had changed to 45.32.151[.]157, which had also appeared in the third wave. Researchers additionally identified 45.32.150[.]251 as an exfiltration server.

The reused IP address, shared delivery characteristics and continued use of Solana-based discovery supported the connection to previous GlassWorm activity. An IP address alone, however, should not be treated as definitive proof of an operator’s identity.

This architecture also complicates disruption. Removing a conventional domain is not enough to eliminate a discovery mechanism recorded on a public blockchain. That does not make the operation impossible to disrupt: defenders can still investigate and restrict malicious endpoint activity and address the payload-hosting and exfiltration infrastructure identified in the campaign.

Hardware Wallet Applications Become a Target

One of the fourth wave’s most notable additions was code intended to replace cryptocurrency hardware-wallet companion applications.

The payload checked for these application directories:

Figure 4: AppleScript checking for Ledger Live and Trezor Suite before invoking wallet replacement routines.

When either application was present, the code invoked a wallet installation routine. The original analysis described a sequence intended to download a replacement, remove the legitimate application and install the attacker-supplied version.

What Researchers Confirmed—and What They Did Not

During testing on December 29, 2025, the wallet replacement endpoints returned empty files.

The installation routine checked the downloaded file’s size and rejected files smaller than 1,000 bytes. Consequently, the empty downloads did not proceed through the replacement process. The researchers observed the replacement logic, but they did not confirm successful installation or operation of a trojanized wallet application during that testing.

Figure 5: Wallet installation routine rejecting downloaded files smaller than 1,000 bytes.

This distinction is important. The code demonstrated an intended attack path, not evidence that a fully functioning wallet trojan had been delivered to victims.

A malicious companion application could potentially misrepresent receiving addresses, present misleading transaction information or use fraudulent recovery prompts to solicit sensitive information. Those are risks associated with compromising the software interface. The findings did not establish compromise of the hardware devices themselves or extraction of private keys stored on those devices.

The unavailable wallet replacement downloads did not eliminate the broader threat. The original investigation reported that other functionality—including credential collection, persistence and data exfiltration—remained operational during the investigation.

The Data Targeted by GlassWorm

The payload’s collection routines extended beyond cryptocurrency applications. They also targeted credentials and local data associated with development tools, browsers and the operating system. The original investigation identified the following categories.

The malware staged collected data in:

/tmp/ijewf/

It then compressed the collected material and sent it to the reported exfiltration endpoint:

45.32.150[.]251/p2p

These paths and network indicators describe the December 2025 samples and infrastructure.

This collection-and-transfer sequence represents data exfiltration: the unauthorized movement of sensitive information out of an environment. Defenders should correlate suspicious file collection and archive creation with unexpected outbound connections rather than investigate each event in isolation.

For organizations, the potential consequences extend beyond the affected workstation. Stolen developer tokens, SSH credentials and browser session data could enable subsequent credential-based attacks, depending on the permissions, validity and protections associated with those credentials. An investigation should therefore assess both the endpoint and the accounts it could access.

Four Waves, Changing Delivery Techniques

The December investigation documented substantial changes across GlassWorm’s first four reported waves. The dates below follow the timeline in the original research.

The operational lesson is not that every wave used entirely new infrastructure or that one particular encoding technique defined the threat. GlassWorm changed its delivery while retaining recognizable behaviors and infrastructure connections.

Defenders should therefore track the broader activity: extension execution, credential access, persistence, endpoint discovery and data transfer—not just the appearance of a particular payload.

Recommended Defensive Actions

The following recommendations translate the reported findings into investigation and prevention priorities.

Establish Visibility Into Developer Extensions

Inventory installed extensions, their full publisher identifiers, versions and installation sources. Match the complete extension IDs in the indicators below rather than relying on display names such as “Prettier” or “Svelte.”

Use the extension-management controls available in each development environment to restrict unapproved software. For managed VS Code deployments, Microsoft documents policies for controlling allowed extensions and versions. Apply equivalent controls in other editors where supported.

Investigate Behavior Beyond Installation

Pair extension inventory and approval controls with endpoint detection and response (EDR) telemetry to investigate process execution, file changes and network activity. Correlating these events over time can help analysts reconstruct what happened after an extension was installed.

Build investigation workflows around the behaviors documented in the campaign: unexpected AppleScript execution, LaunchAgent creation, access to Keychain databases or developer credential files, and staging of data in temporary directories. Correlate those events with the responsible editor or extension process and subsequent network activity.

Do not treat encryption, a timer or a connection to blockchain infrastructure as conclusive evidence of malware by itself. Evaluate those signals in the context of what the extension does and which resources it accesses.

Treat Confirmed Execution as an Incident

Where investigation establishes that the payload executed, isolate the affected endpoint and preserve relevant evidence. Assess persistence and application integrity before returning the system to service.

Use a known-clean system to revoke or rotate potentially exposed developer tokens, SSH credentials and other secrets. Review associated account activity, repository changes and package-publishing events.

Removing the extension alone should not be the entire response: the reported payload established persistence and collected credentials independently of its original delivery mechanism.

Reassess Trust Over Time

Evaluate extensions and their updates throughout their lifecycle, not only when they are first approved. The changes documented across GlassWorm’s waves support a defense that combines software governance, code inspection and endpoint behavior analysis rather than relying exclusively on known signatures.

For broader guidance on reducing risk across development environments, read How To Prevent the 5 Most Common Software Supply Chain Weaknesses, which examines third-party components, access controls, version control systems and CI/CD pipelines.

Indicators of Compromise

The following indicators were reported in the December 2025 investigation. They are provided for historical hunting and investigation; their inclusion does not establish their present-day ownership or activity. Network addresses are defanged.

Open VSX Extension Identifiers

studio-velte-distributor.pro-svelte-extension
cudra-production.vsce-prettier-pro
Puccin-development.full-access-catppuccin-pro-extension

Use these complete identifiers when reviewing extension inventories. The original report did not provide a complete affected-version matrix.

Network and Host Indicators

These indicators and their roles are drawn from the original Koi investigation.

Recommended Reading: Securing the Agentic Endpoint

Protecting the Software Behind Developer Workflows

GlassWorm’s macOS wave illustrates why developer extensions deserve the same scrutiny as other software running on enterprise endpoints. In this investigation, malicious extensions provided a delivery path to credential collection, persistence and attempted application replacement.

The appropriate response is layered: understand which software is installed, evaluate its behavior, restrict unapproved components and investigate suspicious activity across both the endpoint and the accounts it can access.

The risks associated with developer extensions are part of a broader challenge: maintaining visibility and control over software installed outside centralized oversight. Securing the Agentic Endpoint examines that challenge across IDE plugins, browser extensions, code packages and AI tools, and explains the role of Koi within Palo Alto Networks.

Palo Alto Networks Cortex Agentic Endpoint Security provides visibility, risk assessment and governance capabilities across extensions and other components of the modern AI software environment. Organizations can use these capabilities as part of a broader strategy for managing the software operating on their endpoints.

Explore Cortex Agentic Endpoint Security to learn more about identifying and governing software risks across your organization.