Wednesday, October 1, 2014

I am not suffering from blogger’s block.

I post rarely on this blog, but not because I am suffering from blogger’s block; on the contrary, I have too many ideas and exciting things to share. Unlike writing about travel or weather however, digital forensic topics require more time to verify, test and research. Work eats up most of my time, so I have not much time left for blogging at the moment.



Currently, I am contributing to our Computer Forensic Company's blog, where you can always find fresh stuff under the NEWS section.

Social Media has finally caught up with me as well, despite my resistance. I recently started using Google+ for quick sharing, commenting or exchanging ideas. You can find me here .


Where time permits, I will try updating this blog as well, but no promises.

[Google+ is no more. Is the Internet a Living Thing?]

Wednesday, May 21, 2014

Disarming suspicious PDF files on Apple Mac

You can't be too careful these days when browsing the Internet. I tend to read a lot of documents in PDF, often emailed to me as attachments or downloaded directly from the net. Even if the document comes from a trusted source, I tend to run in through Didier Stevens's pdfid tool with -d for disarm argument. pdfid.py script is written in Python and disables the automatic actions and scripts in PDF. You can read a brief explanation about how it works here.

Most of the time I am online on my beloved MacBook Air. Running the script in command line in the middle of something can be disruptive.  To deal with this, I used Platypus tool (freeware) to quickly create an app, that simply sits on my desktop. When I get a PDF file, I just drag and drop it into this app, which I called PDFdisarm. The app is nothing but pdfid.py script GUI wrapper. A few seconds later it spits out a new version of the PDF file to the same location as the original. It adds ".disarmed.pdf" to the new PDF version. If you on Mac, you can simply download this app from here or make one for yourself.  MD5 [PDFdisarm.app.zip = 028f76abce5b6ea6f0425b34ebab9dd2]

Here are the instructions.

First, you need to download Platypus and the latest pdfid.py script. Open Platypus, then name your app, choose one of the default icons or use your own. Select Script Type as Python. Select Script Path and navigate to your saved pdfid.py script. Click Args button and add "-d" as Argument for Script.  Output can be Droplet or you can choose Progress Bar if you like. Secure bundled script is really optional.

Click to enlarge


Make sure to add '-d' argument for the script, not for Python interpreter!

Click to enlarge


Use Accept dropped items option to make sure you can drop files into your new app. You can specify the type of files to accept by entering pdf and removing default * symbol.

Click to enlarge


Click Apply and Create. If you followed these instructions, you should now have a useful app at your disposal. Don't forget to visit Didier Stevens's blog and say thanks for his great work.






Saturday, May 10, 2014

Distributed Processing Notes

I tested distributed case processing and password cracking today by adding Amazon EC2 instances to the local processing resources. Purpose - tmp improve processing (& decryption) speed with security and budget in mind. I used Amazon "compute optimised" instances "c3.8xlarge", each with 32 Virtual CPU; 60GB RAM; 2 x 320 (SSD) and 10 Gigabit Network. "c3.8xlarge" instance costs around $3 USD per hour. My Internet link was a bottleneck, because it only supports 15.62 Mbps (15615 kbps). I used 'soon to be decommissioned' Free LogMeIN service, participating nodes were setup as "MESH" Network. Free account only supports up to five nodes in Mesh network.



In order to use LogMeIN Hamachi, it must be installed on each computer. Windows Server 2008 OS had issues with failing to connect to tunnelling engine, so to save time Windows Server 2003 OS was used instead. No problems encountered with installing and connecting the instances to the Mesh. Perhaps Windows Server 2008 R2 or later OS would also work without too much tinkering. I called my network "Passware", but had to use network ID instead to connect each instance.


Firstly, Passware Password Recovery Kit Forensic was used to decrypt SAM + System registry files. The tool has its own integration with Amazon Cloud, however I always had connectivity issues with it. Additionally,  the purpose of this exercise was to make sure no data is transferred between the local network and external resources in a clear.

After the 1st EC2 instance was connected to the local workstation running Passware, I saw a significant improvement in speed compared to two (1CPU) local workstations at brute-forcing NTLM hashes.


When three remaining EC2 instances were connected, each added 153 000 000 pwd/sec to the pool.

AccessData Password Recovery Toolkit (PRTK), oclHashcat v1.20 and ElcomSoft Distributed Password Recovery, all produced decent results. I would be even more happier if I could make the new EC2 NVIDIA GRID GPU driver to work.

Distributed processing of evidence with X-Ways Forensics, NUIX and Forensic Toolkit (FTK) also produced some good results, however I would not call these tests scientific :-). 

X-Ways Forensics calls the process "Distributed Volume Snapshot Refinement". It splits  the task of processing different evidence objects of the same case between multiple computers, that must live on the same network to be able to process the evidence at the same time. 

NUIX is a completely deferent beast, it is the fastest evidence processing solution I ever worked with. My network has quickly became a bottleneck with NUIX, which was expected. 

Setting up FTK distributed processing engine took me some time ( configuring shares, DB connectivity etc.). Processing of 50 Gb E01 image was completed about 30% faster compared to a stand-alone machine.

Several Amazon EC2 instances provide 10 Gigabit Network option, which is more than enough for distributed processing. With faster internet connection at the lab it makes sense to use Amazon EC2 resources when time is limited or demand for these resources is higher then usual. Configuration time is relatively short, CPU overhead (due to encryption) is only slightly noticeable and Security should not be the issue with VPN tunnel established between all processing nodes. 



Monday, May 5, 2014

InfoSec To-Do list


Chief InfoSec Officer's (CISO) To-Do list as mentioned by E. Cole.