Mimikatz ve WCE Gibi RAM Üzerinden Parolanın Açık Halini Ele Geçirebilen Araçların Çalışma Prensibi

Etki alanı sızma testleri sırasında Windows işletim sistemine yetkili erişim sağlandıktan sonra, gerçekleştirilen adımlardan birisi bellek üzerinden parolaların açık halinin elde edilmesidir. Bu amaçla WCE veya Mimikatz gibi araçlar kullanılabilmektedir. Bu yazıda, aktif oturumlardaki kimlik bilgilerinin RAM üzerinde nasıl saklandığı ve kimlik bilgilerinin açık halinin elde edilmesinin nasıl mümkün olduğu konuları incelenecektir.

Yerel kullanıcılara ait hesap bilgilerinin (hesap adları ve hesaplara ait parolaların özetleri) elde edilmesi için C:\Windows\System32\config dizini altındaki SAM ve SYSTEM dosyaları kullanılır. Bu işlemler için çeşitli yöntemler bulunmaktadır. Birçok son kullanıcı bilgisayarının bulunduğu etki alanı (domain) ortamlarında ise etki alanı kullanıcı hesaplarının bilgileri SAM dosyası yerine etki alanı denetleyicisindeki (DC) NTDS.dit dosyasında depolanmaktadır. Bu dosyaya yetkili kullanıcı hesabı ile erişilmesi durumunda ise etki alanındaki tüm kullanıcıların parola özetleri elde edilebilmektedir.

Bir kullanıcıya ait örnek hesap bilgisi (adı ve parolasının özeti) aşağıdaki gibidir:

Derya:1131:f26fb3ae03e93ab9c81667e9d738c5d9:47bf8039a8506cd67c524a03ff84ba4e

Yukarıda belirtilen Derya hesabının adı, SID değeri ve parola özetini içeren kayıt SAM veya NTDS.dit dosyasından alınmıştır. Bu kayıtta mavi ile belirtilen kısım, kullanıcının parolasının LM özeti, kırmızı ile belirtilen kısım ise NTLM özeti olmaktadır. Bu kayıtta LM parola özeti tutulduğu için, parola özeti değeri kullanılarak – bir takım araçlarla veya internet üzerinden – çok kolay bir şekilde parolanın açık hali elde edilebilir. Ancak, özellikle LM parola özetinin tutulmadığı durumlarda, sadece NTLM parola özetinden parolanın açık halinin elde edilme işlemi her zaman gerçekleşmeyebilmektedir veya çok uzun zaman alabilmektedir.

Kurumsal ortamlarda genellikle son kullanıcı bilgisayarları için Windows işletim sistemi tercih edilmekte olup, her bilgisayarın kurulumunda aynı imaj kullanılmaktadır. Bu imaj ile kurulum gerçekleştirildikten sonra, yerel ve gömülü (Built-in) kullanıcı hesaplarının parolaları genellikle değiştirilmemektedir. Etki alanı sızma testlerinde (domain pentest) kullanılan yöntemlerden birisi, bir şekilde sızılan ve yüksek yetki elde edilen bir bilgisayardaki gömülü yerel yönetici hesabına (Built-in Administrator) ait bilgilerin (hesap adı ve parola) alınmasıdır. Sızılan bilgisayardan alınan bu bilgiler erişim sağlanabilen diğer tüm bilgisayarlarda denenir. Böylece aynı imajın kullanıldığı (ve/veya gömülü yöneticilere ait hesap bilgilerinin aynı olduğu) bilgisayarlarda yüksek yetkilere sahip olunur. Kullanıcı hesaplarına ait parola özetlerini kullanılarak diğer bilgisayarlara erişim sağlanabilen bu yönteme Pass-the-Hash (PTH) adı verilir. PTH yöntemi ile kullanıcı adı ve parola özeti kullanılarak giriş yapılabilecek bilgisayarların tespit edilmesine dair örnek bir durum aşağıdaki gibidir:

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-01

Şekil – 1: Parola Özeti Kullanılarak Oturum Açma Denemeleri

Bazı durumlarda parolanın özeti yeterli olmayabilir. Örneğin, etki alanı parolası ile kimlik doğrulanabilen bir başka sisteme (Outlook web maile, veritabanı sistemlerine, VPN sistemlerine, vs.) bağlanılmaya çalışıldığı durumlarda parola özetinin elde edilmesi yetersiz kalabilmektedir. Benzer olarak birçok kimse aynı parolayı (gerekli olmamasına rağmen) birçok kritik sistemde kullanmaktadır. Bu gibi durumlarda parolanın kendisi (açık hali – plaintext) gerekmektedir. Yazı dizisinin konusu da parolaların açık olarak elde edilmesi ile ilgilidir.

Parolanın açık hali, Windows işletim sisteminde açılan bir oturumda – oturum süresi boyunca – bellek (RAM) üzerinde saklanmaktadır. Etki alanı sızma testlerinde (veya gerçekleştirilen bazı siber saldırılarda) RAM üzerinde kayıtlı bu bilgiler elde edilmeye çalışılmaktadır.

 

Windows İşletim Sisteminde Oturum Açma İşlemi İle İlgili Prosesler

Windows işletim sisteminde çalışan bir proses çekirdek modu (kernel mode) ve kullanıcı modu (user mode) olmak üzere iki farklı modda çalışabilir. Çekirdek modunda işletim sistemi bileşenleri çalışırken, uygulamalar kullanıcı modunda çalışır. İşletim sistemi bileşenleri yüklendikten sonra, kullanıcı modu ve etkileşimli oturum açma (interactive logon) işlemi başlayabilmektedir.

Kullanıcıya ait bu modda çalışan ilk proses Smss.exe prosesidir. Ana Smss prosesi her zaman sıfır numaralı etkileşimsiz oturumda bulunur ve başlatılacak olan her bir etkileşimli oturum için bir adet kopya Smss prosesi oluşturur. Oluşturulan kopya Smss prosesi ilgili oturuma ait Csrss ve Winlogon proseslerini oluşturup kendi çalışmasını sonlandırır. Aşağıdaki resimde de gösterildiği gibi PID değeri 368 olan Smss kendisinin iki kopyasını oluşturmuştur. 488 ve 624 PID değerlerine sahip olan kopya Smss prosesleri başka prosesleri oluşturduktan sonra sonlanmıştır. Prosesler arasındaki bu ilişki aşağıdaki ekran görüntüsünde görülmektedir:

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-02

Şekil – 2: Windows 7 İşletim Sisteminde Boot İşlemi Sonrası Çalılan Prosesler

Oturum işlemleri ile ilgili en önemli prosesler aşağıdaki gibidir:

  • Smss.exe (Session Manager Subsystem): Windows işletim sisteminin başlangıç prosesidir. Çevresel değişkenlerin oluşturulması, belirli (HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems altında belirtilen) alt sistemlerin başlatılması, bir takım proseslerin (csrss, wininit, winlogon) başlatılması en temel görevlerindendir.
  • Csrss.exe (Client/Server Runtime Subsystem): Thread ve Win32 konsolunun (metinsel arayüz, API kullanımı ile kullanıcı dostu arayüze sahip olunabilir) kontrolünden sorumlu olan prosestir. Temel olarak, kullanıcı modunda gerçekleşen bir çok görevin (task), çekirdek moduna erişmemesini (sistem çağrısının gerçekleştirilmemesini) sağlar.
  • Winlogon.exe: İşletim sisteminde oturum açılması ve kapatılması, LogonUI prosesinin oluşturulması, beklenmedik bir şekilde sonlanan LogonUI prosesinin yeniden başlatılması, kimlik doğrulama işlemi için LSASS prosesinin çağırılması, kullanıcı şifresinin değiştirmesi, iş istasyonunun (workstation) kilitlenmesi ve kilitli olan iş istasyonunun tekrardan açılması gibi işlemlerden sorumludur. Winlogon bu görevleri yerine getirirken, yetkisi olmayan başka bir prosesin bu işlemleri okuyamaması, değiştirememesi, kısaca araya girememesini sağlar. Winlogon SYSTEM haklarıyla çalışır, bu sebeple sıfır numaralı oturumda çalışmamaktadır. Windows ortamında etkileşimli her bir oturum için bir adet Winlogon oluşturulur. Sonraki başlıkta biraz daha detaya girilecektir.
  • LogonUI.exe: Kimlik bilgisi sağlayıcılarının (Credential Provider) yüklenmesinden ve oturum değişimi (açma ve kapama işlemleri sırasında) Windows etkileşimli oturum açma grafik arayüzünün gösterilmesinden sorumlu prosestir. Sonraki başlıkta biraz daha detaya girilecektir.
  • LSASS.EXE (Local Security Authority Subsystem Service): Kullanıcıların oturum açma işlemleri sırasında kimlik bilgilerini doğruluyan, parola değişikliklerinin gerçekleştirilmesinde görevli olan, kullanıcının yerel güvenlik ilkelerine (Security Policy) uymaya zorlayan, kullanıcı haklarına göre token oluşturan, göreviyle ilişkili bir olay olduğunda bu olayı Olay Günlüklerine (Event Viewer) yazan prosestir.

 

Winlogon ve Windows İşletim Sisteminde Oturum Açma İşlemi

Windows Vista işletim sistemi öncesinde (Windows XP, Windows Server 2003 gibi), her etkileşimli oturum için Winlogon prosesinin bir örneğini oluşturulurdu. Winlogon prosesi RAM üzerinde kendisine belli bir yer ayırmaktadır. Winlogon, bu yere GINA (Graphical Identification and Authentication) adı verilen DLL (dynamic-link library)’i yüklerdi. GINA da etkileşimli oturumda kimlik doğrulama işlemini gerçekleştirirdi.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-03

Şekil – 3: Eski Mimarideki Oturumlar

Ancak, bu (eski) mimaride Winlogon sıfırıncı (0.) oturumda çalışırdı. Yani kullanıcının açtığı oturum, sistem servislerinin ve kritik diğer proseslerin çalıştığı oturumla aynı oturumda işlem görmekteydi. Ayrıca kullanıcıdan hesap bilgilerini isteyen arayüz 3. taraf bir bileşen olarak kullanılmaktaydı.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-04

Şekil – 4: Windows XP İşletim Sİsteminde Oturum Açma Ekranı

Windows Vista işletim sistemi ve sonrasında (Windows 7/8, Windows Server 2008/2008 R2/2012 gibi) oturum açma mimarisi oldukça değişiklik göstermiştir. Yeni mimaride de her oturum için Winlogon prosesinin bir örneği oluşturulur. Ancak bu (yeni) mimaride, etkileşimli oturum direk olarak sıfırıncı (0.) oturumda işlem görmemektedir.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-05

Şekil – 5: Yeni Mimaride Oturumlar – 1

Bu mimari ile sistem ve kullanıcı prosesleri farklı oturumlarda işlem görmeye başlamış, çekirdek için RAM üzerinde ayrılan alana kullanıcı proseslerinin direk erişimi oldukça kısıtlanmıştır.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-06

Şekil – 6: Yeni Mimaride Oturumlar – 2

Yeni mimarideki önemli ikinci değişiklik ise, GINA yerine işletim sistemine gömülü (built-in) olarak gelen ve Winlogon tarafından oluşturulan LogonUI prosesidir. Yani, Winlogon prosesinin bellek alanında DLL kullanılması yerine ayrı bir proses oluşturulmuştur. Aşağıdaki ekran görüntüsü bir numaralı oturum açıkken alınmıştır. Birinci kullanıcı ilk oturum ile etkileşim içerisinde olduğundan dolayı LogonUI prosesinin çalışması sona ermiştir. İki, üç ve dört numaralı kullanıcıların açtığı iki, üç ve dört numaralı oturumlar açık olmasına rağmen kullanıcılar bu oturumlarla etkileşim halinde olmadığı için bu oturumlara ait LogonUI prosesleri çalışmaya devam eder.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-07

Şekil – 7: LogonUI Prosesi

LogonUI adında yeni bir proses oluşturulması sayesinde; kimlik doğrulama işlemi sırasında gerçekleşecek bir hatadan dolayı, Winlogon prosesi (ve tüm sistemin) beklenmedik şekilde sonlanmaması sağlanacaktır. Ayrıca, Winlogon prosesinin bellek alanında harici bir DLL’in kullanılmasından vazgeçilmesi, DLL açıklığından kaynaklı bir kötüye kullanımın da önüne geçmeyi amaçlamaktadır.

Yeni oturum açma mimarisinde göze çarpan bir iyileştirme de kimlik bilgisi sağlayıcılarıdır (Credential Providers – CP). Kimlik bilgisi sağlayıcıları, LogonUI prosesi tarafından yüklenirler ve Kayıt Defteri’ndeki “HKLMSoftwareMicrosoftWindowsCurrentVersionAuthenticationCredential Providers” anahtarı altında listelenirler.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-08

Şekil – 8: Kimlik Bilgisi Sağlayıcıları

Örneğin, GUID değeri “{6f45dc1e-5384-457a-bc13-2cd81b0d28ed}” olan sağlayıcı, varsayılan olarak parola bilgilerini alan sağlayıcıya (PasswordProvider) aittir. Bunun yanında akıllı kartlar, sertifikalar, biyometrik sistemler için de, Windows işletim sistemi tarafından kimlik bilgi sağlayıcıları kullanıma sunulmuştur.

Winlogon prosesi, LogonUI prosesini oluşturduğunda, LogonUI prosesi Kayıt Defteri’nden etkin olan kimlik bilgisi sağlayıcılarının listesini alır. Her bir sağlayıcı, LogonUI prosesine ihtiyacı olan arayüz bileşenlerini (metin kutusu, kontrol kutusu, buton vs) belirtir. LogonUI prosesi de bu teleplere uygun olarak bir arayüz oluşturur. Örnek bir arayüz aşağıdaki gibidir:

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-07

Şekil – 9: Özelleştirilmiş Oturum Açma Ekranı

Kullanıcı karşısına gelen arayüzde kimlik bilgilerini (kullanıcı adı, parola, parmak izi, retina, PIN, sertifika, vs) girer. Kimlik bilgi sağlayıcıları (CP); bu bilgileri alır, özel bir formata koyar (serialization). Daha sonra da, kimlik bilgi sağlayıcıları bu bilgileri, LogonUI prosesi aracılığıyla (veya direk olarak) Winlogon prosesine ulaşır. Winlogon prosesi de bu bilgileri, sıfırıncı oturumda çalışan LSASS prosesine göndererek kimlik doğrulama işleminde aracılık gerçekleştirir.

Oturum açma konusunda bu zamana dek bahsedilen işlemler aşağıdaki resimde özetlenmiştir.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-10

Şekil – 10: Kimlik Doğrulama İşlemi

Özetle, yukarıdaki işlemler sonucunda kimlik bilgileri LSASS.exe prosesine aktarılmış olur. Bu noktadan sonra kimlik doğrulama paketleri (Authentication Packages) ve kimlik verilerinin tutulduğu veritabanları (SAM dosyası, Aktif Dizin gibi) devreye girer.

 

LSASS ve Windows İşletim Sisteminde Oturum Açma İşlemi

Windows işletim sistemi üzerindeki kullanıcı kimlik bilgileri doğrulanma işlemleri için SSPI (Security Support Provider Interface) adı verilen özel bir mimari tasarlanmıştır. Kimlik doğrulaması ile ilgili tüm çağrılar (call) bu mimari temelinde ele alınır. Böylece hem Windows kimlik doğrulama mekanizmasını koruma altına almakta, hem de kendi kimlik doğrulama mekanizmalarını kullanmak isteyen geliştiricilerin Windows’un kullandığı kimlik doğrulama mekanizmalarının derinliklerine dalmasına gerek kalmamaktadır. Bu mimariyi tasarlayanlar, kimlik doğrulama işlemini istemci üzerinde (local) veya uzak bir sunucu ile istemci arasında (remote) güvenilir olarak gerçekleştirilmesini hedeflemişlerdir. Windows 7 ve Windows Server 2008 R2 mimarisindeki (ve sonrasındaki) varsayılan kimlik doğrulama sağlayıcıları (Security Support Provider – SSP), sisteme yüklenen DLL’leri kullanarak kimlik doğrulama işlemlerini gerçekleştirirler.

Kimlik bilgisi sağlayıcılarından (CP) geçen kimlik bilgileri Winlogon prosesine eriştiği konusuna değinilmişti. Winlogon prosesi LSASS prosesinin LsaLookupAuthenticationPackage fonksiyonunu çağırarak, bilgisayarın desteklediği bütün kimlik doğrulama paketlerinin (authentication packages) listesini elde eder. Winlogon prosesi, bu sefer LSASS prosesinin LsaLogonUser fonksiyonunu çağırarak, kimlik bilgisi sağlayıcısı (CP) için gerekli olan pakete kimlik bilgileri gönderir. Örneğin, MSV1_0.dll paketine kullanıcı adı ve şifre bilgisini gönderir.

Yerel bir sistem çağrısı ile gerçekleştirilen oturum açma işlemi temel olarak aşağıdaki gibi gerçekleşmektedir.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-11

Şekil – 11: Yerel Sistem Çağrısı ile Oturum Açma İşlemi

Kullanıcıdan alınan kimlik bilgileri yukarıda belirtildiği şekliyle ilgili SSP (Security Support Provider) tarafından sağlanan DLL’e aktarılır. Windows 7 ve Windows Server 2008 R2 (ve sonrasındaki) sistemlerde varsayılan olarak bulunan güvenlik destek sağlayıcıları (SSP) ve kullandıkları DLL’ler şu şekildedir:

  • Credential Security Support Provider – credssp.dll
  • Digest Security Support Provider – Digest.dll
  • Kerberos Security Support Provider – kerberos.dll
  • Negotiate Security Support Provider – lsasrv.dll
  • Negotiate Extensions Security Support Provider – negoexts.dll
  • NTLM Security Support Provider – msv1_0.dll
  • PKU2U Security Support Provider – pku2u.dll
  • Schannel Security Support Provider – Schannel.dll
  • Live Security Package – LiveSSP.dll

Bunların yannda Wdigest.dll, Kdcsvc.dll, Ntdsa.dll, Ntdsapi.dll vs gibi LSA bileşenleri de kimlik doğrulama işlemlerinde görev alır.

İşletim sisteminde kimlik doğrulama paketleri mevcut olduğu halde LSA (Local Security Authority) tarafından belleğe yükleme işleminin gerçekleşmezse bu DLL’ler kullanılamaz. Bu sebeple LSA tarafından bu paketler belleğe yüklenmelidir. LSA, hangi DLL dosyalarını yükleyeceğini kayıt defterindeki “HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages” kaydından alır. Bu kayıtta bulunmayan paketler belleğe yüklenmeyecek ve bu sebeple tercih edilen modda kimlik doğrulaması gerçekleşmeyecektir.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-12

Şekil – 12: Güvenlik Paketleri

SSP ve kimlik doğrulama paketleri ile ilgili ayrıntılı bilgi için bakınız:

  • http://technet.microsoft.com/en-us/library/dn169026(v=ws.10).aspx
  • http://technet.microsoft.com/en-us/library/dn169016(v=ws.10).aspx
  • http://msdn.microsoft.com/en-us/library/aa374733(v=vs.85).aspx

Sonuç olarak belleğe yüklenen DLL, kendisine açık olarak gelen kimlik bilgilerini alır ve işler. Yerel bilgisayarda yerel bir hesap için kimlik doğrulama işleminde MSV1_0.dll, etki alanındaki bir bilgisayarda etki alanı hesabı için kimlik doğrulama işleminde ise Kerberos.dll kütüphaneleri çağırılabildiği gibi, bir oturum kullanılarak başka sistemlerde de oturum açılması (Single Sign-on) belleğe yüklenen bu kütüphaneler kullanılarak gerçekleştirilir.

Kimlik doğrulama paketleri (authentication packages), bazı fonksiyonları kullanarak, parolayı (veya parolanın özetini) geri döndürülebilir olacak şekilde şifreli olarak saklamaktadır. Örneğin, standart Win32 fonksiyonlarından olan LsaProtectMemory fonksiyonunu kullanarak belirli bir adresten (Buffer) başlayarak belirli uzunluktaki (Buffer Size) bir bellek adres uzayını (memory address space) şifrelerken, LsaUnProtectMemory fonksiyonu ise aldığı parametrelere göre şifre çözme işlemini gerçekleştirir. Şifreleme işleminde kullanılan anahtarlar, bilgisayar ilk olarak başlatıldığında LSASS prosesi içerisindeki fonksiyonlar tarafından üretilir. LsalnitializeProtectedMemory fonksiyonu bu anahtarı üreterek LsaEncryptMemory fonksiyonunun kullanımına sunar. Şifrelenen veri, DLL’e göre, parola olabildiği gibi parolanın özeti de olabilir. Örneğin, MSV1_0.dll parolanın LM ve NTLM özet halinin şifresini saklamaktayken, wdigest.dll veya kerberos.dll ise parolanın kendisinin şifreli halini saklamaktadır. Böylece gerekli durumlarda (SSO gerektiren işlemler gibi) bu bilgiler, LSASS tarafından üretilen anahtar yardımı ile açık olarak elde edilebilmekte (parola veya parola özeti olarak) ve kimlik doğrulama işlemlerinde kullanılmaktadır.

Kimlik bilgilerinin bu şekilde (açık veya MSV1_0.dll için özet haline geri döndürülebilir olarak RAM üzerinde şifreli şekilde) saklandığı durumlardan bazıları aşağıdaki gibidir:

  • Bilgisayar başında konsoldayken oturum açıldığında,
  • RDP ile uzak masaüstü bağlantısı yapıldığında,
  • RunAs komutu kullanarak bir işlem gerçekleştirildiğinde,
  • Belirli bir kullanıcı hakkı ile servis çalıştırıldığında,
  • Kimlik doğrulaması için tasarlanan mimarideki bazı API’leri kullanan uygulamalarla işlemler gerçekleştirildiğinde, vs.

Bu noktadan sonraki konular yazının kapsamı dışında olduğu için değinilmeyecektir. Aşağıdaki resim kimlik doğrulamanın sonraki aşamalar için fikir vermektedir.

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-13

Şekil – 13: Oturum Açma İşlemi Mekanizması

Oturum açma işlemini bu yazı için tek bir cümleyle şu şekilde özetleyebiliriz: Oturum açmak için yazdığımız kullanıcı adı ve parola gibi bilgiler, belleğe (RAM) yüklenen ve kimlik doğrulama işleminde görev alan bazı kütüphane dosyalarında şifreli olarak saklanmakta ve bu bilgiler kimlik doğrulama işlemleri sırasında işlenmektedir. Aşağıdaki resim oturum açma işlemini özetlemektedir:

working-principle-of-tools-wce-and-mimikatz-that-obtains-clear-text-passwords-on-windows-session-14

Şekil – 14: Oturum Açma İşlemininin Özetlenmesi

 

Kaynaklar:

[1] http://www.bilgiguvenligi.gov.tr/windows-isletim-sisteminde-oturum-acma-islemi-winlogon.html
[2] http://msdn.microsoft.com/tr-tr/magazine/cc163489(en-us).aspx
[3] http://technet.microsoft.com/en-us/library/ff404303(v=ws.10).aspx
[4] http://blog.bga.com.tr/2013/01/mimikatz-ile-windows-sistemlerde.html
[5] http://ertugrulbasaranoglu.blogspot.com/2012/10/ipucu-wceden-kacnma-yontemi.html
[6] http://blog.opensecurityresearch.com/2012/06/using-mimikatz-to-dump-passwords.html
[7] http://technet.microsoft.com/en-us/library/cc778868(WS.10).aspx
[8] http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf
[9] http://www.ampliasecurity.com/research/WCE_Internals_RootedCon2011_ampliasecurity.pdf
[10] http://technet.microsoft.com/en-us/library/dn169026(v=ws.10).aspx
[11] http://technet.microsoft.com/en-us/library/dn169016(v=ws.10).aspx
[12] http://codeidol.com/community/windows/logon/25019/
[13] http://fr.slideshare.net/gentilkiwi/mimikatz-asfws
[14] http://www.sans.org/reading-room/pass-the-hash-attacks-tools-mitigation-33283
[15] http://danielaelmi.altervista.org/password-cracking-hashes-dumping-brute-forcing-auditing-and-privileges-escalation/
[16] http://www.blackhat.com/presentations/bh-dc-09/Muckin/BlackHat-DC-09-Muckin-vista-security-internals.pdf
[17] http://umut-simsek.blogspot.com/2013/04/hashini-seven-kovboy-heykrlara-karsi.html
[18] https://www.bilgiguvenligi.gov.tr/microsoft-guvenligi/bellekten-parolalarin-elde-edilmesi-1.html
[19] https://www.bilgiguvenligi.gov.tr/microsoft-guvenligi/bellekten-parolalarin-elde-edilmesi-2.html
[20] https://www.bilgiguvenligi.gov.tr/microsoft-guvenligi/bellekten-parolalarin-elde-edilmesi-3.html

 

 

 

Yazarın Bilgileri

Ertuğrul BAŞARANOĞLU
Ertuğrul BAŞARANOĞLU

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Kullanabileceğiniz HTLM etiketleri ve özellikleri: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Bu sayfada incelenen konulardan doğacak sorunlar kişinin kendi sorumluluğundadır.