AI phishing nedir? Yapay zekâ destekli oltalama, saldırganların sahte e-posta, mesaj veya konuşmaları daha doğal ve hedefe özel hazırlamak için yapay zekâ araçlarından yararlandığı sosyal mühendislik yöntemidir. “Merhaba, ben muhasebeden arıyorum. Yeni tedarikçi hesabına ödemeyi hemen yapmamız gerekiyor.” Arayan kişinin sesi yöneticinize çok benziyor; hatta bir video görüşmesinde yüzünü de görüyor olabilirsiniz. Peki gerçekten o mu? Yapay zekâ, oltalama saldırılarının yazım kalitesini ve kişiselleştirme kapasitesini artırırken ses ve görüntü taklidiyle yapılan girişimleri de inandırıcı hâle getirebiliyor. Korunmanın anahtarı mesajın kusurlu görünmesini beklemek değil, talebin kaynağını bağımsız biçimde doğrulamaktır.

FTC, ses klonlama teknolojisinin bir yönetici veya aile üyesinin sesini taklit ederek para ya da bilgi talebini ikna edici gösterebildiğini vurgular. Bunun için her şüpheli aramanın teknik olarak sahte olduğunun kanıtlanmasını beklemek gerekmez; önceden bilinen bir numaradan geri arama yapmak daha güvenilir bir ilk adımdır. Kaynak: FTC ses klonlama uyarısı.

Bu yazıda neler öğreneceksiniz?

  • AI phishing, spear phishing, smishing, vishing ve BEC arasındaki farklar
  • Yapay zekâ ile üretilen e-postalarda kontrol edilmesi gereken işaretler
  • Deepfake ses ve görüntü taleplerinin bağımsız doğrulanması
  • SPF, DKIM, DMARC ve FIDO2 gibi teknik kontrollerin sınırları
  • Yanlışlıkla bağlantıya tıklanınca izlenecek olay müdahalesi adımları
  • 30 günlük kurumsal farkındalık ve ödeme güvenliği uygulama planı

2026’da AI phishing neden daha fazla konuşuluyor?

Verizon’un 2026 DBIR özetine göre mobil cihazlarda sosyal mühendislik mesajlarının tıklanma oranı, karşılaştırılan geleneksel e-posta kanallarına kıyasla %40 daha yüksek. Raporda ayrıca yapay zekânın farklı saldırı tekniklerini desteklediği belirtiliyor. Bu veriler “gelen her SMS sahte” demek değildir; ancak kurum içi farkındalık çalışmalarının yalnızca masaüstü e-posta kutularına odaklanmaması gerektiğini gösterir. Kaynak: Verizon 2026 DBIR.

İş telefonu üzerinden gelen kısa mesaj, işbirliği platformundaki sahte davet, WhatsApp’tan gönderilen sözde kargo bildirimi veya QR kodlu ödeme hatırlatması aynı güven kararını tetikler: Bu talimatı gönderen kişi gerçekten yetkili mi, istenen işlem normal süreçle uyumlu mu?

Phishing, spear phishing, smishing, vishing ve BEC arasındaki fark

Yöntem Kullanılan kanal Tipik aldatma unsuru
Phishing (oltalama) E-posta, web Sahte giriş sayfası veya beklenmedik dosya
Spear phishing Hedefli e-posta/mesaj Kişi, şirket ve proje adıyla özelleştirilmiş talep
Smishing SMS ve mesajlaşma Kargo, ödeme, hesap doğrulama bağlantısı
Vishing Telefon / sesli arama Banka, IT ekibi veya yönetici taklidi
BEC (Business Email Compromise) Kurumsal e-posta ve ödeme süreçleri Fatura alıcısı ya da banka hesabı değişikliği
Deepfake destekli dolandırıcılık Ses, video, görüntü Tanıdık kişinin yapay olarak üretilmiş kimliği

Bu kategoriler birbirini dışlamaz. Saldırgan bir BEC olayını öncesinde hedefli phishing, ardından ses klonlamayla güçlendirebilir. Savunmanın teknoloji kadar onay süreçlerine dayanmasının nedeni budur.

AI phishing nedir; klasik oltalamadan farkı ne?

Oltalama, kişinin güvenini kazanıp parola, tek kullanımlık kod, ödeme veya sisteme erişim elde etmeye yönelik aldatıcı iletişimdir. Yapay zekâ destekli oltalamada saldırgan; kurumsal üsluba benzeyen metinler hazırlayabilir, farklı dillerde doğal yazışabilir, kamuya açık şirket bilgilerini kullanarak ilgili departmana özel senaryolar kurabilir. Geleneksel “yazım hatası var, demek ki sahte” kuralı artık yeterli değildir.

Güncel saldırı örnekleri yalnızca e-posta değildir: smishing (SMS veya mesajlaşma üzerinden oltalama), vishing (sesli arama), sahte toplantı daveti, QR kodla yönlendirme, işletme hesabı taklidi ve ödeme talimatı değiştirme gibi yollar birlikte kullanılabilir. Amaç çoğunlukla kullanıcıyı güvenli rutininden çıkarmaktır.

Bir mesajın riskli olabileceğini gösteren yedi sinyal

  1. Beklenmedik aciliyet: “Bu ödeme 10 dakika içinde yapılmalı”, “Hesabınız hemen kapanacak” gibi baskılar.
  2. Gizlilik talebi: Muhasebe veya IT ekibinin normal kontrolünü atlamanızı isteyen “kimseye söylemeyin” vurgusu.
  3. Yeni hesap veya IBAN: Önceki faturalarla tutarsız banka bilgisi, ödeme alıcısı veya para birimi.
  4. Alışılmadık oturum açma isteği: E-posta bağlantısıyla açılan ve kurumsal giriş ekranını taklit eden sayfa.
  5. Tek kullanımlık kod talebi: Telefonun diğer ucundaki kişinin “güvenlik için” MFA kodunuzu istemesi.
  6. Süreç dışı dosya veya QR kod: Önce makro etkinleştirmenizi, uygulama kurmanızı ya da kişisel cihazınızdan QR okutmanızı gerektiren mesaj.
  7. Kimlik doğrulama itirazı: Talebi bilinen bir kurumsal numaradan teyit etmek istediğinizde karşı tarafın öfkelenmesi veya vazgeçirmeye çalışması.

Bu işaretlerin biri bile doğrulama için yeterli olabilir. Buna karşılık hiçbir işaret bulunmaması mesajın gerçek olduğunu kanıtlamaz.

Sahte e-posta nasıl incelenir? Beş teknik kontrol

1. Görünen isim ile gerçek adresi ayırın. Gelen kutusunda “Ancyra Muhasebe” yazması, iletinin beklenen alan adından gönderildiğini kanıtlamaz. Tam gönderici adresini ve varsa “Reply-To” alanını kontrol edin. Harf benzerliğiyle oluşturulmuş alan adları gözden kaçabilir.

2. Bağlantının gerçek hedefini doğrulayın. Masaüstünde imleci bağlantının üzerine getirmek hedefi gösterebilir; mobilde bağlantıya uzun basarken yanlışlıkla açmamaya dikkat edin. Güvenli yöntem çoğu zaman bağlantıyı hiç kullanmayıp kurumun bilinen adresini tarayıcıya kendiniz yazmaktır.

3. İsteği normal iş süreciyle karşılaştırın. Daha önce fatura göndermiş bir tedarikçinin yeni IBAN bildirmesi otomatik olarak sahte değildir; ancak hesaba ilişkin değişikliği kurumsal kayıtlarla ve bağımsız iletişimle doğrulamayı gerektirir.

4. SPF/DKIM/DMARC sonuçlarını doğru yorumlayın. E-posta başlıklarında doğrulama sonucunun başarısız olması uyarı olabilir; ancak başarılı sonuçlar da mesajın güvenilir olduğunu kesinleştirmez. Ele geçirilmiş meşru bir hesaptan gönderilen zararlı ileti, ilgili kontrollerden geçebilir.

5. Ek ve belge taleplerini değerlendirin. Beklenmedik makro, arşiv şifresi, uzaktan destek uygulaması veya “önce eklentiyi yükle” adımı normal iş akışı dışında kalıyorsa güvenlik ekibine bildirin. Dosyayı çalıştırarak test etmeyin.

Şüpheli e-posta örneği ve doğru yanıt

Konu: ACİL — Ödeme bilgimiz değişti
Merhaba, bugün gönderdiğimiz faturayı yeni banka hesabımıza aktarın. Proje gizli olduğu için başka kişiye sormayın. İşlemi tamamlayınca dekontu bu adrese gönderin.

Bu kurgu örneğinde üç kırmızı bayrak var: hesap değişikliği, aciliyet ve bağımsız kontrolü engelleme. Doğru yanıt iletideki IBAN’ı “test etmek” değildir. Mevcut tedarikçi kaydındaki numaradan yetkiliyle görüşün, hesap değişikliğinin onaylı iş akışına girmesini sağlayın ve orijinal mesajı inceleme için koruyun.

Yönetici sesini taklit eden biri ödeme isterse ne yapmalı?

Örnek senaryo: Finans sorumlusu, CEO’nun sesine benzeyen birinden arama alıyor. “Yeni müşteri anlaşması gizli, 180.000 TL’yi bugün aktarın” talimatı veriliyor. Kurum içinde kural yalnızca tutarın yüksekliğine bağlandıysa daha küçük ödemeler kontrol dışında kalabilir.

Doğru yaklaşım şudur: Görüşmeyi bitirin; kurumsal rehberde kayıtlı numaradan yöneticiyi geri arayın veya iş akışında onaylı ikinci kanalı kullanın. Banka hesap değişikliklerini mesajın içindeki bağlantıdan ya da arayanın verdiği numaradan doğrulamayın. İşlemi kayıtlı iki yetkilinin onayladığı mekanizma üzerinden yürütün. Ses benzerliği, video görüntüsü veya görünen telefon numarası tek başına kimlik kanıtı değildir. FTC de beklenmedik taleplerde resmi iletişim kanallarının kullanılmasını önerir. Kaynak: FTC dolandırıcılıktan korunma.

Çalışanlar için üç aşamalı doğrulama protokolü

1. Dur — İletideki bağlantıya tıklama, dosyayı açma, ödeme başlatma veya kod paylaşma.

2. Bağımsız doğrula — Kişiye, mevcut şirket rehberinden bulunan telefon, kurum içi onay sistemi veya önceden belirlenen güvenilir kanal üzerinden ulaş. Mesajda verilen iletişim bilgilerini kullanma.

3. Bildir ve kaydet — Şüpheli iletiyi güvenlik sorumlusuna ilet; saatini, ekran görüntüsünü, gönderen alan adını ve istenen işlemi kayda geçir. Çalışanları hatalı tıklamayı bildirdikleri için cezalandıran kültür, olayın gizlenmesine yol açabilir.

Teknik savunma: Eğitim neden tek başına yetmez?

Kurumsal savunma birden çok katman gerektirir. E-posta alan adında SPF, DKIM ve DMARC yapılandırmaları taklidi azaltmaya yardımcı olabilir; ancak gerçek ele geçirilmiş hesaplardan gelen mesajları tamamen engellemez. Oltalamaya dayanıklı MFA, parola yöneticileri, cihaz erişim politikaları ve e-posta filtreleri hesap devralma riskini azaltır. Finans tarafında ise yeni hesap alıcısı ekleme ve yüksek riskli işlem için çoklu onay akışı uygulanmalıdır.

Tatbikatların başarısını yalnızca “kaç kişi bağlantıya tıkladı” oranıyla değerlendirmeyin. Şüpheli olayı bildirme süresi, bildirilen olayların doğrulanma hızı ve doğrulama prosedürüne uyum daha anlamlı güvenlik ölçümleridir.

MFA seçimi: Her ikinci faktör aynı korumayı sağlamaz

SMS kodu ve uygulama üzerinden alınan tek kullanımlık kodlar, yalnızca parolaya göre ek bir katman sağlar. Fakat ikna edici sahte bir oturum açma sayfasında kullanıcıdan gerçek zamanlı kod alınabilir. CISA, mümkün olduğunda FIDO/WebAuthn tabanlı oltalamaya dayanıklı MFA kullanılmasını önerir; yüksek yetkili hesaplarda bu tercih özellikle önemlidir. Kaynak: CISA Phishing-Resistant MFA.

Küçük işletmede bütün sistemleri aynı anda değiştirmek zor olabilir. Önce e-posta yöneticileri, bulut yönetimi, alan adı hesabı, finans onay sistemleri ve uzaktan erişimden başlayın. Parola kurtarma yöntemleri ve yedek hesaplar daha zayıf bırakılırsa güçlü MFA’nın etkisi azalabilir.

Finans ve insan kaynakları için örnek doğrulama matrisi

Talep Onaylanmadan önce doğrulama Kayıt
Yeni tedarikçi IBAN’ı Kayıtlı bağımsız numaradan arama + ikinci yetkili Tedarikçi değişiklik kaydı
Yönetici adına acil ödeme Normal finans onay akışı, gerekiyorsa yüz yüze veya bilinen kanal Kim onayladı, saat, tutar
Çalışan maaş hesabı değişikliği İK’nın doğrulanmış kimlik süreci İK onayı ve değişiklik izi
Şifre/MFA sıfırlama Kurumsal yardım masası kimlik kanıtı Talep numarası ve işlem kaydı
Büyük müşteri verisi dışa aktarımı Veri sahibi ve güvenlik sorumlusunun yetkilendirmesi Amaç, kapsam, erişim süresi

Bu tablo bir güvenlik politikası şablonudur; kurumun gerçek yetki matrisi, işlem hacmi ve mevzuat yükümlülüklerine göre uyarlanmalıdır.

30 günlük AI phishing savunma planı

1–7. gün: Yönetici ve finans hesaplarına MFA değerlendirmesi yapın. Ödeme alıcısı değişikliği için iki kanallı doğrulama kuralını yazın. Çalışanların şüpheli iletiyi nereye göndereceği tek cümleyle açık olsun.

8–15. gün: Gönderici alan adlarının SPF, DKIM ve DMARC kurallarını BT uzmanıyla inceleyin. Kritik e-posta hesaplarında cihaz, oturum ve parola kurtarma süreçlerini gözden geçirin. Sesli aramalarda hangi kimlik doğrulama adımlarının kullanılacağını belirleyin.

16–23. gün: Kurgusal, zararsız örneklerle senaryo eğitimi düzenleyin. Finans, destek ve İK ekipleri için farklı vaka kullanın. Amaç çalışanı utandırmak değil, şüpheli talebin hızlı bildirilmesini sağlamaktır.

24–30. gün: Tespit edilen olaylar, doğrulama başarısı, bildirim süresi ve açık kalan süreç eksikleri için kısa bir rapor oluşturun. Eğitim sonuçlarına göre prosedürü güncelleyin.

AI destekli dolandırıcılıkta sık yapılan savunma hataları

  • Tüm çalışanlara yalnızca “yazım hatasına dikkat edin” demek.
  • E-posta güvenlik kontrolünden geçmiş her mesajı kesin güvenilir kabul etmek.
  • Tanıdık ses veya video görüntüsünü tek başına kimlik doğrulaması saymak.
  • MFA kodunu help desk çalışanı olduğunu söyleyen kişiye paylaşmak.
  • Şüpheli olayı bildiren kişiyi suçlamak; bunun sonraki bildirimleri geciktirebileceğini göz ardı etmek.
  • Ödeme prosedürünü yalnızca yüksek tutarlarda işletip hesap değişikliklerini denetimsiz bırakmak.

Bir bağlantıya tıkladıysanız ne yapmalısınız?

Parola veya MFA kodu girdiyseniz derhal güvenlik ekibini bilgilendirin; temiz ve güvenilir bir cihazdan hesap oturumlarını, parolanızı ve giriş yöntemlerinizi gözden geçirin. Kurumsal IT, aktif oturumları sonlandırmalı, şüpheli erişim kayıtlarını araştırmalı ve gerekirse cihazı ağdan ayırmalıdır. Para transferi yapıldıysa bankayla resmî kanaldan gecikmeden iletişim kurulmalıdır. Kanıtları saklayın; olayla ilgili mesajları silmeyin.

Sık sorulan sorular

Deepfake video görüşmesi yüzde yüz anlaşılır mı?

Hayır. Yüz hareketi veya ses bozulması gibi işaretler bulunabilir, fakat yoklukları güvenilirlik kanıtı değildir. İşleme dayalı bağımsız doğrulama daha sağlamdır.

AI phishing’i antivirüs engeller mi?

Bazı zararlı ekleri ve bağlantıları tespit edebilir. Ancak sosyal mühendislik, ele geçirilmiş meşru hesaplar ve telefonla gelen talimatlar için süreç kontrolleri de gerekir.

En pratik kurum politikası hangisi?

Ödeme alıcısı değişikliği, olağan dışı veri talebi veya yeni sistem erişimi gibi yüksek riskli işlemlerde iki kanallı doğrulama ve kayda bağlı onay.

Yapay zekâ ile yazılmış sahte e-postaları yüzde yüz tespit eden araç var mı?

Hayır. Filtreler ve anomali tespiti faydalıdır; fakat yanlış negatifler ve gerçek hesapların ele geçirilmesi mümkündür. İşlem bazlı bağımsız doğrulama gereklidir.

Gerçek telefon numarasından arıyor görünüyorsa güvenilir mi?

Hayır. Arayan numara bilgisi taklit edilebilir. Çağrıyı sonlandırıp önceden doğrulanmış numaradan geri aramak daha güvenlidir.

Deepfake şüphesinde ses kaydı almak gerekir mi?

Kurumun hukuki çerçevesine ve iç politikalarına göre hareket edin. Olay saati, arayan numara, talep edilen işlem ve ilgili ileti kayıtları hukuka uygun biçimde korunmalıdır.

Sonuç: İyi yazılmış bir e-posta, tanıdık ses veya gerçekçi bir görüntü artık yeterli güven unsuru değil. İnsan kontrolünü güçlü kimlik doğrulama ve işlem politikalarıyla birleştiren işletmeler, AI destekli sosyal mühendisliğe karşı daha dayanıklı olur. Kurum genelindeki kontroller için KOBİ siber güvenlik kontrol listesini, olay yaşanması durumunda fidye yazılımı ilk müdahale rehberini ve Ancyra’nın siber güvenlik yaklaşımını inceleyebilirsiniz.

Kaynaklar: FTC ses klonlama · FTC dolandırıcılık işaretleri · CISA oltalamaya dayanıklı MFA · Verizon DBIR 2026