To operate the VM inconspicuously, obviously you don’t run the full-fledged VirtualBox GUI. VirtualBox can also be fully managed from its command-line interface, called VBoxManage (you can read the User Manual if you want to learn more about VBoxManage).
In what follows, I will discuss how you can set VirtualBox to run in headless mode, and also how to set the virtual machine running pfSense to automatically enter the ‘saved state’ mode when you shut your Windows host down, and how to make it automatically start again when you boot your host.
Firstly, I need to say that I have spent quite a few hours trying to figure out on my own how to run VirtualBox as a service, so it can detect power events on the host, such as shutdown, logoff or startup. Especially the shutdown / logoff part. No, don’t even think about Group Policies, since in Windows 7, during shutdown, all programs are closed first and only afterwards it runs whatever scripts we set. Which means that we cannot tell VBoxManage or VBoxHeadless to nicely shut down our VM or to save its state.
The best bet is VBoxVmService, developed by an enthusiastic VirtualBox fan and available for free on Sourceforge. Download the latest build here and after unzipping it, read the Howto in the docs folder. It is very explanatory and simple.
By the way, don’t fret if the service does not start your VM right away so don’t try yet to debug it; just reboot after installing the service.
Still, the service is set for delayed start, so your VM will not start right away after your Windows boots. I didn’t quite like the idea, so in the VBoxVmService.ini file (you’ve read the Howto for VBoxVmService, right?) I have set my VM’s AutoStart option to no, and then created a small VBScript file to execute automatically at startup. It is a much faster option.
Note: C:\Program Files\Oracle\VirtualBox\ is the full path for a default VirtualBox installation. If you changed its location, you need to modify the path in the script accordingly.
- Type the following code in a text file and then save it as headless_start.vbs:
Set WshShell = WScript.CreateObject("WScript.Shell")
cmd = chr(34) & "C:\Program Files\Oracle\VirtualBox\VBoxHeadless.exe" & chr(34) & " --startvm" & " pfSense"
obj = WshShell.Run(cmd, 0)
set WshShell = Nothing
Copy the file in C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup
- If you have Windows 7 Professional and up, or Vista Business and up. Run the Local Group Policy Editor as administrator (the easy way: click the Start orb and type in the search box gpedit.msc).
- Go to Computer Configuration > Windows Settings and left click Scripts (Startup/shutdown).
- In the right side of the window, right-click Startup and select Properties. In the properties window click the Add button and then browse to the VBScript file which we have created earlier for startup and select it:
- Click OK, and then OK again.
- If you have a Home Edition of Windows 7 (or Vista). Copy the VBS file in C:\Users\[yourusernamehere]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. This will work only for the specified user.
- Still having problems? Check on SevenForums.com for a wealth of advice on how to run programs at startup in Windows 7 / Vista.
Now, if you need to access your VM console, you now have to identify the IP address of your VirtualBox Host-Only Network (type in ipconfig in a Command window) and then connect to it using Remote Desktop Connection available in Windows 7 (we used the port set in Part 3). See the next two screenshots:
Done!
Just in case: if you need some more quick VBScript files to control your VM when in headless mode, here they are:
- To save state: headless_savestate.vbs:
Set WshShell = WScript.CreateObject("WScript.Shell")
cmd = chr(34) & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" & chr(34) & " controlvm" & " pfSense" & " savestate"
obj = WshShell.Run(cmd, 0)
set WshShell = Nothing
- To force reset: headless_reset.vbs:
Set WshShell = WScript.CreateObject("WScript.Shell")
cmd = chr(34) & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" & chr(34) & " controlvm" & " pfSense" & " reset"
obj = WshShell.Run(cmd, 0)
set WshShell = Nothing
- To shut it down (ACPI power button): headless_acpiturnoff.vbs:
Set WshShell = WScript.CreateObject("WScript.Shell")
cmd = chr(34) & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" & chr(34) & " controlvm" & " pfSense" & " acpipowerbutton"
obj = WshShell.Run(cmd, 0)
set WshShell = Nothing
Congrats! You are done.
<<Part 5: Configuring VLANs. Removing Windows’ TCP/IP stacks
Thanks Manuel. This is a remarkable guide which is very easy to follow. I have some questions as to how some things work for other VMs on the host.
How should I set up the adapters for the guest OS so that it cannot communicate to the host? I’ve asked other questions in this topic that I’m curious about and can’t seem to figure out: http://www.sandboxie.com/phpbb/viewtopic.php?t=12103
Its important for traffic to be separated because I tend to test malware in the guest OS and would need to ensure that there is no possibility for cross contamination through netwroking. Is the only way to accomlish this through VLANs? Does there have to be hardware support for VLAN tagging for this to work? Please post instructions on how I could go about doing this or even a tutorial would be very much appreciated.
I get very confused on what exactly happens to traffic routed from the guest VM when its running. I am trying to acieve something like this:
http://i.imgur.com/9hNza.jpg
To make sure that the vm cannot communicate with the host I initiated ping tests, while temporarily disabling the firewalls on both systems as to not distort the results.
First Set of Tests:
xp vm has only (1) and also primary NIC set to use the WAN wirless interface in bridged mode.
-xp vm cannot ping Host
-Host can ping xp wm
-PF can ping host only on LAN – host ip also falls in a different range than when traffic was normal
-PF can ping xp vm on both the LAN and WAN <- which confuses me since I thought that the xpvm was supposed to be considered as only on the WAN side of PF since I didn't configure for it to use the loopback interface.
Second Set of Tests:
xp vm is set to use 2 NICs; The primary WAN which is bridged ot the wireless card and also the MS loopback for LAN as the second interface.
-xp vm CAN ping host
-host can ping xp vm
-PF can only ping host on LAN as case above
-PF still can ping xp vm on both LAN and WAN
– Can I correctly assume that the configuration described in the first test ensures that the vm cannot talk to my host by any means? What throws me off is that PF sees the guest OS appears to be responding from both sides of the firewall, while the guest's communication is only one sided as in the case of Test 1.
If you have no desire to explain this, please let me know. I've posted this question on various forums (including pfsense) and never got any feedback. Then I thought it would be best to ask you here, even though I thought that you stopped writing for a while. Since my comment appeared you appear to regularly check on your site so you've probably seen my question.
This seems very complicated and I'm about to give up.
Hi x0r,
Thank you for stopping by. I’m glad you found this tutorial helpful. To answer to one of your questions from the first post: I am not sure whether VLAN tagging would be of much help anyway; it has not been designed as a security measure and it is exposed to malware that propagates through VLAN hopping. VLANs seem to be trusted too much when it is about network security. Better think security in depth, rather than through segmentation.
I will take a closer look at your tests and what you are trying to achieve and then come back with a more comprehensive answer. The problem would be similar to a physical lab in the end, so the same defense principles apply, thus it is worth considering.
To put it right, with VMs you are at risk of ‘leaks’ anyway, as a principle. I.e. can you know for sure that some malware you are playing with doesn’t exploit a 0-day vulnerability in VirtualBox / VMware, and thus bypass the sandbox other way than through the network? Some worms can be really good at identifying whether they are running within a virtual machine, and thus look for exploits (for instance, the I/O ports used for communication with the host could be a target). Or they may render your testing redundant by deactivating themselves.
The days before Christmas are quite busy, and to a certain extent you are right – this blog is not my main concern right now – but I’ll get back to you within a couple of days.
Merry malware testing
Just an afterthought: there’s no glory in using malware written by someone else. No glory in using it at all
Good to hear back from you and Happy Holidays. I didn’t mean to come across as impatient, honest
I understand the impllications of using vms for observing malware and would consider myself prepared. And no I’m a malware tester not some skiddie user
I am considering making use of virtualbox’s internal networking for isolation instead of vlans, but to no avail (guest os doesn’t see the virtualbox internal Intel NIC) .
Since i’m not knowledgeable enough nor do i know if this is the anwser, I’ll just wait and see what you make of the test results first.
Ciao
Great tutorial, all work perfect…until the end, i could not connect with remote desktop.
i can ping the Vbox address but cant connect to it(i append the port number as in the example). Error that remote access is not enabled or machine might be off, or cant reach it on network.
Hi Zak,
Did you enable the Remote Display server as explained in Part 4? I know, you say that you’ve followed the tutorial, but just make sure that you’ve ticked that box.
Also, you may want to check your Windows Firewall settings (which may not allow RDP connections to a non-standard port or any RDP connections at all).
Hope this helps,
Manuel