Hello all,
its possible that I am just simply not looking in the right area as I am not very experienced with forensic work but I am looking to see if there is a place to look for evidence that a person may have reinstalled their operating system.
Some background info –
Currently working on a civil case where the user purchased their Windows 7 laptop in 2008 and used it all the way up until they turned it over for forensic imaging in early 2014. The user testified that from the time they learned that they would be turning over their laptop for imaging (they learned this mid 2013) until they actually turned it over in early 2014, that they did everything they could to preserve evidence (eg no deletion of files etc.) My goal was to dip into the image using Encase, pull all the log files (system, security, application etc.) to see if the computer was experiencing any issues over those years that it was in use. And this is where I immediately saw that something was off.
All the log files show a creation date of October 2013. At first I thought perhaps some of the log files ran out of room and recycled but after further investigation, I realized all the OS log files show the same October 2013 creation date (this was further verified looking at the Windows Event Log Parser Output). At this point I took a step back and ran the System Info Parser and the OS System Artifact came back with an 'Install Date' of October 2013. I then started looking at creation dates of important files and folders - many of them come back with a creation date of October 2013 but not all of them. Some of them (eg \Windows) comes back with an install date of back in 2007). Its a bit confusing - there are a lot of system folders and files that appear to have been deleted right before that October 2013 date. Some other important pieces of info - the hard drive appears to be the original one that was shipped with the laptop. Key files on the boot partition ($MFT, $MFTMirr, $LogFile etc.) all show one version deleted (that had a creation date back in 2007) and the other current "in use" version with the October 2013 creation date. Again, the user was not supposed to do anything to their laptop during that 2013 - 2014 period that might delete/alter files.
So my question is, are there any key places/files I can look at that would shed a bit more light on just what exactly the user might have done on that October 2013 date?
thanks
ps - sorry for the lengthy post, just wanted to provide as much useful info as possible.
quick addition regarding the log files - there are no entries in any of the log files prior to the creation date of the actual log file. So its not like somehow the creation date attribute of the log file changed but entries from earlier dates were still in there. Basically just brand new log files and entries starting from the October 2013 date.
Loosely, it is "normal" that "event logs" cycle/are overwritten/cleared, though - unless they are (manually or within some form of automated routine) cleared, they cycle when a given size is reached and thus it is extremely unlike than more than one cycle on the same date.
I find it "criminal" (as opposed to "civil", if I am allowed a small pun) to have a system in use for more than one year before imaging 😯 , set aside (possible) malicious intent, there are tens, hundreds or thousands things that may have happened and partially or totally destroyed any evidence, including automated (and built-in) defragmenting and cleaning, and automatic updates.
Define the "anyhing" the user was told not to do.
I mean was the directive "disconnect the laptop from everything, switch it off, put it in a drawer and don't touch it"?
Or was it "do not delete files"?
What about SetupAPI log?
What about installed MS KB's/updates?
Internet histories, etc.?
jaclaz
thanks for the quick response jaclaz.
Yeah, it stinks that the user wasn't forced to make an image immediately. From my understanding was that he was instructed by his lawyers in mid 2013 to make sure he takes steps to preserve evidence and not delete anything. But he could continue to use his laptop (eg download and apply Kbs/updates)
Just went through the setupapi.dev.log and the setup.api.app.log
the setupapi.dev log has a creation date of 10/16/2013 and the first section starts from that exact date and increments from there as the file progresses. The setupapi.app log has a creation date of 07/2009 (which I believe is when everything was first installed) but inside that log the first two entries show the 07/2009 date but they are associated with sysprep being run and then the subsequent entries in that file starts with the 10/16/2013 date and increments from there.
I totally agree that there is the possibility of log files could be overwritten/cleared (eg overwrite events when max log size reached) but all of the options generally available to the user to change (for log rotation) shouldn't change the creation date of the log file (I think). I haven't been able to locate where exactly in the registry the setting is that shows the log rotation option used but I suspect the user just used the default settings which would be "Overwrite events as needed". In this case, it would be very, very unusual for all of the log files on the system to have overwritten their events in such a way that they all can only go back to that 10/16/2013 date.
So basically the setupapi log entries all have that 10/16/2013 date, the OS log files all have a creation date of 10/16/2013 or later (but nothing before then), the earliest entries in those log files are that 10/16/2013 date; the currently "in use" $MFT, has a creation date of 10/16/2013 but then there is an older deleted $MFT file has a creation date of 09/2007. Same thing for the $LogFile, "in use" one has a date of 10/16/2013 and older deleted one has a date of 09/2007.
Still digging through user created files and apparently all the user created folders have that same creation date of 10/16/2013. Its almost like he did a system restore perhaps?
Definitely something is off here.
Simple answer partition revovery
extract old partition registries
parse it for os install date
Everything you described leads to believe that something "relevant" happened on the 16th October 2013, what is perplexing (to me) is the presence of more than one $MFT (and $LogFile).
Those NTFS structures are created at the time the volume is formatted and never change (AFAICR) in any "normal" operation (and if the volume is re-formatted they are usually overwritten).
What about shadow copies/restore points? (but normally if enabled they are automatically deleted when they are 90 days old, another reason to do things timely)
Having dates of folders on that same date more than a restore *seems* like the effect of a copy (from another volume) operation. 😯
jaclaz
Presuming that the system registry was not altered on purpose, try the following
Open a command prompt with admin rights and see the results of
systeminfo | find /i "Install Date"
or
open a PowerShell and try this
cd c\
([WMI]").ConvertToDateTime((Get-WmiObject Win32_OperatingSystem).InstallDate)
Compare the results with the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
registry key. This registry key stores a 32-bit value displaying the time in number of seconds since 1st Jan 1970, as UNIX time.
PS. Edited it because of important typo mistakes leading to bad syntax )
thanks for response guys - was traveling the past two days and just got back.
Night worker - I didn't realize you can do partition recovery in Encase, I will definitely give that a shot when I get back into the office tomorrow.
Passcode Unlock - unfortunately I only have the forensic image and no access to the actual laptop, so I can't run those commands on it. I forgot to mention that I did look at the install date from that registry key exported out of encase and was a bit perplexed by the results. Viewing the Install Date key under 'Current Version' had an odd value. On the left hands side the value was B2 2A 5F 52 and on the right had side was this interesting string 2*_R. I figured the left hand side was hex and I converted it to decimal and then put that through a unix time converter but the date came back as September 20th 2064. But when I ran the Encase System Info module, that reported back that the install date was the October 2013 date. So not sure why the registry key and the system module have different information.
jaclaz - yeah, this is just really weird. at the very least, I can show that this person clearly did something to their laptop even though they swore under oath that they didn't. I'll keep digging and hopefully will be able to figure out exactly what he did.
I don't know if it helps or not, but I've read about some virtualization solutions, like vmware or Sumuri Carbon
http//
and
https://
I wonder what results would you get if you succeed creating a virtual machine from your image and analyze the live system like that. It is worth a try if you got time for it.
that's a really good idea. I do have time this week so I will give that a shot.