Görünmez Unicode oltalamaya döndü: e-postada gördüğünüz metin aynı değil

Microsoft Security Research’ın 3 Eylül 2026 tarihli incelemesi, görünmez Unicode etiket karakterlerinin yüksek hacimli bir oltalama kampanyasında finans temalı sözcükleri parçalamak için kullanıldığını ortaya koydu. İnsanların ekranda kesintisiz gördüğü “funding” gibi ifadeler, filtreye aralarına U+E0000–U+E007F aralığından kod noktaları eklenmiş farklı bir karakter dizisi olarak ulaşabiliyor.

Bu, Microsoft 365 korumasının bütünüyle aşıldığı anlamına gelmiyor: Microsoft’a göre ilgili iletilerin yüzde 99’dan fazlası, görünmez karakteri doğrudan aramayan diğer Defender for Office 365 katmanlarınca işaretlendi. Yayımlanan bulgu, Şubat 2026’da yükselen ve mayıs ortasından sonra gerileyen bir kampanya evresini belgeliyor; yeni olan saldırının başlaması değil, yapay zekâya yönelik prompt enjeksiyonlarıyla tanınan yöntemin geleneksel e-posta kaçınmasında bu ölçekte doğrulanması.

Görünen sözcük ile filtrelenen dizi neden ayrışıyor?

“ASCII smuggling” olarak anılan yöntem, yaygın yazı tipleri ve arayüzlerin göstermediği Unicode Tags bloğundan yararlanıyor. Karakterler ekranda görünmese de ham e-posta içeriğinde gerçek kod noktaları olarak kalıyor; ağ geçidi, arşiv, arama dizini, sınıflandırıcı veya yapay zekâ sistemi bunları işlemeye devam edebiliyor.

Microsoft’un belgelediği örneğin basitleştirilmiş karşılığı şöyle:

• Alıcının gördüğü metin: funding
• Ham karakter dizisi: fun[U+E0020]ding
• Değişmemiş eşleşme kuralının aldığı dizi: “funding” sözcüğünün arasına eklenmiş görünmez bir kod noktası

U+E0020, görünmeyen TAG SPACE karakteridir. Kampanyada bu karakter uzun ve gizli bir yapay zekâ talimatı taşımak için değil, finansal yem sözcüğünün bitişik karakter dizisini bozmak için kullanıldı. Alıcı aynı sözcüğü okumaya devam ederken yalnızca düz metin eşleşmesine veya görünmez karakterleri hesaba katmayan bir düzenli ifadeye bağlı filtre beklediği diziyi bulamayabiliyor.

Bu ayrım, başlıktaki “gördüğünüz metin aynı değil” sonucunun sınırını da belirliyor: sözcüğün ekranda algılanan biçimi değişmiyor, fakat yazılımın aldığı ham kod noktaları görünen harflerden ibaret değil. Bütün filtrelerin aynı şekilde yanıldığı söylenemez; sonucu, her ürünün metni hangi aşamada dönüştürdüğü ve hangi ek sinyalleri kullandığı belirliyor.

Yüksek hacimli evre sona erdi, daha geniş kampanya sürdü

Avlama imzasındaki eşleşmeler 9 Şubat 2026’da keskin biçimde yükseldi ve hafta içlerinde yaklaşık üç ay yüksek kaldı. The Hacker News’in 4 Eylül tarihli haberi, günlük hacmin 1 milyon ile 2,37 milyon ileti arasında seyrettiğini ve bu tekniğin kullanıldığı yüksek hacimli dönemin 15 Mayıs sonrasında hızla gerilediğini aktarıyor.

Microsoft, bu evreyi daha önce Fortra tarafından incelenen ve ActiveCampaign altyapısını kötüye kullanan daha geniş, SBA temalı oltalama faaliyetiyle ilişkilendirdi. Unicode yöntemi daha geniş kampanyanın tamamını tanımlamıyor: faaliyet görünmez etiket karakterleri kullanılmadan önce başlamış, bu belirli örüntü geriledikten sonra da değişerek devam etmişti.

Defender telemetrisindeki yüzde 99’un üzerindeki tespit oranı da “filtreler çalışmadı” yorumunu desteklemiyor. Gönderen, IP adresi, alan adı ve URL itibarı; kimlik doğrulama, marka taklidi analizi, makine öğrenmesi ve görüntüden metin çıkarma gibi kontroller, parçalanmış bir anahtar sözcüğe bağlı kalmadan iletileri değerlendirebildi. Ortaya çıkan boşluk özellikle yalnızca değişmez sözcük listeleri, basit düzenli ifadeler veya tutarsız metin dönüşümleri kullanan katmanları ilgilendiriyor.

Bayrak emojileri neden yanlış alarm üretiyor?

U+E0000–U+E007F aralığındaki her karakteri tek başına zararlı saymak güvenilir bir kural oluşturmuyor. İngiltere, İskoçya ve Galler’in alt bölge bayrakları, siyah bayrak kod noktasının ardından görünmez etiket karakterlerinden oluşan geçerli bir dizi ve bir sonlandırıcı kullanıyor. Microsoft’un ilk geniş avlama imzası bu nedenle söz konusu emojileri içeren meşru iletilerde de çalıştı.

İstisna bütün ülke bayraklarına veya etiket bloğunun tamamına verilmemeli. Geçerli alt bölge bayrağı dizisi bir bütün olarak tanınabilir; sözcüğün içine yerleştirilmiş tekil TAG SPACE ise gönderen geçmişi, kimlik doğrulama sonucu, bağlantılar ve finansal yem bağlamıyla birlikte puanlanabilir. Güvenlik araştırmalarının iletildiği e-postalar ile ağ geçitlerinin ürettiği test örnekleri de ayrı bir temel çizgi gerektirebilir.

Posta hattında normalleştirme nasıl uygulanmalı?

Amaç, kullanıcının okuduğu anlam ile güvenlik motorunun değerlendirdiği metni aynı kanonik temsilde buluşturmaktır. Yalnızca genel bir Unicode normalleştirme biçimi seçmek yeterli kabul edilmemeli; işlem hattının etiket kod noktalarını açıkça bulduğu, politikasına göre işaretlediği veya analiz kopyasından kaldırdığı ve içerik denetimini bu kopya üzerinde yeniden çalıştırdığı test edilmelidir.

ShadowContext’un savunma analizi, kanonikleştirmenin imzalar, sınıflandırıcılar ve yapay zekâya aktarım öncesinde uygulanmasını; özgün iletinin ise adli inceleme için değişmeden korunmasını öneriyor. Aynı dönüşüm ağ geçidi, arşiv, SIEM, arama dizini ve gelen kutusuna bağlı yapay zekâ araçlarında tutarlı değilse farklı katmanlar aynı ileti hakkında farklı kararlar verebilir.

Microsoft 365 kullanan kurumlar için uygulanabilir denetim sırası şudur:

1. Ham MIME içeriğinde, çözümlenmiş konuda ve gövdede U+E0000–U+E007F aralığını kayda geçir.
2. Geçerli İngiltere, İskoçya ve Galler bayrağı dizilerini bağlama duyarlı biçimde ayır; kuralı önce denetim modunda ölç.
3. Etiket karakterleri işaretlenmiş veya kaldırılmış kanonik kopyayı anahtar sözcük, düzenli ifade ve sınıflandırıcılara yeniden gönder.
4. Unicode bulgusunu gönderen altyapısı, kimlik doğrulama, URL itibarı, ilk temas ve ileti benzerliğiyle birleştir.
5. Teslim edilen bir iletide bağlantı tıklandıysa uç nokta süreçlerini, olağandışı oturum açmaları ve sonraki kimlik bilgisi kullanımını ilişkilendir.

Normalleştirme, posta içeriğini özetleyen veya iş akışı başlatan yapay zekâ araçlarına ulaşmadan önce de yapılmalı. Bununla birlikte kanonikleştirme bir yetkilendirme kontrolü değildir; ileti gönderebilen, veri getirebilen veya başka araçları çalıştırabilen sistemlerin izinleri ayrıca sınırlandırılmalıdır.

Bu bir yama haberi değil, işlem hattı uyarısı

Araştırma belirli bir Microsoft 365 sürümündeki yazılım kusurunu, etkilenen sürümler listesini veya kurulacak tek bir yamayı tarif etmiyor. Sorun, geçerli fakat görünmeyen kod noktalarının farklı güvenlik katmanlarında farklı yorumlanması. Bu nedenle düzeltme de tek bir imzadan çok, posta hattındaki metin temsillerinin uyumlaştırılmasına ve bağımsız tespit katmanlarının korunmasına dayanıyor.

Doğrulanan tablo, görünmez Unicode kullanımının Şubat ile mayıs ortası arasındaki yüksek hacimli evrede görüldüğü, sonrasında daha düşük artık etkinlik kaldığı ve daha geniş oltalama faaliyetinin taktik değiştirerek sürdüğü yönünde. Saldırganın kimliği açıklanmadı ve yayımlanan incelemeler bütün e-posta ürünlerinin aynı ölçüde etkilendiğini göstermiyor. Bundan sonraki kritik veri, yeni dalgalarda etiket karakterlerinin yeniden kullanılıp kullanılmadığı ve farklı posta işleme katmanlarının aynı test iletisinden gerçekten aynı kanonik metni üretip üretmediği olacak.

Ayrıca okuyun:

• Hugging Face yalnızca model deposu değil: Hub, Spaces ve Transformers farkı
• Firestore, MongoDB değil: Taşımadan önce bilinen altı uyumsuzluk
• Muse Spark 1.3 çıktı: En güçlü sürüm henüz genel erişimde değil