A coworker just asked me this question, and I thought that it would be useful enough to create a quick post. If you’d like to find out the hostname of a Windows workstation/server and only have a drive image available (and don’t want to boot it), you can find the name within the System registry hive in the key named Hostname located here: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Happy Monday.
So – you’re working on creating a timeline for a new disk image and you’re finding that the subject accessed a large number of unrelated files in quick succession. Perhaps they were up to no good, but before utilizing this evidence to support any findings, let’s step back and think. When analyzing a timeline, if you find a number of files that were accessed in quick succession, you should immediately consider that some sort of program/process actually accessed the files and that they were probably not intentionally accessed by the subject. The usual suspects can include backup software, antivirus software, and any other software/malware that “scans” a filesystem. Of course, once you find the presence of one of these tools, you’re going to need to note it in your findings and if you would like to use accessed times in the timeline to build a case, you’re going to need to prove that the timeline was not affected by this tool. Some strategies to proving that your access times are relevant include:
It’s interesting to note that most likely due to the proliferation of “scanning tools” and thus the reduction of relevance that an access time can have in an investigation, Microsoft has decided that by default, in Windows Vista and Windows 7, that the OS does not modify the last accessed time when a file is accessed (this behavior can be modified via GPO and/or the local registry).
My personal reccomendation is that unless you have a very specific reason to use the access time to support your findings, given the active use of tools that automatically access/scan files, you may find that your results are more clear and less challengable if you do not base investigative findings on this timestamp.
Microsoft has significantly changed how files and their corresponding details are represented within the Recycle Bin in Windows 7 and Vista. In Windows XP, when files were placed into the Recycle Bin they were placed within a hidden directory named \Recycler\%SID% where %SID% is the SID of the user that performed the deletion. The files were renamed D%drive_letter%%index_number%.%file_extension% where %drive_letter% is the original drive letter of the file, %index_number% is an index number, and %file_extension% is the original file’s extension. Additionally, a file named INFO2 was placed in the user’s Recycler directory and it container entries, identified by index number, which described the original files size, full path/name, and size.
In Windows 7 and Vista, Microsoft did away with the INFO2 file and completely changed the way files were named and indexed within the Recycle Bin. Firstly, the new Recycle Bin is located in a hidden directory named \$Recycle.Bin\%SID%, where %SID% is the SID of the user that performed the deletion. Secondly, when files are moved into the Recycle Bin, the original file is renamed to $R followed by a set of random characters, but maintaining the original file extension. At the same time a new file beginning with $I followed by the same set of random characters given to the $R file and the same extension, is created; this file contains the the original filename/path, original file size, and the date and time that the file was moved to the Recycle Bin. You’ll also notice at all of the $I files are exactly 544 bytes long.
The behavior is a bit different when you move a directory to the Recycle Bin. The directory name itself is renamed to $R followed by a set of random characters, but the files/directories under that directory maintain their original names. A $I file is created just as when deleting an individual file that contains the original directory name, date/time deleted, and size. When utilizing the information contained in the $I file for forensic purposes, you can safely report that all files found under the $R directory structure within the Recycle Bin were deleted at the same time (and all at once). If a file was previously deleted out of the now deleted directory (but not yet removed from the Recycle Bin), it would have it’s own $R and $I files and not be grouped with the files that were deleted as part of the directory deletion action.
Unfortunately, unlike the INFO2 file, the new $I files are not in plain/readable text. In order to decode a $I files, you could use a forensic tool that has the ability to interpret these files (I belive that Encase and FTK can do this), or you can simply open the file up in a hex editor. The file is structured as follows:
So – break out your hex editors and take a look. The new Vista/Windows 7 Recycle Bin is just as easy to deal with as the XP one – in fact, when it comes to whole directory deletions, I personally find it easier to work with…sometimes change is a good thing!
Have fun!
PsExec can be a very useful tool during incident response and live forensics work. For those that don’t know, PsExec is a tool that can be used to execute commands on a remote Windows computer andwas initially developed by Sysinternals, which is now owned by Microsoft (additional details can be found on PsExec’s webpage).
However, it seems that PsExec has one significant shortfall – when utilizing the tool one must provide administrator-level credentials for the remote PC. These credentials are passed in the clear to the remote workstation (thus exposing the credentials to anyone who happens to be “listening in”). Thankfully, there is a workaround that can prevent this exposure from occurring, which involves connecting to the $IPC share on the target workstation first (with the admin credentials), prior to executing PsExec.
To find out more, check out an excellent write up on this issue and the workaround found on SANS Computer Forensics blog titled Protecting Admin Passwords During Remote Response and Forensics.
A discussion came up recently at work around how a file can become identified as “Orphaned” in an NTFS file system and I thought that it would be a good topic to cover on my blog since understanding how this occurs aids in the forensic analysis of NTFS filesystems.
An orphaned file is a file that has been deleted and the parent directory that the file is linked to (within its MFT entry) has also been deleted and then its MFT entry has been reallocated. You can also have an orphaned directory index for the same reason as you can have orphaned files (same basic concepts apply).
As an aside: when a directory is deleted on an NTFS file system the operating system marks the directory as unallocated within the MFT and also recursively goes through and marks the file MFT records (and other directories) as unallocated (of course, it also checks the hard link count to make sure that the file isn’t linked from any other location prior to marking it in the MFT as unallocated).
Even though a file appears “orphaned,” you may still be able to recover the file the same way that you would recover a deleted file on an NTFS volume (given the clusters for that file have not been overwritten with other data). Additionally, you may be able to see directory structure information (names, etc) for an orphaned file/directory that is buried several directories deep; the “orphaning” can happen at any point in a directory structure and you’ll be able to find directory information up until the final MFT entry that is pointing to the now overwritten MFT entry.
The bottom line is: orphaned files are simply just deleted files that may be treated the same way you’d treat any other deleted file during an investigation…you’ll just not be able to determine with any certainty the exact location of the file within the directory structure prior to deletion.