M365 Cihaz Kodu Phishing - Tek Tıklamayla Zincirleme Yayılma

Bu yazıda anlatılan içeriğin beslendiği Github Repomuza buradan ulaşabilirsiniz: https://github.com/redinpulse/RinP-Kodes-M365-Stealer

%3’lük Tıklama Oranı, %100’lük Etki

Siber güvenlik, teknoloji yatırımlarının en yoğun yapıldığı alanlardan biri. Ancak ayrılan bütçe ve geliştirilen çözümlerin ölçeği ne kadar büyürse büyüsün, en zayıf halka değişmiyor: insan faktörü.

Farkındalık çalışmalarını ne kadar yaygınlaştırır, rutin sosyal mühendislik testleriyle grafikler oluşturup yıllık “bağlantıya tıklama” ve “form doldurma” oranlarını ne kadar yakından izlersek izleyelim, aynı sorun devam ediyor: Yüzdelerdeki iyileşme ile tek bir çalışanın hatası sonucu oluşabilecek güvenlik riski arasındaki uçurumu kapatamıyoruz.

Matematiği basitçe kurduğumuzda da tablo değişmiyor:

Yıllık raporlarda sevindirici görünen bu eğrilerin yanıtlamadığı asıl soru şudur: O tıklamadan - ya da bu yazının odağındaki kod çalıştırıldıktan - sonra ne olur?

Tek bir çalışanın tek bir hatası, kurumun tamamı için hangi kapıları açabilir? Gerçek risk denklemi tam olarak burada kurulur. Geleneksel simülasyon metrikleri ise bu etkinin büyüklüğünü ölçmek için tasarlanmamıştır.

Tam da bu nedenle, çalışanların internete açık üçüncü taraf servislerde oluşturduğu saldırı yüzeyinin sürekli izlenmesi ve haritalandırılması gerekir. Böyle bir harita çıkarıldığında ciddi riskler yalnızca görünür hale gelmez; önceliklendirilerek mevcut güvenlik çözümleriyle bütünleşik biçimde yönetilebilir.

Bu yazıda, Microsoft 365 ekosistemindeki kullanıcı odaklı saldırı yüzeyinin nasıl haritalandırıldığını ve Red in Pulse olarak geliştirdiğimiz Kodes M365 Red Team platformunun bu senaryoyu uçtan uca nasıl yönettiğini anlatacağız.

Çünkü günümüzde kurumunuzdaki her kullanıcı, başlı başına bir saldırı yüzeyidir.

M365 Dünyasında “Link” Yok - “Kod” Var

Kurumsal farkındalık eğitimlerinin büyük bölümü tek bir refleks üzerine kuruludur: “Tanımadığın bağlantıya tıklama.”

Ancak Microsoft 365 odaklı bir saldırı senaryosunda saldırganın bu reflekse ihtiyacı yoktur. OAuth 2.0 Device Authorization Grant, diğer adıyla cihaz kodu akışı (RFC 8628); klavye veya tarayıcı etkileşiminin kısıtlı olduğu yazıcılar, akıllı televizyonlar ve CLI araçları için geliştirilmiş meşru bir kimlik doğrulama standardıdır. Bu meşru akış, sosyal mühendislik senaryosunda saldırganın en önemli avantajına dönüşebilir:

1. Kurbana gönderilen iletide saldırgana ait bir bağlantı bulunmaz. Bunun yerine, “Cihazınızı eşleştirmek için [kod] değerini microsoft.com/devicelogin adresine girin” benzeri bir yönlendirme yer alır.
2. Kullanıcı tarayıcıyı kendisi açar ve gerçek Microsoft adresine kendisi gider. Geleneksel e-posta güvenliği kontrollerinin yeniden yazabileceği, analiz edebileceği veya izole ortamda çalıştırabileceği saldırgana ait bir URL yoktur. Bu nedenle URL yeniden yazma, sahte alan adı tespiti ve marka koruması gibi kontroller sınırlı sinyal üretir.
3. Kimlik doğrulama işlemi gerçek Microsoft sayfasında gerçekleştirilir. TLS sertifikası, alan adı ve marka unsurlarının tamamı orijinaldir.
4. En kritik nokta ise kullanıcının kendi MFA doğrulamasını kendisinin tamamlamasıdır. MFA yorgunluğu saldırısına, MFA bypass yöntemine veya sahte bir kimlik avı sayfasına ihtiyaç duyulmaz. Kullanıcı, meşru görünen bir Microsoft akışı içerisinde her iki faktörü de doğru biçimde girer.

Bu senaryoda MFA tek başına yeterli bir koruma sağlamaz; çünkü MFA kullanıcının kimliğini doğrular, işlemin arkasındaki niyeti değil.

Dolayısıyla simülasyon raporlarında kullanılan “tıklama oranı” metriği, bu senaryoda ölçülmesi gereken davranışı kapsam dışında bırakır. Kullanıcı saldırgana ait bir bağlantıya tıklamamıştır; ancak cihaz kodu akışını tamamlayarak kurum politikalarına bağlı olarak uzun süre kullanılabilecek veya yenilenebilecek bir oturum yetkisini saldırgana teslim etmiş olabilir.

Zincir: Cihaz Kodundan Kurumsal Erişime

Peki kullanıcı o kodu girdikten sonra, izleyen 72 saat içinde ne olur? Kodes’in yönettiği simülasyon zinciri dört aşamada ilerler.

Aşama 1 - Token Yakalama

Cihaz kodu akışı tamamlandığında Microsoft, talep edilen kapsamlar doğrultusunda kısa ömürlü bir access token üretir. İstekte offline_access kapsamı da bulunuyorsa buna uzun ömürlü bir refresh token eşlik edebilir. Refresh token, kullanıcı yeniden kimlik doğrulaması yapmadan yeni erişim token’ları üretilebilmesini sağladığı için zincirdeki asıl stratejik varlıktır. Microsoft’ın cihaz kodu akışı dokümantasyonu da refresh token’ın offline_access kapsamına bağlı olarak üretildiğini belirtir.

Refresh token’ın geçerliliği; token türüne, tenant politikalarına, Conditional Access kontrollerine ve uygulanan iptal işlemlerine göre değişir. Bu nedenle yalnızca oturumu kapatmak veya parolayı değiştirmek her senaryoda anında sonuç vermeyebilir; token açıkça iptal edilene veya süresi dolana kadar yeni erişim token’ları üretmeye devam edebilir. Microsoft’ın token yaşam döngüsü dokümantasyonu, parola değişikliği ve oturum kapatma gibi olayların token türlerine göre farklı sonuçlar doğurabildiğini gösterir.

Kodes tarafında bu aşama, kullanıcının cihaz kodu akışını tamamlamasıyla otomatik olarak gerçekleşir. Elde edilen token’lar şifrelenerek saklanır; kullanıcının adı, UPN bilgisi, IP adresi ve yetki kapsamları gibi kimlik ve oturum verileri ayrıştırılır.

Aşama 2 - Yatay Genişleme: 14 Servis İçin Tek Anahtar

Microsoft’ın bazı birinci taraf uygulamaları, uygulamalar arasında kesintisiz oturum deneyimi sağlamak amacıyla aynı istemci ailesinin parçası olarak çalışır. Bir aile üyesi için üretilen family refresh token, mevcut kullanıcı onayları ve yetki kapsamları dahilinde, aynı ailedeki diğer istemciler için de token alınmasına olanak tanıyabilir. Araştırma dünyasında bu davranış FOCI (Family of Client IDs) olarak adlandırılır. Bu mekanizmanın Microsoft tarafından kasıtlı bir SSO özelliği olarak tasarlandığı, Secureworks FOCI araştırmasında ayrıntılı biçimde ele alınmıştır.

Kodes, bu mekanizmadan yararlanarak tek bir refresh token üzerinden 14 farklı Microsoft servisi için token üretimini ve yetki analizini tek işlemle gerçekleştirir:

Teams · MS Graph · Outlook · SharePoint Online · Azure Management · Azure Core Management · AAD Graph · Substrate · Yammer · Office Apps · Office Management · MAM (Intune) · MS Manage · DOD MS Graph

Buradaki kritik nokta, yeni bir yetki kazanılması değil; kullanıcının daha önce onayladığı veya zaten sahip olduğu yetkilerin farklı Microsoft servislerinde kullanılabilmesidir. Mevcut izinler yeterliyse yeni bir onay ekranı görüntülenmeyebilir ve kullanıcıya ek bir bildirim ulaşmayabilir.

Sıradan bir çalışan hesabı dahi kurum politikalarına bağlı olarak dizin bilgileri, takvim, e-posta, OneDrive ve diğer iş kaynakları üzerinde geniş bir erişim alanına sahip olabilir. Böylece tek bir kimlik doğrulama işleminin etkisi, başlangıçta görünen servisin çok ötesine taşınabilir.

Aşama 3 - Kurumsal Veriye Erişim

Token’lar hazır olduğunda, kullanıcının mevcut yetkileri kapsamında erişilebilen veriler tek bir panelde toplanır. Kodes’in veri görüntüleyicisi Microsoft API’leriyle doğrudan bütünleşerek aşağıdaki kaynakları analiz eder:

• Posta kutusu - Gelen ve gönderilen iletiler ile mesaj içerikleri
• Kurum dizini - Çalışanların ad, unvan, e-posta ve telefon bilgileri
• Takvim ve Teams - Toplantılar, görüşmeler, kararlar ve günlük iş akışları
• OneDrive ve SharePoint - Dosyalar, paylaşım noktaları ve departman siteleri
• Azure abonelikleri - Kullanıcının yetkili olduğu bulut kaynakları

Bu aşamada değerlendirilen etki artık yalnızca “bir kullanıcının e-postalarına erişim” ile sınırlı değildir. Ortaya çıkan veri; kurumun organizasyon yapısını, devam eden projelerini, kritik iş süreçlerini ve dış paydaşlarla kurduğu iletişimi görünür hale getirebilir. Zincirin sonraki adımları, bu kurumsal bağlam üzerinden değerlendirilir.

Aşama 4 - Kurum Ağına Pivot

Son aşamada ele geçirilen uç noktanın kurum ağına sağlayabileceği erişim doğrulanır. Kodes, onaylanmış test kapsamı içerisinde hedef cihazda kimlik doğrulamalı bir SOCKS5 proxy çalıştırır ve bu servise kontrollü bir tünel üzerinden erişim sağlar.

Böylece operatör trafiği hedef cihazın ağ bağlamından yönlendirilebilir; intranet uygulamaları, iç DNS servisleri ve dosya sunucuları gibi yalnızca kurum içinden erişilebilen kaynakların görünürlüğü kontrollü biçimde test edilebilir.

Laboratuvar ve yetkilendirilmiş müşteri testlerimizde bu zincirin tamamı - cihaz kodunun girilmesinden trafiğin kurum ağı üzerinden yönlendirilmesine kadar - dakikalar içinde uçtan uca doğrulanmıştır.

İki Taraflı Görünüm: Saldırgan Ne Kazanır, Savunma Nerede Görür?

Bir red team çalışması, blue team görünürlüğü ve tespit tasarımı olmadan yarım kalır. Bu nedenle zincirin her adımını saldırganın kazancı ve savunmanın görebileceği sinyaller açısından yan yana değerlendirelim:

Microsoft, cihaz kodu kullanımının Entra oturum açma günlüklerinde Authentication Protocol filtresiyle izlenebildiğini ve sonraki token yenilemelerinin Original Transfer Method alanı üzerinden ilk cihaz kodu oturumuyla ilişkilendirilebildiğini belirtiyor. Benzer şekilde MailItemsAccessed, desteklenen posta protokolleri ve istemcileri üzerinden gerçekleşen e-posta erişimlerinin incelenmesinde kullanılabiliyor. (Entra Authentication Flows, MailItemsAccessed)

Tablonun verdiği mesaj açık: Zincirin hiçbir adımı doğası gereği tamamen görünmez değildir. Ancak her adım, tek başına incelendiğinde olağan veya düşük önemde görünebilir. Gerçek görünürlük; Entra oturum kayıtlarını, Microsoft Graph etkinliklerini, iş yükü denetim günlüklerini ve uç nokta telemetrisini aynı oturum bağlamında ilişkilendirebilmekten doğar. Microsoft’ın oturum ve token kimliklerini farklı günlük kaynakları arasında ilişkilendirmeye yönelik yaklaşımı da bu ihtiyacı açıkça ortaya koyar. (Microsoft Entra linkable identifiers)

Sürekli red team çalışmalarının asıl değeri burada ortaya çıkar: Gerçekçi saldırı zincirlerini düzenli aralıklarla işleterek SOC’un yalnızca tekil olayları görüp görmediğini değil, bu olaylar arasındaki bağlantıyı ne kadar hızlı kurabildiğini de ölçmek.

Çözüm: İnsan Riskini Sürekli Ölçmek ve Yönetmek

Yıllık simülasyon ve çeyreklik farkındalık eğitimi döngüsü, Microsoft 365 ekosisteminin oluşturduğu dinamik insan riskini yönetmek için artık yeterli değildir. Önerdiğimiz model üç temel unsura dayanır:

1. Sürekli senaryo çalıştırma - Cihaz kodu akışı dahil olmak üzere güncel saldırgan taktik, teknik ve prosedürlerini (TTP) temel alan kontrollü red team senaryoları düzenli olarak uygulanır. Her çalışmada zincirin hangi aşamada tespit edildiği, ne kadar ilerleyebildiği ve hangi noktada durdurulduğu ölçülür.

2. Purple team entegrasyonu - Her senaryo, savunma ekibi ve mevcut güvenlik telemetrisiyle eş zamanlı olarak izlenir. Önceki bölümdeki görünürlük tablosu kurumun kendi günlükleriyle doldurulur; tespit, korelasyon ve müdahale süreleri raporlanabilir KPI’lara dönüştürülür.

3. Teknik kontrollerle sınırlandırma - Cihaz kodu akışı, Conditional Access politikalarıyla yalnızca ihtiyaç duyulan kullanıcı, grup ve kullanım senaryolarına açılır. Microsoft Graph etkinlik kayıtları ile iş yüküne özgü denetim günlükleri merkezi olarak izlenir; oturum ve token kullanımına ilişkin anomali eşikleri bu saldırı zincirine göre kalibre edilir.

Bu üçlü yaklaşım, insan faktörünü yalnızca “eğitilmesi gereken zayıf halka” olmaktan çıkararak ölçülen, izlenen ve teknik kontrollerle sınırlandırılan bir risk bileşenine dönüştürür.

Red in Pulse, insan riskini yalnızca tıklama oranlarıyla değil; saldırı zincirinin ilerleyişi, savunmanın görünürlüğü ve müdahale süresi üzerinden ölçen bu sürekli red team ve purple team modelinin tam merkezinde yer alır.

Kodes M365 Red Team

Bu yazıda ele aldığımız saldırı zincirini tek bir operasyon yüzeyinden yönetebilmek için Kodes M365 Red Team adında mini bir platformunu geliştirdik. Kodes; sosyal mühendislik senaryosunun ardından yürütülen yetkilendirilmiş red team faaliyetlerini kampanya yönetiminden token analizine, veri görünürlüğünden kurum içi erişim doğrulamasına kadar uçtan uca yöneten bir operasyon panelidir:

• Kampanya yönetimi - Hedef listelerinin oluşturulması, senaryoya özel domain ile dağıtım yapılandırmalarının merkezi olarak yönetilmesi
• Token operasyonları - Elde edilen token’lar üzerinden 14 farklı Microsoft servisi için tek işlemle token üretimi ve mevcut yetki kapsamlarına göre sonraki adım önerilerinin sunulması
• Veri görüntüleyici - Kullanıcının yetkileri dahilindeki e-posta, dizin, takvim, sohbet, dosya ve site verilerinin panel üzerinden incelenmesi; hızlı önizleme ve kapsamlı veri toplama modları
• Kontrollü pivot - Kimlik doğrulamalı SOCKS5 tüneli üzerinden kurum ağına kontrollü erişim sağlanması ve iç kaynak görünürlüğünün doğrulanması. Erişim sağlanan her uç nokta, farklı bir ağ bağlamı ve kurum açısından ayrı bir olay senaryosu oluşturabilir.

Kodes’in araştırma altyapısı, açık kaynak güvenlik ekosistemindeki AADInternals ve TokenTacticsV2 projelerinin ortaya koyduğu teknik birikimden yararlanır. Cihaz kodu tabanlı kimlik avının teknik arka planını ve saldırı metodolojisini daha ayrıntılı incelemek isteyenler için AADInternals’in ilgili araştırma yazısını özellikle öneriyoruz.

Sorumlu Kullanım

Kodes M365 Red Team yalnızca yazılı yetkilendirmeyle yürütülen penetrasyon testi, red team ve purple team çalışmalarında kullanılmak üzere tasarlanmıştır. Bu yazıda adı geçen teknikler, savunma ekiplerinin görünürlüğünü artırmak amacıyla, alandaki kamuya açık araştırmalara dayanarak paylaşılmıştır.