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.

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)