Lab Setup
Last updated
Last updated
FOllowing resources helped me with lab setup
We can either choose to setup lab locally or in cloud.
In order of how we perform the setup in the video:
Download Windows Terminal (optional):
Download the VCLibs package. In a PowerShell window, run: wget https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx -usebasicparsing -o VCLibs.appx
Download the Windows Terminal MSIX bundle from the provided link: wget https://github.com/microsoft/terminal/releases/download/v1.15.3465.0/Microsoft.WindowsTerminal_Win10_1.15.3465.0_8wekyb3d8bbwe.msixbundle -UseBasicParsing -o winterminal.msixbundle
In a PowerShell admin window, add the VCLibs package: Add-AppxPackage [C:\path\to\downloaded\VCLibs.appx]
In a PowerShell admin window, run: Add-AppxPackage [C:\path\to\downloaded\winterminal.msixbundle]
(Optional) Pin Windows Terminal to the task bar
Disable proxy auto detect setting:
In the Windows search bar, search “proxy settings”,
Switch "Automatically detect settings" button off
Disable Tamper Protection
Search "Defender", open Defender settings and set all Defender Settings to off
Disable AV/Defender in GPO
In Windows search bar, search "group policy"
In GPO, navigate to → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Enable “Turn off Microsoft Defender Antivirus”
Disable Windows Firewall
GPO → Administrative Templates → Network → Network Connections → Windows Defender Firewall → Domain Profile → Disable “Protect All Network Connections”
Do the same but for the Standard profile
TAKE A SNAPSHOT!
Download and install FLARE-VM:
In PowerShell Admin prompt, run: (New-Object net.webclient).DownloadFile('https://raw.githubusercontent.com/mandiant/flare-vm/main/install.ps1',"$([Environment]::GetFolderPath("Desktop"))\install.ps1")
Change directories to the Desktop
Run: Unblock-File .\install.ps1
Run: Set-ExecutionPolicy Unrestricted
Accept the prompt to set the ExecPol to unrestricted if one appears
Run: .\install.ps1 -customConfig https://raw.githubusercontent.com/HuskyHacks/PMAT-labs/main/config.xml
Follow the rest of the prompts and continue with the installation.
When the installation is done, TAKE ANOTHER SNAPSHOT!
uncomment DNS service start
set bind address to 0.0.0.0
change dns_default_ip to remnux ip. i.e. 10.0.0.4
From windows machine:
view network connection > ethernet options > properties > ipv4 setting > update dns to remnux ip
In Host-Only mode, a guest VM does not know and cannot see the outer LAN. That’s good ✅
But it’s the VM→ Host and Host → VM communication capability represented in the first two columns of the table that tends to concern students. Let’s examine how this functions and some of the mitigating factors at play.
Assume that for the following section, I am using the FLAREVM host with a Host-Only network adapter with a configuration that mirrors the course’s lab network setup configuration. FLAREVM is the host that is used to detonate malware in the course, so we need to make sure it’s safe for our analysis efforts.
Our first experiment is to start a listening socket in our FLAREVM machine and attempt to reach it with our physical host. For simplicity sake, I’ll use port 80.
On FLAREVM:
From my physical host:
Just like the table depicts, we can route from our physical host to our guest VM.
But now, let’s attempt to do this in reverse. Note that I use a Windows OS for my physical host with a default set of host firewall configuration rules.
On my physical host:
From FLAREVM, I can try to access my physical host through its Host-Only adapter IP address, which is 10.0.0.1:
No connection is established. We can repeat this with our physical host’s LAN IP and the same thing happens. The Windows host firewall has prevented this from occurring. As long as the default firewall settings are configured, no connection will traverse from the guest VM to the host.
So when we think about the risk displayed in the previous test, what do we see? Our physical host can route into our guest VM, but our guest VM cannot route to our physical host because it is blocked by the host firewall.
Is there much risk in our physical host being able to initiate a connection and reach our guest VM? I would say no. Our physical host’s hypervisor is how we interact with the guest VM, so this represents another way that the hypervisor host can access the guest. If the opposite were true and the guest VM could initiate a connection to our physical host, it would be riskier.
If we imagine any malware sample that detonates in FLAREVM and tries to traverse out to our physical host, this traffic will now either:
be handled and routed to INetSim,
or, be dropped by the physical host’s firewall.
Now, that works well for Windows hosts, but what about a physical host running *nix or MacOS? While it’s true that these OS do not come standard with a host firewall, the malware in the PMAT course is not designed to be compatible with *nix operating systems. The one exception here is the Android malware sample, but this sample is only examined with static analysis methodology, meaning it is never executed. There are no malware propagation mechanisms in the malware in this course that can infect a *nix/MacOS host.
Additionally, *nix and MacOS can use the venerable iptables utility to drop traffic that is inbound from the guest VMs. iptables is built into the *nix OS and serves as a host firewall:
For the final part of this section, I’d like to offer the steps for how to make an Internal Network for our malware analysis lab. This is completely optional and you cannot have an Internal Network and a Host-Only network configured at the same time, so please pick one to configure.
Again, Host-Only is sufficient for this course. The Internal Network provides an additional level of safety that removes the reliance on a host firewall to protect our physical host, so if you are more comfortable implementing it, please feel free to do so.
I want to teach this because it is likely that, during your lucrative career as the world’s preeminent malware analyst, you’ll be faced with a situation where the risk calculus is such that an Internal Network is the only safe option. In truth, all of my malware analysis work is done with VMworkstation Pro and an Internal Network. While VMworkstation Pro is not available for free, the VirtualBox Internal Network is now sufficiently stable and usable that we can use it in the course.
We need to create an Internal Network and associate both VMs to it. We’ll start with REMnux. Perform the following steps to do so.
Right-click on the REMnux VM and select Settings
Click on Network
In the Attached To dropdown menu, select Internal Network
In VirtualBox, Internal Networks are associated by name. Add a name to the new Internal Network, like “pmat-internalnet”
Click the drop down arrow next to Advanced to expand the advanced settings
In the Promiscuous Mode drop down menu, select “Allow VMs”
Your settings should now look like this:
Click OK. Then, power on the REMnux guest host by clicking the Start button.
There is no DHCP server in the Internal Network, so we need to manually define a static IP address for the REMnux host. We will use the netplan utility to do so. The netplan utility uses a YAML config file to control the host’s adapter settings. This YAML config file lives in /etc/netplan/
Open the netplan conf file in nano with sudo:
We want to remove this from DHCP and assign all network information statically. YAML syntax requires specific code indentation to be processed correctly. Please pay attention to the amount of spaces for each YAML object.
Change dhcpv4 to no, add the addresses and gateway4 objects, and configure them with the following values:
yaml# This file describes the network interfaces available on your system # For more information, see netplan(5). network: version: 2 renderer: networkd ethernets: enp0s3: dhcp4: no addresses: [10.0.0.3/24] gateway4: 10.0.0.1
Now, we apply the configuration:
If no output returns after the netplan apply command, the YAML file is formatted correctly and has been processed.
If you get the following error:
… or:
… that means your YAML syntax is off somewhere. It will show you the line that you need to fix.
We can now inspect the adapter settings on REMnux:
FLAREVM is, believe it or not, a bit more straightforward than REMnux for this setup.
Right-click on the FLAREVM host and select Settings
Click on Network
In the Attached To dropdown menu, select Internal Network
Associate FLAREVM to the same Internal Network that we made earlier in the setup for REMnux by selecting it from the Name dropdown: “pmat-internalnet”
Click the drop down arrow next to Advanced to expand the advanced settings
In the Promiscuous Mode drop down menu, select “Allow VMs”
Your settings should now look like this:
Click OK. Then, power on the FLAREVM guest host by clicking the Start button.
Once you have logged in and are at the FLAREVM desktop, go to the Windows button and enter View Network Connections in the search to get to the Network Connection Adapter settings.
Two adapters are present: an Ethernet Adapter and the Npcap Loopback Adapter. Right click on the Ethernet adapter and select Properties → IPv4 Properties.
We will now statically define our IPv4 settings to mirror the Host-Only setup. This means that at the end of the day, we want:
The IPv4 address of FLARE to be set to something. It doesn’t matter what it’s set to as long as it’s a valid address in the 10.0.0.0/24 network and we keep track of it.
The Subnet Mask to configure a /24 network.
Our Default Gateway to be the REMnux host so we can make use of INetSim.
Our DNS server to be the REMnux host so we can make use of INetSim.
The correct settings look something like this:
Once this looks good, select OK and then select OK in the adapter settings window.
Now, examine the IP settings in a cmd prompt:
Note the entries for the IP address, subnet mask, default gateway, and DNS server.
Now, let’s test our network. Ideally, our network now facilitates communication between FLAREVM and REMnux while also denying traffic to our physical host and beyond. And unlike a Host-Only network, we don’t need to rely on a host firewall to drop traffic heading for our physical host.
The old ping test. Ping the other VM.
Under certain circumstances, you may see a ping response when pinging a DNS record. Depending on if you have been using the lab and INetSim, this response may be coming from the INetSim DNS resolver. Stopping INetSim, flushing the DNS cache on FLAREVM, and attempting to ping again should fix this:
Use the configuration details from the INetSim setup from PMAT and test to make sure FLAREVM can still ac;cess arbitrary DNS records.
Conclusion
That concludes this section on Host-Only network safety and creating an Internal Network for our malware analysis lab. You have learned more about the safety considerations of the Host-Only network setup and how to make an Internal Network to apply a greater degree of safety to the lab setup.
Don't worry we will automate network setup in next section.
Download Chrome:
If you are using *nix/MacOS for your physical host’s OS, it may be a good idea (though is not necessary for this course) to implement iptables rules for future analysis, especially if you want to analyze malware that is built for *nix. Please see the man page for iptables and for more information.
