Hesap yaşam döngüsü: Oluşturma, devre dışı bırakma, kilitlenme, silme ve sahipsizlik.

1. Core Mechanism / Temel mekanizma

Bir hesabın yaşam döngüsü durumu tek bir yerde tutulmaz. Enabled/disabled için userAccountControl içindeki ACCOUNTDISABLE (0x0002) bitine bakılır. Locked durumu lockoutTime ve policy/zaman koşullarından hesaplanan msDS-User-Account-Control-Computed görünümüyle değerlendirilir; LOCKOUT (0x0010) kalıcı bir userAccountControl alanı gibi okunmamalıdır. Deleted nesne isDeleted=TRUE ile Deleted Objects yaşam döngüsüne girer; Recycle Bin etkinliği, niteliklerin korunmasını ve restore penceresini değiştirir. Stale bir bit değildir; lastLogonTimestamp gibi yaklaşık bir zaman değerinden yapılan çıkarımdır. Audit event bir geçişi, bir DC'den okunan directory attribute o DC'nin gördüğü güncel durumu anlatır; replikasyon yakınsaması ayrı bir katmandır. Grup üyeliği 07.x'te, parola politikası 08.02'de, ACL sahipliği 05.x'tedir.

Arabirimler ve belirtimler

• userAccountControl: ACCOUNTDISABLE = 0x0002 değişikliği almış DC’nin bu hesap için yeni çevrimiçi domain authentication isteğini reddetmesini sağlar. Cached desktop logon ve daha önce açılmış oturumlar ayrı yollardır. AD DS'de etkin lockout görünümü, lockoutTime ve hesaplanan msDS-User-Account-Control-Computed niteliğindeki ADS_UF_LOCKOUT (0x0010) üzerinden okunur; bu biti kalıcı userAccountControl değeri sanma.
• Account Lockout Policy: başarısız parola denemeleri yapılandırılmış Account lockout threshold değerine ulaştığında lockout uygulanır; Account lockout duration ve Reset account lockout counter after davranışı belirler.
• lastLogonTimestamp: domain logon etkinliğini yaklaşık izleyen replicated nitelik; yalnızca değer yapılandırılmış msDS-LogonTimeSyncInterval'dan eskiyse güncellenir. Yaygın varsayılan davranış yaklaşık 9–14 günlük güncelleme eşiği oluşturur; değer tam son etkinliği kanıtlamaz. badPwdCount ve lastLogon ise non-replicated, DC başına tutulur.
• Deleted object: silinen nesne isDeleted=TRUE ile Deleted Objects içine alınır. AD Recycle Bin silme öncesinde etkinse silinmiş nitelikler deleted-object lifetime boyunca restore edilebilir; sonraki recycled/tombstone ve kalıcı temizleme aşamaları tombstoneLifetime ile yapılandırmaya bağlıdır. Tek bir evrensel 180 günlük varsayım kullanma.
• Windows Security 4725 (disabled), 4722 (enabled), 4726 (deleted), 4740 (locked out), 4767 (unlocked): Audit User Account Management geçiş kayıtlarıdır; DC/domain ve yerel hesap olaylarının üretildiği bilgisayar bağlamını ayır.

Beş durum, beş farklı saklama yeri

Enabled/disabled durumu userAccountControl içindeki ACCOUNTDISABLE (0x0002) bitine bağlıdır. Disable nesneyi silmez. Değişikliği görmüş bir DC’ye yapılan yeni domain authentication reddedilir; başka DC’nin eski replica görünümü ve DC yokken yerel cached logon ayrı koşullardır. Cached desktop, domain doğrulaması isteyen network resource’a erişim kanıtı değildir.

Locked bundan farklıdır: başarısız deneme sayacı yapılandırılmış Account lockout threshold değerine ulaştığında sistem lockoutTime'ı günceller. Etkin lockout durumu AD DS'de lockoutTime ve msDS-User-Account-Control-Computed çıktısından değerlendirilir; 0x0010 değeri kalıcı userAccountControl niteliği değildir. Süre dolunca kilit kalkabilir; manuel unlock ayrıca 4767 kaydı üretebilir.

Deleted, nesnenin yaşam döngüsünü değiştirir; immediately kalıcı yok oluş demek değildir. Recycle Bin silinmeden önce etkinse silinmiş nesnenin nitelikleri deleted-object lifetime boyunca korunup restore edilebilir. Recycle Bin kapalıysa veya geri yükleme penceresi geçtiyse nesne farklı tombstone/recycled aşamalarına ilerler. Bu sürelerin varsayılanı forest'in geçmişine ve yapılandırmaya göre değişir. Stale ise bir bit değildir: hesap enabled olabilir ama lastLogonTimestamp uzun süredir yenilenmemiştir; bu, kesin son kullanım kanıtı değil bir çıkarımdır.

Geçiş kaydı ile güncel durum aynı şey değildir

Bir 4725 kaydı 'op.admin, abdulvehhab'ı devre dışı bıraktı' der. Bu bir GEÇİŞTİR: kim, ne zaman, hangi eylem. Ama 'abdulvehhab şu anda disabled mı?' sorusunun yanıtı 4725'te değil, nesnenin güncel userAccountControl değerindedir. Birisi 4725'ten sonra hesabı yeniden etkinleştirmiş (4722) olabilir.

Bu ayrım pratik bir teşhis kuralına dönüşür: 'nesne hangi durumda?' sorusu directory'den okunur (userAccountControl, lockoutTime, isDeleted); 'bu duruma nasıl gelindi?' sorusu audit log'dan okunur (4725/4726/4740/4767). Audit log geçmişi anlatır, nitelik bugünü söyler.

İki tarafı karıştırmak yaygın bir hatadır: eski bir 4725'i görüp hesabı hâlâ disabled sanmak, ya da güncel disabled bitini görüp bunun ne zaman/kim tarafından yapıldığını nitelikten okumaya çalışmak. Her soru kendi katmanına sorulur.

Durum ile session state farklı katmanlardır

Bir hesabı disable etmek, daha önce kurulmuş session’ı veya access token’ı anında sonlandırmaz. Değişikliği görmüş DC’deki yeni domain authentication reddedilir; mevcut service ticket, target context ve offline cached desktop bundan ayrı değerlendirilir.

Bu yüzden 'hesabı kapattım' demek 'erişimi anında kestim' demek değildir: mevcut session veya hedef hizmetin önceden kabul ettiği ticket, hedefin yaşam döngüsü/yeniden doğrulama davranışına göre sürebilir. Yeni ticket taleplerinin sonucu ise KDC hesabı, policy ve replikasyon kontrollerine bağlıdır; yalnızca var olan TGT'ye bakarak devam edeceğini varsayma. Incident response sırasında hedef sistemlerdeki etkin oturumları da ele al.

Aynı mantık lockout için de geçerlidir: lockout yeni authentication/logon girişimlerini reddeder ama zaten kurulmuş bir oturumu otomatik düşürdüğü anlamına gelmez. Directory account state ile canlı session/access state ayrı katmanlardır.

Silme, tombstone ve 'sahipsiz' nesneler

Silme anlık fiziksel yok oluş değildir. Recycle Bin önceden etkinse nesne, korunan nitelikleriyle deleted-object yaşam süresi içinde geri yüklenebilir; bu özelliğin kapalı olduğu ormanda ise restore olanakları ve kalan nitelikler farklıdır. Silinmiş, recycled/tombstone ve kalıcı temizleme aşamalarının süreleri forest yapılandırmasına bağlıdır; bu nedenle '180 gün'ü her orman için sabit varsayma.

Sahipsiz (orphaned) hesap ayrı bir kavramdır: nesne silinmemiştir, enabled'dır, ama arkasındaki gerçek sahip (ayrılan çalışan, kaldırılan servis) yoktur. Bu hesabın kimliği hâlâ geçerlidir; parolası biliniyorsa veya bir yerde saklıysa erişim üretmeye devam eder. Sahipsizlik bir durum biti değil, organizasyonel bir gerçeğin çıkarımıdır.

Bu iki kavram 08.01'in Red katmanının çekirdeğidir: silme penceresi ve sahipsiz-ama-geçerli hesap, 'kapatıldı sanılan ama hâlâ kimlik üreten' nesnelerin iki tipik kaynağıdır.

Beş ayrı yerde tutulan erişim

Finance üyeliğini kaldırdığını düşün. Directory’deki üyelik, kullanıcının parolasına bağlı credential, istemci process token’ı, ticket cache ve dosya sunucusunun kabul ettiği session aynı yerde tutulmaz. Üyelik değişikliği mevcut process token’ını baştan üretmez. Parola değiştirmek de o token’daki grup SID’lerini düzenleyen bir işlem değildir. Yeni authentication’ın sonucu, kullanılan DC’nin gördüğü durum ve policy ile ayrıca değerlendirilir.

Karşılaştırmadaki her seçeneği bu yüzden ayrı oku: hesap kapatma directory durumunu, parola değişikliği credential zamanını, ticket cache temizliği istemcideki cache’i etkiler. Cache temizlenirken hedefte açık olan bağlantının context’i otomatik yeniden oluşturulmaz. Kontrollü yeni bir target context ise yeniden ölçüm fırsatıdır; farklı bir DC veya başka bir izin yolu kullanılıyorsa aynı sonuç çıkabilir. 02.03 token’ın oluşumunu, 06.02 ticket’ın yolunu, 10.07 replica’nın güncelliğini ayrı açıklar.

Durum ve veri akışı

1. Başlangıç: DC01’in güncel attribute görünümü ile daha önce kurulmuş token, ticket ve target session ayrı kayıtlardır.
2. Seçilen hesap değişikliği fixture’a uygulanır. Disable/enable, 4725/4722; lockout/unlock, 4740/4767 ayrı geçişlerdir.
3. Önceden oluşmuş token ve target session geriye dönük yeniden kurulmaz. Ticket’ın endtime’ı tek başına session’ın kapanma anı değildir.
4. Yeni authentication’ın yolu ayrı değerlendirilir: güncel DC, eski replica görünümü ve offline cached desktop aynı karar değildir.
5. Yeni target context gerekiyorsa ayrıca oluşturulup sonucu gözlenir. Cache temizliği, hedefteki mevcut bağlantının kendiliğinden yenilendiğini göstermez.
6. Son karşılaştırma: event geçmişi hangi geçişi anlatıyor; seçilen DC’nin güncel attribute’u ne; target session’ın gerçek sonucu ne?

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: 'Bir hesabı disable ettiysem veya lockout olduysa o kimlikle kurulmuş erişim anında biter.' Disable/lock yeni girişimleri engelleyebilir; fakat önceden kurulmuş session, access token veya hizmetin kabul ettiği ticket'ı otomatik geri çağırmaz. Recycle Bin ile silinmiş nesne ancak doğru özellik ve yaşam süresi koşullarında restore edilebilir; enabled kalan sahipsiz hesap ise parolası erişilebiliyorsa geçerli kalır. Risk, account state ile gerçek session/resource access state'ini aynı sanmaktan doğar.

Technical prerequisites

• Yeni online domain authentication’ın hangi DC’ye gittiği ve o DC’nin ACCOUNTDISABLE değişikliğini görüp görmediği bilinmelidir. Güncel disabled durumdaki DC bu yolu reddeder; offline cached desktop ve eski replica görünümü ayrı koşullardır.
• Disable/lock anından önce kurulmuş session/access token veya hedef hizmetin kabul ettiği bir service ticket bulunması; mevcut erişim, hedef oturumun ve ticket'ın yaşam döngüsüne bağlıdır. Yeni service-ticket isteğinin başarılı olacağını TGT'nin varlığından tek başına çıkarma.
• Geri yükleme riski için AD Recycle Bin silinmeden önce etkin, nesne restore süresi içinde ve restore işlemini yapan principal yetkili olmalıdır; geri gelen nitelikler ile üyelikler bu feature/lifetime koşullarına bağlıdır.
• Stale hesabın hâlâ ayrıcalıklı grup üyeliği taşıması; kullanılmayan ama yetkili bir hesap, unutulmuş bir attack surface'tir (üyelik 07.x'te).

Exploitation mechanism / İstismar mekanizması

Mekanizma account state ile kaynak üzerinde zaten kurulmuş access context arasındaki farktır. Disable ACCOUNTDISABLE'ı set eder ve yeni logon/authentication girişimlerini engeller; fakat mevcut access token'ı, açık session'ı veya bir hizmetin daha önce kabul ettiği ticket'ı geriye dönük silmez. TGT ile yeni service ticket alınacağını ise her durumda varsayma: KDC'nin yeni talepte uyguladığı hesap/policy durumu ayrıca belirleyicidir. Lockout da mevcut session'ı otomatik sonlandırmaz. Sahipsiz ama enabled hesap geçerli credential ile giriş yüzeyi olmaya devam eder. Silinmiş nesnenin attribute ve üyelikleriyle geri gelmesi, Recycle Bin'in önceden etkin olması, süre ve restore yetkisi gibi koşullara bağlıdır.

Devre dışı hesap, canlı oturum

Hesabı disable etmek, o kimlikle daha önce açılmış oturumu anında düşürmez. Hedef sistemdeki session, access token veya servisin daha önce kabul ettiği ticket kendi yaşam döngüsüne göre kalabilir. Yeni service-ticket talebinin sonucu ayrıca KDC ve account policy kontrollerine bağlı olduğundan, yalnızca TGT varlığıyla devam eden erişimi garanti sayma. Incident response'ta hesabı kapatmanın yanında hedeflerdeki etkin oturumları da gözden geçir.

Ticket ömrünü kısaltmak gelecekteki ticket kullanımını sınırlar; daha önce kabul edilmiş target session’ı tek başına kapatmaz. Fiili kesinti, ilgili service’in reauthentication/session davranışına ve açık oturumun sonlandırılmasına bağlıdır. Disable ile erişimin bitmesi arasına her service için sabit bir ticket-lifetime süresi yazılamaz.

Sahipsiz ve stale: en sessiz yüzey

Sahipsiz hesap bir alarm üretmez çünkü teknik olarak her şey normaldir: enabled, parola geçerli, belki de düzenli 'çalışıyor'. Risk, arkasında bir insan/servis sahibinin olmaması ve kimsenin onu izlememesidir. Parolası eski ve hiç değişmiyorsa, bir sızıntıda uzun ömürlü bir giriş noktası olur.

Stale hesap benzer biçimde radar altındadır: lastLogonTimestamp aylardır güncellenmemiştir ama hesap silinmemiş, disable edilmemiştir. Eğer bu hesap ayrıcalıklı bir grupta kalmışsa, kullanılmayan ama yetkili bir hedef olur. Her iki durumda da 'zafiyet' bir bit değil, yönetimsel bir kör noktadır ve tam da bu yüzden envanter/expiry kontrolleriyle kapatılır (Blue).

Silme penceresi ve yanlış restore: geri gelen ayrıcalık

Silinen kimliğin geri gelmesi uzaktan sömürü değildir: Recycle Bin silinmeden önce etkinleştirilmiş ve deleted-object lifetime sürüyor olmalı; ayrıca restore işlemini yapacak principal yeterli yetkiye sahip olmalıdır. Bu koşullar sağlanırsa korunan SID, grup üyelikleri ve diğer nitelikler geri dönebilir. Retention değerleri forest yapılandırmasına bağlıdır; her yerde 180 gün varsayma.

Olası etki, restore edilen kimliğin eski ayrıcalıklarıyla geri dönmesidir: eğer silinen hesap bir yönetici grubundaysa, naif bir restore o üyeliği de geri getirir ve fark edilmeyen bir ayrıcalıklı hesap yeniden erişim üretir. Bunu engelleyen kontrol, silme/restore'u kontrollü bir süreç yapmaktır: Recycle Bin'i bilinçli yönet, restore'ları onaya bağla ve geri getirilen ayrıcalıklı hesapların üyeliğini restore sonrası doğrula. Böylece silme penceresi bir saldırı yüzeyi değil, denetlenen bir yaşam döngüsü adımı olur.

Bu örneğin risk sınırı

“Hesabı kapattık” ifadesinden bütün hedeflerdeki erişimin sona erdiği sonucu çıkmaz. İncelenen context’in nerede ve ne zaman oluşturulduğunu belirle; eski TGT’den yeni taleplerin mutlaka kabul edileceğini de varsayma.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• userAccountControl içindeki ACCOUNTDISABLE, enabled/disabled durumunu gösterir. Lockout için lockoutTime ve policy/zamanla hesaplanan msDS-User-Account-Control-Computed niteliğini de incele; isDeleted ve lastLogonTimestamp farklı lifecycle sorularına yanıt verir. Directory okuması bağlandığın DC'nin görünümüdür; replication convergence ayrıca değerlendirilir. Audit event ise yalnız geçişi kaydeder.
• 4725/4726/4740/4767 gibi hesap yönetimi olayları Audit User Account Management alt kategorisine bağlıdır ve hesap işleminin gerçekleştiği bilgisayarda üretilir: domain hesapları için ilgili DC'de, yerel (SAM) hesaplar için ilgili üye sunucu/istemcide. Bunlar SACL gerektirmez, User Account Management denetimi açık olmalıdır.
• 4740 (lockout) kaydı, hesabın kilitlenmesinin kaydedildiği bilgisayarda üretilir (bu senaryodaki domain hesabında ilgili DC). Başarısız deneme sayacı badPwdCount replicated değildir ve her DC'de ayrı tutulur (AD replikasyon modeli); bu yüzden tek bir DC'nin görüntüsü tüm ormanın başarısız deneme toplamını vermez.
• Stale hesabı tek bir event yerine lastLogonTimestamp toplu sorgusuyla yaklaşık değerlendir. Değer yalnız msDS-LogonTimeSyncInterval eşiğini geçtiğinde yenilenir; varsayılan eşik yaklaşık 9–14 gün davranışı gösterebilir ve yapılandırılabilir. Bu nedenle yakın tarihli kullanım yorumunda alanı kesin son-logon zamanı gibi okuma.
• 4726, account deletion geçişini kaydeder; Deleted Objects retention, restore ve nihai temizleme davranışı AD Recycle Bin'in silme öncesinde etkin olup olmamasına ve deleted-object/tombstone lifetime yapılandırmasına bağlıdır. 4726 fiziksel yok oluşu kanıtlamaz.

Events and relevant fields

• 4725 / SubjectUserName + TargetUserName: devre dışı bırakma geçişinde eylemi yapan (Subject) ile etkilenen hesabı (Target) ayırır; TargetSid kalıcı kimliktir, ad değişse de sabittir.
• 4740 / TargetDomainName ile Caller Computer Name ayrı alanlardır: domain hesabında TargetDomainName hesap domain'ini taşır; kilitlenmeyle sonuçlanan denemenin kaynağı Microsoft'un Additional Information / Caller Computer Name alanında gösterilir. Bu alanları SIEM şemasında aynı kolona eşleme.
• 4740 / SubjectUserSid: kilitlenme otomatik olduğu için genellikle S-1-5-18 (Local System) ve DC hesabıdır; bir kullanıcı 'kilitledi' demek yanlıştır, eylem sistemseldir.
• 4767 / TargetUserName: bir hesabın manuel açılmasını (unlock) kaydeder; art arda kilitlenme + hızlı unlock deseni, hem yanlış yapılandırma hem de olası bir brute-force belirtisi olabilir.
• 4722 / TargetUserName: bir hesabın yeniden etkinleştirilmesini kaydeder; disable geçmişini okurken 4725'i tek başına değil, sonraki 4722 ile birlikte değerlendirmek gerekir, aksi hâlde güncel durum yanlış çıkarılır.

Hangi soru hangi katmana sorulur

İlk kural, soruyu doğru katmana yöneltmektir. Güncel enabled/disabled için userAccountControl içindeki ACCOUNTDISABLE; lockout için lockoutTime ve computed msDS-User-Account-Control-Computed; silinme için isDeleted; yaklaşık kullanım için lastLogonTimestamp okunur. 'Kim, ne zaman değiştirdi?' sorusu audit event'tir.

Bu ayrım, yaygın bir yanlış çıkarımı önler: eski bir 4725'i görüp hesabı hâlâ disabled sanmak. Doğru okuma, geçiş olaylarını zaman sırasıyla değerlendirip güncel durumu her zaman nitelikten teyit etmektir. Event geçmişi anlatır; nitelik bugünü söyler.

Durum       Güncel kaynak                                  Geçiş event'i
----------  --------------------------------------------  ---------------------
disabled    userAccountControl / ACCOUNTDISABLE           4725 / 4722
locked      lockoutTime + computed UAC view                4740 / 4767
deleted     isDeleted + Deleted Objects lifecycle          4726
stale       lastLogonTimestamp (yaklaşık çıkarım)           -- tek event yok
orphaned    -- organizasyonel sahiplik durumu                -- envanter/sahiplik

Replikasyon durumu ile denetim çıkarımını ayır

Bir hesabın durumunu birden çok DC'de sorgularsan, replikasyon gecikmesi yüzünden farklı yanıtlar görebilirsin: bir DC hesabı hâlâ enabled, diğeri disabled gösterebilir. Bu bir çelişki değil, replikasyonun henüz yakınsamamış (converge) olmasıdır. userAccountControl gibi replicated nitelikler eninde sonunda tüm DC'lerde aynı olur; badPwdCount ve lastLogon gibi non-replicated nitelikler ise her DC'de ayrıdır ve hiçbir zaman tek bir 'doğru' değere yakınsamaz.

Bu, denetim çıkarımını dikkatli yapmayı gerektirir. Directory replikasyon protokolünün taşıdığı şey nesne durumudur (nitelik değerleri, versiyon ve originating bilgisi); audit log ise ayrı bir kanaldır ve olayları üreten DC'de tutulur. İki hesap değişikliği farklı DC'lerde neredeyse aynı anda yapılırsa, hangisinin 'kazandığı' bir conflict-resolution kuralıyla belirlenir — ama bu kural, senin audit log'dan yaptığın 'kim önce yaptı' çıkarımınla aynı şey değildir. Bu derste replikasyonun iç metaverisi (versiyon sayaçları, originating DC) uydurulmaz; yalnızca şu ilke tutulur: gördüğün durum bir DC'nin o andaki görüntüsüdür, olayların mutlak sırası değil.

Pratik sonuç: 'kim/ne zaman' çıkarımını tek bir DC'nin audit log'una dayandır, ama 'nesne şu an hangi durumda' sorusunu yanıtlarken hangi DC'ye sorduğunu ve replikasyonun yakınsayıp yakınsamadığını hesaba kat. Non-replicated bir niteliği (badPwdCount) tek DC'den okuyup tüm ormanın gerçeği sanmak, en sık yapılan çıkarım hatasıdır.

Değişiklik sonrası doğrulama

Değişikliği yapan DC’deki güncel state’i, istemci cache’ini ve hedef session’ı ayrı zamanlarla kaydet. Kapanışta aynı kaynak ve requested right için yeni context sonucunu ve yetkili kullanıcının çalışabildiğini doğrula.

Detection logic · Sigma

title: Hesap disable ve otomatik lockout gecisleri (hesap yasam dongusu)
id: 0801-account-lifecycle-transitions
status: experimental
description: >
  User Account Management gecislerini (disable/lockout/unlock) gozlem noktasi
  olarak secer; directory'nin guncel account state'ini vermez.
logsource:
  product: windows
  service: security
detection:
  transitions:
    EventID:
      - 4725   # disabled
      - 4740   # locked out
      - 4767   # unlocked
  condition: transitions
fields:
  - EventID
  - TargetUserName
  - TargetSid
  - TargetDomainName     # hedef account domain/computer baglami
  - CallerComputerName   # 4740 icin kaynak computer; ayri alan
  - SubjectUserName
falsepositives:
  - Rutin yonetim: planli disable, mesru unlock islemleri
  - Yanlis kaydedilmis parola kaynakli mesru lockout
level: low

Query assumptions

• Sigma logsource windows/security kanalını varsayar; bu kural bir korelasyon değil, gözlem noktası seçimidir ve 'güncel durumu' vermez, yalnız geçiş kayıtlarını toplar.
• TargetDomainName hedef hesabın domain/computer bağlamıdır. 4740'taki Caller Computer Name ayrı ek bilgidir; event şemasında iki alanı tek alana indiren bir backend kaynak ayrımını kaybettirir.
• 4740 hesabın kilitlenmesinin kaydedildiği bilgisayarda oluşur; domain hesaplarında DC Security log'ları toplanmalıdır. badPwdCount non-replicated ve DC başına tutulur; tek DC değeri domain toplamı değildir. Caller Computer Name kaynağı gösterebilir ama her senaryoda IP adresi sağlamaz.
• Bu seçim canlı bir sistemde çalıştırılmadı; yalnızca bu dersin sentetik 4725/4740 örnekleri üzerinde alanların seçilebilirliği doğrulandı.

False positives

• Planlı hesap devre dışı bırakma (ayrılan çalışan süreci) meşru 4725 üretir; tek başına saldırı değildir.
• Yanlış kaydedilmiş parola art arda başarısız denemeyle meşru lockout/4740 üretebilir; kaynak için 4740 Caller Computer Name alanını kullan, TargetDomainName'i değil.
• Negatif örnek: sahipsiz ama enabled ve düzenli kullanılan bir hesap hiçbir geçiş olayı üretmez; bu filtre onu göremez. Stale/orphaned tespiti event değil, nitelik sorgusu gerektirir.

Hardening

• Hesap kapatmayı, ilgili DC’nin güncel read-back’i ve target’taki etkin oturumların incelenmesiyle doğrula. Kısa ticket lifetime gelecekteki kullanımı sınırlayabilir; mevcut session’ın kapandığını ayrı gözlemle. Service’in reauthentication davranışını ve oturum sonlandırma politikasını birlikte değerlendir (06.07).
• lastLogonTimestamp temelli düzenli stale-account envanteri yap; ~14 günlük güncelleme gecikmesini hesaba katarak eşiği (örneğin 90 gün) buna göre seç, dar pencerelerle yanlış 'aktif' etiketi verme.
• Ayrıcalıklı gruplardaki stale ve sahipsiz hesapları öncelikle temizle; kullanılmayan yetkili hesap, en sessiz attack surface'tir. Kaldırma öncesi bağımlılıkları (servis, scheduled task) doğrula.
• AD Recycle Bin'i etkinleştir ve tombstone lifetime'ı politikayla yönet; silme sonrası geri getirmeyi kontrollü bir süreç yap, yanlış restore ile ayrıcalıklı bir kimliğin geri canlanmasını engelle.
• Account lockout threshold/duration/observation window değerlerini denge gözeterek ayarla; çok düşük eşik meşru kullanıcıyı kilitleyip DoS'a yol açar, çok yüksek eşik brute-force'a alan açar. Değişiklik sonrası bilinen bir iş akışıyla doğrula: meşru giriş kilitlenmemeli, eşik aşımında 4740 üretilmeli.
• Denetim kapsamını doğrula: Audit User Account Management açık olmalı ve hesap işlemlerinin üretildiği bilgisayarların (domain hesapları için DC'ler) Security log'ları merkezîleştirilmeli; aksi hâlde lockout ve disable geçişleri eksik toplanır.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4725</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T08:12:03.7710000Z" />
    <EventRecordID>90114</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="4360" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1188</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-30300820-1105</Data>
    <Data Name="SubjectUserName">op.admin</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3e9f1</Data>
  </EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4740</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T08:41:57.2030000Z" />
    <EventRecordID>90260</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="5012" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="CallerComputerName">WS-FIN07</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1188</Data>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">DC01$</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
  </EventData>
</Event>

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E01",
  "directoryView": "membership removed on A/B",
  "TGT": "issued before change",
  "serviceTicket": "issued before change",
  "targetToken": "accepted at 09:10",
  "applicationSession": "same connection at 10:05",
  "comparison": "fresh target context observed without Finance SID, old connection still usable",
  "sessionLifetimeBoundary": "Ticket endtime does not by itself establish target session termination; service reauthentication and session state are separate."
}

İki yanlış kanı / Two reality checks

Sanılan: Bir hesabı devre dışı bıraktığımda o kimliğin tüm erişimi anında biter.

Gerçekte: Hayır. Disable userAccountControl içindeki ACCOUNTDISABLE (0x0002) bitini set eder ve yeni logon/authentication girişimlerini engeller; mevcut access token, kurulmuş session veya hedef hizmetin kabul ettiği ticket'ı geriye dönük geri çağırmaz. Yeni service-ticket isteğinin sonucu TGT'nin varlığından tek başına çıkarılamaz; KDC account/policy kontrolleri ayrıca önemlidir. Gerçek erişim kesme, hedef sistemlerdeki mevcut oturumları da ele almayı gerektirebilir.

Sanılan: 4740 olayındaki TargetDomainName kaynak bilgisayarı gösterir.

Gerçekte: Hayır. Domain account örneğinde TargetDomainName hedef hesabın domain bağlamıdır. Kaynak makine Microsoft'un 4740 dokümanında Additional Information / Caller Computer Name olarak ayrı tanımlanır. Event Viewer veya SIEM görünümünde bu iki alanı karıştırma; kaynak alanı eksik/boş olabilir ve IP adresi garantilemez. Subject'in genellikle Local System olması, Target ve Caller alanlarının anlamını değiştirmez.

Kaynaklar / Sources

• Microsoft · How to use the UserAccountControl flags to manipulate user account properties (KB305144)
  Property flags tablosu: ACCOUNTDISABLE = 0x0002; lockout state is read from the computed MS-ADTS attribute mapped separately.
• Microsoft · 4725(S) A user account was disabled
  Event XML (Version 0); Subject (SubjectUserSid/Name/LogonId) ve Target (TargetUserName/TargetSid) alanları; Audit User Account Management; domain controller, üye sunucu ve istemcilerde üretilebilir (ilgili hesap işleminin gerçekleştiği bilgisayarda).
• Microsoft · 4740(S) A user account was locked out
  Event XML'de TargetDomainName hedef hesap domain/computer bağlamı; Field Descriptions altında Caller Computer Name ayrı Additional Information alanı; Subject ve event üretim kapsamı.
• Microsoft · 4767(S) A user account was unlocked
  Unlock geçişinin audit kaydı; Subject ve Target alanları; Audit User Account Management alt kategorisi.
• Microsoft · Account lockout threshold (security policy setting)
  badPwdCount eşiği; Account lockout duration ve Reset account lockout counter after ile ilişki; 0 = kilitleme yok; DoS/brute-force dengesi.
• Microsoft · Enable Active Directory Recycle Bin in Windows Server
  Recycle Bin varsayılan olarak etkin değildir; önceden etkinleştirilmişse deletion sonrası korunmuş link/non-link attributes ve memberships restore edilebilir; feature öncesi silinen nesneler bu yolla kurtarılamaz.
• Microsoft Open Specifications · msDS-User-Account-Control-Computed
  AD DS computed ADS_UF_LOCKOUT (0x0010), lockoutTime ve effective lockout duration koşullarından hesaplanır; stored userAccountControl bit'i değildir.
• Microsoft · Bad-Pwd-Count attribute
  badPwdCount non-replicated'dır, her DC'de ayrı tutulur ve 0 değeri unknown anlamına gelebilir.
• Microsoft · Last-Logon-Timestamp attribute
  lastLogonTimestamp approximate ve replicated activity alanıdır; güncelleme msDS-LogonTimeSyncInterval'dan eski değer koşuluna bağlıdır.
• Microsoft Open Specifications · Tombstone Lifetime and Deleted-Object Lifetime
  tombstoneLifetime ve msDS-DeletedObjectLifetime değerleri/configuration; varsayılanlar forest geçmişi ve attribute durumuna bağlıdır.
• Access tokens
  Access token contents; primary and impersonation tokens
• RFC 4120 — Kerberos V5
  §3.2.1–3.2.3 AP exchange
• AD DS replication behavior
  Replication behavior overview
• Choose hybrid authentication
  Scope; PHS/PTA/federation; business continuity and account-state timing
• RFC 5280 — CRL profile
  §5.1.2.4–5.1.2.6 thisUpdate/nextUpdate/revokedCertificates
• Microsoft · Cached domain logon information
  Local cache verification versus domain-validated network access.
• Microsoft MS-SMB2 · Per Session
  Session.State/SecurityContext/ExpirationTime and reauthentication; not equal to a universal ticket endtime rule.