Rust Supply Chain Attack On Arrayref Significant Overlap With Dprk Campaigns

On August 20, 2026, malicious versions of three Rust crates were published to crates.io: [email protected] , [email protected] , and [email protected] . The malicious crates added a typosquatted dependency ( proc-macro1 ) whose build script downloads and executes a remote binary. Notably, proc-macro1 was the first dependency added to arrayref in its ten-year history.

Because build scripts run during compilation, building an affected project was sufficient to execute the payload. arrayref can be found in over 35% of all environments. Even more notably, it's used in ¾ of all environments where Rust is present.

The Rust Security Response Team deleted the malicious versions and locked the account, and assesses that the maintainer's machine or credentials were compromised .

Wiz customers should review our Threat Intel Center advisory: arrayref and Other Rust Crates Hijacked in Supply Chain Attack

The impacted package versions add a malicious dependency to the Cargo.toml :

proc-macro1 is a typosquat of the legitimate proc-macro2 crate (154M+ downloads). Its build.rs contains the malicious logic. Because Cargo executes build scripts at compile time, building a project that depends on proc-macro1 is sufficient to trigger the payload.

At compile time, the build script:

Reconstructs a C2 URL from Base64 fragments (e.g. )

Disables TLS certificate validation via a custom AcceptAll verifier

Downloads a platform-specific payload based on OS and architecture

Writes it to /tmp/rust-setup (Unix) or %TEMP%\rust-setup.ps1 (Windows)

Executes the payload, passing the C2 beacon address as an argument

The build otherwise completes and the package functions normally. The second stage payload is selected based on the platform, with support for x86_64 versions of Linux, Windows, and macOS, in addition to aarch64 macOS.

Wiz Research was able to analyze the malicious Rust crates, retrieved from Google Threat Intelligence . The implant is a featureful backdoor that:

Beacons to C2 via HTTPS POST (to the endpoint /49890878 ), exfiltrating host info and stolen credentials as Base64-encoded JSON

Collects hostname, username and operating system details, enumerates installed applications, and reads Chrome, Brave and Edge profiles for saved logins and extension settings, querying the browsers' SQLite credential stores directly. Edit: A prior version of this piece mistakenly stated that browser credentials were stolen. The queries only enumerate saved logins, they do not retrieve the encrypted credential material.

Persists via Registry Run key (Windows), LaunchAgent (macOS), or systemd user service (Linux)

Supports four commands: kill (terminate), minicfg (reconfigure C2 and beacon interval), startup (install persistence), and runscript (download and execute PowerShell or shell scripts, synchronously or in background)

Falls back to a Domain Generation Algorithm if the primary C2 is unreachable, generating 10 algorithmic .com domains every 5 days. Currently, the relevant domains do not appear to be registered.

Configuration is encrypted with AES-128-GCM using the hardcoded key i am botking . Commands are authenticated via an embedded RSA-2048 private key.

The arrayref infrastructure substantially overlaps with operations attributed to recent North Korean actors.

Shared C2 endpoint pattern: The arrayref payloads beacon to /49890878 . This endpoint has been used in the Mastra campaign, attributed by Microsoft to DPRK / Sapphire Sleet . The IP address used in the arrayref beacon also shares an SSL issuer ( WIN-A6QF8AHPQH1\Administrator@WIN-A6QF8AHPQH1 ) with 23.254.167[.]13 - also used in the Mastra campaign.

Victim-reported infrastructure overlap: A victim has reported C2 traffic to 23.254.167[.]216 . This IP appears in Google Cloud Threat Intelligence's analysis of UNC1069's axios npm attack , which Mandiant links to North Korea.

Preferred Host: Both campaigns generally use the same 23.254.164.0/23 range of Hostwinds LLC infrastructure we see repeated in this incident.

Wiz customers should review our Threat Intel Center advisory: arrayref and Other Rust Crates Hijacked in Supply Chain Attack .

Check your lockfiles and local cache : Cargo.lock across your repositories for the malicious versions and for any of the six attacker-controlled crate names. Locally, run:

Treat affected hosts as compromised : because the payload executes during cargo build , any developer workstation or CI runner that built an affected project must be treated as compromised. Rotate every credential, token and key reachable from it, including CI secrets and signing keys, and rebuild any artifacts produced after exposure from clean sources.

Rotate browser-stored credentials : the payload reads saved logins and extension data from Chrome, Brave and Edge profiles on the affected host. Reset those passwords and revoke the associated sessions.

Remove payload and persistence artifacts : delete /tmp/rust-setup , %TEMP%\rust-setup.ps1 and %TEMP%\rust-setup-launch.vbs where present, and check for unrecognized systemd user services, HKCU Run entries and LaunchAgents. Re-deploy affected workloads from a known clean state.

Do not resolve yank warnings by upgrading blindly : this attack used yanking to drive upgrades. Treat a sudden yank of multiple stable versions of a long-lived crate as a signal to investigate.

Review build-time dependencies : build scripts execute with full user privileges during compilation. Review any new or changed build-dependencies entry, particularly networking crates such as ureq , reqwest or rustls in a crate with no reason to make network calls.