Qubole Üzerinden AWS Ortamlarına Girildi: Unutulmuş Satıcı Güveni ve Yapılacaklar

9 Kasım 2026’da Wiz ve Sentra, Mandiant’ın da katıldığı bir soruşturmanın ardından, Qubole adlı veri platformuyla ilişkili bir AWS hesabına ait kimlik bilgileriyle, Qubole müşterilerinin kendi AWS hesaplarında Qubole’ye güvenen rollerin üstlenilip içeriye girildiğini bildirdi. Saldırgan 14–26 Ekim arasında bu rollerle gizli bilgileri okudu ve S3’ten veri indirdi. Bildirilmiş bir yazılım açığı (CVE) yok; Wiz saldırı zincirinde bir AWS açığı da bildirmiyor. Cloud Security Alliance (CSA) bunu şöyle özetliyor: zayıf nokta, güven ilişkisinin kendisiydi. Etkilenen kurumların adı ve toplam sayısı açıklanmadı; Qubole ile ilişkili kimlik bilgilerinin nasıl ele geçirildiği de bilinmiyor.

Kısaca

• Ne oldu: Bir saldırgan, Qubole ile ilişkili bir AWS hesabındaki IAM kullanıcı kimlik bilgilerini kullanarak müşterilerin Qubole için oluşturduğu çapraz hesap rollerini (sts:AssumeRole) üstlendi. Wiz’in gözlemine göre her istek geçerli bir External ID ile yapıldı ve hepsi başarılı oldu.
• Ne zaman: Wiz’in gördüğü ilk faaliyet 14 Ekim 2026, son gözlenen göstergeler 26 Ekim. Wiz ayrıca 8–11 Ekim’de müşterilere ait AWS erişim anahtarlarıyla yapılan, bu faaliyete bağlayamadığı ayrı bir kötüye kullanım da bildirdi.
• Kimler etkilenebilir: Qubole ile entegrasyon kurmuş, hesabında Qubole’nin hesabına güvenen bir IAM rolü bulunan kurumlar. Sentra’nın yazısında hem “onlarca Qubole müşterisi” hem “bir düzineden fazla kurum” geçiyor; SecurityWeek başlığında ikincisini kullanıyor. Kesin sayı belli değil.
• Neden başarılı oldu: Etkilenen rollerin çoğu artık kullanılmıyordu ama güven ilişkisi silinmemişti. Wiz’in gözlediği ortamların çoğunda Ekim ayında Qubole hesabından gelen tek AssumeRole etkinliği saldırganınkiydi.
• Ne çalındı: Wiz’e göre Secrets Manager, SSM Parameter Store ve Lambda ortam değişkenlerinden gizli bilgiler okundu ve doğrulandı; S3’ten veri indirildi, bazı durumlarda tüm bucket’lar. Sentra, gözlenen ortamlarda yazma ya da silme işlemi görmediğini söylüyor.
• Ne yapmalı: Qubole’yi kullandıysanız ya da kullanmış olabilirseniz 1 Ekim’den itibaren CloudTrail’de aşağıdaki ölçütleri arayın; Qubole’ye güvenen kullanılmayan rolleri silin, kullandıklarınızı daraltın.
• Bilinmeyenler: Qubole’nin kimlik bilgilerinin nasıl ele geçirildiği, toplam kurban sayısı ve isimleri, çalınan verinin kapsamı, saldırganın kim olduğu. Qubole, Idera ya da AWS’den bir açıklama bulamadık.

Ne oldu?

Tablo Wiz’in yazısına dayanır; yazı saat dilimi ya da saat belirtmiyor, bu yüzden yalnızca tarih veriyoruz.

Saldırgan ne yaptı?

Aşağıdaki ayrıntılar Wiz’in ve Sentra’nın yazılarındaki gözlemlerdir; biz bu ortamları görmedik.

• Keşif. Rol oturum adları quiam- önekiyle başlıyordu (örneğin quiam-enum, quiam-scope-full). Saldırgan S3, veritabanı, bilgi işlem, IAM ve KMS hizmetlerinde geniş bir envanter çıkardı.
• Gizli bilgi toplama. Lambda fonksiyonlarının yapılandırmasından (ortam değişkenleri), Secrets Manager’dan ve SSM Parameter Store’dan okuma yaptı. Sentra ayrıca EC2 kullanıcı verisinden (user data) okuma gördüğünü yazıyor ve yaklaşık 100 parola ve anahtarın 7 dakika içinde okunduğunu söylüyor.
• Bulunan kimlik bilgilerini doğrulama. Wiz’e göre saldırgan TruffleHog aracıyla bulduğu bilgileri denedi: AWS erişim anahtarları (GetCallerIdentity ile), Entra ID hizmet sorumluları ve Okta OAuth bilgileri. Bunlar Qubole’ye değil, etkilenen kurumlara aitti.
• Veri çalma. Rolün erişebildiği S3 bucket’larını listeleyip nesneleri indirdi; Wiz saldırganın belirli bir veri aramadığını, ulaşabildiği her şeyi okuduğunu, bazı durumlarda bir oturumda tüm bucket’ı indirdiğini yazıyor. Sentra, bir şirketin hesaplarında milyonlarca dosyanın indirildiğini söylüyor.
• İlerleyiş. Sentra, saldırganın önce düşük değerli bir Qubole rolünde denediğini, sonra dakikalar içinde güvenen tüm rollere girdiğini ve son olarak farklı bir VPN adresinden üretim veritabanı yedeklerini çektiğini yazıyor.
• Önyükleme imajı. Wiz, saldırganın kontrol ettiği IP’de sso_agent.iso adlı, uzaktan başlatılmak üzere tasarlandığına inandığı bir Linux imajı buldu. Wiz bu imajın bir kurbanda kullanıldığını tespit etmediğini ve nasıl kullanıldığını doğrulayamadığını söylüyor.
• Kimlik ve amaç. Wiz bu faaliyeti başka kamuya açık faaliyetlerle ilişkilendirmedi; hedefleme ve veri hırsızlığının fırsatçı göründüğünü, devlet destekli saldırıların tipik önceliklerine uymadığını söylüyor, ama saldırganın amacı hakkında doğrudan bir bilgisi olmadığını da ekliyor.

Neden bu kadar kolay oldu?

• AWS’nin önerdiği yöntem izlendi. Qubole gibi satıcılar müşterinin hesabında, satıcının AWS hesabına güvenen bir rol ister; güven politikasında genellikle bir External ID koşulu bulunur. Sentra, etkilenen kurumların entegrasyonu AWS’nin önerdiği şekilde kurduğunu ve External ID’nin her rolde bulunduğunu belirtiyor.
• External ID gizli bir bilgi değil. Wiz, External ID’nin CloudTrail’de düz metin olarak kaydedildiğini, satıcıda ve altyapı kodunda sıklıkla saklandığını, tek başına bir denetim olarak güvenilmemesi gerektiğini yazıyor. Saldırgan her seferinde doğru External ID’yi sundu.
• Kullanılmayan roller açık kaldı. Sentra’ya göre bazı Qubole rolleri bahardan beri kullanılmıyordu ve saldırı sırasında yeniden “uyandı”; Wiz’in gördüğü ortamların çoğunda Qubole hesabından gelen tek faaliyet saldırganınkiydi.
• Satıcı kimlikleri müşteri ortamlarına açılan bir kapıdır. Wiz, müşterilerin güvendiği satıcı kimliklerinin fiilen tüm müşteri ortamlarının kimlik bilgisi olduğunu yazıyor ve SaaS sağlayıcılarına da öneriler yapıyor (aşağıda). Bu olayda saldırgan her seferinde doğru External ID’yi sundu; bu değerleri nasıl edindiği kaynaklarda açıklanmıyor.
• Ağ koşulu yoktu. Wiz, tek başına bir kaynak IP koşulu olsaydı gözlenen her rol üstlenmenin engelleneceğini yazıyor. Sentra da yalnızca bir ağ kısıtlamasının gördüğü her girişi engelleyeceğini söylüyor.

Etkilenip etkilenmediğinizi nasıl anlarsınız?

Wiz, Qubole ile entegrasyon kurmuş kurumların, entegrasyon rolü bulunan her hesapta 1 Ekim 2026’dan itibaren CloudTrail’e bakmasını öneriyor. Aşağıdaki ölçütler Wiz’in arama listesinden ve gösterge tablosundan derlendi:

1. AssumeRole olayları: userIdentity.accountId değeri 805246085872 ve sourceIPAddress bir AWS adresi değil. Wiz, gözlediği meşru platform trafiğinin tamamının AWS altyapısından geldiğini söylüyor.
2. AssumeRole olayları: userIdentity.principalId değeri AIDA3W7DIFLYOLTK63SFS. Wiz’in gözlediği ortamlarda bu kullanıcıyı yalnızca saldırgan kullandı.
3. AssumeRole olayları: userIdentity.principalId değeri AIDAJYRRH5Y3A7AAJM2HW ve sourceIPAddress bir AWS adresi değil. Bu kullanıcı meşru trafikte de var, bu yüzden kaynak adrese göre ayırın.
4. Wiz’in listelediği adreslerden gelen her faaliyet: 57.129.54[.]120, 45.83.220[.]211, 185.209.199[.]73, 89.37.63[.]175 ve 2001:41d0:70d[:]7800::. Mullvad adresleri ortak çıkış düğümleridir; tek başına kesin kanıt değildir.
5. quiam- önekli rol oturum adları.
6. TruffleHog kullanıcı aracısıyla yapılan ve yukarıdaki adreslerle eşleşen GetCallerIdentity çağrıları; kimlik sağlayıcınızın oturum açma günlüklerinde de aynı kullanıcı aracısını arayın. TruffleHog meşru güvenlik ekipleri tarafından da kullanılır.

Bulduğunuz her rol oturumunun sonrasındaki faaliyetleri, özellikle Secrets Manager, SSM Parameter Store, Lambda ve S3 erişimlerini inceleyin. Wiz’in uyarısı: CloudTrail yönetim olayları rol üstlenmeyi ve bucket listelemeyi kaydeder, ama nesne okumalarını kaydetmez; bunun için S3 veri olayları ya da S3 sunucu erişim günlükleri açık olmalıdır. Günlükleri olmayan kurumlarda hangi nesnelerin okunduğu görülemeyebilir. Wiz’in tam gösterge tablosu (kullanıcı aracıları, imaj özetleri dahil) kendi yazısında.

Ne yapmalısınız?

Aşağıdakiler Wiz’in ve Sentra’nın önerilerine dayanır; hangisinin size uyduğuna kendi ortamınızla karar verin.

1. Dış hesaplara güvenen rolleri envanterleyin. Güven politikası harici bir AWS hesabına izin veren her IAM rolünü listeleyin; hangi izinlere ve hangi verilere erişebildiklerine bakın.
2. Kullanmadığınız entegrasyonların güvenini kaldırın. Wiz, birçok kurban ortamında meşru satıcı trafiği olmadığını ama rollerin saldırganın isteklerini kabul ettiğini belirtiyor. Kullanılmayan entegrasyon rollerini silin ya da satıcı hesabını güven politikasından çıkarın.
3. Güvenilen kimliği daraltın. Satıcı destekliyorsa hesabın root kimliği yerine satıcının kullandığı belirli IAM kimliğini yazın; aws:SourceIp ya da aws:SourceVpce koşuluyla rol üstlenmeyi satıcının belgelenmiş ağ aralıklarına sınırlayın.
4. External ID’yi tek denetim saymayın. Gizli kabul etmeyin; bir olaydan sonra satıcıyla koordinasyon içinde değiştirin ve mümkünse rol başına ayrı değer kullanın.
5. Entegrasyon rollerinin yetkisini sınırlayın. Lambda yapılandırmasına, Secrets Manager’a, SSM parametrelerine ve geniş S3 okumaya erişim çoğunlukla kolaylık için verilir; en az ayrıcalığı uygulayın. Sentra’ya göre sızan her gizli bilgi, Qubole’nin hiç ihtiyaç duymadığı izinlerden geldi.
6. Yeni ağlardan gelen satıcı rol üstlenmesi için uyarı kurun. Satıcı trafiği genellikle bilinen bulut ağlarından gelir; satıcı hesabından VPN ya da satıcının hiç kullanmadığı bir barındırma sağlayıcısı üzerinden gelen AssumeRole güçlü bir sinyaldir.
7. Günlükler her hesabı kapsasın. Tüm hesapları ve bölgeleri kapsayan bir kuruluş izi (organization trail) ve hassas bucket’lar için S3 veri olayları ya da S3 sunucu erişim günlükleri kullanın.
8. Şüphe varsa: Wiz, bir entegrasyon rolünün üstlenildiğini görürseniz o rolün okuyabildiği her gizli bilgiyi, parametreyi ve Lambda ortam değişkenini değiştirmenizi ve rolün etkin oturumlarını iptal etmenizi öneriyor; kimlik bilgisini değiştirmenin zaten verilmiş geçici oturumları sonlandırmadığını da vurguluyor. Sentra’nın etkilenen müşterilerine verdiği adımlar: Qubole’yi güvenen her rolden çıkarın, okunan her gizli bilgiyi değiştirin, saldırganın IP adreslerini engelleyin, günlükleri süreleri dolmadan koruyun ve Qubole’ye bildirin.
9. SaaS sağlayıcısıysanız: Wiz, müşterilerin güvendiği kimliklerin fiilen tüm müşteri ortamlarının anahtarı olduğunu, bu yüzden müşteri rollerini uzun ömürlü IAM kullanıcı anahtarları yerine kısa ömürlü kimlik bilgileriyle çalışan iş yükü rolleriyle üstlenmenizi, bu kimliklerin kullanılabileceği yeri aws:SourceIp ya da aws:SourceVpc ile sınırlamanızı, çıkış IP aralıklarınızı müşterilerin güven politikasını sabitleyebilmesi için yayımlamanızı ve kendi CloudTrail’inizde beklenmeyen ağlardan müşteri hesaplarına yapılan AssumeRole çağrılarını izlemenizi öneriyor.

Zafiyet taraması ve sızma testi bu tür bir olayda ne işe yarar?

Önce sınırı koyalım: bu olay, kurumun kendi sistemindeki bir yazılım açığı değil, güvenilen bir satıcının kimlik bilgilerinin kötüye kullanılmasıdır. CVE tabanlı bir tarama bu olayı önceden bulmak için tasarlanmamıştır ve hiçbir test, bir satıcının ele geçirilmeyeceğini garanti etmez. Yapılabilecek olan, bir satıcı kimliği ele geçirildiğinde ortamınızda neler olabileceğini önceden görmektir:

1. Dış hesaplara açık güven ilişkileri ve aşırı geniş roller. Bulut yapılandırma değerlendirmesi, AWS, Azure ve Google Cloud hesaplarında kimlik ve erişim yönetimini inceler; harici hesaplara güvenen, kullanılmayan ya da gereğinden geniş yetkili rollerin görünür olmasına yardımcı olur.
2. Ele geçirilmiş bir kimlikle nereye varılır? Kırmızı takım testi, bir saldırganın dış kimliklerden başlayıp ortamınızda hangi gizli bilgilere ve verilere ulaşabildiğini sınar.
3. Yeniden test. Güven politikaları daraltıldıktan sonra yapılan yeniden test, test kapsamında görünen durumun düzeldiğini gösterir. Ağ koşulları ve izleme kuralları gibi ayarların sistem tarafında ayrıca doğrulanması gerekir.

Seemarter Security ile

Bulut hesaplarınızda dış satıcılara tanınan güveni ve rollerin yetkilerini incelemek için bulut yapılandırma değerlendirmesi ve kırmızı takım testi hizmetlerimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Tüm çalışmalar, sistem sahibinin yazılı yetkisiyle ve önceden belirlenen kapsamda yapılır.

Kaynaklar

• Wiz: Trusted by Default: Qubole Cross-Account Access Abused in the Wild (9 Kasım 2026); arama ölçütleri, göstergeler ve önerilerin kaynağı
• Sentra: Inside the Qubole Supply Chain Attack: How Sentra Found It (9 Kasım 2026)
• CSO Online: Qubole supply chain attack exposed AWS, Entra ID, and Okta credentials
• SecurityWeek: Over a Dozen Organizations Hit in Qubole Supply Chain Attack
• Cloud Security Alliance: Trusted by Default: Qubole Cross-Account Role Abuse (10 Kasım 2026)

Bu yazı 11 Kasım 2026 sabahına (TSİ) kadar yayımlanmış kaynaklara dayanır; olay sürdüğü için gelişmelere göre güncellenir. Qubole, Idera ya da AWS’nin açıklaması, kimlik bilgilerinin nasıl ele geçirildiği, kurban sayısı ve Wiz ile Sentra’nın yeni göstergeleri yazıya eklenecektir.