Die Angreifer setzten auf eine mehrstufige Konstruktion. In der untergeschobenen Abhängigkeit [email protected] versteckten sie die Datei build.rs, ein Build-Skript, das eine plattformspezifische Zweitstufe als Binärdatei über TLS nachladen sollte — allerdings erst, nachdem es die Zertifikatsprüfung deaktiviert hatte.
Neben den drei übernommenen Crates verwiesen auch mehrere vom Angreifer selbst angelegte Pakete auf dieselbe Abhängigkeit: aovine, arone, aronenao und tinymember.
Das Rust Security Response Team beschrieb den Vorgang so: „Eine neue Version der Crate arrayref wurde mit einer direkten Abhängigkeit zu proc-macro1 veröffentlicht, die ein bösartiges Build-Skript ausführen würde." Rund 86 Minuten nach der Veröffentlichung waren die Pakete entfernt.
Zur Rolle des Maintainers äußerte sich das Rust-Sicherheitsteam zurückhaltend: „Wir glauben nicht, dass der Autor von arrayref böswillig handelt, aber sein Rechner oder seine Zugangsdaten sind wahrscheinlich kompromittiert, und wir versuchen, ihn zu erreichen."
Eine Analyse von StepSecurity zeichnet das Vorgehen als sorgfältig geplant nach: Der Angreifer legte die getippsquatteten Varianten von proc-macro2 sowie ein nachahmendes Konto unmittelbar vor der Veröffentlichung der präparierten arrayref-Version an.
Wiz ordnet den Vorfall der nordkoreanischen Gruppe Sapphire Sleet zu, die bereits die NPM-Supply-Chain-Angriffe auf Axios und Mastra im April beziehungsweise Juni zu verantworten hatte. Grundlage der Zuordnung sind erhebliche Überschneidungen in der Infrastruktur.
Konkret nennt Wiz drei Anknüpfungspunkte: Die arrayref-Schadroutinen melden sich bei einem Endpunkt, der schon im Mastra-Angriff genutzt wurde. Command-and-Control-Verkehr floss zu einer IP-Adresse aus der Axios-Kampagne. Und in allen drei Fällen kam derselbe IP-Bereich einer Infrastruktur von Hostwinds LLC zum Einsatz.