Bu makalede7 bölüm
- Teknoloji
- Exchange Online, Defender for Office 365, DMARC, dnstwist, Microsoft Graph PowerShell
- Konu
- İş e-postası dolandırıcılığına karşı teknik ve süreç kontrolleri
- Seviye
- Orta
- Ön koşullar
- Exchange Online PowerShell erişimi
- Finans ve satın alma süreçlerinin bilinmesi
Ekte zararlı yazılım yok, bağlantı yok, yazım hatası yok. Sadece doğru kişiye, doğru zamanda gelen kısa bir e-posta: “Banka hesabımız değişti, bu ayki ödemeyi yeni IBAN’a yapabilir misiniz?” İş e-postası dolandırıcılığı (Business Email Compromise, BEC) böyle çalışır. Bu rehber, finans ve satın alma yazışmalarını e-postayla yürüten kurumlarda tipik BEC senaryolarını, bunları yakalayan teknik kontrolleri ve hiçbir filtrenin yerini tutmayan ödeme doğrulama sürecini anlatıyor.
BEC’i phishing’den ayıran özellikler
Klasik kimlik avı kullanıcıyı bir bağlantıya tıklatmayı veya bir eki açtırmayı hedefler; savunma katmanlarının çoğu da bu yükü taramaya göre kurulmuştur. BEC iletisinde taranacak yük yoktur. Metin kısa, dil düzgün, talep iş akışına uygundur. URL itibar kontrolleri, sandbox ve imza tabanlı filtreler bu yüzden büyük ölçüde boşa çalışır. Filtre metni okur, niyeti okuyamaz.
| Özellik | Kimlik avı | BEC |
|---|---|---|
| Hedef | Kimlik bilgisi, zararlı yazılım | Para transferi, hassas veri |
| Yük | Bağlantı veya ek | Genellikle yok, yalnızca metin |
| Hacim | Toplu gönderim | Az sayıda, hedefli ileti |
| Başarı koşulu | Tek tıklama | Süreç açığı ve güven |
Genel kimlik avı savunma katmanları kurumsal e-postada phishing riskini azaltmak yazısında ele alınıyor. Burada o katmanların görmediği alana odaklanıyoruz.
Tipik senaryolar: CEO dolandırıcılığı, sahte fatura, tedarikçi ele geçirme
Yönetici taklidi
Saldırgan genel müdür veya finans direktörü adına finans ekibine yazar. Görünen ad doğrudur; adres ise ücretsiz bir posta hizmetinden veya benzer bir alan adından gelir. Talep hem acil hem gizlidir: “Bir satın alma görüşmesi yürütüyorum, kimseyle paylaşmadan bugün bu transferi yapmanız gerekiyor.” Yöneticinin seyahatte veya toplantıda olduğu bilgisi kurumsal web sitesinden ve sosyal medyadan toplanmıştır. Zamanlama tesadüf değildir.
Sahte fatura
Saldırgan gerçek bir tedarikçiyi taklit eder ve muhasebeye fatura veya “hesap değişikliği” bildirimi gönderir. Fatura şablonu tedarikçinin web sitesinden ya da daha önce sızmış belgelerden kopyalanmıştır. Tutar gerçek iş hacmine yakın seçilir; dikkat çekmeyecek kadar sıradan.
Tedarikçi posta kutusunun ele geçirilmesi
Tespiti en zor senaryo budur. Saldırgan tedarikçinin gerçek posta kutusuna girmiş, yazışmaları haftalarca okumuş ve ödeme döneminde mevcut yazışma zincirine yanıt olarak yeni IBAN göndermiştir. İleti gerçek alan adından gelir; SPF, DKIM ve DMARC’tan geçer; yazışma geçmişi gerçektir. Yanıtları gizlemek için tedarikçinin posta kutusuna genellikle bir gelen kutusu kuralı da eklenir. Teknik olarak her şey temiz.
Benzer alan adı ve görünen ad sahteciliği
DMARC p=reject yalnızca alan adınızın birebir kullanımını engeller; ayrıntılar DMARC’ta p=reject’e geçiş rehberinde. Saldırgan bu yüzden şu yollara sapar:
- Benzer alan adı: harf değişimi (
examp1e.com), harf ekleme veya çıkarma, farklı üst düzey alan adı (example.com.tryerineexample.comveyaexample.co), tire ekleme (example-tr.com). - Uluslararası alan adı (IDN) benzerliği: Latin harfine benzeyen başka alfabeden karakterler; alan adı DNS’te
xn--ile başlayan Punycode biçiminde görünür. - Görünen ad sahteciliği: Adres
ornek.kisi@ucretsiz-posta.example, görünen ad “Genel Müdür Adı Soyadı”. Mobil istemciler çoğunlukla yalnızca görünen adı gösterdiği için işe yarar. - Reply-To yönlendirmesi: From adresi masum görünür ama Reply-To başka bir adrese ayarlıdır; yanıtlar saldırgana gider.
Kendi alan adınızın varyasyonlarını izlemek için açık kaynaklı dnstwist aracı kullanılabilir. Aşağıdaki komut olası permütasyonları üretir ve yalnızca tescilli olanları listeler:
dnstwist --registered example.com
Çıktıda MX kaydı olan alan adları önceliklidir. E-posta alabilen benzer bir alan adı, hazırlık aşamasındaki bir saldırının işareti olabilir. Aynı taramayı kritik tedarikçilerinizin alan adları için de yapın; sahte fatura onların adıyla gelecek.
Teknik kontroller
Kurumsal siber güvenlik açısından teknik kontroller BEC’i tek başına durdurmaz. Yaptıkları iş, kullanıcıya şüphelenmesi için işaret vermek ve ele geçirme izlerini erken yakalamaktır. Aşağıdaki örnekler Microsoft 365 ortamı içindir.
Dış gönderen etiketlemesi. Exchange Online, desteklenen Outlook istemcilerinde dış iletilere yerleşik bir etiket ekleyebilir:
Set-ExternalInOutlook -Enabled $true
Get-ExternalInOutlook
Kimliğe bürünme koruması. Defender for Office 365 anti-phishing politikalarında yönetici ve finans kullanıcıları korunan kullanıcılar listesine, kritik tedarikçi alan adları korunan alan adları listesine eklenebilir; ayrıntılar Defender for Office 365 yapılandırması rehberinde.
Gelen kutusu kuralı izleme. Ele geçirilmiş posta kutusunda konsolda ilk bakılacak yer kurallardır. Tipik iz; fatura, ödeme, IBAN, havale gibi kelimeleri içeren iletileri silen, okundu işaretleyen veya RSS gibi kimsenin açmadığı bir klasöre taşıyan kurallardır:
Get-InboxRule -Mailbox finans@example.com |
Select-Object Name, Enabled, SubjectOrBodyContainsWords, MoveToFolder, DeleteMessage, ForwardTo, RedirectTo
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
-Operations New-InboxRule,Set-InboxRule,UpdateInboxRules -ResultSize 5000
Dışa otomatik yönlendirmenin engellenmesi. Saldırganın yazışmaları sürekli kopyalamasını önlemek için giden istenmeyen posta politikasında otomatik yönlendirme kapatılabilir; iş gereği olan istisnalar ayrı politikayla tanımlanır:
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode Off
Kimlik koruması. Posta kutusu ele geçirme çoğunlukla parola veya oturum çalınmasıyla başlar. Finans ve yönetici hesaplarında phishing’e dayanıklı MFA ve riskli oturum politikaları ilk sıradadır; konu Entra ID Protection risk politikaları rehberinde işleniyor.
Ödeme değişikliği doğrulama süreci
Bütün senaryoların ortak açığı aynıdır: e-postayla gelen talep yine e-postayla doğrulanır. Kontrol, doğrulamanın bağımsız bir kanaldan yapılmasını zorunlu tutmaktır. Süreç yazılı olmalı, finans yönetimince onaylanmalı ve yöneticilerin kendisi dahil herkese istisnasız uygulanmalıdır. İstisna tanıyan süreç, süreç değildir.
| Talep türü | Doğrulama yöntemi | Onay |
|---|---|---|
| Tedarikçi IBAN değişikliği | Tedarikçi kartındaki kayıtlı numaradan geri arama | İki kişi, değişiklik kaydı |
| Yeni IBAN’a ilk ödeme | Değişiklik talebinden bağımsız ikinci teyit | Finans yöneticisi |
| Yöneticiden acil transfer talebi | Yöneticinin bilinen numarasından sesli teyit | Normal yetki matrisi, istisna yok |
| Yeni tedarikçi kaydı | Vergi bilgisi ve resmi belgelerle kontrol | Satın alma ve finans |
| Fatura üzerinde farklı hesap bilgisi | Ana sözleşme ve önceki ödemelerle karşılaştırma | Muhasebe sorumlusu |
Geri aramada kullanılan numara değişiklik talebini içeren e-postadan, imzadan veya faturadan alınmaz; saldırgan onları da değiştirir. ERP veya muhasebe sisteminde IBAN alanındaki her değişikliğin kim tarafından, hangi kanıtla yapıldığı kayda geçmelidir. Finans çalışanlarına yönelik eğitim “aciliyet ve gizlilik talebi” kalıbını özellikle işlemeli; gerçekçi senaryolarla desteklenen bir program için siber güvenlik eğitimi ve phishing simülasyonu hizmetine bakılabilir.
Olay anında ilk adımlar
Ödeme çıktıysa saat işliyor. Aşağıdaki sıra, finansal kaybı sınırlamayı ve delili korumayı öne alır:
- Bankayı arayın. Transferin durdurulması veya geri çağrılması için gönderen bankaya hemen başvurun; alıcı banka bilgisini ve işlem referansını hazır tutun.
- Delili koruyun. İlgili iletileri silmeyin; tam başlıklarıyla dışa aktarın. Başlıkların nasıl inceleneceği şüpheli e-posta başlık analizi rehberinde anlatılıyor.
- Kaynağı belirleyin. İleti benzer bir alan adından mı geldi, yoksa gerçek tedarikçinin ya da kendi posta kutunuzun içinden mi? Sonraki adımları bu ayrım belirler.
- Ele geçirilmiş hesabı kontrol altına alın. Parolayı sıfırlayın, oturumları sonlandırın (
Revoke-MgUserSignInSession -UserIdile), kayıtlı MFA yöntemlerini, gelen kutusu kurallarını, yönlendirmeleri ve uygulama onaylarını inceleyin. Yalnız parola sıfırlamak yetmez; saldırganın eklediği MFA yöntemi veya uygulama onayı yerinde kalır. - Kapsamı genişletin. Aynı göndericiden veya benzer alan adından gelen diğer iletileri arayın; ele geçirilmiş hesaptan dışarı giden iletileri tespit edip ilgili tarafları bilgilendirin.
- Bildirimleri yapın. Kolluk ve savcılığa suç duyurusu için hukuk birimiyle çalışın. Kişisel veri etkilendiyse 6698 sayılı Kanun’un 12. maddesi kapsamında veri sorumlusunun Kişisel Verileri Koruma Kurulu’na ve ilgili kişilere bildirim yükümlülüğünü, Kurul’un güncel kararlarıyla birlikte KVKK kaynaklarından değerlendirin.
Bu adımların kimde olduğu olaydan önce yazılmalıdır. Finans, IT ve hukuku aynı masaya oturtan bir masa başı tatbikat, sürecin gerçek açıklarını çabuk gösterir: geri arama numarası nerede kayıtlı, hafta sonu bankayı kim arayacak, posta kutusunu kim kilitleyecek. E-posta tarafındaki teknik kontrollerin bir arada kurulumu için e-posta güvenliği ve kimlik avı koruması hizmeti de değerlendirilebilir.
Sık sorulan sorular
DMARC p=reject BEC saldırılarını engeller mi?
Kısmen. DMARC, saldırganın From alanında birebir sizin alan adınızı kullanmasını engeller. Benzer görünen bir alan adından, ücretsiz bir posta hesabından veya ele geçirilmiş gerçek bir tedarikçi posta kutusundan gelen iletiler DMARC’tan geçer. BEC’e karşı DMARC gereklidir, ama yetmez.
Tedarikçinin posta kutusu ele geçirildiyse hangi teknik kontrol işe yarar?
İleti gerçek alan adından ve geçerli kimlik doğrulamasıyla geldiği için filtreler genellikle yakalamaz. Belirleyici kontrol süreçtir: ödeme bilgisi değişikliğinin e-postadaki değil, önceden kayıtlı iletişim bilgisi üzerinden telefonla doğrulanması ve yeni IBAN’a yapılacak ilk ödemenin ek onaya bağlanması.
Dış e-posta etiketini konu satırına mı eklemek daha iyi?
Konu satırındaki ön ek her istemcide görünür, ama yanıt zincirlerinde birikir ve iletinin içeriğini değiştirdiği için bazı durumlarda imza doğrulamasını etkileyebilir. Exchange Online kullanıyorsanız Outlook istemcilerindeki yerleşik Dış etiketi daha temizdir; desteklemeyen istemciler varsa ikisi birlikte değerlendirilebilir.
Sahte faturaya ödeme yapıldığını fark ettiğimizde ilk ne yapılmalı?
İlk adım teknik değil, finansaldır: hemen bankayı arayıp ödemenin durdurulmasını veya geri çağrılmasını talep edin. Ardından ilgili e-postaları başlıklarıyla birlikte silmeden saklayın, posta kutusu ele geçirme belirtilerini inceleyin ve hukuki bildirim sürecini başlatın.
- Teknoloji
- Exchange Online, Defender for Office 365, DMARC, dnstwist, Microsoft Graph PowerShell
- Konu
- İş e-postası dolandırıcılığına karşı teknik ve süreç kontrolleri
- Seviye
- Orta
- Ön koşullar
- Exchange Online PowerShell erişimi
- Finans ve satın alma süreçlerinin bilinmesi
Veri ve E-posta