32 Bit Windows Kernel Mode Rootkit Lab Setup with INetSim
Author’s Note: I’ll be cross posting this article here and on augustomalnalysis.home.blog. I’m transitioning away from Medium due to the premium membership requirements for readers.
Preface
I decided to make this article after struggling to set up simulated networking on my own malware analysis lab due to outdated guides. I realized that an updated guide may help some people. This guide is also related to an upcoming series where I demonstrate static analysis, dynamic analysis, and memory analysis of kernel mode rootkits.
This guide requires:
- VirtualBox on a Windows host (7, 8.1, 10, the host is not relevant to this guide)
- A REMnux Virtual Machine (found here)
- A Windows 7 Professional 32 bit iso image, pre-Service Pack 1 (you need to acquire this yourself)
This guide covers the following topics:
- Creating a Windows 7 x86 VM and installing Flare VM
- Preparing a Windows 7 VM for kernel mode debugging, skip if not interested in rootkit analysis
- Configuring INetSim and Burp Suite on a REMnux virtual machine
- Configuring the Windows victim to redirect traffic to INetSim and Burp Suite
This guide does not cover the memory dumping, anti-anti-debugging, or import reconstruction software that I will be using in future tutorials. I will not be covering importing the REMnux virtual machine into VirtualBox, as I trust you can figure that out. This guide assumes you already have WinDBG installed. If you need to set up WinDBG on a Windows 10 host, please see my previous guide. Please note that I set up the pipe on the Virtual Machine instead of in WinDBG for reasons I outline in the linked guide. Some of what is covered there is covered here in terms of guest setup.
I will not be covering the installation of the VirtualBox Guest CD on the victim because it is not recommended. I do it anyway because I’m willing to put up with a lot of patching to avoid that tiny screen.
Windows 7 Victim Setup
As I mentioned previously, it is very important that your Windows 7 ISO is both pre-SP1 and 32 bit. 32 bit malware runs differently on 64 bit systems.
When creating a Windows virtual machine, there are a few considerations.
First of all, you need to give it enough ram to run properly. I like to give mine around 3GB.
You’ll want to create a virtual hard disk with 45–50GB of RAM, as you will be installing Flare VM, a large malware analysis toolset.
After this, you can select your Windows 7 ISO and install your VM. Note that it must have access to the internet for the first part of this guide.
Once you have this installed, there are a few things you’ll want to do to prepare your system for Flare VM.
Flare VM needs to reboot the VM periodically during installation, so you need to turn off login procedures. Type “netplwiz” into run to bring up the user menu.
Deselect the box that says, “Users must enter a user name and password to use this computer,” ensuring that you type in the correct password. Windows will give you no indication that it is wrong, you’ll just get an error at the next login.
Now it’s time to put Windows in a vulnerable state. You must disable Windows Defender.
Disable the firewall.
And disable checking for updates.
Now it’s time to install Flare VM. To download the install script, you must first activate https support Internet Explorer. This is done under “Internet Options > Advanced > Security”. Just enable SSL and TLS setting.
Downloading from github is difficult with older versions of internet explorer, but copying raw files to the system is still viable. Flare VM will install Google Chrome, but for now you must access the raw ps1 file through this link:
https://raw.githubusercontent.com/fireeye/flare-vm/master/install.ps1
Copy the entire script to Notepad and save it as “install.ps1” in your Documents folder.
After this, you must open Powershell as an administrator and move to the Documents folder. To disable the restrictions on Powershell scripts, type “Set-ExecutionPolicy Unrestricted”.
You can then install Flare VM with “.\install.ps1”. This will take several hours, and requires a restart after completion.
Preparing Windows for Kernel Debugging
There are three things you need to do to prepare Windows 7 for kernel debugging and kernel mode rootkits: Dropping driver protections, enabling debug mode, and creating a pipe for your host to connect to with WinDBG.
Windows 7 protects against unsigned drivers, which is no good unless you’re looking at advanced kernel mode rootkits that can bypass this protection. Fortunately, you can turn off this feature by running the command “bcdedit /set nointegritychecks on” in an admin command prompt.
You can enable debug mode with the following commands:
bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200
After this, you must shut down your virtual machine.
Note: I do not cover disabling trusted installer here, because if you’re dealing with old school kernel mode rootkits that attempt to overwrite protected drivers, your best bet is probably analyzing the user-mode portion to determine what drivers it will attempt to overwrite and removing trusted installer protections from those specific drivers ahead of time. I’ll have to do this when I analyze Cutwail in a later tutorial
Before you turn it back on, go into settings, into “Serial Ports”, and create a custom “Host Pipe” on COM1, make sure it isn’t connecting to an existing socket, and put in your own socket, “\\.\pipe\MalDBG”.
Now you have a pipe that you can access from the host for debugging purposes. Restart your Windows VM, shut it down again, and take a snapshot. It is time to configure networking on the REMnux VM.
Configuring REMnux for Traffic Analysis
Before you even start up the VM, you need to switch the network interface over to “Internal Network” and come up with a name for your internal network. You’ll be using the same one later in the victim network setup.
The reason you’re using INetSim is because all required software is pre-installed and there is no need for network access. This is also true of Kali Linux circa 2019 if you want to use a Kali VirtualBox image.
Start up the virtual machine and type “sudo nano /etc/network/interfaces” to configure the internal network to use a static IP. Copy what I have here into the config file.
Note: The interface name changes every few years with new VirtualBox versions, it used to be “ens0cap” or something. Either way, it’s eth0 now, but just go with whatever primary interface you see. After you do this, save the file and type “sudo ifdown eth0 and sudo ifup eth0”.
Run an “ifconfig” and ensure your IP and netmask match the ones on the screen.
If they match, open up the INetSim config with “sudo nano /etc/inetsim/inetsim.conf”. I actually do it with gedit because searching is easier, but if you want to use nano that’s fine.
In the “start service” section, uncomment dns, http, and https.
Now set the service bind address to “0.0.0.0”.
Set the dns default IP to the one from before.
Set the https bind port to “8443” instead of the https port 443, because you’ll need to intercept the traffic using Burp Suite and redirect it back to INetSim.
And set the http bind port to 880 for the same reason.
Save, exit, and restart INetSim with “sudo /etc/init.d/inetsim restart”.
Now that you’ve set up INetSim, it’s time to set up Burp Suite. You can launch it with the “burpsuite” command.
Once you’re in burpsuite, you’ll need to configure the proxy to view traffic on two new ports. This can be done by going to the “Proxy > Options” tab.
You should see one pre-existing listener on port 8080. Don’t mess with that, you’ll need it to download the SSL certificate for the victim machine.
To add the https port to the listener, click the “Add” button, bind to port 443, and select “All interfaces”.
Next, go to request handling, redirect to localhost:8443 (your INetSim https interface), and select “Support invisible proxying”.
Repeat this process for http on port 80, redirect to localhost:880.
Now you’ll need to export your certificate for transfer to the victim. Go to “localhost:8080” in the browser and click “CA Certificate” to download the certificate.
Note: Sometimes the Windows 7 VM is finicky about the type of USB drives it accepts. You may have to import the certificate file as an ISO.
You are now finished setting up your REMnux VM. Take a live snapshot and leave the VM open for the victim networking setup.
Networking the Windows 7 Victim
Your Windows 7 VM should be shut down. Before you power it up again, you’ll need to set it to use the same internal network as the REMnux VM.
When you power on the Windows 7 VM, navigate to the “Network and Sharing Center”, right click on “Local Area Connection”, and select “Properties”. In the dialogue box that pops up, disable IPv6. Then select “Internet Protocol Version 4” and click “Properties”.
Then set the IP, netmask, and DNS server to the following settings.
Select “Validate settings upon exit” before exiting. This will check if your Windows VM connects to INetSim. Then apply the changes and exit network setup. Ensure that the troubleshooter indicates you are networked to the REMnux VM before continuing.
Note: If your network connection succeeds but the troubleshooter indicates a DNS connection error, run a netstat in your REMnux system and ensure that DNS is up and listening on the correct port. This is a common cause of error, as DNS is off by default in the INetSim settings.
You can now check and make sure that http is working by putting any “http://” URL into Internet Explorer. You should see the INetSim notice.
Before you can check https, you’ll need to import the Burp root certificate into the “Trusted Root Certificate Authorities” folder by double clicking on downloaded certificate on the Windows 7 VM and walking through the certificate installer.
At this point, you should be able to run the same test you ran on https to check if the certificate has been correctly installed. Ensure that you do not get a certificate error when you attempt to access your test site.
Note: Certificate errors usually mean that you didn’t install the burp certificate in the correct store. Run the installer again and check if your certificate is trusted.
If you’ve done everything right, you should have a rootkit analysis lab with internal networking. Take snapshots of every virtual machine and shut them down, restoring to the snapshots. Good luck!
Sources
