Grup Tarafından Yönetilen Hizmet Hesaplarının Kötüye Kullanılması ve Güvenliğinin Sağlanması

Grup Tarafından Yönetilen Hizmet Hesaplarına Genel Bakış

Normal kullanıcı hesaplarını hizmet hesapları olarak kullanma şeklindeki geleneksel uygulama, şifre yönetimi yükünü kullanıcılara yüklemektedir. Sonuç olarak, hesap şifreleri genellikle yıllarca aynı kalır; bu da onları kaba kuvvet saldırılarına ve kötüye kullanıma karşı oldukça savunmasız bırakır. Grup tarafından yönetilen hizmet hesapları (gMSA'lar), otomatik görevleri, hizmetleri ve uygulamaları çalıştırmanın daha güvenli bir yolunu sunar.

gMSA, Windows Server 2016'da tanıtıldı ve Windows Server 2012 ve üzeri sürümlerde kullanılabilir. gMSA şifreleri tamamen Windows tarafından yönetilir: Rastgele oluşturulur ve otomatik olarak döndürülürler. Ayrıca, hizmet hesaplarının kendisi çalışma zamanında Active Directory'den parola bilgilerini sorgulayacak sunucuya 'yüklü' olduğundan, parolaların herhangi bir kullanıcı tarafından bilinmesine gerek yoktur. Sonuç olarak gMSA'lar, hizmet hesapları olarak kullanılan kullanıcı hesaplarına kıyasla kötüye kullanım ve tehlikeye karşı çok daha az hassastır.

Grup Tarafından Yönetilen Hizmet Hesabı Güvenliği

gMSA'lar Active Directory'deki belirli bir nesne türüdür: msDS-GroupManagedServiceAccount. Bu nesnelerin, şifreleri ve dönüşleriyle ilgili olarak kendileriyle ilişkilendirilmiş özel nitelikleri vardır. LAPS'ye benzer şekilde, gMSA özelliklerinin yalnızca bunlara erişmesi gereken Active Directory nesnelerine kilitlendiğinden emin olmak isteyeceksiniz.

gMSA Nitelikleri ve İzinleri

gMSA'lar aşağıdaki özelliklere sahiptir:

  • msDS-ManagedPassword— gMSA şifresini içeren bir BLOB
  • msDS-ManagedPasswordID— Geçerli gMSA şifresini oluşturmak için kullanılan anahtar kimliği
  • msDS-ManagedPasswordPreciousID— Önceki gMSA şifresini oluşturmak için kullanılan anahtar kimliği
  • msDS-GroupMSAMembership— gMSA şifresini sorgulama izni olan nesnelerin listesi
  • msDS-ManagedPasswordInterval— Parolanın değiştirildiği aralık (gün)

Parola bilgileri msDS-ManagedPassword özelliğinde saklandığından, ortamınızda kimlerin parolayı sorgulayabildiğini kesinlikle bilmek isteyeceksiniz. Bu bilgiler msDS-GroupMSAMembership özniteliğinde ayarlanır.

Ancak Active Directory izinleri devreye girdiğinden, bu özellikten biraz daha karmaşıktır. Herhangi bir nedenle bir kullanıcı veya nesne, msDS-GroupMSAMembership hesabı aracılığıyla parolayı sorgulama izinlerine sahip olacak şekilde yapılandırılmışsa, yine de gMSA'nın msDS-ManagedPassword özniteliğine yönelik 'Okuma' izinlerine sahip olmaları gerekir.

Bu, gMSA şifrelerini güvence altına almanın iki yolu olduğu anlamına gelir:

  • Yalnızca gerekli nesnelerin parolayı sorgulama iznine sahip olduğundan ve bunların msDS-GroupMSAMembership'te mevcut olduğundan emin olun
  • Yalnızca erişime ihtiyacı olan yönetici kullanıcıların ve gMSA'ların yüklü olduğu bilgisayar hesaplarının özniteliği okuma iznine sahip olduğundan emin olun. Ayrıca gMSA'yı ve özniteliklerini değiştirme yeteneğine yalnızca yöneticilerin sahip olduğundan emin olun; böylece hiç kimse msDS-GroupMSAMembership özniteliğine kendisini ekleyemez.

İdeal olarak, bir saldırganın yukarıdaki senaryolardan birinden yararlanma seçeneğine sahip olmasını engellemek için gMSA'ları her iki yolla da kilitlersiniz. Aşağıda, bir gMSA'da yanlış yönetilen izinlerin veya yapılandırmaların, hesabın ele geçirilmesine ve ayrıcalık artışına veya yatay harekete nasıl yol açabileceğini göstereceğiz.

gMSA şifresini kötüye kullanmak

Bir gMSA'nın kötüye kullanılması kavramsal olarak nispeten basittir. Öncelikle Mimikatz gibi bir araç kullanarak veya Active Directory'deki güvenli olmayan yapılandırmalardan dolayı doğrudan sorgulayarak şifresini alın. gMSA'lar hizmet hesapları olduğundan genellikle nispeten ayrıcalıklıdırlar, dolayısıyla genellikle yanlara doğru hareket edebilir veya üst kademeye yükseltebilirsiniz.

Örnek bir senaryo üzerinden ilerleyelim.

1. Öncelikle kimlik avı gibi bir teknikle sıradan Windows kullanıcı hesabı 'notadmin'in güvenliğini ihlal ediyoruz. Bu hesabın Active Directory'de minimum ayrıcalıkları var ancak geldiğimiz makinede yerel bir yönetici.

2. Daha sonra herhangi bir gMSA'nın var olup olmadığını bulmaya çalışacağız. Windows PowerShell cmdlet'ine erişiminiz varsa bunu gerçekleştirmek çok kolaydır. Basit bir komut dosyasını çalıştırmak bize Active Directory'deki tüm yönetilen hizmet hesaplarını sağlar:

Get-ADServiceAccount -Filter *

3. Komut dosyasında yapılan bazı küçük değişikliklerle, gMSA şifrelerini sorgulamak için kimin erişime sahip olduğunu belirleyebiliriz:

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword

Gördüğümüz gibi bu hizmet hesaplarının şifrelerini yalnızca Kevin Joyce hesabı sorgulayabiliyor:

4. Bu hizmet hesaplarının herhangi bir ayrıcalıklı gruba üye olup olmadığını kontrol ederek istediğimiz hedeflerin kapsamını daraltabiliriz ve buradan nesnelerden birinde ayarlanan izinleri daha derinlemesine inceleyebiliriz:

Get-ADServiceAccount -Filter * -Properties memberof

Buradaki sonuçlara baktığımızda, gMSA hizmet hesabının Domain Admins'in bir üyesi olduğunu görebiliyoruz, bu yüzden yararlanmaya çalışacağımız hesap bu olacak.

5. Microsoft LAPS'teki bir gönderide sağlanan komut dosyasını değiştirerek, belirli bir gMSA özelliği için Tam Denetim, Tüm Özellikleri Yaz veya Yazma Özelliğini içeren bir yönetilen hizmetler hesabı üzerinde izinleri olan tüm nesnelerin bir listesini elde edebildik. Çıktı aşağıdadır ve komut dosyası altta bağlantılıdır.

6. Gördüğünüz gibi notadmin hesabı gMSA hesabı üzerinde Tam Kontrole sahiptir. Bu bize, yönetilen hizmet hesabının parolasını almamıza olanak tanıyan msDS-GroupMSAMembership özniteliğini değiştirme olanağı sağlar:

Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin

7. Artık şifreyi gerçekten sorgulayabildiğimize göre, onunla ne yapabileceğimize bakalım:

Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword

$pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword

8. Öznitelikte saklanan değer, parolanın kendisini değil, parolanın verilerini içeren bir BLOB'dur, dolayısıyla DSInternals gibi bir araç kullanarak parolanın kodunu çözmemiz gerekecek:

$pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword

Bu bize SecureCurrentPassword ve CurrentPassword'u verir. CurrentPassword kullanışlı bir şeye benzemiyor ancak bunun nedeni tüm karakterlerin UTF-16 olmasıdır. SecureCurrentPassword, bir NTLM karmasına dönüştürülebilir ve ayrıcalıklarımızı yükseltmek için mimikatz ile karma saldırısını geçmek için kullanılabilir.

9. Hash'i iletmek için sadece mimikatz'ı çalıştırmamız ve şu komutu kullanmamız gerekiyor:

sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9

10. Artık Domain Admins'in üyesi olan gMSA hizmet hesabı olarak çalıştırılan bir kabuğumuz olduğuna göre, Active Directory'yi tehlikeye atmak için ne istersek yapabiliriz. Bunu yapmanın en hızlı ama muhtemelen en çetrefilli yollarından biri, bir DCSync saldırısı gerçekleştirip krbtgt hesabının karma değerini çalmaktır:

lsadump::dcsync /user:krbtgt /domain:sbpmlab.net

gMSA Koruması ve İzleme

gMSA kötüye kullanımını önlemek ve tespit etmek için kullanabileceğiniz stratejiler vardır.

İzinler

Yerleştirebileceğiniz en açık ve tartışmasız en önemli koruma, grup tarafından yönetilen hizmet hesaplarınızda uygun izinlerin ayarlandığından emin olmaktır. Bu nesnelere kimin yazma erişimi olduğunu anlamak, onları korumak açısından önemlidir; Teorik olarak şifreyi kimin sorgulayabileceğini kontrol eden özelliğe kendisini ekleyebilen birinin bu hesabı devralma ve ayrıcalıklarını kötüye kullanma erişimi zaten vardır.

Bir sonraki adım, bu hesaplardaki şifreleri kimin sorgulayabileceğini ve tam olarak kimin böyle bir erişime ihtiyacı olduğunu anlamak olacaktır. Gerçekte, bir gMSA'nın şifresini alabilmesi gereken tek hesap, gMSA'nın kurulu olduğu bilgisayar hesabıdır.

Olay Günlükleri

Yerel olay günlüklerinde arayabileceğiniz, gMSA hesaplarının parolalarını kimin sorguladığını belirlemenize yardımcı olacak bir olay vardır. Alanınız için 'Dizin hizmeti erişimini denetle' politikasını etkinleştirirseniz ve izlemek istediğiniz gMSA'larda bir SACL yapılandırırsanız, insanlar msDS-ManagedPassword özelliğini sorguladığında olay günlükleri oluşturabilirsiniz:

Bu ayarın açılması ve yeni bir SACL oluşturulması, olay kimliği 4662 olan bir olay günlüğü oluşturacaktır; şuna benziyor:

Gördüğünüz gibi bu, 'notadmin' hesabının gMSA hesabındaki bir özelliği okuduğunu kaydetti. Okunan özellikler, Active Directory şemasında saklanan GUID'lerdir, ancak ADSI düzenlemesini kullanarak, vurgulanan GUID'in msDS-ManagedPasssword özniteliğine çözümlendiğini görebiliriz.

Bir tür olay günlüğü iletme veya SIEM çözümünüz olabileceğini varsayarsak, bu günlükler, bu niteliklere kimin eriştiğini belirlemek açısından çok değerli olacaktır.

Netwrix GizliSAVUNMA

Diğer bir seçenek ise Netwrix StealthDEFEND gibi bir araçtır. Netwrix StealthDEFEND yerel olay günlüklerine güvenmez ve gMSA şifre erişimini ve yüksek riskli izin atamalarını kutudan çıktığı anda algılayabilir. Örneğin, yukarıda gösterilen senaryo, 'notadmin' hesabı şifreyi sorguladığında aşağıdaki tehdidi oluşturacaktır:

Üstelik Netwrix StealthDEFEND ile gMSA'nın kötüye kullanımı tespit edildiğinde çalıştırılacak bir taktik kitabını kolayca oluşturabilirsiniz. Başucu kitabı, fail kullanıcı hesabının bir MFA isteğine yanıt vermesini zorunlu kılmak, hesabı devre dışı bırakmak veya bir ServiceNow olayı oluşturmak gibi birden çok adımı içerebilir.

Ek

gMSA izin kodu:

<#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}

ham görüntülemegMSA_Permissions_Collection.ps1GitHub tarafından barındırılır.

SSS

gMSA nedir?

Yönetilen hizmet hesaplarına (MSA) benzer şekilde, grup tarafından yönetilen hizmet hesapları (gMSA'lar), hizmetlerin güvenli hale getirilmesine ve erişim yönetimine yardımcı olmak için kullanılan yönetilen etki alanı hesaplarıdır. gMSA işlevi, etki alanı denetleyicisi (DC) tarafından otomatik parola yönetimi, basitleştirilmiş hizmet asıl adı (SPN) yönetimi ve yönetimi diğer yöneticilere devretme yeteneği sağlar; bu da Active Directory güvenliğini artırır ve ayrıcalıklı erişime sahip hesapları en aza indirir.

MSA'lar ile gMSA'lar arasındaki fark nedir?

MSA'nın aksine, gMSA birden fazla bilgisayarla ilişkilendirilebilir.

Grup tarafından yönetilen bir hizmet hesabı nasıl bulunur?

Etki alanı denetleyicinizdeki gMSA'ların listesini almak için Sunucu Yöneticisi > Araçlar > Active Directory Kullanıcıları ve Bilgisayarları > Yönetilen Hizmet Hesapları'nı açın.

Bir gMSA, Alan Adı Yöneticisi olabilir mi?

Evet, bir gMSA hesabı Domain Admins'e üye olabilir ancak bu uygulama bilgi güvenliği açısından tehlikeli olabilir.

GMSA'yı nasıl oluşturabilirim?

Grup tarafından yönetilen hizmet hesapları, New-ADServiceAccount cmdlet'iyle oluşturulur.

İlgili makaleler