TL;DR

Key Points

• Treat most “blockchain C2” as resilient rendezvous: on-chain data holds rotating URLs/IPs/keys, while actual C2 runs over standard web/WebSocket.

• Hunt for the behavioral chain: blockchain RPC read → base64-decode/JSON-parse/decompress → immediate outbound HTTP(S)/WebSocket to a new destination.

• Expect two dominant patterns: Solana transaction memos and EVM (Ethereum Virtual Machine) contract state / proxy chains as pointer stores.

• Once you know the wallet/contract, you can monitor updates and race pointer changes, blocking newly revealed infrastructure quickly.

• prioritize: Alert on non-Web3 hosts doing repeated Solana/EVM RPC with new HTTP(S)/WebSocket connections right after.

• detect: Instrument for “decode pipeline then connect” (base64-decode, JSON-parse, decompress → outbound to a first-seen domain/IP).

• constrain: Lock down install-time execution (npm/CI), browser Web3, and outbound WebSockets where not required.

AlphaHunt

Stop doomscrolling, start decisioning. We chewed through the muck so your team doesn’t have to. → Subscribe!

Like this? Forward this to a friend!

(Have feedback? Did something resonate with you? Did something annoy you? Just hit reply! :))

The story in 60 seconds

Adversaries are using blockchains as public, tamper-resistant configuration mailboxes: implants read a wallet or contract, decode the content, then connect to conventional HTTP(S) or WebSocket C2. The chain is where the pointer lives; the real control plane is off-chain and rotates cheaply, while every change remains globally visible.

On Solana, public reporting shows npm install-time malware polling a hardcoded wallet roughly every 10 seconds, reading transaction memos, base64-decoding JSON, and using the result as a URL for stage 2. On EVM chains, botnets and web-injection campaigns read contract storage (single state variables) or follow router→logic→storage contract chains to fetch URLs, keys, and WebSocket endpoints.

In most enterprises, repeated Solana/EVM RPC from CI/build or endpoint workstations is abnormal—especially when it’s followed immediately by first-seen destinations. If you capture the wallets/contracts involved, you can track pointer updates, block each new endpoint as it appears, and reduce the time attackers get to use new C2 infrastructure.

High Impact, Quick Wins

• Gate Solana/EVM RPC from CI/build and servers
  • Action: Default-deny outbound Solana/EVM RPC from CI/build agents and production servers; allowlist only explicit Web3/blockchain RPC APIs.
  • Measure: Drop in non-approved RPC sessions; share of CI/build jobs under default-deny policies.
• Deploy read→decode→connect correlation
  • Action: Correlate RPC calls, decode steps (base64-decode/JSON-parse/decompress), and first-time HTTP(S)/WebSocket connections within a short window.
  • Measure: Precision of full-sequence detections vs single-signal RPC or WebSocket alerts.
• Operationalize wallet/contract watchlists
  • Action: Track known wallets/contracts, watch for memos/state updates, and automatically test/block newly derived endpoints.
  • Measure: Time from on-chain update to block; count of campaigns where endpoints are blocked before broad internal fan-out.

AlphaHunt Converge - Plug in your Flight Crew

Get intelligence where it counts. No dashboards. No detours. AlphaHunt Converge teases out your intent, reviews the results and delivers actionable intel right inside Slack. We turn noise into signal and analysts into force multipliers.

Anticipate, Don’t Chase.

Plug it In!

Why it matters

SOC

• If you do only one thing: Alert when non-Web3 hosts show repeated Solana/EVM RPC at ~10-second intervals followed by first-time HTTP(S)/WebSocket connections, to cut dwell time before C2 stabilizes.
• Watch for:
  • Repeated Solana/EVM RPC at regular intervals from CI/build agents, servers, or user workstations, because these rarely need chain access.
  • RPC reads followed within seconds by HTTP(S) or wss:// connections to first-seen domains/IPs.
  • Bursts of new WebSocket endpoints accessed by multiple hosts shortly after known wallet/contract update events.

IR

• If you do only one thing: When you see the read→decode→connect chain, capture the wallets/contracts and decoded endpoints, then pivot both internally and on-chain to identify additional victims and future C2 endpoints.
• Preserve and analyze:
  • Process trees where npm/postinstall scripts, Node/PowerShell, or browser child processes perform RPC read → base64-decode/JSON-parse/decompress → connect.
  • Intermediate artifacts: decoded URLs, WebSocket endpoints, keys, and any local cooldown markers (for example, small JSON files created to throttle execution).
  • Timelines linking on-chain updates (memos/state changes) to internal first-seen connections for containment and retro-hunting.

SecOps

• If you do only one thing: Enforce default-deny internet egress for CI/build and sensitive server tiers, with explicit exceptions for Web3/blockchain RPC APIs.
• Control changes:
  • Restrict npm and other install-time hooks from arbitrary outbound network access; require justification and logging for exceptions.
  • Limit outbound WebSockets from CI/build and most server tiers; baseline and monitor remaining WebSocket egress for new external IP:ports.
  • Route approved Web3/blockchain RPC through controlled egress points (proxies/gateways) to centralize visibility and policy.

Strategic

• If you do only one thing: Frame this as supply-chain and web-compromise blast-radius reduction that shrinks the window between attacker pointer rotation and your block decision.
• Stakeholder outcomes:
  • Lower risk that hijacked dependencies, IDE extensions, or compromised websites quietly stage code via blockchain pointers on CI/dev endpoints.
  • Establish that Web3/blockchain access is an explicitly governed capability with accountable owners and monitored chokepoints.
  • Integrate wallet/contract monitoring into standard threat-intel and incident workflows so future pointer rotations trigger rapid defensive actions.

See it in your telemetry

Network

• Focus on:
  • Repeated Solana/EVM RPC from hosts without declared Web3 use, especially with ~10-second polling patterns.
  • RPC read → within seconds, HTTP(S) or ws:///wss:// connections to first-seen domains/IPs.
  • Correlation between wallet/contract memo or state updates and subsequent internal connection bursts to newly resolved endpoints.

Endpoint

• Focus on:
  • Node.js/npm install scripts, IDE extensions, or build tools that:
    • Call Solana/EVM RPC, then
    • Base64-decode, JSON-parse, or decompress data, then
    • Connect to the decoded destination.
  • Browser JavaScript that combines Web3 libraries with atob, gzip-like decompression, and eval, followed by outbound fetches or iframes to new domains.
  • Creation of cooldown or marker files (for example, small JSON files in user home directories) tightly aligned in time with the read→decode→connect sequence.

[DEEP RESEARCH] Blockchain Dead-Drop “Pointers” in C2: The Common Patterns (Solana + EVM) and How to Hunt Them

TL;DR

• Most “blockchain C2” is really blockchain-as-pointer-registry: on-chain artifacts provide a rotating off-chain URL/IP/key, not full commands.
• Two dominant pointer placements show up in public reporting: Solana transaction memos and EVM contract state variables / multi-contract proxy chains.
• The high-signal hunt primitive is a behavioral sequence: chain read → decode → immediate outbound fetch/connect.
• Defenders can often race the attacker: once you identify the on-chain anchor, you can monitor it and preemptively block the newly revealed off-chain infrastructure.
• Treat this as resilient rendezvous, not “magic un-blockable C2”: the on-chain part is durable; the off-chain destinations are still disruptable.

1) What “Pointer Patterns” Are (and Why Adversaries Prefer Them)