Tipik bir durum: Aylardır yazıştığınız tedarikçiden, açık bir fatura yazışmasının içinde yeni bir ileti gelir: "Banka hesabımız değişti, bu faturadan itibaren ödemeyi aşağıdaki IBAN'a yapınız." Fatura numarası doğrudur, ekteki PDF önceki faturalara benzer, imza bloğu aynıdır. Ödeme yapılır; birkaç hafta sonra tedarikçi parayı almadığını söyler. Bu noktada iki ayrı soru vardır: para geri alınabilir mi ve ileti nereden geldi. Birincisi bankanın işidir, ikincisi kayıtların.
İş e-postası dolandırıcılığı (BEC) nasıl işler?
İş e-postası dolandırıcılığı, saldırganın bir şirketin ya da iş ortağının yazışmasına onun kimliğiyle girip ödeme talimatını değiştirdiği dolandırıcılık türüdür. FBI'ın İnternet Suçları Şikâyet Merkezi (IC3), 2025 yılında kendisine yapılan 24.768 BEC şikâyetinde bildirilen kaybı 3.046.598.558 dolar olarak raporladı; bu, yatırım dolandırıcılığından sonra en yüksek kayıp kalemi. Türkiye için bu ayrıntıda yayımlanmış resmî bir istatistiğe ulaşamadık.
Ekranda aynı görünen ileti teknik olarak üç farklı yoldan gelebilir. Hangisi olduğu, hangi kayda bakılacağını belirler:
| Yol | Ne olmuştur | Başlıkta tipik görünüm | Asıl kanıt nerede |
|---|---|---|---|
| Ele geçirilmiş hesap | Saldırgan tedarikçinin (ya da sizin) gerçek posta kutusuna girmiş, yazışmayı okumuş ve iletiyi o hesaptan göndermiştir. | SPF, DKIM ve DMARC pass; ileti gerçek sağlayıcının sunucularından çıkar. | Hesabın oturum açma kayıtları, posta kutusu kuralları, denetim (audit) kayıtları |
| Benzer alan adı | Saldırgan gerçeğine benzeyen bir alan adı kaydetmiş, yazışmayı oradan sürdürmüştür: tek harf farkı, "-tr" eki, farklı uzantı. | Denetimler çoğu zaman pass, çünkü alan adı saldırganındır. Fark, From'daki alan adı harf harf okununca görünür. | Alan adının kayıt tarihi, ilk TLS sertifikası, saldırganın yazışmanın içeriğine nereden ulaştığı |
| Gönderici taklidi (spoofing) | From alanına gerçek adres yazılmış, ileti bambaşka bir sunucudan gönderilmiştir. | Alıcı sunucunun sonuç satırında dmarc=fail. Alan adının politikası p=none ise ileti yine teslim edilir. | Başlığın kendisi (e-posta başlığı nasıl okunur) |
İlk iki yolda saldırgan yazışmayı genellikle önceden okumuştur; doğru fatura numarası ve doğru zamanlama oradan gelir. Hesabı ele geçirilen tarafta sık rastlanan bir iz, gerçek muhatabın yanıtlarını sahibinden saklayan posta kutusu kurallarıdır: belirli bir göndericiden ya da belirli kelimeleri içeren iletileri okundu işaretleyen, başka klasöre taşıyan ya da silen kurallar. Microsoft, ele geçirilmiş posta kutusunun belirtileri arasında iletileri bilinmeyen adreslere yönlendiren ya da Notlar, Gereksiz E-posta veya RSS abonelikleri klasörlerine taşıyan kuralları sayar. MITRE ATT&CK bu davranışları T1564.008 (Email Hiding Rules) ve T1114.003 (Email Forwarding Rule) olarak tanımlar.
İlk 24 saatte ne yapılmalı?
Sıra önemlidir: önce para, sonra kanıt, sonra hesap güvenliği. Kanıtı kaydetmeden kuralları silmek, sonradan "kural ne zaman, kim tarafından, hangi IP'den kuruldu" sorusunu cevapsız bırakabilir.
- Bankanızı hemen arayın. Transferin durdurulmasını ya da geri çağrılmasını ve alıcı bankaya bildirim yapılmasını isteyin; talebi yazılı olarak da iletin. Bunun mümkün olup olmadığı bankanın ve alıcı bankanın süreçlerine bağlıdır. IC3 raporu da sahte bir transfer fark edildiğinde zamanın belirleyici olduğunu ve ilk olarak finans kuruluşuyla iletişime geçilmesi gerektiğini vurgular. Teknik incelemenin sonucunu beklemeyin.
- Karşı tarafa yazışmadan değil, bildiğiniz telefondan ulaşın. Yazışma saldırganın gözü önünde olabilir. Numarayı şüpheli iletideki imzadan değil, sözleşmeden ya da kayıtlı rehberinizden alın.
- İletiyi silmeyin, iletmeyin; dosya olarak kaydedin. Gmail'de Diğer > İletiyi indir, Outlook'ta Farklı kaydet ile
.emlya da.msgalın; ekli faturayı ayrıca saklayın. Dosyaların SHA-256 değerini hash hesaplama aracıyla not edin. Aynı göndericiden gelmiş önceki gerçek iletileri de saklayın; karşılaştırma için onlar gerekecek. - Posta kutusu kurallarını ve yönlendirmeyi kontrol edin, ama önce kaydedin. Bazı kurallar Outlook'ta ve Outlook web'de görünmeyecek biçimde gizlenebilir. Microsoft 365 yöneticisi Exchange Online PowerShell'de
Get-InboxRule -Mailbox <adres> -IncludeHiddenile gizliler dahil bütün kuralları,Get-MailboxçıktısındakiForwardingSmtpAddressdeğeriyle dış adrese yönlendirmeyi görür. Gmail'de Ayarlar'daki "Yönlendirme ve POP/IMAP" sekmesine ve filtrelere bakın. Şüpheli kuralın komut çıktısını ya da ekran görüntüsünü alın, sonra kapatın. - Oturumları inceleyin, kayıtları dışa aktarın. Microsoft Entra oturum açma kayıtlarında IP adresi, konum, saat ve girişin başarılı olup olmadığı bulunur. Kişisel Gmail hesabında gelen kutusunun sağ altındaki "Ayrıntılar" bağlantısı erişim türünü ve son 10 IP adresini gösterir. Tanımadığınız ülke, saat ya da cihaz not edilir. Kayıtları bugün dışa aktarın: aşağıdaki süreler dolduğunda geri gelmezler.
- Hesabı güvenceye alın: şifre, oturumlar, MFA. Şifreyi değiştirmek tek başına yetmez. Açık oturumlar sonlandırılmalıdır. Microsoft, uygulama parolalarının şifre sıfırlandığında otomatik iptal edilmediğini, ayrıca silinmesi gerektiğini belirtir. Çok faktörlü kimlik doğrulamayı (MFA) açın; hesaba sonradan eklenmiş MFA yöntemlerini ve izin verilmiş uygulamaları gözden geçirin. Yeni şifreyi aynı posta kutusuna e-postayla göndermeyin.
| Kayıt | Varsayılan saklama |
|---|---|
| Microsoft Entra oturum açma kayıtları | Ücretsiz sürümde 7 gün, P1 ve P2 lisanslarında 30 gün |
| Microsoft 365 birleşik denetim kaydı (Audit Standard) | 180 gün (17 Ekim 2023'ten önce üretilen kayıtlar için 90 gün) |
| Exchange Online ileti izleme (message trace) | 90 gün; süre değiştirilemez |
| Google Workspace: Gmail günlüğü ve kullanıcı oturum olayları | 6 ay |
| Google Workspace: e-posta günlüğü araması | 30 gün |
| Kişisel Gmail, "Ayrıntılar" | Süre değil, yalnızca son 10 IP adresi gösterilir |
Saldırgan müşteri ya da çalışan bilgisi içeren bir posta kutusuna eriştiyse olay aynı zamanda bir kişisel veri ihlali olabilir. Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararı, veri sorumlusunun ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirmesini öngörür. Bildirimin gerekip gerekmediğini hukuk biriminizle ya da avukatınızla değerlendirin.
Hangi taraf neyi saklamalı?
| Ödemeyi yapan taraf | Adı kullanılan taraf |
|---|---|
Şüpheli ileti (.eml/.msg) ve eki | Gönderilmiş Öğeler ve Silinmiş Öğeler klasörleri, o günlerin giden iletileri |
| Aynı göndericiden gelmiş önceki gerçek iletiler | Posta kutusu kuralları ve yönlendirme ayarları, değiştirilmeden önceki hâliyle |
| Ödeme dekontu ve bankayla yazışmalar | Oturum açma ve denetim kayıtları |
| Kendi posta kutusunun kuralları ve oturum kayıtları: sızıntı sizin tarafınızda da olabilir | Alan adının SPF, DKIM ve DMARC kayıtlarının olay tarihindeki hâli |
Teknik incelemede nelere bakılır?
İnceleme iletinin kendisinden başlar, iki tarafın kayıtlarına doğru genişler. Ne kadar ilerleyebileceği, hangi kayıtlara hukuka uygun olarak erişilebildiğine bağlıdır.
Başlık ve önceki iletilerle karşılaştırma
İlk iş, şüpheli iletinin başlığını aynı göndericinin önceki gerçek iletileriyle yan yana koymaktır. Gerçek iletiler hep aynı sağlayıcının sunucularından, aynı DKIM seçicisiyle (s=) ve benzer bir Message-ID biçimiyle geliyorsa, şüpheli iletideki farklılık çok şey anlatır. En üstteki Authentication-Results satırında DMARC sonucu, From ile DKIM d= alan adının hizası, Reply-To ve bağlanan sunucunun IP'si okunur. Zinciri tablo hâlinde görmek için başlığı e-posta başlık analizi aracına yapıştırabilirsiniz.
Hesap, oturum ve denetim kayıtları
Microsoft 365'te kural oluşturma, değiştirme ve silme işlemleri denetim kaydına New-InboxRule, Set-InboxRule ve Remove-InboxRule adlarıyla; Outlook masaüstü istemcisinden yapılan kural değişiklikleri UpdateInboxRules adıyla düşer. MailItemsAccessed olayı iletilerin okunduğunu ya da bunlara erişildiğini gösterir; kaydın bulunup bulunmadığı kurumun denetim yapılandırmasına bağlıdır, posta kutusu denetimi tek tek kapatılmış da olabilir. Denetim kayıtlarındaki zamanlar UTC'dir. Google Workspace'te yönetici konsolundaki Gmail günlüğü ve kullanıcı oturum olayları, ileti hareketleri ve oturumlar için benzer bilgiyi verir. Aranan cevap şudur: kuralı kim, ne zaman ve hangi IP'den kurdu; sahte ileti gönderildiğinde hesapta kimin oturumu açıktı.
Alan adı
Benzer alan adı kullanılmışsa alan adının ne zaman kaydedildiği güçlü bir işarettir. Genel uzantılarda kayıt bilgisi artık RDAP üzerinden sorgulanır (ICANN Lookup); .tr uzantılı adların kayıtları TRABİS'tedir. Kayıt sahibi çoğu zaman gizlenmiştir, ama kayıt tarihi görünür. Sertifika şeffaflığı (Certificate Transparency) kayıtları da alan adı için ilk TLS sertifikasının ne zaman alındığını gösterir. Sahte iletiden birkaç gün önce kaydedilmiş ve sertifika alınmış bir alan adı, planlı bir hazırlıkla uyumludur. Sınır: RDAP'taki tarih mevcut kaydın tarihidir; silinip yeniden kaydedilmiş bir adın geçmişini göstermez.
Ekli fatura
Sahte fatura PDF'i, gerçek bir faturanın düzenlenmesiyle hazırlanmış olabilir. Producer, Creator, CreationDate ve ModDate alanları ile dosyanın sonuna eklenmiş güncellemeler, aynı tedarikçinin önceki faturalarıyla karşılaştırılır. Bu alanlar da değiştirilebilir; bulgu olarak tek başına kullanılmaz. Tedarikçi e-Fatura kullanıyorsa, e-postadaki PDF'i e-Fatura sistemi üzerinden gelmiş kayıtla karşılaştırmak da yararlıdır: e-postadaki dosya yalnızca bir kopyadır. Ayrıntı: metadata incelemesi.
Zaman çizelgesi
Kuralın kurulması, şüpheli oturumlar, sahte iletinin gönderimi ve ödeme UTC ve Türkiye saatiyle tek bir çizelgede birleştirilir. Örnek: çizelge, yönlendirme kuralının sahte iletiden iki gün önce yabancı bir IP'den açılmış bir oturumda kurulduğunu gösteriyorsa, bu ilişki bulguların her birinden tek başına daha çok şey anlatır.
Sızıntı kimin sisteminde? Ayırt edilebilenler ve sınırlar
Bu soru neredeyse her dosyada sorulur ve çoğu zaman tek tarafın kayıtlarıyla cevaplanamaz. Başlık ve kayıtlar bazı durumları iyi ayırır, bazılarını ayırmaz:
- İleti tedarikçinin gerçek alan adıyla imzalı ve onun sağlayıcısından çıkmışsa, gönderimde tedarikçinin hesabı ya da sistemi kullanılmıştır. Bu, hesabın ele geçirilmesiyle de, içeriden birinin göndermesiyle de uyumludur; hangisi olduğunu o hesabın oturum kayıtları gösterir.
- İleti benzer bir alan adından geldiyse ama gerçek yazışmayı doğru ayrıntılarla sürdürüyorsa, saldırgan yazışmayı bir yerden okumuştur. Bu yer tedarikçinin posta kutusu, sizin posta kutunuz, yazışmaya bilgi (CC) olarak eklenmiş üçüncü bir kişi ya da yazışmanın bulunduğu bir cihaz olabilir. Sahte iletide alıntılanan metin yalnızca bir tarafın kopyasında bulunan bir parçayı içeriyorsa bu bir ipucudur; çoğu dosyada bu kadar net bir iz yoktur.
- Bir tarafın kayıtlarında şüpheli oturum görünmemesi, o tarafın temiz olduğunu kanıtlamaz. Kayıtların saklama süresi dolmuş, ilgili denetim türü hiç açılmamış ya da erişim kayıtları incelenmeyen başka bir hesap veya cihaz üzerinden yapılmış olabilir.
- Her taraf yalnızca kendi kayıtlarını inceletebilir. Karşı tarafın ya da e-posta sağlayıcısının kayıtları onların rızasıyla ya da mahkeme veya savcılık eliyle istenebilir.
Bizce raporun dili burada özellikle önemlidir. Teknik inceleme, örneğin, "bulgular, tedarikçinin posta hesabına sahte iletiden iki gün önce yurt dışındaki bir IP adresinden erişildiğiyle uyumludur" der; "kusur tedarikçidedir" demez. Zararın kime ait olduğu hukuki bir değerlendirmedir ve mahkemeye aittir. Rapor, avukatınız tarafından dosyaya uzman görüşü olarak sunulabilir; mahkemeyi bağlamaz, diğer delillerle birlikte değerlendirilir. İncelemenin e-posta tarafı e-posta incelemesi, hesap ele geçirme tarafı siber olay incelemesi sayfasında.
Nasıl önlenir?
İki önlem bu dolandırıcılığın farklı yollarını kapatır; biri iş süreci, biri teknik. Birbirinin yerine geçmezler.
Ödeme bilgisi değişikliğinde telefonla doğrulama
En etkili önlem teknik değildir: IBAN ya da banka bilgisi değişikliği hiçbir zaman yalnızca e-postayla kabul edilmez. Değişiklik, karşı tarafın önceden kayıtlı telefon numarası aranarak doğrulanır; numara değişikliği bildiren iletiden alınmaz. Doğrulamayı yapan kişiyle ödemeyi onaylayan kişinin farklı olması ve doğrulamanın tarih, saat ve konuşulan kişiyle kayda geçmesi iyi bir uygulamadır. Bu kural, DMARC'ın hiçbir koruma sağlamadığı iki yola, ele geçirilmiş hesaba ve benzer alan adına karşı da işler.
DMARC politikasını p=reject'e taşımak
DMARC politikası, alan adınızın From alanında izinsiz kullanılması hâlinde alıcı sunuculara ne yapmalarını istediğinizi söyler. p=none bir tercih bildirmez, p=quarantine doğrulanamayan iletiyi şüpheli sayar, p=reject doğrulanamayan kullanımı açıkça geçersiz sayar (RFC 9989). DNS'teki kayıt şuna benzer:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-rapor@example.com"
Geçişi aceleye getirmeyin. RFC 9989'a göre p=reject yayımlayan alan adı DMARC'tan geçmek için yalnızca SPF'e güvenemez, iletilerini geçerli DKIM imzasıyla göndermek zorundadır; aksi hâlde yönlendirilen meşru iletiler reddedilebilir. Kullanıcıları posta listelerine yazan alan adları için RFC, p=reject'in ciddi uyum sorunları çıkarabileceğini söyler ve bu yola girecek olanlara bir sıra önerir: önce en az bir ay p=none ile toplu raporları (rua) izlemek, ardından aynı süre p=quarantine uygulamak, sonuçları karşılaştırıp ondan sonra karar vermek. Sıradan bir şirket alan adı için de bu sırayı izlemenizi öneririz.
Sınırı da bilinmeli: DMARC yalnızca alan adınızın birebir taklidini hedefler; benzer görünümlü alan adlarını ve görünen ad oyunlarını kapsamaz (RFC 9989 §2.2). Ele geçirilmiş gerçek bir hesaptan giden ileti ise DMARC'tan zaten geçer. Bu yüzden bütün posta hesaplarında MFA ve dış adreslere otomatik yönlendirmenin yönetici tarafından kısıtlanması aynı önlem listesinin parçasıdır.