Network Map

Goals:

• Isolate the lab from any existing machines on the network.
• Transfer files.
• Allow a machine to be 'updated'. (Download new files, update tools, security updates).
• The attacking machine may not be on the same physical machine hosting the lab.

In the follow examples, this is the network scope:

• WAN network (the internet)
• LAN network (192.168.0.0/24)
• Virtual network (172.16.128.0/24)

Depending what software you use to virtualize and network layout, you can change the network mode to limit access. For example:

• Parallel Desktop - 'Host-Only' (Allows access to the host)
• Virtualbox - 'Host-only' (Allows access to the host), 'Internal Network' (No Access to host)
• VMware Fusion - 'Host only' (Allows access to the host)
• VMware Player - 'Host only' (Allows access to the host), 'LAN segment' (No Access to host)
• VMware Workstation - 'Host only' (Allows access to the host), 'LAN segment' (No Access to host)

If the network mode doesn't allow access to the host, any additional features which the virtualize software could offer, will not work (such as a DHCP service). This is normal behaviour as it simulates what would happen using physical machines.



There are various methods for doing this, just like trying to do it via physical machines. For example:

• Network shares (Samba/SMB) (If they have network access)
• Secure copy (SCP) / Secure File Transfer Protocol (SFTP) services (If they have network access)
• File hosting/Cloud storage (If they have internet access)
• Optical Media/Removable Drives (e.g. CDs/DVDs or USB memory sticks)

However, depending on your virtualizing software, you may be able to 'drag & drop' between the host & guest OS (e.g. Parallel Desktop, Virtualbox & VMware products). This allows you to select a file/folder on either machine, and then move it in/out of the virtual machine window into the other machine.



For whatever reason you wish a machine to connect to the internet (e.g. to update the attacker's operating system), you need to be careful. For example, if the machine is (accidentally or intentionally) infected with malware, it could try and 'connect back home', and/or target other machines outside the lab.
Here are a couple of methods you can try:

• If you have another source to the internet (e.g. Mobile broadband) you could chose to connect this to the machine, and connect that way. However, the down side is these often are much 'slower' and have 'low bandwidth limits'.
• Download whatever files you need on another machine, and place the files on a read-only media (write lock SD/USB, CD/DVDs) and copy over the data manually.

If the above isn't an option for you, you can take the machine out of the lab network, and, place it in an existing network (if there is one!). . With that out of the way, you can help protect yourself with the following tips:

• Turn off/Un plug/Disconnect any other devices that are connected the network and are not essential. The ones left on, make sure they do not contain any sensitive information, fully up-to-date, not running any unnecessary services and are using strong credentials.
• If the virtualizing software supports snapshots, before attaching the machine to lab network, you can take a snapshot of a 'good clean' known state of the machine (if the machine is trusted not to have any malware on it to begin with!). Disconnect from the lab network, restore to known state when you're ready to update it, connect to the network with internet access, update the machine, disconnect from the network, replace the snapshot with the updates applied, and connect back to lab network.
• You can then switch the network mode of the virtual machine, to connect the network with internet access. As it's a new network, the IP range could be different from the lab network, so the IP address/Gateway/DNS may need to be updated to reflect the new network. This may have to be done manually if there isn't a DHCP service running.

Switching the network mode each time, forces you to double check the network mode, otherwise, the machine (should!) fail to connect to the 'correct' network. However, if you're wanting to do this often, you may want to add another virtual network adapter (as most virtualizing software supports at least four or more adapters).
The primary/master adapter should be connected into the lab network, and the secondary/salve one can be connected into the other network. When switching networks, you can disable the adapter you don't want to be connected to, and enable the one which you do. Depending on the Virtualizing software, this is much easier (e.g. right click on the network icon) to do than alter settings. Remember to use the right network interface!
You could leave both network adapters connected, allowing for access into both networks at the same time (the default gateway could be pointing to the test lab, stopping internet access). However, if the machine were to be compromised in any manner, the isolated network could possibly have access to the existing network, putting all the other connected devices at risk.
This is an example of security vs. user ability. It's much 'simpler/easier' to be always connected to the internet, rather than having to mess about changing settings & reconnecting to a network, however, you are putting the other devices on the network at risk.



There are a couple of options, if you're wanting to be able to interact with the lab, from a different physical machine.

• Control the host
• Control the virtualizing software
• Join the network

By using 'Virtual Network Computing (VNC)' or 'Remote Desktop Protocol (RDP)', you're able to interact with the host OS, via a graphical user interface (GUI) to mimic having the monitor plugged in on the remote computer.
Therefore, you can use the virtual desktop to interface with the virtualizing software just as you normally would.
Depending on the network connection, there will be a certain amount of 'lag' (delay in reaction), so using this solution for a long period of time, may not give the best experience.



Both VMware and Virtualbox support sharing a virtual machine remotely. Similar to 'Control the host', however instead of having complete control over the entire host machine, you only have control over selected virtual machines.
This option is much more secure than sharing the entire host machine, as the remote connection only has access to the guest machine(s).



The two methods above, function by remotely controlling machine(s), in order to interface with the lab. However, there is another method; join the network.
The problem with this is, allowing remote nodes to join the network means there is remote access, meaning there runs the risk of traffic being able to leave the isolated network.
The most secure way of doing this, is using a physical connection, see 'Attaching virtual machines to physical hardware' below.
Alternatively, create a VPN network (for example, using OpenVPN or Hamachi), then add an additional network adapter to a virtual machine inside the network which has been set to 'Bridged' mode. This allows for the attacker to remotely target a single machine in the lab. However, if they wish to join the rest of the network they can bridge the adapter inside the VM to the VPN to the lab interface. As long as the VPN is connected and the virtual machine is up, the attacker can remotely join the complete network.


A un-used physical interface on the host machine, can be attached to a Virtualizing product and put in 'bridged mode'. Whatever is then connected via this interface, will be connected directly into that specific machine.
If the virtual machine which is attached to is bridged to the internal lab interface, the rest lab.
A network router, switch or hub can be used then to share the amount of physical ports which has access the lab.