> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Evolution of Web3 in Cloud Supply Chain Attacks
- URL: https://f4n6.co.uk/security-feed/evolution-of-web3-in-cloud-supply-chain-attacks/
- Published: 2026-10-08T00:37:16.000Z
- Updated: 2026-10-08T00:37:16.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Unit 42 has published an analysis of how threat actors have moved command-and-control (C2) infrastructure for cloud-focused supply chain malware onto Web3 smart contracts, allowing a botnet or worm network to be re-pointed with a single blockchain transaction rather than a malware rebuild. The report names two campaigns, the ChainDrop npm worm (traced to the Shai-Hulud family, over 400 npm packages including keyv and cacheable-request) and PolinRider (npm, Go modules, Packagist), and attributes related supply chain activity to North Korea-affiliated Alluring Pisces (also tracked as Sapphire Sleet or Midnight Neptune). No CVE, CVSS score, or CISA KEV entry is associated with this item; the exposure is a supply chain and developer-workflow problem, not a patchable product vulnerability. For EMEA financial services the risk sits with any team that resolves open-source dependencies on a workstation or CI/CD runner holding cloud IAM keys, OIDC federation tokens, or deployment secrets, because that is the credential set these campaigns exist to steal. The report is single-sourced vendor research and the Alluring Pisces attribution is not corroborated by the reference data supplied here.

## 2\. Regulatory framing

| Article                                                                 | Trigger (the fact in this item)                                                                                                                                                                                                   | Practical impact                                                                                                                                               |
| ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 28: ICT third-party risk, general principles                  | The attack path runs through open-source dependencies and package registries that the firm consumes but does not control, and the report states supply chain compromise is a leading initial access vector into enterprise cloud. | Third-party risk assessment has to extend to the open-source dependency and CI/CD tooling layer, not just contracted ICT providers.                            |
| DORA Art. 30: key contractual provisions with ICT third-party providers | Credentials harvested from CI/CD runners and build pipelines are the objective, which puts the contractual security terms of the CI/CD and cloud providers in scope.                                                              | Contract reviews should confirm the provider's obligations on build-environment isolation and breach notification for the runner and registry services in use. |
| NIS2 Art. 21(2)(d): supply chain security measures                      | The specific technique is poisoning of open-source dependencies to reach developer endpoints and CI/CD pipelines.                                                                                                                 | Supply chain security measures need to cover dependency resolution and build-runner hardening, not only supplier contracts.                                    |

DORA Art. 17, 18, 19 and 24 and NIS2 Art. 23 are not engaged by this item as written: the source describes a technique and prior campaigns, not an incident at a named entity, so no incident-management, classification, reporting, or resilience-testing trigger is present. If a client confirms compromise of a build pipeline or developer endpoint, Art. 17, 18 and 19 and NIS2 Art. 23 become live at that point.

## 3\. Technical analysis & attack chain

The source is a technique analysis, not an incident report. It describes a shift in C2 tradecraft and two campaigns that use it. The confirmed steps below are those the source states; where it stops short, that is noted.

1. A malicious package is published to a public registry (npm, Go modules, or Packagist) or an existing dependency is poisoned. ChainDrop is described as infecting over 400 npm packages, including keyv and cacheable-request.
2. The package executes on install. ChainDrop uses a preinstall script hook that downloads a custom Bun runtime, which then launches an obfuscated credential harvester.
3. The harvester collects credentials. ChainDrop searches static files on disk and also searches memory inside running build processes, targeting ephemeral cloud provider IAM keys, CI/CD pipeline worker tokens, and short-lived OIDC federation keys. The source states the runner then terminates.
4. Exfiltration endpoints are resolved through Web3 rather than hard-coded infrastructure. ChainDrop uses a technique the source calls EtherHiding: it queries smart contract transactions that contain dynamically encrypted information for the exfiltration IP or domain endpoints. This is the core change the report documents, moving from static C2 endpoints embedded in the binary to smart-contract-driven endpoint resolution that can be updated with a single transaction.
5. Persistence is established on the developer endpoint. ChainDrop injects persistent task hooks that trigger automatic execution whenever a developer opens a project or starts an AI coding session.

PolinRider is described as spanning npm, Go modules, and Packagist, and as concealing malicious loaders in repository configuration files, web resources, and developer IDE workspaces rather than relying strictly on standard package installation scripts. The supplied source text is truncated at that point, so the loader mechanism, persistence, and C2 for PolinRider are not available here and should not be assumed to mirror ChainDrop.

What the source does not provide: no CVE identifiers, no CVSS scores, no CISA KEV entries, no file hashes, no domain or IP indicators, no specific smart contract addresses, and no registry keys or file paths. The report references a 2026 Unit 42 Global Incident Response Report for the claim that software supply chain compromises are a leading initial access vector into enterprise cloud; that underlying report is not in the supplied material, so the claim rests on Unit 42 alone.

Attribution caveat: the source attributes recent supply chain campaigns, including those targeting Axios, Mastra AI, and Rust's arrayref, to North Korea-affiliated Alluring Pisces (aka Sapphire Sleet or Midnight Neptune). No MITRE ATT&CK profile for this actor is present in the verified reference data for this item, so the state-sponsored attribution is unconfirmed here and should be treated as a single-source vendor assessment. The campaign names ChainDrop and PolinRider and the Shai-Hulud family link are likewise single-sourced to Unit 42.

## 4\. Mitigation & containment

P1 (within 24 hours)

- Determine whether Web3 or blockchain network activity is expected anywhere in the estate. If it is not, block outbound traffic to blockchain RPC endpoints and smart contract query services at the egress firewall and in the secure web gateway. This directly breaks the EtherHiding endpoint-resolution step and is the highest-value control in this advisory.
- Inventory CI/CD runners and developer workstations that resolve open-source dependencies and confirm whether they hold cloud IAM keys, pipeline worker tokens, or OIDC federation credentials. Any runner that does is a target for the credential-harvesting behaviour described.
- Search build logs and package manifests for the named packages (keyv, cacheable-request) and for any package version pulled during the ChainDrop window. Where a match is found, treat the runner's credentials as exposed and rotate them.
- Check for unexpected Bun runtime binaries on developer endpoints and build runners. ChainDrop downloads a custom Bun runtime to launch its harvester; a Bun binary appearing on a host that does not legitimately use Bun is a lead.

P2 (within 72 hours)

- Rotate cloud IAM keys, CI/CD worker tokens, and OIDC federation credentials that were present on any runner or workstation where a suspect dependency resolved. Short-lived OIDC tokens expire on their own; long-lived keys and worker tokens do not, so prioritise those.
- Review persistent task hooks on developer endpoints. ChainDrop injects hooks that fire when a project is opened or an AI coding session starts, so audit project-open and IDE-startup automation for entries that were not placed by the team.
- Restrict package installation scripts. Where the toolchain allows it, disable preinstall and postinstall script execution for dependencies, or require explicit approval, since the ChainDrop execution path is a preinstall hook.
- Apply the source's recommendation to automate policy controls across all CI/CD runners and version control systems, so that a runner cannot silently acquire new credentials or new execution hooks.

P3 (within 7 days)

- Extend third-party risk review to the package registries and CI/CD platforms in use, consistent with DORA Art. 28 and Art. 30, covering build-environment isolation and breach notification.
- Add dependency-resolution monitoring to the detection stack so that a new package appearing in a lockfile triggers review rather than silent installation.
- Rehearse the credential-rotation path for build infrastructure. The value of the P2 rotation depends on being able to complete it quickly under pressure.

No vendor patch exists for this item. There is no CVE and no fixed version to pin to; the remediation is architectural and procedural.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The source names packages and campaigns but provides no hashes, domains, IP addresses, URLs, file paths, or registry keys.

The source does describe observable behaviours. These are not atomic indicators and are not suitable for automated blocking, but they are pivotable in logs and EDR telemetry.

### Behavioural indicators

| Behaviour                                                                                                 | Where to observe                                                                           | Confidence               |
| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------ |
| preinstall script hook downloads a Bun runtime during package installation                                | npm install logs, process creation on build runners and developer endpoints                | Single-sourced (Unit 42) |
| Process reads memory of running build processes to extract credentials                                    | EDR memory-access telemetry on CI/CD runners                                               | Single-sourced (Unit 42) |
| Build runner terminates immediately after credential collection                                           | CI/CD job logs, runner lifecycle events                                                    | Single-sourced (Unit 42) |
| Outbound queries to smart contract transactions for endpoint resolution                                   | Egress firewall, DNS, and proxy logs showing blockchain RPC traffic                        | Single-sourced (Unit 42) |
| Persistent task hooks that execute on project open or AI coding session start                             | IDE and project-open automation, scheduled task and startup entries on developer endpoints | Single-sourced (Unit 42) |
| Malicious loaders hidden in repository configuration files, web resources, or IDE workspaces (PolinRider) | Version control diffs, IDE workspace configuration                                         | Single-sourced (Unit 42) |

## 6\. Detection

The source provides no hashes, no command-line flags, no mutex names, and no file paths. The only artefacts specific to the threat are the named npm packages and the Bun runtime download behaviour. A YARA rule built on package names would detect reporting about the threat rather than the threat, so no YARA rule is emitted here.

A Sigma rule is viable for the process and network behaviour the source describes. The rule below matches a package manager spawning a Bun runtime, which is the ChainDrop execution path. Tune the parent process list to the package managers in use.

```yaml
title: Package Manager Spawning Bun Runtime
id: 8f3c1a42-5d7e-4b91-a2c6-0e9f4d1b7c33
status: experimental
description: Detects a package manager or build tool spawning a Bun runtime, consistent with the ChainDrop npm worm preinstall hook that downloads a custom Bun runtime to launch a credential harvester.
author: Adverse Trace
date: 2026-10-08
references:

  - https://unit42.paloaltonetworks.com/web3-cloud-supply-chain-attacks/
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:

      - '/npm'
      - '/node'
      - '/yarn'
      - '/pnpm'
      - '/go'
      - '/composer'
  selection_child:
    Image|endswith:

      - '/bun'
      - '/bunx'
  condition: selection_parent and selection_child
falsepositives:

  - Development teams that legitimately run Bun as their runtime and invoke it from npm scripts
level: medium

```

A second rule covers the network side, matching build tooling making outbound connections to blockchain RPC endpoints. Populate the destination list with the RPC providers in use at the firm; the source does not name any.

```yaml
title: Build Tooling Connecting to Blockchain RPC Endpoint
id: 2b6d9e14-7a3f-4c58-9d21-6f0a8c5e4b77
status: experimental
description: Detects package managers and build runners making outbound connections to blockchain RPC endpoints, consistent with EtherHiding smart contract queries used for C2 endpoint resolution.
author: Adverse Trace
date: 2026-10-08
references:

  - https://unit42.paloaltonetworks.com/web3-cloud-supply-chain-attacks/
logsource:
  category: network_connection
  product: linux
detection:
  selection_process:
    Image|endswith:

      - '/npm'
      - '/node'
      - '/yarn'
      - '/pnpm'
      - '/bun'
      - '/go'
      - '/composer'
  selection_destination:
    DestinationPort:

      - 8545
      - 8546
  condition: selection_process and selection_destination
falsepositives:

  - Teams that develop or test blockchain applications and legitimately query RPC endpoints from build tooling
level: medium

```

## 7\. Sources

- Unit 42 (Palo Alto Networks), "Evolution of Web3 in Cloud Supply Chain Attacks", https://unit42.paloaltonetworks.com/web3-cloud-supply-chain-attacks/, published 2026-10-07.

This is the only source supplied for this item. Every technical claim in this advisory traces to it. The Alluring Pisces attribution, the ChainDrop and PolinRider campaign details, and the reference to the 2026 Unit 42 Global Incident Response Report are single-sourced and have not been independently corroborated.

## 8\. Adverse Trace position

Adverse Trace assesses this as a technique advisory rather than an active incident, and we are not raising a severity rating against a specific CVE because none exists here. The material risk to EMEA financial services clients is concentrated in build infrastructure: any CI/CD runner or developer workstation that resolves open-source dependencies while holding cloud IAM keys, pipeline worker tokens, or OIDC federation credentials is the exact target set these campaigns were built to harvest, and the Web3 C2 change makes takedown of the exfiltration infrastructure materially harder than with static domains. We treat the Alluring Pisces attribution as unconfirmed, since no MITRE profile for that actor appears in the reference data for this item, and we treat the entire report as single-sourced vendor research. We will monitor for corroborating reporting on ChainDrop and PolinRider, for any published indicators that would let us build atomic detection, and for client-side confirmation of build pipeline compromise, which would move this from technique advisory to incident and engage DORA Art. 17, 18 and 19 and NIS2 Art. 23\. Clients who want to check their exposure against the P1 controls above should contact their Adverse Trace handler.

---

[Read the original source →](https://unit42.paloaltonetworks.com/web3-cloud-supply-chain-attacks/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*