Windows Server 2016 ve Windows 10 1607 sürümünden sonra hayatımıza giren WDRCG özelliği temel olarak RDP oturumlarından yetkili hesaplara ait parolaların çalınmasını engellemektedir. Aslında Server 2012 R2 ve Windows 8.1 ile tanıştığımız Restricted Admin Mode for RDP’ ye çok benziyor, ama en temel özelliği şifre tamamen istemcide tutuluyor ve sunucu tarafından tutulmamasına karşın SSO desteği sunuyor.
Daha anlaşılır olması için aşağıdaki şekilleri inceleyebiliriz.
Yukarıda standart bir RDP bağlantısını görüyorsunuz. En büyük sorun kimlik bilgilerinin karşı sunucuda saklanması. Bu sayede bir şekilde bu sunucu ele geçirilmiş ise yönetici parolaları da ele geçirilecek demektir.
Peki Windows Defender Remote Credential Guard olursa neler oluyor? Gördüğünüz gibi kimlik bilgisi artık karşı sunucuda değil, diğer sistemlere bağlanırken makine hesabı değil kullanıcı hesabı kullanabildiği için SSO çalışıyor.
Peki bu resimlere daha teknik olarak bakalım. Yani tam olarak bu 3 modeli teknik olarak inceleyecek olursak aşağıdaki gibi bir tablo karşımıza çıkıyor.
Peki nedir bu başlıklar?
Koruma Noktasında Faydalar?
RD çözümünde kimlik bilgisi uzak sunucuda olduğu için her türlü atağa açıktır. Defender tarafında kesinlikle kimlik bilgisi uzak sunucuda olmadığı için atağa karşı koruma sağlar. Restricted Mode ise, hedef sunucuda bir local administrators gibi açıldığı için gelecek atak sadece o makine local hesapları için geçerli olup domain hesabını etkilemez.
Peki bu üç çözüm her OS için destekleniyor mu?
RD malum her Microsoft OS sürümü için uzun yıllardır kullandığımız bir sürüm. Ancak Defender için Windows 10 1607 ve Server 2016 olması gerekli. Restricted Mode ise en güncel Windows 7, 2008 R2 OS tarafından destekleniyor. Ancak bu iki OS artık desteklenmediği için pek bir anlamı yok.
Peki hangi atak tipleri içi koruma sağlarlar?
Ne yazık ki RD için bir koruma söz konusu değil.
Defender için;
· Pass-the-Hash
· Use of a credential after disconnection
Restricted Mode için
· Pass-the-Hash
· Use of domain identity during connection
Peki istemci tarafında hangi kimlik bilgilerini destekliyorlar?
Remote Desktop, Signed on credentials, Supplied credentials ve Saved credentials. Defender ise sadece Signed on credentials. Restricted mode ise Signed on credentials, Supplied credentials ve Saved credentials desteklemektedir.
Peki bir önemli konu, bu çözümü kimler kullanabilir? Yani sadece yönetici hesapları mı yoksa tüm domain users ya da normal kullanıcılar mı? Malum bu da önemli bir ayrım.
Remote Desktop yine tahmin edebileceğiniz gibi hem kullanıcılar hem yöneticiler kullanabilir. Defender da aynı şekilde normal kullanıcılar tarafından da kullanılabilir. Ancak Restricted Mode adın üstünde sadece ilgili hedef sunucunun local admin grubuna dahil olan yani yöneticiler için sunulmuş bir çözümdür.
Bir diğer konu ise SSO. Yani siz bu 3 yöntemden herhangi birisi ile HakanUzunerPC’ den CozumParkServer’ a bağlandıktan sonra FilServer’ a bağlanmak istediğiniz zaman kimin kimlik bilgisi ile bu sunucuya erişeceksiniz?
Normal RDP oturumları ve Defender için bu “Hakan” kullanıcısı oluyor, aslında normal davranış bu. Ancak Restricted Admin mode burada “CozumParkServer” yani uzak makine kimlik bilgisini kullandığı için SSO çalışmamaktadır.
Benzer şekilde bu nedenle Restricted Admin Mode için bir sunucudan diğerine de RDP ile bağlantı yapamıyorsunuz.
Son olarak ise desteklenen authentication yani kimlik doğrulama protokolü olarak, Remote Desktop ve Restricted Admin Mode tüm protokolleri desteklerken, Defender sadece Kerberos desteklemektedir.
Öncelikle eğer bir sistem admini bir son kullanıcı makinesine bağlanacak ise önerilen yöntem Restricted Admin Mode’ dur. Çünkü bağlanılan makine önceden ele geçirilmiş ise ve siz Windows Defender Credential Guard senaryosu ile bağlanırsanız saldırganın hâlihazırda kontrol ettiği, güvenliği ihlal edilmiş bir istemciye bir RDP oturumu başlatılırsa, saldırgan bu açık kanalı kullanıcı adına oturumlar oluşturmak için kullanabilir.
Peki nasıl kullanıyoruz?
Öncelikle remote host için Restricted Admin veya Windows Defender Remote Credential Guard açmamız gerekli.
Bunun için aşağıdaki komut setini kullanabilirsiniz
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD
Daha sonra uzak sunucuya bağlanacak bilgisayarlar için GPO ayarı yapmamız gerekli.
Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.
Burada 3 tane seçenek sunulmaktadır.
Restrict Credential Delegation: Öncelikle Windows Defender Remote Credential Guard yöntemi ile bağlanmayı dener, ama bağlanamaz ise ve destekleniyor ise Restricted Admin mode ile bağlanır.
Require Remote Credential Guard: Bu durumda ise karşı taraf “Windows Defender Remote Credential Guard” gereksinimlerini sağlıyor ise bağlantı yapar, sağlamıyor ise bağlantı gerçekleşmez.
Require Restricted Admin: Eğer amacınız karış tarafa bağlanırken Restricted Admin Mode ise bu seçeneği seçebilirsiniz.
Bu konuda daha fazla bilgi için aşağıdaki makalemi inceleyebilirsiniz.
https://www.hakanuzuner.com/restricted-admin-mode-for-rdp-remote-desktop-connection
Eğer tüm bağlandığınız uzak sunucularda Windows Defender Remote Credential Guard yok ise bu durumda GPO yerine aşağıdaki gibi bağlanırken ilgili parametreyi yazmayı unutmayın.
mstsc.exe /remoteGuard
Gelelim son notlara;
Windows Defender Remote Credential Guard, bileşik kimlik doğrulamayı desteklemez. Örneğin, bir cihaz talebi gerektiren uzak bir ana bilgisayardan bir dosya sunucusuna erişmeye çalışıyorsanız, erişim reddedilecektir. (Detay için device claim başlığına bakın. Yeni nesil kimlik doğrulama gerektiren bir ortam ise bu konuda biraz uzman olmanız gerekli.)
Windows Defender Remote Credential Guard, Azure sanal makineleri (VM’ler) olarak çalışan AD etki alanına katılmış sunucular da dahil olmak üzere yalnızca bir Windows Server Active Directory etki alanına katılmış bir cihaza bağlanırken kullanılabilir. Windows Defender Remote Credential Guard, Azure Active Directory’ye katılmış uzak cihazlara bağlanırken kullanılamaz.
Remote Desktop Credential Guard yalnızca RDP protokolüyle çalışır.
Hedef cihaza kimlik bilgileri gönderilmez, ancak hedef cihaz yine de Kerberos Hizmet Biletlerini kendi başına alır.
Sunucu ve istemci, Kerberos kullanarak kimlik doğrulaması yapmalıdır.
Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.
Kaynak