Son dönemde kurumsal Microsoft 365 ortamlarını hedef alan yeni bir kimlik avı yöntemi, çok faktörlü kimlik doğrulamanın (MFA) tek başına yeterli olmadığını bir kez daha gösterdi. Saldırganlar, kullanıcıları sahte bir giriş akışına yönlendirip OAuth izin ekranında onay almaya çalışıyor; böylece parola ele geçirmeden, oturum belirteci ve yenileme belirteci üzerinden kalıcı erişim elde edebiliyor. Analiz edilen kampanyalarda yüzlerce kurumsal kiracı etkilenirken, hedefler arasında farklı ülkelerde faaliyet gösteren şirketlerin Microsoft 365 hesapları da yer aldı.
Bu yöntem özellikle e-posta güvenliği, bulut güvenliği ve IAM (kimlik ve erişim yönetimi) ekipleri için kritik. Çünkü saldırı, klasik parola hırsızlığından farklı olarak, kullanıcının meşru bir oturum açma sürecini kötüye kullanıyor ve SIEM ya da EDR tarafında ilk bakışta şüpheli görünmeyebiliyor.
Saldırı Zinciri Nasıl İşliyor?
Saldırının temelinde, kullanıcıyı Microsoft’un cihaz kodu giriş ekranına benzer bir akışa veya sahte bir uygulama izin ekranına ikna etmek var. Kullanıcı MFA adımını tamamladığını düşünürken aslında bir OAuth uygulamasına erişim izni veriyor. Bu izin, posta kutusu, takvim, kişiler ve dosyalar gibi kaynaklara kapsamlı erişim sağlayan bir refresh token ile sonuçlanabiliyor.
Buradaki kritik nokta şu: MFA, kimlik doğrulama aşamasında devreye giriyor; ancak kullanıcı bir kez “Kabul et” dediğinde, saldırganın aldığı belirteç artık sistemin tasarlandığı şekilde üretilmiş meşru bir varlık oluyor. Yani saldırı, kimlik doğrulama katmanını değil, onay katmanını hedef alıyor. Bu nedenle geleneksel oturum açma alarmları, coğrafi anomali kontrolleri veya cihaz güveni politikaları tek başına yeterli olmayabiliyor.
Neden MFA Bunu Durduramıyor?
Klasik kimlik avında saldırgan kullanıcı adı ve parolayı ele geçirir, ardından bu bilgileri başka bir yerde yeniden kullanmaya çalışır. Modern güvenlik yığınları da bu aşamada ikinci faktör, risk tabanlı erişim veya koşullu erişim politikalarıyla devreye girer. Ancak OAuth izin kötüye kullanımında kullanıcı, doğrudan meşru kimlik sağlayıcı üzerinde oturum açar ve MFA’yı normal şekilde tamamlar. Ardından verdiği izin, saldırganın eline yenilenebilir bir token bırakır.
Bu token çoğu zaman parola sıfırlansa bile geçerliliğini koruyabilir. Kiracı politikalarına bağlı olarak günlerce, hatta haftalarca aktif kalabilen bu erişim, yalnızca açık iptal işlemiyle ya da yeniden onay gerektiren bir koşullu erişim kuralıyla sonlandırılabiliyor. Bu da olay müdahale ekiplerinin yalnızca kullanıcı hesabını kilitlemesinin yeterli olmayabileceği anlamına geliyor.
Kurumsal Ortamlarda Risk Neden Büyüyor?
Günümüzde çalışanlar, takvim entegrasyonları, yapay zekâ asistanları, CRM eklentileri ve dosya senkronizasyon araçları için sık sık izin ekranı görüyor. Bu durum, kullanıcıların “izin ver” butonuna refleksle basmasına yol açıyor. Saldırganlar da tam bu alışkanlıktan faydalanıyor. Özellikle SaaS ekosistemlerinde, tek bir kullanıcının farklı uygulamalara verdiği izinler birleştiğinde “zehirli kombinasyon” olarak adlandırılan riskli bir tablo oluşabiliyor.
Örneğin finans departmanındaki bir çalışanın takvimine erişen bir yapay zekâ toplantı özetleyicisi, aynı kişinin paylaşılan sürücüsüne erişen bir üretkenlik aracı ve müşteri veritabanına bağlanan bir CRM eklentisi ayrı ayrı masum görünebilir. Ancak bu izinler aynı kimlik üzerinden birleştiğinde, saldırgan sözleşme taslaklarına, müşteri kayıtlarına ve iç yazışmalara ulaşabilecek bir köprü kurmuş olur. Bu tür çapraz uygulama ilişkileri, tek bir uygulamanın denetim kaydında tam olarak görünmez.
Teknik Olarak Hangi Sinyaller İzlenmeli?
Bu tip saldırılarda klasik giriş denemeleri kadar OAuth grant kayıtları, uygulama izin geçmişi ve token yenileme olayları da izlenmeli. SIEM tarafında yalnızca başarısız oturum açma denemelerine değil, yeni uygulama onaylarına, olağandışı kapsam taleplerine ve kısa sürede birden fazla SaaS uygulamasına verilen izinlere de alarm tanımlanmalı. Zero Trust yaklaşımı burada özellikle önemli; çünkü güven ilişkisi bir kez kurulduğunda, saldırganın hareket alanı uygulamalar arasında genişleyebiliyor.
MITRE ATT&CK açısından bu kampanya; kimlik avı (T1566), geçerli hesapların kötüye kullanımı (T1078) ve bulut hesaplarının ele geçirilmesiyle ilişkili tekniklerle örtüşüyor. Ayrıca token tabanlı kalıcılık, saldırganın oturum açma olayını tekrar üretmeden erişimi sürdürmesine imkân tanıyor. Bu da EDR ve geleneksel uç nokta kontrollerinin, bulut tarafındaki izin katmanını tek başına göremeyeceği anlamına geliyor.
SOC ve IAM Ekipleri İçin Uygulanabilir Kontrol Listesi
Aşağıdaki kontroller, OAuth tabanlı izin kötüye kullanımını daha erken fark etmek için pratik bir başlangıç noktası sunar:
1. Kiracıdaki tüm üçüncü taraf uygulamaları ve bunların tuttuğu refresh token’ları düzenli olarak envantere alın.
2. 30 günden eski OAuth izinlerini yeniden onay gerektirecek şekilde işaretleyin.
3. Aynı kullanıcıda üç veya daha fazla SaaS uygulamasına yayılan izinleri riskli kabul edin.
4. Yeni uygulama onaylarında kapsam (scope) taleplerini otomatik olarak sınıflandırın ve yüksek riskli izinleri incelemeye alın.
5. Koşullu erişim politikalarını yalnızca oturum açma olaylarına değil, consent olaylarına da bağlayın.
6. Tek bir kullanıcı hesabını kapatmak yerine token düzeyinde iptal playbook’u hazırlayın.
7. OAuth uygulama kayıtlarında yayıncı doğrulaması, izin açıklamaları ve yönlendirme URI’larını denetleyin.
8. Şüpheli onaylardan sonra posta kutusu kuralları, yönlendirme kuralları ve yeni cihaz oturumlarını ayrıca kontrol edin.
Yapay Zekâ Entegrasyonları ve MCP Yüzeyi
Son dönemde yapay zekâ ajanları ve Model Context Protocol (MCP) sunucuları da benzer bir güven modeliyle çalıştığı için risk alanı genişliyor. Bir ajan, takvim, e-posta ya da dosya sistemine erişmek için bir kez yetki aldığında, bu yetki çoğu zaman uzun süreli ve yeniden kullanılabilir oluyor. Pydantic AI gibi çerçevelerle geliştirilen ajanlarda bile, izin kapsamı doğru sınırlandırılmadığında saldırganın erişim yüzeyi büyüyebiliyor.
Bu nedenle kurumlar, yalnızca kullanıcı hesaplarını değil, insan olmayan kimlikleri de kimlik grafiğine dahil etmeli. Ajanların hangi uygulamalara bağlandığı, hangi kapsamları aldığı ve hangi veriye eriştiği sürekli izlenmeli. Aksi halde tek bir entegrasyon, e-posta kutusundan dosya paylaşımına, oradan da müşteri verisine uzanan bir köprüye dönüşebilir.
Yöneticiler İçin Kısa Teknik Özet
Saldırı modeli: OAuth consent phishing / grant abuse
Hedef: Microsoft 365 ve benzeri SaaS ortamları
İlk adım: Sahte giriş veya izin ekranı üzerinden kullanıcı onayı alma
Kalıcılık: Refresh token ile uzun süreli erişim
Görünürlük sorunu: Parola çalma olmadığı için klasik MFA ve oturum açma alarmları yetersiz kalabiliyor
Savunma: Consent olaylarını izleme, token iptali, uygulama envanteri, koşullu erişim, anomali analizi ve ağ segmentasyonu ile desteklenen Zero Trust yaklaşımı
Bu tablo, kimlik güvenliğinin artık yalnızca giriş ekranından ibaret olmadığını gösteriyor. Kurumlar, OAuth izinlerini, AI ajan bağlantılarını ve üçüncü taraf entegrasyonlarını tıpkı kimlik doğrulama kadar kritik bir kontrol alanı olarak ele almadıkça, saldırganlar en zayıf halka olan onay katmanını kullanmaya devam edecek.