<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Sosyal Mühendislik ve Farkındalık]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:38 +0000 MyBB <![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[Help Desk'ten Parola Sıfırlatmak: 2026'nın En Etkili Sıfırıncı Günü]]> https://www.turkteam.org/konu-help-desk-ten-parola-sifirlatmak-2026-nin-en-etkili-sifirinci-gunu.html Sat, 24 Oct 2026 11:32:05 +0300 KulTigin]]> https://www.turkteam.org/konu-help-desk-ten-parola-sifirlatmak-2026-nin-en-etkili-sifirinci-gunu.html [Resim: attachment.php?aid=408]
Selamlar,

Dark Reading'in 23 Ekim 2026 dosyası net söylüyor: saldırganlar artık her zaman zararlı yazılım yazmıyor; help desk'i arayıp kibarca erişim istiyor. 1Password'dan Dave Lewis bunu "2026'nın en etkili sıfırıncı günü" diye nitelendiriyor. TransUnion raporu da dolandırıcılığın çoğunun müşteri ilişkisi kurulduktan sonra gerçekleştiğini gösteriyor. Bu konu, insanları suçlamak yerine süreci nasıl sertleştireceğinize dair pratik notlar.

Konuda anlatılacaklar
  1. Saldırı neden işe yarıyor?
  2. YZ ve deepfake boyutu
  3. CRM / SaaS yan kapıları
  4. Help desk için süreç önerileri
  5. Kimlik ve veri hijyeni

1. Neden işe yarıyor?
On yıl boyunca insanlara "bağlantıya tıklama" diye eğitim verdik; saldırganlar tıklatmayı bırakıp telefonla MFA kodu veya parola sıfırlama istedi. Hız metrikleri (ortalama görüşme süresi) ajanları doğrulamayı kısaltmaya itiyor. AI ile kişiselleştirilmiş senaryo ve ses deepfake'i bu baskıyı artırıyor.

2. YZ boyutu
KnowBe4, AI marka taklitlerinde (ör. Claude adına sahte ödeme maili) Nisan'dan bu yana yüzde 228 artış izlediklerini söylüyor. Saldırganlar hem insanları hem de yanlış yapılandırılmış YZ ajanlarını hedefliyor. Sosyal mühendislik tekniği aynı; ölçek ve inandırıcılık değişti.

3. CRM yan kapıları
Lewis'in gözlemi: kimse CRM'yi "hack"lemiyor; unutulmuş bir satıcı anahtarı veya yıllar önce açılmış misafir hesabıyla giriş yapıyor. Bir ele geçirilen entegrasyon, klasik veri merkezi ihlaline göre çok daha fazla hedef demek. Tespit de zor çünkü SaaS günlükleri geleneksel altyapıdan farklı.

4. Help desk süreç önerileri
  • Parola/MFA sıfırlamada scriptli kimlik doğrulama.
  • Kayıtlardaki numaraya geri arama (callback).
  • Ayrıcalıklı veya MFA sıfırlamalarında yönetici onayı.
  • Kimlik hassas görüşmelerde ortalama süre metriklerini kaldırın veya ağırlığını düşürün.

5. Kimlik ve veri hijyeni
  1. Her OAuth uygulaması, entegrasyon, misafir/portal kullanıcısı ve API anahtarını envanterleyin.
  2. Sahipsiz olanları iptal edin; kalanları daraltın; üç ayda bir tekrarlayın.
  3. Müşteri kayıtlarında saklama süresi koyun; uykudaki hesapları silin.
  4. Üretim müşteri verisini sandbox'a kopyalamayın.
"Tutmadığınız veri çalınamaz."

Help desk'inizde parola sıfırlama için geri arama zorunlu 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   16-k01-helpdesk-guven.png (Dosya Boyutu: 113.18 KB / İndirme Sayısı: 5) ]]> [Resim: attachment.php?aid=408]
Selamlar,

Dark Reading'in 23 Ekim 2026 dosyası net söylüyor: saldırganlar artık her zaman zararlı yazılım yazmıyor; help desk'i arayıp kibarca erişim istiyor. 1Password'dan Dave Lewis bunu "2026'nın en etkili sıfırıncı günü" diye nitelendiriyor. TransUnion raporu da dolandırıcılığın çoğunun müşteri ilişkisi kurulduktan sonra gerçekleştiğini gösteriyor. Bu konu, insanları suçlamak yerine süreci nasıl sertleştireceğinize dair pratik notlar.

Konuda anlatılacaklar
  1. Saldırı neden işe yarıyor?
  2. YZ ve deepfake boyutu
  3. CRM / SaaS yan kapıları
  4. Help desk için süreç önerileri
  5. Kimlik ve veri hijyeni

1. Neden işe yarıyor?
On yıl boyunca insanlara "bağlantıya tıklama" diye eğitim verdik; saldırganlar tıklatmayı bırakıp telefonla MFA kodu veya parola sıfırlama istedi. Hız metrikleri (ortalama görüşme süresi) ajanları doğrulamayı kısaltmaya itiyor. AI ile kişiselleştirilmiş senaryo ve ses deepfake'i bu baskıyı artırıyor.

2. YZ boyutu
KnowBe4, AI marka taklitlerinde (ör. Claude adına sahte ödeme maili) Nisan'dan bu yana yüzde 228 artış izlediklerini söylüyor. Saldırganlar hem insanları hem de yanlış yapılandırılmış YZ ajanlarını hedefliyor. Sosyal mühendislik tekniği aynı; ölçek ve inandırıcılık değişti.

3. CRM yan kapıları
Lewis'in gözlemi: kimse CRM'yi "hack"lemiyor; unutulmuş bir satıcı anahtarı veya yıllar önce açılmış misafir hesabıyla giriş yapıyor. Bir ele geçirilen entegrasyon, klasik veri merkezi ihlaline göre çok daha fazla hedef demek. Tespit de zor çünkü SaaS günlükleri geleneksel altyapıdan farklı.

4. Help desk süreç önerileri
  • Parola/MFA sıfırlamada scriptli kimlik doğrulama.
  • Kayıtlardaki numaraya geri arama (callback).
  • Ayrıcalıklı veya MFA sıfırlamalarında yönetici onayı.
  • Kimlik hassas görüşmelerde ortalama süre metriklerini kaldırın veya ağırlığını düşürün.

5. Kimlik ve veri hijyeni
  1. Her OAuth uygulaması, entegrasyon, misafir/portal kullanıcısı ve API anahtarını envanterleyin.
  2. Sahipsiz olanları iptal edin; kalanları daraltın; üç ayda bir tekrarlayın.
  3. Müşteri kayıtlarında saklama süresi koyun; uykudaki hesapları silin.
  4. Üretim müşteri verisini sandbox'a kopyalamayın.
"Tutmadığınız veri çalınamaz."

Help desk'inizde parola sıfırlama için geri arama zorunlu 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   16-k01-helpdesk-guven.png (Dosya Boyutu: 113.18 KB / İndirme Sayısı: 5) ]]> <![CDATA[ClickFix Tuzağı: Chrome Enhanced Protection Artık Tehlikeli Komutları Uyarıyor]]> https://www.turkteam.org/konu-clickfix-tuzagi-chrome-enhanced-protection-artik-tehlikeli-komutlari-uyariyor.html Thu, 22 Oct 2026 11:25:41 +0300 Tonyukuk]]> https://www.turkteam.org/konu-clickfix-tuzagi-chrome-enhanced-protection-artik-tehlikeli-komutlari-uyariyor.html [Resim: attachment.php?aid=348]
Selamlar,

"Sayfanızda bir hata var, şu komutu kopyalayıp Çalıştır'a yapıştırın" diye başlayan sahte düzeltme sayfalarını duymuşsunuzdur. Bu yöntemin adı ClickFix. Google, Chrome'un Enhanced Protection (Gelişmiş Koruma) modunu bu tuzakları yakalayacak şekilde güncelledi: şüpheli komut panoya kopyalandığında Safe Browsing'e gönderiliyor ve tehlikeli bulunursa kullanıcı uyarılıyor.

Konuda anlatılacaklar
  1. ClickFix nedir, neden klasik indirme korumalarını aşıyor?
  2. Chrome'un yeni uyarısı nasıl çalışıyor?
  3. Enhanced Protection'ın diğer yenilikleri
  4. Kullanıcı ve kurum için pratik kurallar

ClickFix nedir?
Help Net Security'nin aktardığına göre ClickFix siteleri, sahte bir sorunu "düzeltmek" için kullanıcıyı kötü amaçlı bir komutu kopyalayıp kendi bilgisayarında çalıştırmaya ikna ediyor. Panoya kopyalanan komut, sayfada gösterilen metinden farklı olabiliyor. Komutlar çoğu zaman işletim sisteminde zaten bulunan meşru araçları (LOLBins) çağırıyor: PowerShell, cmd.exe gibi. İndirme işlemi tarayıcıdan terminal'e taşındığı için Chrome ve Safe Browsing'in indirme korumaları baypas ediliyor.

Chrome'un yeni uyarısı nasıl çalışıyor?
Enhanced Protection kullanıcıları şüpheli bir komutu kopyaladığında Chrome, panodaki yükten kişisel tanımlayıcı bilgileri (PII) çıkarıp Safe Browsing'e gönderiyor. Komut tehlikeli bulunursa bir uyarı görünüyor. Bu, "dosya indirildi mi?" değil, "kullanıcı kendi makinesinde çalıştırılacak bir komutu panoya aldı mı?" sorusuna yanıt veren bir katman.

Önemli sınır: Bu özellik Enhanced Protection açıkken geçerli. Standart koruma kullananlar bu yeni uyarıyı görmeyebilir. Google'a göre Enhanced Protection kullanıcıları, phishing ve sosyal mühendislik gibi tehditlere karşı Standart koruma kullanıcılarına kıyasla ortalama on kat daha az risk altında (şirketin iki mod arasında gösterilen güvenlik uyarısı sayısına dayanan karşılaştırması).

Diğer Enhanced Protection yenilikleri
  • Şüpheli site uyarıları: Bilinen kötü sitelerle ilişkili aldatıcı kalıplar gösteren sayfalarda, duruma özel ikon/renk/metin ile uyarılıyor.
  • Tehlikeli site uyarıları: Yüksek riskli, bilinen kötü sayfalarda tam sayfa kırmızı ekran devam ediyor.
  • Gemini destekli scam tespiti: Cihaz üzeri modelden sunucu tarafı modele geçildi; sahte antivirüs ve tarayıcı güncelleme dolandırıcılıkları da teknik destek dolandırıcılıklarına eklendi. Sayfa metni yalnızca yüksek güvenli scam göstergeleri olduğunda analiz için gönderiliyor; Google metnin loglanmadığını, saklanmadığını ve model eğitiminde kullanılmadığını söylüyor.

Kullanıcı için tek kural
Hiçbir meşru web sitesi sizden Win+R açmanızı, Terminal veya PowerShell'e bir komut yapıştırmanızı istemez. "CAPTCHA doğrulaması", "tarayıcı güncellemesi", "bağlantıyı düzelt" bahaneleriyle gelen yapıştır-çalıştır adımlarının tamamını reddedin.

Kurum için pratik adımlar
  • E-posta ve ödeme işleyen personelde Chrome Enhanced Safe Browsing'i politika ile zorunlu kılın.
  • Standart kullanıcı hesaplarında Çalıştır iletişim kutusunu (Win+R) mümkünse kısıtlayın.
  • PowerShell Script Block Logging, Module Logging ve Transcription'ı açın; "kullanıcı panodan çalıştırdı" senaryolarını EDR'da ayrı bir kural sınıfı yapın.
  • Farkındalık eğitiminde ClickFix'i ayrı bir senaryo olarak gösterin; klasik ek dosya / link eğitimine ekleyin.

Kod:
# Windows (kendi labınız) - PowerShell Script Block Logging kontrolu Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -ErrorAction SilentlyContinue # Chrome politikasi (kurumsal): SafeBrowsingProtectionLevel = 2 (Enhanced) # https://chromeenterprise.google/policies/#SafeBrowsingProtectionLevel

ClickFix tarzı bir sayfa gördünüz mü? Win+R / Terminal'e yapıştır denince ne yaptı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   10-t10-clickfix-chrome.png (Dosya Boyutu: 117.23 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=348]
Selamlar,

"Sayfanızda bir hata var, şu komutu kopyalayıp Çalıştır'a yapıştırın" diye başlayan sahte düzeltme sayfalarını duymuşsunuzdur. Bu yöntemin adı ClickFix. Google, Chrome'un Enhanced Protection (Gelişmiş Koruma) modunu bu tuzakları yakalayacak şekilde güncelledi: şüpheli komut panoya kopyalandığında Safe Browsing'e gönderiliyor ve tehlikeli bulunursa kullanıcı uyarılıyor.

Konuda anlatılacaklar
  1. ClickFix nedir, neden klasik indirme korumalarını aşıyor?
  2. Chrome'un yeni uyarısı nasıl çalışıyor?
  3. Enhanced Protection'ın diğer yenilikleri
  4. Kullanıcı ve kurum için pratik kurallar

ClickFix nedir?
Help Net Security'nin aktardığına göre ClickFix siteleri, sahte bir sorunu "düzeltmek" için kullanıcıyı kötü amaçlı bir komutu kopyalayıp kendi bilgisayarında çalıştırmaya ikna ediyor. Panoya kopyalanan komut, sayfada gösterilen metinden farklı olabiliyor. Komutlar çoğu zaman işletim sisteminde zaten bulunan meşru araçları (LOLBins) çağırıyor: PowerShell, cmd.exe gibi. İndirme işlemi tarayıcıdan terminal'e taşındığı için Chrome ve Safe Browsing'in indirme korumaları baypas ediliyor.

Chrome'un yeni uyarısı nasıl çalışıyor?
Enhanced Protection kullanıcıları şüpheli bir komutu kopyaladığında Chrome, panodaki yükten kişisel tanımlayıcı bilgileri (PII) çıkarıp Safe Browsing'e gönderiyor. Komut tehlikeli bulunursa bir uyarı görünüyor. Bu, "dosya indirildi mi?" değil, "kullanıcı kendi makinesinde çalıştırılacak bir komutu panoya aldı mı?" sorusuna yanıt veren bir katman.

Önemli sınır: Bu özellik Enhanced Protection açıkken geçerli. Standart koruma kullananlar bu yeni uyarıyı görmeyebilir. Google'a göre Enhanced Protection kullanıcıları, phishing ve sosyal mühendislik gibi tehditlere karşı Standart koruma kullanıcılarına kıyasla ortalama on kat daha az risk altında (şirketin iki mod arasında gösterilen güvenlik uyarısı sayısına dayanan karşılaştırması).

Diğer Enhanced Protection yenilikleri
  • Şüpheli site uyarıları: Bilinen kötü sitelerle ilişkili aldatıcı kalıplar gösteren sayfalarda, duruma özel ikon/renk/metin ile uyarılıyor.
  • Tehlikeli site uyarıları: Yüksek riskli, bilinen kötü sayfalarda tam sayfa kırmızı ekran devam ediyor.
  • Gemini destekli scam tespiti: Cihaz üzeri modelden sunucu tarafı modele geçildi; sahte antivirüs ve tarayıcı güncelleme dolandırıcılıkları da teknik destek dolandırıcılıklarına eklendi. Sayfa metni yalnızca yüksek güvenli scam göstergeleri olduğunda analiz için gönderiliyor; Google metnin loglanmadığını, saklanmadığını ve model eğitiminde kullanılmadığını söylüyor.

Kullanıcı için tek kural
Hiçbir meşru web sitesi sizden Win+R açmanızı, Terminal veya PowerShell'e bir komut yapıştırmanızı istemez. "CAPTCHA doğrulaması", "tarayıcı güncellemesi", "bağlantıyı düzelt" bahaneleriyle gelen yapıştır-çalıştır adımlarının tamamını reddedin.

Kurum için pratik adımlar
  • E-posta ve ödeme işleyen personelde Chrome Enhanced Safe Browsing'i politika ile zorunlu kılın.
  • Standart kullanıcı hesaplarında Çalıştır iletişim kutusunu (Win+R) mümkünse kısıtlayın.
  • PowerShell Script Block Logging, Module Logging ve Transcription'ı açın; "kullanıcı panodan çalıştırdı" senaryolarını EDR'da ayrı bir kural sınıfı yapın.
  • Farkındalık eğitiminde ClickFix'i ayrı bir senaryo olarak gösterin; klasik ek dosya / link eğitimine ekleyin.

Kod:
# Windows (kendi labınız) - PowerShell Script Block Logging kontrolu Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -ErrorAction SilentlyContinue # Chrome politikasi (kurumsal): SafeBrowsingProtectionLevel = 2 (Enhanced) # https://chromeenterprise.google/policies/#SafeBrowsingProtectionLevel

ClickFix tarzı bir sayfa gördünüz mü? Win+R / Terminal'e yapıştır denince ne yaptı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   10-t10-clickfix-chrome.png (Dosya Boyutu: 117.23 KB / İndirme Sayısı: 6) ]]> <![CDATA[Sahte Teknik Destek Dolandırıcılığı: Ekran Bağlantısını Kesin ve Sonrası]]> https://www.turkteam.org/konu-sahte-teknik-destek-dolandiriciligi-ekran-baglantisini-kesin-ve-sonrasi.html Wed, 21 Oct 2026 09:35:10 +0300 Tonyukuk]]> https://www.turkteam.org/konu-sahte-teknik-destek-dolandiriciligi-ekran-baglantisini-kesin-ve-sonrasi.html [Resim: attachment.php?aid=314]
Selam,

"Microsoft / Windows Destek hattıyız, bilgisayarınızda virüs var" diye gelen aramalar ve ekran paylaşımı istekleri klasik dolandırıcılık. Bu yazıda ne yapmanızı, bağlantıyı nasıl keseceğinizi ve sonrasında hangi kontrolleri yapacağınızı anlatıyorum.

Nasıl işler?
  • Soğuk arama veya korkutucu pop-up ("ara +1-...")
  • AnyDesk / TeamViewer / Quick Assist ile tam kontrol
  • "Virüs temizliği" adı altında uzak erişim hesabı açma, kripto / kart parası, sahte fatura
Microsoft, Apple, Google sizi arayıp virüs uyarısı yapmaz.

O anda yapılacaklar
  1. Ekran paylaşımını hemen sonlandırın
  2. İnternet bağlantısını kesin (kablo / Wi-Fi)
  3. Telefonu kapatın; geri aramayın
  4. Başka bir temiz cihazdan parola yöneticisi ile kritik hesap oturumlarını düşürün

[Resim: attachment.php?aid=315]

Sonrası kontrol listesi
  • Yeni kullanıcı hesabı / RDP / AnyDesk kalmış mı?
  • Başlangıç programları ve zamanlanmış görevler
  • Bilinmeyen tarayıcı eklentileri
  • Banka / e-posta / parola yöneticisi parolalarını temiz cihazdan değiştirin
  • Şüpheli banka hareketi varsa bankayı arayın (resmi numaradan)
Windows'ta hızlı bakış:
Kod:
Get-LocalUser Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'} | Select TaskName,TaskPath

Yaşlı / aile için önlem
  • Pop-up'ta yazan numarayı aramama kuralı
  • Ekran paylaşım uygulamalarını varsayılan kurmayın
  • Ayrı sınırlı kullanıcı hesabı
  • Şüphede ailedeki "teknoloji kişisini" arama kartı

Kaynaklar
  • Microsoft güvenlik blogları: tech support scam
  • BTK / yerel siber suç bildirim kanalları
  • Tüketici dernekleri uyarıları

Yakın çevrenizde bu dolandırıcılığa denk gelen oldu mu? Hangi uygulama istendi?

Pop-up kilidi
Tam ekran "virüs" uyarısı bazen tarayıcıyı kilitlemiş gibi gösterir. Ctrl+Alt+Del / başka tarayıcı / güvenli mod. Bilgisayarı formatlatmaya ikna eden aramalar da aynı dolandırıcılık ailesindendir.

Bildirim
Ödeme yaptıysanız banka + yerel siber suç birimleri. Ekran görüntüsü, arayan numara, verilen IBAN/BTC adresi kanıttır. Utanmayın; bildirmek başkalarını korur.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n35-cd70b5.png (Dosya Boyutu: 66.1 KB / İndirme Sayısı: 8)

.png   n35-inner.png (Dosya Boyutu: 19.39 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=314]
Selam,

"Microsoft / Windows Destek hattıyız, bilgisayarınızda virüs var" diye gelen aramalar ve ekran paylaşımı istekleri klasik dolandırıcılık. Bu yazıda ne yapmanızı, bağlantıyı nasıl keseceğinizi ve sonrasında hangi kontrolleri yapacağınızı anlatıyorum.

Nasıl işler?
  • Soğuk arama veya korkutucu pop-up ("ara +1-...")
  • AnyDesk / TeamViewer / Quick Assist ile tam kontrol
  • "Virüs temizliği" adı altında uzak erişim hesabı açma, kripto / kart parası, sahte fatura
Microsoft, Apple, Google sizi arayıp virüs uyarısı yapmaz.

O anda yapılacaklar
  1. Ekran paylaşımını hemen sonlandırın
  2. İnternet bağlantısını kesin (kablo / Wi-Fi)
  3. Telefonu kapatın; geri aramayın
  4. Başka bir temiz cihazdan parola yöneticisi ile kritik hesap oturumlarını düşürün

[Resim: attachment.php?aid=315]

Sonrası kontrol listesi
  • Yeni kullanıcı hesabı / RDP / AnyDesk kalmış mı?
  • Başlangıç programları ve zamanlanmış görevler
  • Bilinmeyen tarayıcı eklentileri
  • Banka / e-posta / parola yöneticisi parolalarını temiz cihazdan değiştirin
  • Şüpheli banka hareketi varsa bankayı arayın (resmi numaradan)
Windows'ta hızlı bakış:
Kod:
Get-LocalUser Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'} | Select TaskName,TaskPath

Yaşlı / aile için önlem
  • Pop-up'ta yazan numarayı aramama kuralı
  • Ekran paylaşım uygulamalarını varsayılan kurmayın
  • Ayrı sınırlı kullanıcı hesabı
  • Şüphede ailedeki "teknoloji kişisini" arama kartı

Kaynaklar
  • Microsoft güvenlik blogları: tech support scam
  • BTK / yerel siber suç bildirim kanalları
  • Tüketici dernekleri uyarıları

Yakın çevrenizde bu dolandırıcılığa denk gelen oldu mu? Hangi uygulama istendi?

Pop-up kilidi
Tam ekran "virüs" uyarısı bazen tarayıcıyı kilitlemiş gibi gösterir. Ctrl+Alt+Del / başka tarayıcı / güvenli mod. Bilgisayarı formatlatmaya ikna eden aramalar da aynı dolandırıcılık ailesindendir.

Bildirim
Ödeme yaptıysanız banka + yerel siber suç birimleri. Ekran görüntüsü, arayan numara, verilen IBAN/BTC adresi kanıttır. Utanmayın; bildirmek başkalarını korur.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n35-cd70b5.png (Dosya Boyutu: 66.1 KB / İndirme Sayısı: 8)

.png   n35-inner.png (Dosya Boyutu: 19.39 KB / İndirme Sayısı: 7) ]]> <![CDATA[Sosyal Mühendislik ve Phishing Nasıl Tanınır? Farkındalık ve Savunma Rehberi]]> https://www.turkteam.org/konu-sosyal-muhendislik-ve-phishing-nasil-taninir-farkindalik-ve-savunma-rehberi-104.html Sun, 18 Oct 2026 07:00:16 +0300 BilgeKagan]]> https://www.turkteam.org/konu-sosyal-muhendislik-ve-phishing-nasil-taninir-farkindalik-ve-savunma-rehberi-104.html [Resim: attachment.php?aid=137][/center]

Selam TurkTeam, BlueTornado ile.

Teknik kontroller ne kadar iyi olursa olsun, insan faktörü hâlâ en geniş saldırı yüzeylerinden biridir. Bu konu saldırı "nasıl yapılır" diye değil; nasıl tanınır ve nasıl savunulur diye yazıldı. Phishing, vishing, smishing ve iş e-postası dolandırıcılığı (BEC) belirtilerini, güvenli doğrulama alışkanlıklarını ve kurumsal kontrolleri ele alıyoruz.

Konuda Anlatılacaklar
  1. Sosyal mühendislik nedir?
  2. Phishing türleri (e-posta, SMS, ses, QR, BEC)
  3. Tanıma ipuçları ve güvenli kontrol listesi
  4. Lab: kendi test e-postanızı analiz etme
  5. Kurumsal ve bireysel savunma
  6. İleri seviye: MFA yorgunluğu, evilginx tarzı reverse proxy farkındalığı (savunma)
  7. Kaynakça ve yasal uyarı

1) Sosyal Mühendislik Nedir?
Sosyal mühendislik, insanları manipüle ederek gizli bilgiyi ifşa ettirme, zararlı eylem yaptırma veya güvenlik kontrollerini atlatma sanatıdır. Teknik zafiyet yerine güven, acele, korku, hiyerarşi ve yardımseverlik kullanılır.
  • Phishing: Sahte iletişimle kimlik bilgisi veya zararlı dosya/link
  • Spear phishing: Belirli kişi/kuruma özel hazırlanmış
  • Whaling: Üst düzey yönetici hedefi
  • Vishing: Telefon
  • Smishing: SMS
  • Pretexting: Sahte senaryo (IT destek, kargo, banka)
  • BEC: Sahte CEO/tedarikçi ile havale talimatı

Alıntı:İyi bir oltalama maili "kötü Türkçe ve kırmızı bayraklarla dolu" olmak zorunda değildir. Kurumsal dile benzeyen, kişiselleştirilmiş ve acil görünen içerikler daha tehlikelidir.

2) Phishing Nasıl Tanınır?

Gönderen ve domain:
Kod:
# Gözle kontrol Görünen ad: "IT Destek" <it-destek@turkteam-guvenlik.com> # Gerçek domaininiz turkteam.org ise bu şüphelidir # Homoglyph: rn -> m, IDN punycode

Linkler:
  • Üzerine gelince (hover) görünen URL ile metin farklı mı?
  • Kısaltılmış linkler (bit.ly vb.) bilinmeyen gönderende riskli
  • Kod:
    https://turkteam.org.güvenlik-kontrolü.evil.example
    gibi alt alan adı oyunları

İçerik psikolojisi:
  • Aşırı aciliyet: "Hesabınız 1 saat içinde kapanacak"
  • Korku: "Yasal işlem başlatılacak"
  • Ödül: "Kargo sizden ücret bekliyor / ikramiye"
  • Otorite: "Yönetim Kurulu gereği hemen onay"

Ekler:
Kod:
.html
, çift uzantı
Kod:
fatura.pdf.exe
, makro'lu Office, ISO/IMG. Beklemediğiniz bir fatura eki klasik vektördür.

[center][/center]

3) Güvenli Doğrulama Alışkanlıkları
  • Maildeki linke tıklamak yerine tarayıcıya kurumu sizin bildiğiniz adresten yazın
  • Para/havale taleplerini ikinci bir kanaldan (bilinen telefon) doğrulayın
  • IT'nin parolanızı mail ile istemeyeceğini bilin; SSO sayfasına mail içinden gitmeyin
  • Şüpheli maili "bildir" ile SOC/IT'ye iletin; silmeden önce kurum prosedürünü izleyin
  • Kişisel hesaplarda da aynı şüphecilik

Kod:
# Bireysel hızlı kontrol listesi [ ] Gönderen domain gerçek mi? [ ] Ben bu maili bekliyor muydum? [ ] Aciliyet baskısı var mı? [ ] Link hover / ek şüpheli mi? [ ] İkinci kanal doğrulaması yaptım mı?

4) Uygulamalı: Zararsız Analiz Labı
Kendi kendinize gönderdiğiniz veya kurumsal phishing simülasyonundan gelen bir örneği (güvenli ortamda) inceleyin. Üretimde şüpheli ekleri açmayın.

Kod:
# E-posta kaynak başlıklarını görmek (Gmail: Show original) # İncelenecek başlıklar: From: Return-Path: Reply-To: Received: (zincir) Authentication-Results: (SPF/DKIM/DMARC)

Kod:
# Örnek Authentication-Results satırı (kavramsal) spf=pass dkım=pass dmarc=pass # Hepsi fail ise yüksek şüphe; hepsi pass olsa bile içerik sahte olabilir (hesap ele geçirme)

[center][/center]

URL'yi açmadan önce:
Kod:
# VirusTotal / urlscan.io gibi servislere URL yapıştırın (kurum politikasına uygun) # Kendi sandbox'ınız yoksa ekleri çalıştırmayın

5) Kurumsal Savunma Kontrolleri
  • SPF, DKIM, DMARC yayınlayın; DMARC politikasını kademeli sıkılaştırın
  • Gelen kutusu güvenliği: link rewriting, ek sandbox (imkân varsa)
  • MFA zorunlu; mümkünse phishing-resistant (FIDO2 / passkey)
  • BEC için mali süreç: çift onay, bilinen tedarikçi hesap listesi
  • Düzenli farkındalık eğitimi + ölçülebilir simülasyon (cezalandırıcı değil öğretici)
  • SOC playbook: phishing bildirimi -> URL/hash -> IOC -> kullanıcı etkisi

Kod:
# DMARC kayıt örneği (DNS TXT, kavramsal) v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@sizin-domaininiz.com; pct=100

Kod:
# SPF örneği (aşırı geniş +all kullanmayın) v=spf1 include:_spf.google.com -all

6) İleri Seviye Farkındalık (Savunma)
MFA yorgunluğu (fatigue): Saldırgan parolayı bir şekilde elde edip telefonunuza peş peşe MFA bildirimi yağdırabilir. Alışkanlık: beklemediğiniz onayları reddedin; parolayı değiştirin; IT'ye bildirin.

Proxy / Adversary-in-the-middle phishing: Sahte sayfa, gerçek login ile kurban arasında aracılık ederek oturum çerezini/token'ı yakalayabilir. Klasik SMS OTP bu senaryoda yetersiz kalabilir. Passkey/FIDO2 ve Conditional Access (cihaz uyumu, imkânsız gezinti) savunmada öne çıkar.

QR phishing (quishing): Afiş, PDF veya mail içindeki QR bilinmeyen yere götürebilir. Kurumsal cihazda rastgele QR okutmayın.

[center][/center]

Raporlama dili (kullanıcıdan SOC'a):
Kod:
Konu: Şüpheli e-posta bildirimi Gönderen: ... Zaman: 2026-10-17 14:10 Europe/Istanbul Tıkladım mı?: Hayır Ek açtım mı?: Hayır Ekran görüntüsü / .eml ekte

7) Sonuç
Sosyal mühendislik teknik bir açık değil, insan ve süreç açığıdır. Tanıma refleksleri, ikinci kanal doğrulama, DMARC/MFA/passkey ve iyi bir bildirim kültürü en etkili savunma paketidir. Merak ettiğiniz teknik detayları izinsiz sistemlerde denemeyin; kurumsal simülasyon programlarına katılın.



Ek: Ev ve Küçük İşletme İçin 10 Dakikalık Sertleştirme
Büyük bir SOC'unuz olmasa bile uygulanabilir adımlar:
  • E-posta hesabında MFA açın (mümkünse uygulama veya güvenlik anahtarı; SMS son çare)
  • Tarayıcıda şüpheli eklentileri kaldırın; otomatik indirme klasörünü izleyin
  • Kargo/banka SMS'lerindeki linklere değil, resmi uygulamaya gidin
  • İş bilgisayarında yönetici hesabıyla gezmeyin
  • Yedek alın; ransomware'li oltalama ekleri hâlâ yaygındır
  • Aile bireylerine "parola isteme" ve "acil havale" senaryolarını anlatın

Kod:
# Kişisel alan adı kullanıyorsanız (ör. küçük işletme) # DNS'te SPF + DKIM + DMARC'ı hosting panelinden etkinleştirin # DMARC raporlarını ilk ay "p=none" ile izleyip sonra quarantine/reject'e geçin

[center][/center]

Şüpheli bir mesaj aldığınızda duygusal tepkiyi (korku/acele) bilinçli olarak yavaşlatmak, teknik bilgiden önce gelen en ucuz kontroldür. "Bu mail beni ne hissettiriyor?" sorusu bile birçok oltalamayı boşa çıkarır.

Kaynakça
Yasal Uyarı
Bu içerik farkındalık ve savunma eğitimidir. Phishing altyapısı kurmak, başkalarına oltalama yapmak veya izinsiz kimlik bilgisi toplamak suçtur. TCK 243-245 ve ilgili dolandırıcılık maddeleri kapsamında ağır yaptırımlar uygulanabilir. Yalnızca yetkili simülasyon ve kendi labınızda çalışın.

.png   000-team-10-team-94f246.png (Dosya Boyutu: 69.19 KB / İndirme Sayısı: 5) ]]> [Resim: attachment.php?aid=137][/center]

Selam TurkTeam, BlueTornado ile.

Teknik kontroller ne kadar iyi olursa olsun, insan faktörü hâlâ en geniş saldırı yüzeylerinden biridir. Bu konu saldırı "nasıl yapılır" diye değil; nasıl tanınır ve nasıl savunulur diye yazıldı. Phishing, vishing, smishing ve iş e-postası dolandırıcılığı (BEC) belirtilerini, güvenli doğrulama alışkanlıklarını ve kurumsal kontrolleri ele alıyoruz.

Konuda Anlatılacaklar
  1. Sosyal mühendislik nedir?
  2. Phishing türleri (e-posta, SMS, ses, QR, BEC)
  3. Tanıma ipuçları ve güvenli kontrol listesi
  4. Lab: kendi test e-postanızı analiz etme
  5. Kurumsal ve bireysel savunma
  6. İleri seviye: MFA yorgunluğu, evilginx tarzı reverse proxy farkındalığı (savunma)
  7. Kaynakça ve yasal uyarı

1) Sosyal Mühendislik Nedir?
Sosyal mühendislik, insanları manipüle ederek gizli bilgiyi ifşa ettirme, zararlı eylem yaptırma veya güvenlik kontrollerini atlatma sanatıdır. Teknik zafiyet yerine güven, acele, korku, hiyerarşi ve yardımseverlik kullanılır.
  • Phishing: Sahte iletişimle kimlik bilgisi veya zararlı dosya/link
  • Spear phishing: Belirli kişi/kuruma özel hazırlanmış
  • Whaling: Üst düzey yönetici hedefi
  • Vishing: Telefon
  • Smishing: SMS
  • Pretexting: Sahte senaryo (IT destek, kargo, banka)
  • BEC: Sahte CEO/tedarikçi ile havale talimatı

Alıntı:İyi bir oltalama maili "kötü Türkçe ve kırmızı bayraklarla dolu" olmak zorunda değildir. Kurumsal dile benzeyen, kişiselleştirilmiş ve acil görünen içerikler daha tehlikelidir.

2) Phishing Nasıl Tanınır?

Gönderen ve domain:
Kod:
# Gözle kontrol Görünen ad: "IT Destek" <it-destek@turkteam-guvenlik.com> # Gerçek domaininiz turkteam.org ise bu şüphelidir # Homoglyph: rn -> m, IDN punycode

Linkler:
  • Üzerine gelince (hover) görünen URL ile metin farklı mı?
  • Kısaltılmış linkler (bit.ly vb.) bilinmeyen gönderende riskli
  • Kod:
    https://turkteam.org.güvenlik-kontrolü.evil.example
    gibi alt alan adı oyunları

İçerik psikolojisi:
  • Aşırı aciliyet: "Hesabınız 1 saat içinde kapanacak"
  • Korku: "Yasal işlem başlatılacak"
  • Ödül: "Kargo sizden ücret bekliyor / ikramiye"
  • Otorite: "Yönetim Kurulu gereği hemen onay"

Ekler:
Kod:
.html
, çift uzantı
Kod:
fatura.pdf.exe
, makro'lu Office, ISO/IMG. Beklemediğiniz bir fatura eki klasik vektördür.

[center][/center]

3) Güvenli Doğrulama Alışkanlıkları
  • Maildeki linke tıklamak yerine tarayıcıya kurumu sizin bildiğiniz adresten yazın
  • Para/havale taleplerini ikinci bir kanaldan (bilinen telefon) doğrulayın
  • IT'nin parolanızı mail ile istemeyeceğini bilin; SSO sayfasına mail içinden gitmeyin
  • Şüpheli maili "bildir" ile SOC/IT'ye iletin; silmeden önce kurum prosedürünü izleyin
  • Kişisel hesaplarda da aynı şüphecilik

Kod:
# Bireysel hızlı kontrol listesi [ ] Gönderen domain gerçek mi? [ ] Ben bu maili bekliyor muydum? [ ] Aciliyet baskısı var mı? [ ] Link hover / ek şüpheli mi? [ ] İkinci kanal doğrulaması yaptım mı?

4) Uygulamalı: Zararsız Analiz Labı
Kendi kendinize gönderdiğiniz veya kurumsal phishing simülasyonundan gelen bir örneği (güvenli ortamda) inceleyin. Üretimde şüpheli ekleri açmayın.

Kod:
# E-posta kaynak başlıklarını görmek (Gmail: Show original) # İncelenecek başlıklar: From: Return-Path: Reply-To: Received: (zincir) Authentication-Results: (SPF/DKIM/DMARC)

Kod:
# Örnek Authentication-Results satırı (kavramsal) spf=pass dkım=pass dmarc=pass # Hepsi fail ise yüksek şüphe; hepsi pass olsa bile içerik sahte olabilir (hesap ele geçirme)

[center][/center]

URL'yi açmadan önce:
Kod:
# VirusTotal / urlscan.io gibi servislere URL yapıştırın (kurum politikasına uygun) # Kendi sandbox'ınız yoksa ekleri çalıştırmayın

5) Kurumsal Savunma Kontrolleri
  • SPF, DKIM, DMARC yayınlayın; DMARC politikasını kademeli sıkılaştırın
  • Gelen kutusu güvenliği: link rewriting, ek sandbox (imkân varsa)
  • MFA zorunlu; mümkünse phishing-resistant (FIDO2 / passkey)
  • BEC için mali süreç: çift onay, bilinen tedarikçi hesap listesi
  • Düzenli farkındalık eğitimi + ölçülebilir simülasyon (cezalandırıcı değil öğretici)
  • SOC playbook: phishing bildirimi -> URL/hash -> IOC -> kullanıcı etkisi

Kod:
# DMARC kayıt örneği (DNS TXT, kavramsal) v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@sizin-domaininiz.com; pct=100

Kod:
# SPF örneği (aşırı geniş +all kullanmayın) v=spf1 include:_spf.google.com -all

6) İleri Seviye Farkındalık (Savunma)
MFA yorgunluğu (fatigue): Saldırgan parolayı bir şekilde elde edip telefonunuza peş peşe MFA bildirimi yağdırabilir. Alışkanlık: beklemediğiniz onayları reddedin; parolayı değiştirin; IT'ye bildirin.

Proxy / Adversary-in-the-middle phishing: Sahte sayfa, gerçek login ile kurban arasında aracılık ederek oturum çerezini/token'ı yakalayabilir. Klasik SMS OTP bu senaryoda yetersiz kalabilir. Passkey/FIDO2 ve Conditional Access (cihaz uyumu, imkânsız gezinti) savunmada öne çıkar.

QR phishing (quishing): Afiş, PDF veya mail içindeki QR bilinmeyen yere götürebilir. Kurumsal cihazda rastgele QR okutmayın.

[center][/center]

Raporlama dili (kullanıcıdan SOC'a):
Kod:
Konu: Şüpheli e-posta bildirimi Gönderen: ... Zaman: 2026-10-17 14:10 Europe/Istanbul Tıkladım mı?: Hayır Ek açtım mı?: Hayır Ekran görüntüsü / .eml ekte

7) Sonuç
Sosyal mühendislik teknik bir açık değil, insan ve süreç açığıdır. Tanıma refleksleri, ikinci kanal doğrulama, DMARC/MFA/passkey ve iyi bir bildirim kültürü en etkili savunma paketidir. Merak ettiğiniz teknik detayları izinsiz sistemlerde denemeyin; kurumsal simülasyon programlarına katılın.



Ek: Ev ve Küçük İşletme İçin 10 Dakikalık Sertleştirme
Büyük bir SOC'unuz olmasa bile uygulanabilir adımlar:
  • E-posta hesabında MFA açın (mümkünse uygulama veya güvenlik anahtarı; SMS son çare)
  • Tarayıcıda şüpheli eklentileri kaldırın; otomatik indirme klasörünü izleyin
  • Kargo/banka SMS'lerindeki linklere değil, resmi uygulamaya gidin
  • İş bilgisayarında yönetici hesabıyla gezmeyin
  • Yedek alın; ransomware'li oltalama ekleri hâlâ yaygındır
  • Aile bireylerine "parola isteme" ve "acil havale" senaryolarını anlatın

Kod:
# Kişisel alan adı kullanıyorsanız (ör. küçük işletme) # DNS'te SPF + DKIM + DMARC'ı hosting panelinden etkinleştirin # DMARC raporlarını ilk ay "p=none" ile izleyip sonra quarantine/reject'e geçin

[center][/center]

Şüpheli bir mesaj aldığınızda duygusal tepkiyi (korku/acele) bilinçli olarak yavaşlatmak, teknik bilgiden önce gelen en ucuz kontroldür. "Bu mail beni ne hissettiriyor?" sorusu bile birçok oltalamayı boşa çıkarır.

Kaynakça
Yasal Uyarı
Bu içerik farkındalık ve savunma eğitimidir. Phishing altyapısı kurmak, başkalarına oltalama yapmak veya izinsiz kimlik bilgisi toplamak suçtur. TCK 243-245 ve ilgili dolandırıcılık maddeleri kapsamında ağır yaptırımlar uygulanabilir. Yalnızca yetkili simülasyon ve kendi labınızda çalışın.

.png   000-team-10-team-94f246.png (Dosya Boyutu: 69.19 KB / İndirme Sayısı: 5) ]]> <![CDATA[Sosyal Mühendislik ve Phishing Nasıl Tanınır? Farkındalık ve Savunma Rehberi]]> https://www.turkteam.org/konu-sosyal-muhendislik-ve-phishing-nasil-taninir-farkindalik-ve-savunma-rehberi.html Sun, 18 Oct 2026 04:35:19 +0300 BilgeKagan]]> https://www.turkteam.org/konu-sosyal-muhendislik-ve-phishing-nasil-taninir-farkindalik-ve-savunma-rehberi.html [Resim: attachment.php?aid=136][/center]

Selam TurkTeam, BlueTornado ile.

Teknik kontroller ne kadar iyi olursa olsun, insan faktörü hâlâ en geniş saldırı yüzeylerinden biridir. Bu konu saldırı "nasıl yapılır" diye değil; nasıl tanınır ve nasıl savunulur diye yazıldı. Phishing, vishing, smishing ve iş e-postası dolandırıcılığı (BEC) belirtilerini, güvenli doğrulama alışkanlıklarını ve kurumsal kontrolleri ele alıyoruz.

Konuda Anlatılacaklar
  1. Sosyal mühendislik nedir?
  2. Phishing türleri (e-posta, SMS, ses, QR, BEC)
  3. Tanıma ipuçları ve güvenli kontrol listesi
  4. Lab: kendi test e-postanızı analiz etme
  5. Kurumsal ve bireysel savunma
  6. İleri seviye: MFA yorgunluğu, evilginx tarzı reverse proxy farkındalığı (savunma)
  7. Kaynakça ve yasal uyarı

1) Sosyal Mühendislik Nedir?
Sosyal mühendislik, insanları manipüle ederek gizli bilgiyi ifşa ettirme, zararlı eylem yaptırma veya güvenlik kontrollerini atlatma sanatıdır. Teknik zafiyet yerine güven, acele, korku, hiyerarşi ve yardımseverlik kullanılır.
  • Phishing: Sahte iletişimle kimlik bilgisi veya zararlı dosya/link
  • Spear phishing: Belirli kişi/kuruma özel hazırlanmış
  • Whaling: Üst düzey yönetici hedefi
  • Vishing: Telefon
  • Smishing: SMS
  • Pretexting: Sahte senaryo (IT destek, kargo, banka)
  • BEC: Sahte CEO/tedarikçi ile havale talimatı

Alıntı:İyi bir oltalama maili "kötü Türkçe ve kırmızı bayraklarla dolu" olmak zorunda değildir. Kurumsal dile benzeyen, kişiselleştirilmiş ve acil görünen içerikler daha tehlikelidir.

2) Phishing Nasıl Tanınır?

Gönderen ve domain:
Kod:
# Gözle kontrol Görünen ad: "IT Destek" <it-destek@turkteam-guvenlik.com> # Gerçek domaininiz turkteam.org ise bu şüphelidir # Homoglyph: rn -> m, IDN punycode

Linkler:
  • Üzerine gelince (hover) görünen URL ile metin farklı mı?
  • Kısaltılmış linkler (bit.ly vb.) bilinmeyen gönderende riskli
  • Kod:
    https://turkteam.org.güvenlik-kontrolü.evil.example
    gibi alt alan adı oyunları

İçerik psikolojisi:
  • Aşırı aciliyet: "Hesabınız 1 saat içinde kapanacak"
  • Korku: "Yasal işlem başlatılacak"
  • Ödül: "Kargo sizden ücret bekliyor / ikramiye"
  • Otorite: "Yönetim Kurulu gereği hemen onay"

Ekler:
Kod:
.html
, çift uzantı
Kod:
fatura.pdf.exe
, makro'lu Office, ISO/IMG. Beklemediğiniz bir fatura eki klasik vektördür.

[center][/center]

3) Güvenli Doğrulama Alışkanlıkları
  • Maildeki linke tıklamak yerine tarayıcıya kurumu sizin bildiğiniz adresten yazın
  • Para/havale taleplerini ikinci bir kanaldan (bilinen telefon) doğrulayın
  • IT'nin parolanızı mail ile istemeyeceğini bilin; SSO sayfasına mail içinden gitmeyin
  • Şüpheli maili "bildir" ile SOC/IT'ye iletin; silmeden önce kurum prosedürünü izleyin
  • Kişisel hesaplarda da aynı şüphecilik

Kod:
# Bireysel hızlı kontrol listesi [ ] Gönderen domain gerçek mi? [ ] Ben bu maili bekliyor muydum? [ ] Aciliyet baskısı var mı? [ ] Link hover / ek şüpheli mi? [ ] İkinci kanal doğrulaması yaptım mı?

4) Uygulamalı: Zararsız Analiz Labı
Kendi kendinize gönderdiğiniz veya kurumsal phishing simülasyonundan gelen bir örneği (güvenli ortamda) inceleyin. Üretimde şüpheli ekleri açmayın.

Kod:
# E-posta kaynak başlıklarını görmek (Gmail: Show original) # İncelenecek başlıklar: From: Return-Path: Reply-To: Received: (zincir) Authentication-Results: (SPF/DKIM/DMARC)

Kod:
# Örnek Authentication-Results satırı (kavramsal) spf=pass dkım=pass dmarc=pass # Hepsi fail ise yüksek şüphe; hepsi pass olsa bile içerik sahte olabilir (hesap ele geçirme)

[center][/center]

URL'yi açmadan önce:
Kod:
# VirusTotal / urlscan.io gibi servislere URL yapıştırın (kurum politikasına uygun) # Kendi sandbox'ınız yoksa ekleri çalıştırmayın

5) Kurumsal Savunma Kontrolleri
  • SPF, DKIM, DMARC yayınlayın; DMARC politikasını kademeli sıkılaştırın
  • Gelen kutusu güvenliği: link rewriting, ek sandbox (imkân varsa)
  • MFA zorunlu; mümkünse phishing-resistant (FIDO2 / passkey)
  • BEC için mali süreç: çift onay, bilinen tedarikçi hesap listesi
  • Düzenli farkındalık eğitimi + ölçülebilir simülasyon (cezalandırıcı değil öğretici)
  • SOC playbook: phishing bildirimi -> URL/hash -> IOC -> kullanıcı etkisi

Kod:
# DMARC kayıt örneği (DNS TXT, kavramsal) v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@sizin-domaininiz.com; pct=100

Kod:
# SPF örneği (aşırı geniş +all kullanmayın) v=spf1 include:_spf.google.com -all

6) İleri Seviye Farkındalık (Savunma)
MFA yorgunluğu (fatigue): Saldırgan parolayı bir şekilde elde edip telefonunuza peş peşe MFA bildirimi yağdırabilir. Alışkanlık: beklemediğiniz onayları reddedin; parolayı değiştirin; IT'ye bildirin.

Proxy / Adversary-in-the-middle phishing: Sahte sayfa, gerçek login ile kurban arasında aracılık ederek oturum çerezini/token'ı yakalayabilir. Klasik SMS OTP bu senaryoda yetersiz kalabilir. Passkey/FIDO2 ve Conditional Access (cihaz uyumu, imkânsız gezinti) savunmada öne çıkar.

QR phishing (quishing): Afiş, PDF veya mail içindeki QR bilinmeyen yere götürebilir. Kurumsal cihazda rastgele QR okutmayın.

[center][/center]

Raporlama dili (kullanıcıdan SOC'a):
Kod:
Konu: Şüpheli e-posta bildirimi Gönderen: ... Zaman: 2026-10-17 14:10 Europe/Istanbul Tıkladım mı?: Hayır Ek açtım mı?: Hayır Ekran görüntüsü / .eml ekte

7) Sonuç
Sosyal mühendislik teknik bir açık değil, insan ve süreç açığıdır. Tanıma refleksleri, ikinci kanal doğrulama, DMARC/MFA/passkey ve iyi bir bildirim kültürü en etkili savunma paketidir. Merak ettiğiniz teknik detayları izinsiz sistemlerde denemeyin; kurumsal simülasyon programlarına katılın.



Ek: Ev ve Küçük İşletme İçin 10 Dakikalık Sertleştirme
Büyük bir SOC'unuz olmasa bile uygulanabilir adımlar:
  • E-posta hesabında MFA açın (mümkünse uygulama veya güvenlik anahtarı; SMS son çare)
  • Tarayıcıda şüpheli eklentileri kaldırın; otomatik indirme klasörünü izleyin
  • Kargo/banka SMS'lerindeki linklere değil, resmi uygulamaya gidin
  • İş bilgisayarında yönetici hesabıyla gezmeyin
  • Yedek alın; ransomware'li oltalama ekleri hâlâ yaygındır
  • Aile bireylerine "parola isteme" ve "acil havale" senaryolarını anlatın

Kod:
# Kişisel alan adı kullanıyorsanız (ör. küçük işletme) # DNS'te SPF + DKIM + DMARC'ı hosting panelinden etkinleştirin # DMARC raporlarını ilk ay "p=none" ile izleyip sonra quarantine/reject'e geçin

[center][/center]

Şüpheli bir mesaj aldığınızda duygusal tepkiyi (korku/acele) bilinçli olarak yavaşlatmak, teknik bilgiden önce gelen en ucuz kontroldür. "Bu mail beni ne hissettiriyor?" sorusu bile birçok oltalamayı boşa çıkarır.

Kaynakça
Yasal Uyarı
Bu içerik farkındalık ve savunma eğitimidir. Phishing altyapısı kurmak, başkalarına oltalama yapmak veya izinsiz kimlik bilgisi toplamak suçtur. TCK 243-245 ve ilgili dolandırıcılık maddeleri kapsamında ağır yaptırımlar uygulanabilir. Yalnızca yetkili simülasyon ve kendi labınızda çalışın.

.png   000-team-10-team-94f246.png (Dosya Boyutu: 69.19 KB / İndirme Sayısı: 11) ]]> [Resim: attachment.php?aid=136][/center]

Selam TurkTeam, BlueTornado ile.

Teknik kontroller ne kadar iyi olursa olsun, insan faktörü hâlâ en geniş saldırı yüzeylerinden biridir. Bu konu saldırı "nasıl yapılır" diye değil; nasıl tanınır ve nasıl savunulur diye yazıldı. Phishing, vishing, smishing ve iş e-postası dolandırıcılığı (BEC) belirtilerini, güvenli doğrulama alışkanlıklarını ve kurumsal kontrolleri ele alıyoruz.

Konuda Anlatılacaklar
  1. Sosyal mühendislik nedir?
  2. Phishing türleri (e-posta, SMS, ses, QR, BEC)
  3. Tanıma ipuçları ve güvenli kontrol listesi
  4. Lab: kendi test e-postanızı analiz etme
  5. Kurumsal ve bireysel savunma
  6. İleri seviye: MFA yorgunluğu, evilginx tarzı reverse proxy farkındalığı (savunma)
  7. Kaynakça ve yasal uyarı

1) Sosyal Mühendislik Nedir?
Sosyal mühendislik, insanları manipüle ederek gizli bilgiyi ifşa ettirme, zararlı eylem yaptırma veya güvenlik kontrollerini atlatma sanatıdır. Teknik zafiyet yerine güven, acele, korku, hiyerarşi ve yardımseverlik kullanılır.
  • Phishing: Sahte iletişimle kimlik bilgisi veya zararlı dosya/link
  • Spear phishing: Belirli kişi/kuruma özel hazırlanmış
  • Whaling: Üst düzey yönetici hedefi
  • Vishing: Telefon
  • Smishing: SMS
  • Pretexting: Sahte senaryo (IT destek, kargo, banka)
  • BEC: Sahte CEO/tedarikçi ile havale talimatı

Alıntı:İyi bir oltalama maili "kötü Türkçe ve kırmızı bayraklarla dolu" olmak zorunda değildir. Kurumsal dile benzeyen, kişiselleştirilmiş ve acil görünen içerikler daha tehlikelidir.

2) Phishing Nasıl Tanınır?

Gönderen ve domain:
Kod:
# Gözle kontrol Görünen ad: "IT Destek" <it-destek@turkteam-guvenlik.com> # Gerçek domaininiz turkteam.org ise bu şüphelidir # Homoglyph: rn -> m, IDN punycode

Linkler:
  • Üzerine gelince (hover) görünen URL ile metin farklı mı?
  • Kısaltılmış linkler (bit.ly vb.) bilinmeyen gönderende riskli
  • Kod:
    https://turkteam.org.güvenlik-kontrolü.evil.example
    gibi alt alan adı oyunları

İçerik psikolojisi:
  • Aşırı aciliyet: "Hesabınız 1 saat içinde kapanacak"
  • Korku: "Yasal işlem başlatılacak"
  • Ödül: "Kargo sizden ücret bekliyor / ikramiye"
  • Otorite: "Yönetim Kurulu gereği hemen onay"

Ekler:
Kod:
.html
, çift uzantı
Kod:
fatura.pdf.exe
, makro'lu Office, ISO/IMG. Beklemediğiniz bir fatura eki klasik vektördür.

[center][/center]

3) Güvenli Doğrulama Alışkanlıkları
  • Maildeki linke tıklamak yerine tarayıcıya kurumu sizin bildiğiniz adresten yazın
  • Para/havale taleplerini ikinci bir kanaldan (bilinen telefon) doğrulayın
  • IT'nin parolanızı mail ile istemeyeceğini bilin; SSO sayfasına mail içinden gitmeyin
  • Şüpheli maili "bildir" ile SOC/IT'ye iletin; silmeden önce kurum prosedürünü izleyin
  • Kişisel hesaplarda da aynı şüphecilik

Kod:
# Bireysel hızlı kontrol listesi [ ] Gönderen domain gerçek mi? [ ] Ben bu maili bekliyor muydum? [ ] Aciliyet baskısı var mı? [ ] Link hover / ek şüpheli mi? [ ] İkinci kanal doğrulaması yaptım mı?

4) Uygulamalı: Zararsız Analiz Labı
Kendi kendinize gönderdiğiniz veya kurumsal phishing simülasyonundan gelen bir örneği (güvenli ortamda) inceleyin. Üretimde şüpheli ekleri açmayın.

Kod:
# E-posta kaynak başlıklarını görmek (Gmail: Show original) # İncelenecek başlıklar: From: Return-Path: Reply-To: Received: (zincir) Authentication-Results: (SPF/DKIM/DMARC)

Kod:
# Örnek Authentication-Results satırı (kavramsal) spf=pass dkım=pass dmarc=pass # Hepsi fail ise yüksek şüphe; hepsi pass olsa bile içerik sahte olabilir (hesap ele geçirme)

[center][/center]

URL'yi açmadan önce:
Kod:
# VirusTotal / urlscan.io gibi servislere URL yapıştırın (kurum politikasına uygun) # Kendi sandbox'ınız yoksa ekleri çalıştırmayın

5) Kurumsal Savunma Kontrolleri
  • SPF, DKIM, DMARC yayınlayın; DMARC politikasını kademeli sıkılaştırın
  • Gelen kutusu güvenliği: link rewriting, ek sandbox (imkân varsa)
  • MFA zorunlu; mümkünse phishing-resistant (FIDO2 / passkey)
  • BEC için mali süreç: çift onay, bilinen tedarikçi hesap listesi
  • Düzenli farkındalık eğitimi + ölçülebilir simülasyon (cezalandırıcı değil öğretici)
  • SOC playbook: phishing bildirimi -> URL/hash -> IOC -> kullanıcı etkisi

Kod:
# DMARC kayıt örneği (DNS TXT, kavramsal) v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@sizin-domaininiz.com; pct=100

Kod:
# SPF örneği (aşırı geniş +all kullanmayın) v=spf1 include:_spf.google.com -all

6) İleri Seviye Farkındalık (Savunma)
MFA yorgunluğu (fatigue): Saldırgan parolayı bir şekilde elde edip telefonunuza peş peşe MFA bildirimi yağdırabilir. Alışkanlık: beklemediğiniz onayları reddedin; parolayı değiştirin; IT'ye bildirin.

Proxy / Adversary-in-the-middle phishing: Sahte sayfa, gerçek login ile kurban arasında aracılık ederek oturum çerezini/token'ı yakalayabilir. Klasik SMS OTP bu senaryoda yetersiz kalabilir. Passkey/FIDO2 ve Conditional Access (cihaz uyumu, imkânsız gezinti) savunmada öne çıkar.

QR phishing (quishing): Afiş, PDF veya mail içindeki QR bilinmeyen yere götürebilir. Kurumsal cihazda rastgele QR okutmayın.

[center][/center]

Raporlama dili (kullanıcıdan SOC'a):
Kod:
Konu: Şüpheli e-posta bildirimi Gönderen: ... Zaman: 2026-10-17 14:10 Europe/Istanbul Tıkladım mı?: Hayır Ek açtım mı?: Hayır Ekran görüntüsü / .eml ekte

7) Sonuç
Sosyal mühendislik teknik bir açık değil, insan ve süreç açığıdır. Tanıma refleksleri, ikinci kanal doğrulama, DMARC/MFA/passkey ve iyi bir bildirim kültürü en etkili savunma paketidir. Merak ettiğiniz teknik detayları izinsiz sistemlerde denemeyin; kurumsal simülasyon programlarına katılın.



Ek: Ev ve Küçük İşletme İçin 10 Dakikalık Sertleştirme
Büyük bir SOC'unuz olmasa bile uygulanabilir adımlar:
  • E-posta hesabında MFA açın (mümkünse uygulama veya güvenlik anahtarı; SMS son çare)
  • Tarayıcıda şüpheli eklentileri kaldırın; otomatik indirme klasörünü izleyin
  • Kargo/banka SMS'lerindeki linklere değil, resmi uygulamaya gidin
  • İş bilgisayarında yönetici hesabıyla gezmeyin
  • Yedek alın; ransomware'li oltalama ekleri hâlâ yaygındır
  • Aile bireylerine "parola isteme" ve "acil havale" senaryolarını anlatın

Kod:
# Kişisel alan adı kullanıyorsanız (ör. küçük işletme) # DNS'te SPF + DKIM + DMARC'ı hosting panelinden etkinleştirin # DMARC raporlarını ilk ay "p=none" ile izleyip sonra quarantine/reject'e geçin

[center][/center]

Şüpheli bir mesaj aldığınızda duygusal tepkiyi (korku/acele) bilinçli olarak yavaşlatmak, teknik bilgiden önce gelen en ucuz kontroldür. "Bu mail beni ne hissettiriyor?" sorusu bile birçok oltalamayı boşa çıkarır.

Kaynakça
Yasal Uyarı
Bu içerik farkındalık ve savunma eğitimidir. Phishing altyapısı kurmak, başkalarına oltalama yapmak veya izinsiz kimlik bilgisi toplamak suçtur. TCK 243-245 ve ilgili dolandırıcılık maddeleri kapsamında ağır yaptırımlar uygulanabilir. Yalnızca yetkili simülasyon ve kendi labınızda çalışın.

.png   000-team-10-team-94f246.png (Dosya Boyutu: 69.19 KB / İndirme Sayısı: 11) ]]> <![CDATA[Microsoft YAM Store: 1 Milyar Oltalama Mesajını Destekleyen Altyapı Çökertildi]]> https://www.turkteam.org/konu-microsoft-yam-store-1-milyar-oltalama-mesajini-destekleyen-altyapi-cokertildi.html Fri, 16 Oct 2026 11:12:52 +0300 Tonyukuk]]> https://www.turkteam.org/konu-microsoft-yam-store-1-milyar-oltalama-mesajini-destekleyen-altyapi-cokertildi.html [Resim: attachment.php?aid=9]
Microsoft DCU, YAM Store / CoGUI / Iron Man Oltalama Ekonomisini Çökertti

Merhaba,

14 Ekim 2026'da Microsoft Digital Crimes Unit (DCU) ve Health-ISAC, Çin dilinde faaliyet gösteren bir siber suç pazar yeri ekosisteminin üç bileşenine karşı mahkeme emriyle müdahale etti: YAM Store, CoGUI ve Iron Man. Bu servisler Ocak 2026'dan bu yana 1 milyardan fazla zararlı mesajın gönderilmesini mümkün kıldı. Konu yalnızca bir "phishing kit" değil; hazır hesap, hazır şablon ve hazır altyapı satan bir hizmet ekonomisi.

Konuda Anlatılacaklar
  1. Operasyonun kapsamı ve rakamlar
  2. YAM Store, CoGUI ve Iron Man ne işe yarıyordu?
  3. Japonya'dan başlayan soruşturma nasıl küresel hale geldi?
  4. Son kullanıcı ve kurum için pratik dersler
  5. Kaynakça

1) Rakamlar
Microsoft'un resmi açıklamasına göre:
  • Ocak 2026'dan bu yana 1 milyardan fazla zararlı mesaj (e-posta ve SMS)
  • 75.000'den fazla kuruluş hedef alındı
  • 150'den fazla ülkede faaliyet
  • Yalnızca Microsoft müşterilerine yönelik 750 milyondan fazla mesaj
  • 20.000'den fazla YAM Store bağlantılı hesap devre dışı bırakıldı
  • 100.000'den fazla kimlik taklidi (impersonation) alanı engellendi

2) Üç Bileşen
YAM Store: Çevrimiçi mağaza gibi çalışan bir pazar. Sahte Microsoft ve Google hesapları, kimlik bilgisi hırsızlığı araçları ve hazır altyapı satılıyordu. Operatörler bazen süresi dolmuş meşru alan adlarını (özellikle kar amacı gütmeyen kuruluşlar ve eğitim sektörü) satın alıp siteleri yeniden inşa ederek sahte Microsoft 365 hesapları oluşturuyor, bunları da mağazada satıyordu.

CoGUI: Banka, kamu kurumu ve markaları taklit eden hazır web siteleri ve mesajlar sunan bir kit. Suçlu kendi sahte sitesini sıfırdan yazmak yerine hazır şablonları birkaç tıkla ayağa kaldırabiliyordu. Özellikle Japonya ve ABD'deki kurbanları hedefleyen kampanyalarda yaygındı.

Iron Man: 2026 ortalarında CoGUI'nin yerini almaya başlayan yeni nesil teklif. Microsoft ve Resecurity'nin test satın almalarıyla erişildiği belirtilen sistemde 150'den fazla ülkede banka, perakende, sağlık, ulaşım, polis ve kamu kurumlarını taklit eden 2.300'den fazla şablon tespit edildi. Şablonların varlığı, o kurumun sistemlerinin ele geçirildiği anlamına gelmiyor; yalnızca markanın görsel kimliğinin suçlular tarafından kopyalandığını gösteriyor.

3) Japonya'dan Küresel Operasyona
Soruşturma 2025 sonlarında Japonya Ulusal Polis Teşkilatı'nın (NPA) Microsoft'a ilettiği uyarılarla başladı. Japonya Siber Suç Kontrol Merkezi (JC3), Health-ISAC, Resecurity, Cloudflare, Oracle, Proofpoint ve TRM Labs katkı verdi. ABD Florida Güney Bölgesi Mahkemesi'nden alınan emirle alan adları ele geçirilip yönlendirildi. Microsoft, ABD Secret Service ve uluslararası kolluk kuvvetleriyle istihbarat paylaştığını da belirtti.

4) Pratik Dersler
  • Gelen "kargo teslim edilemedi", "trafik cezası", "vergi borcu", "hesabınız kilitlendi" mesajlarını uygulama içinden veya resmi web sitesinden doğrulayın; mesajdaki bağlantıya tıklamayın.
  • Kurumlar için: Marka taklidi izleme (domain monitoring) ve DMARC/DKIM/SPF zorunlu hale getirilmeli.
  • Süresi dolmuş alan adlarınızı yenilemeyi unutmayın; aksi halde suçlular bunları hesap oluşturma için kullanabiliyor.
  • Sağlık sektörü özellikle hedeflendi; Health-ISAC'ın operasyona katılması bu yüzden anlamlı.
  • Tek bir kampanyayı kapatmak yetmiyor; altyapıyı satan "hizmet ekonomisi"ne vurmak gerekiyor. Bu operasyon tam da bunu yapıyor.

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

.jpg   tonyukuk-05-phishing.jpg (Dosya Boyutu: 125.12 KB / İndirme Sayısı: 8) ]]> [Resim: attachment.php?aid=9]
Microsoft DCU, YAM Store / CoGUI / Iron Man Oltalama Ekonomisini Çökertti

Merhaba,

14 Ekim 2026'da Microsoft Digital Crimes Unit (DCU) ve Health-ISAC, Çin dilinde faaliyet gösteren bir siber suç pazar yeri ekosisteminin üç bileşenine karşı mahkeme emriyle müdahale etti: YAM Store, CoGUI ve Iron Man. Bu servisler Ocak 2026'dan bu yana 1 milyardan fazla zararlı mesajın gönderilmesini mümkün kıldı. Konu yalnızca bir "phishing kit" değil; hazır hesap, hazır şablon ve hazır altyapı satan bir hizmet ekonomisi.

Konuda Anlatılacaklar
  1. Operasyonun kapsamı ve rakamlar
  2. YAM Store, CoGUI ve Iron Man ne işe yarıyordu?
  3. Japonya'dan başlayan soruşturma nasıl küresel hale geldi?
  4. Son kullanıcı ve kurum için pratik dersler
  5. Kaynakça

1) Rakamlar
Microsoft'un resmi açıklamasına göre:
  • Ocak 2026'dan bu yana 1 milyardan fazla zararlı mesaj (e-posta ve SMS)
  • 75.000'den fazla kuruluş hedef alındı
  • 150'den fazla ülkede faaliyet
  • Yalnızca Microsoft müşterilerine yönelik 750 milyondan fazla mesaj
  • 20.000'den fazla YAM Store bağlantılı hesap devre dışı bırakıldı
  • 100.000'den fazla kimlik taklidi (impersonation) alanı engellendi

2) Üç Bileşen
YAM Store: Çevrimiçi mağaza gibi çalışan bir pazar. Sahte Microsoft ve Google hesapları, kimlik bilgisi hırsızlığı araçları ve hazır altyapı satılıyordu. Operatörler bazen süresi dolmuş meşru alan adlarını (özellikle kar amacı gütmeyen kuruluşlar ve eğitim sektörü) satın alıp siteleri yeniden inşa ederek sahte Microsoft 365 hesapları oluşturuyor, bunları da mağazada satıyordu.

CoGUI: Banka, kamu kurumu ve markaları taklit eden hazır web siteleri ve mesajlar sunan bir kit. Suçlu kendi sahte sitesini sıfırdan yazmak yerine hazır şablonları birkaç tıkla ayağa kaldırabiliyordu. Özellikle Japonya ve ABD'deki kurbanları hedefleyen kampanyalarda yaygındı.

Iron Man: 2026 ortalarında CoGUI'nin yerini almaya başlayan yeni nesil teklif. Microsoft ve Resecurity'nin test satın almalarıyla erişildiği belirtilen sistemde 150'den fazla ülkede banka, perakende, sağlık, ulaşım, polis ve kamu kurumlarını taklit eden 2.300'den fazla şablon tespit edildi. Şablonların varlığı, o kurumun sistemlerinin ele geçirildiği anlamına gelmiyor; yalnızca markanın görsel kimliğinin suçlular tarafından kopyalandığını gösteriyor.

3) Japonya'dan Küresel Operasyona
Soruşturma 2025 sonlarında Japonya Ulusal Polis Teşkilatı'nın (NPA) Microsoft'a ilettiği uyarılarla başladı. Japonya Siber Suç Kontrol Merkezi (JC3), Health-ISAC, Resecurity, Cloudflare, Oracle, Proofpoint ve TRM Labs katkı verdi. ABD Florida Güney Bölgesi Mahkemesi'nden alınan emirle alan adları ele geçirilip yönlendirildi. Microsoft, ABD Secret Service ve uluslararası kolluk kuvvetleriyle istihbarat paylaştığını da belirtti.

4) Pratik Dersler
  • Gelen "kargo teslim edilemedi", "trafik cezası", "vergi borcu", "hesabınız kilitlendi" mesajlarını uygulama içinden veya resmi web sitesinden doğrulayın; mesajdaki bağlantıya tıklamayın.
  • Kurumlar için: Marka taklidi izleme (domain monitoring) ve DMARC/DKIM/SPF zorunlu hale getirilmeli.
  • Süresi dolmuş alan adlarınızı yenilemeyi unutmayın; aksi halde suçlular bunları hesap oluşturma için kullanabiliyor.
  • Sağlık sektörü özellikle hedeflendi; Health-ISAC'ın operasyona katılması bu yüzden anlamlı.
  • Tek bir kampanyayı kapatmak yetmiyor; altyapıyı satan "hizmet ekonomisi"ne vurmak gerekiyor. Bu operasyon tam da bunu yapıyor.

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

.jpg   tonyukuk-05-phishing.jpg (Dosya Boyutu: 125.12 KB / İndirme Sayısı: 8) ]]>