Active Directory’de “Sahte Parola Değişikliği” Nedir? Nasıl Çalışır, Neden Risklidir?

Active Directory ortamlarında parola yönetimi kurumsal güvenliğin en temel bileşenlerinden biridir. Özellikle servis hesapları, yönetici hesapları ve kritik yetkilere sahip kullanıcılar söz konusu olduğunda, parola yaşının düzenli olarak takip edilmesi büyük önem taşır. Çünkü eski ve uzun süredir değişmemiş parolalar, saldırganlar için ciddi bir fırsat yaratabilir.

Ancak burada pek çok kişinin gözden kaçırdığı önemli bir detay vardır Active Directory’de yıllardır var olan bir yöntem sayesinde, bir hesabın parolası gerçekte değiştirilmeden parola son değiştirilme tarihi güncellenebilir.

Yani sistem dışarıdan bakıldığında hesabın parolasını yeni değiştirilmiş gibi gösterir fakat gerçekte kullanılan parola aynıdır. Bu durum “sahte parola değişikliği” olarak adlandırılabilir.

Bu teknik özellikle parola yaşına göre tarama yapan güvenlik ekiplerini yanıltabilir. Çünkü birçok denetim mekanizması hesabın gerçekten hangi parolayı kullandığını değil yalnızca PasswordLastSet / pwdLastSet bilgisini kontrol eder. Eğer bu alan güncel görünüyorsa hesap sağlıklı ve yakın zamanda parola değiştirmiş gibi değerlendirilir. Oysa perde arkasında gerçek parola hâlâ eski olabilir.

Sahte parola değişikliği neden oluşur?

Bu davranışın temelinde Active Directory’nin çalışma mantığı yer alır. Bazı durumlarda servis hesaplarının veya yönetici hesaplarının parolasının değiştirilmesi gerekir. Fakat pratikte bu işlem her zaman kolay değildir.

Özellikle servis hesapları çoğu zaman uygulamalara, zamanlanmış görevlere, servis yapılandırmalarına veya entegrasyonlara bağlıdır. Parola gerçekten değiştirildiğinde bu bağımlılıkların da tek tek güncellenmesi gerekir. Bu da hem zaman alır hem de hata riskini artırır.

Tam da bu nedenle bazı yöneticiler veya yetkili kullanıcılar gerçek parola değişikliğini yapmak yerine sistemde yalnızca parola tarihi değişmiş gibi görünmesini sağlayabilir. Eğer ilgili hesap üzerinde pwdLastSet niteliğini değiştirme yetkisi varsa bu işlem teknik olarak mümkündür.

Aynı yetki Active Directory Users and Computers (ADUC) üzerinde bulunan “User must change password at next logon” seçeneğini işaretleme veya kaldırma imkânı da verir.

Normal şartlarda bu seçenek kullanıcının bir sonraki oturum açma işleminde parolasını değiştirmesini zorunlu kılmak için kullanılır. Ancak bu özellik kötüye kullanılabildiğinde veya denetimsiz bırakıldığında parola hiç değişmeden parola tarihi güncellenmiş gibi bir görüntü ortaya çıkarabilir.

Bu işlem teknik olarak nasıl çalışır?

Mantık aslında oldukça basittir. Diyelim ki hedef hesapta parola en son Ağustos 2025’te değiştirilmiş olsun. Yani hesabın gerçek parolası uzun süredir aynıdır.

Bu hesap üzerinde yeterli yetkiye sahip biri Active Directory Users and Computers konsolunu açarak ilgili kullanıcıya çift tıklar ve hesabın özelliklerini görüntüler. Ardından Account sekmesine geçer. Burada yer alan “User must change password at next logon” seçeneği işaretlenir ve Apply butonuna basılır.

Bu adım sonrasında dikkat çekici bir durum yaşanır hesabın PasswordLastSet bilgisi boş görünmeye başlar. Yani sistem bu kullanıcı için artık mevcut bir parola değişiklik zamanını göstermemektedir.

Bunun sebebi Active Directory’nin kullanıcıdan bir sonraki girişte yeni parola belirlemesini beklemesidir. Başka bir deyişle sistem hesabı “parola değişimi bekleniyor” durumuna alır.

Daha sonra aynı kutucuk tekrar kaldırılır yani işaret kaldırılıp yeniden Apply yapılır. İşte kritik nokta burada ortaya çıkar. Bu işlem sonrasında Active Directory, sanki parola gerçekten değiştirilmiş gibi davranır ve pwdLastSet alanını güncel tarih ve saat ile doldurur. Böylece dışarıdan bakıldığında hesap bugün parola değiştirmiş gibi görünür. Oysa gerçekte kullanılan parola hâlâ eski, yani örnekteki gibi Ağustos 2025’te belirlenmiş olan paroladır.

Kısacası burada yapılan şey, gerçek bir parola değişikliği değil; yalnızca parola değişmiş izlenimi oluşturmaktır.

Active Directory neden böyle davranır?

Bu davranış aslında bir güvenlik açığı olarak değil mevcut işleyişin doğal sonucu olarak ortaya çıkar. “User must change password at next logon” seçeneği işaretlendiğinde Active Directory kullanıcının mevcut parola durumunu geçiş aşamasına alır. Bu aşamada sistem kullanıcı henüz yeni parola belirlemediği için pwdLastSet bilgisini boş bırakır.

Kullanıcı gerçekten oturum açıp parolasını değiştirdiğinde ise sistem bu işlemi tamamlanmış kabul eder ve yeni tarih-saat bilgisiyle pwdLastSet alanını günceller. Fakat bu mekanizma kutucuğun manuel olarak açılıp kapatılmasıyla da tetiklenebilir. Sonuç olarak parola değiştirilmemiş olsa bile tarih alanı güncellenebilir.

Yani burada problem Active Directory’nin tasarım mantığının bazı senaryolarda manipüle edilebilir olmasıdır.

Bu durum neden tehlikelidir?

Bu yöntem ilk bakışta masum görünebilir. Sonuçta sadece bir tarih alanı değişiyor gibi düşünülebilir. Ancak güvenlik açısından etkisi oldukça ciddidir.

Kurumsal ortamlarda eski parolaları tespit etmek için sıkça parola yaşına dayalı denetimler yapılır. Güvenlik ekipleri genellikle belirli bir süredir değişmemiş parolaları riskli kabul eder ve bunları raporlar. Özellikle etki alanı yöneticileri, servis hesapları ve ayrıcalıklı hesaplar için bu tür kontroller kritik önemdedir.

Fakat saldırgan veya kötü niyetli bir iç kullanıcı ele geçirdiği bir hesapta bu tekniği uygularsa hesabın eski parolayla kullanılmaya devam etmesine rağmen sistem onu “yakın zamanda güncellenmiş” olarak gösterebilir. Böylece hesap, standart güvenlik taramalarından kaçabilir.

Bu da birkaç önemli riski beraberinde getirir:

• Birincisi güvenlik ekipleri yanlış bir güven duygusuna kapılır. Çünkü raporlarda parola yeni görünür.

• İkincisi aslında zayıf veya eski bir parola, ortamda kullanılmaya devam eder.

• Üçüncüsü saldırganlar kalıcılık sağlamak için bu yöntemi kullanabilir. Eski bir hesabı kontrol ettikten sonra, parolayı değiştirmeden sadece tarih bilgisini güncelleyerek dikkat çekme ihtimalini azaltabilirler.

Özellikle yüksek yetkili hesaplarda bu durum çok daha kritik hale gelir. Çünkü böyle bir hesabın parolasının gerçekten ne kadar süredir aynı kaldığını anlamak zorlaşır.

Bu yöntem hangi yetkilerle uygulanabilir?

Bu işlemin yapılabilmesi için saldırganın veya kullanıcının ilgili hesap üzerinde belirli değişiklik yetkilerine sahip olması gerekir. Özellikle pwdLastSet niteliğini değiştirme yetkisi önemlidir. Bu yetki doğrudan ya da dolaylı olarak “User must change password at next logon” bayrağını yönetebilme imkânı verir.

Her kullanıcı bu işlemi yapamaz. Ancak yanlış delege edilmiş izinler, hatalı yetki atamaları veya ele geçirilmiş yönetici hakları bu tekniğin uygulanmasını mümkün kılabilir. Bu yüzden yalnızca parola politikalarına bakmak yeterli değildir; aynı zamanda hangi hesapların hangi AD özniteliklerini değiştirebildiği de dikkatle incelenmelidir.

Saldırganlar bu tekniği nasıl kullanabilir?

Bir saldırganın eski bir parolaya sahip hesabı ele geçirdiğini düşünelim. Normalde bu hesabın uzun süredir parola değiştirmediği fark edilirse güvenlik denetimlerinde dikkat çekebilir. Ancak saldırgan ilgili yetkilere de sahipse, gerçek parolayı değiştirmeden sadece pwdLastSet bilgisini güncelleyebilir.

Bu sayede hesap sanki güvenlik politikasına uygun şekilde yakın zamanda parola yenilemiş gibi görünür. Güvenlik ekipleri eski parola avına çıktığında bu hesabı riskli listede görmeyebilir. Böylece saldırgan, ortamda daha uzun süre fark edilmeden kalabilir.

Bu durum özellikle “low and slow” yani dikkat çekmeden ilerlemeyi amaçlayan tehdit aktörleri için oldukça elverişlidir.

Bu tür sahte parola değişiklikleri nasıl tespit edilir?

Bu tekniğin en büyük problemi geleneksel parola yaşı kontrollerini yanıltabilmesidir. Bu nedenle yalnızca PasswordLastSet alanına güvenmek yeterli olmaz. Güvenlik ekiplerinin daha derin analizler yapması gerekir.

Bu amaçla geliştirilen PowerShell betikleri sayesinde etki alanındaki yönetici hesapları veya tüm kullanıcılar taranarak sahte parola değişikliği ihtimali olan hesaplar bulunabilir. Verdiğiniz içerikte de bu tür kontroller için hazırlanmış bir PowerShell scriptinden bahsediliyor.

Bu script, Active Directory’de gerçek parola değişikliği ile yalnızca tarih alanının oynanması arasındaki tutarsızlıkları daha geniş ölçekte tespit etmeye yardımcı olabilir.

Param
 (
    [atring]$Domain = $env:userdnsdomain,
    [switch]$CheckADAdmins,
    [switch]$AllUsers
 )

IF ( ($CheckADAdmins -eq $False) -AND ($AllUsers -eq $False) )
 { [switch]$CheckADAdmins = $True }

[string]$DomainDC = (Get-ADDomainController -Discover -DomainName $Domain).Name
[array]$DomainInfo = Get-ADDomain -Server $DomainDC

IF ($CheckADAdmins -eq $True)
 { 
    Write-Host "Discovering AD Admins..." -ForegroundColor Cyan
    [array]$ADAccountArray = Get-ADGroupMember -Identity 'Administrators' -Recursive -Server $DomainDC  
 }

IF ($AllUsers -eq $True)
 { 
    Write-Host "Discovering All User Accounts..." -ForegroundColor Cyan
    [array]$ADAccountArray = Get-ADUser -Filter * -Server $DomainDC  
 }

Write-Host "Identifying Fake Password Changes for Accounts..." -ForegroundColor Cyan
$ADAccountMetaDataArray = @()
ForEach ($ADAccountArrayItem in $ADAccountArray)
 {
    $ADAccountMetaDataValueArray = Get-ADReplicationAttributeMetadata -Server $DomainDC -Object $ADAccountArrayItem.DistinguishedName -prop unicodepwd,pwdlastset
    $ADAccountMetaDataValueArrayPwdLastSet = $ADAccountMetaDataValueArray | Where {$_.AttributeName -eq 'pwdLastSet'}
    $ADAccountMetaDataValueArrayunicodePwd = $ADAccountMetaDataValueArray | Where {$_.AttributeName -eq 'unicodePwd'}

    $ADAccountMetaDataValueArrayPwdLastSetDate = ($ADAccountMetaDataValueArrayPwdLastSet.LastOriginatingChangeTime).ToString('yyyy-MM-dd')
    $ADAccountMetaDataValueArrayunicodePwdPwdDate = ($ADAccountMetaDataValueArrayunicodePwd.LastOriginatingChangeTime).ToString('yyyy-MM-dd')


    IF ($ADAccountMetaDataValueArrayPwdLastSetDate -eq $ADAccountMetaDataValueArrayunicodePwdPwdDate)
     { $DidPasswordChangeValue = $True }
    ELSE
     { $DidPasswordChangeValue = $False }

    $ADAccountMetaDataRecord = [PSCustomObject]@{
        AccountID              = $ADAccountArrayItem.SAMAccountName
        AccountDN              = $ADAccountArrayItem.DistinguishedName
        PasswordLastSet        = $ADAccountMetaDataValueArrayPwdLastSet.LastOriginatingChangeTime
        PasswordLastChanged    = $ADAccountMetaDataValueArrayunicodePwd.LastOriginatingChangeTime
        PasswordChanged        = $DidPasswordChangeValue
      }
    [array]$ADAccountMetaDataArray += $ADAccountMetaDataRecord
 }

IF ($CheckADAdmins -eq $True)
 { 
    Write-Host "$Domain AD Admin Account Password Changes:" -ForegroundColor Cyan
    $ADAccountMetaDataArray | Sort AccountID | Format-Table -AutoSize
 }

IF ($AllUsers -eq $True)
 { 
    Write-Host "$Domain Domain Accounts with Fake Password Changes:" -ForegroundColor Cyan
    $ADAccountMetaDataArray | Where-Object {$_.PasswordChanged -eq $False} | Sort AccountID | Format-Table -AutoSize
 }

Böyle bir kontrol yaklaşımı özellikle şu ortamlarda çok değerlidir:

• Çok sayıda servis hesabının bulunduğu yapılarda
• Eski uygulamaların hâlâ çalıştığı kurumsal sistemlerde
• Ayrıcalıklı hesapların yoğun kullanıldığı yönetim altyapılarında
• Düzenli parola rotasyonu gerektiren güvenlik politikalarının olduğu ortamlarda

Kurumlar bu riski azaltmak için ne yapmalı?

Bu riskin azaltılması için öncelikle şunu kabul etmek gerekir Active Directory’de parola tarihi tek başına mutlak güvenilir bir gösterge değildir. Bu yüzden kurumlar denetim yaklaşımını daha katmanlı hâle getirmelidir.

İlk olarak pwdLastSet gibi kritik öznitelikler üzerinde kimlerin değişiklik yapabildiği dikkatle denetlenmelidir. Gereksiz delege edilmiş yetkiler kaldırılmalı ayrıcalıklar minimum seviyede tutulmalıdır.

İkinci olarak servis hesapları için manuel ve belgesiz parola yönetimi yerine merkezi parola kasaları PAM çözümleri veya otomatik parola rotasyon sistemleri kullanılmalıdır. Böylece hem gerçek parola değişiklikleri güvenli şekilde yapılır hem de bu tür manipülasyonlara ihtiyaç kalmaz.

Üçüncü olarak ayrıcalıklı hesapların parola yaşam döngüsü yalnızca son değiştirilme tarihine bakılarak değil event log’lar, yetki değişiklikleri ve hesap aktivitesiyle birlikte değerlendirilmelidir.

Dördüncü olarak şüpheli değişiklikleri tespit etmek için düzenli PowerShell taramaları veya güvenlik araçları kullanılmalıdır. Özellikle yüksek yetkili hesaplarda yapılan pwdLastSet değişimleri beklenmedik yönetim işlemleriyle birlikte korele edilmelidir.

Kaynak : https://github.com/PyroTek3/ActiveDirectory/blob/main/Get-FakePWChanges.ps1