Performing Forensic Analysis in Memory Acquisition Lab

By: Emily Wu

Introduction

As someone who has an interest in digital forensics and incident response, I was excited to take Computer System Forensics (CSEC-464) in my third year at RIT. In that class I learned a lot about forensically sound image acquisition, Linux and Windows file systems, different forensic tools, and the incident response process. I was able to take what I learned from lectures and apply it in the real world when I interned for Cisco on their Cisco Talos Incident Response team. While I had a lot of theoretical knowledge that I could pull from, I felt that I was not adequately prepared for hands on keyboard response.


When I was contemplating how the class could be redesigned or tweaked to better prepare students, I constantly thought back to the labs that were required by the class. A characteristic that seems to fit for most classes in the Computing Security department is that labs are either very step-by-step and hand holding, or the labs are very vague and open for interpretation. Computer System Security fell squarely on the side of being strictly step-by-step. This is great for students to achieve an easy mark in a class. However, I don’t believe that simply following lab instructions without needing to contribute significant outside thoughts and analysis is conducive to a positive learning environment. Personally, I do not learn much from copying commands and following steps. There is not much information retention because the action of completing the lab is robotic.

The Lab in question

One specific lab that I was looking forward to working on was “Lab #05 – Memory Acquisition and Analysis” (referred to as Lab 5). I was excited to try my hand at memory acquisition since memory holds a plethora of important forensic artifacts but is very volatile. I have since seen the value that memory analysis provides to an active investigation during my internship. Going into the lab I was anticipating doing something akin to a miniature forensic investigation on the memory of a machine using a memory analysis tool such as volatility. This did not happen. Volatility was used, but not in the context of analyzing an event on a machine or using an investigatory methodology. The lab was split into running commands on a capture of memory from a Windows machine and a capture of memory from a Linux machine. For the Windows section exact commands were given to the students to look up what is gathered with those specific commands.

Figure 1: Instructions for Part 1 of Lab 5


Part 2 only consisted of choosing random volatility commands to run on a memory dump from a Linux machine.

Figure 2: Instructions for Part 2 of Lab 5

I was disappointed in Lab 5 because I was excited to have the chance to perform memory forensics, but instead all I did was run a few random commands. It was nice to see the output of the commands and compare them, specifically the commands that dealt with processes, but that could have been done as a part of an investigation or as an extra aside to an investigation.

My Lab Environment

My goals in improving Lab 5 was to incorporate actual digital forensics into the structure of the lab, have more critical thinking involved, keep the scope of the investigation limited to memory analysis, have the attack that triggered the analysis to seem somewhat realistic, and maintain a small number of dumps to analyze. With the capabilities that I had creating a new lab from my laptop, I started formulating ideas. For an attack surface, I wanted one or two victim machines that were attacked by a Kali box. Since this was all running on my laptop with virtual machines in VMWare Workstation Pro, all the machines were on the same local network. This would be like an insider attack at a company. After much debate and testing, I settled on my victim environment being comprised of two Windows 7 SP1 Ultimate machines. I made this decision because Windows 7 has known vulnerabilities, it reached end of life just recently, but it is still found in large quantities in many companies. Therefore, attacks that I could perform against these machines has a connection to what companies could experience. One Windows 7 machine would be running Remote Desktop Protocol (RDP), while the other Windows 7 machine would run File Transfer Protocol (FTP). Both protocols would be configured to accept connections from the broader internet if the correct credentials are used. As a security professional that is not what companies should be doing; however, many companies have protocols misconfigured in this way and do not realize the problem until an adversary is already in their environment. Another bad practice that I have observed happen on customer machines and incorporated into my environment is the storage of information and credentials in plain text by a user. Thus, my overall environment consisted of an insider adversary machine, a Windows 7 box running RDP, and a Windows 7 box running FTP with credentials and personally identifiable information.

Figure 3: Topology of my lab environment

The Attack

As an insider, the adversary in this scenario would not need to go through any outside firewalls. The insider would also have at least vague knowledge of what services run in the environment. With insider knowledge that some machines run RDP, the adversary can run a nmap scan looking for RDP running on the standard port of 3389.

Figure 4: Results of nmap scan

From this, it is known that 192.168.253.143 is running RDP. Going through Metasploit, the adversary can check to see if it is an old enough version of Windows to be vulnerable to BlueKeep, an RDP exploit.

Figure 5: Output of checking BlueKeep vulnerability

Since the adversary now knows that the machine is indeed vulnerable to BlueKeep, they can use the Metasploit exploit to perform remote code execution on the victim’s machine.

Figure 6: Options set for BlueKeep vulnerability exploit

Figure 7: BlueKeep Vulnerability exploited through Metasploit

Now the adversary has a remote shell on one of the victim’s machines. Going through the user’s documents, a file named creds.txt is discovered containing information for another system.

Figure 8: User with file of FTP credentials

This provides the ability for the adversary to move laterally through the environment from the machine running RDP to the FTP server. After authenticating into the FTP server, the adversary found personally identifiable information and customer information that they exfiltrated to their machine and then possibly outside of the environment. Finally, the adversary put a note on the FTP server that an attack has been performed as a way of bragging. This is what alerted the victims to the attack. Yes, the attack was noisy, but it was also relatively quick. If a company does not deploy proper tools and monitor the output of the tools, it is possible for an attack such as this to slip through. 

Figure 9: Sensitive information exfiltrated from FTP server

Figure 10: Hacker note

The Investigation

After this attack was performed, snapshots were taken of the two victim machines in order to perform memory analysis. These two snapshots would be the files provided to students to analyze in the new lab. The students would also be provided basic information like the IP addresses of the victims, network topology and how the attack was noticed, and a potential IP address of 192.168.253.153. In this case, the victim on the FTP box saw the hacker note dropped and the investigation started. The RDP box was also pulled for evidence collection because initial searches indicated that machine also was connected to by the malicious IP address.

This section will describe steps that should be taken to complete the investigation. In the next section, appropriate lab instructions will be given so that students can perform this investigation. The first step that students should do is to figure out what profile to use when running volatility commands. This is done through volatility -f <image> imageinfo on both snapshots.

Figure 11: Getting profile of the memory file

From that information, the profile of Win7SP0x64 should be used for the rest of the volatility commands. Both machines are the same version of Windows. Given that the investigation is starting from the hacker note, the first step would be to figure out when the file was made. The investigation should start on FTP box. Creation, modification, and access times in Windows machines are in the master file table, so it would be most appropriate to search through the master file table for the name of the file dropped on the RDP box. This can be completed with volatility -f tundr45-Snapshot6.vmem –profile Win7SP0x64 mftparser | grep -B 2 hacked. The two lines above hacked are to see the headings for the times; however, it is not completely necessary in this instance because the times are all the same.

Figure 12: MAC times for hacked.txt

Since the hacked.txt file was put on the box by someone else, the student should investigate connections to the box, because the adversary had to get on the box somehow. The times from above may be helpful if volatility provides timestamps for connections relating to the investigation. Running volatility -f fr0z3n-Snapshot6.vmem –profile Win7SP0x64 netscan will show the student all the network connections to this FTP box. Going through the entirety of netscan’s output, there is only one IP address that connects to FTP, and that IP address is the local malicious machine with the IP of 192.168.253.153.

Figure 13: Portion of netscan output with FTP connections.

It is important to note the process and pid associated with that connection which is svchost.exe with a pid of 1240. From here, an investigator should be interested in what processes were spawned from this pid. To figure this out, a command such as volatility -f fr0z3n-Snapshot6.vmem –profile Win7SP0x64 pstree should be helpful. Pstree is a better option over pslist because it gives a hierarchically breakdown to easily see the parents of each process.

Figure 14: Output of pstree

In this instance svchost.exe does not spawn any child processes. This begs the question, what is svchost.exe with pid 1240 doing? Dumping the memory of that pid might be helpful. This can be accomplished through volatility -f tundr45-Snapshot6.vmem –profile Win7SP0x64 memdump -p 1240 –dump-dir tundr45_dump/.  This outputs a .dmp file to the specified directory.

Figure 15: Output file of dumping the memory of pid 1240 (svchost.exe)

Given that the artifact left behind by the adversary was hackled.txt and the IP address identified was 192.168.253.153, running strings against those values with a few lines above and below may give some context as to the actions of the adversary on this FTP box. Running a search for the IP address (strings tundr45_dump/1240.dmp | grep 192.168.253.153 -A 5 -B 5) comes up with a large section of activity that looks like the adversary logs into FTP, lists the files, retrieves customers.txt and secret.txt. It looks like they try to retrieve a file called secure.txt but given the bytes transferred, it does not look like it exists. It also looks like hacked.txt was put on the machine here. From the bottom of Figure 15, the output of a ls or dir command looks to be show. Furthermore, the timestamp for storing hacked.txt corroborates the timestamp of hacked.txt that was seen in the master file table.

Figure 15: FTP traffic from memory dump

Running the same strings command but on hacked shows the hacker note (minus the shocked Pikachu ascii art) which confirms that this is the note dropped by the adversary.

Figure 16: Strings output of hacked file

Knowing that both customers.txt and secret.txt were retrieved by the adversary is concerning. It would be helpful to know what are on these files. The first step would be to scan the files of the FTP box to get their physical location in memory with volatility -f tundr45-Snapshot6.vmem –profile Win7SP0x64 filescan | grep -E ‘customers.txt|secret.txt’.

Figure 17: Offset locations of secret.txt and customers.txt

After figuring out the offsets of the files, the dumpfiles plugin can be used to dump the contents of these files. The basic outline of the command is: volatility -f tundr45-Snapshot6.vmem –profile Win7SP0x64 dumpfiles -Q <file offset from filescan> -D tundr45_dump/ -u -n.

Figure 18: Commands and reading output for files customers.txt and secret.txt

The output of secret.txt and customers.txt should be concerning for the company. This looks like exfiltration of customer data. The incident has now crossed over into a breach. At this point, it is unknown how the adversary was able to obtain the creds for the FTP machine. Looking at the other box (RDP box) in this investigation may be helpful, because it also had connections to the adversarial IP address. Since the connection is information given to the investigator, the first logical step would be to check network connections with volatility -f fr0z3n-Snapshot6.vmem –profile Win7SP0x64 netscan.

Figure 19: Snip of netscan output showing an established connection with the malicious IP address

On this machine, the connection is not over a well-known port. However, we can see that the pid was 1116 with svchost.exe. As with the FTP box, doing a memory dump with volatility -f fr0z3n-Snapshot6.vmem –profile Win7SP0x64 memdump -p 1116 –dump-dir fr0z3n_dump/ then running strings fr0z3n_dump/1116.dmp | grep -A 10 -B 5 192.168.253.147 to look at the strings for the FTP box IP address – since it still needs to be figured out how the adversary got there – would be helpful. 

Figure 20: Output from strings.

From this output it looks like the user on the RDP box had a file on their desktop with their credentials into the FTP box with the IP of the box. This would be how the adversary gained access to credentials. But we still don’t know how they got into the RDP box because the port connected was not the standard RDP port of 3389. Like the FTP box, checking at the process tree with volatility -f fr0z3n-Snapshot6.vmem –profile Win7SP0x64 pstree might be helpful. 

Figure 21: Output of pstree of RDP box.

Two different cmd.exe processes and a findstr.exe process was spawned. Again, dump the memory of these processes. Since this is from the command line, filtering the output by “C:” will be helpful because that is at the start of basically every command line prompt. For this strings search, it is helpful to look at about 15-20 trailing lines like with: strings dump_frozen/2420.dmp | grep -A 20 “C:”.

Figure 22: Output of one match to “C:” in either cmd.exe

What should pop out to the student when scrolling up from the bottom of the strings output is the what is in Figure 22. “MS_T120 bluekeep bluekeep-” seems very interesting. Searching this online shows that this is part of CVE-2019-0708 (BlueKeep), a Windows Remote Desktop Connection vulnerability with MS_T120 being an internal channel that can be compromised.

At this point, a clear picture of the attack can be seen. An internal adversary exploited the BlueKeep vulnerability on the RDP box to gain access. From there, the adversary traversed the filesystem and found a file with the IP address and valid credentials to the FTP box. The adversary used these credentials to FTP into the FTP box. Sensitive documents such as customers.txt and secret.txt were retrieved by the adversary. Finally, the adversary put a hacker not on the FTP server. At this point the attack was noticed, and an investigation can begin.

New Lab

As I mentioned before, I wanted this lab to involve more critical thinking and to have digital forensics involved since the name of the course is Computer System Forensics. I think from the above investigation, I have demonstrated use of a digital forensics process. Below, I will provide instructions that I think would be appropriate for this lab that points the students in the right direction but does not give them entire steps and commands like many labs in the computing security major.

Software required: Volatility for memory analysis. Volatility is on the SANS SIFT Workstation and can be downloaded from the Volatility website. The Volatility command reference sheet will be helpful for this lab: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

Files: Download fr0z3n-Snapshot6.vmem and tundr45-Snapshot6.vmem from myCourses to analyze.

SHA256 hashes:

fr0z3n-Snapshot6.vmem:

182e0534916eacf7f3b50e5921114383b3cbb4445126a44a721d097fba1ce900

tundr45-Snapshot6.vmem:  d747642947aa0fb8220d9ddee35ce194930106598e021f8a51ad7203be2a1902

Background: This lab will be a forensic investigation of the machines fr0z3n and tundr45. The machines are a part of a company network. The investigation was launched when a hacker note was dropped on tundr45. Memory dumps from 2 machines were pulled because they both were connected to by the same internal IP address that is not expected to connect to these machines. The potential adversarial IP address is 192.168.253.153. Below is a quick and basic topology of the adversarial machine and the two machines pulled for analysis.

The note that was noticed on tundr45, hacked.txt looks like:

For each step, include the command run along with the desired output.

tundr45 (FTP):

  1. Figure out the profile of both the machines. This will be needed for every volatility command from here on out. (Hint: The first profile for tundr45 matches both boxes)
  • Figure out what time hacked.txt was created on tundr45. (Hint: Where are MAC times stored on a Windows box?)
  • Find out the connections to tundr45. Which connections might be suspicious? Who is the owner of the connection? What is the owner’s pid? What protocol does this connection use?
  • Does this process launch any other processes?
  • Dump the memory of this process.
  • Is there any information in the memory dump that relate to the currently known forensic artifacts? (Hint: use the information from the background, search for lines above and below the searched keywords [about 5 or 10 lines above and below])
  • At this point, what conclusions can be drawn? How did the adversary connect to the machine? What actions did the adversary perform after connecting to the box? What files were affected? How do the timestamps relate to the answer from step 2?
  • Scan the file system for these files. What are the paths of the files? What are the offsets of the files?
  • Are the contents of the files able to be dumped? What are the contents?
  1. Summarize the actions taken by the adversary. What extra concerns should the company now have from the discoveries made in steps 7-9?
  1. What do we not know about the attack through only investigating tundr45 and not fr0z3n?

fr0z3n (RDP):

  1. What are the connections on froz3n? What state is this connection in? Who is the owner of the connection? What is the owner’s pid? Is this connection over a known port?
  • Dump the memory of this process.
  • Is there any information in the memory dump that relate to the currently known forensic artifacts? (Hint: IP address of tund45 is now an artifact, search for lines above and below [about 5 or 10 lines])
  • Does the process that was connected to launch any other processes? What are these processes?
  • Dump the memory of the child processes.
  • Search through the memory dumps for the string that generally is at the start of every prompt in the process (Hint: include 15-20 lines below the matched string as well). What strings stick out?
  • Search this string online. What does this tell you about how the adversary gained access to this machine?

Wrap-Up:

  1. Piece the entire investigation together in a short write-up. How did the adversary get start the attack? How was lateral movement achieved? What files did the adversary access? What actions did the adversary perform on the files accessed? What led to the attack being noticed?

Conclusion

I think all the goals I had for when creating this lab was achieved with the instructions I provided above. Given the attack investigation scenario of my proposed lab, digital forensics became the entire point of performing memory analysis on the given boxes. This provides a lot more value to those completing the lab rather than just running a few commands. Connections needed to be made between the findings made from each Volatility command in this lab which adds to the critical thinking required. I did make the lab somewhat step-by-step because it will be of no use to students if they have no clue how to start the forensic process or become lost along the way. However, no specific command or module was listed. Furthermore, questions were placed throughout to make the students think about what they found, and what they still do not know. Certain words in the steps indicate what commands should be run, but students still must glean that information from the instructions and then figure out the syntax and required fields for each command. With the forensic artifacts found through Volatility, students should be able to figure out exactly how the attack occurred without needing any outside analysis tools. This is essential to keep this lab contained to memory analysis. While it may seem like RDP attacks on Windows 7 boxes are attacks that should not be seen anymore given that Windows 7 is no longer maintained by Microsoft, that is not the case. In my work at Cisco I have seen multiple ransomware incidents begin with RDP attacks including brute forcing RDP. Additionally, most companies that I have encountered still have active Windows 7 boxes in their environment. Thus, an attack on Windows 7 machines starting with RDP is not out of the norm. Finally, while this lab is longer than the previous version, it is not obnoxiously long for students to complete. They only need to analyze two boxes. That is not a hard ask for a lab of a 400-level class.

The previous lab does include information on how to set up a profile to analyze memory from a Linux machine and the execution of a handful of commands which is not included in this proposed lab. If wanted, that could be added as a part 2. However, I think the forensic analysis of the proposed lab provides immense educational value for a student in a computer forensics class. Therefore, I think this lab should be included as part of the curriculum for Computer System Security (CSEC-464).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s