Policies, preferences, scripts ve scheduled tasks: Merkezi yapılandırma neleri değiştirebilir?

1. Core Mechanism / Temel mekanizma

GPO, AD'deki GPC ve SYSVOL'deki GPT ile policy verisini taşır; client-side extensions (CSE) kendi veri türlerini işler. Policies, preferences, scripts ve scheduled tasks aynı GPO'ya bağlanabilse de aynı extension, state modeli veya execution context değildir. Dersin sınırı bu ayrımdır; GPO link/permission yüzeyleri 09.03'te, resultant-policy ve refresh hata ayrımı 09.05'te ele alınır.

Arabirimler ve belirtimler

• Policy settings: Windows bileşeninin policy-aware ayarını yönetir; sonuç, ilgili bileşenin policy semantics'ine bağlıdır.
• Group Policy Preferences: client-side extension tarafından işlenen yapılandırma öğeleridir; policy enforcement ile aynı geri alma/uygulama semantiğine sahip varsayılamaz.
• Scripts: computer startup/shutdown veya user logon/logoff gibi belirli processing aşamalarında yapılandırılan komut/komut dosyası yüzeyidir.
• Scheduled Tasks preference: Task Scheduler için bir tanım/configuration öğesidir; GPO'da tanım bulunması, görevin her endpoint'te başarıyla kaydolduğu ya da çalıştığı kanıtı değildir.
• Computer-side öğeler computer policy processing; user-side öğeler user policy processing bağlamında değerlendirilir. Bir komutun gerçek principal'ı ayrıca o extension/Task Scheduler tanımıyla belirlenir.
• GPC extension listesi bir yapılandırma ipucudur; client processing başarısı, local Task Scheduler kaydı ve task execution ayrı kanıt katmanlarıdır.

Dört araç, tek 'GPO ayarı' değildir

Policies, preferences, scripts ve scheduled tasks aynı yönetim konsolunda yan yana görülebilir; fakat birinin davranışını diğerine taşıyamazsınız. Policy-aware bir Windows bileşeni policy ayarını kendi kurallarıyla işler. Preferences ise ayrı CSE'lerin hedefe uyguladığı configuration öğeleridir.

Scripts bir programı belirli startup/shutdown/logon/logoff aşamasına yerleştirir. Scheduled-task preference ise Task Scheduler'a bir görev tanımı verir. İkisinde de 'GPO mevcut' cümlesi yalnız yapılandırma niyetini anlatır; tanımın endpoint'e ulaştığını, kayıt işleminin başarılı olduğunu veya payload'ın çalıştığını anlatmaz.

Bu nedenle soru 'GPO ne yapabilir?' değil, 'hangi CSE hangi veriyi, hangi policy half'te, hangi local service/bileşenle işler ve hangi state kanıtı kalır?' olmalıdır.

Context: computer, user ve task principal'ını ayır

Computer Configuration ile taşınan öğeler computer policy processing bağlamında, User Configuration ile taşınanlar user policy processing bağlamında değerlendirilir. Bu ayrım, hangi endpoint state'inin hedeflendiğini anlamak için gereklidir; fakat tek başına her child process'in hangi token ile çalıştığını söylemez.

Scheduled task için gerçek çalışma kimliği ayrıca task tanımındaki principal ve Task Scheduler davranışıyla belirlenir. Bu yüzden 'GPO task = SYSTEM' veya 'user policy task = kullanıcı token' gibi evrensel kurallar güvenilir değildir. İnceleme, ilgili task XML'i ve endpoint'teki registration/execution kanıtıyla tamamlanmalıdır.

Preferences için 'silinince otomatik eski haline döner' varsayımı da güvenli değildir. Öğenin action'ı, CSE davranışı ve hedefte bıraktığı state birlikte değerlendirilmelidir; geri alma gereksinimini açıkça tasarlamak gerekir.

Registration sırasında belirtilen credentials, task tanımındaki principal bilgisini değiştirebilir. Run identity’yi söylemeden önce kayıtlı task’ı ve execution kanıtını incele. Policy mode hedefi belirler; ortaya çıkan her process’in token’ını belirlemez.

Artifact: intent kaydı execution kanıtı değildir

Artifact, bir GPO'nun directory metadata'sında extension listesi güncellenmiş gibi görünen sentetik 5136 olayıdır. gPCMachineExtensionNames alanı bize yalnız GPC tarafındaki configuration intent'ini gösterir. Bu alan, scheduled-task item'ın SYSVOL içeriğini, istemcinin CSE'yi çalıştırdığını veya görevin başarıyla tetiklendiğini tek başına doğrulamaz.

Bu sınırlama savunma için bir eksik değil, doğru korelasyon kuralıdır: directory evidence'i GPO değişiminin kim/nerede olduğunu; client-side operational log ve local task inventory ise uygulanma/registration tarafını araştırır. Bir sinyalin öbürünün yerine geçmesine izin vermeyin.

Durum ve veri akışı

1. Yönetici GPC metadata’sı ve GPT extension içeriği hazırlar; author rolü task run identity’si değildir.
2. GPC extension listesi ile GPT task tanımı ayrı veridir. Aynı GPO GUID’i içerik ve execution kanıtını birleştirmez.
3. User/computer policy target ve processing mode’u belirle. Bu hedef, task principal’ı değildir.
4. CSE’nin okuduğu task tanımını izlerken local registration sınırını ayrı tut.
5. Task definition principal, registration credentials ve logon type’ı ayrı oku. Author veya policy target’tan token çıkarma.
6. Registration kanıtını incele. Başarısız kayıt veya yalnız kayıt gözlemi execution başarısı değildir.
7. Execution ve local sonuç gözlemini ayrıca karşılaştır. Bu sentetik örnek gerçek task veya program çalıştırmaz.

2. Exploitation / İstismar

Broken trust assumption

GPO içindeki herhangi bir yapılandırma öğesi aynı yetkiyle çalışır, aynı derecede kalıcıdır ve GPO'da görünmesi endpoint'te otomatik execution anlamına gelir.

Technical prerequisites

• Bir değişikliğin endpoint etkisi için GPO'nun hedefe link/filter koşullarını geçmesi ve ilgili user/computer processing'in gerçekleşmesi gerekir.
• İlgili CSE'nin veriyi okuyabilmesi ve local bileşen/Task Scheduler'ın tanımı kabul edebilmesi gerekir.
• Task veya script etkisini değerlendirmek için execution principal, hedef kapsamı ve payload'ın local güvenlik kontrolleri ayrıca incelenmelidir.

Exploitation mechanism / İstismar mekanizması

Yanlış delegation veya kötü niyetli GPO content değişikliği, ilgili CSE'nin işlediği configuration türüne göre endpoint state'ini değiştirmeye çalışır. Etki, GPO varlığıyla değil; link/filter, CSE processing, local registration ve gerekirse execution kanıtının tamamıyla sınırlandırılır.

Saldırı modelini CSE'ye indir

GPO write erişimi güçlü olabilir; ancak hangi etkiyi doğuracağını öğe türü belirler. Bir preference öğesinin değiştirilmesi, policy-aware bir ayarı zorlamakla aynı mekanizma değildir. Bir scheduled-task item ise önce tanımın istemciye gelmesine, sonra Task Scheduler'ın local kayda/çalıştırmaya ilişkin kontrollerine bağlıdır.

Bu nedenle araştırma zinciri şudur: değişen GPO GUID'i, değişen CSE verisi, hedef user/computer kapsamı, local state ve varsa execution. Bu halkalardan biri yoksa kapsamı 'olası yapılandırma etkisi' ile sınırlayın; başarıyla code execution veya geniş etki iddia etmeyin.

Kırık varsayımı azalt

GPO authoring rollerini işlevsel olarak ayırın: sıradan desktop preference yönetimi, startup/logon script yönetimi ve scheduled task authoring aynı geniş gruba verilmemelidir. Kritik task/script değişiklikleri için review ve dar hedefli pilot gerekir.

SYSVOL içeriğinde beklenmeyen script/task değişimini GPC metadata değişiminden bağımsız inceleyin. Hedef kapsamı ve task principal'ını görünür kılan envanter, yalnız 'GPO changed' alarmından daha güvenilir bir kontrol sağlar.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Directory Service Changes audit + SACL, GPC attribute değişimlerini 5136 ile gözlemlemek için önkoşuldur.
• 5136 directory object/attribute değişimini gösterir; GPT/SYSVOL dosya içeriği, CSE processing veya Task Scheduler execution için tek telemetri kaynağı değildir.
• Client-side validation, ilgili endpoint'in GroupPolicy/CSE ve Task Scheduler kanallarının etkin collection durumuna bağlıdır; burada belirli Event ID şeması uydurulmaz.

Events and relevant fields

• Security 5136: gPCMachineExtensionNames gibi GPC attribute değişikliğinin directory kanıtı.
• SYSVOL/GPT dosya telemetry: script/task XML gibi file-side change için ayrı kanıt yüzeyi.
• Endpoint CSE/Task Scheduler operational kanalları ve local task inventory: registration/execution hipotezini doğrulamak için ayrı kaynaklar.

Niyet ile sonuç arasına kanıt koy

GPC'deki extension metadata değişikliği, bir yönetim niyetinin directory'de kaydıdır. Aynı GUID'in SYSVOL tarafındaki veriyle ve hedef endpoint'teki local state ile eşleşmesi gerekir. Özellikle script ve task öğelerinde, yalnız directory event'inden execution çıkarımı yapılmamalıdır.

Telemetri tasarımında üç ayrı soru sorun: Kim GPO metadata'sını değiştirdi? Hangi dosya/payload değişti? Hangi endpoint'te hangi CSE/task sonucu oluştu? Her sorunun sahibi farklı log kaynağı olabilir.

Normal rollout'u saldırı diye etiketleme

Yeni task veya preference deployment'ı, extension-list değişimi ve client-side kayıtlarla meşru olarak görünür. Baseline GPO owner'ı, change window, hedef OU ve task adı/payload hash'i gibi bağlamlar olmadan sadece bir event'e yüksek öncelik vermeyin.

Tersine, izinli bir change kaydı da endpoint'te beklenmeyen principal veya hedef kapsamını otomatik meşru yapmaz. Directory intent, SYSVOL content ve local resulting state arasındaki farkı araştırma sinyali olarak kullanın.

Detection logic · XPath

/*[local-name()='Event']/*[local-name()='EventData']/*[local-name()='Data' and @Name='AttributeLDAPDisplayName' and text()='gPCMachineExtensionNames']

Query assumptions

• XPath yalnız sentetik 5136 artifact'indeki directory attribute'u seçer; üretimde Security event XML alanları ingest sırasında korunmalıdır.
• gPCMachineExtensionNames değişimi tek başına belirli bir scheduled task'ın yaratıldığını veya çalıştığını kanıtlamaz.
• Client-side evidence toplama politikası ve Task Scheduler operational kanalının kullanılabilirliği endpoint bazında doğrulanmalıdır.

False positives

• Onaylı GPO authoring/deployment değişiklikleri ve normal extension ekleme/çıkarma.
• GPO restore, migration veya yönetim otomasyonunun yaptığı metadata güncellemeleri.

Hardening

• Policy, preference, script ve scheduled-task authoring yetkilerini ayrı envanterleyin; yüksek etkili öğeleri dar rol ve review ile yönetin.
• GPC/SYSVOL change kanıtını endpoint CSE/Task Scheduler kanıtından ayrı toplayın; korelasyon kuralında source gap'i açıkça koruyun.
• Yeni script/task rollout'unu küçük OU'da, geri dönüş ve local resulting-state kontrolüyle doğrulayın; GPO'nun görünmesi başarı ölçütü değildir.

Ö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>5136</EventID><Version>0</Version><Level>0</Level><Task>14081</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-10-01T10:23:00.0000000Z"/><EventRecordID>9042</EventRecordID><Channel>Security</Channel><Computer>dc1.outreason.example</Computer></System><EventData><Data Name="SubjectUserName">workstation-policy-editor</Data><Data Name="ObjectDN">CN={4F3A1A9E-8D25-4B1C-9A06-0C0F0E090304},CN=Policies,CN=System,DC=outreason,DC=example</Data><Data Name="ObjectClass">groupPolicyContainer</Data><Data Name="AttributeLDAPDisplayName">gPCMachineExtensionNames</Data><Data Name="AttributeValue">{synthetic-scheduled-task-extension}</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

İki yanlış kanı / Two reality checks

Sanılan: GPO altında görünen policy, preference, script ve scheduled task aynı şekilde uygulanır ve kaldırıldığında aynı şekilde geri alınır.

Gerçekte: Bunlar farklı CSE ve state modelleridir. Policy-aware ayar, preference öğesi, processing aşamasındaki script ve Task Scheduler tanımı aynı semantiğe sahip değildir; geri alma/kalıcılık davranışı ilgili öğe ve extension bağlamında doğrulanmalıdır.

Sanılan: Bir scheduled-task ayarı GPO'da görünüyorsa görev hedef makinelerde çalışmıştır.

Gerçekte: GPO/GPC kaydı yalnız configuration intent'ini gösterir. Link/filter, client CSE processing, local task registration ve gerekiyorsa execution ayrı kanıt adımlarıdır; directory 5136 olayı bunların yerine geçmez.

Kaynaklar / Sources

• Microsoft Open Specifications · [MS-GPOD]: Group Policy: Core Protocol
  GPC/GPT bileşenleri ve Group Policy verisinin Active Directory/SYSVOL yerleşimi.
• Microsoft Open Specifications · [MS-GPOL]: Group Policy: Core Protocol
  GPO sürüm ve client-side extension processing kavramları; computer/user policy mode ayrımı.
• Microsoft · Group Policy preferences in Windows
  Preferences policy-enforced setting değil, CSE ile her refresh’te işlenen yapılandırma öğeleridir; scheduled-task preferences Task Scheduler’a görev oluşturabilir/değiştirebilir/silebilir; principal ve action ayrıca tanımlanır.
• Microsoft · 5136(S): A directory service object was modified
  Directory Service Changes audit; ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType ve Subject alanları.
• Microsoft Group Policy Application
  User/computer policy mode and CSE invocation
• Microsoft Task Security Contexts
  Definition versus registration credentials and logon type