Rust crates.io Supply-Chain Attack — arrayref / internment / append-only-vec

On 2026-08-20 an attacker compromised or impersonated crates.io maintainer accounts to poison three widely used Rust crates — arrayref (245M all-time downloads), internment, and append-only-vec — with a single new build-time dependency, proc-macro1, a typosquat of the legitimate proc-macro2. The attacker's objective was pure build-time remote code execution: proc-macro1's build.rs runs automatically the moment Cargo compiles it, before any application code executes, so simply running cargo build or cargo update against a resolved lockfile was enough to detonate the payload on a developer workstation or CI runner. The dropper reconstructs a payload URL from base64 fragments, disables TLS certificate validation, fetches a platform-specific second-stage binary from a Hostwinds VPS, and executes it detached so the build finishes clean and green.

The attacker weaponized Cargo's own safety feature against defenders: seconds after publishing the poisoned arrayref 0.3.10, the same account yanked every other recent version in a scripted burst, so the only fix for the resulting "yanked version" warning was to upgrade into the one remaining, malicious release. The Rust Security Response Team pulled the malicious versions and six attacker-owned crates within 86–107 minutes of publication and has since restored the clean, un-yanked versions — but the exposure window means any host that resolved the poisoned versions during that window must be treated as compromised, not just have its dependency updated. Wiz Research further found infrastructure overlap (shared C2 beacon path, shared TLS certificate issuer, and a shared IP also seen in the axios npm compromise) with campaigns Microsoft and Mandiant have separately attributed to DPRK/Sapphire Sleet-linked actors — presented here as attributed infrastructure overlap, not confirmed attribution to a named actor.

The best defensive angle for this class of attack is not patching the crate — there is no CVE and no vulnerable version to fix, only a compromised one to detect — it is catching the moment of detonation: an unexpected process spawned by the Rust build toolchain, and outbound network traffic from a build process to infrastructure it has no reason to contact. Both are squarely inside CrowdStrike Falcon's process-creation and network-connection telemetry, which is why this pack leads with process-lineage and egress hunts rather than static IOC matching alone.

Defender priority: Assume any host that ran cargo build/cargo update between 07:11–09:25 UTC on 2026-08-20 and resolved arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9, or any version of proc-macro1/proc-macro-en is compromised. Run the cache/lockfile sweep in Section 7 first — deletion from crates.io does not clean local or CI caches, and a deleted registry version produces no cargo audit finding at all.

Seven sources were fetched and saved verbatim to the pack's source-snapshot directory for provenance tracing. All seven were reviewed for prompt-injection or untrusted directives before use; none were found, and no source was dropped.

Note on a source discrepancy: Wiz's initial published capability analysis stated browser credentials were stolen; Wiz issued an in-line correction stating the backdoor only enumerates saved logins via the browsers' SQLite stores and does not decrypt or exfiltrate the encrypted credential material itself. This pack uses the corrected claim throughout (see Section 6, T1555.003).

Hunt Hypotheses (ordered by fidelity)

1. [High] The Rust build toolchain (cargo/rustc) spawns the dropped payload or a script interpreter/downloader as a direct child during a build — the moment of detonation. Covers T1195.002. Maps to Q2/Q3.
2. [High] A build process or its child connects to the known C2 IPs or the Hostwinds VPS hostname. Covers T1071.001. Maps to Q4/Q5/Q8.
3. [High] A process image executes from the reported Unix persistence paths (AzureKits/ServiceKit) under a name mimicking a legitimate service (MonoService/MonoXpc). Covers T1543.002, T1036. Maps to Q6.
4. [Medium] Cargo build toolchain spawns a script interpreter or network tool that is not part of a known-good build wrapper — broader behavioral net beyond the exact IOC names. Covers T1195.002, T1059. Maps to Q1.
5. [Medium] A new Registry Run-key entry references the dropper's temp-path naming convention or persistence binary names. Covers T1547.001. Maps to Q7.
6. [Medium — non-CQL] A developer or CI checkout's Cargo.lock/registry cache resolved a poisoned crate version or an attacker-owned crate name, independent of whether the build ever ran. Covers T1195.002. Maps to Section 7 native hunts.
7. [Medium — non-CQL] A host carries an unrecognized systemd user service, LaunchAgent, or scheduled task installed during or after the exposure window. Covers T1543.001, T1543.002, T1053. Maps to Section 7 native hunts.
8. [Low-Medium] A process reads from a Chrome/Brave/Edge profile's saved-login SQLite store outside the browser's own process — proxy signal for the credential-enumeration behavior Wiz documented. Covers T1555.003. Maps to Section 7 native hunts (limited native Falcon telemetry for this behavior — see Section 5 gap).

Attack Chain

These checks cover surfaces Falcon does not natively tag with a dedicated event (Section 5 gaps) or that are faster to run directly against the filesystem/registry than to wait on telemetry ingestion. Run them alongside the CQL queries in Section 8, not instead of them.

Cargo cache & lockfile sweep (all platforms — run per host or fleet-wide via RTR/EDR script deployment)

# Local / CI cargo registry cache — Linux, macOS, WSL
find ~/.cargo/registry/cache -type f \( \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

# Windows equivalent (PowerShell)
Get-ChildItem -Path "$env:USERPROFILE\.cargo\registry\cache" -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -match '^(arrayref-0\.3\.10|internment-0\.8\.7|append-only-vec-0\.1\.9|proc-macro1-.*|proc-macro-en-.*|aovine-.*|arone-.*|aronenao-.*|tinymember-.*)\.crate$' }

# Lockfile / manifest sweep across repo checkouts — resolved version matters, Cargo.toml pins do NOT protect you
grep -rEn 'proc-macro1|proc-macro-en|aovine|arone|aronenao|tinymember|arrayref.*0\.3\.10|internment.*0\.8\.7|append-only-vec.*0\.1\.9' \
  --include=Cargo.lock --include=Cargo.toml .

macOS LaunchAgent audit

launchctl list | grep -viE 'com\.apple\.|com\.microsoft\.|com\.google\.|com\.docker\.'
find ~/Library/LaunchAgents /Library/LaunchAgents -type f -newermt '2026-08-20 07:00:00'

Linux systemd user-service audit

systemctl --user list-units --type=service --all
find ~/.config/systemd/user -type f -newermt '2026-08-20 07:00:00'
# Cross-reference any unrecognized unit against $HOME/.config/AzureKits and $HOME/.config/ServiceKit

Windows Run-key & temp-directory audit

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' | Format-List
Get-ChildItem -Path $env:TEMP -Filter 'rust-setup*' -ErrorAction SilentlyContinue
Get-ChildItem -Path $env:TEMP -Filter '*-launch.vbs' -ErrorAction SilentlyContinue

CI/CD build-log audit

Search CI logs (GitHub Actions, GitLab CI, Jenkins, self-hosted runners) for jobs that executed cargo build, cargo update, or a fresh cargo build with no committed lockfile between 07:11 and 09:25 UTC on 2026-08-20. For any match, pull the runner's egress logs and check for connections to the C2 IPs/domain in Section 4 — ephemeral runners destroyed after the job still exfiltrated whatever secrets that job's environment held, so treat every affected job's accessible secrets as compromised regardless of runner lifetime.

Promote the exact-IOC, low-FP queries to real-time Custom IOA rules. Keep the behavioral/joined queries as scheduled hunt searches — IOAs evaluate single-event patterns and can't express the Q5 join, and Q1/Q7 need a human FP review pass before they're safe to run unattended.

Q1 (behavioral child-process hunt) and Q7 (Run-key naming pattern) stay Investigate-only until FP-tuned against your fleet's known build wrappers and update agents. Q5 (joined network+process query) stays a scheduled search — Falcon's real-time IOA engine does not evaluate cross-event joins.

This is a build-time supply-chain compromise, not a patchable vulnerability — there is no fixed version of arrayref to upgrade to, only a compromised release window to detect and contain. Hardening here targets the mechanism (unvetted build-time dependency execution), the delivery trick (yank-driven forced upgrades), and the downstream techniques (script-host persistence, C2 egress).

Playbook 1 — Pin clean crate versions and purge poisoned caches (all platforms)

Prerequisites: repo write access; ability to trigger a clean CI rebuild; the Section 7 cache-sweep script available on all developer/CI hosts.
Reboot required: No.
Rollback: Remove the explicit "=" version pins once the Rust Security Response Team's un-yanked, clean versions are confirmed safe to track normally again (they already are as of the official advisory) -- rollback is simply reverting the Cargo.toml diff.

1. In Cargo.toml, pin: arrayref = "=0.3.9", internment = "=0.8.6", append-only-vec = "=0.1.8" (only where these crates are actually used).
2. Run: cargo update -p arrayref --precise 0.3.9 (repeat for internment/append-only-vec) to force Cargo.lock to the clean, resolved versions.
3. Run the Section 7 cache-sweep `find` command on every developer machine and CI cache; delete any matching .crate file.
4. Purge CI cache entries (e.g. actions/cache keys) that could hold a warm poisoned cache.
5. Trigger a clean CI rebuild from the purged state; confirm the build succeeds and Cargo.lock shows only the pinned clean versions.
6. Re-run the lockfile grep sweep across all repos; zero hits is the exit criterion.

Playbook 2 — Egress block on the reported C2 infrastructure (network/firewall)

Prerequisites: firewall/proxy admin access covering the network segment(s) developer and CI build hosts sit on.
Reboot required: No.
Rollback: Remove the three /32 block rules and the /23 monitor rule; no endpoint state is changed by this control.

1. Add outbound deny rules (all ports) for 23.254.165.112, 23.254.167.107, 23.254.167.216.
2. Add an outbound alert-only rule (not a hard block, to avoid collateral impact on unrelated Hostwinds-hosted services) for 23.254.164.0/23.
3. Add a DNS-layer block/sinkhole for hwsrv-798836.hostwindsdns.com at your resolver.
4. Validate: attempt a test connection from an isolated lab host to 23.254.165.112:9089 -- confirm it fails closed.
5. Confirm no legitimate business traffic traversed the /23 in the alert-only rule's logs before considering a hard block on the full range.

Playbook 3 — cargo-vet / cargo-audit CI gate (near-term hardening)

Prerequisites: CI pipeline write access; Rust toolchain available in the CI image; `cargo install cargo-vet cargo-audit` run once to seed the tooling.
Reboot required: No.
Rollback: Remove the added CI step(s); no change to the codebase itself beyond the checked-in vet/audit config, which can be deleted.

1. Run `cargo vet init` in the repo root to generate the initial audits.toml / imports.lock.
2. Add a CI step: `cargo audit` -- fails the build on any known-vulnerable or yanked dependency.
3. Add a CI step: `cargo vet check` -- fails the build on any unvetted new dependency, including build-dependencies.
4. Require `cargo build --locked` (not bare `cargo build`) in every CI job so a fresh resolve can never silently pull an unvetted version.
5. Add branch protection requiring the vet/audit CI checks to pass before merge.
6. Validate: open a test PR adding a throwaway unvetted crate as a build-dependency; confirm the CI gate fails it.

Three gaps are structural, not a query-writing shortfall: T1027 (source-level obfuscation) and T1568.002 (unregistered DGA domains) have no endpoint telemetry to hunt against by definition. T1555.003 (browser store enumeration) and the macOS/Linux persistence-creation events are genuine Falcon data-model gaps documented in Section 5 — covered today only by the native, non-CQL checks in Section 7. All four validation gates in Section 11 apply to every query above before any is promoted from Investigate to alerting.

Verbatim source snapshots saved to Arrayref-RustCrate-SupplyChain-Hunt-sources/ for provenance verification of every atomic IOC in Section 10.