Forensic Practical Exercise #4

I have previously posted a couple different practical exercises here for people to work through and practice. You can see the previous ones here: Practical #1, Practical #2, Practical #3.

This exercise is going to be a little more theoretic because I cannot share the data that I have and I have no ability to make additional data for sharing.

So here is the scenario (BTW, it's a real scenario). Local police detectives have responded to the scene of a homicide. During their investigation they have discovered that there is a CCTV system that may have caught the entire event on video. Being conscious of preserving the data, they called the security company responsible for installing the CCTV system, who promptly responded and shut down the CCTV system. The technician pulled the hard drive out and gave it to the detectives, who has now given it to you with one simple request: "find the evidence". They want you to extract the videos so they can review them to see if it is useful in helping solve the case. Sounds simple eh?

Being the energetic examiner that you are, you quickly image the hard drive and begin an initial analysis. Once imaged, you load the image into EnCase and see a single 100GB FAT32 volume containing hundreds of files in the root directory of the volume. There are no subdirectories (other than some file system generated directories that contain no data). Information about the volume looks like this:

The files in the root directory look like this:

The video data from each day is recorded and stored in one or multiple files depending on the amount of data recorded. Each file has the extension of "XBA". The file header looks like this:

You then export several files out to your local working drive and attempt to view them using a freely available video viewer. Each attempt to view fails and the viewer reports the file is corrupted. A quick look at the exported files show they are each 32,768 bytes in length, even though EnCase reports a different size for each file you exported.

Ideas?..........Let the questions begin... please use the comment function below so everyone can benefit from questions and answers already given.

Forensic Practical #3 - An *excellent* submission

This is a follow up to the Forensic Practical #3

I was contacted via email by Brian Perkins (EnCE) with his answers to Forensic practical #3 I posted a few weeks ago. After reviewing the paper he submitted, I was so impressed that I asked him if I could post it here for others to read and benefit from. Daniel Walton was the first and only person to submit the correct answer to that practical, but Brian's explanation and documentation of his process is very impressive and an excellent reference.

Many thanks to Brian for sharing his knowledge and his process so others can benefit and learn.

You can read his submission here.

Forensic Practical Exercise #3 - SOLVED

Humpty Dumpty sat on a wall,
Humpty Dumpty had a great fall.
All the king's horses and all the king's men
Couldn't put Humpty together again.

This practical exercise is very much like Humpty Dumpty. It's a simple scenario, a simple JPG file fragmented in unallocated space. The complex part is that its in 35 pieces (fragmented) and they are not necessarily in order, and the FAT table is completely gone :(.

Well, all the kings men couldn't put Humpty Dumpty back together again, but Daniel Walton from e.law Asia Pacific Pty Ltd (elaw.com.au) in Australia was able to put this highly fragmented, unusual JPG image back together and solve the puzzle. If this had been a real case, he would have been paid a large amount of money for doing almost the impossible. Great job Daniel!!

Here are his notes:

-----------------------------------------------------------------------------------------------------------------
I have recovered  your number on the jpg.

983456 294001 991201

Have attached the recovered .JPG

##Extra Credit:
##Can you hypothesize as to what happened to make the file "disappear"?

It seems that the file was formatted by the mac pc.

###Can you articulate the status of the drive and what, if anything is different that a typical flash disk?
[a]  media descriptor byte
Now the media descriptor byte at the beginning of the FAT on the image signifies a floppy disk.( 0xf0)
re http://support.microsoft.com/kb/140418
Byte   Capacity   Media Size and Type
F0     2.88 MB    3.5-inch, 2-sided, 36-sector
F0     1.44 MB    3.5-inch, 2-sided, 18-sector
F8     -----      Fixed disk

on my usb drives it's 0xf8
now that is true for both partitions.

[b] two partitions.
Most usb drives only have 1 partition as windows will not display both partitions on a USB drive.
The file was on the second partition , which wouldn't be visible on the pc if the first partition was formatted to a FAT or NTFS filesystem.

So the first partition must of not had a  FAT or NTFS filesystem or the partition was  been deleted.

The evidence had the following two partitions.
The first partition was formatted by macos.  ("BSD  4.4" , FAT16)
The second partition had been formatted by windows. ("MSWIN4.1" , FAT32)

With this setup the second partition will not be accessible under windows.

For windows to mount the second partition the first partition must (a) not have a  FAT or NTFS filesystem or (b) the partition must been deleted.
I would assume the first partition originally was created but wasn't formatted when it was put in the MAC.

Not having a MAC I couldn't test it's behavour with partitions and USB sticks.
I know Linux will happily see all partitions on a USB stick.

Unless the first partition wasn't originally formatted , in which case that could be why the file wasn't immediately viewable on the mac and was viewable on the pc.

The partition table is EFI , which is the default format mac's make.

[c] File fragmentation.
The file was extremely fragmented.
the end of the file (footer) was stored before the beginning of the file. (header)
Not a normal situation , shows extreme fragmentation or unusual circumstances.

###  Provide the MD5 of the recovered file.
Can't do that as I have removed all of the section which has a header of 0xFFE2.
I couldn't find any info regarding that part of a jpg which would help me to find the missing parts.

After finding the header and footer if  searched for 0xff00 to find the image data.

My method was to use a hex editor and combine the parts manually.

I used encase to find the pictures header.
Then tried data carving it with "revit" which didn't find anything.

So researched the JFIF file format and found out what I could about the format and the headers in the file.
Searched for the most important headers and found the following.
FFD8 , FFE0 , FFE1 , FFE2 , FFDB , FFC0 , FFDA & FFD9
Exported all chunks with the above headers.

Found that JFIF files use byte stuffing and 0xFF00 is used to represent 0xFF , so searched for all blocks containing 0xFF00.

The size of the FFE2 section was fairly large and I couldn't easily find any details about it's format , so removed it.
(used the following two bytes after the header as the section size. (big endian))

Removed any sectors which contained 0xFF followed by a byte which's value is under C0 but still keeping all sectors which contain 0xFF00. (so keeping 0xFF00 and 0xFFC0 and above)

Connected sections FFD8 , FFE0 , FFE1 , FFDB , FFC0 , FFDA together.

Then appended first 4 found sectors containing 0xFF00 . ( Hadn't found the rest of them at that stage)
The resulting JPG wasn't quite correct , so changed the order until it displayed correctly.
This gave me the first two rows of numbers and half the HDD picture.

I search further and found all the other sectors with 0xFF00 .
Luckily I had started from the beginning as they were all in order and then appended them one by one until I ended up with the correct image.
Appended the footer when I had run out of data.

I had been hoping that I might of been able to find part of the original FAT table so then I could figure out the order of the sectors, but didn't

It was not an easy puzzle.
Was a good challenge !!
---------------------------------------------------------------------------------------------------------------------------

Here is the recovered JPG:

The file was fragmented severely across the second partition. Here is the order of the pieces notated in physical sector numbers :

427586, 427587, 427588, 427589, 427590, 427591, 427592, 427593, 427594, 427330, 426497, 428505, 428434, 428433, 427750, 427749, 427751, 427712, 427713, 428685, 428686,  426442, 426443, 426718, 428457, 426858, 426859, 426878, 426879, 426172, 426188, 426208, 426228, 426246, 427202.

Here is the true scenario:
This flash drive was partitioned and formatted using a MAC. The default was to use a GUID partition table. This caused two partitions to be created. The first partition is used as the GUID partitioning config and the second is actually the usable one.  When used on a MAC, there is no problem and just one partition is seen (the second one). When inserted into a Windows XP machine, the OS says the flash disk needs to be formatted and when you choose "yes" to format, it only formats the first partition (The one containing the GUID partition information) which is only 200MB in size. So in this case, I had a flash device that was 4gb, but the actual reported size in Windows was 200MB. I then deleted the second partition after "laying" down the fragmented JPG.  I manually assigned each piece to each sector using the diskmap tool by Tim Coakley (http://www.simplecarver.com/software.php?cat=All).  This tool allowed me to created the highly unusual, but not impossible, fragmentation and disorder among all the JPG pieces. I then reformatted the second partition using the MAC.

I admit that it is not often that you see the beginning of a file *after* middle parts or even the end piece of a file, especially in a FAT file system, but I have to honestly say that I have seen this situation on real evidence before.

To summarize, it's a simple JPG image with a text layer containing the 18 digit account number. I broke the account number into three parts, six digits each and placed the first part at the top, the second in the middle and the last part at the bottom, so if you started to recover the JPG you could start to see the account number, but not all of it until you got all the pieces (yes, it was evil). If you put the first 23 pieces together, you will get a partial image with the first portion of the account number, then you have to put the remaining pieces in order to get the rest.

I was very surprised and pleased at the amount of emails and responses I received asking questions and providing comments about the practical. It indicated to me that there are a lot of people that enjoy doing these puzzles/practical, so I intend on creating some more and posting them shortly.

Thanks to all that participated and congratulations to DANIEL WALTON!!!!

Forensic Practical #2

I have posted some answers to the first forensic practical here. Based on the lack of answers/feedback on the first one it was either too difficult or nobody was really interested, so I will post an easier second problem and see how this one goes.

Scenario:
An employee named Castor Troy has just abruptly left a software company that he has worked at for the past 5 years. His departure was sudden and somewhat suspicious. Co workers said he came in very early the day he quit and seemed "panicked".

Due to his tenure, he had access to some critical intellectual property. When he left, the IT department assumed control of his computer and briefly examined it pursuant to an HR request. They found several zip files in the user's home folder containing some critical information. HR has referred this to legal counsel and you have been retained to provide whatever information you can about what happened and what, if anything may have left the company when the employee quit. The information found in the user's folder is critical IP information, but the employee had access to even more sensitive information deemed very secret.

Inside Counsel would like to know if any of that information was accessed or copied. Your mission, if you choose to accept, is to conduct a forensic examination and provide whatever factual information you can to counsel so they can decide if further legal action is necessary.

Good luck, have fun, and as always, if you are caught I will deny any knowledge of your existence.

Download Here

Forensic Practical #1 - Answers

A few weeks ago I posted a forensic practical along with a basic scenario. You can review it here. A few readers posted some comments, some of them on target, but not nearly in-depth enough. Here is a summary of key points that should have been observed.

1. WINDOWS/system32/inetsrv/rpcall.exe is malware and would be identified by an AV scan. The behavior of this malware is to scan for additional vulnerable machines, which is what caused the network traffic. This executable is set to run at boot through the HKLM\Run key.

2. Looking at the creation date of rpcall.exe should reveal some interesting things, most notably is that every file in the parent folder (\windows\system32) has the same created date/time. This is not normal and is indicative of some sort of timestamp manipulation tool.

3. Sorting by filenames would have revealed a prefetch file was created 06/18/04. Sorting on creation time on that file would show several other files of interest were started near that same time:

ping.exe
cacls.exe
cmd.exe
sms.exe

4. Looking for sms.exe would result in finding no executable named that, but there must have been one at some point if there was a prefetch file, right?

5. An exam of the User assist keys shows several programs run by the user account of "vmware". One of which is "UEME_RUNPATH:C:\System Volume Information\_restore{00D8A395-89D5-46B8-A850-E02B0F637CE5}\RP2\snapshot\Repository\FS\sms.exe" What the heck is a user doing executing something out of a system restore point folder?

6. Searching in unallocated for "sms.exe" in Unicode would reveal some interesting results

7. Searching the $Logfile would also reveal some interesting results for the keyword of sms.exe, including a complete MFT record for that file and the MAC timestamps. In addition there is an interesting fragment of text from what appears to be a batch file named del10.bat.

8. A search of del10.bat would reveal several hits, including a complete MFT record in the $logfile with timestamps and the appearance in two prefetch files, sms.exe & cmd.exe.

9. reset5setup.exe is a crack used to bypass Windows activation.

There are more artifacts, but the above listed ones are a good start.

Forensic Practical Exercise #3

So I figured many of you may be on vacation and would like a little puzzle to work on during your free time ;)

Scenario:
Your company has been contacted by a very wealthy and prominent business. They have one simple request. They would like you to do some data recovery and recover one simple file. The President of the company explains that he has a USB flash device that contained one simple file and that when he gave it to the company accountant (who uses a MAC), the drive suddenly became unreadable. The President advises you that the file contains the account number of a very important bank account and that he needs that 18 digit account number. Nothing else matters to him.

The file is *very* important and he is willing to pay you whatever fee you demand if you are able to recover the file exactly as it was.

Your mission, if you choose to accept it, is to recover the file and be able to tell the President (me) the account number (via email, please don't spoil it and post it in the comments, send to lance(at)forensickb.com).

Extra Credit:
Can you hypothesize as to what happened to make the file "disappear"?
Can you articulate the status of the drive and what, if anything is different that a typical flash disk?
Provide the MD5 of the recovered file.

I will provide an exact explanation of what was done to the device and file to those who submit answers so you can compare it with what you see. 

There is no encryption or hidden elements to this problem. This is a classic puzzle. For this scenario, I will be the "President" who lost the data and has contacted you. Feel free to "interview me" and ask any further information that you feel necessary, via the comment section (so everyone can benefit).

Good Luck!

Download Here (7.5MB)

Forensic Practical

I run several honeypots and I decided to take some of the malware found on the honeypots and install it on clean computer systems and watch its behavior. To take it a step further for those of you who like to hone your forensic skills, I have decided to post an evidence file of the machine with the malware, and describe a simple scenario that a first responder or examiner would likely face in examining this evidence.

SCENARIO:

A user in a company is using WinXP Home (just go with me on this ;) and he notices his computer is acting funny. He calls the IT staff over and after some digging around they determine something is definitely wrong. When they do a netstat they see hundreds of connection attempts. They pull the machine offline and image it. They did happen to speak to their netsec people before they pulled it offline, who captured a small amount of network traffic regarding the WinXP system.

The image is provided here in the EnCase evidence format (400mb).

A network capture in tcpdump format is provided here (230kb).


This is not rocket science people, it is fairly simple exam, but it is a good training example and a very common scenario. Please feel free to download and examine the evidence file/network capture and the post any comments on what you find.

EnScripts Currently Offline - being moved

All the EnScripts are currently unavailable while I move them to a different storage location. May of the old links will be broken, please just email me and I will provide an updated link and/or email it directly to you.

UPDATE:

EnScripts:
 https://github.com/lancemueller/EnCase-EnScripts

Practical Evidence files:
https://www.dropbox.com/sh/q0w7fy25qyltalh/AAD_VbL27cpa2bKuCtKaCuhaa?dl=0