New GlassWorm Variant: Leveraging Solana Dead Drops for C2

Inspecting Web3 traffic is a nightmare with standard IDS. The protobuf encoding used by many RPC libraries often obscures the payload. We've had some success hunting for specific User-Agent strings associated with common Solana libraries on the endpoint rather than the network level.

DeviceProcessEvents
| where ProcessVersionInfoOriginalFileName =~ "node.exe"
| where ProcessCommandLine contains "@solana/web3.js"
| project Timestamp, DeviceName, ProcessCommandLine


If you see devs running arbitrary node scripts touching Solana endpoints, audit them immediately.

The Chrome extension vector is the biggest concern here. Once that extension is loaded, it bypasses a lot of traditional network perimeter defenses because the browser trusts the context.

We enforce a strict ExtensionInstallBlocklist via GPO. If you aren't blocking unauthorized extensions, you're basically allowing arbitrary code execution in the user's browser context. You can push a policy to block the specific extension ID once researchers publish it, but an allow-list approach is safer.

Steve and Pete covered the network and browser angles well. To pivot to endpoint detection, I suggest hunting for the extension artifacts on the disk. Since it masquerades as an offline tool, check the manifest file for suspicious permissions or recent creation times.

You can use this PowerShell snippet to scan for recently modified extension directories:

Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Extensions" -Recurse | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-3)}

Since the entry point still relies on social engineering, securing the inbox remains critical. The "Offline Docs" lure implies the email likely contains a suspicious link. We've been hunting for these delivery patterns in our mail logs. Here is a KQL query to identify potential GlassWorm phishing emails based on subject line anomalies:

EmailEvents
| where Subject contains "Google Docs" and Subject contains "offline"
| where SenderFromDomain !endswith "google.com"
| project Timestamp, Subject, SenderFromAddress, RecipientEmailAddress

Building on the link analysis, we can automate the detection of suspicious Solana RPC endpoints within the email headers and body. Standard link scanners often miss blockchain URLs. We run a quick Python script against exported EMLs to flag specific RPC calls embedded in hrefs.

import re, email
msg = email.message_from_string(raw_email)
body = ""
if msg.is_multipart():
    for part in msg.walk():
        body += str(part.get_payload())
else:
    body = msg.get_payload()

# Look for Solana transaction links or custom RPC endpoints
sol_pattern = r"https?://[a-zA-Z0-9.-]*\.solana\.com|api\.mainnet-beta\.solana\.com"
if re.search(sol_pattern, body):
    print("Suspicious Web3 activity detected")

This helps catch the dead drops before users click.

Building on the network visibility, we should focus on the specific RPC methods used for dead drop retrieval. The malware likely polls getAccountInfo or getSignaturesForAddress to fetch C2 instructions. High-frequency calls to these endpoints are a strong indicator.

You can hunt for this behavior using KQL:

DeviceNetworkEvents
| where RemoteUrl has "getAccountInfo" or RemoteUrl has "getSignaturesForAddress"
| summarize Count = count() by DeviceName, RemoteUrl
| where Count > 10

Excellent insights. To pivot from the host and network layer to the payload delivery mechanism, consider actively monitoring the Solana ledger for the specific program IDs or data accounts used in the dead drops. If you identify a suspicious wallet address during analysis, you can poll the RPC node directly to check for embedded payloads or configuration data:

curl -X POST https://api.mainnet-beta.solana.com -H "Content-Type: application/" -d '{"rpc":"2.0", "id":1, "method":"getAccountInfo", "params":["", {"encoding":"base64"}]}'

This helps verify if the address is acting as a C2 beacon before widespread detection.