TürkTeam Portal

Siber güvenlik topluluğunun nabzı

Duyurular, öne çıkan konular ve topluluktan son haberler burada.

Forumlar Yeni Mesajlar Kurallar
Duyurular
 Atlassian Ekim 2026 Bülteni: 75 Üçüncü Taraf Açığı, 6'sı Kritik
TonyukukDün, 08:25 AM · Siber Güvenlik Haberleri
0 12
[Resim: attachment.php?aid=399]

Selamlar,

SecurityWeek'in 23 Ekim 2026 haberine göre Atlassian, Data Center ve Server ürünleri için Ekim güvenlik bültenini yayımladı. Listede 176 kayıt var; benzersiz CVE sayısı yaklaşık 75, bunların altı kritik. Hepsi üçüncü taraf bağımlılıklarda (Apache Tomcat, Netty, Bouncy Castle, Apache SSHD vb.). Kendi yazdığınız kod temiz olsa bile bağımlılık yüzünden risk taşıdığınızın güncel örneği.

Konuda anlatılacaklar
  1. Etkilenen ürünler
  2. Kritik CVE'ler
  3. Atlassian'ın risk notu
  4. Ne yapmalısınız?

1. Etkilenen ürünler
Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible, Jira Software, Jira Service Management.

2. Kritik CVE'ler (SecurityWeek özeti)
Kod:
CVE-2026-65637 / 65182 / 68525 Apache Tomcat (Confluence, Crowd) CVE-2026-58062 Bouncy Castle (Confluence, Crowd, Jira) CVE-2026-75595 Netty (Confluence, Jira) CVE-2026-77185 Apache SSHD (Fisheye/Crucible)
Diğer yüksek önemdekiler arasında DoS, kriptografik zayıflık, SSRF, yetkilendirme sorunları ve kod çalıştırma sınıfları var.

3. Atlassian ne diyor?
Şirket, bültendeki CVE'lerin Atlassian müşterileri için "kritik olmayan değerlendirilmiş risk" sunduğunu yazıyor ve aktif istismar bildirmedi. Yine de geçmişte (ör. CVE-2026-21589) PoC sonrası saatler içinde saldırı görüldüğü hatırlatılıyor.

4. Ne yapmalısınız?
  1. Self-hosted / Data Center envanterini çıkarın; en son sabit sürüm veya bültendeki düzeltilmiş sürüme geçin.
  2. İnternete açık Confluence/Jira örneklerini WAF + IP kısıtı arkasına alın.
  3. Bağımlılık taramasını (SCA) CI'ya ekleyin; "bizim kodumuz değil" bahanesi yama borcunu silmez.
  4. Yedek ve geri dönüş planını yükseltmeden önce doğrulayın.

Self-hosted Atlassian kullananlar: bültenleri kim takip ediyor, yama SLA'nız ne?

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

Ek DosyalarEkran Görüntüleri
   
 BlackX UEFI Bootkit: APT41 Merkezi Asya'da Yamanan Sistemlerde Secure Boot'u Aştı
TonyukukDün, 08:24 AM · Zararlı Yazılım Analizi
0 13
[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

Ek DosyalarEkran Görüntüleri
   
 Microsoft 365 Token Spreying: 79 Kurumda 497 Başarılı Giriş, Parola Yok
TonyukukDün, 08:23 AM · Mavi Takım / SOC
0 17
[Resim: attachment.php?aid=397]

Selamlar,

Huntress, 14 Temmuz - 22 Eylül 2026 arasında Microsoft 365 hesaplarına yönelik bir token spreying / replay kampanyası belgelendirdi. 79 kurumda en az 497 başarılı oturum, 200.000'den fazla başarısız deneme. Parola gerekmedi: AiTM (adversary-in-the-middle) ile MFA sonrası alınan oturum jetonları Alman barındırma sağlayıcısı 1337 Services GmbH (AS210558) IP blokundan yeniden oynatıldı. Bu konu SOC için tespit ve müdahale notları.

Konuda anlatılacaklar
  1. Saldırı nasıl işliyor?
  2. Altyapı ve IOC'ler
  3. Ele geçirme sonrası davranış
  4. Conditional Access neden kritik?
  5. Olay müdahalesi kontrol listesi

1. Saldırı nasıl işliyor?
Kurban sahte veya araya giren bir giriş sayfasından MFA'yı tamamlıyor; röle jetonu tutuyor. Dakikalar içinde aynı oturum 1337 Services adresinden görünüyor. Huntress buna "token spraying" diyor: parola spreying'in jeton hali. Kaynaklar: AiTM röleleri, cihaz kodu (device-code) phishing ve sosyal mühendislik.

2. Altyapı ve IOC'ler
Ana yeniden oynatma bloğu: 193.26.115[.]0/24. Öne çıkan adresler: .221, .199, .16, .21, .72, .210. Build A: node kullanıcı aracısı + OAuth2:Token + sahte Entra cihazı (DESKTOP- + 8 hex karakter). Build B: tarayıcı oturumu yeniden oynatma. En az 48 sahte cihaz kaydı görülmüş.

3. Ele geçirme sonrası
  • Mevcut MFA yöntemlerini silip kendi authenticator'larını ekleme (19 kurumda ilk 3 saat içinde).
  • Gizli gelen kutusu kuralları: ".", "sss", "s", "d" gibi kısa isimler; RSS Feeds / Conversation History'ye taşıma.
  • Bir vakada maaş bordrosu temalı dışarı e-posta.
Parola sıfırlamak tek başına yetmez; jeton, cihaz ve MFA yöntemi kalır.

4. Conditional Access
Phase 3'te aynı saldırgan IP'sinden 1.052 engellenmiş giriş yalnızca dört kurumdan gelmiş; 29 kurumda ise hiçbir şey engel olmamış. Huntress önerisi: All Users + All Cloud Apps + All Client Apps için koşulsuz MFA veya engelleme. Cihaz kodu akışını authentication-flow politikalarıyla kısıtlayın.

5. Müdahale kontrol listesi
  1. Oturumları iptal edin (revoke) ve parolayı sıfırlayın.
  2. Entra cihazlarını denetleyin; DESKTOP- + 8 hex kalıbını doğrulayarak silin.
  3. MFA yöntemlerini denetleyin; tanınmayan authenticator'ı kaldırın.
  4. Gelen kutusu kurallarını (özellikle kısa/noktalama isimli) inceleyin.
  5. Hosting IP'lerinden OAuth2:Token / Device Registration Service girişlerini avlayın.
  6. AADSTS53003 (Conditional Access engeli) geçerli kimlik bilgisi işaretidir; "kurtardık" sanmayın.

Tenant'ınızda Conditional Access tüm istemci uygulamalarını kapsıyor mu, yoksa boşluklar var 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

Ek DosyalarEkran Görüntüleri
   
 Phantom Çerçevesi: Fidye Yazılımı Ortakları Yapay Zeka Ajanlarıyla Sızma Yapıyor
TonyukukDün, 08:22 AM · Yapay Zeka Güvenliği
0 3
[Resim: attachment.php?aid=396]

Selamlar,

SOCRadar'ın ifşa ettiği altyapı, fidye yazılımı ekosisteminde yeni bir modeli belgelendiriyor: Phantom adlı "Autonomous Red Team Kill Chain Framework". The Hacker News'in 23 Ekim 2026 özetine göre INC ve The Gentlemen gruplarının ortakları, OpenCode + OpenRouter üzerinden ticari modellerle sızmayı yürütüyor; insan operatör her adımı onaylıyor. Bu konu, savunma ekiplerinin bilmesi gereken pratik çıkarımlara odaklanıyor.

Konuda anlatılacaklar
  1. Operasyon modeli
  2. İlk erişimde sömürülen kenar cihazlar
  3. Araç seti
  4. Gasp (extortion) taktiği
  5. Savunma öncelikleri

1. Operasyon modeli
İnsan operatör kurban-özel bir istem (prompt) yazıyor; model komutları çalıştırıyor; operatör her adımı inceliyor. Model reddederse istek "yetkili red team değerlendirmesi" diye yeniden yazılıyor. Açığa çıkan dizinde 133 oturumda 8.257 mesaj kaydı görülmüş. Tahmini 62 kurum hedeflenmiş; dördü INC / The Gentlemen sızıntı sitelerine düşmüş. Hedeflerin yarısından fazlası ABD; sanayi, üretim ve enerji önde.

2. Kenar cihaz açıkları
Operatör kayıtlarında şu açıklar geçiyor (SOCRadar / THN):
Kod:
CVE-2024-57727 SimpleHelp path traversal (aktif) CVE-2026-35616 FortiClient EMS auth bypass (aktif) CVE-2026-41940 cPanel/WHM auth bypass (aktif) CVE-2026-15409 SonicWall SMA 1000 SSRF (hazirlik) CVE-2026-63030 WordPress wp2shell (gelistirilmis)
İçeride: alan envanteri, mümkünse domain admin, stealer ile kimlik bilgisi, finans/İK/hukuk/yönetici dosyaları, reverse-SOCKS ile dışarı aktarma. Tek yeniden kullanılan parola bazen VPN, sunucu, RMM ve yedek platformlarını birden açmış.

3. Araç seti
  • Phantom: 18 beceri modüllü AI saldırı çerçevesi.
  • WormGPT-MCP: 32 MCP sunucusu (keşiften gaspa).
  • Ghost C2: Cloudflare / Telegram / DNS üzerinden polimorfik implantlar.
  • RevSocks: Ağ içinde pivot.
  • BYOVD ile EDR engelleme denemeleri (zam64.sys); operatör günlüklerinde başarı karışık.

4. Gasp taktiği
Çalınan mali tablolar incelenerek "banka veya sigortaya gitmeden ödenebilecek" tutar hesaplanıyor; ardından senaryolu vishing ve müşteri/regülatör tehdidi geliyor. Ödeme süresi 24-72 saat. Kripto cüzdan kaydı bulunamamış; sonuçlar bilinmiyor.

5. Savunma öncelikleri
  1. SimpleHelp, FortiClient EMS, cPanel/WHM, VPN gateway'lerini internete açık bırakmayın; yamaları önceliklendirin.
  2. Kimlik bilgisi yeniden kullanımını kırın (parola yöneticisi + MFA + ayrıcalıklı erişim yönetimi).
  3. Reverse-SOCKS ve beklenmeyen Cloudflare tünelleri için ağ izleme.
  4. EDR bozma / BYOVD denemelerine karşı sürücü engelleme politikaları.
  5. YZ ajanlarının "yetkili red team" bahanesiyle dışarıdan komut çalıştırmasını engelleyen DLP ve çıkış kontrolleri.

Kenar cihaz envanterinizi ne sıklıkla tarıyorsunuz? SimpleHelp veya FortiClient EMS açık 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

Ek DosyalarEkran Görüntüleri
   
 Ruby Onigmo Regex Motorundaki Üç Hata: GitLab RCE CVE'lerinin Kök Nedeni
TonyukukDün, 08:21 AM · Siber Güvenlik Haberleri
0 13
[Resim: attachment.php?aid=395]

Selamlar,

Dün GitLab'ın CVSS 10 kimlik doğrulamasız RCE açığını (CVE-2026-110264) konuşmuştuk. 23 Ekim'de Ruby projesi asıl kök nedeni açıkladı: Onigmo regex motorundaki üç bellek bozulması hatası. Ruby 4.0.9, 3.4.12 ve 3.3.13 bu hataları kapatıyor. GitLab sunucusu işletmeseniz bile kullanıcı girdilerinden regex derleyen her Ruby uygulaması için bu konu önemli.

Konuda anlatılacaklar
  1. Hangi GitLab CVE'leri hangi Ruby hatalarına dayanıyor?
  2. Kimler etkileniyor?
  3. Neden Regexp.timeout yetmiyor?
  4. Yükseltme ve geçici önlem
  5. Kendi kodunuzda kontrol

1. CVE eşlemesi
Ruby resmi duyurusuna göre:
Kod:
CVE-2026-89078 -> Cift free (alternation sonrasi parse hatasi) CVE-2026-93577 -> Derlenmis desen boyutu tasmasi CVE-2026-97229 -> Ayni tasma (CI/CD baglami) CVE-2026-110264 -> Cok sayida tekrar iceren desende ID tasmasi
Tam düzeltmeler: Ruby 4.0.9, 3.4.12, 3.3.13. Ruby kendi adına şimdilik ayrı CVE istemedi; takip için GitLab kimliklerini kullanın.

2. Kimler etkileniyor?
Yalnızca saldırganın kontrol ettiği bir dizgeden regex derleyen uygulamalar:
Kod:
Regexp.new(kullanici_girdisi) Regexp.compile(...) Regexp.union(...) /#{kullanici_girdisi}/
Geliştiricinin yazdığı sabit desenler etkilenmez. GitLab bunu CI yapılandırması gibi kullanıcı desenlerinde yapıyordu; benzer desen başka SaaS ürünlerinde de olabilir.

3. Regexp.timeout yetmiyor
Ruby açıkça yazıyor: Regexp.timeout bu hatalara karşı korumaz. Desen uzunluğunu sınırlamak da güvenilir değil; bazı hatalar kısa desenlerle tetiklenebiliyor. Tek sağlam yol: Ruby'yi yükseltmek veya güvenilmeyen girdiden regex derlememek.

4. Yükseltme
Kod:
ruby -v # Hedef: 4.0.9+ veya 3.4.12+ veya 3.3.13+ rbenv install 3.4.12 && rbenv local 3.4.12 # ornek # GitLab Omnibus: resmi yamali surume gecin
Ruby 3.2 ve daha eski dallar bu düzeltmeleri almayacak; yükseltme veya girdiyi sıkı doğrulama şart.

5. Kendi kodunuzda kontrol
Kod:
# projede Regexp.new / Regexp.compile arayin rg -n "Regexp\.(new|compile|union)" --type ruby
Bulduğunuz yerlerde girdinin saldırgan kontrolünde olup olmadığını gözden geçirin. Mümkünse beyaz liste, sabit desen veya güvenli bir eşleme tablosu kullanın.

Uygulamalarınızda kullanıcıdan regex alıyor musunuz? Nasıl sınırlı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

Ek DosyalarEkran Görüntüleri
   
 CISA KEV'e İki Yeni Kayıt: Collabora CODE ve Arista VeloCloud Aktif İstismar
TonyukukDün, 08:20 AM · Siber Güvenlik Haberleri
0 12
[Resim: attachment.php?aid=394]

Selamlar,

ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), 24 Ekim 2026 Cuma günü Bilinen İstismar Edilen Zafiyetler (KEV) kataloğuna iki kritik açık ekledi: Collabora Online Built-in CODE Server (CVE-2026-110447) ve Arista VeloCloud Orchestrator (CVE-2026-114625). Federal sivil kurumlara yama veya azaltım için 26 Ekim 2026 son tarihi verildi. Dün Arista konusunu konuşmuştuk; bugünün yeni bilgisi CISA KEV kaydı ve Collabora tarafı.

Konuda anlatılacaklar
  1. CVE-2026-110447 (Collabora / Nextcloud)
  2. CVE-2026-114625 (Arista VCO) hatırlatması
  3. Neden KEV kaydı önemli?
  4. Pratik kontrol listesi

1. Collabora CODE: CVE-2026-110447
The Hacker News'e göre CVSS 9.2 olan bu komut enjeksiyonu, Nextcloud içindeki Collabora Online Built-in CODE Server (richdocumentscode) paketini etkiliyor. Yerel belge sunucusu çalışmıyorken proxy.php üzerinden uzaktan kod çalıştırma mümkün. Düzeltme Eylül 2026'da 26.4.303 sürümünde gelmiş. Aktörler Nextcloud sunucularına web shell bırakıp kimlik bilgisi depoları, parola yöneticisi artıkları ve kripto cüzdanları arıyor.

2. Arista VCO: CVE-2026-114625
CVSS 9.9 SQL enjeksiyonu; şirket içi (on-prem) VeloCloud Orchestrator'ı etkiliyor. Geçerli bir oturum + ağ erişimi gerekiyor; en düşük kiracı rolü bile "superuser operator" seviyesine çıkabiliyor. Düzeltilmiş sürümler: 5.2.3.18, 6.1.3.10, 6.4.2.12. Arista'nın paylaştığı saldırı kaynakları: 74.82.197[.]86 ve 38.54.50[.]151 (Japonya jeolokasyonu). Bu, Temmuz'dan bu yana VCO'da sömürülen üçüncü sıfırıncı gün.

3. KEV kaydı neden önemli?
CISA KEV, "aktif olarak istismar ediliyor" demenin resmi hali. ABD federal kurumları için bağlayıcı bir yama takvimi oluşturur; özel sektör için de önceliklendirme sinyali verir. "PoC yok, bekleyelim" demek artık savunulabilir değil.

4. Kontrol listesi
  1. Nextcloud kullanıyorsanız richdocumentscode / Collabora sürümünü 26.4.303+ yapın; proxy.php erişimini günlükleyin.
  2. On-prem VCO envanterini çıkarın; 5.2.3.18 / 6.1.3.10 / 6.4.2.12 altına düşenleri yükseltin.
  3. Yukarıdaki iki IP'yi engelleyin ve VCO erişim günlüklerinde arayın.
  4. VCO arayüzünü internete açmayın; yönetim ağına kısıtlayın.
  5. Web shell, beklenmeyen daemon ve yüksek istek oranı için izleme ekleyin.

Nextcloud veya VeloCloud kullananlar: yama süreciniz nasıl ilerliyor?

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

Ek DosyalarEkran Görüntüleri
   
 MythicRatatoskr: Sandworm ve UAC-0099 Yggdrasil Mesh Ağını C2 Olarak Kullandı
TonyukukDün, 08:18 AM · Zararlı Yazılım Analizi
0 4
[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

Ek DosyalarEkran Görüntüleri
   
 Pillow CVE-2026-112900: EPS Dosyası ve Ghostscript Üzerinden Komut Çalıştırma Riski
TonyukukDün, 08:17 AM · Python
0 10
[Resim: attachment.php?aid=392]

Selamlar,

Python dünyasının en yaygın görsel işleme kütüphanesi Pillow için önemli bir güvenlik güncellemesi var. The Hacker News'in 23 Ekim 2026 tarihli haberine göre CVE-2026-112900, EPS dosyalarının Ghostscript'e aktarılması sırasında dosya adının kontrolsüz iletilmesinden kaynaklanıyor. Kullanıcıdan görsel alan bir web uygulaması yazıyorsanız okumanızı öneririm.

Konuda anlatılacaklar
  1. Açığın özeti
  2. Kimler risk altında?
  3. Aynı sürümde kapanan diğer açıklar
  4. Güncelleme ve Python 3.10 notu
  5. Güvenli görsel işleme için kod önerileri

1. Açığın özeti
Kod:
CVE : CVE-2026-112900 Etkilenen : Pillow 2.6.0 - 12.3.0 Duzeltme : Pillow 13.0.0 (16 Ekim 2026) Kosul : Sistemde Ghostscript (gs) kurulu olmasi Puan : GitHub CNA 9.2; bakimcilar "orta" olarak degerlendiriyor
Pillow, EPS formatını kendi başına işleyemez; bu iş için sistemdeki Ghostscript'i çağırır. Sorun, bu çağrı sırasında dosya adının yeterince denetlenmemesi. Ghostscript kurulu değilse risk büyük ölçüde ortadan kalkıyor.

2. Kimler risk altında?
  • Kullanıcı yüklemelerini Image.open() ile açan ve sunucusunda gs kurulu olan uygulamalar.
  • ImageMagick veya PDF araçları nedeniyle Ghostscript'in zaten yüklü olduğu konteyner imajları.
  • Dosya uzantısına güvenen, içeriği doğrulamayan yükleme formları.
Kod:
which gs && gs --version python3 -c "import PIL; print(PIL.__version__)"

3. Aynı sürümde kapanan diğer açıklar
Pillow 13.0.0 iki açığı daha kapatıyor: JPEG küçük resim işlemesinde bir taşma olan CVE-2026-112403 (Anthropic'in Claude modeliyle bulunup Ada Logics tarafından doğrulandı) ve 2013'ten beri kodda olan, TIFF'in belleğe yazılmasıyla ilgili CVE-2026-112393.

4. Güncelleme
Kod:
pip install -U "Pillow>=13.0.0" pip-audit
Dikkat: Pillow 13, Python 3.10 desteğini bıraktı. Hâlâ 3.10 kullanan projelerde önce Python sürümünü yükseltmeniz gerekecek.

5. Güvenli görsel işleme önerileri
Kod:
from PIL import Image IZINLI = ["JPEG", "PNG", "WEBP"] def guvenli_ac(yol): im = Image.open(yol, formats=IZINLI) im.verify() im = Image.open(yol, formats=IZINLI) return im
  • formats parametresiyle kabul ettiğiniz formatları sınırlayın.
  • Ghostscript'e ihtiyacınız yoksa görsel işleyen sunucudan kaldırın.
  • Görsel işlemeyi yetkisi düşük bir işçi süreçte veya konteynerde yapın.

Projelerinizde kullanıcı yüklemelerini nasıl işliyorsunuz? Format kısıtlaması kullanan var 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

Ek DosyalarEkran Görüntüleri
   
 HPE ArubaOS'ta 72 Açık, 8'i En Yüksek Önemde: AOS-8 ve AOS-10 İçin Yama Rehberi
TonyukukDün, 08:17 AM · Ağ Güvenliği
0 12
[Resim: attachment.php?aid=391]

Selamlar,

HPE, kurumsal kablosuz ve kampüs ağlarında yaygın kullanılan ArubaOS (AOS) için 72 güvenlik açığını kapatan güncellemeler yayımladı. BleepingComputer'ın 23 Ekim 2026 tarihli haberine göre bunların sekizi en yüksek önem derecesinde ve çoğu kimlik doğrulama gerektirmeden kod çalıştırmaya imkan veriyor.

Konuda anlatılacaklar
  1. Kritik sekiz açık
  2. AOS-8 ve AOS-10 farkı
  3. İstismar durumu
  4. Geçici önlemler
  5. Yama ve doğrulama adımları

1. Kritik sekiz açık
Kod:
CVE-2026-79844 Kimlik dogrulama atlatma -> RCE (AOS-10) CVE-2026-79845 PAPI kimlik dogrulama atlatma (AOS-10) CVE-2026-79846 Kimlik dogrulamasiz komut enjeksiyonu (AOS-8) CVE-2026-79847 Kimlik dogrulamasiz bellek tasmasi RCE (AOS-10) CVE-2026-79848 Kimlik dogrulamasiz SQLi -> RCE (AOS-8) CVE-2026-79849 Kimlik dogrulamasiz SQLi -> RCE (AOS-8) CVE-2026-79850 Kimlik dogrulama atlatma -> RCE (AOS-8) CVE-2026-79851 Kimlik dogrulamasiz bellek tasmasi RCE (AOS-10)
Geri kalan 64 açık daha düşük önemde olsa da aynı güncellemeyle kapanıyor.

2. AOS-8 ve AOS-10
AOS-8 genellikle Mobility Conductor / Mobility Controller mimarisiyle yerinde yönetilen kurulumlarda, AOS-10 ise Aruba Central ile buluttan yönetilen gateway ve erişim noktalarında görülür. Envanterinizde hangisinin çalıştığını bilmeden doğru bülteni okuyamazsınız.

3. İstismar durumu
Habere göre HPE, bu açıklar için kamuya açık bir PoC veya aktif istismar bilgisinin olmadığını belirtiyor. Kenar cihaz açıklarının yama sonrası günlerde tersine mühendislikle istismar edildiğini bu ay da birçok kez gördük; beklemek için gerekçe değil.

4. Geçici önlemler
HPE'nin önerdiği azaltımlar yönetim düzlemini daraltmaya dayanıyor:
  • CLI ve web tabanlı yönetim arayüzlerini ayrılmış bir L2 VLAN içine alın.
  • Ve/veya L3 güvenlik duvarı ile yalnızca yönetim ağından erişime izin verin.
  • Yönetim erişimleri için hesap kaydı (accounting) ve günlüklemeyi açın.

5. Yama ve doğrulama
  1. HPE destek portalındaki ilgili güvenlik bültenini açın ve cihaz modeliniz için düzeltilmiş sürümü not edin.
  2. Yapılandırma yedeğini alın, bakım penceresi planlayın.
  3. Yükseltme sonrası sürümü doğrulayın:
    Kod:
    show version show image version
  4. Son haftaların yönetim oturumu günlüklerinde beklenmeyen kaynak IP arayın.

Kurumunuzda Aruba denetleyicilerinin yönetim arayüzü ayrı bir VLAN'da 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

Ek DosyalarEkran Görüntüleri
   
 PHP'de Yeni Yamasız Açık CVE-2026-115560 ve PHP2Shell'i Kullanan Potassium Botneti
TonyukukDün, 08:16 AM · Siber Güvenlik Haberleri
0 12
[Resim: attachment.php?aid=390]

Selamlar,

PHP2Shell dalgası bitmeden PHP ekibi 23 Ekim'de yeni bir bilgilendirme yayımladı: CVE-2026-115560 olarak izlenen ve henüz yaması olmayan bir uzaktan kod çalıştırma riski. Aynı günlerde bir Mirai türevi olan Potassium botnetinin PHP2Shell istismarına katıldığı ve x86-64 sunucularda ASLR'yi atlatan çalışan bir PoC yayımlandığı da raporlandı. Bu konuda üç gelişmeyi tek yerde topluyorum.

Konuda anlatılacaklar
  1. CVE-2026-115560 kimleri etkiliyor?
  2. Geçici önlem: tek satırlık ayar
  3. Potassium botneti ve IOC'ler
  4. ASLR atlatan PoC ne anlama geliyor?
  5. Ölçek: rakamlarla PHP2Shell
  6. Sunucu yöneticisi için kontrol listesi

1. CVE-2026-115560 kimleri etkiliyor?
The Hacker News ve BleepingComputer'ın aktardığı PHP duyurusuna göre açık herkesi değil, belirli bir kod desenini kullanan uygulamaları ilgilendiriyor:
  • Uygulama session.serialize_handler değerini önce php_binary veya php_serialize yapıyor,
  • ardından session_start() çağrılmadan önce ini_set() ile tekrar php işleyicisine dönüyor,
  • ve oturum yükleme ilerlemesi (session upload progress) açık.
Önemli nokta: PHP2Shell için çıkan 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri bu yeni açığı kapatmıyor. Düzeltme bir sonraki olağan sürümde gelecek. Duyuruda etkilenen sürüm aralığı ve CVSS puanı verilmedi; istismar edildiğine dair bir rapor da yok.

2. Geçici önlem
Yama gelene kadar PHP'nin önerdiği önlem, oturum yükleme ilerlemesini kapatmak:
Kod:
; php.ini session.upload_progress.enabled = 0
Ayarın gerçekten uygulandığını kontrol edin (FPM ve CLI farklı php.ini okuyabilir):
Kod:
php -i | grep -i upload_progress php-fpm8.3 -i 2>/dev/null | grep -i upload_progress grep -rn "serialize_handler" /var/www --include=*.php

3. Potassium botneti
SecurityWeek'e göre Sophos ve Arctic Wolf, PHP2Shell'i yayılmak için kullanan Potassium adlı bir Mirai türevi gözlemledi. Savunma tarafında işinize yarayacak göstergeler (The Hacker News / Sophos özeti):
Kod:
C2 IP : 134.199.154[.]64 C2 alan : thunder.godofthunder[.]st Port : TCP 50792 Kaynak IP : 85.11.167[.]243 , 217.60.242[.]76 , 45.198.224[.]169
Bu değerleri güvenlik duvarı ve DNS günlüklerinizde arayın. Göstergeler zamanla değişir.

4. ASLR atlatan PoC
SOCRadar, açık bir saldırgan sunucusunda PHP 8.4.26 mod_php hedefli aslr_exploit.py adlı bir betik buldu. VulnCheck'ten Spencer McIntyre da üretim ayarlarıyla çalışan x86-64 sistemlerde ASLR'yi atlatıp kod çalıştıran bir istismar geliştirdi. Pratik anlamı: "bellek rastgeleleştirmesi var, istismar zor olur" varsayımına güvenmeyin; yama tek gerçek çözüm.

5. Rakamlarla ölçek
  • Cloudflare: istismar denemeleri ilk 45 dakikada on binlerden 22 Ekim'e kadar milyonlara çıktı.
  • Censys: 23 Ekim itibarıyla 34,4 milyon PHP servisi savunmasız görünüyor.
  • Qualys: PHP çalıştıranların yaklaşık yüzde 71'i (yaklaşık 110 milyon) desteği bitmiş 5.4 ile 8.1 arası sürümlerde.
  • İngiltere'de 32 kamu servisi önlem amaçlı erişime kapatıldı; NCSC yaklaşık 50.000 uyarı gönderdi.
Doğrulanmış başarılı ele geçirme sayısı kaynaklarda henüz net verilmiş değil.

6. Kontrol listesi
  1. PHP2Shell yamasını uygulayın (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).
  2. session.upload_progress.enabled = 0 yapın ve her SAPI için doğrulayın.
  3. Desteği bitmiş PHP sürümlerini planlı şekilde güncel bir dala taşıyın.
  4. Web sunucusu ve DNS günlüklerinde yukarıdaki IOC'leri arayın.

Sunucularınızda session.upload_progress kapatınca bozulan bir özellik oldu mu?

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

Ek DosyalarEkran Görüntüleri