Windows Forensics-Where to look-What to use
Windows Forensics-Where to look-What to use
I had originally intended to put together a tutorial outlining a toolkit for incident response teams. I decided instead it would probably be more useful to put together a basic lesson geared towards the enthusiast, and the system administrators that normally don't do computer forensics. Most of the tools I have listed have been mentioned here in one thread or another. Oh, I'm not including the links to any tools, they are easy enough to find.
I realize also that there have been 2 previous tutorials relating to forensics, and this one is intended to compliment them. "Windows forensics", by Grinler, looks at it from a networking angle. "Building your Forensic Toolkit", by magnoon, lists many useful tools. I recommend you read both of them.
Unless you are conducting a casual inquiry, you should make a 'ghosted' copy from whatever media you are trying to recover data. There are many sites that detail making a forensically sterile copy.
One of the first tools you should have is a clean boot disk, unless you're not really trying to build a legal case against anyone. Why? I'm glad you asked. On my computer, when you type in "cmd" from the run command, it starts a little program that overwrites every bit of data on my hard drive.(Ok, not really, but you get the point.)
AVAILABLE SOURCES FOR INFORMATION, or WHERE DO WE LOOK
- Logical file system
- Temp files
- Recycle bin
- Browser histories
- Misc. others
First and foremost, password protection. As users are becoming more sophisticated, some are actually turning to password protection. I'm sure many of you are already aware of tools available for password cracking, I just am listing my personal favorites:
Cain & Abel- Very powerful, tons of features. It has recently been iproved to include network capibilities.
NTpassreset- Has the ability to reset admin password from a bootdisk.
LOGICAL FILE SYSTEM
A cursory search with Explorer for anything interesting. (i.e stuff_to_steal.txt)
In Windows XP, there are system logs, application logs, and security logs. System logs record system processes and device driver activities. Application logs record activity by, oddly enough, applications. Security logs detail changes in user privelage, changes in policy, system users, and file and directory access. The downside to the logs is that they are not enabled by default. Also, the IP addresses of remote systems are not recorded.
Logfiles are usually stored in the %system%\sys32\config, but may be in a different location.
A search of .log files on my xp box turned up some sixty or so files. Two of them were somewhat interesting.
-ebd.log= Transaction log that monitors any changes to the active directory
-userenv.log= Tracks settings and changes applied using the group policy
psloglist: a tool from sysinternals to parse the logs, included in the pstoolsuite. This tool is very useful when the event log is password protected, or you are on a remote computer.
mslogparser: command line app that parses all logs into an easy to read format (kind of hard to find ;) )
The registry is, in essence, a huge log file. Installed software, MRU files, security configuration, and hardware are among the keys that can be found here. Keyword searches are generally the most useful way to search. Don't forget to snoop around for backups of the registry also.
One of the downsides to the registry is the lack of time/date stamps, making it difficult to narrow your search (at least I couldn't find any)
Read a tutorial or two so at least you have a basic understanding of the registry structure.
regedit: all you really need, but limited.
regmon: a very good registry viewer that does include some date information, and includes some parsing abilities. Generally most useful for "live" analysis.
MASTER FILE TABLE
A close cousin to the registry is the Master File Table (MFT). In basic terms, it is an index to every file and folder on your hard drive. A copy of the Master Boot Record is kept here also.
I haven't been able to dig up too much information on forensics tools and techniques related to this area other than what I could find with Google. They are essential for proper operation of you system, and are essential for system restore capabilities. They are seen as $mft, and $mftmirror.
Winhex: not free, but fully functional. Allows you to view specific clusters on the hard drive. I rate this among the must have of tools.
Emails, sites visited, they are all here somewhere, even if you have history disabled, and caching disabled. Check the registry, amongst other places. As was pointed out in a thread awhile back, your browser leaves crumbs everywhere. (my apologies to whoever authored that...I couldn't find it)
Netscape keeps its email files in Program Files\netscape\users\<account>mail. It is stored as an .snm file, and a text file. Very useful from a forensics standpoint.
Outlook records can generally be found in Documents and Settings\<user>\local settings|application data\microsoft outlook, and they are stored as a .pst file. Outlook has some configuration capabilities, so you may have to hunt for them.
Exposed: Another tool on the must have list, but be careful with it!!
Pasco: A nice tool from foundstone that reveals browser activity.
"So", you might ask,"what if my suspect used one of those nifty browser/window washer applications I hear so much about?" Never fear, I will address that in Data Recovery :)
Many programs leave remnants in .tmp files from installation and creation. In some cases, Outlook and Netscape leave attachments as .tmp files. Any hex editing program can be used.
The recycle bin is another place one should examine for evidence if installations, documents, etc. And most of us are aware that the recycle bin is not actually emptied, but rather the files are marked as available space. So what if the recycle bin is empty? See Data Recovery.
So, what do you do when the recycle bin is empty, and your fishing around in the browser histories turn up nothing? Try the following tools.
PC inspector file recovery- works on all flavors of windows
Disk Investigator-displays the drive contents by reading directly from drive sectors, and bpassing your OS.
WinHex- mentioned before.
A couple things to note. As I mentioned in an earlier thread, "washer" type software, in general, does not overwrite any of the data...it is still recoverable with one of the above programs.
I also had the opportunity to test some file "wiping" software...they didn't work either. I'm not sure if that is NTFS related, or if the deleted files were still somehow protected in the recycle bin.(alternatively, I am a complete moron that didn't use them correctly) I hope to have some time to investigate that further.
OTHER THINGS OF INTEREST (OR, LATE BREAKING NEWS AND LAST MINUTE ADDITIONS)
If all your searching turns up nothing, there are still a couple things you can try. One is by generating MD5 hashes of all files, and comparing them against various databases...again, turn to Google. (http://www.knowngoods.org/)
Alternate data stream detection, from a forensics standpoint, is a relatively new field, and there are not very many tools available. Basically, it is hiding data within other data. A couple tools I found:
Scanads: ScanADS Scans Alternate Data Streams (ADS) in a local/remote system.
lads: Shows the ADS of encrypted files, even when these files were encrypted with another copy of Windows 2000. From HeySoft.de.
Steganography- although the concept has been around longer than many of us have been alive (and maybe longer), the field is also relatively new to forensics.
Stegdetect: Capable of detecting several different steganographic methods to embed hidden information in JPEG images.
Root kit detection-although a forensics issue, it is more of a networking issue. I wasn't able to find any freeware tools other than demos, although I was able to find alot of info for Linux.
***please excuse some of my over simplistic explanations, and bad jokes. Hopefull once I get a stable version of linux running (my project for the next few days) I'll be able to put one together for linux. Please also excuse my typos, bad grammar, etc.