I freaked out yesterday afternoon when Symantec Client Firewall started blasting me with messages indicating it was blocking outbound traffic coming from vmnat.exe and matching the destination ports associated with various Trojan horses.I run a number of VMware virtual machines and vmnat.exe is the program that manages a virtual network with NAT translation on the host environment. The situation is nice because I can have isolated environments for various activities, take snapshots of system state and roll back if necessary, clone a system, etc.At the time I was doing some stuff on the web in the virtual machine that I’ve got set up for accessing the Web, checking e-mail and instant messaging.I usually run a pretty tight ship. The operating system has all the latest patches, all applications are up to date and the anti-virus software enabled for real-time scanning. I use Firefox with Adblock Plus and NoScript extensions to prevent unnecessary cross site cookie and scripting attacks.I wasn’t sure what was causing the flood of traffic that tripped up Symantec Client Firewall. I checked the logs and sure enough saw messages saying it had blocked traffic for the “Rat”, “Bla”, “Master Paradise” and “DeepThroat” Trojan horses. What was even more troubling was that there were some from a few days prior.Could it be JavaScript code from a web site that I white-listed in NoScript? Did a virus/worm come through one of the IM applications I run? Was there a vulnerability in the VMware vmnat.exe that had been exploited by malware/virus/rootkit? Due to the amount of traffic, I thought it unlikely that it was a false positive… legitimate traffic just being flagged by Symantec.Not knowing for sure what was going on, I powered down the virtual machines, unplugged the network cable and disabled WiFi on the host system. I then got on a different computer and started looking into the Trojan horses. Based on the info on Symantec’s web site, I found that the ones that were reported were mostly Trojan horses from a few years ago and were only reported on Windows 2000. I’m running Windows XP for both the host and guess operating systems, so it was unlikely that I actually had those Trojan horses. But I thought it might still be possible for some JavaScript code or a rootkit on one of the virtual machines to implement the same protocol.I checked a number of security sites like Secunia to see if there were any recent vulnerabilities announced for VMware, Firefox, etc. but didn’t see anything that fit what I was experiencing.So to determine which virtual machine might be the culprit, I re-connected the network cable and downloaded Microsoft’s Network Monitor software. I started a capture and then booted up the virtual machines one by one. When I started the one I used for web browsing/email/IM, sure enough I saw traffic over SSL to a whole slew of IP addresses that I did not know. I did DNS lookups on a number of them and they resolved to things like ISP providers (e.g. comcast.net) and foreign countries (e.g. .il). I thought “Oh, great. A bot network sophisticated enough to communicate over an encrypted connection.”I disabled the virtual network connection for that virtual machine to isolate it from the rest of the world, then ran a full drive anti-virus scan on it to see if it came up with anything. Nada. Malware is getting sophisticated enough these days that it can work its way into the system so deep that it can actually avoid detection by many anti-malware tools. So my next step was to boot the machine from CD (actually a virtual CD) and do a scan before the operating system actually loads.I created a “slipstream” boot CD image using software called Ultimate Boot CD 4 Windows (UBCD4Win). This software builds a bootable Windows CD by extracting files from a Windows install disk and then also installs a bunch of tools for things like disk repair, anti-malware, etc. It actually creates a CD image, called an ISO, which you can then burn to an actual CD. However, one nice thing about the VMware software is that you can set up a virtual machine to boot from an ISO directly rather than using the host system’s physical CD/DVD drive.I booted the virtual machine with the ISO and proceeded to scan the drive image with about a dozen different anti-malware, anti-virus and anti-rootkit packages. All of them failed to find anything wrong (well, at least nothing attributable to the alleged Trojan horses).I was starting to get a little skeptical of the whole situation. Either the infection was cutting edge enough that it hadn’t made it into the latest signature files for all of these tools (which I did remember to update before creating the ISO), or the traffic actually WAS a false positive.I fired up the Network Monitor software again and then rebooted the virtual machine using the installed operating system. After shutting down the programs that I have launch at boot time (IM clients mostly), I re-enabled the virtual network adapter and started watching the Network Monitor capture. Nothing. I launched Firefox. Nope. Thunderbird. Nada. Pidgin. No. Skype. Bingo.There was a flurry of activity to random IP addresses at semi-random ports. There’s a new Skype worm for Windows that was recently announced, so I thought I might have somehow gotten that, but it actually requires clicking on a URL within a chat. So that didn’t seem right.Then I realized the ports weren’t exactly “random”. The activity to the random IP addresses came in batches, with the port number the same within the batch. It was starting to become clear what caused the sudden barrage of Trojan horse warnings. Skype had picked random ports to use in communicating with those other computers. It just so happened that when I received those notifications from the Symantec Client Firewall, it had picked ports that coincided with those used by the previously mentioned Trojan horses.I wanted to make sure my assumption was right, though… maybe see if others had experienced and documented similar behavior… and figure out why Skype was communicating with a bunch of random computers. I had assumed that it worked like most other instant messaging applications: connect to a central server at login, “register” your presence to let others know you’re online, then facilitate setting up a direct one-to-one link for actual text/audio/video chats.I got on the web and did a little research to see what I could learn about Skype’s network protocol. I didn’t find much, but I did a document for network administrators [PDF] on Skype’s website outlining steps to tune a network for optimal Skype usage. The overview explains that the network architecture is NOT like that of the other instant messaging services:
Skype communications rely largely on peer-to-peer communications techniques in order to improve the quality of voice calls and to reduce the latency of data transfers between users. The term “peer-to-peer”, frequently written as “P2P”, is a class of software applications that rely on resources located at the network edge, such as the large number of individual personal computers that are always connected to the Internet, rather than relying on large and costly centralized computer servers. Itís this aspect of Skype networking that makes it incredibly robust and tolerant of network failures: Skype has no single “critical node” upon which the service relies for its operation.
So after several hours of stress and research, I could finally rest easy knowing that the computer had in fact not been infected by some form of malware.Well… maybe not the rest easy part. Our youngest daughter woke up crying several times after I laid down at 2:30 AM. After patting her back for a bit, walking her around and giving her some gas drops, the clock read 4:15 AM before I was able to call it a night.
Invisible Elevators 
