By Michael Schade
In the summer of 2017, companies all around the world were being successfully attacked by something called WannaCry which took advantage of a critical vulnerability in the SMBv1 protocol. Starting in May 2017, attackers were using EternalBlue to completely encrypt the victim’s Windows servers and workstations. This created a huge event in the news, due to victim companies having to pay the attackers large amounts of money, usually in the form of bitcoin, in order for the attackers to remove the encryption. This attack was then added to the popular penetration testing operating system, Kali Linux, which allows security professionals to test their infrastructures.
Something doesn’t look right
A very useful tool for analyzing an attack like this is called the Volatility Framework created by The Volatility Foundation. It is a free download for Windows, Linux, and MacOS, but can also be downloaded as source code, which is what I did in my example. I was using MacOS but still decided that using this as a command line tool would be the most effective way to present the information.
Let’s Check for a Pulse
The first part for this example is to check to see if an unsuspecting victim would be vulnerable to this attack. The victim operating system I am using is Windows XP SP3 which allowed me to perform these attacks easily, considering the main part of this example is to use the volatility framework. Using a scanner module in Metasploit, I was able to test whether or not the victim operating system was vulnerable.
Ignore the fact that this says “INFECTED” and recognize that it says, “Host is likely VULNERABLE to MS17-010”. This first step gives us a good idea that the host might be vulnerable to the EternalBlue attack. The next step is to actually create the attack and then exploit the vulnerability. The EternalBlue-Doublepulsar attack that ElevenPaths created over at GitHub (https://github.com/ElevenPaths/Eternalblue-Doublepulsar-Metasploit) is the attack that I used for this example. After following the installation instructions, I began to setup the attack and the payload for a reverse TCP shell.
Now it is time to start up the attack and fill in all of the information that is necessary in order to complete the attack.
Above you can see the output of a “show options” command. The RHOST section is set to the victim’s IP address while the LHOST, which is a setting in the payload, is the IP address of my Kali Linux box that we will be creating the listener for the reverse TCP handler. Since this attack uses Windows executable files in order to run the attack, wine32 is needed on Kali, hence the “WINEPATH”. The PROCESSINJECT is the setting for the name of the process to inject the attack to. In my situation, the Windows XP image was set to x64, so I had to change it to “lsass.exe”. Otherwise, this attack will not be successful and Metasploit will say that the attack went through, but no sessions were created. After I set the payload to be the reverse TCP handler and set the IP address to my Kali box, I was ready to perform the attack.
This is what we were looking for, a meterpreter session, which shows that we have successfully exploited the vulnerability and have a shell on the victim operating system. Now we can do whatever we want to the victim’s system as a root user. After doing this, I decided to migrate the process to something easier to identify in the output of a memory dump. Using a post exploitation module that is built into Metasploit, I was able to migrate my backdoor to a process called “notepad.exe”.
Since the process is now notepad.exe, we can view it easier within the Volatility Framework, and we can see in the next picture, that the notepad.exe process exists and is being run as SYSTEM, but notepad.exe is not running on the system.
Its Memory Time
Using VMware Fusion 10, I created a snapshot of the Windows XP image’s current state with our process still running. A feature of VMware is that once you create a snapshot, it creates a “.vmem” file which is a snapshot of the VM’s memory at the current state. This is the kind of file that the Volatility Framework works really well with and allows for memory analysis. The Volatility Framework is downloaded from their site (http://www.volatilityfoundation.org/26) and like I put earlier, I used the source code download for my example. Now that I had the script, I can start the analysis
How to Volatility Framework
The Volatility Framework is extremely powerful and can be used for many different things when it comes to memory analysis and forensics. Now that I had the program downloaded, I ran it on the “.vmem” that I had received from the snapshot of Windows XP. To start it off, I ran the following command to get information on the file that I had passed it.
This returns the output of:
Now this output doesn’t necessarily impact this example at all, but it’s a good idea to use that command, especially if you don’t know what kind of system the memory file is from. It’s a good first command for any memory analysis or forensic investigation.
Time to Dig In
The next step is to start looking into what is running on the machine that we grabbed the memory dump from. This leads to the use of the “psscan” command that will be used to display a list of the currently running process on the machine at the time of the snapshot.
This returns the output of:
From this output, we can see all of the processes that were running on the victim machine. Due to the migration of the malicious process to “notepad.exe”, we can see that it is indeed running on the machine. The “notepad.exe” is our current shell running on the machine, but the backdoor that was created by Metasploit is actually the “rundll32.exe”.
You can tell that there is something suspicious about the “notepad.exe” because if you run the following command, you get an output that shows that the notepad process is running as system32, which normal users will not be doing.
To look deeper into these malicious processes, we can take advantage of the fact that we are using Windows XP by using the “connections” command that will tell us what connections are being made between the Windows XP machine and any other remote device.
Wait, Something Isn’t Right
Now that we see some random processes, we want to see if these processes are connecting to other remote addresses that might not be wanted. Usually, malware will contact a command a control server, so using this feature that is built into the Volatility Framework, can be very helpful. Using this command:
Gives the output of:
Now this adds to our suspicion. Since I had created the reverse TCP handler, I know that it is communicating over port 4444, as I had set that in the exploit. This also shows us what process is talking back to our meterpreter shell, process ID 716. Running another “psscan” gives us the following:
Well Now What?
Now that we have the malicious executable, there are bunch of commands that would allow us to dig deeper into that executable like looking for DLLs, and using more Volatility Framework tools to dump those DLLs which would allow for someone to put them into a site like VirusTotal to see if that executable was indeed involved with the attack. You can also do things like view command history, show device trees, and look much closer at memory information.
All in All
The Volatility Framework is a very powerful tool that is used for forensics and memory analysis, especially after breaches. EternalBlue posed a real problem to a ton of companies, causing them to fall victim to ransomeware and WannaCry. Luckily, security professionals have figured out how to fix this issue, as well as Microsoft has released updates for their supported operating systems.