Sunday, 17 November 2013

Document tracking and tracing

Many years ago I was asked if it was possible to track when users opened specific word documents to figure out if confidential documents were openly being passed around the organisation or even sent out of the business over the before you say that this is done and dusted...I'm talking about a many years ago...

After playing around I figured out an ugly method and so I wrote a web interface to automate the entire process...of building a "phone home" word document and interface keeping track of the documents...I wrote the web interface entirely using Perl CGI....yes Perl...eek!

Since way back then there are now online services that offer a service like this for you and they can even track PDF's...

However after a recent exercise I needed to dig up the ugly Perl application and get it up and running. Looking at the ugly interface and too ashamed to let anyone else in the office look at the interface I decided it was time to redo the application from scratch and this time make it prettier and friendlier and add some extra I went with PHP (not that my PHP skills are that great) since that's all I am playing with at the moment.

So today I introduce to you a simple application that one can use to remotely trace and track when users open specially crafted word documents, and you can even use the URL to embed into other applications where needed.


Is a simple application that is used primarily to remotely track and trace custom Microsoft Word documents when opened by users (so far it works well on MS Word for Windows and Mac...I haven't tested on anything else). 

You can use it for the following:
  • Remotely track sensitive documents and keep an eye on where they are being opened
  • Use as a honey pot, store in sensitive shares that should never be opened to see if anyone that shouldn't open it does...
  • Use as a method to find the location of fraudsters and such by sending the phone home documents to them
The entire application is very basic, login, create a new "document", download the generated Word document, edit if you wanted to and save or send it wherever. Once the document is opened up you should receive an email notification informing you of the hit!

Here are some examples of the interface,in the below image, this is the main page, shows the users a list of documents Dracker is listening out for. You can see there is already one document that has been opened:

On the page as shown above users can create new dracks (phone home documents), download newly created tagged documents or delete the entry.

Selecting the "Opened" document, we can drill into some more details with regards to the opened document:

  • Incomming IP Address - Source of the phone home connection
  • Hostname - if it can be resolved at the time of connection
  • Proxy IP - Tries to determine if the Source IP is being proxied
  • Browser - Even MS word for Windows/Mac has a browser agent header
  • Operating System - Guesses the OS
Other details include IP address location, by selecting the source IP address...
There is also a configuration section so that you can setup your email sending settings and add users to the application:

 This is what a "tagged" word doc looks like:

And that's really it, pretty basic! I also made the setup really easy too, just copy to an apache webroot configure your mysql credentials...and your pretty much ready to play.

You can grab yourself a copy of the current stable'ish version at:

And be kind this is really my first release in many years...contribute...modify...or do nothing...if I ever get time on the weekends I may fix stuff or possibly further break stuff  (: Its not active development just something I play with from time to time.

Wednesday, 9 October 2013

Veil - Custom Metasploit Payloads

So I was looking into customizing Metasploit payloads to bypass antivirus and host intrusion protection, but my assembly, bit flipping skills are lacking...or none existent...

So in steps Veil, dont know why I only saw this recently but its a great tool for generating all kinds of custom Metasploit payloads. Developed using Python, Veil will run on Linux (already in Kali sources) and Windows. Its another great way to bypass antivirus to use the Metasploit tools for password audits and internal pen tests. 

We use it for a variety of legitimate reasons on the internal network. A good example is that we have a suite of McAfee products on a network/hosts with ePO. When we get an malware infection alert from a PC that is firewalled off and we cant access it, we get ePO to push and run the custom payload to the ePO agent on the box to pop a shell so we can access, analyse and clean if neccessary. Quite ironic I think (:

When running Veil you will notice the devs made the interface very similar to the Metasploit Console Interface. If your familiar with this then using Veil out of the box should be a breeze for you (:

I had some issues running Veil properly from Kali sources (issues using Wine with the default version of Veil at the time) so I downloaded the latest release from github, which also now support 64bit systems:

Once you got a copy from git, its very important to run the setup script which fetches some important...required files and gets it working with Wine (for automatic compiling python to EXE).

When I run Veil, one of the options I use is "compile_to_exe" which will run wine on Kali and compile the custom python payload to EXE for me. You don't have to do it this way and can output the python payload to file and compile later on a windows system to EXE use Python2EXE libraries.

The only thing to do now is setup a Meterpreter session to listen for your incoming custom payload. The compiled custom payload ran flawlessly on fully patched and up2date McAfee systems (AV and HIPS).  

You can use Veil with Cobalt strike beacon and a variety of other tools out there, the application is quite wide: 

for more info, videos and updates check out:

NB. Dont upload your new custom payloads to virustotal or similar to see if the custom payloads are detectable...rather test that it runs on your servers and antivirus products to ensure the payloads stay undetected for longer.

Tuesday, 17 September 2013


I have been working on a little something on the side for a while now, which was to hopefully improve my PHP, jquery, Ajax skills and to make the entire process vulnerability assessments, management and reporting easier for the stuff I do.

A good friend years ago told me that if your doing just about the same thing something over and over again, you can automate it!  

So I do a lot of pentesting internally for a financial institution were I officially work. The team has now finally grown from one/me to three....yay! Anyways I am always asked about my schedule, what is in the pipeline? who has free time? have the issues been remediated? can you retest? etc etc.

So awhile ago I tried building a sort of interface to parse Nessus scan output and put it in a nice interface, and the user can add manual vulnerabilities, see if some of the re-occurring automated scan results were improving or getting worse...a sort of diff to help me figure out whats changed. It was ugly but it sort of worked and still used today (eek).

However it got me thinking, how to improve the overall Internal Pentest Process, from management of pentesters, projects, vulnerabilities, reporting and management of the remediation and so on. So it would have to combine the managers, pentesters and end clients into one interface...a single central platform to host all of this...and it should be pretty or at least prettier than what I did before.

That same friend that gave me the previous advice, also said at a talk one day that hackers make the worst developers...I guess his right...but what the heck here goes!

Vulnerability & Assessment Management Platform

I present to you...not out of final testing yet...oneVault! 

Its no where close to release...although its pretty much finished in terms of all functionality, I just wanna do a few more things...but i figured I will start talking about it so long...

Its a central web platform to manage projects (assessments), pentesters, vulnerabilities and reporting. Its pretty much aimed at Internal Pentest Teams, I will try mention as much of the features I think are relevant but I wont get to them all. 

There are 3 main users:
  • Client
  • Pentester
  • Manager

Clients log in to the application and are presented with dashboards of information consolidating data from all the completed security assessments. Giving them a global overview of the technical risks they face. There is a nice little "tag" function which allows them to filter the dashboards on specific data/hosts/projects etc. 

They can then drill-in to specific completed projects, get a specific project dashboard and view hosts, and vulnerabilities. Client users can request specific hosts/vulnerabilities to be reviewed, which sends an email to the project pentester informing him of what the client has requested.

Each project will have an online report that the pentester compiled on oneVault there is also a default report to PDF generator that the pentester can use.

The client can also upload files to projects, to share with the pentester of a specific project, such as host information or architectural diagrams.


The pentester will also be presented with a variety of dashboards upon log in, showing him/her what projects they have completed, are busy with or in the pipeline. 

When working on a project the pentester can use a variety of tool output to help populte oneVault project data. Nmap host scans output (xml) can be uploaded, which will generate, hosts, ports etc.

Once there are targets, vulnerability data can be added to them. This can be done with manual testing and manually adding the vulnerability to the host, or with tool output, oneVault currently supports XML output from:
  • Nessus
  • Burpsuite
  • McAfee Vulnerability Manager
  • IBM AppScan

oneVault parses the data as best it can, populating hosts with data, if the host does not exist it will create and add on the fly. The pentester can also create specific notes within the project.

Another nice function built-in is the ability to upload evidence to the specific risk reported. Pentesters can take screenshots and upload it to a specific host vulnerability, which will replay the evidence in a step by step manor to the clients or pentester.

Reports can be enabled on projects, this section will let pentesters create online reports which can be generated into online PDF's as well. The pentester can create the Heading, write up information etc, I have included some key values that will generate specific tables with regards to the project in the online report. 

Then the "Technical Findings" heading is automatically created, building a table of all the technical vulnerabilities in the project.

I also have started on MS Word Template outputting. Here the pentester can upload a simple MS Word docx with specific key values in the document and oneVault will populate the fields with the specific project data...still to be further worked on and improved...

Methodology - These are pretty much important with regards to any sort of security assessment carried out. oneVault makes provision for this, there is a section that allows, pentesters, managers and admins to create methodologies, which are assigned to projects. These will help ensure that the pentesters keep to the methodology standard set by the company and ensure complete testing. This will also help new staff as the methodologies have tasks assigned which can detail exactly what the pentester should do, or tool to use. The pentester will check each task off, which goes to calculating to complete'ness of the project.

Vulnerability Knowledge Base - oneVault has a KB which is populated by pentesters, managers and admins. This allows the team to properly document specific vulnerabilities, remediation, risk rating etc. Helping provide detailed information that can be re-used for consistency in projects and reports back to business. When manually adding a vulnerability to a host, by typing the first portions of the Vulnerability Name, oneVault will fetch the details from the KB database and populate all the fields.


The manager has a global overview of all vulnerabilities etc. The managers can create new accounts and users, and create new projects and assign them to pentesters. 

All kinds of email alerts are built-in to inform the client or pentester of the project, keeping everyone up-to-date.

So that's really it from a high-level overview. I am still not sure what to do with oneVault (release or not to release, package it into a product) but I have a couple more idea's I want to implement into the project.

If your keen for a demo or have questions/idea's, email me at 'gareth at'

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.

Tuesday, 18 June 2013

Introduction to Android App Pentesting - Setting up the environment

A short while back I had to figure out how to setup and pentest an Android and iOS financial app. Not having done either before and not really finding too much information on the interwebs I took bits and pieces of what I did find and put it into the basic setup I am going to demonstrate in this short write up.

This is not an all-in-one from setup to haxor, just a guideline to the basic setup.

As mentioned above this is just an introduction to setting up my environment for an Android app pentest and some of the basic things to look for, there are some great sources of information on the different kinds of flaws and issues but to really understand the information, you need to setup your environment and start playing around.

Depending on the app your assessing you will be looking at different things, for instance; a banking application may store credentials in various databases or even keep a full history of the HTTP session in some cache files that could contain some sensitive information. Other apps may open up various holes on devices that allow another process to query sensitive data from the app your assessing via content-providers.

Anyways back to setting up the environment, I use a Mac but this can easily be tweaked to run on Windows or Linux.

Setup the Android Virtual Device (AVD)

You will firstly need to download and install the Android SDK (ADT Bundle), which can be found at the below link:

There are versions for Linux, Windows and OSX. The ADT Bundle contains everything you will need including Eclipse, ADT plugins and Android platform tools.

Extract the SDK to a folder then run the Eclipse application.

Once the Eclipse interface is up and running you can then create and setup a new Android Virtual Device (AVD). This will be the emulated device which you will use to install, run and test the Android app your going to assess. On the Eclipse interface find the Android Virtual Device Manager as seen in the below screen:

There are various options for creating a new device, I usually setup a tablet device but certain apps are built for phone or tablet specific displays.

Once created we can then use the SDK emulator tools (using a terminal or command prompt) under the following locations:


Now we can run the newly created AVD image, in the terminal we execute the following command:

./emulator –avd {AVD Name}

At this point the test device will boot up in a new window on your base machine.

Setting up a Proxy

If your app makes use of a browser/web service you can also boot the device up and set a default proxy, so that if your app is talking to a web service etc. you can use a great tool like Burpsuite to proxy all communications through for your tinkering.

./emulator –avd {AVD Name} –http-proxy

This can also be set inside the already booted up device:

Home > Settings > Wireless & Networks > Mobile Networks > Access Point Names

There are a few other ways to set proxies these are just the two I use
The default device is very clean with very limited apps installed.You can find various sources to install extra Google apps and such, but for now I will show you how to install the Android app you are going to pentest.

Installing Android Apk

To install .apk files to the virtual device we use a tool under the SDK tools folder (platform-tools, but this can change on different releases) called adb.

./adb install {path to .apk}

The app should now be available on the device, either on the home page or under the applications page. You can run it inside the device, perhaps first run it and let it do its thing before you start poking around at files, folders etc, get some real data in there.

Accessing the device - shell

You will now want to have shell access on the device. A shell on the device is a good starting point when playing with the app and seeing what the app installs, directories created, file permissions and data stored.

To get a shell simply use the adb tool:

./adb shell

By default Android apps are installed under the /data/data/ directory:

Inside the apps main directory there are some interesting folders and databases.

Android apps make use of sqlite databases for storage of all kinds of data which could include usernames, passwords etc. You will need to get familiar with sqlite3 commands to easily query the databases on the device.

There are a few commands to learn, but here are the basics:

.table – will list all the tables in the database
.schema {table name} – will list the table structure
.quit – will exit

Here’s an interesting find, inside the database is a table called password and httpauth. You can then query these with select * from password

That’s pretty much the basic environment setup.

Sieve - An App to Test

MWR have released an Android test app appropriately named Sieve. The app has all kinds of holes and flaws to find. You can download a copy from here:


I think when it comes to Android or iOS apps, data protection is about the most important category on the list, as these devices are more susceptible to loss and theft than regular computers. In addition to this, cached data may get copied to various machines that are used for syncing and data could be stolen from there.

It has been found that mobile operating systems can cache sensitive information such as keystrokes and create snapshots (screenshots of running applications) for extended periods of time. Applications on Android devices may store sensitive information in the form of temporary files, .localstore files, or in client side SQLite databases, .db.

For more details on Android and iOS secure development, which you can use to develop your own security tests from look at:

MWR Information Security, has also development an amazing tool called Mercury. Mercury is a framework for exploring the Android platform; to find vulnerabilities and share proof-of-concept exploits.

In fact MWR have a few papers on Android security and even won some own2pwn at CanSecWest, so look them up for more info, great bunch of guys!

Sunday, 26 May 2013

Introduction to my blog

So I have been in the infosec space for a good 13+ years now, 6 of them spent pentesting at SensePost in my younger years before heading up the Security Intelligence unit in a information security department in "government" and then starting my own sideline business and joining a specialist bank in South Africa as part of the Cyber Security Team (Red Team of course!).

Over the years I have contributed bits and pieces to the security community in the form of NASL's for Nessus, silly security testing tools and even co-authored a few chapters in the "Penetration Testers Open Source Toolkit" series published by Syngress Publishing:
  1. Penetration tester's open source Toolkit
  2. Penetration tester's open source Toolkit Volume 2
Other than that its been getting a bit stagnant lately, pretty busy at work I guess. However I decided to start a blog, like there aren't another 5 million or more out there like this (: But at the end of the day this is for me...I want a place to put some of my idea's down, keep a list of "how to's" and maybe someone else might find it useful in one way or another...and in some sort of way I feel like I am still contributing.

Some of my interests:
  • Web Application Testing
  • Network Assessments
  • Android Application Assessments
  • iOS Application Assessments 
  • Intelligence Acquisition and Provisioning
  • IT Fraud Detection and Alerting
  • Dev'ing stuff (Although a good friend of mine once said...hackers make the worst developers...he is probably right!) 
  • Tech (new tech...old tech...gadgets and more)
So anyways thats about it for now...the aim to hopefully post something at least once a month.