Looks like I need more copies Registry Recon

Hello Reader,
            If you've read this blog you know that I am always looking for new tools and new uses for existing tools to solve all the cases put in front of me. One of the tools I've used for awhile now is Arsenal's Registry Recon to recover deleted registry data and temporary registry data but recently I've been relying a lot of volume shadow copies to get old registries.

Now I know there is way more there and way more ways to use the recovered registry data that I knew before. So here is the scenario, suspect has re-installed Windows on their computer before turning in the computer.    Now I did what you would normally expect, I carved for lnks, ran IEF, recovered USN data but none of that provided me what I really needed to know. Did my suspect take any data with them prior to re-installing. To figure that out, beyond LNK files and jumplists, I usually rely on registry data to determine USB devices connected and shell bags for directory accesses.

I ran registry recon against this image knowing it had support to auto-magically go through all the recovered registry keys and produce a report of previously connected USB devices from recovered registries. I will tell you that it did an amazing job, even after reinstall and slight use i was able to recover over a years worth of USB device connections. So now I knew my suspect had used USB devices... but what did they do with them?

Registry Recon does not allow you to generate a report of the recovered MRU's or Shell bags across all the hives they've recovered, I've talked to them and this is coming in the next release, but I had a directory full of carved registry files.I have other tools I use when I want to go through registry data and some of the recovered hives were quite large and looked like standard registry data, maybe I thought I could just use my normal tools across the recovered hives.

I used the -pipe feature of the TZWorks tools cafae and sbags and passed in the entire set of carved registries and what came back amazed me. Low and behold the recovered registry hives contained a subset that included almost full NTUser hives, system hives and software hives! Using sbags I was able to iterate through all of them and pull out a ton of shell bags data. Using cafae I was able to pull out a ton of MRU and other data! I'm documenting this now so I won't forget later but I do plan to do a step by step to walk through what I did here.

In short, I managed to recover almost all the registry activity I needed from a re-installed system to prove some findings thanks to registry recon. If you have registry recon, and I really do recommend that you do, you can use any third party tool to access the registry data it recovers. In the near future they are updating it again to include even more reports but let's face it just having the data is worth getting a copy today. It's also important to remember that this just doesn't work for re-installed systems. All systems have recoverable temporary registries that may expose data in MRU keys that have rolled over and many other keys.

TLDR; I'm going to get more copies of registry recon and its getting moved up on my tool priority list. 

Also Read: Super Sunday Funday Forensic Challenge - Update 5

Read More

Forensic Lunch 9/19/14 - Discussion with Rich McCutcheon

Hello Reader,

This episode was great as Rich McCutcheon, our Super Sunday Funday Forensic Challenge winner, walked us through how he solved all 5 levels!

You can follow Rich at @macuisdein on twitter!

Also Read: Super Sunday Funday Forensic Challenge - Update 5

Read More

Super Sunday Funday Forensic Challenge - Update 5

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.

Continue Reading: Super Sunday Funday Forensic Challenge - Update 4

Read More