Web3 Supply Chain Attacks Target Enterprise Cloud Credentials

Key takeaways

• Ephemeral Cloud Credentials as Primary Targets: Threat actors use compromised open-source packages to extract short-lived IAM keys, CI/CD worker tokens, and OIDC federation keys directly from developer workstations and build runners.
• Three Architectural Phases of Web3 C2: Command-and-control resolution has progressed from querying smart contract state (EtherHiding) to reading transaction calldata (TxDataHiding), and ultimately to zero-data mathematical extraction from wallet recipient addresses (NullReceiver).
• Total Data Minimization with NullReceiver: By encoding IPv4 addresses within the 20-byte recipient field of zero-value, zero-calldata blockchain transactions, attackers bypass static code scanners and deep packet inspection.
• State-Sponsored Operationalization: North Korea-linked actors (Alluring Pisces / Sapphire Sleet) systematically target core software ecosystems, executing intrusions across Axios, Mastra AI, and Rust’s arrayref crate.
• Shifting to Behavioral Defenses: Static IoC blocklists fail against decentralized C2; enterprise security teams must inspect endpoint process contexts, restrict outbound JSON-RPC calls, and enforce strict CI/CD runner egress policies.

Threat actors are weaponizing open-source software dependencies and decentralized Web3 architectures to conduct cloud supply chain attacks that bypass traditional perimeter defenses. According to threat research published by Palo Alto Networks Unit 42 on October 7, 2026, adversaries—most notably North Korea-linked state-sponsored actors—are embedding malicious loaders into package ecosystems including npm, Go modules, and Packagist. Instead of relying on static command-and-control (C2) domains or IP addresses that security filters quickly sinkhole, attackers resolve dynamic infrastructure through public blockchain smart contracts and zero-data transaction records. These compromises target developer workstations and continuous integration pipelines to harvest ephemeral cloud credentials, bypassing conventional authentication perimeters.

Cloud credentials in the crosshairs: Dependencies as the initial access vector

The operational objective of software supply chain campaigns has shifted decisively toward cloud credential harvesting. Rather than using compromised packages for broad adware distribution or basic coin mining, modern campaigns treat developer workstations and automated continuous integration and continuous deployment (CI/CD) runners as high-value initial access vectors. According to findings in the Unit 42 threat research report, software supply chain compromises have become a leading initial access mechanism targeting corporate cloud environments.

Developer environments represent an exceptionally privileged attack surface holding active cloud sessions, unencrypted environment variables, and cached configuration tokens. When build scripts resolve poisoned upstream dependencies, malicious code executes within this trusted context, allowing attackers to harvest:

• Ephemeral cloud provider identity keys: Short-lived Identity and Access Management (IAM) credentials generated for local command-line operations across AWS, Google Cloud, and Microsoft Azure.
• CI/CD pipeline worker tokens: Automated tokens granting write permissions to container registries, source code repositories, and artifact stores.
• OIDC federation keys: Short-lived OpenID Connect tokens that grant automated runners permission to provision production cloud infrastructure.
• Local secrets and signing keys: Developer environment variables, SSH credentials, and code-signing certificates stored in memory or on local disks.

Because these extracted credentials reflect authenticated sessions, threat actors interface directly with cloud management consoles and administrative APIs. When organizations rely solely on initial multi-factor authentication (MFA) prompts at login without continuous session validation, harvested tokens grant immediate administrative access. Addressing this risk requires a structured strategy for managing enterprise open-source software dependencies across the development lifecycle.

The three-phase architectural evolution of Web3 command and control

Software supply chain compromises face a structural hurdle: public registries are actively monitored by automated scanners. Hard-coding conventional domain names or static IP addresses into a package manifest guarantees rapid discovery, domain sinkholing, and package revocation. To circumvent this vulnerability, adversaries have transitioned to decentralized public blockchains to host and resolve C2 infrastructure across three distinct architectural phases.

Architectural evolution of decentralized Web3 command-and-control mechanisms

Architectural Phase	Resolution Mechanism	On-Chain Footprint	Detection and Evasion Profile
Phase 1: EtherHiding	Read-only JSON-RPC calls (eth_call) querying smart contract state variables	Static smart contract address deployed on a public blockchain	Bypasses DNS sinkholing; vulnerable to blocking outbound RPC traffic directed at the contract address
Phase 2: TxDataHiding	Parsing transaction calldata (eth_getTransactionByHash) from recent wallet transactions	Encrypted payloads stored in raw transaction input fields (0x...)	Decouples resolution from fixed contract state; enables cross-chain fallback across TRON, Aptos, and BNB Chain
Phase 3: NullReceiver	Mathematical extraction of IPv4 address octets directly from the 20-byte recipient address	Zero-value, zero-data transaction broadcast to an actor-controlled wallet	Total data minimization; contains no smart contract code, executable payloads, or readable domain strings

Phase 1: EtherHiding and smart contract state storage. Emerging in late 2024 supply chain campaigns targeting npm, Phase 1 deployed dedicated smart contracts to public blockchains. Malware loaders executed read-only JSON-RPC calls (eth_call) to query contract state variables returning encrypted C2 domain strings. While this bypassed DNS reputation filters by routing traffic through legitimate RPC gateways, it retained a critical bottleneck: outbound JSON-RPC requests exposed the target contract address in the "to" parameter, allowing defenders to block queries directed at that address.

Phase 2: Cross-chain transaction data hiding (TxDataHiding). To eliminate the single point of failure in querying a fixed contract, threat actors shifted toward TxDataHiding. Instead of relying on permanent contract getters, operators embed encrypted C2 configurations directly into raw transaction calldata. Loaders query transaction logs (eth_getTransactionByHash) to retrieve the latest transaction associated with an actor-controlled wallet and decrypt the calldata in memory. In campaigns like PolinRider, actors implement multi-chain fallbacks across TRON, Aptos, and Binance Smart Chain (BSC). If defenders filter RPC traffic on one chain, the malware falls back to secondary networks, updating global C2 endpoints without altering client code.

Phase 3: Zero-data address resolution (NullReceiver). Identified in compromises targeting front-end UI packages like bianira-ui and fluid-type-ui, NullReceiver achieves total data minimization by eliminating smart contracts, calldata, and on-chain payloads entirely. The loader queries a public blockchain gateway for the latest outbound transaction from an actor-controlled wallet. The transaction carries zero financial value and zero input data. The loader parses the 20-byte recipient address, verifies an embedded ASCII validation marker, and mathematically converts the leading four bytes into decimal octets representing the active C2 IPv4 address. Because the transaction contains no payload or domain strings, static filters find nothing anomalous to inspect.

State-sponsored execution: From self-propagating worms to ecosystem poisoning

The weaponization of Web3 infrastructure is actively operationalized by sophisticated threat groups. Telemetry links these decentralized C2 patterns to both opportunistic malware authors and North Korea-affiliated state-sponsored groups known as Alluring Pisces (also tracked as Sapphire Sleet and Midnight Neptune).

The ChainDrop npm worm. Traced to the Shai-Hulud malware family, ChainDrop infected over 400 npm packages, including keyv and cacheable-request. The attack used lifecycle hooks in package.json manifests to download a custom Bun runtime, scrape ephemeral cloud credentials and OIDC keys from running build memory, query smart contracts via EtherHiding for exfiltration endpoints, and inject persistent workspace tasks that execute during subsequent coding sessions.

Get the Weekly Brief

Curated analysis for tech leaders. Every Thursday.

Subscribe

The PolinRider campaign. While ChainDrop prioritized rapid propagation, PolinRider demonstrated cross-ecosystem persistence across npm, Go modules, and Packagist. Attackers planted loaders within developer IDE workspace automation files and repository templates. When developers opened projects in Visual Studio Code, background tasks triggered quietly. PolinRider deployed a hybrid architecture combining multi-chain lookups across TRON, Aptos, and BSC with NullReceiver zero-data resolution, maintaining connectivity if primary RPC gateways were filtered.

Targeted intrusions across Axios, Mastra AI, and arrayref. State-sponsored actors have systematically expanded across developer communities:

• The Axios compromise: Adversaries compromised a lead maintainer account for axios, injecting a backdoored dependency (plain-crypto-js) into the manifest to harvest cloud credentials and target macOS code-signing certificates.
• Mastra AI framework poisoning: Threat actors targeted AI development workflows by publishing poisoned npm packages that scraped environment variables, LLM API tokens, and cloud identity credentials from AI pipelines.
• Rust ecosystem expansion (arrayref): Expanding beyond JavaScript, the threat actor poisoned the arrayref crate on Crates.io, using Rust native compilation hooks (build.rs) to execute secondary payloads directly during application builds.

Shared cryptographic beacon structures, SSL configurations, and clustered hosting ranges across these intrusions demonstrate an integrated strategy aimed at securing scalable footholds inside corporate cloud environments.

Operational trade-offs: Decentralized resilience versus enterprise observability

For adversaries, Web3-based C2 architectures provide notable survivability benefits over traditional Web 2.0 infrastructure, while introducing operational constraints that defenders can exploit.

The primary advantage for attackers is immutability. Public blockchains are distributed across thousands of independent nodes globally. Traditional incident response tactics—such as registrar domain takedowns, DNS sinkholing, and hosting provider IP null-routing—cannot alter or delete confirmed on-chain transactions. Updating an entire distributed implant network requires broadcasting only a single new transaction. However, this model introduces three significant constraints:

• Public ledger transparency: Every transaction broadcast to a public blockchain is permanently recorded. Once defenders identify an attacker wallet or contract address, the full historical transaction record and associated C2 updates become permanently visible for forensic analysis.
• RPC gateway dependencies: Implants on restricted corporate networks cannot operate full blockchain nodes; they rely on HTTP-based JSON-RPC gateways (such as Infura, Alchemy, or public node endpoints) to read ledger state, generating observable HTTP and TLS traffic streams.
• On-chain transaction costs: Broadcasting updates across public chains incurs gas fees, requiring threat actors to fund operational wallets with cryptocurrency and creating potential attribution trails through blockchain intelligence.

Defensive strategies for enterprise IT and platform engineering teams

Defending enterprise environments against decentralized supply chain threats requires moving beyond static Indicator of Compromise (IoC) lists. When attackers extract dynamic C2 endpoints from public ledgers, blocking specific IP addresses or domain names is insufficient. Enterprise security teams and platform engineers must implement behavioral, process-contextual, and pipeline-level controls.

1. Domain context evaluation and JSON-RPC filtering: Evaluate whether business operations require outbound blockchain connectivity. For standard enterprise SaaS, financial services, or healthcare applications, outbound calls to public blockchain RPC gateways represent an immediate anomaly. Security teams should catalog common public RPC endpoints across major blockchains, block outbound connections from non-crypto subnets, and inspect HTTP request bodies for methods like eth_call and eth_getTransactionByHash.
2. Process-level endpoint and memory monitoring: Because supply chain loaders conceal themselves inside developer runtimes and package installation processes, endpoint detection and response (EDR) solutions must monitor process context. Security policies should flag when non-crypto developer utilities—such as node, bun, cargo, go, or python—initiate outbound network connections toward cryptocurrency infrastructure or public blockchain gateways. Memory inspection controls should also monitor running compilation jobs for unauthorized credential scanning.
3. CI/CD pipeline integrity and identity governance: Replace long-lived cloud service account keys with short-lived OpenID Connect (OIDC) federated identity tokens configured with minimal role permissions and strict time-to-live limits. Enforce strict egress network filtering on automated build agents, restricting dependency resolution to verified internal artifact proxies and blocking arbitrary internet egress. Configure package managers to ignore unverified installation hooks (npm install --ignore-scripts), and implement automated branch protection rules and configuration audits to detect unauthorized alterations to IDE configuration files and workflow manifests.

Bottom line

The weaponization of Web3 infrastructure marks an architectural shift in software supply chain attacks. By transitioning from static command-and-control infrastructure to decentralized blockchains, threat actors have neutralized traditional domain sinkholing and perimeter blocklists. The objective of these campaigns is clear: infiltrate developer environments and continuous deployment pipelines to harvest high-privilege cloud identity tokens and service credentials.

For enterprise IT leaders and security architects, mitigating this threat demands moving beyond reactive signature matching. By establishing baseline controls on developer network traffic, blocking unauthorized blockchain RPC communications, hardening CI/CD runner egress, and enforcing identity governance on ephemeral cloud credentials, organizations can disrupt the attack chain before decentralized implants achieve persistent cloud administrative access.

Sources

• Palo Alto Networks Unit 42: Evolution of Web3 in Cloud Supply Chain Attacks
• Unit 42 Global Incident Response Report
• Amazon Threat Intelligence: Open-Source Software Supply Chain Findings
• Microsoft Security Threat Intelligence: Open-Source Ecosystem Tracking
• Rust Security Advisory: Crate Ecosystem Integrity