ArrayRef Saldırısı: Rust'ta proc-macro1 Arka Kapısı

20 Ağustos 2026'da crates.io üzerinde yayımlanan zararlı arrayref@0.3.10, internment@0.8.7 ve append-only-vec@0.1.9 sürümleri, typosquatting ile hazırlanmış proc-macro1 bağımlılığı üzerinden derleme sırasında uzaktan payload indirip çalıştırdı. Projeyi çalıştırmak gerekmiyordu. Etkilenen bağımlılık ağacında cargo build, cargo check, CI derlemesi veya bazı IDE işlemlerinin yürütülmesi saldırı zincirini başlatmak için yeterliydi.

Rust Security Response Team zararlı sürümleri sildi, meşru paketlerin kötü niyetle yank edilmiş eski sürümlerini yeniden erişilebilir hale getirdi ve ilgili yayıncı hesabını kilitledi. Resmî değerlendirme, arrayref yazarının saldırgan olduğu yönünde değil; bakımcının bilgisayarının veya yayın kimlik bilgilerinin ele geçirilmiş olmasının muhtemel olduğu yönünde.

Bu yazı, Rust Security Response Team'in resmî duyurusunu ve bağımsız güvenlik araştırma ekiplerinin kamuya açık teknik bulgularını birlikte değerlendirir. Amaç zararlı kodu yeniden üretmek değil, maruziyeti güvenilir biçimde tespit etmek ve doğru olay müdahalesi kararını vermektir.

Kısa cevap: ArrayRef saldırısında ne oldu?

Saldırgan, uzun süredir kullanılan üç meşru Rust paketinin yeni sürümlerini yayımladı. Bu sürümlere, popüler ve meşru proc-macro2 paketini taklit eden proc-macro1 adlı yeni bir bağımlılık eklendi. proc-macro1@1.0.107 içindeki build.rs, işletim sistemi ve mimariye uygun ikinci aşama dosyayı uzaktaki altyapıdan indiriyor ve Cargo derlemesi devam ederken çalıştırıyordu.

Saldırı zinciri beş adımda özetlenebilir:

1. Rust ekibinin değerlendirmesine göre bakımcının bilgisayarı veya yayın kimlik bilgileri muhtemelen ele geçirildi.
2. Meşru paketlerin eski sürümleri yank edilerek kullanıcılar güncellemeye yönlendirildi.
3. Zararlı yeni sürümler proc-macro1 bağımlılığıyla yayımlandı.
4. Cargo, proc-macro1 paketinin build.rs betiğini derleme sırasında otomatik çalıştırdı.
5. Betik platforma özel ikinci aşamayı indirip geliştirici bilgisayarında veya CI runner üzerinde başlattı.

Buradaki güvenlik dersi yalnızca typosquatting değildir. Asıl risk, meşru ve yaygın bir üst paketin güven zincirinin ele geçirilmesiyle yeni bir geçişli bağımlılığın sessizce yürütme yetkisi kazanmasıdır.

Etkilenen paketler ve maruziyet penceresi

Rust Security Response Team tarafından yayımlanan zamanlar aşağıdaki gibidir:

Paket	Zararlı sürüm	Yayımlanma zamanı	Silinme zamanı	Çevrimiçi süre
arrayref	0.3.10	20 Ağustos 2026 07:15 UTC	08:41:40 UTC	86 dakika
internment	0.8.7	20 Ağustos 2026 07:34:07 UTC	09:04:11 UTC	90 dakika
append-only-vec	0.1.9	20 Ağustos 2026 07:37:49 UTC	09:25:24 UTC	107 dakika
proc-macro1	1.0.107	20 Ağustos 2026 07:11 UTC	Rust ekibi tarafından silindi	açıklanmadı

İlk topluluk bildirimlerine göre proc-macro1@1.0.106, meşru proc-macro2 kodunun temiz bir kopyasıydı ve muhtemel bir hazırlık yayınıydı; uzaktan payload çalıştıran zararlı build.rs, 1.0.107 sürümündeydi. Rust ekibi yine de saldırgan kontrollü proc-macro1 paketinin tüm sürümlerini kaldırdı.

Rust ekibi ayrıca proc-macro-en, aovine, arone, aronenao ve tinymember adlı saldırgan kontrollü veya benzer görünümlü paketlerin tüm sürümlerini kaldırdı. Bağımsız araştırma ekiplerinin analizine göre bunların hepsi aynı zararlı davranışı göstermiyordu. Örneğin bazıları yalnızca hazırlık veya yürütme testi izleri taşıyordu. Buna rağmen aynı olay kümesinin parçası oldukları için bağımlılık ve cache kontrollerinde birlikte aranmalılar.

Kısa yayın penceresi riski önemsizleştirmiyor. arrayref, Rust ekosisteminde çok geniş bir geçişli bağımlılık ağına sahip; yaklaşık 245 milyon yaşam boyu indirme sayısı raporlandı ve bağımsız telemetri çalışmaları paketi gözlemlenen ortamların yüzde 35'inden fazlasında ve Rust bulunan ortamların yaklaşık dörtte üçünde gördüğünü belirtiyor. Bu oranlar farklı veri kümelerine dayanıyor; doğrudan etkilenmiş sistem sayısı olarak okunmamalı. Gerçek maruziyet, zararlı sürümlerin çevrimiçi olduğu sırada lockfile çözen veya cache'e bu sürümleri indiren ortamlarla sınırlı.

Saldırının teknik zinciri nasıl çalıştı?

1. Meşru paketlere yeni bir geçişli bağımlılık eklendi

Zararlı sürümlerde dikkat çeken değişiklik, Cargo.toml dosyasına eklenen şu bağımlılıktı:

[dependencies]
proc-macro1 = "1.0.107"

Bağımsız araştırmacılar, bunun arrayref paketinin yaklaşık on yıllık geçmişindeki ilk bağımlılık olduğunu vurguluyor. Bu, olgun ve küçük bir pakette önemli bir davranış değişikliğiydi. proc-macro1 adı, 154 milyondan fazla indirilen meşru proc-macro2 paketine görsel olarak benziyordu. Paket metadata'sı da meşru proje ve geliştiriciyle ilişki varmış izlenimi verecek şekilde taklit edilmişti.

2. Zararlı davranış kütüphane kodunda değil build.rs içindeydi

proc-macro1 kaynak ağacının büyük kısmı meşru proc-macro2 kodunun yeniden adlandırılmış bir kopyasıydı. Bu sayede paket normal derleniyor ve beklenen işlevleri sağlıyor gibi görünüyordu. Saldırganın eklediği yürütme zinciri, Cargo'nun otomatik çalıştırdığı build.rs dosyasına ve ağ erişimi için eklenen ureq, rustls ve base64 build bağımlılıklarına gizlenmişti.

Rust build script'leri yalnızca paket kurulumunda değil, cargo build, cargo check ve benzeri işlemlerde çalışabilir. CI sistemleri ve rust-analyzer kaynaklı kontroller de aynı güven sınırına yaklaşabilir. Dolayısıyla "uygulamayı hiç çalıştırmadık" ifadesi, bu olay için güvenli olunduğunu göstermez.

3. C2 adresi parçalandı ve TLS doğrulaması etkisizleştirildi

İlk aşama betiği indirme adresini Base64 parçalarından çalışma anında birleştiriyordu. Topluluk incelemeleri, defang edilmiş biçimiyle 23[.]254[.]165[.]112:9089 adresinin payload dağıtımı için, aynı IP üzerindeki 443 portunun ise sonraki C2 iletişimi için kullanıldığını doğruladı.

Betik özel bir sertifika doğrulayıcısı kullanarak TLS sertifika kontrollerini kabul edecek şekilde etkisizleştiriyordu. Böylece saldırganın geçersiz, eşleşmeyen veya kendinden imzalı sertifika kullanması indirme işlemini durdurmuyordu.

4. İşletim sistemine göre ikinci aşama seçildi

İlk aşama aşağıdaki hedefleri destekliyordu:

Hedef	İndirilen dosya ailesi	Bırakılan konum
Linux x86_64	rust-crate_0.1.0	/tmp/rust-setup
Windows x86_64	rust-crate_0.2.0	%TEMP%\rust-setup.ps1
macOS x86_64	rust-crate_0.3.0	/tmp/rust-setup
macOS aarch64	rust-crate_0.4.0	/tmp/rust-setup

Unix sistemlerde dosya çalıştırılabilir hale getirilip standart giriş ve çıkıştan ayrılmış biçimde başlatılıyordu. Windows zinciri ise Cargo'nun alt süreçleri bekleme davranışından kaçmak ve görünür pencere oluşturmamak için bir VBS başlatıcısı üzerinden PowerShell çalıştırıyordu. Paket derlemesi normal tamamlandığı için geliştiricinin yalnızca build sonucuna bakarak saldırıyı fark etmesi zordu.

İkinci aşama ne yapabiliyordu?

Kaynaklar arasındaki önemli zamanlama farkı burada ortaya çıkıyor. Bir araştırma ekibi, analiz anında uzak sunucu yanıt vermediği için ikinci aşama payload'ı elde edemediğini açıkça belirtti. Başka bir ekip, tehdit istihbaratı örnekleri üzerinden ulaştığı implantları daha sonra ayrıntılı analiz etti. Bu iki bulgu birbiriyle çelişmiyor; farklı zamanlarda ve farklı örnek erişimiyle yapılan incelemeleri yansıtıyor.

İncelenen implant şu yeteneklere sahipti:

• Hostname, kullanıcı adı, işletim sistemi ve kurulu uygulama bilgilerini toplama.
• Chrome, Brave ve Edge profillerindeki kayıtlı girişleri ve eklenti ayarlarını listeleme.
• HTTPS POST üzerinden C2'ye beacon gönderme.
• Windows Registry Run anahtarı, macOS LaunchAgent veya Linux systemd kullanıcı servisiyle kalıcılık kurma.
• C2 yapılandırmasını değiştirme, süreci sonlandırma ve uzaktan PowerShell veya shell script'i çalıştırma.
• Ana C2 ulaşılamadığında belirli aralıklarla algoritmik .com alan adları üretme.

Ayrıca ilk yayındaki tarayıcı parolalarının doğrudan çalındığı ifadesi sonradan düzeltildi. İncelenen sorgular kayıtlı girişleri listeliyor, ancak şifrelenmiş credential materyalini doğrudan çekmiyordu. Yine de etkilenen host üzerinde uzaktan komut çalıştırma ve credential erişim yolları bulunduğu için olay müdahalesinde tarayıcı oturumları ile kaydedilmiş hesaplar risk kapsamında tutulmalı.

DPRK bağlantısı ne kadar kesin?

Bağımsız araştırmacılar, ArrayRef kampanyasının altyapısında daha önce Kuzey Kore bağlantılı faaliyetlerle ilişkilendirilen operasyonlarla anlamlı örtüşmeler raporladı:

• Aynı /49890878 C2 endpoint kalıbının Microsoft'un DPRK/Sapphire Sleet ile ilişkilendirdiği Mastra npm kampanyasında kullanılması.
• İlişkili IP altyapısında ortak SSL issuer izleri.
• Bir kurbanın bildirdiği 23.254.167[.]216 trafiğinin, Mandiant'ın Kuzey Kore ile ilişkilendirdiği Axios npm saldırısı analizindeki altyapıyla örtüşmesi.
• Hostwinds üzerinde aynı veya yakın ağ bloklarının tekrar kullanılması.

Bu göstergeler güçlü bir operasyonel benzerlik sunuyor, ancak tek başına nihai aktör kimliği kanıtı değildir. Rust Security Response Team resmî duyurusunda aktör atfı yapmadı. Bu nedenle doğru ifade, saldırının DPRK bağlantılı kampanyalarla önemli altyapı ve davranış örtüşmesi gösterdiği, fakat kamuya açık bulguların tek başına kesin atıf için yeterli olmadığıdır.

Sisteminiz etkilendi mi?

İlk kontrol noktası Cargo.lock, vendored bağımlılıklar ve yerel Cargo cache'idir. Aşağıdaki komut, Rust ekibinin resmî duyurusundaki paket adlarını yerel cache içinde arar:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.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

Repo düzeyinde hızlı bir ilk tarama için:

rg -n 'name = "(arrayref|internment|append-only-vec|proc-macro1|proc-macro-en|aovine|arone|aronenao|tinymember)"|version = "(0\.3\.10|0\.8\.7|0\.1\.9|1\.0\.107)"' \
  --glob 'Cargo.lock' --glob 'Cargo.toml' --glob '*.json' .

Bu kontrollerin yorumu dikkatli yapılmalı:

• Zararlı bir .crate dosyasının cache'te bulunması, dosyanın kesinlikle çalıştırıldığını tek başına kanıtlamaz.
• Zararlı sürümün Cargo.lock içinde bulunması ve aynı ortamda Cargo işlemi çalıştırılması, host compromise varsayımı için yeterince güçlüdür.
• Cache temizliği olay müdahalesi değildir. Önce delil, süreç geçmişi, ağ kayıtları ve secret erişim kapsamı korunmalı.
• Saldırı penceresinde oluşturulan build artefact'ları temiz kaynaklardan ve temiz runner'larda yeniden üretilmeli.

IOC ve avcılık özeti

Aşağıdaki göstergeler bağımsız güvenlik araştırma ekipleri tarafından kamuya açık olarak raporlandı. Ağ göstergeleri güvenli gösterim için defang edilmiştir.

Tür	Gösterge	Açıklama
Paket	arrayref@0.3.10	Ele geçirilmiş yayın
Paket	internment@0.8.7	Ele geçirilmiş yayın
Paket	append-only-vec@0.1.9	Ele geçirilmiş yayın
Paket	proc-macro1@1.0.107	Zararlı build.rs taşıyıcısı
Ağ	23[.]254[.]165[.]112:9089	İlk aşama payload dağıtımı
Ağ	23[.]254[.]165[.]112:443	İkinci aşamaya aktarılan C2
Dosya	/tmp/rust-setup	Linux/macOS bırakma yolu
Dosya	%TEMP%\rust-setup.ps1	Windows bırakma yolu
Dosya	%TEMP%\rust-setup-launch.vbs	Windows başlatıcısı
SHA-256	25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae	arrayref@0.3.10
SHA-256	61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4	proc-macro1@1.0.107

IOC eşleşmesi bulunmaması tek başına temiz sistem kanıtı değildir. İkinci aşama uzaktan script çalıştırabildiği için son durum farklı dosya adları, süreçler veya kalıcılık mekanizmaları içerebilir. EDR telemetry, DNS/proxy kayıtları, process tree, Cargo işlem zamanları, CI job logları ve secret kullanım logları birlikte incelenmeli.

Olay müdahalesi: eşleşme bulursanız ne yapmalısınız?

1. Etkilenen host'u izole edin

Zararlı lockfile ile Cargo çalıştırıldığı doğrulanıyorsa geliştirici bilgisayarını veya CI runner'ı tam host compromise olarak ele alın. Ağ izolasyonu yapın; fakat volatile delilleri ve merkezi log akışını kaybetmeyecek bir prosedür izleyin.

2. Kimlik bilgilerini yalnızca değiştirmeyin, iptal edin

Etkilenen ortamdan erişilebilen GitHub/GitLab token'ları, bulut anahtarları, package registry kimlikleri, SSH anahtarları, code-signing anahtarları, deployment secret'ları ve tarayıcı oturumları için revoke ve rotate işlemi uygulayın. Yeni secret'ları şüpheli host üzerinde üretmeyin veya kullanmayın.

3. Kalıcılık mekanizmalarını araştırın

Windows'ta kullanıcı Run anahtarlarını ve şüpheli script başlatıcılarını, macOS'ta LaunchAgent kayıtlarını, Linux'ta systemd kullanıcı servislerini inceleyin. Yalnızca bilinen rust-setup dosyasını silmek yeterli değildir; ikinci aşamanın çalıştırdığı ek komutların izi araştırılmalı.

4. Lockfile ve artefact zincirini temiz kaynaktan yenileyin

Bilinen temiz sürümler arrayref@0.3.9, internment@0.8.6 ve append-only-vec@0.1.8 olarak raporlandı. Zararlı sürümler crates.io'dan silindikten sonraki güvenilir metadata ile lockfile'ları yeniden oluşturun. Olay penceresinde üretilmiş ikili dosyaları, container image'larını ve release paketlerini temiz runner üzerinde yeniden derleyin ve yeniden imzalayın.

5. CI/CD ve yayın hesaplarını ayrı kapsam olarak inceleyin

Bir CI runner etkilenmişse yalnızca o job'ın secret'larını değil, runner'ın erişebildiği organization, environment, artifact store ve deployment yüzeyini inceleyin. Build sistemleri genellikle production'a doğrudan geçiş sağlayan en değerli kimlikleri taşır.

Eresus Security'nin olay müdahale ve kaynak kod analizi çalışmaları, bağımlılık ağacındaki bulguyu host, secret ve release etkisiyle birlikte doğrulamaya odaklanır.

Bu saldırıdan sonra Rust ve CI/CD ekipleri neyi değiştirmeli?

Yeni bağımlılıkları diff seviyesinde kapılayın

Olgun bir paketin ilk kez yeni bağımlılık eklemesi, özellikle build aşamasında ağ erişimi sağlayan paketler getiriyorsa otomatik güvenlik incelemesi başlatmalı. Sadece paket adına değil build.rs, build-dependencies, yayıncı değişimi, yanked sürümler ve metadata farklarına bakılmalı.

Lockfile güncellemelerini kontrollü değişiklik olarak yönetin

Lockfile yenileme işlemini sıradan bakım olarak görmeyin. Dependency bot PR'larında doğrudan ve geçişli bağımlılık farklarını görünür hale getirin, yeni build script'lerini işaretleyin ve henüz olgunlaşmamış sürümler için bekleme politikası uygulayın.

Build ortamında ağ ve secret erişimini azaltın

Derleme işlemleri mümkün olduğunca geçici, izole ve minimum secret ile çalışan runner'larda yapılmalı. Dependency derleme aşamasının internete sınırsız çıkışı engellenmeli; gereken registry ve mirror hedefleri allowlist ile sınırlandırılmalı. İmzalama anahtarları normal build adımında erişilebilir olmamalı.

Paket kaynağı ve artefact doğrulamasını birlikte uygulayın

Checksum doğrulaması, zararlı sürüm ilk kez güvenilir registry'den çözüldüğünde tek başına koruma sağlamaz; yalnızca indirilen içeriğin lockfile'daki içerikle aynı olduğunu gösterir. İç mirror, paket karantinası, minimum yayın yaşı, davranış analizi, SBOM ve provenance kontrolleri birlikte kullanılmalı.

Bu yaklaşım, daha önce analiz ettiğimiz Axios npm tedarik zinciri saldırısındaki install-time risklerle aynı temel güvenlik sorusuna dayanır: üçüncü parti kod, geliştirme ve release ortamında hangi anda yürütme yetkisi kazanıyor?

Sık sorulan sorular

Yalnızca cargo build çalıştırmak sistemi etkiler mi?

Evet. Zararlı davranış build.rs içinde olduğu için uygulamanın kendisini çalıştırmanız gerekmiyordu. Etkilenen dependency graph çözüldükten sonra cargo build, cargo check, CI derlemesi veya aynı build script'ini tetikleyen araçlar payload yürütmesine yol açabilirdi.

Zararlı sürüm cache'te varsa kesinlikle ele geçirildim mi?

Hayır. Cache eşleşmesi indirme veya depolama kanıtıdır, yürütme kanıtı değildir. Ancak ilgili lockfile ile Cargo işlemi çalıştıysa ortamı ele geçirilmiş kabul etmek ve olay müdahalesi başlatmak en güvenli yaklaşımdır.

arrayref bakımcısı saldırının parçası mıydı?

Kamuya açık resmî bulgular bunu göstermiyor. Rust Security Response Team, bakımcının kötü niyetli olduğuna inanmadığını; bilgisayarının veya kimlik bilgilerinin ele geçirilmiş olmasının muhtemel olduğunu belirtti.

Saldırı kesin olarak Kuzey Kore'ye mi ait?

Hayır, kamuya açık veriler kesin atıf sağlamıyor. Bağımsız araştırmacılar; Mastra ve Axios kampanyalarıyla C2 endpoint, IP/hosting ve sertifika altyapısı düzeyinde önemli örtüşmeler raporladı. Bu, DPRK bağlantısını destekleyen güçlü bir değerlendirmedir; resmî Rust duyurusu ise aktör atfı yapmamıştır.

Sonuç

ArrayRef olayı, küçük ve yıllardır güvenilen bir kütüphanenin tek başına "güvenli" kabul edilemeyeceğini gösterdi. Saldırganlar meşru üst paketlerin yayın yetkisini, typosquat edilmiş geçişli bağımlılığı ve Cargo'nun build script yürütme modelini aynı zincirde birleştirdi. Sonuç, yalnızca bir dependency uyarısı değil; geliştirici bilgisayarları, CI runner'ları, secret'lar ve release artefact'larını kapsayan bir olay müdahalesi problemidir.

En önemli operasyonel karar şudur: zararlı sürümle Cargo çalıştırıldığı doğrulanıyorsa yalnızca paketi düşürmeyin. Host'u, kimlikleri ve o ortamda üretilen tüm artefact'ları güven sınırının dışında kabul edin; temiz altyapıda yeniden oluşturun.

Kaynaklar

• Rust Security Response Team — Supply chain attack on arrayref