Host-only Safety & Internal Networks

Introduction

Safety is taught from the beginning of this course and underpins every single activity that we conduct. One of the most critical pieces of the malware analysis puzzle is the lab setup. Isolating a malware analysis lab is incredibly important to reduce the risk to your physical host and surrounding network.

So far, we've learned how to create a malware analysis lab network that uses a Host-Only network adapter to facilitate communication between lab hosts. Over time, other PMAT students have approached me with a reasonable concern regarding the lab network setup. Their concern usually goes like this:

“If Host-Only mode allows a VM to route to the physical host in some circumstances, can it really be considered safe for malware analysis?”

I applaud my students for approaching me about this because it means they are thinking critically about safety during malware analysis. While we can never truly eliminate the risk incurred during malware analysis, we must make every effort to mitigate the risk as much as possible wherever it exists.

In this section, I’d like to cover some of the safety considerations for the Host-Only network setup to assuage these concerns. I’d also like to walk you through an additional, optional lab network setup for those looking for an extra degree of security.

Host-Only Safety

First thing’s first. I’d like to get this out of the way immediately:

The PMAT course’s Host-Only lab network setup, when followed to the letter, is safe, has been safe, and will always be safe for malware analysis during this course! There is no need to setup an Internal Network to complete the course safely. The malware in the course has been designed and/or chosen to be as safe as possible in tandem with this lab set up.

In most circumstances, a Host-Only setup effectively mitigates the risk of a malware sample being able to route out to the greater internet to download second stages or call back to a C2. This comes standard with the design of a Host-Only network.

Consider the following table of VirtualBox network configurations:

https://www.virtualbox.org/manual/ch06.html

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.

Safety Test

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:

C:\Users\husky>ncat -nvlp 80
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:80

From my physical host:

PS C:\Users\Matt> ncat -nv 10.0.0.4 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.0.4:80.
hello!



C:\Users\husky>ncat -nvlp 80
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:80
Ncat: Connection from 10.0.0.1:1343.
hello!

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:

PS C:\Users\Matt> ncat.exe -nvlp 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80

From FLAREVM, I can try to access my physical host through its Host-Only adapter IP address, which is 10.0.0.1:

C:\Users\husky>ncat -nv 10.0.0.1 80
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: .

PS C:\Users\Matt> ncat.exe -nvlp 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80

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.

*nix and MacOS

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:

# iptables -A INPUT -s [IP ADDRESS] -j DROP

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 this site for more information.

Internal Networks

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.

Setting Up REMnux

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:

image

Click OK. Then, power on the REMnux guest host by clicking the Start button.

REMnux Static IP Assignment

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:

remnux@remnux:~$ sudo nano /etc/netplan/01-netcfg.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: yes

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:

Now, we apply the configuration:

remnux@remnux:~$ sudo netplan apply
remnux@remnux:~$

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:

remnux@remnux:~$ sudo netplan apply
/etc/netplan/01-netcfg.yaml:10:10: Invalid YAML: inconsistent indentation

… or:

Invalid YAML at //etc/netplan/01-netcfg.yaml line 7 column 6: did not find expected key

… 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:

remnux@remnux:~$ ip -br -c a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
enp0s3           UP             10.0.0.3/24 fe80::a00:27ff:feef:67e4/64

Setting Up FLAREVM

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:

image

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:

image

Once this looks good, select OK and then select OK in the adapter settings window.

Now, examine the IP settings in a cmd prompt:

C:\Users\husky>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : DESKTOP-M87PSAK
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physical Address. . . . . . . . . : 08-00-27-55-06-07
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::f4fb:f210:ea5a:478f%4(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.0.4(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.0.3
   DHCPv6 IAID . . . . . . . . . . . : 101187623
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-B4-6C-F2-08-00-27-55-06-07
   DNS Servers . . . . . . . . . . . : 10.0.0.3
   NetBIOS over Tcpip. . . . . . . . : Enabled

Note the entries for the IP address, subnet mask, default gateway, and DNS server.

Testing & Troubleshooting

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.

Test Connectivity Between VMs

The old ping test. Ping the other VM.

On FLAREVM:

C:\Users\husky>ping -n 2 10.0.0.3

Pinging 10.0.0.3 with 32 bytes of data:
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.3:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

On REMnux:

remnux@remnux:~$ ping -c 2 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=128 time=0.308 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=128 time=0.321 ms

--- 10.0.0.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1020ms
rtt min/avg/max/mdev = 0.308/0.314/0.321/0.006 ms

Test Outbound Connections

Ensure that our Internal Network is truly isolated with a few tests. Each of these tests should fail which indicates that our network is not routable to our physical host and beyond.

On REMnux:

remnux@remnux:~$ ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
From 10.0.0.3 icmp_seq=2 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms
pipe 2

remnux@remnux:~$ nslookup google.com
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find google.com: SERVFAIL

remnux@remnux:~$ ping -c 2 [your physical host's IP address/Wifi address]
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
From 10.0.0.3 icmp_seq=2 Destination Host Unreachable

--- x.x.x.x ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms
pipe 2


On FLAREVM, repeat the previous steps.

C:\Users\husky>ping -n 2 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 8.8.8.8:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),

C:\Users\husky>ping -n 2 google.com
Ping request could not find host google.com. Please check the name and try again.

C:\Users\husky>ping -n 2 [your physical host's IP address/Wifi address]

Pinging x.x.x.x with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for x.x.x.x:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),


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:

C:\Users\husky>ping -n 2 google.com

Pinging google.com [10.0.0.3] with 32 bytes of data:
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.3:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

...
[On REMnux, stop INetSim wih Ctl+C]
...

C:\Users\husky>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\Users\husky>ping -n 2 google.com
Ping request could not find host google.com. Please check the name and try again


Test INetSim

Use the configuration details from the INetSim setup from PMAT and test to make sure FLAREVM can still access arbitrary DNS records.

Start INetSim on REMnux:

remnux@remnux:~$ inetsim
INetSim 1.3.2 (2020-05-19) by Matthias Eckert & Thomas Hungenberg
Using log directory:      /var/log/inetsim/
Using data directory:     /var/lib/inetsim/
Using report directory:   /var/log/inetsim/report/
Using configuration file: /etc/inetsim/inetsim.conf
Parsing configuration file.
Configuration file parsed successfully.
=== INetSim main process started (PID 1902) ===
Session ID:     1902
Listening on:   10.0.0.3
Real Date/Time: 2022-09-12 06:48:40
Fake Date/Time: 2022-09-12 06:48:40 (Delta: 0 seconds)
 Forking services...
  * dns_53_tcp_udp - started (PID 1906)
  * smtp_25_tcp - started (PID 1909)
  * pop3_110_tcp - started (PID 1911)
  * pop3s_995_tcp - started (PID 1912)
  * smtps_465_tcp - started (PID 1910)
  * ftp_21_tcp - started (PID 1913)
  * https_443_tcp - started (PID 1908)
  * http_80_tcp - started (PID 1907)
  * ftps_990_tcp - started (PID 1914)
 done.
Simulation running.

Use nslookup from FLAREVM for an arbitrary DNS record:

C:\Users\husky>nslookup asdasdasd.com
Server:  www.inetsim.org
Address:  10.0.0.3

Name:    asdasdasd.com
Address:  10.0.0.3

Use a browser to browse to an arbitrary site name:

image

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.

Remember, both of these lab network setups are sufficiently safe for this course. Please consider each type of network and what your needs are as a malware analyst for analysis beyond the PMAT course.

Complete and Continue