Hacking Exposed Computer Forensics Blog

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 

. 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. 

Hello Forensicator,

     Welcome to Stage 4, where the typing gloves come off and we get to see who has it in them to get to Stage 5.

 

The Challenge:

You’ve worked with law enforcement to track down the source of the IP Address you found in the memory dump connecting to the internet. They traced it down to a ZTE Avail running Android 4.2. This was a prepaid phone left in a coffee shop as it was triangulated and found still powered on and hidden behind a trash can. Local police believe that the attacker must have used the wireless access point functionality of the phone to route to the Internet. They have surveillance video but need to know the make of the laptop used and the time to identify the suspect.

Questions:

1.       How can you determine if the phone was on during the time of the attack

2.       How can you determine the google account associated with the phone

3.       How can you determine which MAC and ip address was associated with the wireless AP feature

4.       How can you determine which type of computer connected to the wireless AP 

1.       How can you determine if the phone was on during the time of the attack

This depends on the time that has elapsed since the attack to the time we tracked down the phone. If the phone had been on continuously since the time of the attack you could run the “uptime” command through ADB debugging or check the kernel log (dmesg.log) to see if the events in it still covered the time of the attack. 

If the phone had been turned off since the attack it is best to fall back filesystem timelining. I could create a timeline of activity in X-Ways from all the sql databases and various logs checking for activity, connections, wireless activity, the log for WiFi connections that we address later in this Stage to determine from some internal timestamps if there was activity and what was happening.

I would start with checking for messages and calls being sent and received during that time frame, and then move into checking the web browsing activity on the phone during the time of the attack.  Between file system timestamps, internal timestamps on databases for user activity and parsing through various logs with Unix timestamps this should be able to be established solidly.

Before relying on your timeline you will want to check the time settings of the phone at “data/property”.  

2.       How can you determine the google account associated with the phone

“Data/system/sync/accounts.xml” should contain the Google account that is associated with the phone. There are other places where this information can be found though.  At “Data/system/users/accounts.db” there is a file that contains all accounts that require authentication.  The Gmail address should be there as well if the user makes use of it for other activities.

At path “data/com.google.android.gm/shared_prefs/gmail.xml” there should be a file with the Gmail account name account.

3.       How can you determine which MAC and ip address was associated with the wireless AP feature

Various config files at paths just under “data/misc” contains files relating to Bluetooth, WiFi and other access that will have the MAC addresses of devices that connected to it. In particular at path “data/misc/dhcp” there would be information for what IP address the phone had from the Wireless access point it was connected to.  Since the computer is tethered to the phone for the connection, that will be the router for it and the most public IP address for the computer.  The wireless access point the phone was connected to would need to be checked for the public IP address out to the Internet.

The computer will have been given a DHCP lease for a local 192.168.x.x IP address on the phone that would be stored at  “data/data/com.googlecode.android.wifi.tether/var/dnsmasq.leases”. The “dnsmasq.leases” file may be stored at a different path if the user had some other type of tethering application. On the phone I examined it had the file at the specified path.  That file will contain the IP address given to the computer by the phone, the MAC of the computer, and a Unix timestamp for the lease (another indicator of if it was on at the time of the attack!).

 

4.       How can you determine which type of computer connected to the wireless AP:

If this question is simply asking to be able to tell if the computer is an Apple or PC you can check the MAC address from "dnsmasq.leases"against a database such as “http://www.wireshark.org/tools/oui-lookup.html” to determine the vendor for the NIC.  Apple produces their own NIC cards and will be the manufacturer.  Marvell or something else will be the vendor for PCs.

If this question wants to know the EXACT type of computer this is a little sticky and I honestly need a test android to tether a computer to for testing.  I did notice that at ”misc/wifi/wpa_supplicant.conf” there are multiple devices names for connections on an Android dump I got access to for answering this question. It contained the make and model number of other devices, but without a phone to test on I cannot be certain if it is a phone that was connected to or from as a hotspot. Since I didn't see any information for WAPs like home routers I really feel this is a file that shows information for devices that have connected to my phone as a hotspot though.