<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Zararlı Yazılım Analizi]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:39 +0000 MyBB <![CDATA[Heartbreaker: Kendini Yeniden Derleyen macOS Fidye Yazılımı ve Davranış Tespiti]]> https://www.turkteam.org/konu-heartbreaker-kendini-yeniden-derleyen-macos-fidye-yazilimi-ve-davranis-tespiti.html Sun, 25 Oct 2026 11:41:16 +0300 Tonyukuk]]> https://www.turkteam.org/konu-heartbreaker-kendini-yeniden-derleyen-macos-fidye-yazilimi-ve-davranis-tespiti.html [Resim: attachment.php?aid=425]
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:
Kod:
12 bayt nonce || şifremetni || 16 bayt GCM doğrulama etiketi
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:
Kod:
~/Library/LaunchAgents/com.network.startup.plist
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

.png   09-t09-heartbreaker-metamorfik-ransomware.png (Dosya Boyutu: 113.88 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=425]
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:
Kod:
12 bayt nonce || şifremetni || 16 bayt GCM doğrulama etiketi
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:
Kod:
~/Library/LaunchAgents/com.network.startup.plist
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

.png   09-t09-heartbreaker-metamorfik-ransomware.png (Dosya Boyutu: 113.88 KB / İndirme Sayısı: 1) ]]> <![CDATA[Lazarus FlashHole: Zararlı Yazılım Dağıtımında Post-Kuantum Şifreleme (ML-KEM)]]> https://www.turkteam.org/konu-lazarus-flashhole-zararli-yazilim-dagitiminda-post-kuantum-sifreleme-ml-kem.html Sun, 25 Oct 2026 11:37:53 +0300 Tonyukuk]]> https://www.turkteam.org/konu-lazarus-flashhole-zararli-yazilim-dagitiminda-post-kuantum-sifreleme-ml-kem.html [Resim: attachment.php?aid=421]
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:
Kod:
1) LPEClient, C2'den dört adet 1.568 baytlık blok alıyor (her biri bir ML-KEM-1024 açık anahtarı) 2) Bu bloklardan dört ayrı paylaşılan anahtar/şifremetni çifti üretiyor 3) Şifremetinlerini GOST algoritmasıyla şifreleyip ClientHub ile C2'ye yolluyor 4) Paylaşılan sırlar Threefish için anahtar malzemesi sağlar 5) Threefish, parametreleri ve çalıştırılabilir payload'u içeren yanıtı çözer 6) Nihai payload Cubridge'dir ve belleğe reflective olarak yüklenir

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

.png   05-t05-lazarus-flashhole-postkuantum.png (Dosya Boyutu: 112.9 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=421]
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:
Kod:
1) LPEClient, C2'den dört adet 1.568 baytlık blok alıyor (her biri bir ML-KEM-1024 açık anahtarı) 2) Bu bloklardan dört ayrı paylaşılan anahtar/şifremetni çifti üretiyor 3) Şifremetinlerini GOST algoritmasıyla şifreleyip ClientHub ile C2'ye yolluyor 4) Paylaşılan sırlar Threefish için anahtar malzemesi sağlar 5) Threefish, parametreleri ve çalıştırılabilir payload'u içeren yanıtı çözer 6) Nihai payload Cubridge'dir ve belleğe reflective olarak yüklenir

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

.png   05-t05-lazarus-flashhole-postkuantum.png (Dosya Boyutu: 112.9 KB / İndirme Sayısı: 1) ]]> <![CDATA[BlackX UEFI Bootkit: APT41 Merkezi Asya'da Yamanan Sistemlerde Secure Boot'u Aştı]]> https://www.turkteam.org/konu-blackx-uefi-bootkit-apt41-merkezi-asya-da-yamanan-sistemlerde-secure-boot-u-asti.html Sat, 24 Oct 2026 11:24:15 +0300 Tonyukuk]]> https://www.turkteam.org/konu-blackx-uefi-bootkit-apt41-merkezi-asya-da-yamanan-sistemlerde-secure-boot-u-asti.html [Resim: attachment.php?aid=398]
Selamlar,

Kaspersky GReAT, 22 Ekim 2026'da BlackX adlı bir UEFI bootkit kampanyasını duyurdu. Hedef: Tacikistan, Özbekistan ve Türkmenistan'daki diplomatik kurumlar. Orta güvenle APT41 ile ilişkilendiriliyor. Çarpıcı nokta: makineler yamalıydı; sorun, Baton Drop (CVE-2022-21894 / CVE-2023-24932 hattı) iptallerinin elle etkinleştirilmesi gerektiği halde çoğu ortamda hiç açılmamış olması.

Konuda anlatılacaklar
  1. BlackX nasıl kuruluyor?
  2. Yük ve kalıcılık
  3. Neden yama yetmedi?
  4. Elle Secure Boot iptali (özet)
  5. Tespit fikirleri

1. Kurulum
Saldırganlar önce yönetici yetkisi alıyor; sonra inst.exe + RC4 ile şifreli PVMDIJGKAX2 paketini bırakıyor. Paket, Baton Drop zinciriyle özel Machine Owner Key (MOK) kuruyor; böylece keyfi EFI dosyaları yüklenebiliyor. BlackLotus ile benzerlik yüksek; kaynak kodu kamuya açık olmadığı için tersine mühendislik veya satın alma ihtimali konuşuluyor.

2. Yük
Bootkit, Windows çekirdeğine sürücü enjekte ediyor. Sürücü güvenlik ürünü geri çağrılarını ve ETW sağlayıcılarını bozmaya çalışıyor; bootkit dosyalarına açılış isteklerini calc.exe'ye yönlendiriyor. Kullanıcı modunda bulut depolama (Google Drive / OneDrive / Yandex.Disk) kullanan bir RAT ve OLLVM ile karartılmış OxiDLLRunner görülmüş. C2 örneği: www[.]archivetj[.]com.

3. Neden yama yetmedi?
Microsoft'un Baton Drop azaltımı "Windows Production PCA 2011" sertifikasını DBX'e eklemeyi gerektiriyor; bu adım varsayılan olarak kapalı. Yönetici kayıt defteri bayrağı + Secure-Boot-Update zamanlanmış görevi ile elle tetiklenmeli. Otomatik "Enforcement Phase" hâlâ ilan edilmemiş. 19 Ekim 2026'da sertifika süresi dolsa da blocklist'e eklenmeden savunmasız ikililer yüklenmeye devam edebiliyor.

4. Elle iptal (kısa hatırlatma)
Microsoft KB5025885 sürecinin özeti (üretimde uygulamadan önce laboratuvarda test edin; geri alınamaz):
  1. Son güvenlik güncellemelerini kurun.
  2. BitLocker kurtarma anahtarını yedekleyin.
  3. DB'ye 2023 UEFI CA ekleyin ve boot manager'ı güncelleyin.
  4. PCA 2011'i DBX'e ekleyerek iptal edin.
  5. Kurtarma medyasını yeni boot dosyalarıyla yenileyin.
Çift önyükleme ve eski kurtarma USB'leri bozulabilir; cihaz sınıfı başına önce pilot yapın.

5. Tespit fikirleri
  • EFI bölümünde beklenmeyen dosyalar / MOK değişiklikleri.
  • ProgramData\Intel\inst.exe benzeri kurulum artıkları.
  • İptal edilmiş "Wenjiang District Mingyu..." sertifikasıyla imzalı sürücüler.
  • googleupdate.exe / jcef_helper.exe üzerinden DLL sideloading.

Ortamınızda Secure Boot DBX iptallerini etkinleştirdiniz mi, yoksa hâlâ varsayılan 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

.png   09-t09-blackx-uefi.png (Dosya Boyutu: 115.24 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=398]
Selamlar,

Kaspersky GReAT, 22 Ekim 2026'da BlackX adlı bir UEFI bootkit kampanyasını duyurdu. Hedef: Tacikistan, Özbekistan ve Türkmenistan'daki diplomatik kurumlar. Orta güvenle APT41 ile ilişkilendiriliyor. Çarpıcı nokta: makineler yamalıydı; sorun, Baton Drop (CVE-2022-21894 / CVE-2023-24932 hattı) iptallerinin elle etkinleştirilmesi gerektiği halde çoğu ortamda hiç açılmamış olması.

Konuda anlatılacaklar
  1. BlackX nasıl kuruluyor?
  2. Yük ve kalıcılık
  3. Neden yama yetmedi?
  4. Elle Secure Boot iptali (özet)
  5. Tespit fikirleri

1. Kurulum
Saldırganlar önce yönetici yetkisi alıyor; sonra inst.exe + RC4 ile şifreli PVMDIJGKAX2 paketini bırakıyor. Paket, Baton Drop zinciriyle özel Machine Owner Key (MOK) kuruyor; böylece keyfi EFI dosyaları yüklenebiliyor. BlackLotus ile benzerlik yüksek; kaynak kodu kamuya açık olmadığı için tersine mühendislik veya satın alma ihtimali konuşuluyor.

2. Yük
Bootkit, Windows çekirdeğine sürücü enjekte ediyor. Sürücü güvenlik ürünü geri çağrılarını ve ETW sağlayıcılarını bozmaya çalışıyor; bootkit dosyalarına açılış isteklerini calc.exe'ye yönlendiriyor. Kullanıcı modunda bulut depolama (Google Drive / OneDrive / Yandex.Disk) kullanan bir RAT ve OLLVM ile karartılmış OxiDLLRunner görülmüş. C2 örneği: www[.]archivetj[.]com.

3. Neden yama yetmedi?
Microsoft'un Baton Drop azaltımı "Windows Production PCA 2011" sertifikasını DBX'e eklemeyi gerektiriyor; bu adım varsayılan olarak kapalı. Yönetici kayıt defteri bayrağı + Secure-Boot-Update zamanlanmış görevi ile elle tetiklenmeli. Otomatik "Enforcement Phase" hâlâ ilan edilmemiş. 19 Ekim 2026'da sertifika süresi dolsa da blocklist'e eklenmeden savunmasız ikililer yüklenmeye devam edebiliyor.

4. Elle iptal (kısa hatırlatma)
Microsoft KB5025885 sürecinin özeti (üretimde uygulamadan önce laboratuvarda test edin; geri alınamaz):
  1. Son güvenlik güncellemelerini kurun.
  2. BitLocker kurtarma anahtarını yedekleyin.
  3. DB'ye 2023 UEFI CA ekleyin ve boot manager'ı güncelleyin.
  4. PCA 2011'i DBX'e ekleyerek iptal edin.
  5. Kurtarma medyasını yeni boot dosyalarıyla yenileyin.
Çift önyükleme ve eski kurtarma USB'leri bozulabilir; cihaz sınıfı başına önce pilot yapın.

5. Tespit fikirleri
  • EFI bölümünde beklenmeyen dosyalar / MOK değişiklikleri.
  • ProgramData\Intel\inst.exe benzeri kurulum artıkları.
  • İptal edilmiş "Wenjiang District Mingyu..." sertifikasıyla imzalı sürücüler.
  • googleupdate.exe / jcef_helper.exe üzerinden DLL sideloading.

Ortamınızda Secure Boot DBX iptallerini etkinleştirdiniz mi, yoksa hâlâ varsayılan 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

.png   09-t09-blackx-uefi.png (Dosya Boyutu: 115.24 KB / İndirme Sayısı: 2) ]]> <![CDATA[MythicRatatoskr: Sandworm ve UAC-0099 Yggdrasil Mesh Ağını C2 Olarak Kullandı]]> https://www.turkteam.org/konu-mythicratatoskr-sandworm-ve-uac-0099-yggdrasil-mesh-agini-c2-olarak-kullandi.html Sat, 24 Oct 2026 11:18:58 +0300 Tonyukuk]]> https://www.turkteam.org/konu-mythicratatoskr-sandworm-ve-uac-0099-yggdrasil-mesh-agini-c2-olarak-kullandi.html [Resim: attachment.php?aid=393]
Selamlar,

ESET Research, 22 Ekim 2026'da yayımladığı raporda daha önce belgelenmemiş bir arka kapıyı anlattı: MythicRatatoskr. Go ile yazılmış bu araç, C2 sunucusunu Yggdrasil adlı deneysel bir mesh (örgü) ağının içinde barındırıyor. UAC-0099 ilk erişimi aldıktan sonra erişim Sandworm'a devredilmiş; Sandworm da 17 Eylül 2025'te Active Directory Group Policy üzerinden SDelete ile veri silme saldırmış. Bu konu, raporun savunma odaklı Türkçe özeti.

Konuda anlatılacaklar
  1. Olayın zaman çizelgesi
  2. Yggdrasil nedir, neden seçilmiş olabilir?
  3. MythicRatatoskr yetenekleri
  4. Barındırma ve kalıcılık izleri
  5. Savunma tarafında ne aranmalı?

1. Zaman çizelgesi (ESET)
  • 16 Temmuz 2025: UAC-0099, Ukrayna'daki bir tahıl lojistik firmasına spearfishing ile girdi; MATCHBOIL/MATCHWOK zinciri.
  • 17 Temmuz 2025: MythicRatatoskr dağıtıldı; ardından SOCKS5 proxy.
  • 17 Eylül 2025: Sandworm, SDelete + GPO ile yıkıcı veri silme.
ESET, UAC-0099'un Sandworm için ilk erişim aracısı gibi hareket edebileceğini yüksek güvenle değerlendiriyor.

2. Yggdrasil nedir?
Yggdrasil, uçtan uca korumalı IPv6 üst katmanı kuran merkezi olmayan bir mesh ağdır. Her düğüm kendi Ed25519 anahtar çiftini üretir; adres 200::/7 aralığından türetilir. Anonimlik hedefi değildir. MythicRatatoskr, gömülü genel eş (peer) listesinden rastgele üç eş seçip ağa katılıyor; C2 ile HTTPS/443 üzerinden JSON konuşuyor. Ağ güvenlik araçları klasik C2 IP'si göremeyebilir; halka açık eş adreslerini engellemek ise uygulanabilir bir azaltımdır.

3. Yetenekler
ESET'e göre komutlar arasında shell (cmd.exe), dosya yükleme/indirme, ekran görüntüsü, dizin gezinme, yerel port açma (expose) ve ters SOCKS5 proxy var. Bazı örneklerde 10 dakikalık başlangıç gecikmesi var (tespiti zorlaştırmak için). Yapılandırma AES-256-CFB ile şifreli; kalıcılık Windows servisi ieupdate üzerinden.

4. Barındırma izleri
Örnek yollar (ESET tablosu):
Kod:
C:\windows\system32\updater.exe C:\Windows\system32\krbtman.exe C:\windows\system32\windowsdefendersvc.exe %localappdata%\Microsoft\OneDrive\OneDriveLiveUpdater.exe Yapilandirma: C:\Windows\Temp\.updatecache
Bazı örneklerde Unix tarzı yolların (ör. /tmp/.test_config) bırakılması Linux varyantının da olabileceğine işaret ediyor.

5. Savunma tarafında ne aranmalı?
  1. Yggdrasil genel eş adreslerine (tls:// ve quic://) giden beklenmeyen çıkış trafiği.
  2. ieupdate adlı Windows servisi ve yukarıdaki dosya yolları.
  3. 127.0.0.1:33690 üzerinde dinleyen SOCKS5 (ESET'in gördüğü ayrı proxy aracı).
  4. PowerShell ile %temp%\temporarydoc.txt benzeri görevler (MATCHBOIL zinciri).
  5. GPO ile dağıtılan SDelete / beklenmeyen toplu silme.
Bu yazı yalnızca savunma ve farkındalık içindir; mesh ağın kendisi meşru bir projedir, kötüye kullanım anlatılmaktadır.

Kurumunuzda mesh/P2P ağ trafiğini SIEM'de nasıl görünür kılı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

.png   04-t04-mythicratatoskr-yggdrasil.png (Dosya Boyutu: 123.36 KB / İndirme Sayısı: 0) ]]> [Resim: attachment.php?aid=393]
Selamlar,

ESET Research, 22 Ekim 2026'da yayımladığı raporda daha önce belgelenmemiş bir arka kapıyı anlattı: MythicRatatoskr. Go ile yazılmış bu araç, C2 sunucusunu Yggdrasil adlı deneysel bir mesh (örgü) ağının içinde barındırıyor. UAC-0099 ilk erişimi aldıktan sonra erişim Sandworm'a devredilmiş; Sandworm da 17 Eylül 2025'te Active Directory Group Policy üzerinden SDelete ile veri silme saldırmış. Bu konu, raporun savunma odaklı Türkçe özeti.

Konuda anlatılacaklar
  1. Olayın zaman çizelgesi
  2. Yggdrasil nedir, neden seçilmiş olabilir?
  3. MythicRatatoskr yetenekleri
  4. Barındırma ve kalıcılık izleri
  5. Savunma tarafında ne aranmalı?

1. Zaman çizelgesi (ESET)
  • 16 Temmuz 2025: UAC-0099, Ukrayna'daki bir tahıl lojistik firmasına spearfishing ile girdi; MATCHBOIL/MATCHWOK zinciri.
  • 17 Temmuz 2025: MythicRatatoskr dağıtıldı; ardından SOCKS5 proxy.
  • 17 Eylül 2025: Sandworm, SDelete + GPO ile yıkıcı veri silme.
ESET, UAC-0099'un Sandworm için ilk erişim aracısı gibi hareket edebileceğini yüksek güvenle değerlendiriyor.

2. Yggdrasil nedir?
Yggdrasil, uçtan uca korumalı IPv6 üst katmanı kuran merkezi olmayan bir mesh ağdır. Her düğüm kendi Ed25519 anahtar çiftini üretir; adres 200::/7 aralığından türetilir. Anonimlik hedefi değildir. MythicRatatoskr, gömülü genel eş (peer) listesinden rastgele üç eş seçip ağa katılıyor; C2 ile HTTPS/443 üzerinden JSON konuşuyor. Ağ güvenlik araçları klasik C2 IP'si göremeyebilir; halka açık eş adreslerini engellemek ise uygulanabilir bir azaltımdır.

3. Yetenekler
ESET'e göre komutlar arasında shell (cmd.exe), dosya yükleme/indirme, ekran görüntüsü, dizin gezinme, yerel port açma (expose) ve ters SOCKS5 proxy var. Bazı örneklerde 10 dakikalık başlangıç gecikmesi var (tespiti zorlaştırmak için). Yapılandırma AES-256-CFB ile şifreli; kalıcılık Windows servisi ieupdate üzerinden.

4. Barındırma izleri
Örnek yollar (ESET tablosu):
Kod:
C:\windows\system32\updater.exe C:\Windows\system32\krbtman.exe C:\windows\system32\windowsdefendersvc.exe %localappdata%\Microsoft\OneDrive\OneDriveLiveUpdater.exe Yapilandirma: C:\Windows\Temp\.updatecache
Bazı örneklerde Unix tarzı yolların (ör. /tmp/.test_config) bırakılması Linux varyantının da olabileceğine işaret ediyor.

5. Savunma tarafında ne aranmalı?
  1. Yggdrasil genel eş adreslerine (tls:// ve quic://) giden beklenmeyen çıkış trafiği.
  2. ieupdate adlı Windows servisi ve yukarıdaki dosya yolları.
  3. 127.0.0.1:33690 üzerinde dinleyen SOCKS5 (ESET'in gördüğü ayrı proxy aracı).
  4. PowerShell ile %temp%\temporarydoc.txt benzeri görevler (MATCHBOIL zinciri).
  5. GPO ile dağıtılan SDelete / beklenmeyen toplu silme.
Bu yazı yalnızca savunma ve farkındalık içindir; mesh ağın kendisi meşru bir projedir, kötüye kullanım anlatılmaktadır.

Kurumunuzda mesh/P2P ağ trafiğini SIEM'de nasıl görünür kılı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

.png   04-t04-mythicratatoskr-yggdrasil.png (Dosya Boyutu: 123.36 KB / İndirme Sayısı: 0) ]]> <![CDATA[BRONZE SANDCASTLE: Sandboxie DLL Sideloading ile Meterpreter Tarzı Arka Kapı]]> https://www.turkteam.org/konu-bronze-sandcastle-sandboxie-dll-sideloading-ile-meterpreter-tarzi-arka-kapi.html Thu, 22 Oct 2026 11:24:48 +0300 Tonyukuk]]> https://www.turkteam.org/konu-bronze-sandcastle-sandboxie-dll-sideloading-ile-meterpreter-tarzi-arka-kapi.html [Resim: attachment.php?aid=347]
Selamlar,

Sophos Counter Threat Unit, Ağustos 2025 - Ağustos 2026 arasında Filipinler, Tayvan, Afganistan, Namibya ve muhtemelen Güney Kore'deki kurbanlarda görülen bir Çin bağlantılı kümeyi BRONZE SANDCASTLE adıyla tanımladı. Kümenin en ayırt edici teknik imzası: Sandboxie bileşenleri üzerinden tutarlı DLL sideloading.

Konuda anlatılacaklar
  1. DLL sideloading nasıl kullanılıyor?
  2. Yükün yapısı: reflective loader ve COFFLoader izleri
  3. C2 ve keşif davranışları
  4. Savunma ve av önerileri

DLL sideloading imzası
Sophos'a göre meşru Sandboxie çalıştırılabilirleri (SandboxieWUAU.exe veya yeniden adlandırılmış Start.exe) kötü amaçlı sbiedll.dll ile yan yana bırakılıyor; güvenilen uygulama çalışma zamanında saldırganın kodunu yüklüyor. Grup yalnızca Sandboxie ile sınırlı değil; raporlanan diğer taşıyıcı/DLL çiftleri:
Kod:
javaw.exe + jli.dll Krita.exe + Krita.dll NvdaHelper.exe + NvdaHelperRemote.dll Jcef_helper.exe + Libcef.dll Vmmap.exe + Version.dll LineAppMgr.exe + msvcp140.dll bginfo64.exe + snmpapi.dll
Sideload edilen DLL'ler genellikle şifreli config.ini dosyasını okuyup çalıştırıyor. Bu tasarım, statik dosya tespitini zorlaştırıyor ve operatörlerin DLL'yi değiştirmeden davranışı ayarlamasına izin veriyor. Yeniden adlandırılmış meşru çalıştırılabilirler ortamda "doğal" görünmek için sık kullanılıyor; yürütme sonucu diskte ek artefakt yerine bellek içi shellcode aktivitesi oluyor.

Yükün yapısı
Çözülen yük, bellek içinde yüzeysel olarak bir Windows çalıştırılabilirini andıran bir arka kapı. Dosya başlığı konumdan bağımsız bir PE yükleyici/çalıştırma stub'ı (reflective loader). Yapısal olarak Metasploit Framework'ün stageless shellcode yüklerine benziyor: konumdan bağımsız yürütme, manuel PE doğrulama, gömülü çalıştırılabilirin bellek içi yüklenmesi. Ancak API çözümleme mantığı Metasploit'in bilinen ROR13 algoritması yerine özel hash/dönüşüm rutinleri kullanıyor ve kod tabanı tipik MSF shellcode'undan belirgin biçimde daha büyük.

Örneklerde ayrıca COFFLoader projesine ait unsurlar görülmüş; bu da yazarın özel Beacon Object File (BOF) özellikleriyle kendi post-exploitation yeteneklerini eklediğini düşündürüyor. Sophos iki sürüm tespit etti: 1.1.5 ve 1.1.7. Yük, C2'ye iç içe "info" bloğu içeren yapılandırılmış bir JSON nesnesi gönderiyor: hostname, kullanıcı adı, GUID, domain, OS sürümü, iç/dış IP, süreç listesi, çalışma dizini, kod sayfası, CPU mimarisi, implant başlangıç zamanı ve tipi (server/client).

C2 ve keşif
  • 1.1.5: dc.cathaypacifice[.]com ve net.dpworldto[.]com
  • 1.1.7: GitHub depolarından şifreli config indirme (örnek: LatonyCharnleyaW adlı az geçmişli bir depo)
  • file[.]io, gofile[.]io, ably[.]net / ably[.]io gibi meşru sitelere de erişim gözlemlenmiş (muhtemel görev alma)
Kurulum sonrası tipik keşif: Windows "net" komutlarıyla yerel ağ ve hesap numaralandırma; Active Directory kimlik bilgileri için vssadmin.exe ile Volume Shadow kopyası oluşturup ntds.dit kopyalama.

Atıf notları
Hedef coğrafya BRONZE PRESIDENT ve BRONZE ATLAS ile örtüşüyor ama teknik özellikler yeterince ayırt edici bulunmuş; bu yüzden ayrı bir küme adı verilmiş. Aktivite saatlerinin UTC+8'e yoğunlaşması Çin merkezli bir grup değerlendirmesini destekliyor.

Savunma ve av önerileri
Sophos'un vurgusu: şifreli yük ve yapılandırma dosyaları çalışma zamanında çözüldüğü için salt dosya tabanlı tespit yetersiz. Davranışsal göstergelere bakın:
  • Bir DLL'nin yerel bir dosyayı okuyup hemen ardından bellek içi yürütmeye geçmesi (çözme + sahneleme)
  • Yansıtıcı (reflective) yükleme kalıpları, bellekte anormal PE başlıkları
  • Konumdan bağımsız shellcode özellikleri gösteren süreçler
  • Kullanıcı profili, ProgramData veya temp altında Sandboxie / Sysinternals / Java yardımcı çalıştırılabilirleri yanında beklenmeyen DLL'ler

Kod:
# Windows (kendi labınız) - sideloading avı için kavramsal PowerShell Get-ChildItem -Path $env:TEMP,$env:APPDATA,$env:LOCALAPPDATA,C:\ProgramData -Recurse -Include *.dll,config.ini -ErrorAction SilentlyContinue | Where-Object { $_.DirectoryName -match 'Sandboxie|Start|javaw|Krita|Vmmap|bginfo' } | Select-Object FullName, Length, LastWriteTime # EDR: "signed application + unexpected DLL from same folder + VirtualAlloc/VirtualProtect" zincirini kurala baglayin

DLL sideloading için hangi EDR kurallarınız var? Sandboxie veya Sysinternals yardımcılarının beklenmeyen konumlarda çalışmasını izliyor musunuz?

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

.png   09-t09-bronze-sandcastle.png (Dosya Boyutu: 110.54 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=347]
Selamlar,

Sophos Counter Threat Unit, Ağustos 2025 - Ağustos 2026 arasında Filipinler, Tayvan, Afganistan, Namibya ve muhtemelen Güney Kore'deki kurbanlarda görülen bir Çin bağlantılı kümeyi BRONZE SANDCASTLE adıyla tanımladı. Kümenin en ayırt edici teknik imzası: Sandboxie bileşenleri üzerinden tutarlı DLL sideloading.

Konuda anlatılacaklar
  1. DLL sideloading nasıl kullanılıyor?
  2. Yükün yapısı: reflective loader ve COFFLoader izleri
  3. C2 ve keşif davranışları
  4. Savunma ve av önerileri

DLL sideloading imzası
Sophos'a göre meşru Sandboxie çalıştırılabilirleri (SandboxieWUAU.exe veya yeniden adlandırılmış Start.exe) kötü amaçlı sbiedll.dll ile yan yana bırakılıyor; güvenilen uygulama çalışma zamanında saldırganın kodunu yüklüyor. Grup yalnızca Sandboxie ile sınırlı değil; raporlanan diğer taşıyıcı/DLL çiftleri:
Kod:
javaw.exe + jli.dll Krita.exe + Krita.dll NvdaHelper.exe + NvdaHelperRemote.dll Jcef_helper.exe + Libcef.dll Vmmap.exe + Version.dll LineAppMgr.exe + msvcp140.dll bginfo64.exe + snmpapi.dll
Sideload edilen DLL'ler genellikle şifreli config.ini dosyasını okuyup çalıştırıyor. Bu tasarım, statik dosya tespitini zorlaştırıyor ve operatörlerin DLL'yi değiştirmeden davranışı ayarlamasına izin veriyor. Yeniden adlandırılmış meşru çalıştırılabilirler ortamda "doğal" görünmek için sık kullanılıyor; yürütme sonucu diskte ek artefakt yerine bellek içi shellcode aktivitesi oluyor.

Yükün yapısı
Çözülen yük, bellek içinde yüzeysel olarak bir Windows çalıştırılabilirini andıran bir arka kapı. Dosya başlığı konumdan bağımsız bir PE yükleyici/çalıştırma stub'ı (reflective loader). Yapısal olarak Metasploit Framework'ün stageless shellcode yüklerine benziyor: konumdan bağımsız yürütme, manuel PE doğrulama, gömülü çalıştırılabilirin bellek içi yüklenmesi. Ancak API çözümleme mantığı Metasploit'in bilinen ROR13 algoritması yerine özel hash/dönüşüm rutinleri kullanıyor ve kod tabanı tipik MSF shellcode'undan belirgin biçimde daha büyük.

Örneklerde ayrıca COFFLoader projesine ait unsurlar görülmüş; bu da yazarın özel Beacon Object File (BOF) özellikleriyle kendi post-exploitation yeteneklerini eklediğini düşündürüyor. Sophos iki sürüm tespit etti: 1.1.5 ve 1.1.7. Yük, C2'ye iç içe "info" bloğu içeren yapılandırılmış bir JSON nesnesi gönderiyor: hostname, kullanıcı adı, GUID, domain, OS sürümü, iç/dış IP, süreç listesi, çalışma dizini, kod sayfası, CPU mimarisi, implant başlangıç zamanı ve tipi (server/client).

C2 ve keşif
  • 1.1.5: dc.cathaypacifice[.]com ve net.dpworldto[.]com
  • 1.1.7: GitHub depolarından şifreli config indirme (örnek: LatonyCharnleyaW adlı az geçmişli bir depo)
  • file[.]io, gofile[.]io, ably[.]net / ably[.]io gibi meşru sitelere de erişim gözlemlenmiş (muhtemel görev alma)
Kurulum sonrası tipik keşif: Windows "net" komutlarıyla yerel ağ ve hesap numaralandırma; Active Directory kimlik bilgileri için vssadmin.exe ile Volume Shadow kopyası oluşturup ntds.dit kopyalama.

Atıf notları
Hedef coğrafya BRONZE PRESIDENT ve BRONZE ATLAS ile örtüşüyor ama teknik özellikler yeterince ayırt edici bulunmuş; bu yüzden ayrı bir küme adı verilmiş. Aktivite saatlerinin UTC+8'e yoğunlaşması Çin merkezli bir grup değerlendirmesini destekliyor.

Savunma ve av önerileri
Sophos'un vurgusu: şifreli yük ve yapılandırma dosyaları çalışma zamanında çözüldüğü için salt dosya tabanlı tespit yetersiz. Davranışsal göstergelere bakın:
  • Bir DLL'nin yerel bir dosyayı okuyup hemen ardından bellek içi yürütmeye geçmesi (çözme + sahneleme)
  • Yansıtıcı (reflective) yükleme kalıpları, bellekte anormal PE başlıkları
  • Konumdan bağımsız shellcode özellikleri gösteren süreçler
  • Kullanıcı profili, ProgramData veya temp altında Sandboxie / Sysinternals / Java yardımcı çalıştırılabilirleri yanında beklenmeyen DLL'ler

Kod:
# Windows (kendi labınız) - sideloading avı için kavramsal PowerShell Get-ChildItem -Path $env:TEMP,$env:APPDATA,$env:LOCALAPPDATA,C:\ProgramData -Recurse -Include *.dll,config.ini -ErrorAction SilentlyContinue | Where-Object { $_.DirectoryName -match 'Sandboxie|Start|javaw|Krita|Vmmap|bginfo' } | Select-Object FullName, Length, LastWriteTime # EDR: "signed application + unexpected DLL from same folder + VirtualAlloc/VirtualProtect" zincirini kurala baglayin

DLL sideloading için hangi EDR kurallarınız var? Sandboxie veya Sysinternals yardımcılarının beklenmeyen konumlarda çalışmasını izliyor musunuz?

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

.png   09-t09-bronze-sandcastle.png (Dosya Boyutu: 110.54 KB / İndirme Sayısı: 7) ]]> <![CDATA[AutoCAD DWG İçinde Yetim VBA Projesi: Didier Stevens YARA Kuralı]]> https://www.turkteam.org/konu-autocad-dwg-icinde-yetim-vba-projesi-didier-stevens-yara-kurali.html Wed, 21 Oct 2026 11:28:26 +0300 BilgeKagan]]> https://www.turkteam.org/konu-autocad-dwg-icinde-yetim-vba-projesi-didier-stevens-yara-kurali.html [Resim: attachment.php?aid=331]
Merhaba,

Didier Stevens (SANS ISC) Ekim 2026'da AutoCAD DWG dosyalarında "yetim" (orphaned) VBA projelerini yazdı. DWG başlığındaki 0x24 ofsetindeki 32-bit işaretçi sıfır olsa bile brute-force OLE araması VBA projesi bulabiliyor. AutoCAD bu yetim projeyi "görmez"; yani dosya açılınca VBA çalışmamış olabilir. Analizde yanlış pozitif sonuç çıkarmamak için önemli.

Normal yol
VBA, DWG içine gömülü OLE olarak durur. autocad.py işaretçiyi okur; cut-bytes.py ile oyulur; oledump.py ile incelenir:
Kod:
cut-bytes.py -S autocad.py -P AutoCAD : ornek.dwg.zip | oledump.py
İşaretçi 0 ise script boş döner — genelde gömülü OLE yok demektir.

Yetim istisna
Stevens'ın örneklerinde işaretçi 0, fakat oledump gömülü OLE + VBA buluyor; hemen öncesinde 16 baytlık uzunluk başlığı da duruyor. Muhtemel neden: AutoLISP
Kod:
(dictremove (namedobjdict) "ACAD_VBA")
işaretçiyi temizleyip gövdeyi bırakıyor olabilir.

YARA (18 Ekim günlüğü)
Kod:
rule autocad_orphaned_vba_project { strings: $a = "AC10" $b = { D0 CF 11 E0 A1 B1 1A E1 } $c = "[Host Extender Info]" ascii condition: $a at 0 and uint32(0x24) == 0 and $b and $c }
VirusTotal retrohunt'ta kural yalnızca iki örneği yakalamış (hash'ler ISC günlüğünde). Yani nadir ama gerçek.

Analist kontrol listesi
  • oledump VBA bulduysa 0x24 işaretçisini de kontrol edin
  • Yetim ise "açılınca çalıştı" sonucuna atlamayın
  • Varsayılan AutoCAD kurulumunda VBA ayrı bileşendir
  • Şüpheli DWG'leri izole labda açın

Yasal uyarı
Zararlı örnekleri yalnızca izole ortamda inceleyin. TCK 243-245.

Kaynaklar
Pipeline'a eklemek
DWG kabul eden mail ağ geçidi veya CAD paylaşım klasöründe YARA kuralını çalıştırın. Yetim VBA = otomatik "kötü" değil; analist notu düşün. VBA destekli AutoCAD kurulum politikasını envanterleyin.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

.png   14-b04-dwg-vba.png (Dosya Boyutu: 113.43 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=331]
Merhaba,

Didier Stevens (SANS ISC) Ekim 2026'da AutoCAD DWG dosyalarında "yetim" (orphaned) VBA projelerini yazdı. DWG başlığındaki 0x24 ofsetindeki 32-bit işaretçi sıfır olsa bile brute-force OLE araması VBA projesi bulabiliyor. AutoCAD bu yetim projeyi "görmez"; yani dosya açılınca VBA çalışmamış olabilir. Analizde yanlış pozitif sonuç çıkarmamak için önemli.

Normal yol
VBA, DWG içine gömülü OLE olarak durur. autocad.py işaretçiyi okur; cut-bytes.py ile oyulur; oledump.py ile incelenir:
Kod:
cut-bytes.py -S autocad.py -P AutoCAD : ornek.dwg.zip | oledump.py
İşaretçi 0 ise script boş döner — genelde gömülü OLE yok demektir.

Yetim istisna
Stevens'ın örneklerinde işaretçi 0, fakat oledump gömülü OLE + VBA buluyor; hemen öncesinde 16 baytlık uzunluk başlığı da duruyor. Muhtemel neden: AutoLISP
Kod:
(dictremove (namedobjdict) "ACAD_VBA")
işaretçiyi temizleyip gövdeyi bırakıyor olabilir.

YARA (18 Ekim günlüğü)
Kod:
rule autocad_orphaned_vba_project { strings: $a = "AC10" $b = { D0 CF 11 E0 A1 B1 1A E1 } $c = "[Host Extender Info]" ascii condition: $a at 0 and uint32(0x24) == 0 and $b and $c }
VirusTotal retrohunt'ta kural yalnızca iki örneği yakalamış (hash'ler ISC günlüğünde). Yani nadir ama gerçek.

Analist kontrol listesi
  • oledump VBA bulduysa 0x24 işaretçisini de kontrol edin
  • Yetim ise "açılınca çalıştı" sonucuna atlamayın
  • Varsayılan AutoCAD kurulumunda VBA ayrı bileşendir
  • Şüpheli DWG'leri izole labda açın

Yasal uyarı
Zararlı örnekleri yalnızca izole ortamda inceleyin. TCK 243-245.

Kaynaklar
Pipeline'a eklemek
DWG kabul eden mail ağ geçidi veya CAD paylaşım klasöründe YARA kuralını çalıştırın. Yetim VBA = otomatik "kötü" değil; analist notu düşün. VBA destekli AutoCAD kurulum politikasını envanterleyin.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

.png   14-b04-dwg-vba.png (Dosya Boyutu: 113.43 KB / İndirme Sayısı: 10) ]]> <![CDATA[YARA Kurallarıyla Zararlı Yazılım Avı: Temelden Pratik Kurallara]]> https://www.turkteam.org/konu-yara-kurallariyla-zararli-yazilim-avi-temelden-pratik-kurallara.html Fri, 16 Oct 2026 11:17:26 +0300 Tonyukuk]]> https://www.turkteam.org/konu-yara-kurallariyla-zararli-yazilim-avi-temelden-pratik-kurallara.html [Resim: attachment.php?aid=20]
YARA ile Zararlı Yazılım Avı: Temelden Pratik Kurallara

Merhaba,

YARA, dosya ve bellek üzerinde imza (pattern) avlamak için endüstri standardı bir dildir. VirusTotal'ın YARA 4.5.x serisi hâlâ yaygın; yeni nesil YARA-X 1.21 de aktif geliştiriliyor. Bu rehberde kendi lab örneklerinizde güvenli şekilde kural yazmayı anlatıyoruz.

Konuda Anlatılacaklar
  1. Kurulum
  2. Kural anatomisi
  3. İlk kuralınız: metin ve hex dizileri
  4. Koşullar, jokerler, regex
  5. Dizin tarama ve CI'ye ekleme
  6. Kaynakça ve yasal uyarı

1) Kurulum
Kod:
# Klasik YARA sudo apt update && sudo apt install -y yara yara --version # YARA-X (opsiyonel, Rust temelli) # https://github.com/VirusTotal/yara-x/releases (v1.21.0 örneği)

2) Kural Anatomisi
Kod:
rule Ornek_Lab_Kurali { meta: author = "TurkTeam" description = "Lab egitimi icin ornek kural" date = "2026-10-16" strings: $a = "This program cannot be run in DOS mode" $b = { 4D 5A 90 00 } // MZ basligi $c = /https?:\/\/[a-z0-9\.\-]+\/gate\.php/i condition: uint16(0) == 0x5A4D and 2 of ($a,$b,$c) }

3) İlk Çalıştırma
Kod:
# Tek dosya yara kural.yar ornek_lab_dosyasi.bin # Dizin (özyinelemeli) yara -r kural.yar /lab/ornekler/ # Eşleşen dizileri de göster yara -s kural.yar ornek_lab_dosyasi.bin

4) Pratik İpuçları
  • MZ kontrolü: uint16(0) == 0x5A4D PE dosyalarını hızlı eleyen klasik koşuldur.
  • Geniş joker kullanmayın: Çok genel diziler yanlış pozitif üretir.
  • meta alanını doldurun: Ekip içinde kuralın neden yazıldığını anlaşılır kılar.
  • Özel zararlı örnekleri paylaşmayın: Forumda örnek dosya yüklemeyin; yalnızca kural ve IOC tartışın.

5) Küçük Alıştırma
Kod:
# 1) Lab klasöründe bilinen bir EICAR test dosyası oluşturun # (EICAR resmi test dizesi: https://www.eicar.org/) # 2) EICAR dizesini arayan bir kural yazın # 3) yara ile eşleştiğini doğrulayın

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Zararlı yazılım örneklerini yalnızca izole lab ortamında ve yasal kaynaklardan inceleyin. Dağıtmak, barındırmak veya üçüncü sistemlere bulaştırmak suçtur (TCK 243-245).


.jpg   tonyukuk-12.jpg (Dosya Boyutu: 101 KB / İndirme Sayısı: 10) ]]> [Resim: attachment.php?aid=20]
YARA ile Zararlı Yazılım Avı: Temelden Pratik Kurallara

Merhaba,

YARA, dosya ve bellek üzerinde imza (pattern) avlamak için endüstri standardı bir dildir. VirusTotal'ın YARA 4.5.x serisi hâlâ yaygın; yeni nesil YARA-X 1.21 de aktif geliştiriliyor. Bu rehberde kendi lab örneklerinizde güvenli şekilde kural yazmayı anlatıyoruz.

Konuda Anlatılacaklar
  1. Kurulum
  2. Kural anatomisi
  3. İlk kuralınız: metin ve hex dizileri
  4. Koşullar, jokerler, regex
  5. Dizin tarama ve CI'ye ekleme
  6. Kaynakça ve yasal uyarı

1) Kurulum
Kod:
# Klasik YARA sudo apt update && sudo apt install -y yara yara --version # YARA-X (opsiyonel, Rust temelli) # https://github.com/VirusTotal/yara-x/releases (v1.21.0 örneği)

2) Kural Anatomisi
Kod:
rule Ornek_Lab_Kurali { meta: author = "TurkTeam" description = "Lab egitimi icin ornek kural" date = "2026-10-16" strings: $a = "This program cannot be run in DOS mode" $b = { 4D 5A 90 00 } // MZ basligi $c = /https?:\/\/[a-z0-9\.\-]+\/gate\.php/i condition: uint16(0) == 0x5A4D and 2 of ($a,$b,$c) }

3) İlk Çalıştırma
Kod:
# Tek dosya yara kural.yar ornek_lab_dosyasi.bin # Dizin (özyinelemeli) yara -r kural.yar /lab/ornekler/ # Eşleşen dizileri de göster yara -s kural.yar ornek_lab_dosyasi.bin

4) Pratik İpuçları
  • MZ kontrolü: uint16(0) == 0x5A4D PE dosyalarını hızlı eleyen klasik koşuldur.
  • Geniş joker kullanmayın: Çok genel diziler yanlış pozitif üretir.
  • meta alanını doldurun: Ekip içinde kuralın neden yazıldığını anlaşılır kılar.
  • Özel zararlı örnekleri paylaşmayın: Forumda örnek dosya yüklemeyin; yalnızca kural ve IOC tartışın.

5) Küçük Alıştırma
Kod:
# 1) Lab klasöründe bilinen bir EICAR test dosyası oluşturun # (EICAR resmi test dizesi: https://www.eicar.org/) # 2) EICAR dizesini arayan bir kural yazın # 3) yara ile eşleştiğini doğrulayın

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Zararlı yazılım örneklerini yalnızca izole lab ortamında ve yasal kaynaklardan inceleyin. Dağıtmak, barındırmak veya üçüncü sistemlere bulaştırmak suçtur (TCK 243-245).


.jpg   tonyukuk-12.jpg (Dosya Boyutu: 101 KB / İndirme Sayısı: 10) ]]>