GlassWorm's Solana Dead-Drop: 50 Blockchain Transactions, 7 C2 Rotations, and an Immutable Forensic Trail
The operator's own infrastructure management created a permanent, public record of every C2 server they ever used
Fifty transactions. Seven IP addresses. Three and a half months of command-and-control infrastructure, logged permanently on a public blockchain by the operator themselves.
On March 31, researcher tipo_deincognito reported a new GlassWorm IOC to ThreatFox: 217.69.2[.]135:5000. Initial triage suggested a possible Wave 4 -- a new campaign phase. But when Breakglass Intelligence pulled the thread, the picture was both simpler and far more alarming. This was not a new wave. It was the same Wave 3 operation we have been tracking since March, now on its seventh C2 server -- and the complete rotation history was sitting in plain sight on the Solana blockchain, written there by the operator as an immutable address book for their botnet.
This is the story of how a threat actor's own infrastructure management technique became the forensic evidence that mapped their entire operation.
The Blockchain Address Book
In our previous GlassWorm Wave 3 analysis, we documented the Solana dead-drop mechanism: infected machines query a Solana wallet's transaction history to discover the current C2 address. The operator publishes new server IPs as memo transactions, and bots read them. We called it "effectively immune to takedown" because Solana transactions are permanent, publicly readable, and uncensorable.
What we did not do in March was read every transaction in the wallet's history. This time, we did.
Wallet BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC -- the GlassWorm C2 resolver -- contains 50 transactions dating back to December 17, 2025. Forty-six of them are memo transactions encoding C2 URLs. Parsing every memo reveals the complete infrastructure rotation timeline: seven unique C2 IP addresses, deployed in sequence, each active for 5 to 37 days before being burned and replaced.
The blockchain does not forget. And the operator, by design, made sure of that.
The Full Rotation
| # | IP Address | First Seen | Last Seen | Duration | Memos | Status |
|---|---|---|---|---|---|---|
| 1 | 45.32.151[.]157 | Dec 17, 2025 | Jan 12, 2026 | 26 days | 17 | Dead |
| 2 | 217.69.11[.]57 | Jan 22, 2026 | Feb 9, 2026 | 18 days | 9 | Dead |
| 3 | 45.32.150[.]97 | Feb 9, 2026 | Feb 14, 2026 | 5 days | 11 | Dead |
| 4 | 217.69.11[.]99 | Feb 25, 2026 | Mar 10, 2026 | 13 days | 5 | Dead |
| 5 | 45.76.44[.]240 | Mar 13, 2026 | Mar 13, 2026 | <1 day | 1 | Unknown |
| 6 | 217.69.0[.]159 | Mar 13, 2026 | Mar 15, 2026 | 2 days | 3 | SSH only |
| 7 | 217.69.2[.]135 | Mar 24, 2026 | Present | Active | 3 | Current C2 |
Two patterns emerge immediately.
First, the rotation is accelerating. The earliest C2 lasted 26 days. The most recent ones last days or hours. Server #5 -- 45.76.44[.]240 -- appeared in a single memo transaction on March 13 and was never referenced again. Either the operator tested it and discarded it, or something spooked them within hours of deployment. Server #6 lasted two days. The operator is getting faster at burning infrastructure, which means they are either detecting monitoring or operating out of increased caution.
Second, every single IP belongs to Vultr (AS20473). The 217.69.x.x range maps to Vultr's Paris/France datacenter; the 45.x.x.x addresses are Vultr US. In 3.5 months of C2 rotation, the operator has never used another hosting provider. This is a loyalty that borders on dependency -- and a clustering signal that makes future infrastructure prediction possible.
IPs #5 and #6 -- 45.76.44[.]240 and 217.69.0[.]159 -- have never appeared in any prior GlassWorm reporting. They were discovered exclusively through blockchain analysis. Without reading the Solana transaction history, these servers would have rotated into and out of active use with zero public record of their existence.
What Lives on Port 5000
The ThreatFox submission flagged port 5000. Prior GlassWorm reporting described this port as hosting an "unknown service" that returned 404 errors. We found out what it actually is.
When we hit 217.69.2[.]135:5000, the server responded with structured JSON:
{"error": "Route not found"}
The HTTP headers told the rest of the story:
- Helmet security headers: Full Content Security Policy, HSTS, X-Frame-Options, X-XSS-Protection -- the complete suite that the Helmet.js middleware applies to Express.js applications
- CORS:
Access-Control-Allow-Origin: http://localhost:3000 - Content-Type:
application/json
This is an Express.js API backend -- the server-side half of a management panel. The CORS configuration allowing localhost:3000 is the signature of a React development server. The operator runs a frontend application locally on their machine that connects to port 5000 on the C2 server. This is how they manage the botnet: issue commands, view victim inventories, browse stolen credentials, monitor campaign health.
Port 5000 was never an "unknown service." It is the operator's dashboard API. It was just never probed deeply enough to fingerprint.
Port 80, meanwhile, continues to serve its documented role as the payload delivery endpoint. A GET request to the root returns a Base64-encoded JavaScript command:
cHJvY2Vzcy5leGl0KDAp
Decoded: process.exit(0) -- a kill switch. The default response to unauthenticated requests is an instruction that terminates the bot's Node.js process. Payload delivery paths use Base64-encoded identifiers and AES-256-CBC encryption, with keys delivered in HTTP response headers. Rate limiting is set at 30 requests per minute.
Fifteen Minutes
We had approximately fifteen minutes with the live C2.
During initial probing, 217.69.2[.]135 responded on ports 80 and 5000 with the JSON API responses described above. We collected headers, tested paths, fingerprinted the Express.js stack, and began enumerating the API surface. Then the server stopped responding.
Not a crash. Not a timeout. The ports were firewalled. SSH (port 22) remained open -- the operator had not rebooted or destroyed the server. They had added our IP to a blocklist. The management panel API, the payload delivery endpoint, the Socket.IO C2 ports (4787, 4789) -- all went dark simultaneously while SSH stayed up.
The operator was watching in real time.
This is consistent with the management panel architecture. If port 5000 is a live dashboard, the operator may have seen our requests appear in access logs or received an automated alert. The response was surgical: block the probing IP, keep the server operational for existing bots. No panic. No server destruction. Just access control.
The operational security implication is clear: this actor monitors their infrastructure actively and responds to anomalous connections within minutes. Any future engagement with live GlassWorm C2 servers should assume real-time observation and plan accordingly.
The Exfiltration Server That Nobody Turned Off
While the C2 servers rotate every few weeks, the exfiltration infrastructure has been remarkably stable. Server 208.85.20[.]124 -- documented in the original GlassWorm reporting as a credential theft endpoint -- is still live.
Port 80 serves a Node.js/Express application. The /wall and /log endpoints accept POST requests containing stolen credentials from infected machines. An authenticated /admin path returns a 403 to unauthenticated requests, suggesting a web interface for browsing exfiltrated data.
The other exfiltration server, 208.76.223[.]59 (the AppleScript data collection endpoint at /p2p), has port 80 down but still responds on SSH. Both are Vultr. Both are in Spain, separate from the France-based C2 cluster.
The persistence of 208.85.20[.]124 is notable because it means the operator has not rotated their exfiltration infrastructure even as they have burned through seven C2 addresses. This asymmetry makes sense operationally -- rotating C2 is automated through the Solana wallet, but rotating exfiltration requires updating the hardcoded endpoints in the malware payload, which means redistributing the stealer module. It is also a vulnerability. This IP has been publicly reported for weeks and continues to receive stolen credentials. Either the operator believes it has not been blocklisted by enough defenders to matter, or they have no mechanism to rotate it without recompiling the payload.
The Wallet Infrastructure
The Solana wallet is not a simple throwaway. The on-chain structure reveals a deliberate, role-separated architecture:
| Role | Wallet | Purpose |
|---|---|---|
| C2 Resolver | BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC | Stores C2 addresses as memo transactions |
| Funder | G2YxRa6wt1qePMwfJzdXZG62ej4qaTC7YURzuh2Lwd3t | Funds transactions (~$170K SOL balance) |
| Fee Payer | E9vf42zJXFv8Ljop1cG68NAxLDat4ZEGEWDLfJVX38GF | Pays transaction fees |
| Nonce Authority | DScDQ1zV4qVMU8HQmfcJkjZhfo5QqCWdV7dbxkb2gU9C | Durable nonce for offline pre-signing |
The funder wallet holds approximately $170,000 in SOL. This is not a disposable burn wallet. Someone with real money is behind this operation, and that wallet is potentially linkable to exchange accounts where SOL was purchased. The durable nonce authority enables offline transaction pre-signing -- the operator can prepare C2 rotation transactions ahead of time and broadcast them without the private key being on a network-connected machine at the moment of publication.
Each C2 rotation costs approximately $0.00025 in Solana transaction fees. At that price, the operator could rotate infrastructure every hour for a century without spending a dollar. The economics of blockchain-based C2 are essentially free, which is why the rotation cadence is driven by operational security concerns rather than cost.
What Changed Since Our Last Report
We published our Wave 3 cross-platform analysis on March 17, documenting the macOS Chrome extension sideloader (RedExt Agent), the Windows ABE bypass DLL, and the Solana dead-drop mechanism. At that time, the active C2 was 217.69.11[.]99 (server #4 in the rotation). Here is what has changed:
| Finding | March 17 Report | Current (March 31) |
|---|---|---|
| Active C2 | 217.69.11[.]99 | 217.69.2[.]135 (7th rotation) |
| Known C2 IPs | 5 (historical) | 7 total (2 newly discovered) |
| Port 5000 purpose | "Unknown service" | Express.js operator management panel API |
| Solana transactions | 47 | 50 (3 new since last report) |
Exfil 208.85.20[.]124 | Reported as "potentially offline" | Confirmed LIVE |
| C2 rotation cadence | Estimated 18-37 days | Confirmed 5-37 days (accelerating) |
| Operator behavior | Theoretical monitoring | Confirmed real-time response (15-min firewall) |
The three new Solana transactions (48, 49, 50) correspond to the deployment and configuration of server #7. The operator is still actively maintaining the botnet.
The Takedown Problem
GlassWorm's Solana-based C2 resolver creates a takedown problem that the security industry has not solved.
Consider the five standard approaches:
Domain seizure. There is no domain. The C2 address is a Solana transaction memo. There is nothing to seize.
IP null-routing. Vultr can null-route 217.69.2[.]135. The operator sends a new memo transaction pointing to a fresh VPS. Cost: $0.00025 and five minutes. Every infected machine automatically discovers the new address on its next Solana RPC query.
Hosting provider abuse report. Vultr will likely act on a well-documented report. The operator spins up a new Vultr VPS -- or, for the first time in the campaign's history, tries a different provider -- sends one transaction, and is operational again before the abuse ticket is closed.
Blockchain censorship. Solana validators do not censor memo content. There is no mechanism to prevent C2 address publication, and no precedent for the Solana Foundation intervening in transaction content regardless of purpose.
Wallet monitoring and preemptive blocking. This is the closest thing to a viable strategy. Organizations can monitor the wallet for new memo transactions and proactively block newly published C2 IPs. But this is a reactive race: the operator publishes, defenders detect, defenders push blocks, and in the window between publication and propagation, the botnet reconnects. The operator can also switch wallets by pushing a malware update through the existing worm propagation channel.
The only reliable countermeasure remains endpoint detection -- catch the malware before it queries the blockchain, or detect behavioral patterns regardless of where the C2 address points.
Threat Actor Profile
The attribution picture has not changed materially since our March 17 report, but the new data adds detail:
Language: Russian. The codebase contains hardcoded Cyrillic strings: "Токен не найден" (Token not found), "Невалидный токен" (Invalid token). Stage 1 validates system locale and excludes CIS countries from infection -- a standard Russian-speaking threat actor technique for avoiding domestic law enforcement attention.
Financial sophistication: The role-separated Solana wallet infrastructure, the $170K funder balance, and the durable nonce for offline pre-signing indicate an operator comfortable with cryptocurrency at an operational level, not just as a theft target.
Infrastructure discipline: Exclusively Vultr. Rapid rotation. Active real-time monitoring with sub-15-minute response to anomalous probing. IP-based access control on the management panel. The operator is experienced enough to maintain consistent OPSEC under pressure.
OPSEC failures: Despite the operational discipline, the mistakes are significant. The Solana wallet has been reused across the entire Wave 3 campaign -- every C2 address ever used is now public record. The campaign UUID (7c102363-8542-459f-95dd-d845ec5df44c) and operator handle (admin) are sent in HTTP headers with every exfiltration request. The shared bot authentication token (mulKRsVtolooY8S) is the same across all connections. And the funder wallet with $170K in SOL is not disposable -- it is an attribution thread that leads to wherever that SOL was purchased.
Indicators of Compromise
Network Indicators
Active Infrastructure (as of March 31, 2026):
| IP | Port(s) | Role | Hosting | Status |
|---|---|---|---|---|
217.69.2[.]135 | 80, 4787, 4789, 5000 | Current C2 + operator panel | Vultr FR (AS20473) | Firewalled |
208.85.20[.]124 | 80 | Exfil server (/wall, /log, /admin) | Vultr ES (AS20473) | LIVE |
Historical C2 (all Vultr AS20473):
| IP | Active Period | Notes |
|---|---|---|
45.32.151[.]157 | Dec 17, 2025 -- Jan 12, 2026 | First known C2 |
217.69.11[.]57 | Jan 22 -- Feb 9, 2026 | |
45.32.150[.]97 | Feb 9 -- Feb 14, 2026 | Shortest rotation (5 days) |
217.69.11[.]99 | Feb 25 -- Mar 10, 2026 | Active during our Mar 17 report |
45.76.44[.]240 | Mar 13, 2026 | Single day, single memo -- NEW |
217.69.0[.]159 | Mar 13 -- Mar 15, 2026 | SSH only remains -- NEW |
Supporting Infrastructure:
| IP | Role | Status |
|---|---|---|
208.76.223[.]59 | Exfil (AppleScript data, /p2p) | SSH only |
217.69.3[.]51 | Payload delivery mirror | SSH only |
45.32.150[.]251 | Payload delivery mirror | Down |
Blockchain Indicators
| Role | Address |
|---|---|
| C2 Resolver Wallet | BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC |
| Funder (~$170K SOL) | G2YxRa6wt1qePMwfJzdXZG62ej4qaTC7YURzuh2Lwd3t |
| Fee Payer | E9vf42zJXFv8Ljop1cG68NAxLDat4ZEGEWDLfJVX38GF |
| Nonce Authority | DScDQ1zV4qVMU8HQmfcJkjZhfo5QqCWdV7dbxkb2gU9C |
| DHT ed25519 Pubkey | ea1b4260a83348243387d6cdfda3cd287e323958 |
File Indicators
| SHA256 | Description |
|---|---|
81e7e8d207b4d758... | Stage archive (ZIP, 7.9 MB) |
e97e50b6e104fdbc... | Native binary (PE/AMD64, 1.4 MB) |
f89ce54fae3ab66e... | RAT loader (JS, 206 KB) |
05a3584d3b296f90... | RAT binary (JS, 549 KB) |
49cd8c05959153... | macOS RAT (JS, 1.3 MB) |
fe06f0d6324dca43... | Stage 1 loader |
7fb54d95cb1738de... | Stage 2 (encrypted) |
d72c1c75958ad7c6... | Stage 3 (decrypted) |
41caca39e0605527... | RAT v2.27 |
1ed7ca5301e96e3c... | Browser credential dumper |
43253a888417dfab... | data.dll (Chromium ABE bypass) |
de81eacd045a8859... | memexec loader (x64) |
4e339dcdc3e3a8bf... | memexec loader (ia32) |
415a4f39dd93c2ad... | VS Code harvester |
Behavioral Indicators
| Indicator | Value |
|---|---|
| LaunchAgent | ~/Library/LaunchAgents/com.user.nodestart.plist |
| Hidden Node.js | ~/.config/system/.data/.nodejs/ |
| Init file | ~/init.json |
| Temp directory | /tmp/ijewf/ |
| Keychain entry | pass_users_for_script |
| Socket.IO auth | _partner=mulKRsVtolooY8S |
| Campaign UUID | 7c102363-8542-459f-95dd-d845ec5df44c |
| Operator handle | admin |
Recommendations
For defenders -- immediate:
Block all 11 IPs at the network perimeter. Search macOS endpoints for com.user.nodestart.plist and the hidden Node.js installation at ~/.config/system/.data/.nodejs/. Audit VS Code extensions against the known-malicious publisher "oorzc" (extensions: ssh-tools, i18n-tools-plus, mind-map, scss-to-css-compile). If your DPI stack supports it, monitor for the Solana wallet address in outbound HTTPS payloads.
For threat intelligence teams:
Monitor the Solana wallet for new memo transactions -- each one signals a C2 rotation before the new server is fully operational. Track the funder wallet G2YxRa6wt1qePMwfJzdXZG62ej4qaTC7YURzuh2Lwd3t for exchange deposits; at $170K, this wallet likely has a traceable acquisition history. File abuse reports with Vultr for both active IPs. Monitor AS20473 for new allocations in the 217.69.0.0/20 range -- the operator has shown a preference for this specific Vultr/France subnet.
For Vultr:
Eleven IPs across your infrastructure, all linked to the same campaign through blockchain evidence. The current active C2 (217.69.2[.]135) and exfiltration server (208.85.20[.]124) are receiving stolen credentials from compromised developer workstations right now. The Solana wallet provides a forensic trail linking every server to a single operator.
The Irony
The Solana dead-drop was GlassWorm's best innovation. It made C2 takedown nearly impossible, freed the operator from domain registration, and provided instant rotation at negligible cost. It was a genuine advancement in C2 resilience.
It was also a complete forensic gift.
Every C2 address the operator has ever used is permanently recorded on a public blockchain, timestamped to the second, linked to a wallet that is linked to a funder with $170,000 in assets. The same mechanism that makes the botnet unkillable makes the operator's infrastructure history unmaskable. You cannot have immutable C2 resolution without immutable C2 records.
The operator chose permanence. So did the evidence.
This investigation was conducted by Breakglass Intelligence's GHOST system. The GlassWorm C2 resolver wallet and all associated infrastructure remain under continuous monitoring. Previous Breakglass coverage: Wave 1 -- 9 Infected VS Code Extensions Still Live (March 16) | Wave 3 -- Cross-Platform Expansion (March 17).
Breakglass Intelligence | March 31, 2026