<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Portal]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:49:28 +0000 MyBB <![CDATA[EPSS ile Yama Önceliklendirme: CVSS Yüksek Ama Önce Hangi Açığı Kapatmalı?]]> https://www.turkteam.org/konu-epss-ile-yama-onceliklendirme-cvss-yuksek-ama-once-hangi-acigi-kapatmali.html Sun, 25 Oct 2026 11:53:51 +0300 KulTigin]]> https://www.turkteam.org/konu-epss-ile-yama-onceliklendirme-cvss-yuksek-ama-once-hangi-acigi-kapatmali.html [Resim: attachment.php?aid=440]
Selamlar,

Oracle'ın tek seferde 1.295 yama çıkardığı bir dünyada "önce hangi açığı kapatalım?" sorusu mavi takımların en kritik kararı. Yıllardır tek ölçüt CVSS'ti; ama CVSS ciddiyeti ölçer, sömürülme olasılığını değil. İşte burada EPSS (Exploit Prediction Scoring System) devreye giriyor. Bu rehberde EPSS nedir, CVSS'ten farkı ne ve pratikte nasıl kullanılır, ele alıyorum.

Konuda anlatılacaklar
  1. EPSS nedir?
  2. CVSS ile farkı
  3. API ile sorgulama
  4. KEV ile birleştirme
  5. Pratik önceliklendirme akışı

1. EPSS nedir?
EPSS, FIRST tarafından geliştirilen, bir CVE'nin önümüzdeki 30 gün içinde vahşi doğada sömürülme olasılığını 0-1 arası bir skorla tahmin eden bir modeldir. 0.96 skor, yüksek sömürülme olasılığı; 0.01 ise düşük anlamına gelir. Model günlük güncellenir.

2. CVSS ile farkı
  • CVSS: "Bu açık sömürülürse ne kadar kötü olur?" (ciddiyet, statik)
  • EPSS: "Bu açık yakın zamanda sömürülür mü?" (olasılık, dinamik)
İkisi birbirini tamamlar. Yüksek CVSS + düşük EPSS bir açık, yüksek CVSS + yüksek EPSS bir açıkla aynı aciliyette değildir. Kaynaklar kısıtlıysa, yüksek EPSS'li olanları öne almak sömürülecek açığı kapatma olasılığınızı artırır.

3. API ile sorgulama
EPSS API'si ücretsiz ve kimlik doğrulamasız:
Kod:
# Tek CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257" | python3 -m json.tool # Birden fazla CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257,CVE-2026-111497" # EPSS'i 0.9 üstü olanları listele curl -s "https://api.first.org/data/v1/epss?epss-gt=0.9&limit=50"
Örnek bir toplu sıralama scripti:
Kod:
import requests cves = ["CVE-2026-0257","CVE-2026-111497","CVE-2025-64446"] r = requests.get("https://api.first.org/data/v1/epss", params={"cve": ",".join(cves)}) data = sorted(r.json()["data"], key=lambda d: float(d["epss"]), reverse=True) for d in data: print(f"{d['cve']} EPSS={float(d['epss']):.4f} pct={d['percentile']}")

4. KEV ile birleştirme
CISA'nın Known Exploited Vulnerabilities (KEV) kataloğu, zaten aktif sömürülen açıkların listesidir. Bir CVE KEV'deyse, EPSS tahminine gerek kalmadan en yüksek önceliktir; çünkü olasılık değil, gerçekleşmiş sömürüdür.
Kod:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | python3 -c "import sys,json;print(len(json.load(sys.stdin)['vulnerabilities']),'KEV kaydi')"

5. Pratik önceliklendirme akışı
  1. KEV'de mi? Evetse -> hemen yama (en yüksek öncelik).
  2. EPSS yüksek mi (örn. > 0.5)? Evetse -> acil sıraya al.
  3. CVSS kritik + internete dönük mü? Evetse -> yüksek öncelik.
  4. Varlık kritikliği ile ağırlıklandır; kritik sistemleri öne al.
  5. Düşük EPSS + düşük maruziyet -> normal bakım döngüsüne bırak.

Sonuç
CVSS tek başına "neyi önce yamalamalı" sorusunu yanıtlamaz. KEV (gerçekleşen sömürü) + EPSS (sömürü olasılığı) + varlık kritikliği üçlüsü, kısıtlı kaynakları en çok sömürülecek açıklara yöneltir. Siz yama önceliklendirmede EPSS/KEV kullanıyor 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   20-t20-epss-yama-onceliklendirme.png (Dosya Boyutu: 120.54 KB / İndirme Sayısı: 3) ]]> [Resim: attachment.php?aid=440]
Selamlar,

Oracle'ın tek seferde 1.295 yama çıkardığı bir dünyada "önce hangi açığı kapatalım?" sorusu mavi takımların en kritik kararı. Yıllardır tek ölçüt CVSS'ti; ama CVSS ciddiyeti ölçer, sömürülme olasılığını değil. İşte burada EPSS (Exploit Prediction Scoring System) devreye giriyor. Bu rehberde EPSS nedir, CVSS'ten farkı ne ve pratikte nasıl kullanılır, ele alıyorum.

Konuda anlatılacaklar
  1. EPSS nedir?
  2. CVSS ile farkı
  3. API ile sorgulama
  4. KEV ile birleştirme
  5. Pratik önceliklendirme akışı

1. EPSS nedir?
EPSS, FIRST tarafından geliştirilen, bir CVE'nin önümüzdeki 30 gün içinde vahşi doğada sömürülme olasılığını 0-1 arası bir skorla tahmin eden bir modeldir. 0.96 skor, yüksek sömürülme olasılığı; 0.01 ise düşük anlamına gelir. Model günlük güncellenir.

2. CVSS ile farkı
  • CVSS: "Bu açık sömürülürse ne kadar kötü olur?" (ciddiyet, statik)
  • EPSS: "Bu açık yakın zamanda sömürülür mü?" (olasılık, dinamik)
İkisi birbirini tamamlar. Yüksek CVSS + düşük EPSS bir açık, yüksek CVSS + yüksek EPSS bir açıkla aynı aciliyette değildir. Kaynaklar kısıtlıysa, yüksek EPSS'li olanları öne almak sömürülecek açığı kapatma olasılığınızı artırır.

3. API ile sorgulama
EPSS API'si ücretsiz ve kimlik doğrulamasız:
Kod:
# Tek CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257" | python3 -m json.tool # Birden fazla CVE curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-0257,CVE-2026-111497" # EPSS'i 0.9 üstü olanları listele curl -s "https://api.first.org/data/v1/epss?epss-gt=0.9&limit=50"
Örnek bir toplu sıralama scripti:
Kod:
import requests cves = ["CVE-2026-0257","CVE-2026-111497","CVE-2025-64446"] r = requests.get("https://api.first.org/data/v1/epss", params={"cve": ",".join(cves)}) data = sorted(r.json()["data"], key=lambda d: float(d["epss"]), reverse=True) for d in data: print(f"{d['cve']} EPSS={float(d['epss']):.4f} pct={d['percentile']}")

4. KEV ile birleştirme
CISA'nın Known Exploited Vulnerabilities (KEV) kataloğu, zaten aktif sömürülen açıkların listesidir. Bir CVE KEV'deyse, EPSS tahminine gerek kalmadan en yüksek önceliktir; çünkü olasılık değil, gerçekleşmiş sömürüdür.
Kod:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | python3 -c "import sys,json;print(len(json.load(sys.stdin)['vulnerabilities']),'KEV kaydi')"

5. Pratik önceliklendirme akışı
  1. KEV'de mi? Evetse -> hemen yama (en yüksek öncelik).
  2. EPSS yüksek mi (örn. > 0.5)? Evetse -> acil sıraya al.
  3. CVSS kritik + internete dönük mü? Evetse -> yüksek öncelik.
  4. Varlık kritikliği ile ağırlıklandır; kritik sistemleri öne al.
  5. Düşük EPSS + düşük maruziyet -> normal bakım döngüsüne bırak.

Sonuç
CVSS tek başına "neyi önce yamalamalı" sorusunu yanıtlamaz. KEV (gerçekleşen sömürü) + EPSS (sömürü olasılığı) + varlık kritikliği üçlüsü, kısıtlı kaynakları en çok sömürülecek açıklara yöneltir. Siz yama önceliklendirmede EPSS/KEV kullanıyor 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   20-t20-epss-yama-onceliklendirme.png (Dosya Boyutu: 120.54 KB / İndirme Sayısı: 3) ]]> <![CDATA[Soru-Cevap: Yazılım Tedarik Zinciri Güvenliği Nedir, Küçük Ekip Nereden Başlamalı?]]> https://www.turkteam.org/konu-soru-cevap-yazilim-tedarik-zinciri-guvenligi-nedir-kucuk-ekip-nereden-baslamali.html Sun, 25 Oct 2026 11:52:44 +0300 KulTigin]]> https://www.turkteam.org/konu-soru-cevap-yazilim-tedarik-zinciri-guvenligi-nedir-kucuk-ekip-nereden-baslamali.html [Resim: attachment.php?aid=438]
Selamlar,

Son dönemde tedarik zinciri saldırıları (ele geçirilmiş paketler, iptal edilmeyen anahtarlar, güvensiz güncelleyiciler) forum gündeminin sürekli konusu oldu. Peki yazılım tedarik zinciri güvenliği tam olarak nedir ve kaynağı kısıtlı küçük bir ekip nereden başlamalı? Bu soru-cevap formatında temel kavramları ve pratik ilk adımları topladım.

S: Yazılım tedarik zinciri güvenliği nedir?
C: Yazdığınız koda ek olarak dışarıdan gelen her şeyin (açık kaynak bağımlılıklar, temel imajlar, CI/CD eklentileri, build araçları, güncelleme kanalları) güvenliğini kapsar. Saldırgan, kodunuza doğrudan sızamasa bile, güvendiğiniz bir bağımlılık veya aracı ele geçirerek dolaylı yoldan girebilir.

S: Neden bu kadar önemli hale geldi?
C: Modern uygulamalar koddan çok bağımlılıktır; yüzlerce dolaylı (transitive) paket içerir. Tek bir popüler paketin ele geçirilmesi binlerce projeyi etkileyebilir. Forumda ele aldığımız LiteLLM ve ConnectWise vakaları tam da bu zincirin kırılma örnekleriydi.

S: SBOM nedir, gerekli mi?
C: SBOM (Software Bill of Materials), uygulamanızın içerdiği tüm bileşenlerin listesidir; bir "içindekiler etiketi" gibi. Yeni bir açık çıktığında "bu paketi kullanıyor muyum?" sorusunu saniyeler içinde yanıtlamanızı sağlar. Üretmek için:
Kod:
# Syft ile (örnek) syft dir:. -o cyclonedx-json > sbom.json

S: Küçük ekip nereden başlamalı?
C: Büyük çerçeveleri (SLSA seviyeleri gibi) bir anda uygulamak zorunda değilsiniz. Öncelik sırası:
  1. Bağımlılıkları kilitleyin. package-lock.json, poetry.lock, go.sum gibi kilit dosyalarını commit edin ki tekrarlanabilir build alın.
  2. Bağımlılık taraması ekleyin. CI'da bilinen zafiyetli paketleri tespit edin (örneğin pip-audit, npm audit, govulncheck).
  3. SBOM üretin. Her sürümde otomatik olarak oluşturup saklayın.
  4. Sırları repodan çıkarın. (Gitleaks rehberimize bakın.)
  5. CI/CD yetkilerini kısıtlayın. En az yetki; token'ları dar kapsamlı ve kısa ömürlü yapın.
  6. Build'i sürümleyin/imzalayın. İlerleyen aşamada SLSA kaynak ve ürün bütünlüğü hedefleyin.

S: SLSA nedir?
C: SLSA (Supply-chain Levels for Software Artifacts), build süreci bütünlüğü için aşamalı bir çerçeve. Düşük seviyeler kaynak ve build'in izlenebilirliğini, yüksek seviyeler imzalı ve doğrulanabilir üretimi hedefler. Küçük ekipler önce düşük seviye hedeflerle başlayabilir.

S: Tek bir cümleyle özet?
C: Kullandığınız her bağımlılığı ve aracı, kendi kodunuz kadar ciddiye alın; kilitleyin, tarayın, listeleyin (SBOM) ve yetkileri daraltın.

Sonuç
Tedarik zinciri güvenliği kulağa büyük gelebilir, ama küçük ekipler için bile birkaç somut adım (kilit dosyası, bağımlılık taraması, SBOM, sır temizliği) riski ciddi ölçüde düşürür. Sizin ekibiniz bu adımlardan hangilerini uyguluyor?

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   19-t19-tedarik-zinciri-sc-baslangic.png (Dosya Boyutu: 119.7 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=438]
Selamlar,

Son dönemde tedarik zinciri saldırıları (ele geçirilmiş paketler, iptal edilmeyen anahtarlar, güvensiz güncelleyiciler) forum gündeminin sürekli konusu oldu. Peki yazılım tedarik zinciri güvenliği tam olarak nedir ve kaynağı kısıtlı küçük bir ekip nereden başlamalı? Bu soru-cevap formatında temel kavramları ve pratik ilk adımları topladım.

S: Yazılım tedarik zinciri güvenliği nedir?
C: Yazdığınız koda ek olarak dışarıdan gelen her şeyin (açık kaynak bağımlılıklar, temel imajlar, CI/CD eklentileri, build araçları, güncelleme kanalları) güvenliğini kapsar. Saldırgan, kodunuza doğrudan sızamasa bile, güvendiğiniz bir bağımlılık veya aracı ele geçirerek dolaylı yoldan girebilir.

S: Neden bu kadar önemli hale geldi?
C: Modern uygulamalar koddan çok bağımlılıktır; yüzlerce dolaylı (transitive) paket içerir. Tek bir popüler paketin ele geçirilmesi binlerce projeyi etkileyebilir. Forumda ele aldığımız LiteLLM ve ConnectWise vakaları tam da bu zincirin kırılma örnekleriydi.

S: SBOM nedir, gerekli mi?
C: SBOM (Software Bill of Materials), uygulamanızın içerdiği tüm bileşenlerin listesidir; bir "içindekiler etiketi" gibi. Yeni bir açık çıktığında "bu paketi kullanıyor muyum?" sorusunu saniyeler içinde yanıtlamanızı sağlar. Üretmek için:
Kod:
# Syft ile (örnek) syft dir:. -o cyclonedx-json > sbom.json

S: Küçük ekip nereden başlamalı?
C: Büyük çerçeveleri (SLSA seviyeleri gibi) bir anda uygulamak zorunda değilsiniz. Öncelik sırası:
  1. Bağımlılıkları kilitleyin. package-lock.json, poetry.lock, go.sum gibi kilit dosyalarını commit edin ki tekrarlanabilir build alın.
  2. Bağımlılık taraması ekleyin. CI'da bilinen zafiyetli paketleri tespit edin (örneğin pip-audit, npm audit, govulncheck).
  3. SBOM üretin. Her sürümde otomatik olarak oluşturup saklayın.
  4. Sırları repodan çıkarın. (Gitleaks rehberimize bakın.)
  5. CI/CD yetkilerini kısıtlayın. En az yetki; token'ları dar kapsamlı ve kısa ömürlü yapın.
  6. Build'i sürümleyin/imzalayın. İlerleyen aşamada SLSA kaynak ve ürün bütünlüğü hedefleyin.

S: SLSA nedir?
C: SLSA (Supply-chain Levels for Software Artifacts), build süreci bütünlüğü için aşamalı bir çerçeve. Düşük seviyeler kaynak ve build'in izlenebilirliğini, yüksek seviyeler imzalı ve doğrulanabilir üretimi hedefler. Küçük ekipler önce düşük seviye hedeflerle başlayabilir.

S: Tek bir cümleyle özet?
C: Kullandığınız her bağımlılığı ve aracı, kendi kodunuz kadar ciddiye alın; kilitleyin, tarayın, listeleyin (SBOM) ve yetkileri daraltın.

Sonuç
Tedarik zinciri güvenliği kulağa büyük gelebilir, ama küçük ekipler için bile birkaç somut adım (kilit dosyası, bağımlılık taraması, SBOM, sır temizliği) riski ciddi ölçüde düşürür. Sizin ekibiniz bu adımlardan hangilerini uyguluyor?

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   19-t19-tedarik-zinciri-sc-baslangic.png (Dosya Boyutu: 119.7 KB / İndirme Sayısı: 2) ]]> <![CDATA[Microsoft Teams'e YZ Destekli Oltalama Tespiti Geliyor: Kullanıcı Ne Yapmalı?]]> https://www.turkteam.org/konu-microsoft-teams-e-yz-destekli-oltalama-tespiti-geliyor-kullanici-ne-yapmali.html Sun, 25 Oct 2026 11:51:27 +0300 KulTigin]]> https://www.turkteam.org/konu-microsoft-teams-e-yz-destekli-oltalama-tespiti-geliyor-kullanici-ne-yapmali.html [Resim: attachment.php?aid=437]
Selamlar,

Microsoft, Teams'e sohbet ve mesajlardaki oltalama/dolandırıcılık girişimlerini uyaran YZ destekli tehdit tespiti getireceğini duyurdu. BleepingComputer konuyu aktardı. Özelliğin Kasım 2026 başında kullanıma sunulmaya başlanması bekleniyor. Teams artık iş iletişiminin merkezi olduğu için, saldırganlar da e-postadan Teams'e kayıyor. Burada yeni özelliği, sınırlarını ve kullanıcı olarak ne yapmanız gerektiğini ele alıyorum.

Konuda anlatılacaklar
  1. Neden Teams hedefte?
  2. Gelen yeni özellikler
  3. Özellik ne yapmaz (sınırlar)
  4. Kullanıcı farkındalık önlemleri
  5. Yönetici tarafı

1. Neden Teams hedefte?
Saldırganlar e-posta filtrelerinin güçleniyor olması nedeniyle giderek daha fazla işbirliği platformlarına yöneliyor. Teams'te dış kullanıcılardan gelen mesajlar, sahte IT desteği kimliğine bürünme ve kötü amaçlı bağlantılar yaygın taktikler haline geldi. Özellikle "yardım masası" veya "IT destek" taklidi yapan mesajlar etkili olabiliyor.

2. Gelen yeni özellikler
Microsoft 365 yol haritasına göre planlanan özellikler:
  • Kötü amaçlı URL uyarıları: sohbetteki tehlikeli bağlantılar için gerçek zamanlı uyarı.
  • Olası oltalama/dolandırıcılık uyarıları: YZ ile şüpheli mesaj kalıplarının işaretlenmesi.
  • Microsoft, bazı korumaların yönetici yapılandırması gerektireceğini belirtiyor.

3. Özellik ne yapmaz?
Önemli bir gerçekçilik notu: YZ tespiti her şeyi yakalamaz. Yeni/özgün sosyal mühendislik mesajları, aciliyet ve otorite baskısına dayanan ikna teknikleri teknik filtrelerden geçebilir. Uyarı sistemi bir katman, tek savunma değil.

4. Kullanıcı farkındalık önlemleri
  1. Dış kullanıcı etiketine dikkat edin. Teams, kurum dışından gelen mesajları işaretler; bu bir uyarı sinyalidir.
  2. IT/yardım masası kimliğine bürünmeye şüpheyle bakın. Gerçek IT, sizden parola/MFA kodu istemez.
  3. Aciliyet baskısını sorgulayın. "Hemen tıkla", "hesabın kapanacak" gibi ifadeler klasik manipülasyon.
  4. Bağlantı üstüne gelin, tıklamayın. Hedef URL beklenen alan adı değilse açmayın.
  5. Şüpheli mesajı raporlayın. Teams'in raporlama özelliğini kullanın.

5. Yönetici tarafı
Yöneticiler için öneriler:
  • Dış erişim (external access/federation) politikalarını gözden geçirin; gerekmedikçe kısıtlayın.
  • Yeni gelen korumaları etkinleştirin ve yapılandırın.
  • Kullanıcılara düzenli farkındalık eğitimi verin; teknik kontrol + insan farkındalığı birlikte çalışır.

Sonuç
YZ destekli tespit, Teams üzerindeki oltalamaya karşı hoş bir katman; ama sosyal mühendislik temelde insan psikolojisini hedefler ve en iyi savunma yine bilinçli kullanıcıdır. Teams üzerinden hiç şüpheli bir "IT destek" mesajı aldı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

.png   18-t18-teams-ai-oltalama-tespiti.png (Dosya Boyutu: 114.2 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=437]
Selamlar,

Microsoft, Teams'e sohbet ve mesajlardaki oltalama/dolandırıcılık girişimlerini uyaran YZ destekli tehdit tespiti getireceğini duyurdu. BleepingComputer konuyu aktardı. Özelliğin Kasım 2026 başında kullanıma sunulmaya başlanması bekleniyor. Teams artık iş iletişiminin merkezi olduğu için, saldırganlar da e-postadan Teams'e kayıyor. Burada yeni özelliği, sınırlarını ve kullanıcı olarak ne yapmanız gerektiğini ele alıyorum.

Konuda anlatılacaklar
  1. Neden Teams hedefte?
  2. Gelen yeni özellikler
  3. Özellik ne yapmaz (sınırlar)
  4. Kullanıcı farkındalık önlemleri
  5. Yönetici tarafı

1. Neden Teams hedefte?
Saldırganlar e-posta filtrelerinin güçleniyor olması nedeniyle giderek daha fazla işbirliği platformlarına yöneliyor. Teams'te dış kullanıcılardan gelen mesajlar, sahte IT desteği kimliğine bürünme ve kötü amaçlı bağlantılar yaygın taktikler haline geldi. Özellikle "yardım masası" veya "IT destek" taklidi yapan mesajlar etkili olabiliyor.

2. Gelen yeni özellikler
Microsoft 365 yol haritasına göre planlanan özellikler:
  • Kötü amaçlı URL uyarıları: sohbetteki tehlikeli bağlantılar için gerçek zamanlı uyarı.
  • Olası oltalama/dolandırıcılık uyarıları: YZ ile şüpheli mesaj kalıplarının işaretlenmesi.
  • Microsoft, bazı korumaların yönetici yapılandırması gerektireceğini belirtiyor.

3. Özellik ne yapmaz?
Önemli bir gerçekçilik notu: YZ tespiti her şeyi yakalamaz. Yeni/özgün sosyal mühendislik mesajları, aciliyet ve otorite baskısına dayanan ikna teknikleri teknik filtrelerden geçebilir. Uyarı sistemi bir katman, tek savunma değil.

4. Kullanıcı farkındalık önlemleri
  1. Dış kullanıcı etiketine dikkat edin. Teams, kurum dışından gelen mesajları işaretler; bu bir uyarı sinyalidir.
  2. IT/yardım masası kimliğine bürünmeye şüpheyle bakın. Gerçek IT, sizden parola/MFA kodu istemez.
  3. Aciliyet baskısını sorgulayın. "Hemen tıkla", "hesabın kapanacak" gibi ifadeler klasik manipülasyon.
  4. Bağlantı üstüne gelin, tıklamayın. Hedef URL beklenen alan adı değilse açmayın.
  5. Şüpheli mesajı raporlayın. Teams'in raporlama özelliğini kullanın.

5. Yönetici tarafı
Yöneticiler için öneriler:
  • Dış erişim (external access/federation) politikalarını gözden geçirin; gerekmedikçe kısıtlayın.
  • Yeni gelen korumaları etkinleştirin ve yapılandırın.
  • Kullanıcılara düzenli farkındalık eğitimi verin; teknik kontrol + insan farkındalığı birlikte çalışır.

Sonuç
YZ destekli tespit, Teams üzerindeki oltalamaya karşı hoş bir katman; ama sosyal mühendislik temelde insan psikolojisini hedefler ve en iyi savunma yine bilinçli kullanıcıdır. Teams üzerinden hiç şüpheli bir "IT destek" mesajı aldı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

.png   18-t18-teams-ai-oltalama-tespiti.png (Dosya Boyutu: 114.2 KB / İndirme Sayısı: 2) ]]> <![CDATA[Lynis ile Linux Sunucu Sertleştirme Denetimi: Skorunuzu Nasıl Yükseltirsiniz?]]> https://www.turkteam.org/konu-lynis-ile-linux-sunucu-sertlestirme-denetimi-skorunuzu-nasil-yukseltirsiniz.html Sun, 25 Oct 2026 11:50:09 +0300 KulTigin]]> https://www.turkteam.org/konu-lynis-ile-linux-sunucu-sertlestirme-denetimi-skorunuzu-nasil-yukseltirsiniz.html [Resim: attachment.php?aid=436]
Selamlar,

Bir Linux sunucusunu internete açmadan önce "ne kadar güvenli?" sorusuna somut yanıt vermek zor olabilir. Açık kaynak güvenlik denetim aracı Lynis, sisteminizi onlarca kontrol kategorisinde tarayıp bir sertleştirme indeksi (hardening index) ve uygulanabilir öneriler verir. Bu rehberde kurulum, denetim ve önerilere göre sertleştirmeyi adım adım ele alıyorum. (Yalnızca yetkili olduğunuz sistemlerde kullanın.)

Konuda anlatılacaklar
  1. Lynis nedir?
  2. Kurulum
  3. İlk denetim
  4. Çıktıyı okumak
  5. Sertleştirme örnekleri
  6. Periyodik çalıştırma

1. Lynis nedir?
Lynis, CISOfy tarafından geliştirilen, kabuk (shell) ile yazılmış, agentsiz bir güvenlik denetim aracıdır. Sistem sertleştirme, uyumluluk testi ve zafiyet taramasına yardımcı olur. Sadece kontrol eder, varsayılan olarak değişiklik yapmaz.

2. Kurulum
Kod:
# Debian/Ubuntu sudo apt install lynis # RHEL/Fedora sudo dnf install lynis # Kaynaktan (en güncel) git clone https://github.com/CISOfy/lynis cd lynis && ./lynis audit system

3. İlk denetim
Kod:
sudo lynis audit system
Lynis; önyükleme, kernel, bellek, kimlik doğrulama, dosya sistemleri, SSH, güvenlik duvarı, loglama gibi onlarca kategoriyi tarar. Sonunda bir özet ve Hardening index gösterir.

4. Çıktıyı okumak
Çıktıda üç ana işaret vardır:
  • Warnings (uyarılar): öncelik verilmesi gereken bulgular.
  • Suggestions (öneriler): iyileştirme fırsatları.
  • Hardening index: 0-100 arası genel skor.
Detaylı log:
Kod:
sudo cat /var/log/lynis.log # Rapor verisi: sudo cat /var/log/lynis-report.dat

5. Sertleştirme örnekleri
Lynis'in sık önerdiği tipik adımlar:
  1. SSH sertleştirme: /etc/ssh/sshd_config içinde PermitRootLogin no, PasswordAuthentication no (anahtar tabanlı giriş), Protocol 2.
  2. Kernel parametreleri: /etc/sysctl.conf ile ağ ve bellek korumaları.
  3. Gereksiz servisleri kapatma: kullanılmayan daemon'ları devre dışı bırakın.
  4. Güvenlik duvarı: varsayılan reddet politikasıyla ufw/nftables yapılandırın.
  5. Denetim izleme: auditd ve dosya bütünlük kontrolü (AIDE) kurun.
Her öneriye kör körüne uymayın; değişikliği anlayarak ve test ortamında doğrulayarak uygulayın.

6. Periyodik çalıştırma
Sertleştirme tek seferlik değil, sürekli bir süreç. cron ile haftalık denetim:
Kod:
0 3 * * 0 /usr/sbin/lynis audit system --quiet >> /var/log/lynis-weekly.log 2>&1

Sonuç
Lynis, "sunucum ne kadar güvenli?" sorusuna ölçülebilir bir yanıt ve somut yapılacaklar listesi verir. Skoru yükseltmek amaç değil, araçtır; asıl hedef anlaşılır ve sürdürülebilir bir sertleştirme. Sunucularınızda en son ne zaman denetim çalıştırdınız?

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   17-t17-lynis-linux-sertlestirme.png (Dosya Boyutu: 109.13 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=436]
Selamlar,

Bir Linux sunucusunu internete açmadan önce "ne kadar güvenli?" sorusuna somut yanıt vermek zor olabilir. Açık kaynak güvenlik denetim aracı Lynis, sisteminizi onlarca kontrol kategorisinde tarayıp bir sertleştirme indeksi (hardening index) ve uygulanabilir öneriler verir. Bu rehberde kurulum, denetim ve önerilere göre sertleştirmeyi adım adım ele alıyorum. (Yalnızca yetkili olduğunuz sistemlerde kullanın.)

Konuda anlatılacaklar
  1. Lynis nedir?
  2. Kurulum
  3. İlk denetim
  4. Çıktıyı okumak
  5. Sertleştirme örnekleri
  6. Periyodik çalıştırma

1. Lynis nedir?
Lynis, CISOfy tarafından geliştirilen, kabuk (shell) ile yazılmış, agentsiz bir güvenlik denetim aracıdır. Sistem sertleştirme, uyumluluk testi ve zafiyet taramasına yardımcı olur. Sadece kontrol eder, varsayılan olarak değişiklik yapmaz.

2. Kurulum
Kod:
# Debian/Ubuntu sudo apt install lynis # RHEL/Fedora sudo dnf install lynis # Kaynaktan (en güncel) git clone https://github.com/CISOfy/lynis cd lynis && ./lynis audit system

3. İlk denetim
Kod:
sudo lynis audit system
Lynis; önyükleme, kernel, bellek, kimlik doğrulama, dosya sistemleri, SSH, güvenlik duvarı, loglama gibi onlarca kategoriyi tarar. Sonunda bir özet ve Hardening index gösterir.

4. Çıktıyı okumak
Çıktıda üç ana işaret vardır:
  • Warnings (uyarılar): öncelik verilmesi gereken bulgular.
  • Suggestions (öneriler): iyileştirme fırsatları.
  • Hardening index: 0-100 arası genel skor.
Detaylı log:
Kod:
sudo cat /var/log/lynis.log # Rapor verisi: sudo cat /var/log/lynis-report.dat

5. Sertleştirme örnekleri
Lynis'in sık önerdiği tipik adımlar:
  1. SSH sertleştirme: /etc/ssh/sshd_config içinde PermitRootLogin no, PasswordAuthentication no (anahtar tabanlı giriş), Protocol 2.
  2. Kernel parametreleri: /etc/sysctl.conf ile ağ ve bellek korumaları.
  3. Gereksiz servisleri kapatma: kullanılmayan daemon'ları devre dışı bırakın.
  4. Güvenlik duvarı: varsayılan reddet politikasıyla ufw/nftables yapılandırın.
  5. Denetim izleme: auditd ve dosya bütünlük kontrolü (AIDE) kurun.
Her öneriye kör körüne uymayın; değişikliği anlayarak ve test ortamında doğrulayarak uygulayın.

6. Periyodik çalıştırma
Sertleştirme tek seferlik değil, sürekli bir süreç. cron ile haftalık denetim:
Kod:
0 3 * * 0 /usr/sbin/lynis audit system --quiet >> /var/log/lynis-weekly.log 2>&1

Sonuç
Lynis, "sunucum ne kadar güvenli?" sorusuna ölçülebilir bir yanıt ve somut yapılacaklar listesi verir. Skoru yükseltmek amaç değil, araçtır; asıl hedef anlaşılır ve sürdürülebilir bir sertleştirme. Sunucularınızda en son ne zaman denetim çalıştırdınız?

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   17-t17-lynis-linux-sertlestirme.png (Dosya Boyutu: 109.13 KB / İndirme Sayısı: 2) ]]> <![CDATA[Gitleaks ile Kod Depolarında Sızan Sır Avı: CI'ya Entegre Pratik Rehber]]> https://www.turkteam.org/konu-gitleaks-ile-kod-depolarinda-sizan-sir-avi-ci-ya-entegre-pratik-rehber.html Sun, 25 Oct 2026 11:48:30 +0300 KulTigin]]> https://www.turkteam.org/konu-gitleaks-ile-kod-depolarinda-sizan-sir-avi-ci-ya-entegre-pratik-rehber.html [Resim: attachment.php?aid=435]
Selamlar,

Kaynak kod depolarına yanlışlıkla işlenmiş API anahtarları, parolalar ve token'lar en yaygın sızıntı nedenlerinden biri. Bu rehberde, açık kaynak sır tarama aracı Gitleaks ile depolarınızı nasıl tarayacağınızı, pre-commit ile sızıntıyı kaynakta nasıl durduracağınızı ve CI'ya nasıl entegre edeceğinizi adım adım anlatıyorum. (Yalnızca kendi veya yetkili olduğunuz depolarda kullanın.)

Konuda anlatılacaklar
  1. Gitleaks nedir?
  2. Kurulum
  3. Depo tarama
  4. Git geçmişini tarama
  5. pre-commit hook
  6. CI entegrasyonu ve ipuçları

1. Gitleaks nedir?
Gitleaks, Go ile yazılmış, dosyalarda ve git geçmişinde parola, anahtar ve token gibi sabit kodlanmış sırları tespit eden bir araç. Düzenli ifade (regex) ve entropi tabanlı kurallarla çalışır; kendi kurallarınızı .gitleaks.toml ile ekleyebilirsiniz.

2. Kurulum
Kod:
# Go ile go install github.com/gitleaks/gitleaks/v8@latest # macOS (Homebrew) brew install gitleaks # Docker docker pull zricethezav/gitleaks:latest

3. Depo tarama
Çalışma dizinindeki dosyaları (git geçmişi olmadan) taramak:
Kod:
gitleaks dir . --report-path gitleaks-report.json -v
Bir bulgu örneği şu alanları içerir: kural adı, dosya, satır, commit ve gizli değerin kısmen maskelenmiş hali.

4. Git geçmişini tarama
Sırlar genelde eski commit'lerde saklıdır. Tüm geçmişi taramak:
Kod:
gitleaks git . -v --report-path history-report.json
Belirli bir aralık:
Kod:
gitleaks git . --log-opts="--since=2026-01-01" -v

5. pre-commit hook
Sızmayı kaynakta durdurmanın en iyi yolu, commit öncesi taramak. .pre-commit-config.yaml:
Kod:
repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.0.0 hooks: - id: gitleaks
Ardından:
Kod:
pre-commit install

6. CI entegrasyonu
GitHub Actions örneği:
Kod:
name: gitleaks on: [push, pull_request] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - uses: gitleaks/gitleaks-action@v2
Önemli ipucu: fetch-depth: 0 verin ki tüm geçmiş çekilsin; aksi halde eski commit'lerdeki sırlar kaçar.

İpuçları
  • Yanlış pozitifleri yönetin. .gitleaksignore dosyasına bulgu parmak izini ekleyerek bilinen güvenli bulguları susturabilirsiniz.
  • Sır bulunduysa sadece silmek yetmez. Sızan her anahtarı/token'ı iptal edip yeniden üretin; geçmişte kaldığı için hâlen geçerlidir.
  • Kendi kurallarınızı ekleyin. Kuruma özgü token formatları için .gitleaks.toml kullanın.

Sonuç
Gitleaks, sır sızıntısını hem geçmişte avlamak hem de gelecekte önlemek için hafif ve etkili bir araç. En büyük kazanım, pre-commit + CI ile sızıntıyı daha repoya girmeden durdurmak. Siz depolarınızda sır taraması yapıyor 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   16-t16-gitleaks-rehberi.png (Dosya Boyutu: 115.36 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=435]
Selamlar,

Kaynak kod depolarına yanlışlıkla işlenmiş API anahtarları, parolalar ve token'lar en yaygın sızıntı nedenlerinden biri. Bu rehberde, açık kaynak sır tarama aracı Gitleaks ile depolarınızı nasıl tarayacağınızı, pre-commit ile sızıntıyı kaynakta nasıl durduracağınızı ve CI'ya nasıl entegre edeceğinizi adım adım anlatıyorum. (Yalnızca kendi veya yetkili olduğunuz depolarda kullanın.)

Konuda anlatılacaklar
  1. Gitleaks nedir?
  2. Kurulum
  3. Depo tarama
  4. Git geçmişini tarama
  5. pre-commit hook
  6. CI entegrasyonu ve ipuçları

1. Gitleaks nedir?
Gitleaks, Go ile yazılmış, dosyalarda ve git geçmişinde parola, anahtar ve token gibi sabit kodlanmış sırları tespit eden bir araç. Düzenli ifade (regex) ve entropi tabanlı kurallarla çalışır; kendi kurallarınızı .gitleaks.toml ile ekleyebilirsiniz.

2. Kurulum
Kod:
# Go ile go install github.com/gitleaks/gitleaks/v8@latest # macOS (Homebrew) brew install gitleaks # Docker docker pull zricethezav/gitleaks:latest

3. Depo tarama
Çalışma dizinindeki dosyaları (git geçmişi olmadan) taramak:
Kod:
gitleaks dir . --report-path gitleaks-report.json -v
Bir bulgu örneği şu alanları içerir: kural adı, dosya, satır, commit ve gizli değerin kısmen maskelenmiş hali.

4. Git geçmişini tarama
Sırlar genelde eski commit'lerde saklıdır. Tüm geçmişi taramak:
Kod:
gitleaks git . -v --report-path history-report.json
Belirli bir aralık:
Kod:
gitleaks git . --log-opts="--since=2026-01-01" -v

5. pre-commit hook
Sızmayı kaynakta durdurmanın en iyi yolu, commit öncesi taramak. .pre-commit-config.yaml:
Kod:
repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.0.0 hooks: - id: gitleaks
Ardından:
Kod:
pre-commit install

6. CI entegrasyonu
GitHub Actions örneği:
Kod:
name: gitleaks on: [push, pull_request] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - uses: gitleaks/gitleaks-action@v2
Önemli ipucu: fetch-depth: 0 verin ki tüm geçmiş çekilsin; aksi halde eski commit'lerdeki sırlar kaçar.

İpuçları
  • Yanlış pozitifleri yönetin. .gitleaksignore dosyasına bulgu parmak izini ekleyerek bilinen güvenli bulguları susturabilirsiniz.
  • Sır bulunduysa sadece silmek yetmez. Sızan her anahtarı/token'ı iptal edip yeniden üretin; geçmişte kaldığı için hâlen geçerlidir.
  • Kendi kurallarınızı ekleyin. Kuruma özgü token formatları için .gitleaks.toml kullanın.

Sonuç
Gitleaks, sır sızıntısını hem geçmişte avlamak hem de gelecekte önlemek için hafif ve etkili bir araç. En büyük kazanım, pre-commit + CI ile sızıntıyı daha repoya girmeden durdurmak. Siz depolarınızda sır taraması yapıyor 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   16-t16-gitleaks-rehberi.png (Dosya Boyutu: 115.36 KB / İndirme Sayısı: 1) ]]> <![CDATA[Windows Server 2016 Destek Sonu 12 Ocak 2027: Son Güncelleme ve Geçiş Planı]]> https://www.turkteam.org/konu-windows-server-2016-destek-sonu-12-ocak-2027-son-guncelleme-ve-gecis-plani.html Sun, 25 Oct 2026 11:47:42 +0300 BilgeKagan]]> https://www.turkteam.org/konu-windows-server-2016-destek-sonu-12-ocak-2027-son-guncelleme-ve-gecis-plani.html [Resim: attachment.php?aid=434]
Selamlar,

Microsoft, Windows Server 2016'nın 12 Ocak 2027'de destek sonuna (EOL) ulaşacağını duyurdu. BleepingComputer konuyu aktardı. Ocak 2027 güvenlik güncellemesi bu sürüm için son güncelleme olacak; sonrasında aylık güvenlik yaması gelmeyecek. EOL, bir "takvim notu" değil; yamasız kalan sunucular hızla saldırı hedefi olur. Burada takvimi ve güvenli geçiş seçeneklerinizi ele alıyorum.

Konuda anlatılacaklar
  1. EOL ne demek, neden önemli?
  2. Takvim ve etkilenen sürümler
  3. Geçiş seçeneği: Windows Server 2025
  4. ESU: ek süre gerekiyorsa
  5. Geçiş kontrol listesi

1. EOL ne demek?
Destek sonu, ürünün artık güvenlik güncellemesi almayacağı anlamına gelir. Yeni keşfedilen her açık, yamasız kalır; yani sunucu zamanla giderek daha savunmasız hale gelir. Server 2016 Ocak 2022'de ana desteği (mainstream) bitirmişti; genişletilmiş destek de Ocak 2027'de bitiyor.

2. Takvim ve etkilenen sürümler
Kod:
Genel kullanıma çıkış : Ekim 2016 Ana destek sonu : Ocak 2022 Genişletilmiş destek : 12 Ocak 2027 (son güvenlik güncellemesi)
Microsoft'a göre bu durum tüm Server 2016 sürümleri için geçerli: Datacenter, Essentials, MultiPoint Premium ve Standard. Aynı tarihte Server 2016 Essentials özellikleri de desteklenmeyi bırakacak.

3. Geçiş: Windows Server 2025
Microsoft, Windows Server 2025'e geçişi öneriyor. Bu, en güncel Uzun Vadeli Servis Kanalı (LTSC) sürümü; Kasım 2024'te genel kullanıma çıktı. Yaşam döngüsüne göre ana desteği Kasım 2029'da bitecek, genişletilmiş destek Kasım 2034'e kadar sürecek. Dağıtımdan önce test etmek isteyenler için 180 günlük ücretsiz deneme mevcut.

4. ESU
Hemen geçiş yapamayanlar için Azure Arc üzerinden Extended Security Updates (ESU) seçeneği var; ancak bu Standard ve Datacenter için geçerli, Essentials için değil. ESU bir köprü çözümüdür, kalıcı plan değil.

5. Geçiş kontrol listesi
  1. Envanter çıkarın. Hangi sunucular Server 2016 çalıştırıyor, üzerlerinde hangi roller var?
  2. Uygulama uyumluluğunu test edin. Kritik iş uygulamalarını Server 2025'te deneme ortamında doğrulayın.
  3. İnternete dönük sunucuları öne alın. En yüksek risk onlarda.
  4. Geçiş yapılamıyorsa ESU + izolasyon planlayın; yamasız sunucuları ağ segmentasyonuyla sınırlandırın.
  5. Yedekleme ve geri dönüş planı hazırlayın.
Not: Microsoft ayrıca Windows 11 24H2 Home/Pro sürümlerinin güncelleme almayı bırakıp 26H2'ye geçilmesi gerektiğini de duyurdu.

Sonuç
EOL tarihleri sürpriz değildir; planlama süresi verir. Server 2016'yı hâlâ çalıştırıyorsanız, Ocak 2027 öncesi geçiş ya da ESU + izolasyon için şimdi plan yapmak gerekiyor. Ortamınızda kaç Server 2016 sunucusu kaldı, biliyor 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   15-t15-windows-server-2016-eol.png (Dosya Boyutu: 126.99 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=434]
Selamlar,

Microsoft, Windows Server 2016'nın 12 Ocak 2027'de destek sonuna (EOL) ulaşacağını duyurdu. BleepingComputer konuyu aktardı. Ocak 2027 güvenlik güncellemesi bu sürüm için son güncelleme olacak; sonrasında aylık güvenlik yaması gelmeyecek. EOL, bir "takvim notu" değil; yamasız kalan sunucular hızla saldırı hedefi olur. Burada takvimi ve güvenli geçiş seçeneklerinizi ele alıyorum.

Konuda anlatılacaklar
  1. EOL ne demek, neden önemli?
  2. Takvim ve etkilenen sürümler
  3. Geçiş seçeneği: Windows Server 2025
  4. ESU: ek süre gerekiyorsa
  5. Geçiş kontrol listesi

1. EOL ne demek?
Destek sonu, ürünün artık güvenlik güncellemesi almayacağı anlamına gelir. Yeni keşfedilen her açık, yamasız kalır; yani sunucu zamanla giderek daha savunmasız hale gelir. Server 2016 Ocak 2022'de ana desteği (mainstream) bitirmişti; genişletilmiş destek de Ocak 2027'de bitiyor.

2. Takvim ve etkilenen sürümler
Kod:
Genel kullanıma çıkış : Ekim 2016 Ana destek sonu : Ocak 2022 Genişletilmiş destek : 12 Ocak 2027 (son güvenlik güncellemesi)
Microsoft'a göre bu durum tüm Server 2016 sürümleri için geçerli: Datacenter, Essentials, MultiPoint Premium ve Standard. Aynı tarihte Server 2016 Essentials özellikleri de desteklenmeyi bırakacak.

3. Geçiş: Windows Server 2025
Microsoft, Windows Server 2025'e geçişi öneriyor. Bu, en güncel Uzun Vadeli Servis Kanalı (LTSC) sürümü; Kasım 2024'te genel kullanıma çıktı. Yaşam döngüsüne göre ana desteği Kasım 2029'da bitecek, genişletilmiş destek Kasım 2034'e kadar sürecek. Dağıtımdan önce test etmek isteyenler için 180 günlük ücretsiz deneme mevcut.

4. ESU
Hemen geçiş yapamayanlar için Azure Arc üzerinden Extended Security Updates (ESU) seçeneği var; ancak bu Standard ve Datacenter için geçerli, Essentials için değil. ESU bir köprü çözümüdür, kalıcı plan değil.

5. Geçiş kontrol listesi
  1. Envanter çıkarın. Hangi sunucular Server 2016 çalıştırıyor, üzerlerinde hangi roller var?
  2. Uygulama uyumluluğunu test edin. Kritik iş uygulamalarını Server 2025'te deneme ortamında doğrulayın.
  3. İnternete dönük sunucuları öne alın. En yüksek risk onlarda.
  4. Geçiş yapılamıyorsa ESU + izolasyon planlayın; yamasız sunucuları ağ segmentasyonuyla sınırlandırın.
  5. Yedekleme ve geri dönüş planı hazırlayın.
Not: Microsoft ayrıca Windows 11 24H2 Home/Pro sürümlerinin güncelleme almayı bırakıp 26H2'ye geçilmesi gerektiğini de duyurdu.

Sonuç
EOL tarihleri sürpriz değildir; planlama süresi verir. Server 2016'yı hâlâ çalıştırıyorsanız, Ocak 2027 öncesi geçiş ya da ESU + izolasyon için şimdi plan yapmak gerekiyor. Ortamınızda kaç Server 2016 sunucusu kaldı, biliyor 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   15-t15-windows-server-2016-eol.png (Dosya Boyutu: 126.99 KB / İndirme Sayısı: 1) ]]> <![CDATA[Google: Gemini'ye Bağlanan Gmail/Fotoğraflar Verisi Hedefli Reklama Dönüşebilir]]> https://www.turkteam.org/konu-google-gemini-ye-baglanan-gmail-fotograflar-verisi-hedefli-reklama-donusebilir.html Sun, 25 Oct 2026 11:46:35 +0300 BilgeKagan]]> https://www.turkteam.org/konu-google-gemini-ye-baglanan-gmail-fotograflar-verisi-hedefli-reklama-donusebilir.html [Resim: attachment.php?aid=432]
Selamlar,

Google, gizlilik politikasını güncelleyerek Arama veya Gemini'deki kişiselleştirilmiş yapay zeka özelliklerini kullanmanın, bağlı diğer Google servislerindeki etkinliğinize dayalı hedefli reklam göstermesine olanak tanıyabileceğini açıkça belirtti. The Hacker News konuyu aktardı. Bu, YZ kolaylığı ile gizlilik arasındaki takasın somut bir örneği. Burada değişikliğin ne anlama geldiğini ve nasıl opt-out yapacağınızı ele alıyorum.

Konuda anlatılacaklar
  1. Politika tam olarak ne diyor?
  2. Personal Intelligence nedir?
  3. Varsayılan durum ve değişen durum
  4. Kimler etkileniyor?
  5. Opt-out adımları

1. Politika ne diyor?
16 Ekim 2026'da yürürlüğe giren güncellemede:
Alıntı:Arama veya Gemini gibi bazı Google servislerine, kullandığınız diğer Google servislerindeki verilere (Google Fotoğraflar ve Gmail, Drive gibi Workspace uygulamaları) erişmesine izin vermeyi seçebilirsiniz... Örneğin, Arama, erişimine izin verdiğiniz bazı verileri reklamlar dahil içeriği kişiselleştirmek için işleyebilir.
Google ayrıca, Drive, Gmail veya Google Fotoğraflar'daki içeriğinize dayalı kişiselleştirilmiş reklam göstermediğini, meğer ki bu verileri reklam destekleyen diğer servislere sunmayı seçesiniz, diyor.

2. Personal Intelligence nedir?
Ocak 2026'da Gemini'de tanıtılan Personal Intelligence, kullanıcıların Gmail, Google Fotoğraflar ve YouTube gibi servisleri bağlayarak sohbet geçmişi ve tercihleriyle birlikte daha kişisel yanıtlar almasını sağlıyor.

3. Varsayılan vs değişen durum
Önemli ayrım:
  • Varsayılan olarak Gmail, Drive veya Fotoğraflar içeriğiniz reklam kişiselleştirmek için kullanılmaz.
  • Ancak Personal Intelligence açıkken bu verileri AI Mode veya Arama araçlarıyla paylaşmayı seçerseniz, o verilerin bilgilendirdiği yanıtlardaki içerik hedefli reklam sinyali olarak kullanılabilir.
Politika, kişisel veriyi YZ araçlarına beslemek ile reklam kişiselleştirmesi arasındaki bağlantıyı netleştirmeyi amaçlıyor.

4. Kimler etkileniyor?
Personal Intelligence şu an 18 yaş üstü uygun kullanıcılara küresel beta olarak sunuluyor; Avrupa Ekonomik Alanı, İsviçre, Birleşik Krallık ve Nijerya hariç.

5. Opt-out adımları
  1. Bağlantılı uygulamaları ayırın. Personal Intelligence içinden Gmail/Fotoğraflar gibi uygulamaların bağlantısını kaldırabilirsiniz.
  2. Kişiselleştirilmiş önerileri kapatın. Arama Servisleri Kişiselleştirme ayarlarından devre dışı bırakabilirsiniz.
  3. My Ad Center'dan kişiselleştirilmiş reklamları tamamen kapatabilirsiniz.
  4. Bağlamadan önce düşünün. Uygulama bağlamak kolaylık sağlar ama gizlilik takası yaratır.
Not: Haber, OpenAI'nin de Ocak 2026'dan beri ABD'li oturum açmış yetişkinlere ChatGPT'de reklam göstermeye başladığını hatırlatıyor. Eğilim genel.

Sonuç
YZ asistanlarına kişisel veri bağlamak güçlü bir kişiselleştirme sağlıyor, ama bunun reklam tarafına da sinyal ürettiğini bilmek gerekiyor. Seçim sizin, yeter ki bilinçli olsun. Siz YZ asistanlarına kişisel hesaplarınızı bağlar mısınız?

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   14-t14-google-gemini-reklam-gizlilik.png (Dosya Boyutu: 121.72 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=432]
Selamlar,

Google, gizlilik politikasını güncelleyerek Arama veya Gemini'deki kişiselleştirilmiş yapay zeka özelliklerini kullanmanın, bağlı diğer Google servislerindeki etkinliğinize dayalı hedefli reklam göstermesine olanak tanıyabileceğini açıkça belirtti. The Hacker News konuyu aktardı. Bu, YZ kolaylığı ile gizlilik arasındaki takasın somut bir örneği. Burada değişikliğin ne anlama geldiğini ve nasıl opt-out yapacağınızı ele alıyorum.

Konuda anlatılacaklar
  1. Politika tam olarak ne diyor?
  2. Personal Intelligence nedir?
  3. Varsayılan durum ve değişen durum
  4. Kimler etkileniyor?
  5. Opt-out adımları

1. Politika ne diyor?
16 Ekim 2026'da yürürlüğe giren güncellemede:
Alıntı:Arama veya Gemini gibi bazı Google servislerine, kullandığınız diğer Google servislerindeki verilere (Google Fotoğraflar ve Gmail, Drive gibi Workspace uygulamaları) erişmesine izin vermeyi seçebilirsiniz... Örneğin, Arama, erişimine izin verdiğiniz bazı verileri reklamlar dahil içeriği kişiselleştirmek için işleyebilir.
Google ayrıca, Drive, Gmail veya Google Fotoğraflar'daki içeriğinize dayalı kişiselleştirilmiş reklam göstermediğini, meğer ki bu verileri reklam destekleyen diğer servislere sunmayı seçesiniz, diyor.

2. Personal Intelligence nedir?
Ocak 2026'da Gemini'de tanıtılan Personal Intelligence, kullanıcıların Gmail, Google Fotoğraflar ve YouTube gibi servisleri bağlayarak sohbet geçmişi ve tercihleriyle birlikte daha kişisel yanıtlar almasını sağlıyor.

3. Varsayılan vs değişen durum
Önemli ayrım:
  • Varsayılan olarak Gmail, Drive veya Fotoğraflar içeriğiniz reklam kişiselleştirmek için kullanılmaz.
  • Ancak Personal Intelligence açıkken bu verileri AI Mode veya Arama araçlarıyla paylaşmayı seçerseniz, o verilerin bilgilendirdiği yanıtlardaki içerik hedefli reklam sinyali olarak kullanılabilir.
Politika, kişisel veriyi YZ araçlarına beslemek ile reklam kişiselleştirmesi arasındaki bağlantıyı netleştirmeyi amaçlıyor.

4. Kimler etkileniyor?
Personal Intelligence şu an 18 yaş üstü uygun kullanıcılara küresel beta olarak sunuluyor; Avrupa Ekonomik Alanı, İsviçre, Birleşik Krallık ve Nijerya hariç.

5. Opt-out adımları
  1. Bağlantılı uygulamaları ayırın. Personal Intelligence içinden Gmail/Fotoğraflar gibi uygulamaların bağlantısını kaldırabilirsiniz.
  2. Kişiselleştirilmiş önerileri kapatın. Arama Servisleri Kişiselleştirme ayarlarından devre dışı bırakabilirsiniz.
  3. My Ad Center'dan kişiselleştirilmiş reklamları tamamen kapatabilirsiniz.
  4. Bağlamadan önce düşünün. Uygulama bağlamak kolaylık sağlar ama gizlilik takası yaratır.
Not: Haber, OpenAI'nin de Ocak 2026'dan beri ABD'li oturum açmış yetişkinlere ChatGPT'de reklam göstermeye başladığını hatırlatıyor. Eğilim genel.

Sonuç
YZ asistanlarına kişisel veri bağlamak güçlü bir kişiselleştirme sağlıyor, ama bunun reklam tarafına da sinyal ürettiğini bilmek gerekiyor. Seçim sizin, yeter ki bilinçli olsun. Siz YZ asistanlarına kişisel hesaplarınızı bağlar mısınız?

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   14-t14-google-gemini-reklam-gizlilik.png (Dosya Boyutu: 121.72 KB / İndirme Sayısı: 2) ]]> <![CDATA[INTERPOL Serengeti III: Afrika'da 10.909 Kötü Amaçlı Ağ Çökertildi, 1.462 Tutuklama]]> https://www.turkteam.org/konu-interpol-serengeti-iii-afrika-da-10-909-kotu-amacli-ag-cokertildi-1-462-tutuklama.html Sun, 25 Oct 2026 11:45:27 +0300 BilgeKagan]]> https://www.turkteam.org/konu-interpol-serengeti-iii-afrika-da-10-909-kotu-amacli-ag-cokertildi-1-462-tutuklama.html [Resim: attachment.php?aid=430]
Selamlar,

INTERPOL, Afrika'nın en büyük siber suç operasyonlarından birini, Operation Serengeti III'ü duyurdu. 29 Haziran - 31 Ağustos 2026 arasında 21 ülkeden kolluk kuvvetleri 10.909 kötü amaçlı ağı çökertti, 1.462 şüpheliyi tutukladı ve 105 milyon dolardan fazla yasadışı fonu geri aldı. BleepingComputer konuyu aktardı. Rakamların büyüklüğü kadar, kullanılan dolandırıcılık taktikleri de bireysel kullanıcılar için öğretici. Burada operasyonu ve çıkarılacak dersleri özetliyorum.

Konuda anlatılacaklar
  1. Rakamlarla Serengeti III
  2. Hangi suç türleri hedeflendi?
  3. Operasyon vurguları
  4. YZ'nin rolü
  5. Bireysel korunma dersleri

1. Rakamlarla
Kod:
Katılan ülke : 21 Çökertilen ağ : 10.909 Tutuklama : 1.462 Geri alınan fon : 105 milyon USD+ Tespit edilen mağdur: 65.929 Bağlantılı kayıp : 385 milyon USD+

2. Hangi suç türleri?
Operasyon; siber destekli dolandırıcılık, fidye yazılımı, iş e-postası ele geçirme (BEC), çevrimiçi dolandırıcılıklar ve dijital şantajı hedefledi. INTERPOL'ün Afrika Siber Tehdit Değerlendirmesi 2026 raporu, yapay zekanın kıtadaki siber suçları giderek kolaylaştırdığına ve mali kayıpların arttığına işaret ediyor.

3. Operasyon vurguları
  • Uganda: İki ülkeler arası dolandırıcılık çetesi çökertildi, Asya'daki mağdurları hedefleyen yatırım/emeklilik dolandırıcılığından 365 yabancı uyruklu tutuklandı. Dönüşümlü çağrı merkezi modeli, sahte ticaret platformları ve sahte siteler kullanılıyordu.
  • Angola: İki yasadışı kripto madenciliği merkezi çökertildi, 9 şüpheli tutuklandı, 2.000'den fazla madencilik cihazı ve altı yasadışı güç trafosu ele geçirildi.
  • Nijerya: Büyük ölçekli bir oltalama/BEC operasyonu; yaklaşık 2,1 milyon e-posta adresi toplanmıştı. Ayrı bir soruşturmada 2,4 milyon dolardan fazla suç geliri kripto ile aklanmıştı.

4. YZ'nin rolü
INTERPOL, raporunda yapay zekanın kıtada siber suç faaliyetini giderek daha fazla kolaylaştırdığını vurguluyor. Operasyon, Group-IB, Kaspersky, Fortinet gibi özel sektör ortaklarının istihbarat ve teknik analiz desteğiyle yürütüldü.

5. Bireysel korunma dersleri
Bu suçların çoğu son kullanıcıyı hedefliyor. Korunma için:
  1. Yatırım "fırsatlarına" şüpheyle yaklaşın. Garantili yüksek getiri vaadi klasik dolandırıcılık işaretidir.
  2. BEC'e karşı ikinci kanaldan doğrulama yapın. E-posta ile gelen havale/IBAN değişikliği taleplerini telefonla teyit edin.
  3. Oltalamaya karşı bağlantı ve göndericileri dikkatle kontrol edin; aciliyet baskısı uyarı işaretidir.
  4. E-posta sızıntısını kontrol edin. 2,1 milyon adres toplandığı düşünüldüğünde, adresinizin sızıp sızmadığını düzenli kontrol etmek önemli.
  5. Kripto ile ödeme baskısı neredeyse her zaman dolandırıcılık işaretidir.

Sonuç
Serengeti III, siber suçun sınır tanımadığını ama uluslararası iş birliğinin en etkili silah olduğunu gösteriyor. Rakamların arkasındaki taktikler (yatırım dolandırıcılığı, BEC, oltalama) tam da günlük hayatta karşılaştığımız tehditler. Çevrenizde yatırım dolandırıcılığına maruz kalan 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

.png   13-t13-interpol-serengeti-3.png (Dosya Boyutu: 120.71 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=430]
Selamlar,

INTERPOL, Afrika'nın en büyük siber suç operasyonlarından birini, Operation Serengeti III'ü duyurdu. 29 Haziran - 31 Ağustos 2026 arasında 21 ülkeden kolluk kuvvetleri 10.909 kötü amaçlı ağı çökertti, 1.462 şüpheliyi tutukladı ve 105 milyon dolardan fazla yasadışı fonu geri aldı. BleepingComputer konuyu aktardı. Rakamların büyüklüğü kadar, kullanılan dolandırıcılık taktikleri de bireysel kullanıcılar için öğretici. Burada operasyonu ve çıkarılacak dersleri özetliyorum.

Konuda anlatılacaklar
  1. Rakamlarla Serengeti III
  2. Hangi suç türleri hedeflendi?
  3. Operasyon vurguları
  4. YZ'nin rolü
  5. Bireysel korunma dersleri

1. Rakamlarla
Kod:
Katılan ülke : 21 Çökertilen ağ : 10.909 Tutuklama : 1.462 Geri alınan fon : 105 milyon USD+ Tespit edilen mağdur: 65.929 Bağlantılı kayıp : 385 milyon USD+

2. Hangi suç türleri?
Operasyon; siber destekli dolandırıcılık, fidye yazılımı, iş e-postası ele geçirme (BEC), çevrimiçi dolandırıcılıklar ve dijital şantajı hedefledi. INTERPOL'ün Afrika Siber Tehdit Değerlendirmesi 2026 raporu, yapay zekanın kıtadaki siber suçları giderek kolaylaştırdığına ve mali kayıpların arttığına işaret ediyor.

3. Operasyon vurguları
  • Uganda: İki ülkeler arası dolandırıcılık çetesi çökertildi, Asya'daki mağdurları hedefleyen yatırım/emeklilik dolandırıcılığından 365 yabancı uyruklu tutuklandı. Dönüşümlü çağrı merkezi modeli, sahte ticaret platformları ve sahte siteler kullanılıyordu.
  • Angola: İki yasadışı kripto madenciliği merkezi çökertildi, 9 şüpheli tutuklandı, 2.000'den fazla madencilik cihazı ve altı yasadışı güç trafosu ele geçirildi.
  • Nijerya: Büyük ölçekli bir oltalama/BEC operasyonu; yaklaşık 2,1 milyon e-posta adresi toplanmıştı. Ayrı bir soruşturmada 2,4 milyon dolardan fazla suç geliri kripto ile aklanmıştı.

4. YZ'nin rolü
INTERPOL, raporunda yapay zekanın kıtada siber suç faaliyetini giderek daha fazla kolaylaştırdığını vurguluyor. Operasyon, Group-IB, Kaspersky, Fortinet gibi özel sektör ortaklarının istihbarat ve teknik analiz desteğiyle yürütüldü.

5. Bireysel korunma dersleri
Bu suçların çoğu son kullanıcıyı hedefliyor. Korunma için:
  1. Yatırım "fırsatlarına" şüpheyle yaklaşın. Garantili yüksek getiri vaadi klasik dolandırıcılık işaretidir.
  2. BEC'e karşı ikinci kanaldan doğrulama yapın. E-posta ile gelen havale/IBAN değişikliği taleplerini telefonla teyit edin.
  3. Oltalamaya karşı bağlantı ve göndericileri dikkatle kontrol edin; aciliyet baskısı uyarı işaretidir.
  4. E-posta sızıntısını kontrol edin. 2,1 milyon adres toplandığı düşünüldüğünde, adresinizin sızıp sızmadığını düzenli kontrol etmek önemli.
  5. Kripto ile ödeme baskısı neredeyse her zaman dolandırıcılık işaretidir.

Sonuç
Serengeti III, siber suçun sınır tanımadığını ama uluslararası iş birliğinin en etkili silah olduğunu gösteriyor. Rakamların arkasındaki taktikler (yatırım dolandırıcılığı, BEC, oltalama) tam da günlük hayatta karşılaştığımız tehditler. Çevrenizde yatırım dolandırıcılığına maruz kalan 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

.png   13-t13-interpol-serengeti-3.png (Dosya Boyutu: 120.71 KB / İndirme Sayısı: 1) ]]> <![CDATA[İran Bağlantılı Prince of Persia 2016'dan Beri İlk Kez ABD'de C2 Barındırdı]]> https://www.turkteam.org/konu-iran-baglantili-prince-of-persia-2016-dan-beri-ilk-kez-abd-de-c2-barindirdi.html Sun, 25 Oct 2026 11:44:19 +0300 BilgeKagan]]> https://www.turkteam.org/konu-iran-baglantili-prince-of-persia-2016-dan-beri-ilk-kez-abd-de-c2-barindirdi.html [Resim: attachment.php?aid=428]
Selamlar,

Semperis'in raporuna göre İran devleti bağlantılı Prince of Persia (diğer adıyla Infy) grubu, bu yıl komuta-kontrol (C2) sunucularından birini ABD'de çalıştırdı; bu, 2016'dan beri ilk kez. SecurityWeek konuyu aktardı. Yaklaşık 20 yıldır faal olan ve çoğunlukla İranlı muhalifler ile ABD/Avrupa/Orta Doğu'daki kurumları hedefleyen grup, uzun bir sessizliğin ardından dikkat çeken bir altyapı tercihi yaptı. Burada olayı ve savunma çıkarımlarını ele alıyorum.

Konuda anlatılacaklar
  1. Prince of Persia kim?
  2. Üç aylık sessizlik
  3. ABD'de barınma: Namecheap paylaşımlı hosting
  4. Tornado zararlısı
  5. Savunma çıkarımları

1. Prince of Persia kim?
Tomer Bar'ın (Semperis) izlediği grup, neredeyse yirmi yıldır faal. Hedefleri çoğunlukla İranlı muhalifler, yanında ABD, Avrupa ve Orta Doğu'daki kamu ve özel kuruluşlar.

2. Üç aylık sessizlik
Bir başka firmanın Şubat 2026 raporundan bir hafta sonra grup bir C2 sunucusunu kapattı ve diğerlerini taşıdı, ardından üç ay boyunca operasyonlarını durdurdu. Bu, Semperis'in doğruladığı en uzun kesinti. Operasyonlar 27 Mayıs'ta yeni bir C2 ile yeniden başladı; yedi gün içinde Tonnerre adlı zararlı tek bir mağdurdan 1.800'den fazla dosya sızdırdı.

3. ABD'de barınma
Ağustos'ta Bar, muhtemelen 7 Temmuz'da kurulan, Tornado'nun ikinci aşamasını destekleyen yeni bir sunucu buldu. Bu sunucu ABD'deydi; grubun 2016'dan beri ülke içinde C2 barındırmasının ilk örneği. Daha da ilginci, saldırganlar VPS yerine binlerce alan adının bulunduğu Namecheap paylaşımlı hosting'e geçti. Bar'ın ifadesiyle: "Prince of Persia'yı saklanırken bulmayı en son bekleyeceğimiz yerdi." 24 Ağustos'ta grup, Cloudflare arkasında gizlenen başka bir Tornado ikinci aşama sunucusu kurmaya başladı; Semperis, ABD sunucusunun ifşa olduğunu fark ettiklerini düşünüyor.

4. Tornado zararlısı
Tornado, grubun en yeni zararlı ailesi; yeteneklerinden biri bir Telegram botu üzerinden dosya çalmak. Araştırma özetlerine göre grup HTTPS ve Telegram API tabanlı C2, DGA alan adları ve RSA ile doğrulanan istekler kullanıyor.

5. Savunma çıkarımları
  1. Coğrafi kökene göre güven olmaz. "ABD IP'si = güvenli" varsayımı tehlikeli; devlet aktörleri de ülke içi bulut/hosting kullanıyor.
  2. Paylaşımlı hosting C2'si tespiti zordur. Meşru sitelerle aynı IP'yi paylaştığı için salt IP engelleme yetmez; alan adı ve davranış bazlı tespit gerekir.
  3. Şüpheli Telegram trafiğini izleyin. Semperis, kurumlara IoC'leri araçlarına eklemeyi ve Telegram trafiğini gözlemlemeyi öneriyor.
  4. DGA alan adlarını avlayın. Algoritmik üretilmiş alan adlarına giden DNS sorguları güçlü bir göstergedir.

Sonuç
Prince of Persia vakası, atıf ve altyapı takibinin ne kadar değerli olduğunu gösteriyor. Uzun soluklu bir aktörün altyapı alışkanlığını değiştirmesi, savunucular için hem yeni bir risk hem de yeni bir tespit fırsatı. Siz C2 tespitinde IP'ye mi, alan adı/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   12-t12-prince-of-persia-tornado.png (Dosya Boyutu: 118.57 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=428]
Selamlar,

Semperis'in raporuna göre İran devleti bağlantılı Prince of Persia (diğer adıyla Infy) grubu, bu yıl komuta-kontrol (C2) sunucularından birini ABD'de çalıştırdı; bu, 2016'dan beri ilk kez. SecurityWeek konuyu aktardı. Yaklaşık 20 yıldır faal olan ve çoğunlukla İranlı muhalifler ile ABD/Avrupa/Orta Doğu'daki kurumları hedefleyen grup, uzun bir sessizliğin ardından dikkat çeken bir altyapı tercihi yaptı. Burada olayı ve savunma çıkarımlarını ele alıyorum.

Konuda anlatılacaklar
  1. Prince of Persia kim?
  2. Üç aylık sessizlik
  3. ABD'de barınma: Namecheap paylaşımlı hosting
  4. Tornado zararlısı
  5. Savunma çıkarımları

1. Prince of Persia kim?
Tomer Bar'ın (Semperis) izlediği grup, neredeyse yirmi yıldır faal. Hedefleri çoğunlukla İranlı muhalifler, yanında ABD, Avrupa ve Orta Doğu'daki kamu ve özel kuruluşlar.

2. Üç aylık sessizlik
Bir başka firmanın Şubat 2026 raporundan bir hafta sonra grup bir C2 sunucusunu kapattı ve diğerlerini taşıdı, ardından üç ay boyunca operasyonlarını durdurdu. Bu, Semperis'in doğruladığı en uzun kesinti. Operasyonlar 27 Mayıs'ta yeni bir C2 ile yeniden başladı; yedi gün içinde Tonnerre adlı zararlı tek bir mağdurdan 1.800'den fazla dosya sızdırdı.

3. ABD'de barınma
Ağustos'ta Bar, muhtemelen 7 Temmuz'da kurulan, Tornado'nun ikinci aşamasını destekleyen yeni bir sunucu buldu. Bu sunucu ABD'deydi; grubun 2016'dan beri ülke içinde C2 barındırmasının ilk örneği. Daha da ilginci, saldırganlar VPS yerine binlerce alan adının bulunduğu Namecheap paylaşımlı hosting'e geçti. Bar'ın ifadesiyle: "Prince of Persia'yı saklanırken bulmayı en son bekleyeceğimiz yerdi." 24 Ağustos'ta grup, Cloudflare arkasında gizlenen başka bir Tornado ikinci aşama sunucusu kurmaya başladı; Semperis, ABD sunucusunun ifşa olduğunu fark ettiklerini düşünüyor.

4. Tornado zararlısı
Tornado, grubun en yeni zararlı ailesi; yeteneklerinden biri bir Telegram botu üzerinden dosya çalmak. Araştırma özetlerine göre grup HTTPS ve Telegram API tabanlı C2, DGA alan adları ve RSA ile doğrulanan istekler kullanıyor.

5. Savunma çıkarımları
  1. Coğrafi kökene göre güven olmaz. "ABD IP'si = güvenli" varsayımı tehlikeli; devlet aktörleri de ülke içi bulut/hosting kullanıyor.
  2. Paylaşımlı hosting C2'si tespiti zordur. Meşru sitelerle aynı IP'yi paylaştığı için salt IP engelleme yetmez; alan adı ve davranış bazlı tespit gerekir.
  3. Şüpheli Telegram trafiğini izleyin. Semperis, kurumlara IoC'leri araçlarına eklemeyi ve Telegram trafiğini gözlemlemeyi öneriyor.
  4. DGA alan adlarını avlayın. Algoritmik üretilmiş alan adlarına giden DNS sorguları güçlü bir göstergedir.

Sonuç
Prince of Persia vakası, atıf ve altyapı takibinin ne kadar değerli olduğunu gösteriyor. Uzun soluklu bir aktörün altyapı alışkanlığını değiştirmesi, savunucular için hem yeni bir risk hem de yeni bir tespit fırsatı. Siz C2 tespitinde IP'ye mi, alan adı/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   12-t12-prince-of-persia-tornado.png (Dosya Boyutu: 118.57 KB / İndirme Sayısı: 1) ]]> <![CDATA[Signal RingRTC Açığı CVE-2026-113380: Kapattığınız Arama Neden Bitmiyor?]]> https://www.turkteam.org/konu-signal-ringrtc-acigi-cve-2026-113380-kapattiginiz-arama-neden-bitmiyor.html Sun, 25 Oct 2026 11:43:11 +0300 BilgeKagan]]> https://www.turkteam.org/konu-signal-ringrtc-acigi-cve-2026-113380-kapattiginiz-arama-neden-bitmiyor.html [Resim: attachment.php?aid=427]
Selamlar,

Signal, kötü niyetli bir arayanın, kullanıcı aramayı kapattıktan sonra bile ses ve video akışını açık tutmasına izin verebilen kritik bir açığı kapattı. CVE-2026-113380 (CVSS 9.3) olarak izlenen açık, Signal'in sesli/görüntülü aramalarda kullandığı açık kaynaklı RingRTC kütüphanesini etkiliyor. SecurityWeek konuyu aktardı. Bu, "kapat" düğmesinin neden her zaman garanti olmadığını gösteren öğretici bir örnek. Burada açığı ve kullanıcı önlemlerini ele alıyorum.

Konuda anlatılacaklar
  1. Açık ne yapıyor?
  2. Teknik neden: FSM kuyruğu
  3. Etkilenen ve düzeltilmiş sürümler
  4. Gerçek dünya riski
  5. Kullanıcı önlemleri

1. Açık ne yapıyor?
Normalde aramayı kapattığınızda mikrofon ve kamera kapanır. Bu açıkta uzaktaki bir katılımcı, aramanın olay kuyruğunu doldurarak kapatma işlemini sonsuza dek bekletebiliyor. Sonuç: kullanıcı aramayı bitirdiğini sanırken ses (ve muhtemelen video) akmaya devam ediyor.

2. Teknik neden
RingRTC, aramayı WebRTC tabanlı bir Sonlu Durum Makinesi (Finite State Machine, FSM) ile yönetiyor. GitHub yazısına göre sorun üç eksiklikten kaynaklanıyor:
  • Kapatma (hangup), bir "öldür" anahtarı gibi değil, FSM olay kuyruğuna eklenen sıradan bir olay olarak ele alınıyordu.
  • Uzak taraftan gelen olaylar için hız sınırı (rate limit) yoktu.
  • Kapatma olayının önceliği yoktu.
Araştırmacının ifadesiyle: kuyruğu doldurun, kapatma saldırganın gürültüsünün arkasında sonsuza dek bekler; böylece arama (mikrofon, belki kamera) hiç sonlandırılmaz.

3. Etkilenen ve düzeltilmiş sürümler
Açık RingRTC 2.72.0 ile (4 Eylül'de yayımlandı) giderildi. GHSA kaydına ve haberlere göre etkilenen uygulama sürümleri:
Kod:
Android : 8.27.0 öncesi iOS : 8.30.0 öncesi Desktop : 8.29.0 öncesi
Signal, çözümü, arama sonlandırma isteklerinin FSM kuyruğunda takılı kalmamasını ve bağımsız olarak algılanmasını sağlayarak uyguladı. NIST, CVE'yi NVD'ye ekledi. Vahşi doğada sömürü raporu yok.

4. Gerçek dünya riski
Saldırganın, aramayı kabul ettiğiniz bir kişi olması gerektiği için risk, rastgele herkese açık değil. Ancak hedefli gözetim senaryolarında ciddi bir gizlilik tehdidi: kurban aramayı bitirdiğini düşünürken ortam sesi dinlenmeye devam edebilir.

5. Kullanıcı önlemleri
  1. Signal'i tüm cihazlarınızda hemen güncelleyin. Android 8.27.0+, iOS 8.30.0+, Desktop 8.29.0+ hedefleyin.
  2. Arama göstergesini kontrol edin. Güncelleyemiyorsanız, kapattıktan sonra aramanın gerçekten bittiğini (gösterge, mikrofon ikonu) doğrulayın.
  3. Şüpheli kişilerden arama kabul etmeyin. Saldırı, karşı tarafın aramada olmasını gerektiriyor.
  4. Hassas görüşmelerde uygulama tamamen kapanana kadar ortam güvenliğine dikkat edin.

Sonuç
Bu açık, "kullanıcı kapattı" ile "sistem gerçekten kapattı" arasındaki farkın güvenlik açısından ne kadar kritik olabileceğini gösteriyor. Kapatma, bir olay değil, öncelikli bir kesme (interrupt) olmalıydı. Signal uygulamalarınızı güncel tutuyor 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   11-t11-signal-ringrtc-cve.png (Dosya Boyutu: 115.85 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=427]
Selamlar,

Signal, kötü niyetli bir arayanın, kullanıcı aramayı kapattıktan sonra bile ses ve video akışını açık tutmasına izin verebilen kritik bir açığı kapattı. CVE-2026-113380 (CVSS 9.3) olarak izlenen açık, Signal'in sesli/görüntülü aramalarda kullandığı açık kaynaklı RingRTC kütüphanesini etkiliyor. SecurityWeek konuyu aktardı. Bu, "kapat" düğmesinin neden her zaman garanti olmadığını gösteren öğretici bir örnek. Burada açığı ve kullanıcı önlemlerini ele alıyorum.

Konuda anlatılacaklar
  1. Açık ne yapıyor?
  2. Teknik neden: FSM kuyruğu
  3. Etkilenen ve düzeltilmiş sürümler
  4. Gerçek dünya riski
  5. Kullanıcı önlemleri

1. Açık ne yapıyor?
Normalde aramayı kapattığınızda mikrofon ve kamera kapanır. Bu açıkta uzaktaki bir katılımcı, aramanın olay kuyruğunu doldurarak kapatma işlemini sonsuza dek bekletebiliyor. Sonuç: kullanıcı aramayı bitirdiğini sanırken ses (ve muhtemelen video) akmaya devam ediyor.

2. Teknik neden
RingRTC, aramayı WebRTC tabanlı bir Sonlu Durum Makinesi (Finite State Machine, FSM) ile yönetiyor. GitHub yazısına göre sorun üç eksiklikten kaynaklanıyor:
  • Kapatma (hangup), bir "öldür" anahtarı gibi değil, FSM olay kuyruğuna eklenen sıradan bir olay olarak ele alınıyordu.
  • Uzak taraftan gelen olaylar için hız sınırı (rate limit) yoktu.
  • Kapatma olayının önceliği yoktu.
Araştırmacının ifadesiyle: kuyruğu doldurun, kapatma saldırganın gürültüsünün arkasında sonsuza dek bekler; böylece arama (mikrofon, belki kamera) hiç sonlandırılmaz.

3. Etkilenen ve düzeltilmiş sürümler
Açık RingRTC 2.72.0 ile (4 Eylül'de yayımlandı) giderildi. GHSA kaydına ve haberlere göre etkilenen uygulama sürümleri:
Kod:
Android : 8.27.0 öncesi iOS : 8.30.0 öncesi Desktop : 8.29.0 öncesi
Signal, çözümü, arama sonlandırma isteklerinin FSM kuyruğunda takılı kalmamasını ve bağımsız olarak algılanmasını sağlayarak uyguladı. NIST, CVE'yi NVD'ye ekledi. Vahşi doğada sömürü raporu yok.

4. Gerçek dünya riski
Saldırganın, aramayı kabul ettiğiniz bir kişi olması gerektiği için risk, rastgele herkese açık değil. Ancak hedefli gözetim senaryolarında ciddi bir gizlilik tehdidi: kurban aramayı bitirdiğini düşünürken ortam sesi dinlenmeye devam edebilir.

5. Kullanıcı önlemleri
  1. Signal'i tüm cihazlarınızda hemen güncelleyin. Android 8.27.0+, iOS 8.30.0+, Desktop 8.29.0+ hedefleyin.
  2. Arama göstergesini kontrol edin. Güncelleyemiyorsanız, kapattıktan sonra aramanın gerçekten bittiğini (gösterge, mikrofon ikonu) doğrulayın.
  3. Şüpheli kişilerden arama kabul etmeyin. Saldırı, karşı tarafın aramada olmasını gerektiriyor.
  4. Hassas görüşmelerde uygulama tamamen kapanana kadar ortam güvenliğine dikkat edin.

Sonuç
Bu açık, "kullanıcı kapattı" ile "sistem gerçekten kapattı" arasındaki farkın güvenlik açısından ne kadar kritik olabileceğini gösteriyor. Kapatma, bir olay değil, öncelikli bir kesme (interrupt) olmalıydı. Signal uygulamalarınızı güncel tutuyor 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   11-t11-signal-ringrtc-cve.png (Dosya Boyutu: 115.85 KB / İndirme Sayısı: 1) ]]>