Shai-Hulud adlı infostealer solucan varyantı, geliştirici ortamlarından CI/CD araçlarına, bulut yapılandırmalarından yapay zekâ araçlarının ayar dosyalarına kadar uzanan 469 farklı konumda kimlik bilgisi arayacak şekilde genişledi. Daha önce 189 yolu kontrol eden varyantla kıyaslandığında bu artış, saldırganların artık güven ilişkilerini kırmaya çalışmak yerine o ilişkileri ayakta tutan kimlik bilgilerini hedef aldığını gösteriyor.
Yazılım tedarik zinciri uzun süredir güven üzerine kurulu. Geliştiriciler paket depolarına, kurumlar bakımcılara, CI/CD sistemleri kendilerine verilen kimlik ve yetkilere, uygulamalar ise derleme sırasında çekilen bağımlılıklara güveniyor. Shai-Hulud ailesindeki saldırılar da tam bu noktayı kullanıyor: Saldırganlar, zinciri oluşturan güven bağlarını değil, o zinciri çalıştıran kalıcı yetkileri ele geçirmeye odaklanıyor.
İncelemeye göre bu tür kampanyalarda bulunan bir token, geliştirici iş istasyonundan kaynak koda açılan kapı olabiliyor. Aynı kod içinde yer alan bulut kimlik bilgileri altyapıya erişim sağlıyor, bir GitHub token’ı ek depolarda yazma yetkisi verebiliyor, paket yayımlama bilgileri ise saldırganın geliştiricilerin zaten güvendiği kanaldan zararlı sürüm dağıtmasına imkân tanıyabiliyor. Böylece tek bir ele geçirilmiş ortam, bir sonraki ortama geçiş noktası hâline geliyor.
Modern geliştirici ortamları yalnızca depo içeriğinden ibaret değil. Kimlik bilgileri .env dosyalarında, kabuk geçmişinde, paket yöneticisi yapılandırmalarında, CLI önbelleklerinde, CI/CD tanımlarında ve IDE ayarlarında bulunabiliyor. Son dönemde ekiplerin, yapay zekâ geliştirme araçlarının kullandığı yapılandırma dosyalarında da erişim anahtarlarına rastladığı belirtiliyor. Bu yüzden kimlik bilgisi toplayan zararlı yazılım yazarları arama alanını sürekli genişletiyor; saldırgan önce hangi bilginin en değerli olduğunu bilmeden toplama yapıyor, ardından her birinin hangi sistemi açtığını ayırıyor.
Shai-Hulud’un öne çıkan yönü, çalınan kimlik bilgilerini tedarik zinciri saldırısının devam eden bir ayağına dönüştürmesi. Geliştirici makinesinde bulunan bir token kaynak koda erişim sağlayabilir; o kodun içinde bulut erişim anahtarları yer alabilir; bir paket yayımlama yetkisi ise başka geliştiricilerin ve otomatik derleme sistemlerinin sorgulamadan çekeceği yazılımı saldırganın eliyle dağıtabilir. Bu, bir ortamdan diğerine uzanan yetki zincirinin tamamını hedef alan bir model.
Güvenlik ekipleri genellikle kaynak kontrolü, CI/CD, bulut, uç nokta ve uygulama güvenliğini ayrı başlıklar altında yönetiyor. Kimlik bilgileri ise bu sınırların hepsinden geçiyor. Bir geliştirici tek bir iş gününde GitHub, npm, AWS, Kubernetes, iç API’ler ve derleme altyapısına erişebiliyor; otomasyon hatları da benzer çeşitlilikte yetki taşıyor. Araştırmaya göre geliştirici ortamında unutulan tek bir gizli bilgi, tamamen başka bir sistemin yetkisini temsil edebiliyor.
Bu nedenle tespit edilen sıradan bir “secret” kaydı, tek başına olayın boyutunu anlatmıyor. İlgili kimlik bilgisi geçerli mi, hangi kimliğe bağlı, hangi sistem tarafından kabul ediliyor, hangi yetkileri taşıyor, hangi ortama ulaşıyor ve kim onun düzeltilmesinden sorumlu, bunlar da bilinmeden gerçek risk görülemiyor. Araştırmada vurgulanan nokta şu: secrets detection, tek başına bulgu listesi değil, credential risk management sürecine dönüşmek zorunda.
Her açığa çıkan kimlik bilgisi aynı ağırlıkta değil. Yüz binlerce girdiden oluşan bir liste, yüz binlerce acil olay anlamına gelmiyor. Bazıları çoktan geçersizleşmiş oluyor, bazıları yalnızca geçici geliştirme ortamlarına ulaşıyor. Az bir kısmı ise üretim veritabanlarına, bulut altyapısına, dağıtım sistemlerine ya da paket yayımlama süreçlerine erişim veriyor. Bu yüzden sıralama yapılırken saldırganın ilk olarak neyi seçeceği sorusunun yanıtı esas alınıyor.
Öncelik listesinin başında paket yayımlama anahtarları var. Çünkü bu anahtarlar, çalınan kimlik bilgilerini yazılım dağıtımına çeviriyor ve saldırıyı ileriye taşıyor. Geliştiricilerin bir paketi yayımlamak için kullandığı token, diğer geliştiricilerin, derleme sistemlerinin ve kurumların otomatik olarak tükettiği güvenilir kanal üzerinde yetki anlamına geliyor. Bu yüzden ekiplerin, kalıcı yayımlama kimlik bilgilerine bağımlılığı azaltması gerektiği belirtiliyor.
Yayımlama yetkisinin uzun ömürlü token’larla yürütülmesi yerine kısa ömürlü, kimlik doğrulamalı mekanizmalara geçilmesi öneriliyor. OpenID Connect tabanlı güvenilir yayımlama, bunun örneklerinden biri olarak gösteriliyor. Docker ve GitHub Actions tarafında yapılan son güncellemelerin de daha güçlü kimlik doğrulama ve trusted publishing kullanımını öne çıkardığı ifade ediliyor. Hâlâ yerinde duran kalıcı yayımlama kimlik bilgileri ise yüksek hassasiyetli altyapı bileşeni gibi ele alınıyor.
Burada asıl mesele yalnızca deponun korunması değil. Paket deposu ve bağımlılık güvenliği önemli olsa da, infostealer solucanların başarılı olabilmesi için gereken esas unsur kimlik katmanında yatıyor. Yani sorun, saldırganın neyi indirebildiğinden çok, neyi yayımlayabildiği ve hangi yetkiyi tekrar kullanabildiğiyle ilgili. Araştırma, reusable authority ifadesiyle anlatılan bu kalıcı yetkiyi, saldırganların aradığı ortak payda olarak öne çıkarıyor.
İkinci öncelik, üretim ortamlarına erişim veren kimlik bilgilerini kaldırmak. Paket yayımlama yolunun kesilmesi yayılımı durduruyor ama sızıntıyı bitirmiyor. Üretim bulut hesapları, müşteri verisi barındıran veritabanları, imzalama altyapısı, Kubernetes kümeleri, dağıtım araçları ve yönetim panelleri gibi kritik sistemlere erişim sağlayan bilgilerin de aynı hızla ele alınması gerekiyor. Araştırmada, iyi bir kısa listenin bu başlıklardan oluşabileceği belirtiliyor.
Kimlik bilgisinin hangi amaçla kullanıldığı da önemini belirliyor. Geliştirme için açılmış izole bir ortamda geçerli bir token sınırlı zarar doğurabilirken, üretim altyapısında yazma yetkisi veren bir anahtar çok daha farklı bir olay yaratıyor. Bu yüzden gerçek etki alanını anlamak için, saldırganın çalıntı erişimle ne yapabileceği sorusunun yanıtı aranıyor.
Paylaşılan kimlik bilgileri ortamlar arasındaki sınırları da bulanıklaştırıyor. Staging’de bulunan bir secret, hâlâ production’a karşı geçerli olabiliyor. Geliştiricinin yerel makinesine kopyalanmış bir token, otomasyon için ayrılmış yetkileri koruyabiliyor. Aynı kimlik bilgisi, orijinal amacı unutulmuş olsa bile birden fazla sistemde görünmeye devam edebiliyor. Bu yüzden bulgunun kendisi tek başına yeterli olmuyor; kimlik, yetki, kaynak, ortam ve sahiplik bilgilerinin birlikte eşleştirilmesi gerekiyor.
Yayımlanan incelemede üçüncü aşama olarak, geriye kalan tüm açık kimlik bilgilerinin risk sırasına göre düzenlenmesi isteniyor. Amaç, her şeyi rastgele döndürmek değil; saldırganın yoluna en faydalı yetkileri sürekli olarak azaltmak. Geçerli bir kimlik bilgisi, süresi dolmuş ya da iptal edilmiş olandan daha acil görülmeli. Ancak geçerlilik tek başına yeterli değil; paylaşılan geliştirme servislerine açılan bir anahtar ile üretim bulut hesabında yönetici yetkisi veren bir anahtar aynı öncelikte değerlendirilmiyor.
Bu noktada bağlam listesi genişliyor: Kimlik bilgisi hâlâ geçerli mi, production, staging ya da development ortamına mı ulaşıyor, hangi kimliği temsil ediyor, bu kimlik hangi yetkilere sahip, hangi kaynaklara erişebiliyor, başka nerede kullanılıyor ve kim revokasyon ya da rotasyondan sorumlu. Araştırma, denetlenebilir yanıtlar olmadan ortaya çıkan secrets listesinin müdahale planına dönüşemeyeceğini aktarıyor.
Shai-Hulud’un bu yeni dalgası, tek seferlik bir temizlik işi gibi ele alınmıyor. Geliştiriciler yazılım üretmeye devam ettikçe, servisler birbirine bağlandıkça, pipeline’lar evrildikçe ve yeni araçlar ortama girdikçe kimlik bilgileri de birikmeye devam ediyor. Bu yüzden yanıtın, görünürlük, tespit, düzeltme ve önleme adımlarından oluşan tekrarlanabilir bir döngüye dönüşmesi gerektiği vurgulanıyor.
İlk adım, elde ne olduğunun kapsamlı bir envantere dökülmesi. Yalnızca kaynak kodu ve Git geçmişi değil, CI/CD sistemleri ile geliştirici ortamları da bu envantere dahil edilmeli. Tespit aşamasında sorulması gereken soru açık: Kalıcı yetki şu anda nerede duruyor? Bu sayımın, vault dışında kalan secrets oranını da göstermesi gerekiyor; çünkü yalnızca kasadaki kayıtları bilmek, açıkta duran ve unutulmuş kimlik bilgilerini görünmez bırakıyor.
Ardından risk sıralaması geliyor. Paket yayımlama kimlik bilgileri ve geçerli üretim erişimleri listenin başına konuyor. Geri kalan kayıtlar ise geçerlilik, ortam, kimlik, yetki, sahiplik ve ek bağlamlara göre sıralanıyor. Böylece müdahale süreci, kontrolsüz bir bekleme kuyruğu olmaktan çıkıp yönetilebilir bir iş akışına dönüşüyor.
Son aşama, aynı yetki katmanının yeniden oluşmasını engellemek. Yeni hardcoded secret’ların önüne geçmek, mümkün olan yerlerde kısa ömürlü kimlik bilgilerine geçmek, geliştirici ortamlarındaki kimlikleri korumak ve yeni sızıntıyı daha büyük bir temizlik işine dönüşmeden yakalamak bu çerçevede sayılıyor. Araştırma, detection, remediation ve prevention adımlarının tek seferlik müdahale değil, sürekli işleyen bir süreç olarak ele alınması gerektiğini söylüyor.
İncelemenin vardığı son nokta, bir sonraki Shai-Hulud varyantının büyük olasılıkla 469’dan da geniş bir yüzey tarayacağı yönünde. Saldırganlar, modern yazılım ortamlarının tekrar kullanılabilir yetkilerle dolu olduğunu gördükleri için arama alanını büyütmeye devam edecek. Bu nedenle mücadele, yeni solucanın nerelere bakacağını ezberlemekten değil, kalıcı yetkiyi ortadan kaldırmaktan geçiyor.
Kimlik katmanı artık ayrı bir güvenlik problemi olarak ele alınıyor: Kalıcı yetkinin nerede bulunduğunu tespit etmek, en yüksek riskli kimlik bilgilerini düzeltmek ve aynı sızıntının yeniden birikmesini engellemek. Analizde çizilen hedef de net: Her yeni solucan ortaya çıktığında, kötüye kullanılabilecek daha az anahtar bulması.