North Korean Hackers Adopt “EtherHiding” to Stash Malware in Smart Contracts

What will you find in this article?

Introduction: A new spin on bulletproof hosting

Google’s Threat Intelligence Group (GTIG) reports that a DPRK-linked cluster (UNC5342) is now using EtherHiding—a technique that stores second-stage malware inside public blockchain smart contracts on chains like BNB Smart Chain and Ethereum. This is notable as the first observed nation-state adoption of EtherHiding, raising the bar for takedowns and attribution.

In brief

Actor: UNC5342 (overlaps with CL-STA-0240 / “Contagious Interview”).
Initial access: Social engineering (fake recruiters via LinkedIn → move to Telegram/Discord).
Delivery: JavaScript loader JADESNOW pulls payloads via smart-contract reads; third stage is INVISIBLEFERRET.JS, with optional credential-stealer components fetched via Ethereum.
Why it’s hard to stop: Decentralized hosting, read-only calls (no on-chain trace), agility to update payloads quickly.
Targets & intent: Developers, crypto/tech orgs; dual goals of espionage and crypto theft.

Context: From fake recruiters to multi-chain payloads

UNC5342’s tradecraft builds on Contagious Interview, a DPRK social-engineering play where “recruiters” coax targets to run code as part of a sham skills test. Earlier research documented two malware families central to this ecosystem: BeaverTail (downloader/stealer) and InvisibleFerret (backdoor), with cross-platform reach across Windows/macOS/Linux. The EtherHiding update adds blockchain-resilient staging to the same playbook.

Technical analysis

Technique primer: What is EtherHiding?

Originally documented by Guardio Labs in 2023, EtherHiding places obfuscated JavaScript (or pointers to it) inside smart contracts. Web-injected loader code calls a contract function (often via eth_call) to fetch the next stage—without creating a transaction and thus leaving minimal investigative surface. Think dead-drop resolvers (MITRE ATT&CK T1102.001) implemented on-chain.

UNC5342 infection chain (current wave)

Initial lure: Recruiter/social DM → candidate runs “assessment” code.
Stage 1: JavaScript JADESNOW runs on the victim machine.
Stage 2 via smart contract: JADESNOW reads data from a BNB Smart Chain contract (owner-controlled), retrieves/decrypts the second stage.
Stage 3: INVISIBLEFERRET.JAVASCRIPT executes in memory; may query Ethereum for an extra credential-stealer component.
Objectives: Crypto wallet theft (MetaMask/Phantom), credential exfiltration, remote control, persistence.
Google published IoCs including contract addresses and transaction hashes for these stages.

Why it’s resilient

Decentralized infrastructure: no single host to seize.
Stealth reads: payload retrieval via read-only calls (no gas, no ledger footprint).
Hot-swappable payloads: operators update the referenced data or pointer contracts to pivot quickly.

Practical consequences and risks

Extended dwell and repeatability: Compromised WordPress sites and developer endpoints can repeatedly fetch fresh payloads once the loader persists.
Attribution friction: Pseudonymous wallets and contract ownership obscure operator identity.
Takedown latency: You can block APIs and endpoints, but the source (a live chain) persists.
High-value targeting: Developer machines with access to source code, CI secrets, and hot crypto wallets are prime loot.

Operational recommendations: What to do next

1) Stop the lure

Recruiting workflow guardrails: Educate staff that coding tests never require running unknown scripts from chats. Use managed sandboxes if assessments are necessary.
LinkedIn hygiene: Validate recruiters (mutuals, corporate emails, domain DMARC/DKIM alignment).

2) Break the loader → contract link

Web controls: On secure networks, restrict access to known blockchain RPC endpoints (e.g., public BSC/Ethereum gateways) except where business-justified; monitor egress to random RPC/API providers.
Script control: Enforce script integrity (CSP + Subresource Integrity) on web properties you own; detect unauthorized theme/plugin/db edits (WordPress). Criminal EtherHiding campaigns abused exactly these surfaces at scale.

3) Hunt and detect

Network/EDR analytics: Look for browsers or Node runtimes making JSON-RPC calls (e.g., eth_call) to unfamiliar endpoints shortly before JavaScript execution.
YARA/IOC ingestion: Import GTIG’s JADESNOW/INVISIBLEFERRET hashes, addresses, and YARA sample provided in Google’s post into your detection stack; alert on interactions with the published BSC/Ethereum artifacts.
ATT&CK mapping: Treat on-chain contracts as dead-drop resolvers (T1102.001); add detections for resolver-like behavior even when the transport is Web3.

4) Containment & hardening

Wallet safety: Require hardware wallets; disable hot wallets on corporate endpoints.
Browser management: Push managed, silent browser updates; train users that they will never need to manually update Chrome—this directly counters social lures reused in EtherHiding campaigns.
Least privilege for developers: Separate build secrets and personal wallets; enforce PAM/SSH short-lived certs; monitor for unexpected Python/Node installs triggered by unknown processes (a hallmark in BeaverTail/InvisibleFerret chains).

Comparison: DPRK (UNC5342) vs criminal EtherHiding (UNC5142)

Motivation: UNC5342 = espionage + revenue generation via crypto theft; UNC5142 = broad infostealer distribution (VIDAR, LUMMAC.V2, RADTHIEF).
Initial access: UNC5342 uses recruiter lures; UNC5142 compromises WordPress at scale and pushes CLEARSHORT/CLEARFAKE overlays (e.g., fake Chrome updates).
On-chain design: Both store stages/pointers in BSC contracts; UNC5342 also pulls extra pieces from Ethereum, demonstrating multi-chain staging.

Summary / key takeaways

EtherHiding is no longer just a criminal trick; DPRK operators are using it now, which increases resilience and complexity for defenders.
Expect JavaScript loaders that query smart contracts for next stages, often without leaving on-chain traces.
Blocking Web3 endpoints where feasible, importing GTIG’s IoCs/YARA, and tightening developer workflows will cut real risk now.

Sources / bibliography

Google GTIG — “DPRK Adopts EtherHiding” (IoCs, chain details, YARA). (Google Clo u d)
Google GTIG — “UNC5142 Leverages EtherHiding” (CLEARSHORT, WordPress, fake updates). (Google Cloud)
Palo Alto Networks Unit 42 — Contagious Interview (BeaverTail & InvisibleFerret evolution). (Unit 42)
Guardio Labs — EtherHiding original write-up (technique background). (guard.io)
MITRE ATT&CK — T1102.001 Dead Drop Resolver (conceptual mapping). (MITRE ATT&CK)