How to detect rogue virtual machines on a network

In the final installment of his series, Harley Stagner offers code that will help you prevent and detect rogue virtual machines using Microsoft Virtual Server 2005.

Are you a security administrator worried about rogue Microsoft Virtual Server 2005 virtual machines showing up on your network? The last article instructed you how to examine the compromised host server. This article will go through detecting rogue virtual machines on your network. Also, find out why the potent combination of Alternate Data Streams and virtual machines could make searching for rogue virtual machines more difficult.

While virtual machines can be very useful, the thought of rogue virtual machines running on the network is enough to make any systems administrator very nervous. There are a couple of steps that you can take to discourage the unauthorized installation and use of Virtual Server 2005 on your network.

First, limit the number of users that need to be in the Administrators group on their local machines. You have to be an administrator to install the Virtual Server 2005 software. I know there are some cases where a user must absolutely have administrator access to a system, especially if they are running some questionably coded software (vendors, you know who you are). However, limiting this as much as possible will help to mitigate unauthorized software.

Second, to limit the possibility of someone bringing a computer into the network with Virtual Server 2005 pre-installed, consider using MAC Address filtering on your desktop switches. Depending on how large the environment is and how well staffed it is, this may not be feasible. However, if it can be managed, MAC Address filtering secures more than just the possibility of a rogue virtual machine. An attacker cannot do much to your network, if your switches will not even allow connectivity.

You could also put software restriction policies in place. However, these are easily circumvented if you rename the executable that installs Virtual Server 2005. Also, you cannot, practically, block access to all *.exe files. This is simply not feasible.

I always contend that proactive network monitoring will help resolve many issues before they become issues. With that said, it would be nice if you could monitor your network periodically for Virtual Server 2005 Host Machines. One of the first things that come to mind for this task is a query script. What should we query for on our network? You could look for common Virtual Server 2005 files like virtual disk files. However, this might not be the most reliable item to look for. This is because of three words: Alternate Data Stream.

Alternate data streams are a "feature" of the NTFS file system that were originally designed to maintain compatibility with Apple's Hierarchical File System (HFS). Files in a HFS file system consist of a resource fork and a data fork. On an NTFS file system, a file entry within the Master File Table (MFT) can have additional attributes or streams associated with the primary data stream. These additional streams are perfect hiding places for files, such as virtual hard disk files. That's right; you can hide a virtual machine's entire boot volume in an Alternate Data Stream. The steps involved are outlined below.

  1. Create a new Virtual Machine with a dynamically expanding virtual hard drive.
  2. Move the virtual hard drive file into an alternate data stream (either attached to a folder or a file).
  3. Tell Virtual Server where to find the virtual hard drive file after it has been moved.

An example of what a virtual hard drive path looks like when it is hidden in an alternate data stream is shown in the virtual machine configuration file section in the figure below.

The portion that reads "test.txt:vs2005-Test-VM.vhd" indicates that there is a file called "vs2005-Test-VM.vhd" attached to an alternate data stream in the file test.txt. You access alternate data streams via filename:streamname. A screenshot of the working directory of this particular virtual machine is shown in the figure below.

As you can see (or not see), there is not a virtual hard drive file (*.vhd) visible in this directory because it is attached to the "test.txt" file. To make this happen, after you create a new virtual machine issue the following command in a command prompt. type > filename.txt:streamname.vhd An example of the command that I entered to hide this virtual hard drive is seen in the figure below.

That's all there is to it. Now the original virtual hard drive file can be deleted because a copy of it is attached to the alternate data stream.

I used a text file in the same directory for illustration purposes. However, I could have just as easily used any file in another location, or even a folder. The best part is that the text file still shows as 0 KB. I can even type in the text file and resave it. Once the path is typed in properly in the Virtual Machine Configuration file (in this case it would be "C:\Virtual Machines\VS2005-ADS\VS2005-ADS-Test\test.txt:vs2005-test-vm.vhd"), the virtual machine is ready to boot. You can install an operating system onto this hidden virtual disk and it will expand inside the alternate data stream.

Windows explorer and the "dir" command lack the capability to show file sizes for alternate data streams, so for all practical purposes, the virtual hard disk file is hidden. However, you can view alternate data streams on a system with the help of a tool called "streams.exe" from Windows Sysinternals. An example of the output is shown in the figure below.

The –s switch tells streams.exe to recursively search subdirectories. As you can see, there is a large alternate data stream attached to the test.txt file (test.txt:vs2005-test-vm-ads.vhd). The streams utility will also let you delete alternate data streams if you specify the –d switch.

Now that you have seen how easy it is to hide files in an alternate data stream, you can also see that searching the network for virtual machine files is not the most reliable way to locate rogue virtual machines. You need to search on something that is not easily changed. The item that comes to mind first is the "Virtual Server" service. Unlike a file, a service is very difficult to rename or hide. The service that is common among all Virtual Server 2005 installations is the "Virtual Server" service.

To query the network for the "Virtual Server" service we will turn to Windows Sysinternals once again and use a utility called "psservice.exe" in combination with vbscript. The pssservice.exe utility has the ability to query the network for a particular service when it is run with the right switches. Since the "psservice.exe" utility is a command-line tool, we will use it in a batch file and this batch file will be called from within a vbscript.

You may be wondering why we are using vbscript if "psservice.exe" is a command-line tool. We will be using vbscript to take exactly what we need out of the output file that "psservice.exe" will produce for us. Then we will construct an email to send to the busy systems administrator so that he does not have to wait for processing to finish or manually look for the output file. You will need a couple of things in place before running this script on your network. First, you will need to run this script with a user account in your domain. Second, the computer that you run the script from will need to have permission to forward smtp traffic to your email server. This can usually be set up on your email server. Finally, vs_query.vbs, VS2005_query.bat, and psservice.exe must all be in the same directory when vs_query.vbs is run. The script is available for viewing or download here, but first is a listing of the VS2005_query.bat file so that you can see what command does most of the query work in the script.

Ultimately, what this script will do is query the network for the "Virtual Server" service and return the names of the machines running the "Virtual Server" service in the form of an email sent to someone of your choosing where [email protected], [email protected], and "yoursmtpserver" are the smtp addresses of your choosing and the smtp server of your choosing, respectively. There is also a text file ("final_results.txt") left in the location where the script was run that has the results as well.

If possible, schedule this script to run periodically when there is little other network traffic. This will allow you to stay ahead of any rogue virtual machines that may be running on your network.

About the author: Harley Stagner has been an IT professional for almost eight years. He has a wide range of knowledge in many areas of the IT field, including network design and administration, scripting and troubleshooting. Of particular interest to Harley is virtualization technology. He was the technical editor for Chris Wolf and Erick M. Halter's book Virtualization: From the Desktop to the Enterprise and currently writes his own blog at www.harleystagner.com.

Dig Deeper on Server virtualization risks and monitoring