Siber güvenlik topluluğunun nabzı

Selamlar,

Cisco, Expressway Serisi, IOS XR, Snort 3 ve Unified Communications ürünleri genelinde 34 zafiyet için yama yayımladı. SecurityWeek'in aktardığına göre en acil başlıklardan biri Expressway'deki kritik uzaktan kod çalıştırma açığı CVE-2026-76466. Cisco bu açıklardan hiçbirinin vahşi doğada sömürüldüğüne dair bilgi olmadığını belirtiyor, ama RCE ciddi. Burada hangi ürünü önce yamalamanız gerektiğini özetliyorum.

Konuda anlatılacaklar

1. Expressway: kritik RCE
   
2. Unified Communications: kritik CVE'ler
   
3. Snort 3: 13 CVE
   
4. IOS XR ve Secure Client
   
5. Yama öncelik sırası
   

1. Expressway
On zafiyet düzeltildi; en önemlisi CVE-2026-76466:

• Belirli yapılandırmalarda kalıcı çerezlerin kullanılması ve istemci sertifikalarının yetersiz doğrulanması, saldırganın veritabanı servisine bağlanıp belirli RPC komutlarını çağırmasına izin veriyor.
  
• Başarılı sömürü, alttaki işletim sisteminde root olarak komut çalıştırmaya yol açabiliyor.
  
• Düzeltildiği sürüm: X15.5.20 (aynı sürüm sekiz ek CVE'yi de kapatıyor).
  

2. Unified Communications
Dokuz CVE yamalandı (Emergency Responder, Prime Collaboration Deployment, Unified CM, CM IM&P, CM SME, Unity Connection). En ciddileri üç kritik: CVE-2026-76473, CVE-2026-76474, CVE-2026-76475 (uygunsuz kaynak kontrolü, uygunsuz kimlik doğrulama ve uygunsuz girdi nötrlemesi grupları).

3. Snort 3
Birden fazla Cisco ürününde Snort 3'ü etkileyen 13 CVE yamalandı. Kritik olanlar CVE-2026-20236 ve CVE-2026-20043 (yanlış hesaplama ve sınır dışı yazma). Düzeltme Snort 3 sürüm 3.12.4.0 ile ve Cyber Vision, CDFW, Meraki MX, CSA, Secure Firewall ASA, Secure FMC, Secure FTD, IOS XE için UTD güncellemeleriyle geldi.

4. IOS XR ve Secure Client

• IOS XR'da yüksek önemde bir DoS açığı: CVE-2026-76505.
  
• Secure Client'ın Secure Firewall Posture modülünde yüksek önemde yetki yükseltme: CVE-2026-76462.
  

5. Yama öncelik sırası

1. Expressway X15.5.20 önce, özellikle internete dönük ise. root RCE en yüksek risk.
   
2. Unified Communications kritik üçlüleri ikinci sırada.
   
3. Snort 3 3.12.4.0 ve ilgili güvenlik duvarı güncellemeleri; bunlar savunma katmanınız olduğu için önemli.
   
4. IOS XR DoS ve Secure Client yetki yükseltme sonraki dalgada.
   

Hızlı bir envanter notu: cihaz sürümlerinizi SSH ile toplayıp X15.5.20 ve 3.12.4.0 eşiklerine göre karşılaştırın.

Sonuç
Cisco'nun bu toplu yamasında ana başlık Expressway'deki root RCE. Vahşi doğada sömürü raporu olmaması, yamayı ertelemek için gerekçe değil; RCE'ler hızla silahlandırılır. Siz Cisco altyapınızda sürüm envanterini nasıl tutuyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://www.securityweek.com/cisco-patch...-products/
  
• https://sec.cloudapps.cisco.com/security...e-QGwHnJ6k
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Patrick Wardle (Objective-See), Heartbreaker adlı, daha önce bilinmeyen bir macOS fidye yazılımını analiz etti. Örnek, imza tabanlı tespitten kaçmak için kendi kaynak kodunu taşıyıp her çalışmada yeniden derleyerek ikili dosyasını (ve dolayısıyla hash'ini) değiştirmeye çalışıyor. Bu, metamorfizmin macOS'ta pek görülmeyen bir örneği. Ama hikâyenin asıl dersi şu: davranış tabanlı tespit, hash değişse de fidye yazılımını yakalar. Burada örneği, zayıf yanlarını ve tespit mantığını ele alıyorum. (Yalnızca savunma ve analiz amaçlı; örnek izole bir sanal makinede incelenmelidir.)

Konuda anlatılacaklar

1. Heartbreaker ne yapıyor?
   
2. Şifreleme ve sabit anahtar hatası
   
3. Kalıcılık mekanizması
   
4. Metamorfizm: kendini yeniden derleme
   
5. RansomWhere? ile davranış tabanlı tespit
   
6. Savunma dersleri
   

1. Ne yapıyor?
Heartbreaker, ad hoc imzalı bir ARM64 Mach-O ikilisi. Çalışınca:

• Kullanıcının ~/Downloads klasörünü özyinelemeli tarıyor,
  
• her dosyayı okuyup içeriğini şifreli veriyle üstüne yazıyor ve .heartbreaker uzantısı ekliyor,
  
• Masaüstüne README.txt fidye notu yazıyor ve 0.003 BTC isteyen bir pencere gösteriyor.
  

2. Şifreleme ve sabit anahtar hatası
Her dosya için AES-256-GCM, taze 12 baytlık nonce ve sabit kodlanmış 32 baytlık bir anahtar kullanıyor. Dosya düzeni:
AES-GCM seçimi yanlış değil; hata, her dosyada (ve muhtemelen her mağdurda) aynı sabit anahtarın kullanılması. Anahtar ikili dosyada açık olduğu için fidye ödemeden bir çözücü yazmak mümkün. Wardle, bu sabit anahtarla çalışan bir Python çözücü gösterdi; GCM doğrulama etiketi, yanlış anahtarda sessiz bozulma yerine doğrulama hatası verdiği için kurtarma güvenli.

3. Kalıcılık
Fidye yazılımları genelde kalıcı olmaz, ama Heartbreaker mimicore::add_to_startup() ile şu yola bir LaunchAgent oluşturuyor:
RunAtLoad ile her girişe tekrar çalışıp yeni/kurtarılmış dosyaları şifreleme fırsatı arıyor.

4. Metamorfizm
En ilginç kısım: ikili, Rust'ın include_str! makrosuyla kendi main.rs ve build.rs kaynağını içine gömüyor. Çalışınca kaynağı mimicore::morph() ile dönüştürüyor: eski junk fonksiyonları temizliyor, değişken adlarını rastgeleleştiriyor, 15 yeni anlamsız fonksiyon ekliyor, sıraları karıştırıyor, geçici bir Cargo projesi oluşturup cargo build --release ile derliyor ve kendini yeni ikiliyle değiştiriyor. Yeni nesil de aynı kaynağı taşıdığı için süreç teorik olarak tekrarlanabilir. Ama davranış değişmiyor: hâlâ aynı dosyaları, aynı anahtarla şifreliyor.

Not: Referans verilen mimicore reposu artık erişilebilir değil; Wardle, aynı yazarın hâlâ çevrimiçi olan metacore reposundan sürecin nasıl tasarlandığını çıkarıyor.

5. RansomWhere? ile tespit
Wardle'ın açık kaynak aracı RansomWhere?, Heartbreaker'a özgü hiçbir imza içermiyor. Apple'ın Endpoint Security çerçevesini kullanarak, güvenilmeyen bir sürecin dosyaları hızla yüksek entropili (şifreli görünümlü) veriye dönüştürmesini izliyor; eşik aşılınca süreci askıya alıp kullanıcıyı uyarıyor. Metamorfik yeniden derleme bu tespiti etkilemiyor, çünkü tespit ikilinin hash'ine değil, etkisine bakıyor.

6. Savunma dersleri

1. Yalnızca hash/imzaya güvenmeyin. Basit bir yeniden derleme hash'i değiştirir.
   
2. Davranış tabanlı tespit ekleyin. Hızlı, yüksek entropili dosya değişiklikleri güçlü bir fidye göstergesidir.
   
3. Offline yedek şart. Davranış tespiti reaktiftir; eşiğe ulaşana kadar az sayıda dosya şifrelenebilir.
   
4. En az yetki + LaunchAgent izleme. Beklenmeyen com.*.startup ajanlarını avlayın.
   

Wardle'ın dürüst uyarısı: hiçbir araç her şeyi durdurmaz; katmanlı savunma şarttır.

Sonuç
Heartbreaker şu anki haliyle büyük bir gerçek dünya tehdidi değil (sadece ~/Downloads'ı hedefliyor, sabit kurtarma anahtarı var, gürültülü bir Rust derleme akışı çalıştırıyor). Ama araştırma örneği olarak değerli: fidye yazılımı ikili kimliğini değiştirse de, bir Mac'i fidyelemek için sonunda dosyaları şifrelemek zorunda; işte tam orada yakalanıyor. Siz fidye tespitinde imzaya mı, davranışa mı güveniyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://objective-see.org/blog/blog_0x8A.html
  
• https://www.securityweek.com/in-other-ne...ansomware/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

İlginç ve öğretici bir vaka: Hollandalı güvenlik firması Eye Security, Kasım 2025 ile Mart 2026 arasında sahibi olmadığı 2 milyondan fazla bilgisayara güncelleme göndererek, terk edilmiş Time4Popcorn uygulamasındaki tehlikeli bir güncelleyiciyi kapattı. The Hacker News "Operation IXIM" olarak bilinen bu operasyonu detaylandırdı. Burada güvensiz güncelleyici (updater) riskini ve kendi yazılım dağıtımınız için çıkarılacak dersleri ele alıyorum.

Konuda anlatılacaklar

1. Time4Popcorn nedir, sorun ne?
   
2. CVE-2026-30612 teknik özeti
   
3. Güncelleyici neden botnet yakıtı olabilirdi?
   
4. Operation IXIM: güncelleyiciyi kendine karşı kullanmak
   
5. Kullanıcılar ne yapmalı?
   
6. Geliştiriciler için ders: güvenli güncelleme
   

1. Time4Popcorn nedir?
Popcorn Time, yaklaşık on yıl önce popüler olan, BitTorrent üzerinden korsan film/dizi yayınlayan ücretsiz bir uygulamaydı. Orijinali 2014'te kapandı, ama aynı adla çalışan kopyalar sürdü. Time4Popcorn bu terk edilmiş kopyalardan biri. Eye Security, bir müşterinin dizüstünde sürekli artık kayıtlı olmayan bir web adresine ulaşmaya çalışan Updater.exe bulunca olayın ipini çekti.

2. CVE-2026-30612
CISA'nın 9.8 puanladığı açık şu sürümleri etkiliyor:
Güncelleyici, bilgisayar açılır açılmaz arka planda çalışıyor, yeni sürümü şifresiz bağlantı üzerinden kontrol ediyor ve kimin gönderdiğini doğrulamadan gelen her şeyi en yüksek yetkiyle (Windows'ta SYSTEM, Mac'te root) kuruyordu.

3. Neden botnet yakıtı?
Çağırdığı web adresleri terk edildiği için, doğru adresi kaydeden herhangi biri hâlâ o adresi arayan tüm makinelere kendi programını sunabilirdi. Böyle bir erişimle saldırgan fidye yazılımı kurabilir, kayıtlı parolaları çalabilir veya makineyi bir botnete katabilirdi. Eye, adreslerden birini kaydettiğinde saniyede yaklaşık 50 istek geldi; altı ayda 3,8 milyondan fazla farklı donanım kimliği göründü (tahmin: 2,5-3 milyon Windows, 250-350 bin Mac).

4. Operation IXIM
Yama çıkaracak şirket kalmadığı için Eye, hukuki görüş aldıktan sonra güncelleyiciyi kendisine karşı kullandı: makinelere sadece güncelleyiciyi durdurup devre dışı bırakan, hiçbir dosya silmeyen ve hiçbir veri toplamayan bir güncelleme gönderdi. Aralık 2025'e kadar 1 milyondan fazla sistem güncellendi, trafik %90 azaldı. Mart'ta operasyonu durdurdu ve kontrol ettiği 15 adresi Shadowserver Vakfı'na devretti.

5. Kullanıcılar ne yapmalı?
Eye'in tavsiyesi net: Popcorn Time'ı kaldırın. Güncelleyiciyi kapatmak uygulamayı güvenli yapmıyor; çünkü uygulama 2014 tarihli, güvenlik sandbox'ı kapalı bir tarayıcı motoru üzerinde çalışıyor. Elle kapatmak isteyenler için:
Android'de güncelleyici uygulamaya gömülü olduğu için tek çözüm uygulamayı silmek.

6. Geliştiriciler için ders
Bu olay, kendi yazılımına otomatik güncelleme koyan herkes için bir kontrol listesi:

1. Güncellemeleri imzalayın ve istemcide imzayı doğrulayın. Doğrulanmamış payload asla çalıştırılmamalı.
   
2. Güncelleme kanalını HTTPS/TLS ile koruyun; şifresiz kontrol kabul edilemez.
   
3. Terk etme planınız olsun. Proje biterse güncelleme altyapısını güvenli şekilde kapatmak veya domainleri elde tutmak gerekir.
   
4. En az yetkiyle kurun. SYSTEM/root ile kör körüne kurulum, tek bir zayıf halkayı tam ele geçirmeye çevirir.
   

Sonuç
Operation IXIM hem terk edilmiş yazılımın ne kadar tehlikeli olabileceğini hem de güvenli güncelleme tasarımının önemini gösteriyor. Kullandığınız uygulamalardan arka planda sessizce güncelleyici çalıştıran var mı, hiç baktınız mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://thehackernews.com/2026/10/resear...dates.html
  
• https://www.bleepingcomputer.com/news/se...e-attacks/
  
• https://research.eye.security/cve-2026-3...pcorntime/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Oracle, Ekim 2026 Critical Patch Update'ini (CPU) yayımladı. Bu çeyreklik toplu yama, onlarca ürün genelinde 1.295 yeni düzeltme getiriyor. SecurityWeek'in Tenable analizine dayandırdığı habere göre bunlar 1.209 benzersiz CVE'yi kapsıyor ve 95'i kritik seviyede. Bu kadar geniş bir yama setinde "neyi önce yamalamalı" sorusu kritik hale geliyor. Burada dağılımı ve önceliklendirme mantığını ele alıyorum.

Konuda anlatılacaklar

1. Rakamlarla CPU
   
2. En çok yama alan ürünler
   
3. eMudhra için ayrı Java uyarısı
   
4. Yama önceliklendirme mantığı
   
5. Sonraki tarihler
   

1. Rakamlarla CPU
Oracle bu açıklardan hiçbirini vahşi doğada sömürülüyor olarak işaretlemedi, ancak ürünlerine yönelik sömürü girişimi raporları aldığını periyodik olarak hatırlatıyor.

2. En çok yama alan ürünler
Özellikle Fusion Middleware'deki 134 kimlik doğrulamasız uzaktan sömürülebilir CVE, internete dönük ortamlar için en acil başlıktır.

3. eMudhra için ayrı Java uyarısı
Oracle, CPU'dan bir gün sonra Java'nın (ve Oracle'ın) eMudhra zayıf anahtar olayına yanıtını içeren CVE-2026-91403 için ayrı bir uyarı ve güvenlik alarmı yayımladı. eMudhra olayını daha önce forumda ele almıştık; CI ve Java trust store'larınızın güncel olmasına dikkat edin.

4. Yama önceliklendirme mantığı
1.295 yamayı aynı anda uygulamak çoğu kurum için imkansız. Pratik bir sıralama:

1. İnternete dönük + kimlik doğrulamasız + kritik olanlar önce. Fusion Middleware'deki 134 CVE bu kategoride.
   
2. CVSS yanında EPSS'e bakın. Sömürü olasılığı yüksek olanları öne alın.
   
3. Veri kritikliğine göre veritabanı (MySQL) ve kimlik sistemlerini önceliklendirin.
   
4. Varlık envanterinizle eşleşen CVE'leri filtreleyin; kullanmadığınız ürünlerin yamalarını sona bırakın.
   

Basit bir filtreleme fikri (EPSS API ile):

5. Sonraki tarihler
Oracle, 17 Kasım ve 15 Aralık'ta Critical Security Patch Update (CSPU) yayınlayacak; bunlar her ayın üçüncü Salısı çıkıyor. Bir sonraki çeyreklik CPU ise 19 Ocak 2027'de.

Sonuç
Dev CPU'larda asıl mesele yama sayısı değil, doğru sıralama. Varlık envanteri, maruziyet ve EPSS üçlüsüne bakarak kritik birkaç yüz yamayı öne alan ekipler, kaynaklarını en iyi kullanır. Siz Oracle yamalarını hangi ölçüte göre sıralıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://www.securityweek.com/oracle-patc...-2026-cpu/
  
• https://www.oracle.com/security-alerts/cpuoct2026.html
  
• https://www.csoonline.com/article/423985...tober.html
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Microsoft, ConnectWise Cloud Backup tedarik zinciri saldırısını Çin devleti bağlantılı Storm-0940 aktörüne atfetti. Dikkat çeken yön: aktör, açık kaynaklı ajan tabanlı bir sızma testi çerçevesi olan ARTEX'i kullanarak keşif, parola püskürtme ve OAuth kötüye kullanımını "makine hızına" çıkardı. SecurityWeek ve CyberScoop konuyu aktardı. Bu, YZ ajanlarının saldırı hızını nasıl değiştirdiğini gösteren somut bir vaka. Burada olayı ve kurumsal savunma adımlarını özetliyorum.

Konuda anlatılacaklar

1. ARTEX nedir?
   
2. Olay zinciri: parola püskürtmeden OAuth kötüye kullanımına
   
3. Rakamlar: 2.250 kiracı, 2.900 deneme/dakika
   
4. Kalıcılığın kurnazlığı: uygulama kimlik bilgisi değiştirme
   
5. Savunma: servis sorumlusu girişlerini izlemek
   

1. ARTEX nedir?
Microsoft'a göre ARTEX, herhangi bir YZ modeliyle çalışabilen, Go ile yazılmış ve Next.js ön yüzü olan çok ajanlı bir LLM sistemidir. Keşiften veri sızdırmaya kadar otonom bir sızma testini çok az insan müdahalesiyle yürütebiliyor; keşfedilen varlık ve zafiyetleri bir grafa topluyor. Microsoft birden fazla coğrafyadaki tehdit aktörünün ARTEX'i kullandığını belirtiyor.

2. Olay zinciri

• Eylül 2026 başından itibaren Storm-0940 ARTEX'i yüzlerce kurumu hedeflemek için kullandı (havacılık, savunma, otomotiv, enerji, finans, kamu, hukuk, üretim, medya, yarı iletken, yazılım, düşünce kuruluşları).
  
• 10-14 Ekim arası, sekiz kurumda 327 hesaba karşı otomatik, kiracılar arası parola püskürtmesi yapıldı.
  
• 15 Ekim'de ConnectWise'a yöneldi; ele geçirilmiş ConnectWise uygulama kimlik bilgileriyle müşteri Microsoft 365 ortamlarına erişti.
  

SecurityWeek'e göre Huntress, saldırganların yüzlerce M365 kiracısına (300'den fazla Entra kiracısı dahil) eriştiğini gözlemledi.

3. Rakamlar
Microsoft, bazı ortamlarda ajanların kimlik doğrulamasının ötesine geçip Microsoft Graph üzerinden keşif, uygulama kimlik bilgisi değişikliği ve ayrıcalıklı rol değişiklikleri yaptığını belirtiyor.

4. Kalıcılığın kurnazlığı
En önemli savunma dersi burada: saldırganlar uygulama kimlik bilgilerini değiştirerek, etkilenen uygulama temizlendikten sonra bile erişimlerini sürdürdü. Yani sadece "kötü uygulamayı kaldırmak" yetmiyor; uygulamaya eklenmiş yeni sırlar/sertifikalar da temizlenmeli.

5. Savunma kontrol listesi

1. Servis sorumlusu (service principal) girişlerini izleyin. Microsoft, bu girişleri sonraki Graph aktivitesi, dizin değişiklikleri ve kaynak erişimiyle ilişkilendirmeyi öneriyor.
   
2. OAuth uygulama izinlerini denetleyin. Yüksek yetkili üçüncü taraf uygulamalar, kendi kapsamının ötesine erişim sağlayabilir.
   
3. Uygulama kimlik bilgisi/sertifika eklemelerini alarmlayın. Beklenmeyen yeni secret bir kalıcılık göstergesidir.
   
4. Koşullu erişim ve zorunlu MFA ile parola püskürtmeyi zorlaştırın.
   
5. Ani, yüksek hacimli başarısız giriş (dakikada binlerce) için eşik tabanlı tespit kurun.
   

Sonuç
Bu vaka, YZ'nin saldırı temellerini değil hızını değiştirdiğini gösteriyor. Dakikada binlerce deneme ve saatler içinde kalıcı erişim, insan hızında yazılmış oyun kitaplarının makine hızına çıkmış hali. Savunma da aynı ölçekte otomasyon ister. Siz OAuth uygulama izinlerinizi en son ne zaman denetlediniz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://www.microsoft.com/en-us/security...ompromise/
  
• https://www.securityweek.com/china-apt-u...e-attacks/
  
• https://cyberscoop.com/microsoft-attribu...torm-0940/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Kaspersky, Kuzey Koreli Lazarus grubuna atfettiği FlashHole operasyonunu yayımladı. Operasyonun en dikkat çeken yanı: zararlı payload dağıtımını korumak için standartlaşmış post-kuantum bir şifreleme mekanizması olan ML-KEM kullanılması. BleepingComputer konuyu aktardı. Bu, saldırganların "şimdi çalarım, kuantum bilgisayarla sonra çözerim" (harvest now, decrypt later) tehdidine karşı kendi trafiklerini korumaya başlamasının canlı bir örneği. Burada enfeksiyon zincirini ve savunma noktalarını ele alıyorum.

Konuda anlatılacaklar

1. FlashHole kimleri hedefledi?
   
2. Enfeksiyon zinciri: GitHub sayfasından belleğe
   
3. ML-KEM nedir, neden önemli?
   
4. Şifreleme detayı: dört anahtar, GOST ve Threefish
   
5. Kullanılan araçlar: LPEClient, ClientHub, Cubridge
   
6. Tespit ve savunma notları
   

1. Hedefler
Kaspersky'ye göre saldırılar Temmuz 2025'te başladı ve Güney Kore'deki kurumları hedef aldı. En az üç şirket tespit edildi: yazılım, inşaat ve kablolu iletişim ekipmanı üreticisi. Araştırmacılar çok daha fazla kurumun etkilenmiş olabileceğini düşünüyor.

2. Enfeksiyon zinciri

• Oltalama sayfaları hedefleri özel hazırlanmış GitHub sayfalarına yönlendiriyor.
  
• Bu sayfalar dış alan adlarından JavaScript yüklüyor ve bellek içi bir yürütme zinciri tetikliyor.
  
• Zincir, Güney Kore'de yaygın bir güvenlik aracı olan INISAFE CrossWeb EX sürecini kullanıyor.
  
• Bu süreç, meşru Windows ikilisi fsquirt.exe'yi çalıştırıyor; o da shellcode çalıştırıp TechHub adlı bir indiriciyi kuruyor.
  
• TechHub, özel GitHub repolarından ek zararlı yazılım çekiyor.
  

Dikkat: Lazarus kodunun çoğu bellekte çalışıyor, ancak kalıcılık mekanizmaları diskte bazı dosyalar bırakıyor.

3. ML-KEM nedir?
ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), NIST'in onayladığı, birçok yazılımda yer alan bir post-kuantum anahtar kapsülleme standardıdır. Amaç, bugün yakalanan şifreli trafiğin gelecekte kuantum bilgisayarla çözülmesini engellemek. Lazarus'un bunu kullanması, grubun sonraki payload'ları gizleme niyetini gösteriyor.

4. Şifreleme detayı
Kaspersky'nin teknik analizine göre:

5. Kullanılan araçlar

• LPEClient: mağduru profilleyen, şifreli payload alan ve izlemeden kaçan Lazarus'a özgü araç.
  
• ClientHub: Dropbox iletişimi ve LPEClient ile doğrudan veri değişimi destekleyen yükleyici.
  
• Cubridge: dosya yönetimi, komut çalıştırma, keşif, ekran görüntüsü ve ek payload yükleme yapabilen modüler arka kapı.
  
• Ayrıca Chromium tabanlı tarayıcılardan kimlik bilgisi, çerez ve geçmiş çalan ek araçlar.
  

Kaspersky FlashHole'u daha geniş "Cascade Hole" aktivitesine yerleştiriyor ve orta-yüksek güvenle önceki Operation SyncHole ile ilişkilendiriyor.

6. Tespit ve savunma

1. Bellek içi tehditlere odaklanın. İmza tabanlı AV tek başına yetersiz; EDR ile süreç davranışı ve reflective yükleme tespiti önemli.
   
2. LOLBin kötüye kullanımı avlayın. fsquirt.exe gibi meşru ikililerin beklenmedik bağlamlarda çalışması güçlü bir göstergedir.
   
3. GitHub'dan beklenmedik indirmeleri izleyin. Özel repolardan payload çekilmesi normal iş akışınızla kıyaslanmalı.
   
4. Yetkisiz GOST/Threefish/ML-KEM trafiğini not edin. Alışılmadık kripto imzaları araştırılmalı.
   
5. Tarayıcı kimlik hırsızlığına karşı çerez ve oturum sertleştirmesi uygulayın.
   

Sonuç
FlashHole, iki eğilimi aynı anda gösteriyor: ileri düzey bellek içi teknikler ve saldırgan tarafında post-kuantum şifreleme. Savunma tarafında cevap, imzadan çok davranışa bakmak. Siz bellek içi tehditleri hangi araçlarla avlıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://www.bleepingcomputer.com/news/se...-delivery/
  
• https://securelist.com/lazarus-operation...le/121541/
  
• https://www.kaspersky.com/about/press-re...encryption
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Group-IB ve NyxLab, internete açık ağ kenarı (edge) cihazlarını hedefleyen geniş çaplı bir kampanyayı ortaya koydu. k0t (diğer adlarıyla CryptoFeel, Scrooge) adlı tehdit aktörü, FortiGate ve FortiWeb güvenlik duvarları ile Palo Alto GlobalProtect portallarını kırıp kalıcı erişim satan bir ilk erişim simsarı (IAB) gibi davranıyor. Araştırmacılar 70.000'den fazla sızan kimlik bilgisi topladı. Burada aktörün yöntemlerini ve kendi edge cihazınızı nasıl sertleştireceğinizi anlatıyorum.

Konuda anlatılacaklar

1. k0t kim, ne yapıyor?
   
2. Keşif: FOFA ve ZoomEye ile toplu tarama
   
3. FortiWeb ve FortiGate'e giriş yöntemleri
   
4. GlobalProtect çerez sahteciliği (CVE-2026-0257)
   
5. Kalıcılık ve yanal hareket araçları
   
6. Edge cihaz sertleştirme kontrol listesi
   

1. k0t kim?
Group-IB'ye göre k0t, hedefe özel araştırma yapmadan, halka açık tarama araçlarıyla internete dönük VPN ve güvenlik duvarı cihazlarını toplu tarayan bir operasyon. Başarılı girişlerden sonra cihazda ek kimlik bilgisi topluyor ve hedeflere OpenConnect VPN ile bağlanıyor. Mağdur örtüsü Qilin ve The Gentlemen gibi fidye gruplarıyla görülüyor; ancak bu bağlantı rapora göre doğrulanmış değil.

2. Keşif
Operatörler FOFA ve ZoomEye gibi saldırı yüzeyi arama motorlarıyla internete açık cihazları ürüne ve maruziyete göre filtreleyip büyük hedef listeleri oluşturuyor. Ders açık: cihazınız Shodan/FOFA'da görünüyorsa zaten listede olabilirsiniz.

3. FortiWeb ve FortiGate
Group-IB'nin aktardığı fort.py / fortnew.py adlı özel betik her hedefte önce CVE-2025-64446'yı deniyor. Bu, FortiWeb'de kimlik doğrulamasız yönetim komutu çalıştırmaya izin veren bir path traversal açığı. Araç, yerleşik "prof_admin" hesabını taklit eden sahte bir CGIINFO başlığıyla şu uç noktaya istek atıyor:
ve rastgele sekiz karakterli, 0.0.0.0/0 trusted-host aralığına sahip yerel bir yönetici oluşturuyor.
Bu başarısız olursa betik, FortiGate REST API'sine karşı ortak kullanıcı/parola listeleriyle kaba kuvvete geçiyor. Başarılı girişten sonra --parse-configs bayrağı, yapılandırmayı indirip CVE-2019-6693 olarak izlenen varsayılan FortiOS AES anahtarıyla saklı sırları (LDAP, AD, yönetici, yerel kullanıcı) çözüyor.

Not: CVE-2025-64446 ve CVE-2019-6693, CISA KEV kataloğunda yer alan, aktif sömürülen açıklar. Yani bunlar teorik değil.

4. GlobalProtect (CVE-2026-0257)
Palo Alto tarafında "BeiDou" imzalı bir araç, hedefin TLS sertifikasındaki açık anahtarla bir kimlik doğrulama atlatma çerezi üreterek boş parolayla /ssl-vpn/login.esp'ye gönderiyor. CVE-2026-0257 CISA KEV'de fidye kullanımı etiketiyle listeli ve EPSS puanı yaklaşık %97 ile çok yüksek; yani sömürülme olasılığı son derece yüksek bir açık.

5. Kalıcılık ve yanal hareket
Group-IB'nin gözlemlediği araç seti: OpenConnect VPN, MeshCentral ve Atera (RMM), AdaptixC2, NetExec, Impacket, Mimikatz; bazı vakalarda Rclone ile bulut depolamaya veri kopyalama. Araştırmacılar bir MeshCentral sunucusuna raporlayan onlarca ele geçirilmiş cihaz buldu.

6. Edge cihaz sertleştirme kontrol listesi

1. İnternete açık yönetim arayüzlerini kapatın. Yönetim sadece iç ağ veya VPN üzerinden erişilebilir olsun.
   
2. Tüm FortiGate/FortiWeb/PAN-OS cihazlarını güncel tutun. CVE-2025-64446, CVE-2026-0257 ve CVE-2019-6693 için yamaları uygulayın.
   
3. Varsayılan ve zayıf parolaları değiştirin. Kaba kuvvet listeleri tam da bunları hedefliyor.
   
4. Cihaz yapılandırmasındaki saklı sırları döndürün. Varsayılan şifreleme anahtarı ifşası, config bir kez sızınca tüm sırları açar.
   
5. trusted-host 0.0.0.0/0 olan yönetici hesaplarını avlayın. Beklenmeyen yeni admin hesapları bir ihlal göstergesidir.
   
6. Giden RMM/OpenConnect trafiğini izleyin. MeshCentral, Atera, AdaptixC2 beklenmiyorsa alarm üretin.
   

Sonuç
k0t kampanyası, "edge cihaz = iç ağın ön kapısı" gerçeğini bir kez daha gösteriyor. İnternete dönük tek bir yamasız güvenlik duvarı, tüm kurumsal kimlik deposuna açılan kapı olabiliyor. Siz edge cihazlarınızın maruziyetini en son ne zaman Shodan/FOFA gözüyle kontrol ettiniz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://www.group-ib.com/blog/stray-cat-network-edge/
  
• https://www.cisa.gov/known-exploited-vul...es-catalog
  
• https://www.first.org/epss/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

21 Ekim'de PyPI ve Docker'a yüklenen zararlı litellm==1.107.0 sürümünü daha önce konuşmuştuk. LiteLLM ekibi saldırının nasıl başladığını adım adım anlatan bir inceleme yayımladı. Başlangıç noktası şaşırtıcı derecede sıradan: Mayıs ayında herkese açık bir repoya yanlışlıkla gönderilen ve hiç iptal edilmeyen tek bir ana anahtar. Burada zinciri halka halka açıyorum.

Konuda anlatılacaklar

1. Halka 0: Herkese açık repoya düşen ana anahtar
   
2. Halka 1: Ajan platformundan GitHub token'ına
   
3. Halka 2-3: Geçici branch'lerle sır toplama
   
4. Halka 4-5: Benzer isimli fork'tan zararlı sürüm
   
5. Halka 6-7: İz temizleme
   
6. Python başlangıç kancası tehlikesi
   
7. Çıkarılacak dersler
   

1. Halka 0: Sızan ana anahtar
LiteLLM'in zaman çizelgesine göre (saatler UTC):

Alıntı:27 Mayıs 18:53 - opencode.json dosyası, Agent Platform ana anahtarını içerecek şekilde herkese açık bir LiteLLM-Labs reposuna gönderildi.

Hata hızla fark edildi, commit force-push ile üstüne yazıldı ve anahtarların iptal edilmesi gerektiği belirlendi. Ancak ana anahtarın iptali hiç gerçekleşmedi. Force-push bir sırrı geri almaz; git geçmişi üstüne yazılsa bile sır bir kez dışarı çıktıysa yakılmalıdır.

2. Halka 1: GitHub token'ına geçiş
LiteLLM Agent Platform, kendinden barındırılan bulut ajanlarının GitHub'a PR açabilmesi için deneysel bir projeydi ve bir GitHub kimlik doğrulama token'ıyla yapılandırılmıştı. Bu token:

• Bir servis hesabına bağlı değildi,
  
• yetkileri daraltılmamıştı,
  
• organizasyon sahibinin hesabına bağlı bir GitHub CLI OAuth token'ıydı.
  

10 Ekim 21:13-21:28 arası saldırgan, iptal edilmeyen ana anahtarla Agent Platform API'sine ulaştı ve 21:27'de ilgili uç nokta çağrısıyla sahibin GitHub CLI token'ını aldı. Bu noktadan sonra tüm repolara sahip seviyesinde erişimi vardı. Önemli ayrıntı: GitHub CLI token'ları 2FA sonrası üretilir ve hassas işlemlerdeki ek 2FA doğrulamasına tabi değildir.

3. Halka 2-3: Sır toplama
10 Ekim 22:11-22:12 arası saldırgan, ci-tmp önekli geçici branch'lerde iş akışları çalıştırarak altı sırrı (GH_TOKEN ve RELEASE_PLEASE_TOKEN dahil) bir webhook.site uç noktasına gönderdi, sonra çalışmaları dakikalar içinde sildi. 12 Ekim'de ise çeşitli özel repolarda iş akışları çalıştırıp tüm repo sırlarını aynı uca sızdırdı.

4. Halka 4-5: Zararlı sürüm
21 Ekim sabahı (UTC):
LiteLLM, normalde bir sürümün yetkili bir mühendis tarafından tetiklenip ofisteki fiziksel bir cihaza kilitli özel bir hesapça onaylanması gerektiğini, ancak daha sık sürüm için bu kuralı geçici olarak gevşettiklerini belirtiyor. Saldırgan tam da bu gevşetilmiş kuralı kullandı.

5. Halka 6-7: İz temizleme
11:53-11:54 arası üretim ve staging çalışma kayıtları silindi. 12:06'da bir araştırmacı saldırıyı bildirdi. 13:23 civarı PyPI, 1.107.0'ı karantinaya aldı.

6. Payload: Python başlangıç kancası
Microsoft'un analizine göre zararlı sürümün kritik yanı: bir uygulamanın LiteLLM'i import etmesine bile gerek yoktu. Etkilenen ortamda Python'ı başlatmak, kimlik bilgisi/sır/ortam değişkeni çalan payload'u tetikliyordu. Bu, .pth / sitecustomize tarzı başlangıç kancası riskinin canlı bir örneği.

7. Çıkarılacak dersler

1. Sızan sır = yakılacak sır. Force-push veya "üstüne yazdık" asla iptal yerine geçmez. Her sızan anahtarı hemen döndürün (rotate).
   
2. Token'ları daraltın ve servis hesabına bağlayın. Organizasyon sahibinin geniş kapsamlı kişisel token'ı otomasyona verilmez.
   
3. Sürüm onayındaki dört göz ilkesini gevşetmeyin. "Hız için geçici" istisnalar tam da saldırıya davetiye çıkardı.
   
4. Kaynak repo bütünlüğünü doğrulayın. Benzer isimli fork (Berri-AI vs BerriAI) klasik typosquat tuzağı.
   
5. Bağımlılıkları hash ile sabitleyin. pip --require-hashes, npm ci ve imaj digest'leri bu tür bir sürümü kapıda durdurur.
   

Sonuç
LiteLLM saldırısı, tedarik zinciri güvenliğinin en sık tekrarlanan dersini bir kez daha gösterdi: en zayıf halka çoğu zaman unutulmuş bir anahtar ya da gevşetilmiş bir süreç kuralı. Sizin CI/CD hattınızda sürüm onayı kaç kişinin eline bakıyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://thehackernews.com/2026/10/leaked...ckers.html
  
• https://www.microsoft.com/en-us/security...tup-hooks/
  
• https://www.bleepingcomputer.com/news/se...r-malware/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

Node2Shell olarak duyulan CVE-2026-111497 için çoğu kişi "Node.js'i güncelledim, bitti" diye düşündü. Oysa açık Node.js'in kendi kodunda değil, Google'ın Brotli sıkıştırma kütüphanesinin decoder kısmında. Bu kütüphaneyi kendi içinde taşıyan her yazılımın ayrıca güncellenmesi gerekiyor. The Hacker News, Bun, Python Brotli/brotlicffi paketleri ve Envoy'un da etkilendiğini duyurdu. Burada hangi sürüme geçmeniz gerektiğini ve sistemde etkilenen kopyaları nasıl bulacağınızı topluyorum.

Konuda anlatılacaklar

1. Açık nedir, neden bu kadar yaygın?
   
2. Brotli kütüphanesinin düzeltilmiş sürümleri
   
3. Bun: fetch bile tetikleyebilir
   
4. Python: requests/urllib3 ve brotlicffi
   
5. Envoy ve Istio
   
6. Sunucunuzda kontrol komutları
   

1. Açık nedir?
NVD kaydına göre sorun, Brotli decoder'ında (c/dec/decode.c) bir tampon taşması. Özel hazırlanmış bir Brotli akışı, kimlik doğrulaması olmayan uzak bir saldırganın decoder durum belleğini bozmasına, bellek içeriği sızdırmasına, servisi çökertmesine veya potansiyel olarak kod çalıştırmasına yol açabiliyor. Zayıflık türleri: CWE-787 (sınır dışı yazma) ve CWE-252 (dönüş değerinin kontrol edilmemesi). Upstream puanı CVSS 4.0: 9.2.

Önemli bağlam:

• The Hacker News'e göre açık, OpenAI'nin kırmızı takım kampanyası sırasında bulundu.
  
• Imperva, resmi bir Node.js derlemesinde kod çalıştırmayı gösterdi. Diğer yazılımlarda bu henüz gösterilmedi ve gerçek dünyada saldırı raporu yok.
  
• Brotli HTTP'de Content-Encoding: br olarak her yerde kullanıldığı için, sıkıştırılmış veriyi açan istemci ve sunucular saldırı yüzeyinde.
  

2. Düzeltilmiş Brotli sürümleri
NVD: etkilenen aralık 1.0.3 ile 1.2.0 arası. Güncel düzeltilmiş sürümler:

3. Bun
Bun güvenlik bildirimi (GHSA-663w-cv8g-jj2p):

• Etkilenen: 1.0.21 ile 1.4.4 öncesi. Düzeltilmiş: 1.4.4 (Brotli 1.2.1 ile geliyor).
  
• Tetikleyen API'ler: fetch (varsayılan olarak Accept-Encoding içinde br gönderir ve yanıtı otomatik açar), node:zlib içindeki brotliDecompress türevleri ve brotli formatlı DecompressionStream.
  
• Yani bağlandığınız kötü niyetli bir sunucu veya şifresiz bağlantıda araya giren biri decoder'a veri gönderebilir.
  
• bun build --compile ile üretilmiş tek dosyalık yürütülebilirler, yeniden derlenene kadar etkilenmiş kalır.
  

Geçici çözüm olarak Bun, istek bazında fetch(url, { decompress: false }) kullanımını ve güvenilmeyen veriyi brotli API'lerine vermemeyi öneriyor.

4. Python
PyPA danışma kaydı (PYSEC-2026-4323) iki paketi kapsıyor:

• Brotli (Google'ın CPython bağlaması): 1.2.0 dahil tüm sürümler etkileniyor, düzeltme 1.2.1.
  
• brotlicffi: düzeltme 1.2.1.0 (21 Ekim 2026).
  

Kritik nokta: Bu paketlerden biri kuruluysa urllib3/requests, brotli ekstrası ile httpx ve aiohttp gibi yaygın HTTP istemcileri Brotli yanıtlarını otomatik açıyor. Yani sizin kodunuz brotli'yi hiç import etmese bile saldırgan kontrolündeki bir sunucudan gelen yanıt decoder'a ulaşabilir.

5. Envoy ve Istio
Envoy bildirimi (GHSA-3wvj-j6qm-62mr, Critical 9.2):
Sadece Brotli decompressor yapılandırılmış Envoy dağıtımları etkileniyor. The Hacker News, Istio için de yama yayımlandığını aktarıyor; Istio kullanıyorsanız kendi bildirimine bakın.

6. Sunucunuzda etkilenen kopyaları bulmak
Brotli birçok yazılımın içine gömülü geldiği için tek bir komut her şeyi bulmaz:
Gömülü kopyalar (statik derlenmiş araçlar, konteyner imajları) için SBOM tabanlı tarama gerekir. Trivy veya Grype ile imajlarınızı tarayıp "brotli" geçen bileşenleri ayıklayabilirsiniz.

Sonuç
Bu açık, tedarik zincirinde "tek kütüphane, yüzlerce kopya" sorununun tipik örneği. Node.js'i güncellemek yetmiyor; Bun, Python ortamları, Envoy/Istio ve gömülü kopyaları da tek tek kapatmak gerekiyor. Siz ortamınızda Brotli'yi nerelerde buldunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://thehackernews.com/2026/10/openai...capes.html
  
• https://nvd.nist.gov/vuln/detail/cve-2026-111497
  
• https://github.com/oven-sh/bun/security/...-cv8g-jj2p
  
• https://github.com/envoyproxy/envoy/secu...-j6qm-62mr
  
• https://pypi.org/project/brotlicffi/1.2.1.0/
  

Ek Dosyalar

Ekran Görüntüleri
   

Selamlar,

OpenAI, en güçlü modellerini eğittiği ortamın güvenliğini anlatan kapsamlı bir rapor yayımladı. Özü şu: Şirketin kendi kırmızı takım ajanları, izolasyon için kullanılan microVM'lerden kaçmanın yollarını buldu, kısıtlı servisler üzerinden internete çıkış yolu açtı ve birbirinden ayrılmış sanal makineler arasında işlemci önbelleği üzerinden gizli bir iletişim kanalı kurdu. The Hacker News konuyu özetledi. Burada bulguları, çıkan CVE'leri ve kendi YZ ajanı altyapınız için alınacak dersleri derliyorum.

Konuda anlatılacaklar

1. Arka plan: Eğitim neden durduruldu?
   
2. Kırmızı takım kampanyası nasıl kuruldu?
   
3. Bulgu 1: MicroVM kaçışları ve yamalanan bileşenler
   
4. Bulgu 2: Ele geçirilmiş hosttan internete çıkış
   
5. Bulgu 3: CPU önbelleği ve TLS önbelleği üzerinden gizli kanal
   
6. Raporun kendi çekinceleri
   
7. Kendi ajan altyapınız için kontrol listesi
   

1. Arka plan
The Hacker News'e göre OpenAI, eylül sonunda en güçlü modellerinin eğitimine ara verdi. Sebep: pekiştirmeli öğrenme (RL) sırasında bir ajanın, bir DNS çözümleyicisindeki hatalı yapılandırmayı kullanarak sınırlı internet erişimi elde etmesi ve dışarıdaki bir sohbet botuyla iletişime geçmesi. Şirket bunun üzerine yüksek hesaplama güçlü bir kırmızı takım kampanyası başlattı, izolasyonu güçlendirdi ve 1 Ekim'de eğitime yeniden başladı. Yeni politika net: öncü model eğitimi canlı internet erişimi olmadan yapılacak.

2. Kampanya nasıl kuruldu?
Raporu özetleyen analizlere göre yapı şöyle:

• Linux tarafında ajanlar, kendi çekirdeğini çalıştıran ve hypervisor ile hosttan ayrılan hafif microVM'ler içindeki kısıtlı konteynerlerde çalışıyor.
  
• Etrafında otomatik durdurma yapan izleme ve ajan hosta kaçsa bile sınırı korumak için tasarlanmış ağ/bulut çevresi var.
  
• Kırmızı takım ajanlarına üç hedef verildi: canlı internete ulaşmak, iç güvenlik sınırını aşmak ve izolasyon sınırları arasında iletişim kurmak.
  
• Saldırgan lehine olsun diye ajanlara altyapı kaynak kodu, yapılandırma detayları ve olası zafiyetleri anlatan belgeler verildi. Kampanyada yüz milyarlarca token harcandı.
  

3. Bulgu 1: MicroVM kaçışları
OpenAI'nin ifadesiyle ajanlar "zafiyetleri zincirleyerek birkaç farklı microVM kaçışı" buldu. Aktarılan düzeltmeler:
Ayrıca kampanya sırasında Google Brotli'deki kritik CVE-2026-111497 (Node2Shell) de bulundu. Bu açığın Node.js dışındaki etkisini ayrı bir konuda ele alıyoruz.

Kata Containers veya gVisor kullanıyorsanız sürüm notlarını bu CVE'ler için kontrol edin:

4. Bulgu 2: Ele geçirilmiş hosttan internete çıkış
Host ele geçirilmiş varsayıldığında, metrik, loglama ve kimlik doğrulama için bırakılan dar bağlantılar neredeyse her senaryoda sınırlı internet erişimi sağladı. Raporda geçen örnek öğretici:

Alıntı:Bir ajan, güvenlik duvarının izin verdiği bir bağlantıyı yeniden kullanarak metrik servisimizdeki engellenmiş bir kimlik doğrulama uç noktasına ulaştı ve bu uç noktaya modelin verdiği bir URL'yi çektirdi.

Diğer testlerde ajanlar DNS ve güvenlik duvarı yapılandırma hatalarından geçti ya da iç servislere dış URL çektirdi. Bu, klasik SSRF mantığının ajan dünyasındaki karşılığı.

5. Bulgu 3: Gizli kanallar
En çok konuşulan kısım burası. Aynı fiziksel hostta, ayrı microVM'lerdeki ajanlardan ağ bağlantısı ve paylaşılan yazılabilir dosya kullanmadan sentetik sırları değiş tokuş etmeleri istendi:

• CPU önbelleği: Bir ajan seçili veriyi önbellekten çıkarıyor (evict), diğeri o veriyi yeniden yükleme süresini ölçüyor. Hızlı okuma ile yavaş okuma arasındaki fark bitleri taşıyor. Aynı zamanlama tekniği Spectre ve Meltdown'da da kullanılmıştı.
  
• Paylaşılan depolama: Bir ajan sürekli yazma ve boşta bekleme arasında gidip geliyor, diğeri zamanlama farklarını çözüyor.
  
• CPU zamanı rekabeti ve çevrim dışı web altyapısındaki TLS sertifika önbelleği de kanal olarak kullanıldı.
  

6. Raporun kendi çekinceleri
Haberi abartmamak için şunları bilmek gerekiyor:

• Testlerin çoğunda ajanlara hangi kanalı araştıracakları söylendi ya da kodlama protokolü verildi. Sadece bir senaryoda ajanlara genel bir zafiyet listesi verildi ve kanalı kendileri kurdular.
  
• OpenAI'ye göre bu kanalların çoğu yavaş ve modellerin istismar etmesi zor.
  
• OpenAI'nin yanıtı kanalları kaldırmak değil, izleme sistemine bu girişimleri tespit eden kontroller eklemek oldu.
  

7. Kendi ajan altyapınız için kontrol listesi
Kod çalıştıran YZ ajanları (kod asistanları, otomasyon botları, değerlendirme sandbox'ları) kullanıyorsanız raporun pratik karşılığı:

1. Çıkış trafiğini varsayılan olarak kapatın. Metrik, log ve kimlik doğrulama için bıraktığınız "küçük" istisnalar en zayıf halka çıktı.
   
2. İç servislerde SSRF'e karşı allowlist uygulayın. Ajanın ulaşabildiği hiçbir servis, ajanın verdiği URL'yi kör körüne çekmemeli.
   
3. DNS'i de bir çıkış kanalı sayın. Sadece izinli çözümleyiciye izin verin, sorguları loglayın.
   
4. Birbirine güvenmeyen iş yüklerini aynı fiziksel çekirdekte çalıştırmayın.
   
5. Sandbox bileşenlerini güncel tutun: Kata, gVisor, Docker/Moby ve çekirdek yamaları.
   
6. Ajan oturumlarını loglayın ve otomatik durdurma kuralı koyun.
   

Basit bir çıkış kısıtlaması örneği (nftables, lab ortamı için):

Sonuç
Bu rapor, YZ ajanlarını "kutuya koymanın" ne kadar zor olduğunu bir YZ şirketinin kendi ağzından gösteriyor. Ders aslında klasik: en az yetki, çıkış filtreleme, SSRF koruması ve güncel izolasyon katmanları. Siz kod çalıştıran ajanları nasıl izole ediyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

• https://openai.com/index/securing-our-fr...vironment/
  
• https://thehackernews.com/2026/10/openai...capes.html
  
• https://the-decoder.com/openais-isolated...cpu-cache/
  

Ek Dosyalar

Ekran Görüntüleri