Post Exploitation: Etki Alanındaki Bütün Kullanıcıların Parola Özetlerinin Elde Edilmesi

Post Exploitation: Etki Alanındaki Bütün Kullanıcıların Parola Özetlerinin Elde Edilmesi

Sızma testi sırasında DC ele geçirildikten sonra gerçekleştirilecek adımlardan birisi etki alanındaki tüm kullanıcıların parolasının elde edilmesi gerekebilir. Bu amaçla, MSF smart_hashdump modülü kullanılabilir. Ancak DC gibi kritik bir makineye MSF ile bağlanmak istenmeyen şeylere sebep olabilir. Bu sebeple, sisteme daha az zarar verme ihtimali olan yöntemler kullanılması gerekebilir.

Bu yazıda DC'ye yetkili kullanıcı hakkı ile erişim elde ettikten sonra, NTDS.dit ve SYSTEM dosyaları elde edilecek ve daha sonra da kullanıcı parolalarının özeti elde edilecektir.

1) NTDS.dit ve SYSTEM Dosyalarının Elde Edilmesi

Etki alanı nesnelerine ait bilgiler temel olarak NTDS.dit dosyasında bulunmaktadır diyebiliriz. Bu dosya da SYSTEM dosyasındaki bir anahtarla (SYSKEY) şifrelenmiştir. Bu 2 dosya elde edilirse, etki alanındaki kullanıcıların parola özetleri elde edilebilir. Ancak bu 2 dosyaya erişim işletim sistemi tarafından engellenmiştir. Bu amaçla, Volume Shadow Copy kullanılabilir.

Shadow kopya oluşturmak için, öncelikle, işletim sisteminin kurulu olduğu ve NTDS.dit dosyasının tutulduğu disk'te "Configure Shadow Copies..." seçimi yapılır.

Sonrasında seçilen alan Shadow kopya oluşturma özelliği aktifleştirilir.

Uyarı mesajı gelirse, bu mesaj onaylanır.

Böylece ilk kopya oluşturulmuştur:

Shadow kopya oluşturma işlemi "Disable" butonu ile iptal edilebilir veya Setting butonu ile konfigüre edilebilir.

Oluşan Shadow kopya içerisinden NTDS.dit ve SYSTEM dosyalarını elde etmek için öncelikle tüm shadow kopyalar listelenir:

vssadmin.exe list shadows

Bu örnekte tek bir kere Shadow kopyası oluşturulduğu için, bir adet Shadow kopya listenmiştir. Bu dizin "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1" olarak belirtilmiştir. En sondaki ID değeri her Shadow için bir artacaktır.

Bu Shadow kopya içerisindeki NTDS.dit ve SYSTEM dosyaları herhangi bir yere (C:\Users\Administrators\Desktop gibi) kaydedilebilir.

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\ntds\ntds.dit C:\Users\Administrator\Desktop
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\config\SYSTEM C:\Users\Administrator\Desktop

Elde edilen bu dosyalar Kali bir makinenin üzerine alınabilir. Ancak etki alanında çok fazla nesnenin olması bu dosyaların boyutunun artmasına sebep olacaktır. Bu durum da ağ üzerinde anormallik tespiti yapan ürünlerin (ADS gibi) alarm üretmesine sebep verebilir.

Not: DC'nin arayüzüne erişmeden, komut satırını kullanılarak da Shadow kopya elde edilebilir:

vssadmin create shadow /for=c:

Not: SYSTEM dosyası komut satırından ele geçirmek için Shadow kopyası oluşturmaya gerek yoktur. Aşağıdaki komutun çalışması yeterlidir:

reg SAVE HKLM/SYSTEM C:\SYSTEM_Dosyasi

Bu dosyalar Kali bilgisayarın root masaüstüne kaydedilir.

2) Elde Edilen Dosyalardan Etki Alanındaki Kullanıcıların Parola Özetlerinin Elde Edilmesi

Bu başlıkta, kopyalanan NTDS.dit ve SYSTEM dosyaları kullanılarak, etki alanındaki kullanıcı parolaları elde edilecektir. Bu amaçla önce NTDS.dit veritabanından ilgili tablolar çekilecek, daha sonra da bu tablolardan istenen hesap bilgileri çekilecektir. Bu işlem için Google Code üzerindeki "libesedb" aracı kullanılabilir.

Harici linke erişildiğinde araç görülmektedir:

Araç Kali üzerine indirilir.

wget https://255adcba056b7d59fd55a94f0ea02de0cf110bfb.googledrive.com/host/0B3fBvzttpiiSN082cmxsbHB0anc/libesedb-alpha-20120102.tar.gz --no-check-certificate

Sıkıştırılmış dosya çıkarılır.

gunzip libesedb-alpha-20120102.tar.gz
tar -xvf libesedb-alpha-20120102.tar

Konfigürasyon işlemi gerçekleştirilir.

ls
cd libesedb-20120102/
ls
ls -la configure
chmod +x configure
ls -la configure
./configure && make

Sonrasında da esedbtools/ klasörüne girilerek /root/Desktop dizinine koyulan ntds.dit dosyasındaki tablolar dışarıya aktarılır.

cd esedbtools/
ls
./esedbexport /root/Desktop/ntds.dit

Dışa aktarım sonrası durum aşağıdaki gibidir:

ls
cd ntds.dit.export/
ls

Daha sonra dışa aktarılan tabloları kullanarak etki alanındaki kullanıcıların parolalarını elde etmek için NTDSXTRACT aracının ana sayfasına girilir.

Aracın 1.0 sürümü indirilir

cd /root/
wget http://www.ntdsxtract.com/downloads/ntdsxtract/ntdsxtract_v1_0.zip
ls
unzip ntdsxtract_v1_0.zip

Amaç, etki alanı kullanıcılarının parola özetini almak olduğu için dsusers.py betiği kullanılacaktır. Bu betik parametre olarak NTDS.dit içerisinden çıkartılmış olan veri tablosunu ve link tablosunu almakta, ayrıca SYSTEM hive dosyasını da kullanmaktadır.

ls
cd NTDSXtract\ 1.0/
ls
python ./dsusers.py /root/libesedb-20120102/esedbtools/ntds.dit.export/datatable.3 /root/libesedb-20120102/esedbtools/ntds.dit.export/link_table.5 --passwordhashes /root/Desktop/SYSTEM

Böylece etki alanındaki kullanıcıların parola özetleri bu şekilde elde edilmiştir.

Kaynak:
http://blog.walkerville.org/?p=486

İpucu: Kayıt Defteri’nden SAM ve SYSTEM Dosyalarının Elde Edilmesi

İpucu: Kayıt Defteri’nden SAM ve SYSTEM Dosyalarının Elde Edilmesi

Bir bilgisayardaki yerel hesapların parolaları LM ve NTLM ile özetlenerek, SYSKEY adlı verilen bir anahtarla da şifrelenerek Security Accounts Manager (SAM) dosyasında (veritabanında) tutulur. SYSKEY adı verilen bu anahtar SYSTEM dosyası içerisinde bulunur. SAM ve SYSTEM dosyaları, %SystemRoot%\System32\Config dizininde saklanır. Ancak işletim sistemi çalışıyorken bu dosyalara erişimler yasaklanmıştır. Bu sebeple, yerel kullanıcıların parolalarına ait özet bilgileri, bilgisayar çevrimdışı hale getirilerek alınabilir. Bunun için, bilgisayar USB/CD ile başlatılıp,  SAM ve SYSTEM dosyaları alınır.

• http://www.bilgiguvenligi.gov.tr/donanim-guvenligi/sam-dosyasi-ve-ramdeki-bilgilerin-guvenligi-2.html
• http://ertugrulbasaranoglu.blogspot.com/2012/12/ipucu-makineye-fiziksel-olarak-eriserek.html

Bunun yanında bilgisayarda yerel yönetici hakları elde edilebilmişse, çevrimiçi yollarla da parola özetleri elde edilebilir. Cain & Abel uygulaması bu amaçla kullanılabilir.

Ayrıca, SAM ve SYSTEM dosyaları kayıt defterinden de alınabilir. Bu işlem için, komut satırı yönetici modunda açılır ve aşağıdaki 2 komut çalıştırılabilir.

• reg save HKLM\SAM "C:\Users\Yerel Yonetici\Desktop\SAM”
• reg save HKLM\SYSTEM "C:\Users\Yerel Yonetici\Desktop\SYSTEM”

Bu dosyalardaki yerel kullanıcı parolalarının özetleri Ophcrack veya Cain & Abel gibi uygulamalarla elde edilebilir.

Exchange Server: Throttling Parameters and Policies

Exchange Server: Throttling Parameters and Policies

Exchange ortamındaki kaynaklar sistemin performansı üzerinde önemli bir role sahiptir. Bu kaynakların en uygun şekilde kullanılması gerekmektedir. Aksi halde güvenliğin temellerinden olan “Availability” zarar görür. Bu sebeple; HTS, ETS, MBS ve CAS üzerinde kaynak kontrolü için Throttling  İlkeleri adı verilen kurallar uygulanmaktadır. Kısacası, Throttling ilkeleri sunucularda kaynakların yetersiz durumuna gelmesini önlemek için posta ve bağlantılara konulan limittir. Böylece hem DoS gibi saldırılara karşı önlem alınmakta, hem de sistemin işleyişi kontrol altında tutulmaktadır.
Microsoft Exchange Throttling servisi, MBS üzerinde çalışması gereken kritik bir servistir.

HTS & ETS için kurallar
Bu sunucular taşıdıkları postalar için maliyet bilgisini tutarlar. Taşınan postanın maliyeti yüksek ise öncelik maliyeti daha düşük olan postaya verilir. Bu önceliklendirmenin yanında bir takım kısıtlar uygulanır. Bu kısıtlar, HTS ve ETS rollerine sahip sunucularda bulunan Send ve Receive Konektörleri üzerinde uygulanmaktadır. Uygulanabilecek bazı kısıtlamalar şu şekildedir:

• HTS’nin, MBS’a posta göndermek için veya MBS’dan mail alabilmek için açabileceği en fazla iş parçacığı(threads) sayısı kısıtlanmalıdır.
• ETS’a veya HTS’a  bir dakikada açılabilecek en fazla bağlantı sayısı kısıtlanabilir. Bu kısıtlama gelen postalar için Receive Konektör’de, giden postalar için Send Konektörde ayarlama yapılmalıdır. Ayrıca kısıtlama belli bir kaynak veya hedef ile olan iletişim için de belirlenebilir. Limit belirtilmezse, saldırı sırasında bağlantı sayısı çok artış gösterir ve posta ile iletişim gerçekleştirilemez. Ayrıca belli bir domaine giden posta sayısının kısıtlanması da sağlanmalıdır.
• Açık bir SMTP bağlantısının posta alımı veya gönderimi yapılmadan geçen süre için zaman aşımı uzunluğu kısıtlanmalıdır.
• Posta alınmasının devam etse bile, Receive Konektörü’nün bir bağlantıyı sürdürmesi için gerekli zaman aşımı süresi kısıtlanmalıdır.
• Bir SMTP bağlantısı boyunca, Send Konektör’ünden gönderilebilecek en fazla posta sayısı kısıtlanmalıdır.
• Tarpitting aralığı makul bir süre olarak belirlenmelidir.

CAS & MBS için kurallar
Bir kullanıcının yapacağı işlem tüm sistem üzerine çok büyük bir yük getirebilir. Örneğin bir arama işlemi bile sistemi çok fazla yorabilir. MBS, RPC yoğunluğunun arttığını tespit ettiğinde kaynak kısıtlamasına giderek interaktif kullanıcılara öncelik verir. Bu önceliklendirmenin yanında bir takım kısıtlar uygulanır. Uygulanabilecek bazı kısıtlamalar şu şekildedir:

• POP3 komut büyüklüğü kısıtlanmalıdır.
• Sunucunun kabul edeceği gelebilecek POP3 ve IMAP4 bağlantı sayısı kısıtlanmalıdır. Bu kısıtlama IP bazında, kullanıcı bazında veya toplam bağlantı sayısı bazında gerçekleştirilmelidir.
• CAS bağlantısı öncesi, kimlik doğrulama süresi kısıtlanmalıdır.
• CAS bağlantısı olan kullanıcının oturumu, bir süre işlem yapılmazsa zaman aşımına uğramalıdır.
• Bir istemcinin CAS üzerinde gerçekleştireceği işlemlerin süresi kısıtlanmalıdır. Bu süre; AD ile olan kimlik doğrulama için gerekli LDAP sorgu süresi, MBS ile olan RPC talebi süresi ve CAS üzerinde gerçekleştirilen işlemler için geçen sürenin toplamıdır. Bu süreler için kısıtlama ayrı ayrı olarak da gerçekleştirilmelidir.
• Bir kullanıcının postayı en fazla iletebileceği ve gönderebileceği alıcı sayısı kısıtlanabilir. Bunun yanında bir kullanıcının gönderebileceği en fazla posta sayısı için de kısıt uygulanabilir.
• ActiveSync  ile kurulabileceği ve silebileceği ortaklık sayısı kısıtlanabilir.
• Exchange Web Services, OWA, POP, RCA (RPC Client Access) veya ActiveSync kullanıcısının aynı anda yapabileceği bağlantı sayısı kısıtlanabilir.
• Bir posta içeriğinin veya ekinin büyüklüğü kısıtlanmalıdır. Böylece hem MBS üzerinde kaplanılan alan, hem de kullanılan bant genişliği kontrol altına alınır.

Parametreler ayarlanırken hiçbir parametre değerinin $null olarak ayarlanmaması tavsiye edilmektedir.

Exchange Server: Information Rights Management (IRM)

Exchange Server: Information Rights Management (IRM)

Mesajlaşma güvenliği için kullanılan tekniklerin bir takım eksiklikleri bulunmaktadır. Örneğin, TLS ile, iki SMTP makinesi arasındaki SMTP trafiği korunabilmektedir. Posta seviyesinde bir koruma gerçekleştirilememektedir. Posta, istemci tarafına ulaştıktan sonra herhangi bir koruma sağlamamaktadır. S/MIME ile PKI kurulmasında ise özel anahtarların saklanması, yapılan işlemlerin maliyeti problem olmaktadır. Bunun yanında posta deşifre edildikten sonra herhangi bir kontrol mekanizması da sunulmamaktadır. Posta şifresiz olarak kopyalanabilir, çıktı olarak alınabilir veya bir başka kullanıcıya iletilebilir. Kısacası, TLS ve S/MIME gibi güvenlik metotlarının belirtilen sınırları için yeni bir teknik uygulanmaya başlanmıştır: Information Rights Management (IRM)
IRM ile veri kaçağına, imaj kaybına, finansal kayba karşı önlem alınır.

IRM ile posta gönderildikten sonra, alıcı tarafında posta içeriği ve ekleri üzerinde ne gibi işlemlerin gerçekleştirilebileceği belirlenebilir. IRM kısıtları şu şekildedir (Bunlar AD RMS için geçerli):

• Full Control: Her işlem gerçekleştirilebilir.
• View: İçerik açılabilir.
• Edit: İçerik değiştirilebilir.
• Save: Kaydedilebilir.
• Copy: İçerik kopyalanabilir.
• Save: Kaydedilebilir.
• Print: İçerik çıktısı alınabilir.
• Access the message programmatically: Makro gibi programlar çalıştırılabilir.
• Forward: Posta iletilebilir.
• Reply: Gönderene cevap verilebilir.
• Reply All: Gönderene alıcı listesindekilerle beraber cevap gönderilebilir.

IRM ajanları HTS üzerinde çalışır. Bunun yanında, Active Directory Rights Management Services (AD RMS) ile de kullanılabilir. IRM koruması, AD RMS ilkelerinde belirlenerek gerçekleştirilir. IRM koruması Exchange Server 2010 ortamında şu yollarla gerçekleştirilebilir:

• Outlook kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler.
• OWA kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler.
• ActiveSync aygıtları ve Windows Mobile kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler. Windows mobile desteği olmayan cihazlarla da bu mesajlar alınabilir ve görüntülenebilir. Bunun için posta indirilmeden önce CAS’a SSL ile bağlanılmalıdır. Posta şifresi bağlantı kurulduktan sonra  çözülmektedir.
• Outlook 2010 kullanıcıları kural oluşturarak otomatik olarak IRM korumalı posta oluşturabilirler.
• Exchange Server 2010 HTS rolüne sahip sunucuda iletim kuralları ile otomatik olarak IRM korumalı posta oluşturulabilinir. 

IRM korumalı posta iletişimi organizasyon dahilindeki etki alanında, farklı forest’ları arasında, bulut tabanlı Exchange ortamları arasında gerçekleşebilir. Farklı bir federasyonda veya güven ilişkisinin olmadığı sistemlerle olan iletişimde kullanılamaz. Kullanılması için Windows Live ID hesabı ile AD RMS arasında bir güven kurulabilir.
IRM ile posta içeriğinin organizasyon tarafınca okunabileceği de unutulmamalıdır. Bu sebeple, S/MIME koruması aksine, IRM korumalı içerik deşifre edilerek taranabilir, politikalara göre filtreleme gerçekleştirilebilir. Ayrıca yasal denetimler için de kullanılabilir.

IRM’in eksiklikleri şunlardır:

• Postanın Windows Snipping Tool harici 3. taraf bir ekran kopyalama aracı ile ekran görüntüsü alınabilir.
• Kamera veya fotoğraf makinesi ile posta görüntülenebilir.
• El ile yazılarak veya ezberlenerek veri kaçağı gerçekleşebilir.
• Bir zararlı tarafından posta içeriği silinebilir, çalınabilir, bozulabilir.

Exchange Server: Sertifikalar && S/MIME

Exchange Server: Sertifikalar && S/MIME

Sertifikalar
Mail iletişimini daha güvenilir hale getirmek için sertifikalar kullanılabilmektedir. Exchange Server 2000 ve 2003 ortamlarında sertifika kullanımı yaygın olmamakla birlikte IIS üzerinde manuel olarak gerçekleştiriliyordu. Exchenge Server 2007 ile birlikte bu işlemler Exchange Management Console ve Exchange Management Shell üzerinde daha basit adımlar ile gerçeklenmeye başlamıştır.

Exchange Server 2010 üzerinde sertifika 5 servis için oluşturulabilmektedir. Bu servisler şunlardır:

• IMAP
• POP
• SMTP
• IIS (HTTP)
• UM (Unified Messaging)

Bu trafikler ve kullanan bileşenler şu şekildedir:

• SMTP: HTS ve ETS arasında veya ortak organizasyonlar arasındaki SMTP trafiğinde kimlik doğrulama ve şifreleme sağlamak için kullanılır.
• EdgeSync Senkronizasyonu: HTS ve ETS arasındaki LSAP iletişimini şifrelemede kullanılır.
• UM: UMS rolündeki sunucudan HTS rolündeki sunucuya, IP giriş kapılarına (gateway) ve Ofis İletişim Sunucuları’na (Office Communication Servers) giden SMTP trafiğini şifrelemek için kullanılır.
• Autodiscover: CAS ve istemci arasındaki HTTPS trafiğini şifrelemek için kullanılır.
• POP3/IMAP4: Posta alınması sürecinde şifreleme ve kimlik doğrulama için kullanılır.
• Outlook Anywhere: CAS rolündeki sunucudan istemciye giden trafik güvenliğini sağlamak için kullanılır.
• OWA: CAS rolündeki sunucudan istemciye giden HTTP trafiğinin güvenliğini sağlamak için kullanılır.
• ActiveSycn: CAS rolündeki sunucudan istemciye giden HTTP trafiğinin güvenliğini sağlamak için kullanılır.

Kullanılan sertifika güvenilir bir sertifika otoritesi tarafından onaylanmış olabileceği gibi, kendimiz de bir sertifika oluşturabiliriz. Kendimizin onaylayacağı sertifikada bir uyarı mesajının çıkabileceği, bu uyarı mesajını almamak için istemcilere onaylayıcının sertifikasının yüklenmesi gerektiği unutulmamalıdır. İç sistemlerde kendimizin imzaladığı, dış sistemlerde ise bir CA tarafından imzalanan sertifikaların kullanılması önerilmektedir.
Kendimizin onayladığı sertifikaları kullanabileceğimiz sistemler şu şekildedir:

• Hub Transport sunucuları arasına
• HTS ve ETS arasında
• EdgeSync trafiği için
• UM trafiği için
• Dahili CAS rolü sunucularında

CA tarafından onaylanan sertifikaları kullanabileceğimiz sistemler şu şekildedir:

• POP3 & IMAP4 trafiği için
• OWA için
• Outlook Anywhere
• ActiveSync için
• Autodiscover için

Ek Bilgiler:

• Exchange Server 2010 kurulumu sırasında varsayılan olarak SMTP sertifikası da oluşturulmuş durumdadır. Ama diğer iletişim protokolleri için sertifikalar, Exchange ortamı yöneticisi tarafından oluşturulmalıdır.
• Exchange Server 2013 kurulumu sırasında MBS üzerinde kendinden imzalı sertifika yüklü olarak gelmektedir. CAS, MBS üzerindeki sertifikaya güvendiği için kullanıcılar herhangi bir sertifika uyarısı almamaktadır.
• Sertifika oluşturulması için bakınız: http://www.cozumpark.com/blogs/exchangeserver/archive/2009/11/22/exchange-2010-sertifika-olu-turma.aspx

Secure/Multipurpose Internet Mail Extensions (S/MIME)
Sayısal imzalama gönderici taraflı kimlik doğrulama, bütünlük ve reddedilemezlik kazandırmak için kullanılan bir çözümdür. Sayısal imza ile, SMTP protokolünde olduğu gibi, posta açık olarak gönderilir. Base64 kodlama gerçekleştirilse bile şifreleme yapılmadığı sürece posta bir başkası tarafından okunabilir. Asimetrik şifreleme ile ise gizlilik, bütünlük ve alıcı taraflı kimlik doğrulama gerçekleştirilmektedir. Posta iletişiminde sayısal imzalama ve şifreleme kullanılması ile güvenlik arttırılması sağlanabilir. Bu amaçla posta içeriğine bir takım eklentiler konulmalıdır. MIME(Multipurpose Internet Mail Extensions) gönderilecek olan postaya resim, ses, görüntü gibi eklentileri eklemek için kullanılan bir internet standardıdır. Bu standarda bahsedilen güvenlik eklentilerinin eklenmesiyle yeni bir standart oluşturulmuştur. Bu standart S/MIME olarak adlandırılmaktadır. S/MIME temelinde asimetrik şifreleme ve sayısal imzalama yatmaktadır. S/MIME ile posta gönderilirken, önce göndericinin özel anahtarı ile imzalanır, sonra da alıcının genel anahtarı ile şifreleme gerçekleştirilir. Bu postayı alınırken, önce alıcının özel anahtarı ile şifre çözülür, sonra da göndericinin genel anahtarı ile doğrulama gerçekleşir. Böylece iki taraflı kimlik doğrulama, gizlilik, bütünlük ve reddedilemezlik sağlanır. Kullanılan sertifikalar etki alanını yöneticisi tarafından imzalanabildiği gibi, uluslar arası sertifika makamları tarafından da imzalanabilmektedir.

Ek Bilgiler:

• Bu şekilde iletişim için posta istemcisinin S/MIME desteğinin olması gerekmektedir. Örneğin, OWA’da, S/MIME ActiveX kontrolü kullanılarak sağlanır. Bu sebeple ActiveX desteği olan bir istemci tercih edilmeli ve ActiveX özelliği açılmalıdır.
• S/MIME desteği ilk olarak Exchange Server 2003 ile birlikte Outlook Web Access için yayınlanmıştı. Günümüzde bu destek gelişerek sürdürülmektedir. S/MIME v3 ile üç sarmallı bir iletişim (Triple-Wrapped Messages) sağlanmaktadır. Bu yapı ile önce imzalama, sonra şifreleme, sonra yine imzalama işlemi gerçekleştirilmektedir.
• S/MIME ile gerçekleşen operasyonlar ile güvenlik sağlandığı gibi, bu operasyonlar istemci tarafında gerçekleştiği için posta sunucusu için herhangi bir işlem maliyeti yoktur. Diğer taraftan, kullanıcıların özel anahtarları etki alanı sunucusunda tutulmadığı durumlarda, sunucu tarafında yöneticilere kontrol eksikliği oluşabilmektedir. Posta sunucusundaki imzalanmış ve şifrelenmiş posta okunamadığı için taşıma kuralları uygulanamaz, Anti-virüs/Anti-spam gibi çözümlerle zararlı tespiti gerçekleştirilemez, veri kaçağı anlaşılamaz. Bu durum da kontrol eksikliğine sebep olabilmekte ve yasal düzenlemelere karşı bulguya sebep olabilmektedir.

Kaynak site:
http://technet.microsoft.com/en-us/library/aa995740(v=exchg.65).aspx