Active Directory’den Entra ID’ye Geçiş Saldırı Yüzeyini Artırıyor mu?

Kurumsal kimlik altyapıları son yıllarda ciddi bir dönüşüm geçiriyor. Uzun yıllar boyunca Microsoft ekosistemindeki kimlik yönetiminin merkezinde Active Directory bulunuyordu. Kullanıcı hesapları, bilgisayarlar, servis hesapları, grup üyelikleri ve yetkilendirme mekanizmalarının büyük bölümü kurumun kendi veri merkezindeki Domain Controller’lar tarafından yönetiliyordu.

Cloud servislerinin yaygınlaşmasıyla birlikte bu model değişmeye başladı. Microsoft 365, Azure ve SaaS uygulamalarının hayatımıza girmesiyle Microsoft Entra ID birçok kurum için kimlik altyapısının merkezine yerleşti.

Bu dönüşüm beraberinde önemli bir güvenlik sorusunu getiriyor:

Active Directory’den Entra ID’ye geçmek saldırı yüzeyimizi gerçekten azaltıyor mu, yoksa yalnızca saldırı yüzeyinin şeklini mi değiştiriyoruz?

Bu soruya doğrudan “evet” veya “hayır” şeklinde cevap vermek pek mümkün değil.

Çünkü Entra ID’ye geçiş bazı geleneksel saldırı vektörlerini azaltırken, aynı zamanda token’lar, API’ler, application registration’lar, service principal’lar, workload identity’ler ve servisler arası güven ilişkileri gibi tamamen farklı güvenlik alanlarını hayatımıza sokuyor.

Yakın zamanda ortaya çıkarılan ve Microsoft tarafından CVE-2025-55241 olarak yayımlanan Actor Token zafiyeti ise bu yeni saldırı yüzeyinin ne kadar karmaşık olabileceğini gösteren oldukça çarpıcı bir örnek.

Active Directory Dünyasında Saldırı Yüzeyi

Active Directory güvenliğiyle uzun yıllardır ilgilenenler için saldırı yüzeyinin önemli bölümü oldukça tanıdıktır.

Domain Controller’lar, Kerberos, NTLM, LDAP, servis hesapları, delegation mekanizmaları, trust ilişkileri ve privileged account’lar yıllardır saldırganların hedef aldığı alanlar arasında bulunuyor.

Basitleştirirsek geleneksel saldırı yüzeyini şöyle düşünebiliriz:

                Active Directory
                       |
        +--------------+--------------+
        |              |              |
     Kerberos         NTLM           LDAP
        |              |              |
     Tickets       Credentials    Directory
        |              |              |
        +--------------+--------------+
                       |
                Domain Controller
                       |
              Privileged Accounts
                       |
           Domain / Enterprise Admin

Pass-the-Hash, Pass-the-Ticket, Kerberoasting, AS-REP Roasting, NTLM Relay, delegation abuse ve credential dumping gibi tekniklerin büyük bölümü bu mimarinin farklı noktalarını hedef alıyor.

AD CS’nin yaygınlaşmasıyla certificate tabanlı saldırılar da bu saldırı yüzeyinin önemli parçalarından biri haline geldi.

Dolayısıyla Active Directory kesinlikle küçük bir saldırı yüzeyine sahip değil. Ancak bu saldırı yüzeyinin önemli bir özelliği var:

Altyapının büyük bölümü kurumun kendi kontrolünde.

Domain Controller sizin.

Firewall sizin.

Network sizin.

Authentication protokollerinin nasıl kullanılacağını büyük ölçüde siz belirliyorsunuz.

Logların önemli bölümü sizin sistemlerinizde üretiliyor.

Cloud identity dünyasına geçtiğimizde ise güven modeli değişmeye başlıyor.

Entra ID ile Saldırı Yüzeyi Ortadan Kalkmıyor

Microsoft Entra ID modern authentication konusunda klasik Active Directory’ye göre oldukça güçlü güvenlik yetenekleri sunuyor.

Conditional Access, phishing-resistant MFA, passkey/FIDO2, Identity Protection ve Privileged Identity Management gibi mekanizmalar kullanıcı kimliklerinin korunmasında önemli avantajlar sağlıyor.

Ancak burada yapılan yaygın hatalardan biri şu: “MFA ve Conditional Access kullanıyorum, dolayısıyla identity tarafım güvende.”

Modern cloud identity bundan çok daha karmaşık. Entra ID dünyasında artık yalnızca kullanıcıların nasıl authenticate olduğunu düşünmüyoruz.

Aynı zamanda:

OAuth / OpenID Connect
Access Tokens
Refresh Tokens
Application Registrations
Enterprise Applications
Service Principals
Managed Identities
Workload Identities
API Permissions
Guest / B2B Identities
Federation
Microsoft Graph
Service-to-Service Authentication

gibi çok sayıda bileşeni güvenlik modelimize dahil etmek zorundayız. Kabaca şöyle bir mimari ortaya çıkıyor:

                        Entra ID
                           |
        +------------------+------------------+
        |                  |                  |
      Users           Applications       Workloads
        |                  |                  |
       MFA          Service Principals   Managed Identity
        |                  |                  |
 Conditional Access    API Permissions       |
        |                  |                  |
        +------------------+------------------+
                           |
                     OAuth Tokens
                           |
             +-------------+-------------+
             |             |             |
        Microsoft 365     Azure         SaaS
             |
       Exchange / Teams
       SharePoint / etc.

Dolayısıyla saldırı yüzeyi kaybolmuyor.

Dönüşüyor.

Paroladan Token’a Geçiş

Active Directory güvenliğinde yıllarca credential’ları korumaya odaklandık. Saldırganın kullanıcı parolasını veya NTLM hash’ini ele geçirmesini engellemeye çalıştık. Cloud identity dünyasında ise saldırganın her zaman parolaya ihtiyacı olmayabilir. Geçerli bir access token, refresh token veya application credential ele geçirildiğinde saldırgan bazı senaryolarda kullanıcının authentication sürecini tekrar gerçekleştirmeden kaynaklara erişebilir.

Bu nedenle modern identity saldırılarında soru artık sadece: “Parolayı nasıl koruyacağız?” değil.

Aynı zamanda: “Kimlik doğrulama tamamlandıktan sonra oluşturulan tokenları ve bu tokenları oluşturabilecek workload identity’leri nasıl koruyacağız?” olmalıdır. Actor Token vakası tam olarak bu noktada oldukça öğretici bir örnek sunuyor.

Actor Token Nedir?

Güvenlik araştırmacısı Dirk-jan Mollema, Black Hat ve DEF CON sunumları için yaptığı araştırmalar sırasında Microsoft’un backend servislerinde kullanılan undocumented bir token mekanizmasıyla karşılaştı.

Bu tokenlara Actor Token adı veriliyordu. Actor Token’lar Microsoft’un servisler arası, yani service-to-service (S2S) iletişiminde kullandığı impersonation mekanizmasının bir parçasıydı. Araştırmacının bulduğu kritik problem ise Actor Token mekanizmasının legacy Azure AD Graph API’deki tenant validation eksikliğiyle birleşmesiydi. Sonuç teorik olarak son derece ağırdı:

Bir tenant’tan elde edilen Actor Token başka bir Entra ID tenant’ındaki herhangi bir kullanıcıyı, Global Administrator dahil, impersonate etmek için kullanılabiliyordu.

Araştırmacı Actor Token mekanizmasıyla ilk olarak hybrid Exchange yapılarını incelerken karşılaştığını belirtiyor. Exchange, başka Microsoft servisleriyle bir kullanıcı adına iletişim kurması gerektiğinde Actor Token isteyebiliyordu. Bu mekanizma Exchange Online, SharePoint ve Azure AD Graph gibi servislerle service-to-service iletişim için kullanılabiliyordu.

Actor Token içerisindeki dikkat çekici claim’lerden biri şuydu:

trustedfordelegation: true

Bu claim, token’ın başka kimlikler adına işlem yapılabilmesi açısından önemliydi. Ayrıca araştırmadaki Actor Token’ın expiration süresi tam olarak 24 saat olarak görülüyordu. Ancak hikayenin en ilginç kısmı bundan sonra başlıyor.

İmzalanmamış Impersonation Token

Exchange Actor Token’ı kullanırken token başka bir JWT içerisinde taşınabiliyordu. Bu JWT’nin header’ında dikkat çekici şekilde:

{
    "alg": "none",
    "typ": "JWT"
}

bulunuyordu. Yani araştırmacının “impersonation token” olarak adlandırdığı bu yapı imzalanmamıştı. Araştırmacının değerlendirmesine göre Actor Token mekanizmasının güvenlik açısından problemli bazı özellikleri bulunuyordu:

• Actor Token oluşturulduğunda görünür log üretilmiyordu.
• Impersonation token’larının oluşturulması veya kullanılması normal Entra ID authentication telemetry’sini üretmiyordu.
• Tokenlar 24 saatlik geçerlilik süresi içerisinde revoke edilemiyordu.
• Conditional Access kısıtlamalarını bypass ediyordu.
• Token kullanımını tespit edebilmek büyük ölçüde resource provider’ın logging yeteneğine bağlıydı.

Burada çok önemli bir noktaya geliyoruz. Bir kurum Global Administrator hesaplarını son derece sıkı koruyor olabilir.

Örneğin:

Global Administrator
        |
        +-- Phishing-resistant MFA
        +-- Conditional Access
        +-- Compliant Device
        +-- PIM
        +-- Restricted Location

kullanılıyor olabilir. Ancak saldırı normal kullanıcı authentication sürecinden geçmiyorsa bu kontrollerin tamamı aynı şekilde devreye girmeyebilir. Actor Token vakasında da tam olarak böyle bir durum söz konusuydu.

Asıl Kritik Hata: Tenant Sınırının Aşılması

Actor Token mekanizması tek başına bu zafiyetin tamamını oluşturmuyordu. Asıl kritik hata legacy Azure AD Graph API tarafındaydı. Araştırmacı testleri sırasında impersonation token içerisindeki tenant ID değerini değiştirdi. Normal şartlarda beklenecek davranış oldukça basit:

Actor Token -> Tenant A

Impersonation Token -> Tenant B

               ↓

           REJECT

Çünkü token’ın oluşturulduğu tenant ile erişilmeye çalışılan tenant birbirinden farklı. Fakat Azure AD Graph bu uyuşmazlığı beklenen şekilde reddetmedi. Araştırmacı hedef tenant’taki geçerli bir kullanıcının netId değerini kullandığında Azure AD Graph üzerinden başka tenant’taki verilere erişebildiğini gördü.

Test farklı lab tenant’larında tekrarlandığında aynı davranış doğrulandı. Böylece problem bir anda çok daha büyük hale geldi.Artık soru: “Bir Microsoft servisi kendi tenant’ındaki kullanıcı adına işlem yapabilir mi?” değildi.

Soru şuna dönüşmüştü: “Bir tenant’taki Actor Token başka bir tenant’taki kullanıcı adına kullanılabilir mi?” Araştırmaya göre zafiyet düzeltilmeden önce cevap evet idi.

Global Administrator’a Kadar Giden Yol

Araştırmacı zafiyetin etkisini göstermek amacıyla hedef tenant içerisindeki bir Guest kullanıcının kimliği üzerinden Global Administrator’ın netId bilgisini elde etti. Daha sonra aynı Actor Token kullanılarak Global Administrator için impersonation token oluşturuldu. Sonuçta Azure AD Graph üzerinde Global Administrator kimliğiyle işlem yapılabildi. Bu noktada olay artık basit bir information disclosure zafiyeti olmaktan çıkıyor.

Araştırmaya göre erişilebilecek Entra ID verileri arasında:

• Kullanıcı bilgileri
• Gruplar
• Roller
• Tenant ayarları
• Conditional Access politikaları
• Applications
• Service Principals
• Application permission assignments
• Device bilgileri
• Entra ID’ye senkronize edilen BitLocker key bilgileri

bulunuyordu.

Global Administrator impersonate edildiğinde ise bunların değiştirilmesi de mümkün hale gelebiliyordu.

Global Admin Compromise Artık Sadece Directory Compromise Değil

Active Directory dünyasında Domain Admin compromise olduğunda ortaya çıkabilecek blast radius’u biliyoruz. Entra ID dünyasında benzer bir durumun etkisi daha farklı bir alana yayılabilir. Çünkü Entra ID yalnızca directory hizmeti değildir.

                         Entra ID
                            |
          +-----------------+----------------+
          |                 |                |
          v                 v                v
     Microsoft 365        Azure             SaaS
          |                 |                |
     Exchange           Resources       Third-party
     SharePoint         Applications    Applications
     Teams

Araştırmada Global Administrator impersonation’ın Entra ID objelerinin değiştirilmesinin yanında Exchange Online ve SharePoint Online gibi Entra ID authentication kullanan servislere erişimin genişletilmesine yol açabileceği belirtiliyor. Azure tarafında da Global Administrator’ın kendisine subscription seviyesinde yetki kazandırabileceği senaryolar değerlendiriliyor. Bu nedenle cloud identity dünyasında blast radius kavramını yeniden değerlendirmek gerekiyor.

Saldırının Belki de En Tehlikeli Tarafı: Görünürlük

Güvenlikte prevention kadar detection da önemlidir. Bir saldırıyı engelleyemediğimiz durumda en azından gerçekleştiğini görebilmek isteriz. Actor Token vakasında bunun da ciddi sınırları vardı.

Araştırmaya göre Actor Token istekleri kurban tenant’ta görünür bir kayıt bırakmıyordu. Legacy Azure AD Graph’ın API-level logging kapasitesi de son derece sınırlıydı. Bu nedenle directory üzerindeki bazı read operasyonlarının kurban tenant açısından kullanılabilir iz bırakmadan gerçekleştirilebilmesi söz konusuydu.

Tenant üzerinde değişiklik yapılmaya başlandığında audit log oluşması daha olasıydı. Ancak başka bir problem ortaya çıkıyordu: Loglarda yapılan işlem saldırgan yerine impersonate edilen meşru Global Administrator tarafından gerçekleştirilmiş gibi görünebilirdi. Bu da SOC ekipleri açısından önemli bir ders içeriyor.

Artık yalnızca: “İşlemi hangi kullanıcı yaptı?” sorusunu sormak yeterli olmayabilir. Aynı zamanda:“Bu kullanıcı bu işlemi hangi authentication context içerisinde yaptı?” ve “Bu işlem gerçekten kullanıcının interactive authentication’ından mı kaynaklandı?” sorularının da sorulması gerekiyor.

Conditional Access Her Şeyi Çözer mi?

Conditional Access, Entra ID’nin en güçlü güvenlik yeteneklerinden biri. Ancak Conditional Access’in neyi koruduğunu doğru anlamak gerekiyor. Actor Token vakasında araştırmacı açıkça Actor Token tabanlı impersonation mekanizmasının Conditional Access kısıtlamalarından etkilenmediğini belirtiyor. Dolayısıyla burada kabaca şöyle bir saldırı yolu oluşabiliyordu:

                  Normal Authentication

Attacker ───X─── Password
             X
             ├── MFA
             X
             ├── Conditional Access
             X
             └── Device Compliance


                  S2S / Actor Token

Attacker ───────────────► Actor Token
                               |
                               v
                         Impersonation
                               |
                               v
                         Target Resource

Bu vaka bize önemli bir şeyi hatırlatıyor: Identity Security yalnızca kullanıcı authentication güvenliği değildir.

Service Principal’lar Yeni Service Account’larımız

Active Directory ortamlarında yıllardır service account güvenliğini tartışıyoruz. Yetkileri fazla olan service account’lar, değişmeyen parolalar, SPN’ler ve delegation ayarları ciddi saldırı yüzeyi oluşturabiliyor.

Cloud dünyasında bunun karşılığında artık: Application Registrations, Service Principals, Managed Identities ve Workload Identities bulunuyor. Hatta bazı durumlarda bunların sahip olduğu yetkiler insan kullanıcıların yetkilerinden bile daha kritik olabilir.

Actor Token araştırmasında saldırganın uygulamalara credential ekleyebileceği, application permission’larını değiştirebileceği ve bu application identity’lerini Microsoft 365 verilerine erişmek amacıyla kullanabileceği senaryolar da değerlendiriliyor.

Bu nedenle artık sadece: “Global Admin kim?” diye sormak yeterli değil. Şunları da sormamız gerekiyor: Hangi Service Principal hangi API permission’larına sahip? Hangi uygulamalar tenant-wide yetkiye sahip? Application credential’larını kim yönetiyor? Hangi workload identity yüksek ayrıcalığa sahip?Kullanılmayan application registration ve service principal’lar kaldırılıyor mu? Modern identity governance’ın önemli bir bölümü artık insan olmayan kimliklerin yönetiminden oluşuyor.

Active Directory mi Daha Güvenli, Entra ID mi?

Buraya kadar anlattıklarımızdan: “Active Directory daha güvenlidir.” veya “Entra ID daha güvensizdir.” sonucunu çıkarmak doğru olmaz. Her iki mimarinin saldırı yüzeyi birbirinden farklıdır.

Entra ID’nin klasik AD’de aynı biçimde bulunmayan çok güçlü savunma mekanizmaları vardır:

Phishing-resistant MFA
Conditional Access
Identity Protection
Privileged Identity Management
Risk-based Authentication
Passwordless Authentication
Workload Identity Controls

Dolayısıyla mesele hangi platformun daha güvenli olduğundan çok, hangi platformun saldırı yüzeyini ne kadar iyi anladığımızdır.

Asıl Risk Hybrid Dönemde Ortaya Çıkıyor

Belki de kurumlar açısından en önemli konu burası. Gerçek hayatta Active Directory’den Entra ID’ye geçiş çoğunlukla şöyle gerçekleşmiyor:

Active Directory
       |
       X
       |
    Entra ID

Active Directory’yi kapatıp ertesi gün tamamen cloud-native identity modeline geçmiyoruz.

Bunun yerine çoğunlukla:

                         Identity
                            |
              +-------------+-------------+
              |                           |
       Active Directory                Entra ID
              |                           |
       Kerberos / NTLM                OAuth/OIDC
       LDAP / AD CS                   Tokens
       Delegation                     Applications
       Trusts                         Service Principals
              |                           |
              +-------------+-------------+
                            |
                      Microsoft 365
                       Azure / SaaS

gibi hybrid bir dünya ortaya çıkıyor. Ve burada önemli bir problem var. Eski saldırı yüzeyini kaldırmadan yenisini ekliyoruz. Domain Controller hala var. Kerberos hala var. NTLM belki hala var. AD CS hala var. Service account’lar hala var. Bunların yanına: OAuth token’ları, Service Principal’lar, Application egistration’lar, API permission’ları, Guest kullanıcılar, Workload Identity’ler, Microsoft Graph, Conditional Access, Federation ve SaaS trust ilişkileri ekleniyor. Bu durumda teknik olarak toplam saldırı yüzeyinin genişlemesi oldukça mümkün.

Shared Responsibility Model’i Unutmamak Gerekiyor

Active Directory ile Entra ID arasındaki en önemli farklardan biri de kontrol alanıdır. On-premises Active Directory’de altyapının önemli kısmı bizim sorumluluğumuzdadır. Entra ID’de ise platformun önemli bölümü Microsoft tarafından işletilir. Bu önemli avantajlar getirir. Ancak aynı zamanda güvenlik zincirinin bir bölümünün doğrudan bizim kontrolümüz dışında olması anlamına gelir. Actor Token vakası bunun iyi bir örneğidir.

Kurum:

• MFA’yı açmış olabilir,
• Conditional Access uygulamış olabilir,
• Global Administrator hesaplarını PIM ile yönetiyor olabilir,
• Kullanıcı cihazlarını compliant hale getirmiş olabilir.

Ancak zafiyet Microsoft’un backend servisleri arasındaki authentication mekanizması ile legacy Azure AD Graph’ın tenant validation davranışının birleşiminden kaynaklanıyordu. Müşterinin bunu kendi tenant konfigürasyonuyla tamamen ortadan kaldırması mümkün değildi. Cloud security’de Shared Responsibility Model tam olarak burada önem kazanıyor.

Microsoft Açığı Kapattı

Burada çok önemli bir ayrım yapmamız gerekiyor. CVE-2025-55241’i bugün aktif olarak kullanılabilecek bir Entra ID saldırı yöntemi gibi değerlendirmemek geekir. Araştırmacı zafiyeti Microsoft Security Response Center’a bildirdi.

Microsoft problemi kısa süre içerisinde kendi tarafında düzeltti, Actor Token’ların Azure AD Graph API için talep edilmesini engelleyen ek mitigasyonlar uyguladı ve zafiyeti CVE-2025-55241 olarak yayımladı.

Ayrıca Microsoft’un internal telemetry verilerine göre zafiyetin kötüye kullanıldığına dair bir bulgu tespit edilmediği aktarılıyor.

Dolayısıyla Actor Token vakasının bizim için asıl değeri bugün bu açığın nasıl exploit edileceği değil.

Asıl değer: Cloud identity sistemlerinin arkasındaki güven ilişkilerinin ne kadar karmaşık hale geldiğini göstermesi.

Sonuç: Saldırı Yüzeyi Küçülmüyor, Dönüşüyor

Active Directory’den Entra ID’ye geçişi yalnızca teknolojik bir migration projesi olarak görmek doğru değil. Bu aynı zamanda güven modelinin dönüşümü. Active Directory dünyasında:

Domain Controllers
Kerberos
NTLM
LDAP
AD CS
Delegation
Trusts
Service Accounts

konuşuyorduk.

Entra ID dünyasında ise:

OAuth / OIDC
Access Tokens
Refresh Tokens
Applications
Service Principals
API Permissions
Workload Identities
Microsoft Graph
Conditional Access
Service-to-Service Trust

konuşuyoruz. Dolayısıyla Active Directory’den Entra ID’ye geçtiğimizde saldırı yüzeyi basitçe küçülmüyor veya büyümüyor.

Saldırı yüzeyi dönüşüyor.

Ancak kurum Active Directory’yi kullanmaya devam ederken Entra ID, Microsoft 365, Azure, SaaS uygulamaları, workload identity’ler ve API tabanlı yetkilendirme mekanizmalarını da mevcut yapının üzerine ekliyorsa başka bir durum ortaya çıkıyor. Eski saldırı yüzeyi ortadan kalkmadan yeni saldırı yüzeyi ekleniyor. Bu nedenle özellikle hybrid yapılarda toplam saldırı yüzeyinin genişlemesi oldukça mümkün. Actor Token ve CVE-2025-55241 vakasının bize verdiği en önemli ders de belki burada yatıyor.

Modern identity security yaklaşımında artık sadece: “Kullanıcı sisteme nasıl giriş yapıyor?” sorusunu soramayız.
Bunun yanında:
“Tenant içerisinde hangi kullanıcı, uygulama veya servis kimin adına hareket edebilir?”

“Hangi token hangi kaynağa erişebilir?”

“Hangi Service Principal hangi yetkiye sahip?”

“Bir authentication işlemi gerçekleşmeden kaynaklara erişmenin başka yolları var mı?”

“Bunların tamamını gerçekten loglayabiliyor ve izleyebiliyor muyuz?”

sorularına da cevap vermemiz gerekiyor. Cloud’a geçiş Domain Controller sayısını azaltabilir. NTLM veya geleneksel authentication bağımlılığımızı düşürebilir. Modern authentication ve phishing-resistant MFA sayesinde bazı saldırıları çok daha zor hale getirebilir. Ancak cloud’a geçmek tek başına güvenli olmak anlamına gelmez.

Saldırganlar da bizimle birlikte cloud’a taşınıyor. Bu nedenle Active Directory’den Entra ID’ye geçerken sormamız gereken asıl soru belki de şudur: Active Directory’den kurtulmaya mı çalışıyoruz, yoksa Active Directory’de yıllar içinde öğrendiğimiz güvenlik derslerini yeni cloud identity mimarisine gerçekten taşıyor muyuz?