Wednesday, 31 July 2013

How to Audit Active Directory Domain Accounts - Without lighting up Antivirus etc

Recently I wanted to do an audit of weak administrative and service accounts on Active Directory. I had the usual tools ready, Metasploit, pwdump/fgdump and all the auxillary modules that go with dumping that.

The only problem was that the payloads from Metasploit and even the pwdump list of tools lit the anti-virus/host intrusion services running on the AD server in question. I had to figure out a legit way to get the dumps from the domain controller, so I went researching.

Now there's a ton of articles on how to do this on the interwebs, I am just putting it all in this post so I have my own little place of 'how to'...use it don't use it.

Also I am just running through the commands here, take your time and see all the different switches and options for each of the tools.

So with Active Directory gone are the days of SAM dumps etc, enter NTDS.DIT (New Technology Directory Services, the DIT stands for Directory Information Tree). Active Directory stores credential information within a database engine called Extensible Storage Engine (ESE) based of the Jet database and used by Exchange v5.5 and WINS.

Essentially this is the file you want off the Domain Controller to extract the stored password hashes in the database and link_table inside.

To grab the NTDS.DIT file from the Domain Controller, without lighting up the alerts and doing this in a legit manner, enter Volume Shadow Copying Service (VSS)

Volume Shadow Copying Service (VSS)

To use VSS you will need administrative privileges on the domain controller your doing to 'dump' the ntds.dit file from. VSS comes packaged with Windows by default so no worries about uploading tools and triggering anything suspicious. 

Step 1 - Create a Shadow Copy Drive

Usually the ntds.dit file is stored by default on the C: drive, it would be unusual for it to be under another drive, but it is possible, so to create the shadow drive run the following command:

vssadmin create shadow /for=C:
You can see if it was successful by the output from the command or afterwards you can run

 vssadmin list shadows

Step 2 - Copy the Required Files off

We're going to copy two files off the server, NTDS.DIT and the SYSTEM hive file. My layout was as follows, yours may differ:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\NTDS\NTDS.dit c:\temp\NTDS.DIT
 copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\SYSTEM.hive
 I usually copy it directly off to a remote server, some NTDS.DIT files can be pretty big, so choose the location with enough drive space.

Now we need to quickly clean up and remove the Shadow Drive

  vssadmin delete shadows /for=C:

Step 3 - Extract the Required Tables from NTDS.DIT

There are going to be two main sets of tools, for Linux, we use to extract the NTDS.DIT tables and then extract user account information and password hashes.

NTDSXtract -


I used Kali/Backtrack for this. Firstly extract libesedb and compile it, you should know by know how to do this...
# tar zxvf libesedb-alpha-20120102.tar.gz
# cd libesedb-20120102
# ./configure 
# make
# make install
# ldconfig
If you are copying the NTDS.DIT/SYSTEM.hive files to your kali box, be it a virtual machine or physical, make sure the entire file copies across or like me you spend a day and a half trying to figure out why the tools keep crashing (;

Ok so libesedb is installed, now we can extract the stored tables, there are 12 tables to extract:
# esedbexport NTDS.DIT
The default settings will create folder like ntds.dit.export/ filled with extracted data, we are only interested in the database.3 and link_table.5 databases.

Next extract NTDSXtract and run the python script (there are a  few, I suggest play with them all). This is going to extract the NT hashes from the tables, you will need the SYSTEM.hive file too for this.
# python ../ntds.dit.export/datatable.3 ../ntds.dit.export/link_table.5 --passwordhashes ../SYSTEM.hive --passwordhistory ../SYSTEM.hive
I would suggest pumping the output to a file ( > to_somefile.txt).

Step 4 - Start the Cracking...

Now the file we pumped the output from is not nicely formatted, useful yes but we just want to extract the hashes, if you google around a bit you may find a Perl script or two that will take the output and copy the hashes to a file nice and clean.

(google: Perl script to parse the output from NTDSXtract)

Once you extract the hashes from this file you can run it directly in your favorite <insert tool name here> (: for instance:
# john /root/my_password_hashes.txt
Also, during this time, I came across a nice little tool from Digininja, called Pipal. Once you have your list of cracked passwords you run pipal to do some nice analysis of the discovered passwords. I found it rather useful.

Pipal -


So this is the quick'ish, clean and manual way of doing it, afterwards I found that Metasploit also has a module to do exactly as mentioned above with the VSS copy and cleanup, however I didnt get it to work right the first couple of times.

I must say, the results have been interesting and scary! Lots of work to be done after opening this can of worms!

Then lastly, I have been following an interesting tool/service to be released by Praetorian called PWAudit and it looks extremely promising and bad ass! 

sign me up!!!

Friday, 5 July 2013

Introduction to iOS App Pentesting - Setting up the environment / Things to look out for

In my previous blog, I went on about setting up the basic environment with regards to Android app pentesting. Its even easier with iOS application testing, keeping in mind that you will be using a Mac and Xcode.

My setup is as follows:
  • Mac OS X 10.8.4
  • Xcode 4.6.2 
  • The Xcode Project of the Application I am assessing
Since the latest iOS/Xcode versions I have not seen an iPad or iPhone simulator for other operating systems, so I get the full Xcode project from the developers, compile and run the application via the iPhone/iPad Simulator inside of Xcode.

So I have my iOS application running in the Xcode iPhone Simulator, the below is one of many different kinds of password managers and already I have some data in it:

The simulator and running application are all placed under a specific folder on your Mac, the default location can be found here:

/Users/<username>/Library/Application Support/iPhone Simulator/*.*

As my password manager application is running on iOS 6.1 it will be placed under the 6.1 folder:
/Users/<username>/Library/Application Support/iPhone Simulator/6.1/<hash value>

Using a terminal one can access the directories and start looking at the application file and folder permissions. iOS apps store tons of data in sqlite and Cache files, as with this application I found that the stored username and passwords are stored in the clear.

Under the applications installed folder on the simulator, I simply run a grep for my details:

I open the file pmdb, with a SQLITE viewer and find all my details stored in the clear on the device:

Now if my device were stolen and the perp rooted the phone he could essentially gain access to all my stored credentials for anything I saved within the application.  

Once again when it comes to mobile application security its mostly about Data Protection, financial apps should be protecting user data and keeping very little sensitive data on the device, if at all!

Some tips when looking at iOS apps:

Keyboard Cache
Keystrokes entered on iOS devices could potentially get cached in the 


file stored in the device operating system for auto-correction dictionaries. This functionality is similar to the AUTOCOMPLETE for web browsers. If AUTOCOMPLETE is not set to off for the UITextField then text in these fields could be cached.

Every time a user tabs the Home button from within a iOS application, the window of the application shrinks and disappears. In order to create the shrinking effect, the device takes an automatic screenshot. These snapshots are stored in the snapshots directory of the application.

For example:

~/Library/Caches/Snapshots/<app being assessed>/* 


If iOS applications use the UIPasteBoard for copying and pasting objects, this information could be obtained by other applications from the clipboard. In addition to this if the persistent pasteboard property is used by the developer, the copied information will be stored unencrypted on the devices file system and can be found at:


If the application contains sensitive information, it is therefore critical for them to use private pasteboards for copy and paste operations. Also the persistent property should be used at a minimal.

SQLite Database

iOS applications store client side data in SQLite databases on the device under various locations under the applications install folder. Information in these databases is often not encrypted and can therefore contain sensitive data such as passwords, usernames, keys etc. It may even contain application state information, which could be altered to bypass the application logic.

Property List (.plist files)

Property list files are not a good place to store sensitive information. Instead applications should store sensitive data in the keychain. Apple uses sandboxing functionalities to limit access from one application to another application’s data. However, despite sandboxing of applications numerous application property files are readable by other applications. This is because of the loose sandbox rules.