Rust Crate Tampering: Multi-Stage Info-Stealer Malware Launched via build.rs

1. Basic Information

• Article Title: ArrayRef Rust Crate Supply Chain Attack
• Publisher: StepSecurity
• Publication Date: 2026-08-20
• Severity: Critical
• Original Source: StepSecurity
• Related Source: Hackers poison ArrayRef Rust crate to push infostealer malware
• Related Malware: proc-macro1 dropper, proc-macro-en dropper
• Threat Actor: None / Unidentified
• CVE: None
• Products & Technologies: arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9, Cargo, crates.io

2. Executive Summary

A supply chain attack that adds malicious dependencies to legitimate crates from compromised developer accounts, launching information-stealing malware during the build process without needing to execute the target code.

Reason for Severity: Widely used legitimate crates and related crates were tampered with in quick succession. Execution happens simply by Cargo resolving dependencies and building. Developer machines and CI/CD credentials are the targets.

3. Attack Flow

Infection During Cargo Build

1. The attacker compromises crate administrator accounts and publishes malicious versions of arrayref, internment, and append-only-vec.
2. While keeping the legitimate code, they add dependencies on typosquatted proc-macro1/proc-macro-en and include a build.rs script.
3. When a developer or CI resolves new dependencies, updates them, and builds, build.rs runs automatically. There is no need to call functions in the target crate.
4. build.rs disables TLS certificate verification to download the next stage and runs it from a temporary folder.
5. On Linux, it establishes persistence in user settings and systemd. On Windows, it runs temporary PowerShell/VBS scripts.
6. The next stage collects credentials from browsers and development environments, then sends them to the attacker.

Luring Users to Malicious Versions

1. For arrayref, the clean version was yanked, and dependency resolution was manipulated to pull the malicious version.
2. Due to deleted versions, local caches, and vendoring states, it is hard to judge safety by normal audit views alone.
3. Cargo.lock files and caches that resolved dependencies during the roughly two-hour public window are the primary targets for investigation.

4. Attacker Position and Execution Location

• Compromised legitimate publisher accounts on crates.io
• Executed as build scripts on developer machines or CI/CD runners
• Credentials collected by the next-stage C2

5. Visibility for Victims and Administrators

Victims and Users

• Developers can get infected just by running normal cargo build/test, even if tests pass.
• Because it happens at the build stage before application execution, source code reviews of usage spots may miss it.

Administrators and SOC

• Specific versions in Cargo.lock, build.rs, proc-macro1/proc-macro-en, scripts in /tmp or %TEMP%, and outbound C2 are clues.
• Even in short-lived CI runners, tokens and cloud credentials passed to that job can be exposed.

6. Success and Failure Conditions

Success Conditions

• New dependencies are resolved/updated and a build is run while the malicious version is public.
• Execution of build.rs and external downloads are allowed.
• Valuable credentials exist on the developer machine/CI.

Failure Conditions

• Cargo.lock or vendoring is locked down, rejecting unauthorized dependency changes.
• Egress from the build environment is restricted, and secrets are job-scoped, short-lived, and least-privilege.
• Malicious caches are deleted, lock files are pinned to safe versions, and machines are rebuilt.

7. What Happens Upon Success

• Theft of secrets, browser credentials, and tokens on developer machines and CI/CD.
• Chain tampering of other packages using stolen publishing permissions.
• Re-execution even after public access ends, due to remaining compromised artifacts or caches.

8. Observable Logs

Email

• Email is not a direct infection vector. Check if there are crate account change or publication notifications.

Proxy / SWG / DNS

• TLS traffic from the build process to unknown IPs/C2.
• Downloads with disabled certificate verification or connections to IPs not normally accessed by developer machines.

Endpoint / EDR

• build.rs, PowerShell, wscript, shell under cargo/rustc, /tmp/rust-setup, %TEMP%\rust-setup.ps1.
• Linux $HOME/.config/AzureKits, ServiceKit, MonoService, MonoXpc, user systemd.

Identity / IdP

• Abnormal logins and publications for crates.io publisher accounts.
• Use of stolen GitHub, cloud, registry, or CI tokens.

SaaS / Cloud

• CI job logs, dependency caches, artifacts, secret references, and cloud API audits.

Network

• Outbound C2 and next-stage downloads during Cargo builds.

9. Determining Attack Success

• Attack Attempt Observed (Success Unconfirmed): Target versions found in Cargo.lock or cache, but build execution is unconfirmed.
• User Action Confirmed: Confirmed that a developer or CI resolved the target version and built it.
• Initial Execution Confirmed: build.rs or next-stage download/temporary script executed under cargo/rustc.
• Malware Execution or Auth Success Confirmed: Execution of next-stage infostealer malware, persistence, or use of stolen tokens confirmed.
• Information Theft or Session Compromise Confirmed: Access to credential files/browser data and outbound transfer confirmed.
• Subsequent Compromise Confirmed: Other repositories, cloud environments, or package publications manipulated using stolen developer/CI credentials.

"Attack Attempt Observed (Success Unconfirmed)" means suspicious requests or packages were identified, but code execution or data theft is not verified. Escalate the phase based on further evidence.

10. Investigation Playbook

Trigger

• arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9 in Cargo.lock.
• Detection of proc-macro1/proc-macro-en or known temporary files/C2.

Initial Check

• Identify the time and host/runner that resolved, fetched, and built the target version.
• Preserve Cargo.lock, registry cache, vendor folder, and CI logs.

Endpoint

• Investigate cargo/rustc child processes, /tmp, %TEMP%, user settings, systemd, and browser/secret file access.

Authentication & Cloud

• List all tokens, SSH keys, cloud credentials, and registry permissions available on the affected job/machine.
• Investigate usage history and rotate credentials.

Subsequent Operations

• Cross-check other builds using the same dependency cache, artifacts, and developer machines.
• Investigate package publications, repository modifications, and CI setting changes.

Containment

• Stop builds, isolate target runners, clear caches, and pin to safe versions.
• Revoke all potentially exposed secrets and rebuild from a trusted environment.

Judgement Categories

• Dependency presence only
• Target version build confirmed
• Dropper execution confirmed
• Credential access/transmission confirmed
• Credential abuse / chain compromise confirmed

11. Defense and Detection Ideas

Single Events

• PowerShell, wscript, curl/wget, or unknown binaries launched under cargo/rustc.
• Direct connection to unknown IPs during the build.

Timeline Correlation

• Dependency resolution -> build.rs -> next-stage download -> temporary execution -> persistence -> secret access -> outbound transmission.

Threat Hunting Perspective

• Search Cargo.lock and caches across all developer machines and CI.
• Suspicious services in user systemd and $HOME/.config.
• Rapid successive releases by the same publisher with clean versions yanked.

Log Gaps

• Dependency resolution history, CI cache history, build-time processes, secret access, and short-lived runner network traffic.

Priority Countermeasures

• Dependency locking/review and reproducible builds.
• CI egress restrictions and short-lived, least-privilege tokens.
• Monitoring of child processes and network activity during builds.
• Phishing-resistant MFA for package publishing accounts.

12. Facts / Inference / Hypothesis

Facts

• Malicious arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9 were published in a short time frame from compromised administrator accounts.
• build.rs runs automatically during the build even without using dependency crate features.
• Malicious versions kept legitimate code, so passing tests did not prove safety.
• TLS certificate verification was disabled when downloading the next stage.
• Environments that resolved target versions during the public window are recommended to be investigated under a compromise assumption.

Inference

• Because packages remain in local/CI caches and vendor folders even after deletion, registry state alone cannot determine safety.
• CI designs that inject secrets broadly have larger impacts.

Hypothesis

• Attackers may chain attacks to other legitimate packages using compromised administrator privileges and stolen tokens.

13. MITRE ATT&CK Mapping

• T1195.001 – Compromise Client Software Binary: Software Dependencies and Development Tools (High Confidence)
• T1059.001 – Command and Scripting Interpreter: PowerShell (High Confidence)
• T1059.004 – Command and Scripting Interpreter: Unix Shell (High Confidence)
• T1105 – Ingress Tool Transfer (High Confidence)
• T1555.003 – Credentials from Password Stores: Credentials from Web Browsers (Medium Confidence)
• T1543.002 – Create or Modify System Process: Systemd Service (Medium Confidence)

14. Unknowns and Additional Investigations

• Initial compromise method for crates.io accounts.
• Total number of actually infected developer machines/CIs.
• Scope of stolen credentials and subsequent compromises.
• All C2 servers/hashes and next-stage capabilities.

15. Impact on SOCs and Organizations

Even companies that do not use Rust directly in products can be affected via third-party vendors, OSS builds, and shared CI infrastructure. Security Operations Centers (SOCs) should monitor network traffic and child processes under build tools, not just executable file distribution.

16. Summary by Target Audience

For SOCs

Cross-examine target crate versions, Cargo.lock, build child processes, C2, and secret usage.

For Administrators

Clear caches, pin to safe versions, and rotate secrets.

For Users

Developers who ran Rust builds during the target period should not delete files on their own, but report their machines to the security team.