Super Sunday Funday Forensic Challenge - Update 5

Super Sunday Funday Forensic Challenge - Update 5 by David Cowen - Hacking Exposed Computer Forensics Blog
Hello Reader,
     The current contest ends today 9/16/14 and I've really enjoyed seeing your submissions and watching all of your learn from this. So let's get straight to it:

Current Contest


Level 5 has been beat! I'll be honest I wasn't sure if it was going to happen but I was very impressed by our current leader. To all of you on Level 4 still (Our level 5 winner is also the only person to beat Level 4) you still have until tonight to move on and challenge him for the prize. I'll be calling it end of game tonight around 10pm CST.

If you have questions get an IRC client and come ask them. I'll try to remain in the channel today and late tonight. Other players are in the channel though and you are welcome to talk amongst your selves.

For those of you not playing, or looking for a break here is some more good information.

Forensic Lunch this Friday


Want to know how the winner did it? Want a walk through of each level? Join us Friday at 1pm CST 9/19/14 on the Forensic Lunch when the winner of this challenge will join us to explain how he did it and I will explain exactly what I did for each level. You can watch it here: https://plus.google.com/u/0/b/105962155502598586194/events/cuev3kvm2e464es6kefqrjccob8

Learn Windows Forensics from me!


I'll be co-teaching SANS FOR408 with Rob Lee in Ft. Lauderdale, FL at DFIRCon East Nov 3rd-8th 2014. If you want to spend a week learning everything you can about Windows forensics, and nights going deeper into the artifacts/structures if you want, I can't wait to meet you. As a bonus SANS has put out a $400 coupon for the event, go here to claim it.

Solutions to the past contest


Let's finish off the last challenge with the question that few saw, Stage 5. 


Stage 4 Question:

Hello Forensicator,
Welcome to Stage 5, the final stage. You have until end of your day (wherever in the world you are) on July 6th, 2014 to submit your final answer. The person with best answers from all five stages will then be declared the winner and receive a free vLive class of their choice. Good luck and congratulations on making it this far. Getting this email is an accomplishment in itself, many examiners didn't make it this far. Well done and I hope you continue to follow your passion for DFIR no matter the outcome of this game. This stage will either be easier or incredibly more difficult depending on your time in the OSX world.

Stage 5 Challenge:
You found the MAC address and it came back to an apple computer. Using the security camera footage the police are able to identify three apple computers that where present at the coffee shop during the entire attack period recorded. It's time to see if your knowledge extends across the whole DFIR spectrum with some in depth OSX knowledge, assume this system is running OSX Mavericks: 

1. Two of the OSX systems have the same MAC address, the attacker may have cloned his to fool any possible attempts at detection. Only one of them however connected to the wifi hotspot on the Android phone you identified in Stage 4. How can you determine which system connected to the wifi network.
2. Once you've identified which system was used you need to determine if they accessed the ex-filtrated data. There is a text file that appears to named the same as on you found accessed from the victim system but it now has 0 bytes. How can you determine what its prior contents were.
3. Both of the owners of the systems have stated they are innocent, how can your prove that their system wasn't hijacked by malware.
4. In searching for a bank account number you find a fragment of a file but not the file it came from. How can you re-associate the fragment to the file it originally came from.
can you determine which type of computer connected to the wireless AP 
The Winning Answer:


. I definitely learned a few things on this one.  The last time I had a Mac at work it was Snow Leopard, so the versions issue for #2 was all new, and pretty cool to know about. I look forward to reading the winning answers for these questions.  I am glad to have gotten to the end, held my own, and learn a few things along the way.  It started off innocently enough with Stage 1 and the VSCS question. By the end I felt like I was watching the end of War Games "The only way to win is not to play".

1. Two of the OSX systems have the same MAC address, the attacker may have cloned his to fool any possible attempts at detection. Only one of them however connected to the wifi hotspot on the Android phone you identified in Stage 4. How can you determine which system connected to the wifi network.
If there are two Macs with the same MAC, then you might assume that the person who spoofed their MAC is the bad actor.  You can check the true MAC address of a MAC by removing a few screws (how many depends on the year model of the Mac).  The wireless MAC and Ethernet MAC addresses are generally under the battery area where you will also find the serial number for the Mac.  You can then narrow your search to start examining the most likely Mac to begin with (the one whose Ethernet MAC from the battery label is not the one that shows up on ifconfig output).
At path “private/var/log” The file “system.log” is a Mac’s catch all log for most system activities.  Along with many other things this file can be checked for the name of the SSID and MAC of the Android phone that it connected to when it was set up as a wireless hotspot. There will be a timestamp for the date and time of any connections to the hotspot as well as the IP address that was assigned to this computer, which can be checked against the records on the Android phone for assigning the DHCP lease.
A plist at path: “Library/Preferences/SystemConfiguration/com.apple.network.identification.plist” has historical IP assignments with a timestamp for those assignments that can be checked for this issue as well.

2. Once you've identified which system was used you need to determine if they accessed the ex-filtrated data. There is a text file that appears to named the same as on you found accessed from the victim system but it now has 0 bytes. How can you determine what its prior contents were.
From the way this question is worded I assume that it the file was never deleted, and that it was a text file that was modified to remove the content to make it currently 0 bytes. 
If there is no time machine backup for this machine, then I would want to attempt to obtain the previous version of the file by using the “versions” functionality present in Macintosh since Lion version 10.7.  There are databases that Mac uses to track changes to files so that previous versions (I just can’t shake my Windowsness enough to not call them previous versions) can be rolled back to.
At path “/.DocumentRevisions-V100/db-V1/db.sqlite” is a database that tracks file names, paths, and inode for files that have previous versions saved.  That database uses a primary key of “row_id” for file changes to a file.  There is another table that stores information in that database for the change number because OSX is only storing incremental changes and not entire autosaved versions like Time Machine does.
The actual data for the changes of files/previous versions of files is stored at “/.DocumentRevisions-V100/.cs/ChunkStoreDatabase”. If the text file was less than 32KB, then the entire file would be stored as one chunk in the database. The chunks will have to be pieced together from the separate chunks in the database if it is a large file.
Alternatively if the data for the previous version of the file cannot be resolved from the two databases at “/.DocumentRevisions-V100” you can clone the Mac hard drive to another computer then boot it, open the 0 byte file, drop down the arrow next to the file name when it is open and choose to “browse all versions”. You can then open any previous version of the file, and choose to restore any previous version. You may want to double check your work with that method anyhow.


3. Both of the owners of the systems have stated they are innocent, how can your prove that their system wasn't hijacked by malware.
I would start off by examining some log files at “private/var/log”
“Install.log” will show the date, time and name of packages installed on the computer, including OS upgrades, software updates, and new package installations.  It can be checked for the installation of any suspicious binaries.
“System.log” is again our savior for this case as a catch all of things that have been done on the computer.  It can be examined for error messages, remote connections to and from the computer for various application, and activities in the terminal.  I would unpack all of the archived “system.log” files on the computer to put them with the active log then GREP for the terms “sudo” and “USER=root” for starters on seeing lines where an attacker might have dropped into a terminal shell to commit activities.  Older “System.log” files are Gzipped and can be unpacked to be examined if the timeframe of the attack was not in the active “System.log.”
The last 500 entries are stored for terminal usage in the “.bash_history” file at the base of each user’s home directory.
In “System.log” if there is an application on the user’s computer that is making a remote connection to an attacker, then it will be logged for the date, time, and IP address as well as the application making the remote connection out.
Since we know the time of the attack, we can just look through every line of these logs for any activity during that time to determine any remote connections, or suspicious activity.
We can also check to see if the malware was set as an autorun on user login by checking the users “Library/Preferences/com.applie.loginitem.plist” or in the main system we can check for items set to run on system launch as “System/Library/LaunchAgents”. For the launch agents we will have to know a good baseline for normal launch agents and look for suspicious items.

4. In searching for a bank account number you find a fragment of a file but not the file it came from. How can you re-associate the fragment to the file it originally came from.
I would take a note of what cluster number the fragment was found in, then use the TSK tool ifind to find the metadata address (node)for that cluster I would then be able to go to that inode record to determine the file that the data came from. Icat would then be able to be used to view the contents of all data from the file of that node. Istat would be employed to determine information about the file from the node record such as file name, size, type, and CNID. 
If there is trouble with finding what is needed using The Sleuthkit you can always get a bit more manual with the following 6 steps:
1.       1. Take note of the cluster number where the file fragment of interest resides
2.       2. Go to the Catalog file for the file system and search for the “HFSPlusExtentDescriptor” that contains the value “UInt32 – {cluster number where the file fragment of interest was found}”.
3.       3. Back out one level from that HFSPlusExtentDescriptor to view the “HFSPlusForkData record to see the total blocks for the file, and all the other extents for the other file fragments of the file as well as the total size of the file. 
4.       4. Back out one more level from this total file record in the catalog file to view the Catalog Node ID(CNID), Create, Modified, and Access dates for the file as well as other information about the file. 
5.       5. The CNID can be used to locate more information about the file in the “file thread record” area of the Catalog File.  There the CNID can be looked up, and the name of the file as well as the CNID of the parent directory will be available.
6.       6. You could just go nuts and use the “HFSPlusForkData” and “HFSPlusExtentDescriptor” sections to go to all the other fragments of the file to view the contents as well. 

The only answer I needed:

Honestly I needed everything in this winning answer. This answer is what tipped Erik Iker over the scales compared to all the rest of the answers I received. Look over his level of detail and the number of items given for each answer. This is the kind of entry I like to receive as it shows me someone really took the time to test their assumptions with real data rather than just throwing something out there from a google search.

Post a Comment