Bir teklif bağlantısını potansiyel müşteriyle paylaşıyorsun. İki dakika sonra takip aracın açtığını, altı sayfayı kaydırdığını ve her birinde 30 saniye harcadığını söylüyor.
Hızlıca bir takip e-postası atıyorsun. Neden bahsettiğin hakkında hiçbir fikirleri yok — henüz açmamışlar.
Ne oldu: şirketlerinin e-posta güvenlik tarayıcısı bağlantını onlardan önce açtı. "Görüntüleme" bir bottu. Ve analitik platformun bunu özellikle ele almıyorsa, farkı anlayamazsın.
Bu nadir bir uç durum değil. Microsoft 365 veya Google Workspace kullanan kurumsal alıcılara gönderilen neredeyse her e-postada yaşanıyor.
Zamanın kısıtlı mı?
Analitiğini şişiren botlar
Paylaşılan sunum bağlantılarına ulaşan üç kategoride otomatik trafik var:
Bağlantı önizleme botları
Slack'e, LinkedIn'e, Twitter'a veya iMessage'a bir bağlantı yapıştırdığında, bir bot hemen sayfayı çekip önizleme kartı oluşturuyor. Bu istekler tanımlanabilir kullanıcı aracılarından geliyor — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Tespit edilmesi ve filtrelenmesi kolay. Çoğu takip aracı bunları doğru şekilde ele alıyor.
Arama motoru tarayıcıları
Googlebot, Bingbot ve varyantları düzenli olarak kamuya açık içeriği indeksliyor. Bunlar da kendilerini açıkça tanıtıyor ve filtrelenmesi basit. Paylaşılan bağlantıların kimlik doğrulaması arkasında veya benzersiz slug'lar kullanıyorsa, tarayıcılar onları genellikle bulamıyor zaten.
E-posta güvenlik tarayıcıları
Analitiği bozan kategori bu.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast ve Google Safe Browsing, gelen e-postalardaki her bağlantıyı alıcı görmeden önce tarıyor. İşleri phishing sayfalarını ve kötü amaçlı yazılımları tespit etmek. Bunu bağlantıyı gerçekten açarak, sayfayı yükleyerek ve birçok durumda içeriğinde gezinerek yapıyorlar.
Gerçek kullanıcılardan ayırt edilmelerini neredeyse imkansız kılan:
- Sahte kullanıcı aracıları. SafeLinks kendini bot olarak tanıtmıyor. Gerçek tarayıcı kullanıcı aracıları kullanıyor — "Windows 11'de Chrome 120" veya hatta "itel A27 Android" gibi mobil cihaz dizeleri. Sunucun meşru bir tarayıcı ziyareti gibi görünen şeyi görüyor.
- Sayfa gezinme. SafeLinks sadece ilk sayfayı yüklemiyor. Toplam uzunluktan bağımsız olarak destenin yaklaşık 6 sayfasını geziyor. Proofpoint benzer çok sayfalı tarama yapıyor.
- Gerçekçi zamanlama. Bu oturumlar 22–48 saniye sürüyor. Kaba bir kazıyıcı gibi anında geçmiyorlar — zamanlama hızlı bir göz gezdirme için inandırıcı görünüyor.
- Sentetik DOM olayları. Bazı tarayıcılar JavaScript olayları tetikliyor — programatik kaydırmalar, simüle edilmiş dokunuşlar, hatta tıklama olayları — kullanıcı etkileşiminin arkasına gizlenmiş kötü amaçlı komut dosyalarını tetiklemek için.
Net etki: Microsoft 365 kullanan bir şirketteki birine e-postayla sunum bağlantısı gönderdiğin her seferde (kurumsal potansiyel müşterilerinin çoğu bu), gerçek gibi görünen sahte bir "görüntüleme" alıyorsun. Bazen iki tane — biri gönderenin güvenlik yığınından, biri alıcınınkinden.
İşte bir SafeLinks bot oturumunun gerçek bir insan izleyiciyle yan yana karşılaştırması:
URL yeniden yazma durumu daha da kötüleştiriyor
Bazı güvenlik araçları bağlantıları önceden taramakla kalmıyor — tamamen yeniden yazıyor. SafeLinks e-posta gövdesindeki her URL'yi Microsoft'un kendi sunucuları üzerinden bir yönlendirmeyle değiştiriyor (https://nam02.safelinks.protection.outlook.com/...). Proofpoint URL Defense yeniden yazmalarıyla aynısını yapıyor (https://urldefense.proofpoint.com/v2/...).
Alıcı e-postasındaki bağlantıya sonunda tıkladığında, orijinal URL'ni doğrudan açmıyor. Yeniden yazılmış SafeLinks URL'sine tıklıyor, bu Microsoft'un proxy'si üzerinden yönlendiriyor — ve Microsoft'un proxy'si o anda sayfanı yeniden taramak için açıyor. Sonra kullanıcının tarayıcısını gerçek sayfana yönlendiriyor.
Sonuç: bot taraması ve gerçek ziyaret aynı anda gerçekleşiyor. Güvenlik tarayıcısı destenizi bir veri merkezi IP'sinden açıyor, gerçek kullanıcı ofisinden açıyor, tam aynı saniyede. Neredeyse aynı zaman damgalarına sahip iki eşzamanlı oturum alıyorsun — biri bot, biri insan. Analitiğin bunları ayırt edemezse, ya ikisini de sayarsın (şişirilmiş) ya da gerçek olanı filtreleme riski alırsın (eksik sayım).
Bu, doğru şekilde ele alınması en zor senaryo. Teslimat öncesi tarama tek başına kolayca tanımlanabilir — kimse tıklamadan dakikalar önce gelir. Ama tıklama anı yeniden taraması gerçek kullanıcıyla birlikte gelir, farklı bir IP'den, farklı bir kullanıcı aracısıyla, meşru olanla örtüşen ayrı bir oturum oluşturarak.
Takip tuzağı
Takipleri zamanlamak için görüntüleme bildirimlerini kullanıyorsan, bot görüntülemeleri aktif olarak zararlı. Potansiyel müşteriyi "destene bakarken" arıyorsun ama onlar henüz e-postalarını açmamışlar. Dikkatli yerine saldırgan görünüyorsun. Ve URL yeniden yazma ile zamanlama bile yanıltıcı — bot oturumu gerçek olanla aynı anda başlıyor.
Standart bot tespiti neden çalışmıyor
Standart yaklaşım — kullanıcı aracılarını bilinen botlar listesiyle karşılaştırmak — bağlantı önizleme botlarını ve tarayıcıları yakalıyor ama e-posta güvenlik tarayıcılarını tamamen kaçırıyor. SafeLinks kasıtlı olarak gerçek görünen kullanıcı aracıları kullanıyor, tam da parmak izi alınmaktan kaçınmak için — çünkü botları tespit eden phishing sayfaları gerçek kullanıcılara gösterdiklerinden farklı içerik sunuyor.
IP tabanlı oran sınırlama da yardımcı olmuyor. SafeLinks bir Azure veri merkezi IP havuzundan geçiş yapıyor, böylece her tarama farklı bir adresten geliyor. Kurumsal VPN'lerdeki meşru kullanıcıları engellemeden IP ile engelleyemezsin.
Tarayıcı parmak izi alma (canvas, WebGL, yazı tipi numaralandırma) çalışmıyor çünkü SafeLinks tam bir Chromium tabanlı tarayıcı çalıştırıyor. Parmak izi gerçek bir Chrome kurulumundan ayırt edilemiyor.
Nasıl çözüyoruz: üç katmanlı tespit
Meşru kullanıcıları — kurumsal VPN'ler ve proxy'ler dahil — engellemeden e-posta güvenlik tarayıcılarını yakalayan bir tespit sistemi geliştirdik.
İşte trafiğin üç katmandan nasıl geçtiği. Yolunu izlemek için herhangi bir düğümün üzerine gel:
Katman 1: Kullanıcı aracısı eşleştirme
Basit kısım. Gelen istekleri 60'tan fazla bilinen bot kalıbıyla karşılaştırıyoruz — bağlantı önizleme botları, arama tarayıcıları, başsız tarayıcılar, HTTP istemci kütüphaneleri. Bir istek kendini Slackbot veya python-requests olarak tanıtıyorsa, hemen reddediyoruz. Oturum oluşturulmuyor.
Bu, bot trafiğinin yaklaşık %40'ını yakalıyor. Kolay olan %40.
Katman 2: Veri merkezi IP tespiti
E-posta güvenlik tarayıcıları kullanıcı aracılarını taklit ediyor ama nereden çalıştıklarını gizleyemiyorlar. SafeLinks Azure veri merkezlerinden çalışıyor. Proofpoint AWS'de çalışıyor. Bunlar bilinen barındırma sağlayıcı IP aralıkları.
Bir izleyici paylaşılan bağlantıyı açtığında, IP'lerini IP'nin bir barındırma sağlayıcısına ait olup olmadığını raporlayan bir coğrafi konum servisiyle kontrol ediyoruz. Öyleyse, oturum bot olarak işaretleniyor.
Bu, e-posta güvenlik tarayıcı trafiğinin büyük çoğunluğunu yakalıyor. Sabah 2'de Microsoft Azure IP'sinden "Quincy, Washington"dan bağlanan bir izleyici neredeyse kesinlikle teklifini okuyan potansiyel müşterin değil.
Burada bir incelik var: bu oturumları engellemiyoruz. Görüntüleme kaydını oluşturuyoruz ama bot olarak işaretliyoruz, analitikten hariç tutuyoruz ve bildirim göndermiyoruz. Bu, yanlış pozitifleri denetlememize izin veriyor ve kullanıcılara istediklerinde bot oturumlarını inceleme seçeneği sunuyor.
VPN kullanıcıları ne olacak?
Kurumsal VPN kullanıcıları bazen veri merkezi IP'leri üzerinden yönlendiriliyor, bu da Katman 2'nin gerçek bir kullanıcıyı bot olarak işaretleyebileceği anlamına geliyor. Katman 3'ün var olma nedeni bu — IP'leri veri merkezi gibi görünse bile insanlara "gerçek" olduklarını "kanıtlama" yolu veriyor.
Katman 3: Jest tabanlı insan doğrulama
Kritik katman bu. Basit bir gözleme dayanıyor: gerçek insanlar sayfayla fiziksel olarak etkileşime girer. Botlar girmez — ya da girdiklerinde etkileşimlerinin ayırt edici bir imzası var.
Bir oturum başlangıçta bot olarak işaretlendiğinde (Katman 2'den), gerçek görüntüleme olarak saymıyoruz. Bunun yerine, gerçek insan girdisini izliyoruz:
Ne izliyoruz: Fare hareketi, dokunma olayları, klavye girdisi ve kaydırma etkinliği.
Ne görmezden geliyoruz: Sayfa gezinme, bağlantı tıklamaları ve indirmeler. Bu sezgisel olmayan — bunlar güçlü insan davranışı sinyalleri gibi görünüyor. Ama SafeLinks taradığı her destenin 6+ sayfasını geziyor. Puppeteer gibi başsız tarayıcılar programatik olarak düğmelere tıklayıp indirmeleri tetikleyebilir. Bu eylemler kolayca taklit edilebilir. Düşük seviyeli giriş cihazı olaylarını ikna edici şekilde sentezlemek çok daha zor.
3 saniyelik pencere: Sayfa yüklenmesinden sonraki ilk 3 saniyedeki tüm jestleri görmezden geliyoruz. SafeLinks ve Proofpoint sentetik olaylarını neredeyse anında tetikliyor — sayfa yüklenmesinden 500 milisaniye içinde. Gerçek insanların yönlerini bulup etkileşime başlamaları en az 3 saniye sürüyor. Bu tek zamanlama eşiği sentetik olay gürültüsünün büyük çoğunluğunu ortadan kaldırıyor.
Fare hareketi analizi: 3 saniyelik pencereden sonra bir fare hareketi tespit ettiğimizde, yörüngeyi günlüğe kaydediyoruz — 20 hareket olayına kadar koordinatlar ve zaman damgaları. Bot tarafından oluşturulan fare hareketleri geometrik yollar izliyor (mükemmel düz çizgiler, tam daireler) veya tek bir olay tetikliyor. İnsan fare hareketlerinde organik hızlanma ve yavaşlama, hafif eğriler ve mikro düzeltmeler var.
Gerçek bir jest tespit edildiğinde, oturum atomik olarak bottan gerçeğe "terfi" ettiriliyor. O noktada — ve yalnızca o noktada — görüntüleme sayısı artıyor ve bildirim alıyorsun.
Zamanlama önemli
Tüm sistem belirli bir yarış durumu etrafında tasarlanmış: gerçek bir kullanıcı bağlantıyı açar, faresini bir kez hareket ettirir ve hemen sekmeyi kapatırsa ne olur?
Onay isteği sekme kapanmadan önce tamamlanmayabilir. Tarayıcılar gezinme sırasında devam eden fetch() isteklerini iptal eder. Bu yüzden yedek olarak sendBeacon() kullanıyoruz — sayfa kapanmalarında hayatta kalan ateşle-ve-unut istekleri için özel olarak tasarlanmış bir tarayıcı API'si. Son beacon, onay verisini oturumun etkileşim metrikleriyle birlikte taşıyor.
Sunucu tarafında terfi atomik: yalnızca oturum daha önce terfi ettirilmemişse başarılı olan tek bir SQL güncellemesi. Bu, hem normal onay hem de beacon yedek geldiğinde çift saymayı önlüyor.
Bu analitiğin için ne anlama geliyor
Pratik etki önemli. Kurumsal odaklı satış ekipleri genelinde yaptığımız testlerde, görünen sunum görüntülemelerinin %15–40'ı bot oturumlarıydı — ağırlıklı olarak SafeLinks ve Proofpoint'ten. Katı e-posta güvenlik politikalarına sahip büyük kuruluşlara satan ekipler için rakam daha da yüksekti.
Filtreleme olmadan:
- Görüntüleme sayıları %15–40 şişirilmiş
- "En çok etkileşimde olan" potansiyel müşteriler en agresif e-posta güvenliğine sahip olanlar olabilir
- Görüntüleme zamanlaması güvenilir değil — birinin desteni öğleden sonra 2'de görüntülediğini düşünüyorsun ama güvenlik tarayıcısı 1:58'de açmış
- Takip sinyalleri gürültü
Filtreleme ile:
- Her görüntüleme içeriğine gerçekten bakan bir insanı temsil ediyor
- Etkileşim metrikleri (harcanan süre, görüntülenen sayfalar, tamamlanma oranı) gerçek ilgiyi yansıtıyor
- Görüntüleme bildirimleri bir bot önceden tarama yaptığında değil, bir insan aktif olarak etkileşimdeyken tetikleniyor
HummingDeck'te bot oturumlarını kontrol etme
Etkinlik akışı, filtrelenmiş oturumları incelemenize izin veren bir "Bot oturumlarını göster" filtresi içeriyor. Belirli potansiyel müşterileriniz için sistemin doğru çalıştığını doğrulamak için kullanın — meşru bir izleyicinin işaretlendiğini görürseniz, jest onay katmanı sayfayla etkileşime geçtiklerinde onları terfi ettirmelidir. Ettirmezse, destek ekibiyle iletişime geçin.
Daha geniş ders
E-posta güvenlik taraması ortadan kalkmıyor — daha kapsamlı hale geliyor. Microsoft ve Google, phishing saldırıları daha sofistike hale geldikçe otomatik bağlantı taramayı genişletiyor. Sayfa yüklemelerini insan görüntülemelerinin temsilcisi olarak kullanan herhangi bir analitik platformu giderek daha hatalı hale gelecek. Sunum görüntülemelerini şişiren aynı botlar, e-posta açılma oranlarını da sahte olarak yükseltir.
İhtiyacın olan sinyal "bağlantım açıldı mı?" değil. "Bir insan içeriğimle etkileşime geçti mi?" Bu, farkı tespit etmeyi gerektiriyor — ve fark sayfa yüklemesinde değil, jestlerde.