Maxwell Evdemon

 

All information learned comes from the Advanced Forensics Lectures 1 and 2 by Christiaan Beek from McAfee/Intel software defense, and was provided by OSU CS 373 class.

 

Advanced Forensics 1 – Volatility, Forensic computation analysis, Yara signatures [1]

Analyzing memory is a popular, especially looking through that of memory dumps. Forensic investigations happen for a few cases with some being, fraud, intellectual theft of property, hack invasions and breaches of data, and inappropriate uses of the internet. This can also happen from child exploitation on the internet, and e-discovery civil litigation and criminal litigation. I learned that Forensic computing is typically the process of identifying, analyzing, and reserving some form of digital evidence that is seen as acceptable. It is process of finding data and using to solve some issue, I assume to usually incriminate some group that is breaking the law. It generally has three different steps to the process, the gathering of information, the analysis of that information, and the process of compiling that information and reporting it. I also learned that there are three categories to forensic computing, being the live forensics, post-mortem based of memory and disk and then the network-based information. I learned that forensics investigation is different than malware information, and the goal is to find evidence of what happened on that system, rather than judge the issue at hand. People are also finding ways to get around using computers, I learned that game station networks can be used to discuss things, I would assume that that would make it shared to connect people to a crime during an investigation. Another thing I learned is that this an be a dangerous field and that at times as this type of forensics can go hand and hand with police work. As some computer’s memory can be erased upon powering down or if it is unplugged from the network. For reporting the evidence, since this are typically handled in courts due to the nature of the crimes, it is important to provide a report in manner the court will understand.  When working in forensic the rules on should typically follow are, always minimize the data loss as I assume losing any form of data means one might lose critically important data, always record the work/evidence so nothing is lost, analyze all data found no matter how insignificant some things might be, and report the findings. Time is considered to be the most important thing during recording, both he actual time you work in and the system time, which will help greatly when looking through the timeline of a forensic investigation. I learned that forensics computing team typically has a writer to write down all events, if not it was highly recommended to write down everything physically on paper. I also learned that this field extends past the of the more basic investigation machines like computers and into strange things like smart TV’s, GPS data, and PLC controller where potential investigations can be quite difficult as tools do not generally exist for such strange platforms.

Evidence is something that can prove or reject a fact. I learned that evidence in terms of forensic computing it is typically found in the network, operating systems, databases and other applications, peripherals, usb/CDs/removable hard drives/media, and from people themselves. Getting familiar with operating systems is a must for forensic computing and will be dependent on typically what place of the world you are in for what operating system you may be investigating. Triage in forensic analysis is proving the same thing in multiple different ways, for what I assume is used to prove something. As multiple sources showing the same results should be trustworthy. One challenge investigators face is the hard disk, and the sheer size that a hard disk can contain, this alone can take a great amount of time. Whitelisting helps during these investigations due to the size of this files, as the investigator will no longer have to look through every file. The evidence should be kept the same at all times, this way there is no tampering with the data itself. This can be done by creating bit-image copies, creating some sort of cryptographic hash of all data. In order to ensure that the data has not been changed you can use that cryptographic hash/checksum and compare it to the original to confirm that they are the same and one can also lock in some original disk limit-limited area, I assume this way the data cannot be tampered with or accidently edited. I also learned that SSD’s can potentially do a sort of maintenance which will end up changing it’s data and thus invalidating the hash copy, which is another reason the best way for investigations is to write it all down in a way. I also learned that SSD’s also have their own tools and programs that are used for looking through them. Once all data from a hard disk has been thoroughly looked through, a write blocker is used to prevent an interference and is used a as form of one-way reader for the investigator to look into it more. Something interesting is, a forensic investigator cannot look through personal emails without approval from a judge, even though it could contain important information to an investigation, I believe this is likely due to some forms of privacy laws that protect a person’s information. The incident response process is the steps taken when responding to some issue. First issue occurs, then the initial response happens along with a strategy or plan to deal with the incident, next data is collected then analyzed and documented, from there depending on the situation there will either be legal or administrative action. During that entire incident response process the incident will also tried to be fixed or contained, this is also part of the overarching evaluation process. Most large companies have some sort of a response team, but smaller companies will need to bring in experts to help solve the incident. The picture below is from the power point lecture.

 

[1]

 

When looking for evidence when compared to the APT, advanced persistent threat, forensics investigator can map evidence to certain steps of that process, I assume that the process of mapping the data will allows for easier understanding of the incident during evaluation. When looking through the firmware or ISP logs those can be related to the reconnaissance step. Evidence found in the email gateway logs, proxy logs, internet history file, and java IDK files can all be traced to the delivery step of the ATP. Evidence found in the windows even logs or crash dump files can be related to the exploitation step. Any evidence found in the memory dump registry keys, or prefetch files can be mapped to the installation step. Memory dumps, firewall logs, IPS logs, proxy logs and netflow can all be resulted to the command and control step of a APT. memory dump, registry keys, prefetch files, remote tools and netfflow can all be mapped to actions and objectives step of the APT. You may notice some overlaps on the mapping, I assume this due to the fact that some of these pieces of evidence can be used for either or both those steps but having the mapping of the evidence should help in the valuation process still. I learned about the investigation cycle and the steps that are apart of it, those are verification, system description, and evidence acquisition. Those three relate to the actual cycle which is, timeline analysis, media analysis, string/byte searching, data recovery, and reporting analysis. Below is a picture from the advanced forensics lecture 1 slides showing the cycle.

 

[1]

I learned about Locard’s principle, the idea that all actions leave some form of evidence. This is true for computing forensics as well, particularly with network cables and usbs as, anything put into the system will change it. Anything that is originally contaminated in the files, cannot be changed back to its original form this is important as many investigations have to be dropped the second the evidence is changed. One of the first steps is disconnect the network cable as the attack could still have some remote access tot the machine. I also learned about an important concept for these investigative forensics, in particular the idea of order of volatility, the idea that you should always look and collect more volatile information first, RFC 3227. The volatile data will typically disappear upon shutting down the computer, which is why it is so important to get more important data first as it is all temporary in essence.  The order is usually as follows, first the system memory, then temporary system files, the process table and network connection (the process information that could be dumped, the network rounding information and ARP cache, the forensics acquisition of the disks, the remote logon and monitor data, the physical configuration and the network topology, and finally the backups of the data. After acquiring the volatile data move to acquire any non-volatile data such as time stamps, event logs, web application logs and if possible, the registry. After that look for any local files that may pass as evidence, this includes any unknown executable files, and tools that looks like that tack may have used, and then any other file that may relate to the incident case.

Starting into lab 1 of this lecture, something important I learned was to neve install forensics tools on the suspect computer as that counts as tampering with the evidence. Never store the memory dumps on the suspect machine, always store on some external storage device. This is also can be done through a network share to get the evidence off in a one-way path. I also learned about the FTK imager and how to use it. The FTK imager has a capture memory feature that allows you to look through the machine to a destination path, this will then start dumping memory from that path that has been selected. I also learned that FTK can be used to copy protected files through this way. FTK imager seems to primarily be used to copy files and data, for what I assume is used to look through data for analysis without actually tampering with the data. FTK has a read mode which allow the user to look at the data before a snapshot, this helps as it does not actually tamper with the data. The master file data cannot typically be copied, but the FTK imager can be used to copy and export of the master file which is critical for forensic investigation. The FTK can also create a physical disk image, in formats EN0 which is for Encase, raw which is compatible with Linux and various tools, and smart format, which can be seen at the destination in the FTK imager.  This process cannot change anything in the file, but it may change something in the memory which cannot be avoided. During the process of taking the image one can give it labels or descriptions, the file format has to be increased based of how big the image you are taking. That size should always be slightly bigger than that of disk you are imaging, or you run the risk of creating split files.

I learned that physical memory in this field is considered to be the RAM o f the computer, the short-term memory. This short-term memory will quickly disappear once the power connected to this short-term physical memory is disconnected. The short-term memory is an important memory dump for a forensics investigator, as I learned as the dumps can reveal anything hidden on the suspect computer. As for what can be obtained from this physical information, I learned that all running process during the snapshot, all loaded modules and dynamic link libraries with the added malware, all the running device drivers, all potential rootkits, all open files from all processes, all the registry keys from the processes, the open network sockets for each process, the IP address and port information for those process, any decrypted versions of encrypted data found, the content of any windows running, keystrokes recently made on the machine, email attachments or an other form or file transfer, any and all cryptographic key material, hard drive encryption keys that  are not normally found, any WEP and WPA wireless keys that may be unknown, and finally any usernames and passwords used on that computer.  With all that information it makes sense on why RAM and physical memory are so important to dump and analyze on any forensic investigation. Below is picture of a example memory dump, from the advanced forensics 1 lecture.

 

[1]

 

 

I learned that physical memory is divided into some thing called pages, these pages contain memory that is in turn mapped onto some physical memory. It is important to note that the same page of physical memory can be located at several memory address locations, and the memory on these pages does not get overwritten if the memory itself is free. I also learned about how process running on windows are assigned memory, each process has 4GiB divided into 2 GiB for the application and system respectively. I also learned about some of the ways to analyze memory dumps, looking for a sort of printable string in the data, reconstructing the data structures, or searching for a static signature which in turn should show the kernel data structures. The idea of looking at strings is what was done before some of the modern volatility tools we have today, which is why it is considered to be the original way to look through the memory. I learned that volatility stared as a way to read through windows memory dumps. Yara is a tool to create signatures, malware is then set against a certain signature and through the process of volatility it can then look for these signatures to identify them quickly. I assume this was done a way to save time when using volatility, as the investigator would be able to identify certain pieces of malware much easier.

Getting into Lab 2 I learned more about volatility specifically and how it is a free tool in python, where the user can write and create their own plugins. There is also plenty of plugins already made and available for users, for example Malfind, which is used to detect hidden or injected code into the memory. When working with operating systems it is always good to have up the volatility cheat sheet which details some of the useful commands for when working with volatility. When using volatility in windows it will be volitlity.exe and Linux it will be vol.py and it will have the same syntax overall. The syntax is as follows, -f “name of the memory dump” “plugin name”. Image info plug in is useful for looking up the operating system version and this will help in finding that. Volatility is primarily used to analyze memory dumps, but volatility can create memory dumps. In the case of having multiple suggested profiles you pick only one, and how that is done is by volatility -f “name of memory dump” — profile = “name of profile”.  For volatility -h is a help option and -psscan is will look in the memory dump for which process that were running on the system at some time. It will show the process id’s during this time, along with the parent process id. Which I assume can then be used to keep track of processes like the process explorer tool, except this time from the memory. The netscan and deskcan commands are for looking around the network and desktop activity respectively. The getsib command is used for which user rights the programs that were running which in turn I assume can be a great piece of evidence during forensic computing investigations. [1]

 

Advanced Forensics 2 – In-depth look at more tools [2]

 

I learned that one of the most important things, other than that of memory, to keep in mind during a forensic investigation is that of the registry, as many things are recorded within the register. I learned that even external hard drives and usbs are recorded within the register as it will show what was put directly into the computer. Regripper in tandem with FTK imager can be used to search for information you want. RegMon can be used to shows the registry in real time, which I assume would be useful for keeping track of the registry to make sure nothing changes when looking through malware. The default tool in windows is regedit, and it can be used to browse the registry files. I learned that there are five folders that are considered to be the most hierarchical and are refereed to as hives. Out of those five folders, two of them contain most of the registry information that forensic investigators are interested in are known as the HQ users and HQLM local machine.  The other three hives are generally considered to be shortcuts to reach other branches within the hives. I also learned about the structure of the windows registry, as each of the five hives mentioned above are composed of keys, and any values contained by those keys are considered to be sub keys. For these keys, values are the names of specific items that are held within a key. These will usually relate to an operating system or that of an application. Below is picture that represents this, I got this picture from the Advanced Forensics 2 PowerPoint/Presentation.

 

[2]

Looking at the registry always inspect autorun as it is one of the biggest places to find malware, I learned that is because malware want to survive the restart operation on the machine. This was it allows the virus to begin running upon restarting the machine through autorun. You can find wireless access points through the geolocation in the registry, this way you can see if a certain MAC address you are investigating connected there before. URLs are also stored within the internet explorer section of the registry which can be useful to see where the computer has gone to. I believe this shows just how important the registry table is during forensics analysis as it helps to find information a user could easily use as evidence in an investigation. When looking at timeline analysis, the $MFT is typically used which stands for master file table. From the $MFT you can see when files are created and deleted, but it normally cannot be accessed, but using FTK imager you can get the contents. Getting the information from the $MTF can then be used to create a volatile timeline analysis, but this process can also be done with the Regripper.

Getting into the first lab of this presentation about $MFT. I learned about timeliner and MFTparse. Timeliner is formatted like output = body >> “output file name”, in that output file you will see a overview of process that happened over the network along with unix times. Using MFTparser, the format is the same as timeliner to go to an output file. I learned what happens during this process is that it will go into the memory dump and find the master file table information and then output that information into that output text file, which can then be used for forensic analysis. The timeliner generally has less information than that of the MFTparser on output and will display its time in that of MAC time. I also learned that even if don’t have the disk but have memory dump you can still read run the disk commands similar to that of the master file table parser. Other things a forensic investigator should be interested in are the page files and index files, which I learned happen to be the internet explorer url files. Also look at windows event logs, the application files and condition files, prefetch files, and then anything that may be a sign of being tampered with from malware. The crash dumps of windows can also contain parts of malware files, which can be useful for reconstruction if necessary. Look through any antivirus log files as well, as it may show information on malware. I learned that the prefetch file in windows will contain the last 128 files that have been rand on the computer, which I assume would be useful for looking to see if parts of the have been accessed recently. The prefetch will also show the location and drivers that are utilized by some tool, which is why the prefetch folder is high on the volatility list as it is constantly changing. I also learned that you can look through the restores points to find possible malware as well, and that the malware will still be detected as long as it is part of those restore points. Other key files an investigator should look at are the hibernation file, any crash-dump files, the LNK files, and the shell-bag.

What is mostly used for data recovery is known as a concept of data carving. For data recovery, one needs to identify when they were deleted, look for some file fragments, possible unrecoverable data, recovery any possible pertinent files including that of images or emails, and then describe how you went about that process of data recovery. If a file is removed/deleted from that of a hard disk it places some information in a position, each of these positions have a start and end flag to show the data. I learned that when something is actually deleted, it is in fact not gone, but rather it removes the flags that mark where the data is. The only way that data is actually gone is if it is overwritten or hard wiped entirely. On SD cards for phones even if it is brought back to default you can still find information on them, so I assume that SD cards are a great way of finding out information that is wanted or unwanted. I learned that each file head will have some identification and foot that contains some bit to mark the end of the file. I learned about PhotoRec is carving program that can be used to look for specific things, in this case specifically photos. PhotoRec looks for specific signatures while running and is able to carve out anything with the matching signature, this is done by looking for a specified header to the footer, which is used as part of that signature. PhotoRec will only find complete files, but other data carving tools can look for parts of files. I assume this tool is very useful for investigations as it can help track down any evidence on a suspect computer/hard drive that had been deleted. I learned that sometimes the data is spread throughout a hard drive and need stop then be put back together. SleuthKit is tool used to look at lower level of data and is generally used for manually carving data rather than automated like PhotoRec. This moves to the next lab of this lecture. It is important to remember while using PhotoRec it assumes that the file is actually readable. In this lab I leaned how to use PhotoRec, it starts by point the tool towards some card that has data on it and also pointing it towards some output location. On the options part of PhotoRec you can choose what file you specifically want from that disk drive, if not interfered with it will default to simply carving all the matching files from that disk drive. The output screen of the tool will display how many files have been carved. [2]

 

Sources:

[1]    C. Beek, Class Lecture, “Advanced Forensics 1” College of Engineering, Oregon State University,

Corvallis, Jan., 2015

[2]    C. Beek, Class Lecture, “Advanced Forensics 2” College of Engineering, Oregon State University,

Corvallis, Jan., 2015

 

 

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *