Thursday, July 26, 2012

Introduction to Penetration Testing – Part 3a – Active Reconnaissance

by Si Biles, Thinking Security

Apologies in advance, this is a bit of a connective blog entry – this is a big topic, and it needs some scene setting, basic understanding and several weeks worth to get the most out of it.

We live in a connected world now – my other half was showing me a washing machine with a WiFi connection and an associated iPhone App that would allow you remote control of and reporting about your intimate garments spin cycle ! I wonder if that is really necessary to be honest, as even if it has finished, knowing that while I’m in the office and the washing machine is at home is a complete waste of electrons.

The network, and the connected nature of things is what allows us as penetration testers to attempt to compromise the security of a company without going anywhere near it. There are other aspects to full scale penetration testing as I’ve alluded to before – with social engineering and physical attack ( lock picking, not baseball bat ) parts of such a scope – but a majority of the work is computer and network based.

To that end, a good understanding and working knowledge of networking is pretty much a job pre-requisite. So, rather than giving you a lesson myself, I’ll give you a quick and dirty set of online references – this won’t make you an expert by any stretch of the imagination, but hopefully it will get us through the rest of this section without too much head scratching.1
I would apologise for the laziness on my part, however I subscribe to Larry Wall’s school of thought that it is a virtue – if someone else has done it well enough already, why spend time re-inventing the wheel. The corollary of that is, if you find that there isn’t a good explanation of something in that set that you’d like to understand better – add a comment on the bottom of this post and we’ll bring it up to scratch ( perhaps both here and at Wikipedia ;-) ).

So seing as you all now fully understand TCP/IP packet structure and know your URG from your SYN …

Read more

Tuesday, July 24, 2012

Authenticating Internet Web Pages as Evidence: a New Approach

By John Patzakis [1] and Brent Botta [2]

Previously, in Forensic Focus, we addressed the issue of evidentiary authentication of social media data (see previous entries here and here). General Internet site data available through standard web browsing, instead of social media data provided by APIs or user credentials, presents slightly different but just as compelling challenges, which are outlined below. To help address these unique challenges, we are introducing and outlining a specified technical process to authenticate collected “live” web pages for investigative and judicial purposes.[3] We are not asserting that this process must be adopted as a universal standard and recognize that there may be other valid means authenticate website evidence. However, we believe that the technical protocols outlined below can be a very effective means to properly authenticate and verify evidence collected from websites while at the same time facilitating an automated and scalable digital investigation workflow.

Legal Authentication Requirements

The Internet provides torrential amounts of evidence potentially relevant to litigation matters, with courts routinely facing proffers of data preserved from various websites. This evidence must be authenticated in all cases, and the authentication standard is no different for website data or chat room evidence than for any other. Under US Federal Rule of Evidence 901(a), “The requirement of authentication … is satisfied by evidence sufficient to support a finding that the matter in question is what its proponent claims.” United States v. Simpson, 152 F.3d 1241, 1249 (10th Cir. 1998).

Ideally, a proponent of the evidence can rely on uncontroverted direct testimony from the creator of the web page in question. In many cases, however, that option is not available. In such situations, the testimony of the viewer/collector of the Internet evidence “in combination with circumstantial indicia of authenticity (such as the dates and web addresses), would support a finding” that the website documents are what the proponent asserts. Perfect 10, Inc. v. Cybernet Ventures, Inc. (C.D.Cal.2002) 213 F.Supp.2d 1146, 1154. (emphasis added) (See also, Lorraine v. Markel American Insurance Company, 241 F.R.D. 534, 546 (D.Md. May 4, 2007) (citing Perfect 10, and referencing MD5 hash values as an additional element of potential “circumstantial indicia” for authentication of electronic evidence)...

Read more

Thursday, July 19, 2012

"Finding Evidence in an Online World" webinar recording and PDF now available

A recording of this week's webinar "Finding Evidence in an Online World - Trends and Challenges in Digital Forensics" is now available here and on YouTube here.

Sincere thanks to Jad Saliba for agreeing to re-record the presentation yesterday as a result of the audio issues we experienced during the live version. Also, a number of people requested a PDF version of the slides and Jad has kindly made that available here.

A free trial of IEF (the software used in the presentation) is available at and for details of a 10% discount available until August 1st 2012 please contact

Saturday, July 14, 2012

Retrieving Digital Evidence: Methods, Techniques and Issues

by Yuri Gubanov
Belkasoft Ltd.

This article describes the various types of digital forensic evidence available on users’ PC and laptop computers, and discusses methods of retrieving such evidence.

A recent research conducted by Berkeley scientists concluded that up to 93% of all information never leaves the digital domain. This means that the majority of information is being created, modified and consumed entirely in digital form. Most spreadsheets and databases never make it on paper, and most digital snapshots never get printed. There are many activities such as chats and social networking that are specific to digital and are even unimaginable outside of the virtual realm.

Most such activities leave definite traces, allowing investigators to obtain essential evidence, solve criminal cases and prevent crimes. This article discusses the many types of digital evidence produced by a typical computer user, criminal or not, and demonstrates methods and techniques available to extract that evidence out of the original PC and into the hands of a forensic investigator...

Read more

Friday, July 13, 2012

Parallels hard drive image converting for analysis

by zoltanszabodfw

The other day, talking to one of the analysts in Dallas, a question emerged about analyzing Parallels’ virtual machine hard drives.  To my surprise, I did not find many help on this issue on-line and did not find tools that would interpret the file system in Parallels’ hard drive images.  The simplest way I wanted to approach this issue is by converting the hard drive image to something simpler like a dd image.  I found a very nice article on how to convert to a plain hard drive image using Parallels Image Tool that comes with Parallels Desktop(, but I had no access to a Mac and wanted to see if there is a way to do this on Windows.  There was VMware vCenter Converter ( free software – ), but it did not by giving a message the it could not recognized it.  I also found an interesting tool MakeVM – that looked very promising, but the demo version would not convert an image size larger than 2GB.  So, I wanted to look further into other options.  This article is about the findings of that “journey”.

Parallels Workstation comes with a few command line tools for basic drive manipulation like prl_disk_tool or prl_conver, but the best converter, I found, is the latest Open Source project QEMU. -

One of the utilities in QEMU is qemu-img where the help file reveals the value of this simple utility, when it comes to converting image types.  The latest version just added the parallels’ image format support.  “Supported formats: blkdebug blkverify bochs cloop cow dmg nbd parallels qcow qco w2 qed host_device file raw sheepdog vdi vmdk vpc vvfat”
Step 1. I have downloaded Parallels Workstation trail version to create a virtual machine for testing and to make sure my findings will be applicable to the latest version of Parallels.

Parallels Workstation Build 6.0.13976
( Revision 769982; June 8, 2012 )

Step 2. Created a virtual machine ( Windows 2008 Server ) with a 20GB hard drive.
Step 3. Used qemu-img utility to convert the image into a raw image
qemu-img.exe convert -f parallels -O raw “Windows Server 2008-0.hdd.copy.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds” f:\temp\otput.dd
Step 4. Opened the image in FTK Imager to analyze the data

Parallels converted hard drive image in FTK Imager

Wednesday, July 11, 2012

Introduction to Penetration Testing – Part 2 – The Discovery Phase – Passive Reconnaissance

by Si Biles ( @si_biles ), consultant for Thinking Security

PenTest, like forensics, is almost as much an art as it is a science – you can only be taught so far, technical techniques and tools are all very well, but you really need a mind that can think sideways and approach a task from as many angles as possible. The ex-LE forensicators have this skill in spades – the data that is potentially available during an investigation includes interviews, statements, crime scene photos and all matter of collected evidence – in the commercial world there is less available, but still I’m confident that you’ll all have your sources. PenTest is much the same, the more that we can know about a potential target before we even fire up NMap1, the further we will get.

The title of this segment is “Passive Reconnaissance” – that’s not to say that you don’t have to do anything during this phase and that it all comes to you – it’s about obtaining information which is already in the public domain – not necessarily deliberately – and is related to the target.2

There isn’t really anything, at this stage, that we aren’t interested in – collect all the information you can – we can whittle it down to pertinent facts as we go along3.

Right then – where to start ? Well, let’s start to build a picture of our target. Let’s have a look at their domain:

si$ whois
Domain name:
Google Inc.
Registrant type:
Registrant's address:
1600 Amphitheatre Parkway
Mountain View
United States
Markmonitor Inc. t/a Markmonitor [Tag = MARKMONITOR]
Relevant dates:
Registered on: 14-Feb-1999
Expiry date: 14-Feb-2013
Last updated: 10-Feb-2011
Registration status:
Registered until expiry date.
Name servers:
WHOIS lookup made at 23:20:53 03-Jul-2012

Ok, so we have a home address for our company – this example isn’t the most detailed, but you can often glean names, e-mail addresses and phone numbers from a whois lookup. It’s good if you can get an e-mail address – these will start to give you an idea of what the common format is that is used within the company – e.g. first initial last name (sbiles) or first name.last name (simon.biles) or if there is a complicator (simon.biles100) [incidentally these are all real addresses at various organisations I've worked at]. Remember this, it will come in useful later.

If we have a look at the website of our target itself, it is most likely that there will be good information there too – names, addresses, phone-numbers and e-mails are all good. Also, look out for support contact details, FTP site details and logins for example, social networking links etc. All of this is grist to the mill – potential routes of later attack, sources for social engineering, logins to systems that will get you past the first line of defence. Take a note of product names as well, these are often used as “guest” login details for FTP sites too – “producttrial” as both the username and password for example – for sales staff to use with customers. If you are planning a social engineering phase, it can be beneficial  to take copies of web-pages ( faking a login page ), logos ( faking business cards and documents ) and other official looking documents and marketing material – I personally dislike performing social engineering, it’s often the easiest way to get into somewhere – if you are going to do it, make sure that you agree with your client in advance that there will be no repercussions for any member of staff that you succeed in manipulating, and that anonymity will be preserved – it could be an unlucky ring of the phone that costs someone their job otherwise.

Where next ? Google. Google is your friend – it is one of the most amazing tools available, not only having a huge index of things that are current, but also cached copies of things that might not be so current. Googling well is a skill, not unlike that of writing search queries for Forensic searches – just Google is a lot faster than EnCase or FTK over a much bigger data set...

Read more

Thursday, July 05, 2012

Interview with John H. Riley, Bloomsburg University of Pennsylvania

John, can you tell us something about your background and why you decided to teach digital forensics?

First, thanks for the opportunity to discuss our program. We're really proud of what we've accomplished here and believe we're contributing to the digital forensics community. I started as a mathematician (Ph.D., University of Connecticut, 1980) and then began to teach computer science as well as mathematics in the 1980s. I wrote two programming textbooks (Pascal, for the old timers). About six or seven years ago, my department was investigating majors that would be good for students. We decided upon computer forensics. It is an interesting, useful field of study that has worked really well for us and our students.

On the intellectual side, I find the whole issue of what information can be found and how it can be used to build a story quite fascinating. "Story" here means a narrative that shows what happened, in a rigorous sense (a la a mathematician's proof). As a professor, it's really fun to work with digital forensics students. Our curriculum has a lot of hands on work so we see our students really digging into things. The ultimate reward is seeing them graduate and begin work. I must note that I've had really great colleagues, particularly Scott Inch, to work with. I also am grateful to the larger forensics community for their help.

What digital forensic courses are currently offered by Bloomsburg University?

Introduction to Digital Forensics, File Systems 1 and 2, Digital Forensics Software, Advanced Topics in Digital Forensics, Small Devices Forensics, UNIX/Linux for Digital Forensics.

Tell us more about course structure and content. What core knowledge and key skills should students gain by the end of their studies?

The first five courses listed above (along with some computer science and other courses) form the backbone of our major. They cover the artifacts that can be found on a computer (and how they come to be), how the artifacts can be extracted in a forensically sound manner and how they can be linked together and presented or reported. As an example, students know why a deleted file may or may not be able to be recovered, how to use a tool like EnCase or FTK (or even a hex editor) to recover it, how it might be related to a link file or a registry entry, how to ensure its integrity after extraction using a hash function and how to include it in a report. We stress the importance of knowing how the computer is organizing files and generating artifacts so that what a tool produces is understood. Our graduates are prepared to defend their results. We also put this work in context. It's not just finding a deleted file, it's finding evidence which may change a person's life. So beyond knowledge and skills, we foster a sense of responsibility and integrity...