Group Policy Serisi Bölüm 6: Saldırgan Gözünden Group Policy

Merhaba

Beşinci bölümün sonunda duvar kağıdı paylaşımındaki bir izin hatasının GPO’yu (Group Policy Object) nasıl uygulanmış ama çalışmıyor durumuna getirdiğini gördük. Bu bölümde aynı düzeneğe tersten bakıyoruz: izin yanlış yöne kaydığında, yani ihtiyaç duyulandan fazla yetki verildiğinde ne olur? Group Policy, bir etki alanındaki yüzlerce makineye aynı anda, çoğu zaman SYSTEM yetkisiyle ayar ve kod ulaştırabilen bir mekanizmadır. Bu yüzden saldırgan için de çok değerli bir araçtır.

Bu bölüm bir saldırı rehberi değildir. Amacımız, savunmacı olarak Group Policy çevresindeki zayıf noktaların nerede olduğunu, standart bir kullanıcının bunları nasıl keşfedebildiğini, hangi kayıtların tutulduğunu ve bunların nasıl kapatıldığını görmektir. Uygulama kısmında laboratuvarda yalnızca zararsız örnekler kullanıyoruz: bir duvar kağıdının değiştirilmesi, izin listelerinin okunması ve olay kayıtlarının incelenmesi.

1. Group Policy Neden Saldırganın Hedefidir?

Bir saldırgan etki alanında yetki yükseltirken ya da kalıcılık sağlarken şu özelliklerden yararlanır:

• Geniş erişim: Bir GPO tek bir değişiklikle yüzlerce bilgisayara ya da kullanıcıya ulaşır.
• Yüksek yetki: Computer Configuration tarafındaki ayarlar, betikler ve zamanlanmış görevler SYSTEM bağlamında çalışır.
• Meşru görünüm: GPO değişiklikleri günlük yönetimin parçasıdır. Dikkatle izlenmezse olağan bir değişiklikten ayırt edilemez.
• Kalıcılık: Ayar GPO’da durduğu sürece, makine temizlense bile bir sonraki yenilemede geri gelir.
• Herkese açık okuma: Bir GPO’nun tanımı ve dosyaları, etki alanındaki her kimliği doğrulanmış kullanıcı tarafından okunabilir. Bu, tasarım gereğidir, çünkü istemciler kendi ayarlarını okuyabilmelidir.

Savunma açısından ana fikir şudur: Bir GPO’yu değiştirebilen kişi, o GPO’nun kapsadığı tüm hesapların ve makinelerin yetkisini devralır. Bu yüzden GPO yazma yetkisi, kapsadığı en yüksek yetkili hesap kadar korunmalıdır.

2. Saldırı Yüzeyi Haritası

Group Policy çevresindeki başlıca zayıf noktalar aşağıdaki tabloda toplanmıştır. Bu bölümde ilk dört satırı laboratuvarda inceliyoruz.

3. Laboratuvar Ön Koşulu: Duvar Kağıdı Düzeneğini Yeniden Kurmak

Bölüm 5‘in sonunda isteğe bağlı temizlik komutlarını çalıştırdıysanız U - Satis - Duvar Kagidi GPO’su ve Wallpaper paylaşımı silinmiştir. Bölüm 5‘teki Adım 1, 2 ve 4’ü yeniden uygulayabilirsiniz. Aşağıdaki komutlar aynı düzeneği tek seferde, bu kez doğru izinlerle kurar. Temizliği yapmadıysanız bu adımı atlayıp Get-GPInheritance ile Satis OU’sunda (Organizational Unit) U - Satis - Duvar Kagidi bağlantısının durduğunu doğrulayın.

Domain controller’da Run as administrator (Yönetici olarak çalıştır) açılmış bir PowerShell penceresinde:

New-Item -Path "C:\Shares\Wallpaper" -ItemType Directory -Force | Out-Null

Add-Type -AssemblyName System.Drawing
$bmp = New-Object System.Drawing.Bitmap 1920, 1080
$g = [System.Drawing.Graphics]::FromImage($bmp)
$g.Clear([System.Drawing.Color]::FromArgb(17, 24, 39))
$font = New-Object System.Drawing.Font("Segoe UI", 72, [System.Drawing.FontStyle]::Bold)
$sf = New-Object System.Drawing.StringFormat
$sf.Alignment = [System.Drawing.StringAlignment]::Center
$sf.LineAlignment = [System.Drawing.StringAlignment]::Center
$alan = New-Object System.Drawing.RectangleF 0, 0, 1920, 1080
$g.DrawString("bakicubuk.tech", $font, [System.Drawing.Brushes]::White, $alan, $sf)
$bmp.Save("C:\Shares\Wallpaper\wallpaper.png", [System.Drawing.Imaging.ImageFormat]::Png)
$g.Dispose(); $bmp.Dispose()

New-SmbShare -Name "Wallpaper" -Path "C:\Shares\Wallpaper" -FullAccess "Administrators" -ReadAccess "GG_Satis"

New-GPO -Name "U - Satis - Duvar Kagidi" | Out-Null
Set-GPRegistryValue -Name "U - Satis - Duvar Kagidi" -Key "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" -ValueName "Wallpaper" -Type String -Value "\\W25DC\Wallpaper\wallpaper.png" | Out-Null
Set-GPRegistryValue -Name "U - Satis - Duvar Kagidi" -Key "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" -ValueName "WallpaperStyle" -Type String -Value "4" | Out-Null
$gpo = Get-GPO -Name "U - Satis - Duvar Kagidi"
$gpo.GpoStatus = "ComputerSettingsDisabled"
New-GPLink -Name "U - Satis - Duvar Kagidi" -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" | Out-Null

Get-SmbShareAccess -Name "Wallpaper"
Get-GPInheritance -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech"

Kendi ortamınıza uyarlarken:

Bu bloktaki GpoStatus satırı hata verirse, GPO’yu GPMC’den (Group Policy Management Console) açıp Details sekmesinde GPO Status değerini Computer configuration settings disabled yapabilirsiniz. Bu, GPO’nun yalnızca kullanıcı ayarlarını işlemesi içindir ve Bölüm 5‘teki durumla aynıdır.

New-SmbShare komutu paylaşım oluşunca Name, ScopeName, Path ve Description sütunlu kısa bir tablo yazdırır. Get-SmbShareAccess çıktısında BUILTIN\Administrators için Full, BAKICUBUK\GG_Satis için Read görünmelidir.

İstemcide nihat.cubuk ile oturum açıp duvar kağıdının geldiğini doğruluyoruz. Bölüm 5‘te gördüğümüz masaüstü görüntüsü burada da aynıdır. Duvar kağıdı gelmiyorsa Bölüm 5‘teki sorun giderme sırasını izleyin.

4. Uygulama: Savunmacının Bildiği, Saldırganın da Öğrendiği

Adım 1: Standart bir kullanıcı ile keşif

Önce saldırganın ilk elde ettiği şeyi canlandırıyoruz: yetkisiz, standart bir etki alanı kullanıcısı. İstemcide nihat.cubuk ile oturum açıyoruz. Hiçbir yönetim aracı kurmadan, Windows’un kendi araçlarıyla neleri görebildiğine bakıyoruz.

1. Uygulanan GPO’lar: Komut isteminde gpresult /r /scope user çalıştırıyoruz. Kullanıcının hangi GPO’ların kendisine uygulandığı, hangilerinin filtrelendiği ve hangi güvenlik gruplarının üyesi olduğu görünür.
2. SYSVOL (System Volume) içindeki politika klasörleri: File Explorer’da \\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies yoluna gidiyoruz. Her GPO bir GUID (Globally Unique Identifier) adlı klasör olarak listelenir. PolicyDefinitions klasörü bir GPO değildir, Bölüm 2’de gördüğümüz merkezi şablon deposudur (Administrative Templates şablon dosyaları burada durur). Bir GPO klasörüne girip User ya da Machine altındaki dosyalara bakabiliyoruz.
3. GPO nesneleri: Active Directory içinde GPO’lar groupPolicyContainer türünde nesnelerdir. PowerShell ile standart kullanıcı bile bu nesneleri sorgulayabilir.

Üçüncü madde için istemcide, kullanıcı olarak PowerShell açıp şu komutu çalıştırıyoruz:

$arama = [adsisearcher]"(objectClass=groupPolicyContainer)"
$arama.PropertiesToLoad.AddRange(@("displayName","name","versionNumber","gPCFileSysPath"))
$arama.FindAll() | ForEach-Object {
    [pscustomobject]@{
        Ad      = $_.Properties["displayname"][0]
        Guid    = $_.Properties["name"][0]
        Surum   = $_.Properties["versionnumber"][0]
        Yol     = $_.Properties["gpcfilesyspath"][0]
    }
} | Format-Table -AutoSize -Wrap

Kendi ortamınıza uyarlarken:

Çıktıda laboratuvardaki tüm GPO’ların adları, GUID’leri, sürüm sayıları ve SYSVOL yolları listelenir. Listede Default Domain Policy, Default Domain Controllers Policy, üç Satis GPO’su ve Seamless SSO Settings bulunur. Sonuncusunu Entra Connect serisinde Seamless SSO’yu (Single Sign-On) yapılandırırken Microsoft Entra Connect oluşturmuştur, sizin ortamınızda yoksa şaşırmayın. Bu komut yönetici yetkisi gerektirmez.

Pencere dar kalırsa PowerShell sığmayan sütunları gizler. Bu yüzden Surum sütununu uzun olan Yol sütunundan önce aldık.

Surum sütununu okumak: Bu sayı düz bir sayaç değildir. Active Directory, GPO’nun kullanıcı sürümünü ve bilgisayar sürümünü tek bir sayıda tutar. Sayının üst 16 biti kullanıcı sürümü, alt 16 biti bilgisayar sürümüdür. Kullanıcı sürümünü bulmak için sayıyı 65536’ya bölüp tam kısmını alırız. Bilgisayar sürümü ise sayıdan kullanıcı sürümü × 65536 çıkarılarak bulunur. Örneğin U - Satis - Duvar Kagidi için 131072 = 2 × 65536 olduğundan kullanıcı sürümü 2, bilgisayar sürümü 0’dır. GPO’yu bu bölümde yeniden kurarken iki kayıt değeri yazdık (Wallpaper ve WallpaperStyle), sürüm de 2 oldu. Satis GPO’larının bilgisayar sürümü 0’dır, çünkü yalnızca kullanıcı ayarları içerirler. Seamless SSO Settings için 196614 değeri ise kullanıcı sürümü 3, bilgisayar sürümü 6 demektir.

GPMC’de ve Get-GPO çıktısında gördüğümüz AD Version ve Bölüm 5‘teki Revision değerleri bu sayıdan türetilir. Bir GPO’da ayar değiştiğinde bu sayı artar. Aşağıda Adım 4’te göreceğimiz 5136 olayında değişen özelliğin neredeyse her zaman versionNumber olmasının nedeni budur.

Adım 2: SYSVOL’da unutulmuş parolaları aramak (cpassword)

Windows Server 2008 ile gelen GPP (Group Policy Preferences), yerel yönetici hesabı oluşturma, zamanlanmış görev ve servis tanımlama gibi işlerde parola girmeye izin veriyordu. Bu parola SYSVOL’daki XML (Extensible Markup Language) dosyasına cpassword alanı olarak, AES (Advanced Encryption Standard) ile şifrelenmiş biçimde yazılırdı. Sorun, şifreleme anahtarının Microsoft tarafından herkese açık yayımlanmış olmasıdır. Yani SYSVOL’u okuyabilen her kullanıcı bu parolayı çözebilirdi. Microsoft bu özelliği MS14-025 güncelleştirmesiyle (2014) kaldırdı, ancak güncelleştirme öncesinde oluşturulmuş dosyalar kendiliğinden silinmez. Eski bir ortamda bu dosyalar yıllarca kalabilir.

Savunmacı olarak yapacağımız şey, ortamımızda bu dosyalardan kalıp kalmadığını aramaktır. Domain controller’da ya da herhangi bir etki alanı bilgisayarında:

findstr /S /I cpassword "\\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies\*.xml"

Kendi ortamınıza uyarlarken:

Temiz bir ortamda komut hiçbir satır döndürmez. Bir satır dönerse, o XML dosyasındaki parolayı hemen değiştirin, çünkü parola zaten ele geçmiş sayılmalıdır. Ardından o Preferences öğesini silip parolayı GPO dışında yönetin (örneğin Windows LAPS (Local Administrator Password Solution) ile yerel yönetici parolaları için).

Adım 3: Yazılabilir paylaşım, yani Bölüm 5’teki hatanın tersi

Bölüm 5‘te GG_Satis grubuna yeterli izin vermeyince duvar kağıdı görünmemişti. Şimdi tersini yapıyoruz: GG_Satis grubuna gereğinden fazla izin veriyoruz. Gerçek ortamlarda bu hata genellikle kullanıcılar dosyayı yönetebilsin ya da sorun çıktı, Everyone Full Control yapalım düşüncesiyle ortaya çıkar.

Domain controller’da paylaşıma ve NTFS (New Technology File System) iznine Modify veriyoruz:

Grant-SmbShareAccess -Name "Wallpaper" -AccountName "GG_Satis" -AccessRight Change -Force
$acl = Get-Acl "C:\Shares\Wallpaper"
$kural = New-Object System.Security.AccessControl.FileSystemAccessRule("BAKICUBUK\GG_Satis", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($kural)
Set-Acl -Path "C:\Shares\Wallpaper" -AclObject $acl
Get-SmbShareAccess -Name "Wallpaper"
(Get-Acl "C:\Shares\Wallpaper").Access | Where-Object IdentityReference -like "*GG_Satis*" | Format-Table IdentityReference, FileSystemRights, AccessControlType

Kendi ortamınıza uyarlarken:

Şimdi istemcide nihat.cubuk ile \\W25DC\Wallpaper paylaşımına gidiyoruz. Artık dosyayı yeniden adlandırabilir, silebilir ya da üzerine başka bir resim kopyalayabilir. Zararsız bir deneme olarak, wallpaper.png dosyasının adını wallpaper-yedek.png yapıp aynı klasöre farklı bir wallpaper.png koyuyoruz (bizim örneğimizde kırmızı zeminli, üzerinde bakicubuk.tech yazan bir resim). Ardından GG_Satis grubunun bir başka üyesi ile ya da aynı kullanıcı ile oturumu kapatıp açıyoruz. Kendi resminizin boyutu 1920×1080’den farklıysa Fill yerleşimi onu büyütüp kırpar. Bizim örneğimizde yazının ortada değil sağa kayık ve kenarlarının pikselli görünmesinin nedeni budur. Bölüm 5’te metni merkeze yakın tutma konusunu da bu yüzden vurgulamıştık.

Bu örnekte etki masum bir renk değişikliğidir. Ama aynı mantık bir logon betiğinin, bir yazılım dağıtım paylaşımının ya da bir GPO’nun çağırdığı yürütülebilir dosyanın durduğu klasör için de geçerlidir. Orada klasöre yazabilen kullanıcı, o kaynağı çağıran tüm hesaplar adına kod çalıştırabilir. Bir GPO’nun işaret ettiği her yol, GPO’nun kendisi kadar korunmalıdır.

Şimdi bu değişikliği izlenebilir duruma getiriyoruz. Dosya sistemi denetimini açıp klasöre denetim kuralı ekliyoruz:

auditpol /set /subcategory:"File System" /success:enable /failure:enable
$acl = Get-Acl "C:\Shares\Wallpaper"
$denetim = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "Write,Delete", "ContainerInherit,ObjectInherit", "None", "Success")
$acl.AddAuditRule($denetim)
Set-Acl -Path "C:\Shares\Wallpaper" -AclObject $acl

Kendi ortamınıza uyarlarken:

Denetim kuralı artık açık. İstemcide nihat.cubuk ile \\W25DC\Wallpaper paylaşımına dönüp iki yeniden adlandırma yapıyoruz. Önce şu an wallpaper.png adını taşıyan kırmızı resmin adını wallpaper-yedek2.png yapıyoruz. Sonra wallpaper-yedek.png olarak sakladığımız asıl resmin adını yeniden wallpaper.png yapıyoruz. Böylece hem asıl duvar kağıdı yerine geliyor hem de denetlenen iki işlem oluşuyor. Ardından domain controller’da Security günlüğünde 4663 olaylarına bakıyoruz. Tam olayı görmek için Format-List, ekran görüntüsüne sığacak kısa bir özet için aşağıdaki tabloyu kullanabilirsiniz:

Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4663} -MaxEvents 5 | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{ Zaman = $_.TimeCreated; Hesap = $d.SubjectUserName; Nesne = $d.ObjectName; Maske = $d.AccessMask }
} | Format-Table -AutoSize

Kendi ortamınıza uyarlarken:

Bizim laboratuvarda üç olay oluştu (en yeni olay en üstte listelenir):

Üç olayda da hesap nihat.cubuk‘tur. Bu tabloda üç noktaya dikkat edin:

• Klasör ve dosya ayrı nesnelerdir. Bir klasöre ad eklemek klasör üzerinde AddFile, bir dosyayı silmek ya da adını değiştirmek dosyanın kendisi üzerinde DELETE olarak kaydedilir.
• Process Name boştur, Process ID 0x4‘tür. Bu, işlemin ağ paylaşımına gelen bir SMB (Server Message Block) isteği olarak çekirdekteki sürücü tarafından yapıldığını gösterir. Olay hangi program sorusunu değil, hangi hesap sorusunu cevaplar.
• Olay kaynak makineyi göstermez. 4663 olayında kullanıcının hangi bilgisayardan bağlandığı yoktur. Bunu 5145 (ağ paylaşımı nesnesine erişildi) olayı verir, ancak o olay için Audit Detailed File Share denetim alt kategorisini açmak gerekir.

Denetim kuralının dosyalara gerçekten geçtiğini ayrıca doğrulamak için dosyaların denetim listesine bakıyoruz:

foreach ($d in "wallpaper.png","wallpaper-yedek2.png") {
    "--- $d"
    (Get-Acl "C:\Shares\Wallpaper\$d" -Audit).Audit
}

Kendi ortamınıza uyarlarken:

Bizim laboratuvarda sonuç şöyle çıktı:

Bu, DELETE olayının neden yalnızca kırmızı resim için oluştuğunu açıklar. Denetim kuralı olmayan dosyada yapılan işlem kayda girmez. Kuralın neden iki dosyadan yalnızca birine geçtiğini bu laboratuvarda kesin olarak belirlemedik. Çıkarılacak ders şudur: Bir klasöre denetim kuralı koymak, içindeki mevcut her dosyanın denetlendiği anlamına gelmez. Denetimi kurduktan sonra Get-Acl -Audit ile dosyaları kontrol edin ve gerçek bir işlemle deneyip hangi olayların oluştuğunu doğrulayın.

Sorunu düzeltmek için izinleri eski durumuna getiriyoruz. Asıl duvar kağıdını yukarıda zaten yerine koyduk, burada yalnızca izinleri düzeltiyoruz:

Grant-SmbShareAccess -Name "Wallpaper" -AccountName "GG_Satis" -AccessRight Read -Force
$acl = Get-Acl "C:\Shares\Wallpaper"
$acl.Access | Where-Object { $_.IdentityReference -like "*GG_Satis*" -and $_.FileSystemRights -match "Modify" } | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "C:\Shares\Wallpaper" -AclObject $acl
Get-SmbShareAccess -Name "Wallpaper"

Kendi ortamınıza uyarlarken:

NTFS tarafının da temizlendiğini ayrıca doğruluyoruz:

(Get-Acl "C:\Shares\Wallpaper").Access | Where-Object IdentityReference -like "*GG_Satis*" | Format-Table IdentityReference, FileSystemRights, AccessControlType

Kendi ortamınıza uyarlarken:

Çıktı boştur, çünkü GG_Satis için NTFS kuralı kalmamıştır. Okuma hakkı Users gibi başka bir grup üzerinden geliyorsa onun satırı bu filtrede görünmez.

Adım 4: GPO üzerinde fazla yetki bulmak ve değişikliği izlemek

En kritik zayıf nokta, bir GPO’yu değiştirme yetkisidir. GPMC’de GPO’yu seçip Delegation sekmesine baktığımızda kimin ne yapabildiğini görürüz. Normalde Edit settings ve üstü yalnızca Domain Admins, Enterprise Admins, SYSTEM ve Group Policy Creator Owners gibi yönetim hesaplarında olmalıdır. Başka bir kullanıcı ya da grup burada Edit settings yetkisine sahipse, o hesabı ele geçiren herkes GPO’nun kapsadığı hesaplara ve makinelere ayar ve kod ulaştırabilir.

Önce tek bir GPO’nun izinlerine bakıyoruz. Bu, taramanın neyi okuduğunu görmemizi sağlar:

Get-GPPermission -Name "U - Satis - Duvar Kagidi" -All | Select-Object @{n="Hesap";e={$_.Trustee.Name}}, Permission | Format-Table -AutoSize

Kendi ortamınıza uyarlarken:

Tüm GPO’larda yönetim dışı hesapların sahip olduğu yazma yetkilerini tek komutla listeliyoruz:

Get-GPO -All | ForEach-Object {
    $gpo = $_
    Get-GPPermission -Guid $gpo.Id -All | Where-Object {
        $_.Permission -in "GpoEdit","GpoEditDeleteModifySecurity" -and
        $_.Trustee.Name -notin "Domain Admins","Enterprise Admins","SYSTEM","ENTERPRISE DOMAIN CONTROLLERS"
    } | Select-Object @{n="GPO";e={$gpo.DisplayName}}, @{n="Hesap";e={$_.Trustee.Name}}, Permission
} | Format-Table -AutoSize

Kendi ortamınıza uyarlarken:

Temiz bir laboratuvarda Group Policy Creator Owners ya da sizin eklediğiniz bir grup dışında sonuç dönmemelidir. Çıktıdaki her satır, bu hesap neden bu GPO’yu değiştirebiliyor? sorusunu cevaplatmalıdır.

Şimdi savunmacının asıl sorusuna geliyoruz: bir GPO değiştiğinde bunu nasıl görürüz? Domain controller’da Directory Service Changes denetiminin açık olduğunu doğruluyoruz, kapalıysa açıyoruz:

auditpol /get /subcategory:"Directory Service Changes"
auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /get /subcategory:"Directory Service Changes"

Kendi ortamınıza uyarlarken:

Denetim açıkken bir GPO ayarını değiştiriyoruz. GPMC’de U - Satis - Duvar Kagidi GPO’sunu sağ tıklayıp Edit ile açıyoruz ve Wallpaper Style değerini Fill yerine Fit yapıp kaydediyoruz ya da komutla:

Set-GPRegistryValue -Name "U - Satis - Duvar Kagidi" -Key "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" -ValueName "WallpaperStyle" -Type String -Value "6"

Ardından Security günlüğünde 5136 olaylarına bakıyoruz:

Get-WinEvent -FilterHashtable @{LogName="Security"; Id=5136} -MaxEvents 2 | Select-Object TimeCreated, Id, Message | Format-List

Kendi ortamınıza uyarlarken:

Olay mesajında Subject altında değişikliği yapan hesabı (Administrator), Object altında DN olarak CN={GUID},CN=Policies,CN=System,DC=bakicubuk,DC=tech biçimindeki GPO nesnesini, Attribute altında ise değişen özelliği (versionNumber) görürüz. GPO’nun adı olayda değil, GUID olarak geçer. Adı bulmak için Get-GPO -Guid kullanılır.

Çıktıda iki olay göreceğiz ve ikisi de aynı Correlation ID değerini taşır. Bunlar tek bir değişikliğin iki yarısıdır: Value Deleted eski sayıyı (bizim laboratuvarda 131072), Value Added yeni sayıyı (196608) gösterir. Sürüm sayısını okumayı Adım 1’de öğrenmiştik: 131072, 2 × 65536 eder, yani kullanıcı sürümü 2’dir. 196608 ise 3 × 65536 eder ve kullanıcı sürümü 3’e çıkmıştır. WallpaperStyle kullanıcı tarafı bir ayar olduğu için artan taraf kullanıcı sürümüdür.

Burada iki önemli ayrıntı var:

• Olayda iki farklı GUID vardır. DN içindeki {...} değeri GPO’nun GUID’idir ve Get-GPO -Guid ile kullanılır. Object altındaki ayrı GUID: satırı ise AD (Active Directory) nesnesinin kendi objectGUID değeridir ve Get-GPO ile çalışmaz. İkisini karıştırmayın.
• Olay neyin değiştiğini söylemez. 5136 yalnızca GPO’nun versionNumber değerinin arttığını gösterir. Duvar kağıdı stilinin mi, başka bir ayarın mı değiştiği olayda yer almaz. Ayrıntı için SYSVOL’daki ilgili GPO klasörüne ve Group Policy Results raporlarına bakmak gerekir.

GPO’nun GUID’ini ada çevirmek için:

Get-GPO -Guid "00000000-0000-0000-0000-000000000000" | Select-Object DisplayName, Id, ModificationTime

Kendi ortamınıza uyarlarken:

Çıktıda 259dfad8-... GUID’inin U - Satis - Duvar Kagidi GPO’suna ait olduğunu görürüz. ModificationTime değeri, olaydaki değişiklik zamanına çok yakındır (birkaç saniye farkla).

5. Tespit ve Savunma: Neyi İzlemeli, Neyi Kapatmalı?

Bu bölümde gördüğümüz zayıf noktaların her birinin bir olay ve bir önlemi vardır. Aşağıdaki tablo, SIEM’de (Security Information and Event Management) ya da olay incelemesinde ilk bakacağınız yerleri özetler.

Önlemleri öncelik sırasıyla şöyle sıralayabiliriz:

1. GPO yazma yetkilerini sınırlayın. Edit settings yalnızca küçük bir GPO yönetim grubunda olsun. Düzenli olarak Get-GPPermission taramasını çalıştırıp çıktıyı karşılaştırın.
2. GPO’nun işaret ettiği her yolu GPO kadar koruyun. Paylaşım ve NTFS izinleri Read ile sınırlı olsun. Yazma yalnızca yönetici gruplarında olsun. Gerekmedikçe logon betiklerini SYSVOL dışındaki paylaşımlarda tutmayın.
3. Group Policy Creator Owners grubunu boş tutun ya da çok küçük tutun. Bu gruptaki bir hesap yeni GPO oluşturup kendi GPO’sunun sahibi olur.
4. OU’larda Link GPOs yetkisini denetleyin. GPMC’de OU’yu seçip Delegation sekmesine bakın. Yetkiyi yalnızca ihtiyacı olan gruplara verin.
5. GPO içine parola koymayın. Yerel yönetici parolaları için Windows LAPS (Local Administrator Password Solution) kullanın. SYSVOL’da cpassword taraması yapın.
6. Default Domain Policy ve Default Domain Controllers Policy‘yi olabildiğince az değiştirin. Bunlara yapılan her değişiklik etkisini tüm etki alanına ya da tüm domain controller’lara yayar. Özel ayarlar için ayrı GPO kullanın. Bu iki varsayılan GPO’da yalnızca parola ve kilitleme politikası gibi gerçekten etki alanı genelinde olması gereken ayarlar kalsın.
7. Yönetim katmanlarını ayırın. Domain Admin hesapları iş istasyonlarında oturum açmasın. Aksi takdirde bir iş istasyonunun GPO’su, Domain Admin kimliğini ele geçirmek için bir yol olur.
8. Düzenli tarama yapın. PingCastle ve Purple Knight gibi araçlar GPO izinlerini, cpassword kalıntılarını ve riskli delegasyonları raporlar. BloodHound ise bir hesabın bir GPO üzerinde sahip olduğu yetkiyi saldırı yolu olarak gösterir. Bunları kendi etki alanınızda, yetkili olarak çalıştırın.

6. Güvenlik Açısından Bu Bölümün Dersleri

• Okuma açık, yazma kapalı olmalıdır. Keşif engellenemez ama yazma yetkisi sıkı tutulabilir.
• GPO yetkisi, kapsadığı en yüksek yetkili hesabın yetkisi kadar kritiktir. Bir GPO’da yazma yetkisi vermek, o GPO’nun kapsadığı tüm kullanıcı ve bilgisayarlar üzerinde yetki vermektir.
• GPO tek başına bir güvenlik sınırı değildir. GPO’nun işaret ettiği paylaşımlar, betikler ve hizmetler de zincirin parçasıdır. Zincirin en zayıf halkası, en az korunan paylaşımdır.
• Tespit, önlemden önce gelir. 5136, 5137, 5141, 4663 ve 4670 olayları açık değilse bir GPO değişikliği hiçbir iz bırakmadan geçer.
• Düzenli denetim şarttır. Bir izin bir kez doğru verilmiş olabilir. Üç yıl sonra aynı izin hala doğru mudur? Get-GPPermission taramasını takvime bağlayın.

7. Özet ve Sonraki Bölüm

1. Group Policy, tek değişiklikle çok sayıda hesaba ve makineye ulaştığı için saldırgan için değerli bir araçtır. GPO’yu değiştirebilen kişi, onun kapsadığı hesapların yetkisini devralır.
2. SYSVOL ve GPO nesneleri her kimliği doğrulanmış kullanıcıya okunur. Bu bir açık değil tasarımdır. Savunma, GPO içine gizli bilgi koymamaktır.
3. cpassword içeren eski GPP dosyaları, MS14-025 sonrasında da SYSVOL’da kalabilir. findstr ile taramak ve bulunan parolaları değiştirmek gerekir.
4. GPO’nun işaret ettiği paylaşımdaki gereğinden geniş yazma izni, GPO’nun kendisi kadar risklidir. Bu izin 4663 ile izlenebilir.
5. GPO değişiklikleri 5136, yeni GPO’lar 5137 ve silinen GPO’lar 5141 olayı olarak görünür. Directory Service Changes denetimi açık değilse bu olaylar hiç oluşmaz.
6. Get-GPPermission ile yönetim dışı hesapların GPO üzerindeki yazma yetkilerini düzenli olarak taramak, en ucuz ve en etkili savunmalardan biridir.

Sonraki bölüm: Bölüm 7’de GPO’larımızı güvenlik temel ayarlarıyla (Security Baseline) sıkılaştırıyoruz. Microsoft Security Compliance Toolkit ile gelen baseline GPO’larını içe aktarıp mevcut ayarlarla karşılaştırıyor, yaygın sıkılaştırma ayarlarını uyguluyor ve hesap ilkelerini (parola ve hesap kilitleme politikası) ele alıyoruz.

Kısaltmalar

Yazıda geçen kısaltmaların açılımlarını ve kısa açıklamalarını aşağıdaki tabloda bir arada bulabilirsiniz.