Drei kompromittierte Rust-Crates verteilen während der Kompilierung Malware

Drei schädliche Releases von crates.io entfernt

Das Rust-Projekt hat drei kompromittierte Versionen weit verbreiteter Crates von crates.io entfernt: arrayref 0.3.10, internment 0.8.7 und append-only-vec 0.1.9.

Die Releases wurden am 20. August 2026 vom selben Besitzerkonto veröffentlicht und waren zwischen 86 und 107 Minuten verfügbar:

• arrayref 0.3.10: von 07:15:00Z bis 08:41:40Z;
• internment 0.8.7: von 07:34:07Z bis 09:04:11Z;
• append-only-vec 0.1.9: von 07:37:49Z bis 09:25:24Z.

Das Rust Security Response Team erhielt die erste Meldung um 07:15 UTC, nachdem ein schädliches Crate namens proc-macro1 entdeckt worden war. Der Name imitiert das legitime proc-macro2 – ein Typosquatting-Verfahren, das in Dependency-Manifests unauffällig bleiben soll.

Als kompromittiert gelten außerdem proc-macro1, proc-macro-en, aovine, arone, aronenao und tinymember, jeweils unabhängig von der Version.

Es wurde keine CVE-Kennung vergeben. Die RustSec-Advisories enthalten keine Hinweise auf eine tatsächliche Nutzung der schädlichen Versionen. Ebenso ist nicht angegeben, ob der Vorfall im CISA-Katalog KEV aufgeführt ist.

Der Angriff begann mit einem gewöhnlichen Cargo-Build

Der Angriff erforderte nicht die Nutzung einer bestimmten Funktion der kompromittierten Crates. Es genügte, cargo build, cargo check oder cargo test für ein Projekt auszuführen, das die manipulierte Dependency auflöste.

Das Manifest der Releases enthielt eine zusätzliche Zeile, um proc-macro1 einzubinden. Das gefälschte Crate enthielt den authentischen Quellcode von proc-macro2, sodass es sich scheinbar normal verhielt. Die schädliche Komponente war ein Build-Skript, das während der Kompilierung automatisch ausgeführt wurde.

Das Skript setzte die Adresse des Command-and-Control-Servers sowie die Download-Adresse für die Payload aus Base64-kodierten Fragmenten zusammen. Außerdem installierte es einen eigenen TLS-Validator, dessen drei Validierungsfunktionen stets ein positives Ergebnis zurückgaben. Dadurch wurde die Zertifikatsprüfung praktisch deaktiviert.

Anschließend wählte der Code anhand des Betriebssystems und der Prozessorarchitektur eine von vier Payloads aus. Unter Unix und macOS wurde die Datei nach /tmp/rust-setup geschrieben, ausführbar gemacht und im Hintergrund gestartet; die C2-Adresse wurde als erstes Argument übergeben.

Unter Windows wurden zwei Dateien im temporären Benutzerverzeichnis erstellt:

• %TEMP%\rust-setup.ps1;
• %TEMP%\rust-setup-launch.vbs.

Die zweite Datei wurde über wscript.exe im versteckten Modus ausgeführt. Anschließend wurde der Kindprozess vom Cargo-Jobobjekt getrennt, sodass der Build nicht auf dessen Beendigung warten musste.

Das Ergebnis war eine in die Build-Phase integrierte Angriffskette, noch bevor die Anwendung ausgeführt wird. Das unterscheidet sie grundlegend von Malware, die erst durch das Laufzeitverhalten eines Programms aktiviert wird.

Das Entfernen früherer Versionen erleichterte die Verbreitung

Die Veröffentlichung von arrayref 0.3.10 wurde in derselben Minute vom Zurückziehen der legitimen Versionen 0.3.5 bis 0.3.9 begleitet. Dadurch war das schädliche Release die einzige verfügbare Version innerhalb der kompatiblen Versionsreihe.

Cargo verwendet für viele Dependencies Caret-Versionierungsbereiche. Eine Vorgabe wie arrayref ^0.3.6 akzeptiert daher alle kompatiblen Versionen der Reihe 0.3.x, einschließlich 0.3.10. Der GitHub-Forscher jhobern berichtete, dass er durch genau diesen Mechanismus auf den Angriff gestoßen sei.

Das potenzielle Ausmaß von arrayref ist erheblich. Eine am 21. August 2026 über die crates.io-API durchgeführte Prüfung ergab:

• 245.385.500 Downloads insgesamt;
• 53.905.601 Downloads in den 90 Tagen bis zum 20. August;
• 403 unterschiedliche Crates, die es als Dependency angaben.

Zu den Dependency-Ketten gehört winit, das sctk-adwaita ^0.10.1 benötigt. Dieses hängt von tiny-skia ^0.11 ab, das wiederum arrayref ^0.3.6 verlangt.

Auch blake3 war bis Version 1.8.6 von arrayref abhängig, nicht jedoch von 1.8.7, das um 09:09 UTC veröffentlicht wurde. Die Projekte blake2b_simd und blake2s_simd entfernten die Dependency in Releases, die um 09:25 beziehungsweise 09:26 UTC veröffentlicht wurden.

Wie das Konto kompromittiert wurde, ist unbekannt. Der legitime Besitzer von arrayref ist der crates.io-Nutzer 2402, David Roundy, der im Oktober 2009 registriert wurde. Das Rust-Team hält eine Kompromittierung des Computers oder der Zugangsdaten für wahrscheinlich und keine absichtliche Handlung des Autors.

Die Payload installierte Persistenz und stahl Browserdaten

Laut der Analyse von Wiz kommunizierte die nächste Stage über HTTPS-POST-Anfragen an den Pfad /49890878. Die Malware konnte betriebssystemspezifische Persistenzmechanismen installieren:

• einen Registry-Run-Schlüssel unter Windows;
• einen LaunchAgent unter macOS;
• einen Benutzerdienst von systemd unter Linux.

Die Komponente unterstützte vier Befeh Kategorien: Beenden, Ändern des C2-Servers, Installieren der Persistenz sowie Herunterladen und Ausführen weiterer Skripte.

Wiz beobachtete außerdem den Diebstahl von Zugangsdaten aus den SQLite-Datenbanken von Chrome, Brave und Edge. Die Nextron-Analyse der Windows-Payload stellte jedoch nur das Auslesen der Felder origin_url und username_value fest, ohne direkte Extraktion von password_value.

Die Linux- und macOS-Payloads lagen nur als Hashes vor und wurden nicht analysiert. Daher lassen sich die beim Windows-Sample beobachteten Erkenntnisse nicht automatisch auf die beiden anderen Betriebssysteme übertragen.

Die Attribution bleibt offen. Wiz meldete infrastrukturelle Überschneidungen mit früheren nordkoreanischen Supply-Chain-Kampagnen, darunter die Kompromittierungen von Mastra npm und axios. Microsoft ordnete die Mastra-Operation Sapphire Sleet zu, während GTIG den axios-Vorfall MIDNIGHT NEPTUNE, zuvor als UNC1069 bezeichnet, zuschrieb.

Kein Anbieter hat diese crates.io-Kampagne jedoch einer bestimmten Gruppe zugeordnet.

Was Entwickler überprüfen sollten

Das Rust Security Response Team entfernte die schädlichen Releases und hob deren bisherigen Yank-Status zur Bearbeitung des Vorfalls auf. Für arrayref wird empfohlen, bei Version 0.3.9 oder früher zu bleiben. Für keine der drei kompromittierten Versionen gibt es ein bereinigtes Release.

Entwickler sollten:

1. in ~/.cargo/registry/cache nach den entfernten Paketen suchen;
2. Projekte überprüfen, die mit cargo build, cargo check oder cargo test kompiliert wurden;
3. nach Verbindungen zu den bekannten Indikatoren suchen;
4. temporäre Dateien und Persistenzmechanismen überprüfen;
5. Zugangsdaten rotieren, die möglicherweise auf den betroffenen Systemen verwendet wurden.

Zu den Netzwerkindikatoren gehören:

• 23.254.165.112:9089, Payload-Server;
• 23.254.165.112:443, C2-Infrastruktur;
• hwsrv-798836.hostwindsdns.com.

Zu suchende Dateinamen sind /tmp/rust-setup, %TEMP%\rust-setup.ps1 und %TEMP%\rust-setup-launch.vbs. Als Binärdateien wurden rust-crate_0.1.0, _0.2.0, _0.3.0 und _0.4.0 genannt.

Außerdem sollten die Metadaten zu den Konten dtolney, das als Impersonator identifiziert wurde, und droundy, das dem legitimen Besitzer zugeordnet ist, untersucht werden. Ebenfalls gemeldet wurde die Adresse [email protected].

Der Fall ist für arrayref durch die Advisory RUSTSEC-2026-0260 dokumentiert. Cargo verfügt weiterhin über kein standardmäßiges Wartefenster für neu veröffentlichte Dependencies. Ein Vorschlag zur Stabilisierung von global-min-publish-age war am 21. August 2026 noch offen.

Der Vorfall verdeutlicht das Risiko automatisch aktualisierter Dependencies und insbesondere von Skripten, die während der Kompilierung ausgeführt werden. In einem früheren Fall im September 2025 aktivierten zwei schädliche Crates den Code erst zur Laufzeit. Hier lag der Einstiegspunkt dagegen im Build-Prozess – einer Phase, die in der Software-Lieferkette häufig als vertrauenswürdiger gilt.