Category Malware Analysis

After several weeks and a trip to Goodwill, I have successfully implemented my malware analysis lab as envisioned!

Part I: The Setup

My network is as follows:

I have the Edgerouter X serving several VLANs, but there are two in particular that I will discuss today. The two ethernet ports on the XenServer serve two purposes: one ethernet port connects to the VLAN aware switch and provides management functions, and the other is used by the VMs for a network connection. This network connection is connected to a Debian PC with two ethernet ports bridged together. That way I can snoop on any network activity silently to the VM. I can also break

Along with this upgraded network, I have revamped all of my firewall settings:

In this, let’s look at VLAN400 (my PC and its VMs), VLAN325 (XenServer MGMT), and ETH1 (both IN and LOCAL). ETH1 has the largest group of firewall policies (11 in total) than any other network. For IN, it can not communicate with any of the VLANs except for the FreeBSD VM located at 192.168.40.100, but only if it originates on the Debian PC. This way, I can have a full two full virtual layers of protection between this network and the rest of the network. If malware were to escape to my main PC, its chain of infection would be either:

Infected VM -> XenServer itself -> FreeBSD VM -> PC

Or

Infected VM -> Debian PC -> FreeBSD VM -> PC

For ETH1 LOCAL, it has two simple rules: Allow port 53 to the router, and deny everything else. This way, any VMs are unable to attack the switch itself through any of the VLAN IPs.

VLAN325 (the XenServer MGMT VLAN) has a similar firewall policy. It can only communicate with the FreeBSD VM:

All of this configuration is well and good, but does it work? All the configuration in the world does you no good if it simply doesn’t work in the first place!

Part II: Testing the configuration

Can my PC ping the Debian PC or the XenServer IP in the 10 network?

Can my PC ping the XenServer MGMT IP?

Can the XenVM ping the PC?

Can it ping the 10 network’s switch IP?

With our simple ping test, we can conclude that the firewall rules are working as expected. To confirm, I did do an NMAP scan of 192.168.40.* with the following commands:
nmap -T4 -d -v -F -Pn 192.168.40.1 192.168.40.2 192.168.40.10 192.168.40.100

Sure enough, not a single packet returned!

However, the 10 network isn’t so lucky. The switch gateway has DNS open; the Debian PC has ports 7, 9, 13, 21, 22, 25, 37, 53, 79, 80, 110, 113, 990, 995, and 3389 open; and the XenServer has ports 22, 80, and 443 open. I’m sure the iptables firewall could close the XenServer ports, but the open ports on the Debian PC are due to two programs I’ve installed.

Part III: PolarProxy and INetSim

By using this guide, we can capture, intercept, and blackhole any communication between the VM and the outside world. INetSim INetSim is an Internet Services Simulator Suite, and it provides simulation for popular protocols, such as HTTP/S, FTP/S, SMTP/S, and others. PolarProxy is a transparent SSL/TLS proxy created specifically for incident responders. These two programs plus Wireshark will form the backbone of the network analysis for malware, and since this is done off of the victim VM, it is practically undetectable.

One thing I do have to investigate is whether or not those SSL errors are fixable. However, that is not a show-stopper in any sort of the imagination! Here is the guide to install both PolarProxy and INetSim.

Part IV: What’s Next?

My first foray into serious malware analysis was in 2019. I was running a Windows VM within VMWare with an active internet connection and shared folders enabled. Fast forward a year and four months later, I have dedicated equipment and a very mature network and firewall setup. I think it has come time to do actual research on my setup and see just how well it can perform. As far as any upgrades to the existing setup, I would like to move the FreeBSD VM to its own PC altogether. After that, I would like to fully physically segment my lab network from everything else. Even up to the point of having its own router!

So earlier this week, I went over the creation of my malware analysis lab. Today I will finish setting it up

Part VI: Installing Openvm-tools

Following these directions, I was able to successfully install OpenVM Tools within my FreeBSD environment. It took a couple reboots, but everything worked as expected. It was nice to finally have something work on the first couple tries!

Part VII: Installing Xen Orchestra

This one was pretty easy. Xen Orchestra requires 4GBs of RAM, and a few dependencies specific to FreeBSD. These are:

• gmake
• redis
• python
• git
• npm
• node
• autoconf
• gifsicle
• jpeg-turbo
• optipng
• yarn
• npm
• node

Easily enough, all of these packages can be installed with:

pkg install gmake redis python git npm node autoconf jpeg-turbo optipng gifsicle npm node

After everything is installed, you can then follow the official documentation. Once built, configured, logged in, and attached to your XenServer, it will look like this:

Part VIII: Implement Firewall Rules

Out of everything in the lab, this is the absolute most important. Without adequate firewall rules, the Windows 7 VM can interact with anything on the network. This is… not good. Especially considering most malware nowadays can spread at the speed of light. So, we will need to implement rules in order to protect everything on the network. Currently, my router acts as my firewall, so we will configure it from there.

The first part is to connect the XenServer to an open port, and assign a new VLAN to it. For my setup, the server is connected to port 3 and I have assigned it VLAN 12:

This will reboot the router, and once the router comes back up, port 3 no longer has access to the network. We can identify this from our previously connected XenCenter reports the XenServer offline:

Now its time to configure our VLAN. I labeled it “To MAL”, enabled NAT masquerade, net isolation, and assigned an IP address of 10.10.220.1. The DHCP server is set to start at .35 and have a maximum of 5 IPs:

Finally, I have to write the firewall rules, which will have to come later. Until next time!

Man, what a week.

In order to more safely analyze malware, I needed an entirely separate environment to run harmful programs. Previously, I would run them in a VM hosted on my personal computer through VMWare. This is how the VBScript was de-obfuscated.

“But Brandon, isn’t running harmful code dangerous?”

That’s why it’s in its own VM. To ensure that should it break, it won’t destroy the rest of the computer. Unless it escapes of course.

“Escape? Escape from what?”

There are certain exploits that malware can use to “break” out of its sandbox, and thus run whatever hack code they want on your own computer.

“Perhaps it is not the best idea to run malware on your own computer.”

And that is why I have revamped my malware analysis lab! I will be running malware on a VM hosted on a Dell PowerEdge R310 with Citrix XenServer. I will have a firewall rule in place to only allow the XenServer to communicate with the outside world and a FreeBSD VM running on my computer. With XenServer, I can run a program called Xen Orchestra in order to manage my XenServer. That way, my personal computer should be much more protected in case of malware attempting to break out. The workflow would be as follows:

Personal Computer -> FreeBSD VM -> HTTPS -> XenServer -> Malware VM

I have 90% of this setup up and running right now. Here is what I did:

Part I: Deploy New Webserver

The first thing I needed to tackle was to set up a new server for my website and this blog. I chose AWS because a simple Windows Server would cost me about <$20/month whereas GCP and Azure would have costed a bit more. Simple enough. AWS EC2 makes it simple and quick to launch new instances for whichever need you have. I chose Windows because I wanted to have the experience of being my own Windows Server Administrator.

This would prove a disaster later on.

I get my Windows Server set up, install IIS and the required plugins, set up my server, and figure out how to install WordPress. Web Platform Installer has an automatic WordPress install. Woo!

Installed it, got it configured, and…. there’s a security warning. Apparently this version of WordPress installs PHP 5.1 !!!, MySql 5.1!, and an outdated WordPress version. These are horribly out of date. Need to update.

First on the list is WordPress itself. It has a button. You click the button and boom. Updated 🙂 Easy enough.

Second is PHP. Got PHP 7.4 installed, and now WordPress has an error. I ran PHP manually from the command line, and I get an error popup:

A quick Google search states this is due to PHP requiring the Microsoft Visual C++ Redistributable for Visual Studio 2019. I installed it, WordPress no longer has an error AND reports that PHP is up to date.

Next was MySql. That was rough. It took me 4 days, and I ended up deleting everything, including the Windows Server itself, and started over from scratch. This time, I installed everything manually, using the official installation walkthrough. After that, worked like a charm.

Part II: Securing the WebServer

This is the next thing that took forever at two days. I originally went with OpenVAS. However, I quickly found out that OpenVAS is now Greenbone Vulnerability Manager. It is the absolute worst thing I have ever had the misfortune of attempting to install. Since it is a Linux application, I had to fire up a Linux VM. My first try was in Ubuntu, however, the apt-get didn’t work. It just simply didn’t start at all. My second through sixth attempt was in Kali Linux. All attempts failed. I used apt-get, an automated script I found on GitHub, the manual build process, and a mix of both. It just simply didn’t work. Fine. I then tried to use their pre-packaged VM. But that too failed. I gave up on GVM.

So I then went to my good friend Nessus. I installed it in my Kali VM, and it worked the first try. As of this writing, I have 9 medium vulnerabilities to fix:

The last thing I needed to do was run the Microsoft Baseline Security Analyzer. However, that is no longer supported 🙁

I did find out that its successor is the Microsoft Security Compliance Toolkit. So, I have something else to get running.

Part III: Building the Malware Analysis Environment

Out of everything, this was the easiest. I was originally going to go with VMware’s ESXi, but my PowerEdge is too out of date. However, Citrix’s XenServer happily runs on the old hardware. Tough decision that was 🙂

Since I do not have a DVD drive, I have to boot my new OSs through PXE Boot. I use (and highly recommend) Serva for all my PXE Boot needs. Simple to install and works without a hitch. I got XenServer installed, and then XenOrchestra installed on my Ubuntu VM for testing. It works! However, it appears I couldn’t start VMs through XenOrchestra, so I installed XenCenter. Worked perfectly. Well… almost.

I configured my Windows 7 VM on XenServer, got Serva running, tested Serva on my PXEBoot VM, and went to install Win7. Nope. Connection timed out. No matter which settings I tried, the guest VM refused to boot. I even tried another PXE Boot server. Didn’t work. Was my project dead in the water? It almost was until…

I realized I can IMPORT VMS through XenCenter!

And VMware Workstation can export! I can load VMs this way!

So, Windows 7 was installed in VMware, exported, imported into XenServer, and now it runs!

Part IV: Installing FreeBSD

This was the most difficult part of this project. I have never used FreeBSD in my lifetime. Never even seen it. FreeBSD installed fine, but it doesn’t come with a GUI. So I installed the GUI, set the resolution, and it appears to be working. Sweet. I just have to finish configuring it for VMWare, and then I can install Xen Orchestra.

Part V: Finding Malware

I have decided my first analysis will be on the Clop Ransomware. This is a really nasty piece of malware family that encrypts your files until you pay. I wrote a paper on the Clop ransomware, so naturally, this would be the first analysis done. My first step is to actually find it in the first place. The McAfee blog gave me an MD5 hash of:

ed7db8c2256b2d5f36b3d9c349a6ed0b

So we have our starting point. The first place I searched from this list is app.any.run. So I put the MD5 has into the search and…. could it be?

On the first try, no less! There it is! In all its glory! Or is it? There’s only one way to find out.

The McAfee blog post shows a snippet of the disassembled code with the memory address included. If we go to that specific memory address, we find….

The same. exact. assembly code in McAfee blog post. I can conclude with reasonable accuracy that I have acquired the Clop ransomware file. Next week, I will dive into this sample!

So a couple weeks ago, I found a thread on Reddit called Help reading a potentially malicious vbs file. The Original Poster had came across a VBScript file that looked rather….. weird. So! To the drawing board I went!

This VBScript is 100% unreadable in its current form. It has a giant array list directly in the middle of the file, it is one line, and every variable is gibberish. When writing malware, this is called obfuscation, as you do not want people to figure out what your virus does. However, you can only take obfuscation so far in programming. The first step in the process of analyzing this script is add line breaks. For any “::”, we will replace it with “/n”. This will convert every line continuation character with a literal new line character.

That looks much more readable! The next steps is to remove the various ” “+” ” strings, and to give it proper indentation. After that, we can get to actually figuring out what each subroutine does.

Now that we have everything indented, its time to replace every gibberish word with something meaningful. This is where the difficult part comes in…. It’s like putting a 2000 piece puzzle back together. The more knowledgeable you are in the language, the easier this becomes. After completing the puzzle, it will become clear what the VBScript does:

If you noticed the message box added between the highlighted lines, good! I added it to pause execution while I grabbed the ZIP file. Inside the ZIP file is our malicious code:

Finally, this script will register this text file as a DLL, thus starting the infection process. That will be covered in Part 2.

Stay tuned!