Protected Users, Credential Guard ve MFA: Koruma kapsamı ve sınırları.

1. Core Mechanism / Temel mekanizma

Kimlik bilgisi korumasını tek bir anahtar gibi düşünmek, en sık görülen tasarım hatasıdır. Doğru soru “korunuyor muyuz?” değil, “hangi kontrol, hangi makinede, hangi protokol anında, hangi secret için devrede?” sorusudur. Protected Users grubu hem üyenin oturum açtığı istemcide hem de domain controller tarafında davranış değiştirir ve etkisinin bir kısmı domain functional level'a bağlıdır. Credential Guard yerel bir platform kontrolüdür: LSA sırlarını izole eder, fakat dizinin kendisini veya kullanıcının zaten açık oturumunu korumaz. MFA cloud veya federated sign-in akışında değerlendirilir; on-premises Kerberos veya NTLM el sıkışmasının içine girmez. Üç kontrol de gerçek ve değerlidir, ama kapsamları birbirinin yerine geçmez.

Arabirimler ve belirtimler

• Protected Users: Active Directory'de tanımlı bir global security group. Üyelik, üyenin oturum açtığı Windows cihazında istemci tarafı kısıtlamalar; domain functional level Windows Server 2012 R2 veya daha yeni olduğunda ise domain controller tarafında ek kısıtlamalar doğurur.
• Protected Users istemci tarafı: desteklenen Windows üzerinde NTOWF, uzun ömürlü Kerberos key ve offline logon verifier önbelleklenmez; CredSSP/WDigest plaintext credential caching engellenir. DC tarafındaki protokol kısıtlamalarının DFL koşulu ayrıdır.
• Protected Users domain tarafı: üyeler NTLM ile kimlik doğrulayamaz, Kerberos ön kimlik doğrulamasında DES veya RC4 kullanamaz, delegation (constrained ve unconstrained) ile devredilemez ve başlangıç TGT ömrü yenilenemez biçimde kısaltılır.
• Credential Guard: Windows platform kontrolü. Virtualization-based security kullanarak LSA sırlarını yalıtılmış bir süreçte tutar; hedefi NTLM parola hash'i, Kerberos TGT ve domain kimlik bilgilerinin işletim sisteminden çıkarılmasını engellemektir.
• Credential Guard'ın kapsam dışı bıraktıkları: Active Directory veritabanının kendisi, yerel hesaplar ve Microsoft hesapları, üçüncü taraf authentication package'lar ve cihaza fiziksel erişim veya tuş kaydı gibi saldırı sınıfları.
• MFA: Microsoft Entra ID tarafında sign-in sırasında ikinci bir doğrulama faktörü isteyen kontrol. Token verme kararını etkiler; domain içi Kerberos bilet alışverişine veya NTLM oturumuna ek faktör enjekte etmez.

Üç kontrol, üç ayrı sınır

Protected Users bir grup üyeliğidir, ama etkisi tipik bir grup üyeliğine benzemez. Normal bir grup bir kaynağa erişim verir; Protected Users ise tam tersine, hesabın kullanabileceği kimlik doğrulama yollarını daraltır. Bu daraltmanın bir bölümü üyenin oturum açtığı cihazda, bir bölümü ise domain controller'da uygulanır. Dolayısıyla “kullanıcıyı gruba ekledik” cümlesi tek başına korumanın tamamını anlatmaz: istemcinin işletim sistemi sürümü ve domain functional level, hangi kısıtlamaların gerçekten devrede olduğunu belirler.

Credential Guard'ın sınırı ise makinedir. Koruma, o cihazdaki LSA sırlarının yalıtılmasıdır. Bu, bir saldırganın yönetici haklarıyla bellekten hash veya bilet çıkarma girişimini zorlaştırır. Ama saldırganın zaten o cihazda yetkili bir oturumun içindeyse, o oturumun ayrıcalığını kullanmasını engellemek Credential Guard'ın işi değildir. Koruma secret'ın dışarı taşınmasına odaklıdır, secret'ın yerinde kullanılmasına değil.

MFA'nın sınırı protokoldür. Entra ID'nin sign-in akışında ek faktör sorulması, aynı kullanıcının on-premises bir dosya sunucusuna SMB ile bağlanırken ek faktör göreceği anlamına gelmez; o yolda değerlendirme yapan bileşen Entra ID değildir. Bu yüzden MFA, cloud uygulama erişimi için güçlü bir kontroldür ve iç ağ yanal hareketi için doğrudan bir kontrol değildir.

Kapsam haritasını üç eksende yaz

Bir ortamda bu üç kontrolün ne yaptığını anlamanın pratik yolu, her kontrolü üç eksende yazmaktır: nerede uygulanır, hangi secret veya karar için geçerlidir, hangi koşul sağlanmazsa sessizce etkisiz kalır. Protected Users için üçüncü eksen domain functional level ve istemci sürümüdür. Credential Guard için donanım ve virtualization-based security gereksinimleridir. MFA için ise erişim yolunun gerçekten Entra ID üzerinden geçip geçmediğidir.

Bu tablo doldurulduğunda, üç kontrolün aynı riski farklı taraflardan azalttığı, ama hiçbirinin diğerinin yerini tutmadığı görülür. Protected Users bir hesabın zayıf protokollerle doğrulanmasını engeller; Credential Guard o hesabın kimlik bilgisinin bir cihazdan çalınmasını zorlaştırır; MFA ise çalınmış bir parolanın tek başına cloud erişimi için yetmemesini sağlar.

Koruma, uyumluluk maliyeti üretir

Protected Users üyeliği, NTLM'e veya RC4'e bağlı bir uygulamanın o hesapla çalışmasını durdurur. Bu bir hata değil, kontrolün tanımıdır. Microsoft bu nedenle grubu kademeli ve test edilerek uygulamayı, servis ve bilgisayar hesaplarını eklememeyi önerir: bu hesaplar için üyelik beklenmeyen kesintilere yol açar.

Credential Guard da benzer şekilde bazı eski kimlik doğrulama yollarıyla birlikte çalışmaz; Microsoft bunları ayrı bir uyumluluk listesinde sayar. Bu yüzden her iki kontrol de güvenlik kazancı kadar, envanterdeki eski protokol bağımlılığının önce bulunmasını gerektirir. Kontrolü açıp kesintiyi beklemek yerine, hangi hesabın hangi protokole bağlı olduğu önceden çıkarılır.

Durum ve veri akışı

1. Üyelik ve desteklenen client koşulunu karşılaştır: NTOWF/long-term key/offline verifier ve CredSSP/WDigest plaintext cache yok. Bu, DFL koşullu DC kısıtlamalarından ayrıdır.
2. Domain functional level Windows Server 2012 R2 veya daha yeni ise domain controller tarafı da devreye girer: üye NTLM ile doğrulanamaz, delegation ile devredilemez ve aldığı başlangıç TGT'si yenilenemez biçimde kısa ömürlüdür.
3. Aynı hesap Credential Guard etkin bir cihazda oturum açtığında, elde edilen Kerberos ve NTLM secret'ları yalıtılmış LSA sürecinde tutulur; işletim sisteminden çıkarılmaları engellenmeye çalışılır.
4. Kullanıcı bir cloud uygulamasına eriştiğinde MFA değerlendirmesi Entra ID sign-in akışında yapılır. Aynı kullanıcının domain içi Kerberos bilet talebi bu akıştan geçmez ve ek faktör sorulmaz.
5. 4768 alanlarını ayır: TicketEncryptionType TGT şifrelemesi, PreAuthType yöntemdir. Bu Version0 kesitinde PreAuthEncryptionType ve üyelik kanıtı yok. Client, DFL, üyelik ve protokol kısıtlamalarını ayrıca doğrula.

2. Exploitation / İstismar

Broken trust assumption

“Protected Users'a ekledik, Credential Guard açık ve MFA zorunlu; artık kimlik bilgisi hırsızlığı bizim için çözülmüş bir konu” varsayımı. Buradan da üç kontrolün birbirini tamamlayarak bütün yolları kapattığı, dolayısıyla ayrıcalıklı hesapların hangi cihazda kullanıldığının, hangi protokolün açık kaldığının ve hangi oturumun hâlâ canlı olduğunun ikincil bir ayrıntı olduğu sonucuna varılır.

Technical prerequisites

• Protected Users üyeliği yapılmış, ancak domain functional level ve istemci işletim sistemi sürümü doğrulanmamıştır; hangi kısıtlamanın gerçekten uygulandığı bilinmez.
• Credential Guard “etkin” olarak raporlanır, fakat hangi cihazlarda gerçekten çalıştığı ve ayrıcalıklı hesapların yalnız bu cihazlarda kullanılıp kullanılmadığı izlenmez.
• MFA politikası cloud sign-in için tanımlıdır; aynı hesabın on-premises kaynaklara eriştiği yollar aynı politika kapsamında sanılır.
• Ayrıcalıklı hesapların hangi sunucularda interaktif oturum açtığı ve bu oturumların ne kadar süre canlı kaldığı düzenli olarak gözden geçirilmez.

Exploitation mechanism / İstismar mekanizması

Yanlış güvenin mekanizması kapsam kaymasıdır. Protected Users'ın domain tarafı kısıtlamaları domain functional level koşuluna bağlıdır; bu koşul sağlanmazsa üyelik grubu vardır, ama beklenen kısıtlamaların bir bölümü yoktur. Credential Guard ise tasarımı gereği “secret çıkarma” sınıfına odaklanır; Microsoft belgeleri bu korumanın Active Directory veritabanını, yerel hesapları ve fiziksel erişim ya da tuş kaydı gibi saldırı sınıflarını kapsamadığını açıkça söyler. Yani kimlik bilgisi bellekten çıkarılamasa bile, aynı cihazda halihazırda açık bir ayrıcalıklı oturum varsa o oturumun ayrıcalığı kullanılabilir. MFA'nın kapsam kayması en belirgin olandır: ek faktör, token veren tarafın sign-in kararında istenir. Bir hesabın parolası ele geçtiğinde cloud erişimi engellenebilir, ama aynı kimlik bilgisiyle iç ağda Kerberos üzerinden erişilebilen kaynaklar bu karardan geçmez. Üç kontrolün birleşik etkisi, ancak ayrıcalıklı hesap kullanım yüzeyi gerçekten daraltıldığında beklenen seviyeye yaklaşır; kontroller açıldığı için değil.

Koşullu koruma, koşul doğrulanmazsa koruma değildir

Protected Users'ın en kritik özelliği, etkisinin iki tarafa bölünmüş olmasıdır. İstemci tarafı kısıtlamalar desteklenen Windows sürümlerinde üyenin oturum açtığı cihazda uygulanır. Domain tarafı kısıtlamalar ise domain functional level Windows Server 2012 R2 veya daha yeni olduğunda uygulanır. Bu ayrım belgelenmiştir ve bir denetimde ilk doğrulanması gereken şeydir.

Pratikte sık görülen tablo şudur: grup oluşturulmuş, ayrıcalıklı hesaplar eklenmiş, ancak ortamda hâlâ eski bir functional level kullanılıyor veya bazı yönetim istasyonları eski bir istemci sürümünde. Sonuç, denetim raporunda yeşil görünen ama gerçekte kısmi olan bir kontroldür. Bu ders bir istismar yöntemi anlatmaz; anlatılan şey, kontrol kapsamının yazılı koşullarının her denetimde ayrı ayrı doğrulanması gerektiğidir.

Secret korunur, oturum korunmaz

Credential Guard'ın hedefi kimlik bilgisinin cihazdan çıkarılmasını engellemektir. Bu, kimlik bilgisi hırsızlığına dayanan birçok yanal hareket tekniğini pahalılaştırır. Ancak Microsoft'un kendi belgeleri korumanın sınırlarını açıkça listeler: Active Directory veritabanı, yerel hesaplar ve Microsoft hesapları, üçüncü taraf authentication package'lar ve fiziksel erişim ya da tuş kaydı bu kapsamın dışındadır.

Bundan çıkan savunma dersi nettir: ayrıcalıklı bir hesabın güvenliği, o hesabın hangi cihazlarda kullanıldığından bağımsız düşünülemez. Tier ayrımı, ayrıcalıklı erişim iş istasyonları ve oturum süresi kısıtları, platform kontrolünün yerine geçen değil onu anlamlı kılan uygulamalardır.

Ek faktör, protokol sınırını aşmaz

MFA'nın değerlendirildiği yer, token veren tarafın sign-in akışıdır. Bu nedenle “MFA zorunlu” ifadesi her zaman bir kapsam cümlesiyle birlikte yazılmalıdır: hangi uygulamalar, hangi sign-in yolu, hangi koşullar. Kapsam cümlesi olmadan ifade, ortamın tamamını kapsıyormuş gibi okunur.

Hibrit ortamlarda bu kayma özellikle tehlikelidir, çünkü aynı kullanıcı adı iki farklı erişim yolunda görünür. Cloud tarafında ek faktör sorulurken, aynı kimliğin on-premises Kerberos yolu bu kararın dışındadır. Risk analizinde iki yol ayrı satır olarak tutulmalı ve her satır için hangi kontrolün devrede olduğu yazılmalıdır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Protected Users üyeliğini üç bilgiyle birlikte kaydet: üye listesi, domain functional level ve üyelerin oturum açtığı istemcilerin işletim sistemi sürümleri. Üçü yazılmadan kontrolün kapsamı belirsizdir.
• Servis hesaplarının ve bilgisayar hesaplarının Protected Users içinde bulunmadığını doğrula; bu hesaplar için üyelik beklenmeyen kesinti üretir ve önerilmez.
• Credential Guard durumunu cihaz envanterinde bir alan olarak tut ve ayrıcalıklı hesapların yalnız bu cihazlarda kullanıldığını ayrı bir kontrol olarak izle.
• MFA politikasının kapsamını uygulama ve sign-in yolu düzeyinde listele; kapsam dışındaki erişim yollarını aynı belgede açıkça yaz.
• Kerberos ön kimlik doğrulama şifreleme türlerini DC olaylarından örnekle; Protected Users üyeleri için RC4 beklenmez, AES beklenir.
• Grup üyeliği değişikliklerini dizin denetimiyle izle: Protected Users'tan çıkarma işlemi, korumanın sessizce kalkması anlamına gelir.

Events and relevant fields

• Protected Users üyeliğinin tek başına varlığı koruma kanıtı değildir; domain functional level koşulu sağlanmıyorsa domain tarafı kısıtlamalar uygulanmaz.
• Bir hesabın Kerberos biletini AES ile alması tek başına Protected Users üyeliğini kanıtlamaz; AES, üye olmayan hesaplar için de varsayılan olarak kullanılabilir.
• Credential Guard etkin bir cihazda yaşanan bir olay, kimlik bilgisinin çalınmadığını kanıtlamaz; koruma dışı kalan saldırı sınıfları belgelenmiştir.
• Cloud tarafında MFA ile tamamlanmış bir sign-in, aynı kullanıcının on-premises kaynaklara erişiminin ek faktörle korunduğunu göstermez.
• NTLM yolunun bir hesap için reddedilmesi, uygulama tarafında genellikle genel bir kimlik doğrulama hatası olarak görünür; kök neden kontrol kapsamında aranmalıdır.

Kontrol kaydını koşullarıyla birlikte tut

Denetim belgelerinde en çok hata üreten alan, kontrolün ikili durumu olarak yazılmasıdır. “Protected Users uygulandı” satırı, hangi kısıtlamaların gerçekten devrede olduğunu söylemez. Aynı satır “domain functional level 2012 R2, istemciler desteklenen sürümde, üyeler yalnız insan ayrıcalıklı hesapları” biçiminde yazıldığında denetlenebilir hale gelir.

Aynı yaklaşım diğer iki kontrol için de geçerlidir. Credential Guard satırı hangi cihaz grubunda etkin olduğunu, MFA satırı hangi erişim yollarını kapsadığını içermelidir. Bu ayrıntı yazılmadığında, bir olay incelemesinde kontrolün beklenen etkiyi neden göstermediği sorusu cevapsız kalır.

Telemetriyi kontrolün uygulandığı yerden topla

Protected Users'ın domain tarafı etkisi domain controller'da, istemci tarafı etkisi ise üyenin oturum açtığı cihazda görünür. Dolayısıyla tek bir kaynaktan bakmak yanıltıcıdır. Kerberos kimlik doğrulama hizmeti olayları DC'de aranır; oturum oluşumuna ilişkin kayıtlar oturumun açıldığı makinede aranır.

Bu ayrım, olay incelemesinde kanıt zincirini doğru kurmanın temelidir. Bir kontrolün beklenen etkiyi göstermediği iddia edildiğinde, önce doğru kaynağa bakılıp bakılmadığı sorulmalıdır. İlgili denetim alt kategorisi etkin değilse, olayın yokluğu davranışın yokluğu anlamına gelmez.

Detection logic · XPath

<QueryList><Query Id="0" Path="Security"><Select Path="Security">*[System[EventID=4768] and EventData[Data[@Name='TargetUserName']='arin.demir']]</Select></Query></QueryList>

Query assumptions

• Bu XPath yalnız biçim örneğidir ve bu oturumda hiçbir Windows sisteminde çalıştırılmamıştır; EventID ve TargetUserName koşulları aynı event-node selector içindedir. Alan adları olay sürümüne göre değişebilir.
• Sorgu domain controller'ın Security kanalını hedefler; Kerberos kimlik doğrulama hizmeti olayları istemcide değil DC'de kaydedilir.
• Olayların görünmesi için ilgili denetim alt kategorisinin etkin olması gerekir; sorgunun sonuç döndürmemesi kimlik doğrulamanın gerçekleşmediği anlamına gelmez.
• TicketEncryptionType alanının yorumu belgeye göre yapılmalıdır; bu sorgu şifreleme türünü kendiliğinden sınıflandırmaz.
• arin.demir kurgusal bir insan kullanıcı hesabı adıdır; isim Protected Users üyeliğini kanıtlamaz. Bu Version 0 kesitinde TicketEncryptionType, TGT’nin şifreleme türünü; PreAuthType=2 ise pre-authentication yöntemini gösterir, onun şifreleme türünü değil. Güncellenen Version 2 olayında ayrı PreAuthEncryptionType alanı vardır; bunu eski iki alandan çıkarma.

False positives

• Aynı hesap adı farklı bağlamlarda kullanılıyorsa, dönen olaylar tek bir kullanıcı etkinliğine ait olmayabilir.
• Yenileme ve servis bileti talepleri de aynı hesap adıyla görünür; tek bir olay satırı oturum başlangıcı anlamına gelmez.
• Negatif örnek: Protected Users üyesi olmayan bir hesap da AES ile ön kimlik doğrulama yapabilir; şifreleme türü tek başına üyelik kanıtı değildir.
• Birden çok DC bulunan ortamda sorgu yalnız çalıştırıldığı DC'nin kaydını görür; eksik sonuç, olayın hiç oluşmadığı anlamına gelmez.

Hardening

• Protected Users'ı önce küçük ve iyi bilinen bir ayrıcalıklı hesap kümesinde uygula; her dalgada hangi uygulamanın hangi protokole bağlı olduğunu kaydet.
• Domain functional level koşulunu kontrol kaydının içine yaz; koşul sağlanmıyorsa kontrolü kısmi olarak işaretle.
• Servis ve bilgisayar hesaplarını Protected Users dışında tut; bu hesaplar için ayrı sertleştirme yolları kullan.
• Ayrıcalıklı hesapların kullanımını Credential Guard etkin, yönetilen ve sınırlı sayıda cihazla kısıtla; cihaz listesini envanterde izlenebilir tut.
• MFA kapsam belgesini erişim yolu bazında yaz; kapsam dışındaki on-premises yollar için ayrı telafi edici kontrol tanımla.
• Üç kontrolün durumunu tek bir “korunuyor” bayrağına indirgeme; her kontrol için ayrı kapsam, ayrı koşul ve ayrı kanıt satırı tut.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4768</EventID><Version>0</Version><Level>0</Level><Task>14339</Task><TimeCreated SystemTime="2026-10-01T07:41:52.0000000Z"/><EventRecordID>1405001</EventRecordID><Channel>Security</Channel><Computer>dc02.outreason.example</Computer><Security/></System><EventData><Data Name="TargetUserName">arin.demir</Data><Data Name="TargetDomainName">OUTREASON.EXAMPLE</Data><Data Name="ServiceName">krbtgt</Data><Data Name="TicketEncryptionType">0x12</Data><Data Name="PreAuthType">2</Data><Data Name="Status">0x0</Data><Data Name="IpAddress">::ffff:198.51.100.37</Data><Data Name="IpPort">51344</Data></EventData></Event>

İki yanlış kanı / Two reality checks

Sanılan: Hesapları Protected Users grubuna eklemek, o hesapların kimlik bilgisi hırsızlığına karşı korunduğu anlamına gelir.

Gerçekte: Üyelik koşulludur: desteklenen client NTOWF/long-term key/offline verifier ile CredSSP/WDigest plaintext caching’i kısıtlar. DC-side NTLM/DES-RC4 pre-auth/delegation/TGT kısıtlamaları Windows Server2012R2+ DFL koşuluna bağlıdır. Üyelik, client ve DFL ayrı doğrulanır; servis/computer hesaplarının üyeliği önerilmez.

Sanılan: Credential Guard açıksa kimlik bilgileri çalınamaz, MFA zorunluysa çalınan bir parola zaten işe yaramaz.

Gerçekte: İkisi de koşullu doğrudur. Credential Guard, virtualization-based security ile LSA sırlarını yalıtarak kimlik bilgilerinin işletim sisteminden çıkarılmasını hedefler; Microsoft bu korumanın Active Directory veritabanını, yerel hesapları ve Microsoft hesaplarını, üçüncü taraf authentication package'ları ve fiziksel erişim ya da tuş kaydı gibi saldırı sınıflarını kapsamadığını belirtir. MFA ise Entra ID sign-in akışında değerlendirilir; on-premises Kerberos veya NTLM ile erişilen kaynaklar bu karardan geçmez. Dolayısıyla iki kontrol de gerçek kazanç sağlar, ama ayrıcalıklı erişim yüzeyini daraltmanın yerine geçmez.

Kaynaklar / Sources

• Microsoft · Protected Users Security Group
  Protected Users istemci tarafı kısıtlamaları (NTLM, CredSSP/WDigest düz metin önbelleği, DES/RC4 ön kimlik doğrulama ve çevrimdışı oturum açma), Windows Server 2012 R2 veya daha yeni domain functional level koşulunda geçerli domain tarafı kısıtlamaları (NTLM reddi, delegation yasağı ve kısaltılmış yenilenemez TGT) ve servis/bilgisayar hesapları için uyarı.
• Microsoft · Credential Guard overview
  Virtualization-based security ile LSA sırlarının yalıtılması ve korunan kimlik bilgisi türleri.
• Microsoft · Credential Guard protection limits
  Credential Guard'ın korumadığı alanlar: Active Directory veritabanı, yerel hesaplar ve Microsoft hesapları, üçüncü taraf authentication package'lar, fiziksel erişim ve tuş kaydı gibi saldırı sınıfları.
• Microsoft · How Microsoft Entra multifactor authentication works
  Ek doğrulama faktörünün Entra ID sign-in akışında istenmesi ve MFA'nın sign-in kararına bağlı olarak değerlendirilmesi.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  EventData alanları: TargetUserName, ServiceName, TicketEncryptionType, PreAuthType, Status, IpAddress; olayın domain controller'da kaydedilmesi.
• Microsoft · Consuming Events (Windows Event Log)
  Windows Event Log XPath alt kümesi; tek Select ifadesinde event-node selector ve aynı olay alanlarına uygulanan birleşik predicates.