Rust Can't Save You Either: A Deep Dive into Cargo Supply Chain Attacks

Memory Safety Doesn't Solve Supply Chain Problems

"Can rewriting this in Rust fix it?" — that question is almost as old as programming itself. Many developers believe that once Rust is part of their build pipeline, the risk of getting hacked or broken will simply disappear. In this video, the Low Level channel delivers a sobering answer: Rust does solve memory safety, but it's powerless against supply chain attacks.

On August 20th of this year, a malicious version (0.3.10) of the popular Rust crate RayRef surfaced. The package itself is lightweight yet powerful — it lets you extract a slice from an array while knowing the slice's length at compile time, providing compile-time safety checks for Rust programs. According to the video's author, it had roughly 254 million downloads at the time of recording, illustrating just how wide the blast radius could be.

The irony is rich: a library specifically designed for compile-time safety checks became the entry point for a compile-time backdoor. This perfectly illustrates the core argument — language-level security (memory safety) and ecosystem-level security (dependency trust) are two entirely different battlefields.

Breaking Down the Attack Chain: From Typosquatting to Compile-Time Backdoors

The technique used in the malicious RayRef version isn't sophisticated, but it's textbook. It injected a malicious dependency called ProcMacro1 into its dependency list — an obvious typosquatting attempt on the legitimate package ProcMacro2. ProcMacro2 itself is just a wrapper around ProcMacro, and the chaotic naming conventions in the Rust ecosystem make this kind of impersonation easier to pull off.

The real payload was hidden inside ProcMacro1's build.rs script. The build.rs file is a build script that runs when you execute cargo build, functioning similarly to the notorious postinstall hook in the NPM ecosystem. The video author makes a critical point: simply placing malicious code inside a package isn't enough — it has to go into build.rs to guarantee execution at build time. Cargo traverses the dependency tree all the way down and executes each build.rs from the bottom up.

The backdoor's execution logic follows standard malware patterns:

• Assembles a URL from Base64 fragments, hiding the real address inside encoded data to bypass scanners and firewall detection
• Appears to disable TLS certificate validation via custom exception rules, circumventing malicious CAs used for traffic interception in enterprise environments
• Downloads an OS-specific payload (Mac / Windows / etc.), writes it to the /Temp directory, and executes it

Once running, the payload primarily performs reconnaissance: capturing hostname, username, OS details, a list of installed applications, and reading Chrome, Brave, and Edge profiles to query their SQLite credential stores.

Typosquatting is a classic supply chain attack technique where attackers register package names nearly identical to popular ones, exploiting developer typos or carelessness. In the NPM ecosystem, crossenv targeting cross-env and 1odash targeting lodash are well-known historical examples. These attacks work because package managers don't prompt "Did you mean to install XXX?" — they simply fetch whatever matches the name exactly. Cargo has no additional protection against this. Package names on crates.io are first-come-first-served, and anyone can register a name differing by just one or two characters from a well-known package.

build.rs is a special convention in Cargo's build system: if this file exists in a package's root directory, Cargo compiles and runs it before compiling the package itself, granting it full system access (file I/O, network requests, spawning subprocesses, etc.). This design was originally intended for legitimate use cases like C bindings and code generation, but it also creates a natural arbitrary code execution entry point. Unlike NPM's postinstall script, build.rs re-executes on every cargo build — not just at install time — meaning the window of harm is longer and harder to detect.

The Misreported "Credential Theft"

One detail worth clarifying: security firm Wiz initially reported that browser credentials were stolen, but the video author points out this was a reasonable but inaccurate assumption. What actually happened was that these queries only read saved login metadata — they did not retrieve encrypted credential material.

Modern browsers store credentials in static encrypted form and only retrieve the decryption key from an HSM or passkey at runtime. This attack never completed the decryption step, and the author admits he's uncertain why the attackers chose not to. The attack ultimately achieved persistence via registry keys, using a string ("IMBotKing") for symmetric encryption — a strange choice, since a hardcoded symmetric key is essentially public.

Attribution Fingerprints: Significant Overlap with North Korean Supply Chain Attacks

The most striking aspect of this campaign is its substantial infrastructure overlap with recent supply chain attacks attributed to North Korea (DPRK), including earlier attacks targeting the NPM library Axios.

Typical DPRK tradecraft involves infiltrating companies through malicious job interviews or fake recruitment personas, with the ultimate goal of gaining code execution to mine cryptocurrency — one of the few ways to funnel money into a heavily sanctioned economy.

The author notes that an IP address used in this campaign is identical to one used in the earlier Axios NPM attack. He also fairly presents an alternative explanation: two different attackers could be sharing the same ISP or IP range, or a country with limited IP resources may have reused the same address across two operations. Regardless of interpretation, this connection marks the first time the Cargo ecosystem has been drawn into the orbit of a nation-state-level supply chain attack.

North Korean hacker groups (commonly attributed to Lazarus Group and its sub-clusters) have a multi-year track record of targeting software supply chains. The 2023 3CX supply chain attack, 2021 npm poisoning targeting cryptocurrency developers, and techniques reminiscent of SolarWinds all demonstrate that these state-level actors treat software dependency chains as high-value infiltration vectors. Their core motivation differs from ordinary cybercrime: beyond intelligence gathering, cryptocurrency mining and theft are critical mechanisms for circumventing international sanctions and acquiring foreign currency — with estimates suggesting North Korea extracts hundreds of millions of dollars annually through cyber operations. This explains why attacks so often target developer workstations: developers typically hold high-privilege credentials with access to code repositories, cloud accounts, and internal systems, making them ideal pivot points for "compromise once, spread everywhere" campaigns.

Why Are Cargo Attacks So Rare?

Compared to the NPM ecosystem's notorious worms like Shai-Hulud, supply chain attacks targeting Cargo have been rare. What makes NPM worms so dangerous is their self-propagating nature: after compromising one package, they steal NPM publish tokens from other packages and use them to publish more malicious packages, creating a snowball effect.

The author honestly corrects a misconception from his own earlier blog post. He had originally assumed that each Cargo repository had its own separate credentials file, requiring attackers to know which repositories a target maintained in order to steal the right tokens. The reality: every user has a single unified credentials.toml file in their Cargo Home directory.

This means a worm could theoretically replicate the exact NPM playbook — simply scraping all keys from Cargo Home without needing to know any specific targets. The technical barrier doesn't exist. The author argues that the real reason Cargo attacks are rare is straightforward: there are far fewer Rust developers than JavaScript developers, making the attack surface smaller and the return on investment lower. But he also predicts that any language with a package manager and token-based publishing will eventually face these attacks — Python and NPM have seen it repeatedly, and Rust is starting to catch up.

The credentials.toml file lives in the user's Cargo Home directory (typically ~/.cargo/credentials.toml) and stores API tokens for all logged-in crates.io accounts in plaintext. This closely mirrors how NPM writes tokens to ~/.npmrc — the very mechanism that enables NPM worm lateral propagation. Once an attacker gains execution through build.rs, reading this file takes a single line of code, after which stolen tokens can be used to publish new malicious versions to crates.io, completing viral spread. Currently, crates.io does not require multi-factor authentication (MFA) for publishing — similar to where NPM stood before it mandated MFA at scale in 2022, a move that came only after multiple worm incidents.

How Developers Can Protect Themselves

For those in the Rust ecosystem, the video offers several practical recommendations:

• Audit your dependencies: Check your Cargo.toml and installed packages for these malicious packages; remove them immediately if found
• Rotate credentials: If you suspect compromise, rotate your credentials first. There's no direct evidence of actual credential theft at this point, but undiscovered payloads can't be ruled out
• Clean up persistence: Remove any payloads planted in autorun entries
• Audit build-time dependencies: This is the most actionable tip. If a crate that has no business making network calls contains a dependency like reqwest (Rust's HTTP request library) — especially in build-time dependencies related to build.rs — that's essentially a red flag

The lesson from the RayRef incident is clear: security isn't something you solve by choosing the right language. Memory safety and type safety address the correctness of code itself, while supply chain trust, dependency auditing, and token management are a separate defensive layer that must be built independently. In an era where AI is generating code at scale and dependency graphs keep growing, that defensive layer only becomes more critical.