Merhaba
Serinin önceki üç bölümünde Kerberoasting, AS-REP Roasting ve Password Spraying’i ele aldık; bunların hepsi kullanıcı objelerini hedef alıyordu. Bu bölümde, Active Directory’nin varsayılan bir ayarını istismar ederek yetkisiz bir kullanıcının kendi bilgisayar objesini yaratmasına izin veren MachineAccountQuota tekniğine geçiyoruz.
MachineAccountQuota Compromise
MachineAccountQuota compromise, kullanıcı objelerinin `ms-DS-MachineAccountQuota` özniteliği aracılığıyla domain’de en fazla on bilgisayar objesi oluşturmasına izin veren varsayılan Active Directory ayarını istismar eder. Bu bilgisayar objeleri otomatik olarak Domain Computers güvenlik grubuna eklenir ve bu grubun yetkilerini devralır. Saldırganların çoğu, tespit edilme riskini azaltmak amacıyla bilgisayar objesinin adını kurumun herhangi bir domain’e özgü adlandırma kurallarına uyacak şekilde belirler. Örneğin, Domain Computers güvenlik grubu aşırı yetkilendirilmişse, daha üst yetkili güvenlik gruplarının üyesiyse veya diğer Active Directory objeleri üzerinde yetkilere sahipse, saldırganlar bunu yetki yükseltmek için istismar edebilir. Saldırganlar kendi bilgisayar objelerini oluşturup bu obje olarak kimlik doğrulaması yaparak ve onun yetkilerini devralarak bunu başarabilir. Bu bilgisayar objesi daha sonra kullanıcı objelerine benzer şekilde domain ile etkileşime girmek için kullanılabilir. Bilgisayar objeleri ayrıca domain’deki diğer sistem ve servislere erişip onlarla etkileşime girebilir. MachineAccountQuota compromise, başka bir teknik olan KrbRelayUp’ın parçası olarak da kullanılabilir. LDAP signing’in zorunlu kılınmadığı (Active Directory’nin varsayılan ayarı) domain’lerdeki sistemlerde, saldırganlar yetkilerini yerel yöneticiye yükseltmek için KrbRelayUp’ı çalıştırabilir.
MachineAccountQuota Compromise’i Mitigasyon Etmek
MachineAccountQuota compromise’i mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:
- Yetkisiz kullanıcı objelerinin domain’e bilgisayar objesi ekleyememesini sağlayın. Bu, Active Directory’de `MS-DS-MachineAccountQuota` özniteliği sıfıra ayarlanarak yapılandırılabilir. Genellikle yalnızca sistem yöneticileri gibi yetkili personelin, yeni bir sunucu veya workstation domain’e katıldığında olduğu gibi yeni bilgisayar objesi eklemesi gerekir.
- Domain Computers güvenlik grubunun yüksek yetkili güvenlik gruplarının üyesi olmadığından emin olun. Bu, saldırganların bir MachineAccountQuota compromise sonucu yetkilerini yükseltmesini engeller.
- Domain Computers güvenlik grubunun Active Directory’deki herhangi bir objeye yazma yetkisi olmadığından emin olun. Bu, saldırganların bir MachineAccountQuota compromise nedeniyle diğer Active Directory objelerinin kontrolünü veya erişimini ele geçirmesini engeller.
- Domain Controller’lar için LDAP signing’i etkinleştirin. LDAP signing, kullanıcı kimlik doğrulaması, mesaj imzalama ve şifreleme dahil çok sayıda güvenlik koruması sağlar. LDAP signing ayrıca KrbRelayUp’a karşı da mitigasyon sağlar.
MachineAccountQuota Compromise’i Tespit Etmek
Active Directory’de her bilgisayar objesi oluşturulduğunda, event 4741 üretilir ve bu olay, objenin özellikleri ve onu kimin oluşturduğuna dair bilgiler içerir. Bu olay, bilgisayar objesinin meşru mü yoksa kötü niyetli amaçlarla mı oluşturulduğunu belirlemek için analiz edilebilir. Ayrıca, MachineAccountQuota için bilgisayar objesi oluşturmak, parolasının belirlenmesini de gerektirir. Bu da bir MachineAccountQuota compromise göstergesi olabilecek bir olay üretir. Aşağıdaki Event ID’ler merkezi olarak loglanmalı ve zamanında analiz edilmelidir.
MachineAccountQuota Compromise’i Tespit Eden Olaylar
| Event ID | Kaynak | Açıklama |
|---|---|---|
| 4624 | Domain Controller’lar | Bir obje başarıyla oturum açtığında üretilir. Bu olay, saldırganlar tarafından oluşturulan bilgisayar objesinin domain’e kimlik doğrulaması yapıp yapmadığını tespit etmek amacıyla event 4741 ile ilişkilendirilebilir. |
| 4724 | Domain Controller’lar | Bir objenin parolasını sıfırlama girişiminde bulunulduğunda üretilir. Saldırganlar yeni bir bilgisayar objesi oluşturduğunda, ardından bu obje olarak kimlik doğrulaması yapabilmek için parolasını belirler. Bu olay, event 4741 ile aynı zamanda (veya yakın bir zamanda) üretiliyorsa, bir MachineAccountQuota compromise gerçekleştiğine işaret edebilir. |
| 4741 | Domain Controller’lar | Active Directory’de bir bilgisayar objesi oluşturulduğunda üretilir. Bu olay, saldırganlar tarafından MachineAccountQuota compromise’in bir parçası olarak oluşturulan bilgisayar objesini tespit etmek için kullanılabilir. Bilgisayar objesi, normalde bilgisayar objesi oluşturmayan kullanıcı objeleri tarafından oluşturuluyorsa, bu bir MachineAccountQuota compromise’e işaret edebilir. |
Lab Uygulaması: Windows Server 2025 Üzerinde MachineAccountQuota Compromise
Bu bölümdeki gösterim için kendi Windows Server 2025 domain controller ve Windows 11 client lab ortamımızda, herhangi bir yönetici yetkisi olmayan sıradan bir domain kullanıcısı (`testuser.sade`) üzerinden ilerledik. Amaç, bu kullanıcının varsayılan `ms-DS-MachineAccountQuota` hakkını kullanarak domain’e kendi bilgisayar objesini ekleyebildiğini somut olarak göstermekti. İlk denemelerimiz, `testuser.sade` oturumundan doğrudan LDAP/ADSI üzerinden (`[adsi]` type accelerator ve `System.DirectoryServices.Protocols` ile) parolasız bir bilgisayar objesi oluşturmaya yönelikti; klasik saldırgan araçlarının çoğu bu yolu izler. Ancak bu denemelerde domain controller, işlemi `WILL_NOT_PERFORM` (problem 5003) hatasıyla reddetti. Parola gerekliliğini atlatmak için kullanılan `PASSWD_NOTREQD` bayrağını denediğimizde ise bu kez `CONSTRAINT_ATT_TYPE` (problem 1005) hatası aldık. Bu, Windows Server 2025’te, yönetici olmayan bir kullanıcının parolasız ya da parola gerekliliğini bayrakla atlatarak bilgisayar objesi oluşturmasının artık engellendiğine işaret eden, kaynak raporda doğrudan belgelenmemiş ilginç bir sertleştirme bulgusuydu. Bunun üzerine, gerçek dünyada MachineAccountQuota’nın en yaygın istismar biçimine döndük: sıradan bir domain kullanıcısının, makinede yerel yönetici hakkına sahip olması kaydıyla, tamamen meşru bir `Add-Computer` domain-join işlemiyle kendi kotasını tüketmesi. Bunun için `W11CLIENT` makinesini önce domain’den çıkarıp workgroup moduna aldık, ardından yerel yönetici oturumunda `Add-Computer -DomainName “bakicubuk.local” -Credential (Get-Credential)` komutunu `testuser.sade` kimlik bilgileriyle çalıştırdık. Dikkat edilmesi gereken nokta şu: bu işlem için `testuser.sade`’ın Active Directory tarafında hiçbir ek yetkisi yok – sadece makine üzerinde yerel yönetici olması yeterli, çünkü domain’e katılma hakkı `ms-DS-MachineAccountQuota` üzerinden zaten her domain kullanıcısına varsayılan olarak tanınmış durumda. İşlem tamamlandıktan sonra domain controller’da oluşan Event ID 4741 kaydı, tam olarak beklediğimiz kanıtı sağladı.
Event Viewer’da oluşan Event ID 4741 kaydının genel görünümü. Olayın `Security` günlüğünde, `Microsoft-Windows-Security-Auditing` kaynağından üretildiği ve “A computer account was created” açıklamasıyla listelendiği görülüyor.
Aynı olayın detay ekranı. `Subject` alanında `BAKICUBUK\testuser.sade` – yani hiçbir yönetici yetkisi olmayan sıradan domain kullanıcısı – görünüyor. `New Computer Account` alanında `BAKICUBUK\W11CLIENT$` yeni bilgisayar objesi yer alıyor ve `Privileges` alanında bu işlemi mümkün kılan `SeMachineAccountPrivilege` ayrıcalığı açıkça listeleniyor. Bu üç alan bir arada, MachineAccountQuota compromise’in ders kitabı niteliğinde bir kanıtı: sıradan bir kullanıcı, hiçbir ek yetki verilmeden, sadece varsayılan domain ayarları sayesinde domain’e yeni bir obje ekleyebiliyor. Gerçek bir saldırı senaryosunda, saldırgan bu bilgisayar objesini fiziksel ya da sanal bir makineye ihtiyaç duymadan, doğrudan LDAP/Kerberos araçlarıyla da oluşturabilir; bizim ortamımızda gördüğümüz sertleştirme, bu yolu zorlaştırsa da, `Add-Computer` gibi tamamen meşru bir işlem üzerinden aynı zafiyetin hala istismar edilebildiğini gösteriyor. Bu da mitigasyon bölümünde belirtilen `ms-DS-MachineAccountQuota` değerinin sıfıra çekilmesinin neden bu kadar kritik olduğunu bir kez daha doğruluyor.
Uyumluluk ve Çerçeve Eşlemesi Tablosu
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 8.2 (Güçlü kimlik doğrulama) |
| HIPAA | 164.312(a)(1) – Erişim Kontrolü |
| ISO 27001 | A.9.2 (Kullanıcı Erişim Yönetimi), A.9.4 (Sistem ve Uygulama Erişim Kontrolü) |
| KVKK | Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler |
| TCMB | Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri |
| NIST CSF | PR.AC-4 (Erişim yetkilerinin yönetimi), PR.AC-1 (Kimlik ve kimlik bilgisi yönetimi) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1098 (Account Manipulation)
Sonuç
MachineAccountQuota compromise, çoğu Active Directory ortamında varsayılan olarak açık duran, fark edilmesi kolay ama genellikle göz ardı edilen bir zafiyeti gösteriyor. Öznitelik değerini sıfıra çekmek tek başına yeterli ve düşük maliyetli bir mitigasyon; buna Domain Computers grubunun yetkilerinin sınırlandırılması ve LDAP signing’in zorunlu kılınması eklendiğinde, bu teknik ve ona bağlı KrbRelayUp saldırı zinciri büyük ölçüde kapanmış oluyor. Serinin bir sonraki bölümünde, ele geçirilen bir bilgisayar objesinin başka kullanıcı objelerinin kimlik bilgilerini çalmak için nasıl kullanılabileceğini gösteren Unconstrained Delegation tekniğini ele alacağız.