Laying a Malware Trap

A client of mine had a network that was constantly under malicious attack. When the client was connected to the Internet, the corporate network routers and switches lit up like a Christmas tree. When the Internet connection was unplugged, network utilization hovered around its normal 2 to 3 percent. Hackers were sending millions of packets across the network, but the client didn't know how. The client had plugged a network sniffer into the network to capture malicious packets, but in a few minutes, it was overwhelmed by hundreds of thousands of packets—mostly of unauthorized traffic. How could we find out how the hackers were breaking into the network and what they were doing? Enter the virus trap.

Sometimes preventing viruses, worms, and Trojan horses from attacking your computers isn't enough—you want to capture the malicious program and learn everything you can from it. Studying the mechanics of what the bug is attempting to do will help you provide a better defense. Even for network administrators without advanced diagnostic skills, a virus trap can provide early detection of network intrusions. Here are some methods you can use to trap malware and examples of how they've been used in the past.

What Is a Virus Trap?
In lay terms, a virus trap is a program—often a honeypot program—designed to detect, slow down, or capture a specific piece or type of malware for further study. A honey-pot is a nonproduction computer asset created to track unauthorized exploitation. A virus trap honeypot is a special-function honeypot built specifically to detect and capture automated malware. It isn't as concerned as a regular honeypot is with attacks originating from dedicated attackers, which are a small percentage of overall attacks anyway. In order to track manual hackers, a more functional and complicated honeypot is needed.

When malware is attacking, we're concerned about two things:

The first question seeks to find out how the pest is planning to attack network computers; the answer will reveal the steps the administrator needs to take to make sure the malware won't be successful (or at least to minimize the damage). The second question speaks to the malware's true motive. Is the malware just breaking in to break in, or does it want to damage data, steal files, send spam, or locate free hard drive space for storing malicious files and unlicensed digital media? A virus trap can help answer these questions.

Here are some situations in which you might want to set a virus trap:

Virus Trap Types and Uses
There are four major types of virus traps: port listeners, tarpits, honeypots, and virtual machines.

Port listeners. A port listener is any program capable of opening an IP port and capturing information entering that port. Port listeners are the simplest of programs. They don't have to emulate a service, pretend to be a server, or respond in any way. They only capture what's sent to them. The downside of port listeners is that you can't use them to monitor stateful TCP traffic, which always requires a reply to establish a successful communication session. However, sometimes listening is all you want to do.

For example, the SQL Slammer worm used a single 376-byte UDP packet to carry out its malicious deeds. To capture it, all you needed was a simple port listener listening on UDP port 1434. The most common port listener in use today is Netcat, a free utility that you can download from http://www vulnwatch.org/netcat. You can use Netcat for all sorts of things, including establishing one or more listening ports. To capture the Slammer worm, you could execute the following Netcat command:

nc -vv -l -p 1434 > port1434.log 

The -vv switch tells Netcat to be verbose and report connection attempts to the screen, -l tells Netcat to listen for inbound connections on the port indicated by the -p switch, and collected data is saved to a text file called port1434.log. (If you try this command, press Ctrl+C to end the Netcat session, or type

nc -h 

for the Netcat Help screen.)

Figure 1 shows an example of the SQL Slammer worm captured in a Netcat port listener. It isn't pretty or even understandable unless you're a programmer, because it's captured executable code that's part of a buffer overflow. Still, the text that follows the command

type port1434.txt 

is the SQL Slammer worm. If you didn't recognize the worm and you searched on the Internet for the few text strings you see, the results would indicate that the executable code you captured belongs to SQL Slammer. You could then test and verify that all your SQL Server systems are patched against the worm. To see the full source code details of SQL Slammer, visit http://www.eeye.com/html/research/flash/sapphire.txt. If the attacks continue from the same source IP address, you can even attempt to contact the host or implement other computer defenses.

Tarpits. Tarpits aren't used to capture and display malicious code as much as to slow down quickly spreading malware. Developed by Michael Robinton, LaBrea (http://labrea.source forge.net) was the first and is still the most popular tarpit. It responds to any request for a nonexistent IP address. After allowing time for any legitimate host to answer, LaBrea answers connection attempts in such a way as to waste as much of the malware's time as possible—by maximizing TCP/IP retransmits and wait periods. LaBrea slows down malware and hackers and identifies their origination IP address, as Figure 2 shows. Although LaBrea's functionality is intentionally limited, it's a huge success at what it does. Many real-life worms and lab tests have corroborated its ability to slow down Internet worms, just as its author hoped.

Honeypots. Honeypots are a great way to catch Internet worms that have more complex interactions. Most honeypots have port listeners and contain more complex interaction mechanisms if you need them. For example, most honeypots can easily handle malware requiring TCP handshakes and respond with prescripted commands. Many are simple to set up and have many logging and notification mechanisms already built in that make them perfect as virus traps.

Several people, including Laurent Oudot of the Rstack team (http://www.rstack.org) used Honeyd (http://www.honeyd.org), a popular open-source honeypot, to catch the MSBlaster worm when it was causing damage around the world. The worm was looking for TCP port 135, so Honeyd users created a port listener on that port by adding the following line to the Honeyd.config file:

add 

tcp port 135 open

The worm, finding this port open, would then attempt a DCOM remote procedure call (RPC) buffer overflow. On a real host, if the buffer overflow was successful, the worm then established a connection on TCP port 4444 and downloaded its main body by using Trivial FTP (TFTP) on TCP port 69.

In order to capture the worm, Honeyd users created a capturing service script called msblaster.sh and added it on port 4444 by using a Honeyd configuration command like the following:

add 

tcp port 4444
"sh msblaster.sh $ipsrc $ipdst"

The msblaster.sh script connected to the attacker and got the MSBlaster executable, as follows:

tftp $1 get msblast.exe 
quit 
EOF

The script used tftp.exe (located in the system32 folder on most Windows machines) to download msblaster.exe so that it could be examined. See "Honeyd vs Msblast.exe" (http://www.citi.umich.edu/u/provos/honeyd/msblast.html) or the excellent "Fighting Internet Worms With Honeypots" (http://www.securityfocus.com/infocus/1740) for more details. Similar scripts and actions can be used to capture most scanning Internet worms.

Sometimes you want to do more than simply capture a worm. The MSBlaster-capturing script articles named above contain a counterattack script that was used by some administrators to try to stop the onslaught of the MSBlaster worm. For more information about this offensive approach, see the sidebar "Taking It to the Worm," . For more details about running and configuring Honeyd, see "Honeypots for Windows," April 2004, InstantDoc ID 41976, and the Windows IT Security article "Honeyd for Windows," August 2003, InstantDoc ID 39428.

Virtual machines. If you want to capture the full interaction of malware with a near-real machine, you can't beat virtual machine software such as VMware Workstation (http://www.vmware.com) or Microsoft Virtual PC 2004 (http://www.microsoft.com/ windows/virtualpc/default.mspx). Virtual machine software can mimic the way in which a real PC would respond to virus and worm probes.

You can use a network sniffer such as the open-source Ethereal (http://www.ethereal .com) on a virtual machine to monitor traffic to and from the virtual session and use the free Regmon and Filemon utilities (http://www.sysinternals.com) to discover what network traffic and registry and file system modifications are taking place. See "Honeypots for Windows" and "Honeyd for Windows" for more information about using virtual machine software as a honeypot or virus trap. The key considerations are directing malicious traffic to only the intended session and making sure the malware doesn't use the virtual session as a starting point to attack other innocent computers. After your simple port listener, tarpit, honeypot, or virtual machine session captures a piece of malware, you can examine the bug in detail or submit it to an antivirus vendor for analysis. By implementing a virus trap, you get early warning and verification of threats to your network.