As the Internet has grown, the benefits associated with the Internet have also increased greatly. People can stream continuous audio and video (e.g., listen to Internet radio stations, watch news videos, etc.), play on-line games, download movies and music, share pictures with friends and family, and collaborate with co-workers all over the world.
The Internet has grown tremendously since its inception, and the traffic communicated over the Internet is enormous. Part of this traffic is spam, or unsolicited junk email. Spam is often used to advertise a particular product or service. With the number of emails communicated over the Internet increasing at an enormous rate, spam too has increased rapidly.
Another form of unwanted email is messages that contain viruses or worms. Typically, these emails are associated with an attachment or an executable file. When the attachment is opened or when the executable is downloaded, the machine often becomes infected with a virus or worm.
Customers (also referred to below as users), in turn, may complain to their Internet Service Provider (ISP) about the amount of spam that they receive. Because spam is such an annoyance to customers, and also because spam makes it more difficult to recognize emails that the customer wants to receive, ISPs typically want to limit the amount of spam that their customers receive.
One technique available to limit spam is spam filtering software. Filters can focus on particular keywords in the subject line of an email to attempt to identify and delete spam. These filters, however, can be sidestepped by spelling those particular keywords differently (e.g., with dashes separating the letters). Additionally, filters may block email having the particular keyword in its subject while the email is an email that a customer wants to receive. More advanced filters, known as heuristic filters, attempt to statistically identify spam based on word patterns or word frequency. A spammer, or a person who sends spam, can still circumvent these advanced filters, such as by using short messages.
A spammer may have an array of servers transmitting spam, with each server having its own Internet Protocol (IP) address. Once spam is detected as being transmitted from a particular IP address, that IP address is put onto a blacklist. ISPs that host email accounts often look at the sending IP address of every email and filter out those emails that have an IP address that matches an IP address on the blacklist.
One technique that spammers use to avoid having their IP address put on the blacklist is by using “zombie” computers for spam. A zombie computer is a computer that is under the control of another computer (e.g., the controller). Specifically, a spammer typically uses a controller computer to write a program called a daemon. A daemon is a program that is implanted on a zombie computer and puts the zombie computer under the control of the spammer without the knowledge of the user of the zombie computer. The daemon executes in the background unknowing to the user of the zombie computer, thereby “stealing” the zombie computer's resources. The controller transmits this daemon to one or more zombie computers via an attachment or over a network. When the daemon arrives at the zombie computer, the daemon executes in the background without the user of the zombie computer noticing any change.
To convert a computer to a zombie computer, the spammer performs several steps. One step is to infect the zombie computer. A method spammers use to infect the zombie computer is to send an email message to the user that contains the daemon, with some enticement to get the user to open the attached daemon. The message may also attempt to exploit flaws in common email programs that would allow the daemon to be installed directly. Another method is to use a “port scanner” of the user's machine to look for flaws.
Specifically, computers connected to the Internet have thousands of ports that work like doors for network services. For example, mail typically travels through ports 25, 110, 143, and 587, and website data typically travels through port 80. Only a few of these “doors” are open at a time, depending on what kind of data a computer accepts or sends. The spammer, trying to convert a computer to a zombie, executes a port scanner that sends messages to all possible ports of the computer to see which ones are open and accept information, and what kind of computer it is.
Many programs that accept data have flaws. The spammer uses a toolkit of different programs to identify these flaws on available ports. If a flaw is available, the spammer can inject the daemon into the computer. When the spammer logs off of a computer, the daemon uses its own toolkit to find a flaw in yet another computer. If the daemon finds a flaw, the daemon can then install another daemon on another computer. The daemons can then use the zombie computers to transmit spam email, or unsolicited junk email, to one or more recipients. The daemon can, for example, send spam to email addresses stored on the zombie computer, or receive a list of addresses from the spammer indicating where to send the spam.
The daemons therefore enable spammers to route spam emails through the zombie computers. Since the IP addresses of these machines are new, the IP addresses do not appear in the IP address blacklists and millions of spam emails can be routed through the zombie computers before they get blacklisted.
Another mechanism ISPs use to determine a spam attack is based on the rate of message transmission from a single host. If an unknown host is sending vast quantities of messages to the ISP, that host is treated as a potential spammer, and subsequently limited in the message rates permitted from that host. By using zombies, instead of sending thousands of messages from a small number of hosts to the ISP, a small number of messages would be sent from thousands of zombies. Each zombie will fall under the radar for the rate limiting of the ISP, and would not be detected. This is often referred to as a trickle attack.
Detecting spam sent from zombie computers is therefore often a difficult task. To reduce the amount of spam received by ISP's customers, there remains a need for ISPs to detect spam generated by zombie computers.
The present invention is a method and system for detecting a zombie attack in a network having a plurality of computers. In one aspect of the invention, a network analysis module determines, for each computer in the plurality of computers, a set of email addresses associated with emails sent by each computer. This set is referred to below as that user's “working set”. Each working set may be associated with a subset of or the full set of emails sent by each computer. A zombie attack is then detected by determining one or more of the following: 1) at least one computer in the plurality of computers is transmitting more than a threshold rate of emails, 2) one or more computers in the plurality of computers is transmitting more than a first threshold number of emails to email addresses outside of its associated working set, 3) more than a first threshold number of computers in the plurality of computers are transmitting email messages to email addresses outside of their associated working set, and 4) more than a second threshold number of computers are transmitting more than a second threshold number of emails to a recipient computer.
Various embodiments are discussed below. The first threshold number of emails may be equal to the second threshold number of emails. The first threshold number of computers may be equal to the second threshold number of computers.
Network analysis may be performed on each computer to determine a list of email addresses associated with each computer. The working set of email addresses can be determined from the list by determining to which email addresses in the list each computer sends email messages. The working set of email addresses can be updated at any time.
These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings.
Spam, or unsolicited junk email, is a problem experienced by many customers of an Internet Service Provider (ISP). Often, spam is sent from so-called “zombie” computers, which are personal computers that are under the control of another controlling computer. It is often extremely difficult for an ISP to detect when spam is being generated by a zombie computer.
As described above, a spammer typically uses a controller computer to execute a program called a daemon. The daemon executes in the background unknown to the user of the zombie computer and “steals” the computer's resources. A controller transmits this daemon to one or more zombie computers via an email attachment or over a network.
Each master computer 110, 112 communicates with and controls one or more zombie computers. The master and zombie computers are typical computers executing typical software applications. For example, the first master computer 110 communicates with a first zombie computer 114, a second zombie computer 116, and a third zombie computer 118. The second master computer 112 communicates with the second zombie computer 116, the third zombie computer 118, and a fourth zombie computer 120. The controller 104 then communicates with the master computers 110, 112 (either directly or through a chain of other hosts that the spammer has compromised) and orders the daemons to send spam to particular email addresses.
Although
The network analysis module 204 creates a working set for each computer in a particular network hosted by an ISP in step 300. The network analysis module 204 may associate a working set with a computer by downloading the working set onto the computer. Alternatively, the network analysis module 204 relates a working set to a computer, such as by creating a record in the working set identifying the computer that the working set is associated with.
In accordance with one aspect of the present invention, the network analysis module 204 uses the working set to detect zombie computers. There are typically three checks performed by the network analysis module 204 to determine whether spam is being sent using zombie computers (i.e., a zombie attack).
The first check occurs when the network analysis module 204 determines whether one or more computers start transmitting many email messages outside of their associated working set (i.e., a zombie spew attack). In one embodiment, the network analysis module 204 determines whether more than a first threshold number of email messages are being transmitted from a zombie computer 208, 212, 216, 220 to addresses outside of the working set associated with the first zombie computer 208 in step 304. If so, then the network analysis module 204 determines that a zombie attack is occurring in step 308.
If not, the network analysis module 204 performs its second check on the zombie computers 208-220. The second check is determining whether there are more than a first threshold number of computers transmitting email messages to addresses outside of the computers' associated working set (i.e., a zombie trickle attack) in step 312. Several users emailing messages to addresses outside of their working set periodically is usually a normal occurrence. If, however, the network analysis module 204 determines that a large number of computers that do not normally send emails to addresses outside of their working set suddenly send such emails, the network analysis module 204 determines that a zombie attack (i.e., a zombie trickle attack) is occurring in step 308.
If the network analysis module 204 determines that the second check is not occurring, the network analysis module 204 then continues with a third check. The third check is determining whether more than a second threshold number of computers are transmitting more than a second threshold number of email messages to the same recipient computer (i.e., a Distributed Denial of Service (DDoS) attack) in step 316. Specifically, the daemons of the zombie computers work together and launch a distributed denial of service (DDoS) attack, flooding a targeted computer with packets in an attempt to cripple the computer's operation. If the network analysis module 204 detects that more than a second threshold number of computers are transmitting more than a second threshold number of email messages to the same recipient computer, the network analysis module 204 determines that a zombie attack is occurring in step 308. If not, then the network analysis module 204 has not detected a zombie attack in step 320.
The first threshold number of computers may or may not be related to the second threshold number of computers. In one embodiment, the first threshold is the same as the second threshold. Alternatively, they are different and/or unrelated. Similarly, the first threshold number of email messages may be related to (e.g., the same as) or unrelated to (e.g., different than) the second threshold number of email addresses.
The network analysis module 204 can be located in any position in the network so long as the network analysis module 204 can analyze the communications being transmitted from and being sent to one or more computers in the network 200. Different levels of support are possible, depending on whether the network analysis module 204 is examining the messages sent or the messages sent and received. In one embodiment, there are the following levels of support possible by the network analysis module 204: 1) examining the rates of messages sent, 2) examining the messages sent outside of the users' working sets, and 3) using the messages sent to the users to further define those working sets. Further, any number of network analysis modules can be used in the network 200 to detect a zombie attack.
The previous description describes the present invention in terms of the processing steps required to implement an embodiment of the invention. These steps may be performed by an appropriately programmed computer, the configuration of which is well known in the art. An appropriate computer may be implemented, for example, using well known computer processors, memory units, storage devices, computer software, and other nodes. A high level block diagram of such a computer is shown in
One skilled in the art will recognize that an implementation of an actual computer will contain other nodes as well, and that
The foregoing Detailed Description is to be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention disclosed herein is not to be determined from the Detailed Description, but rather from the claims as interpreted according to the full breadth permitted by the patent laws. It is to be understood that the embodiments shown and described herein are only illustrative of the principles of the present invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention. Those skilled in the art could implement various other feature combinations without departing from the scope and spirit of the invention.
Number | Name | Date | Kind |
---|---|---|---|
5805442 | Crater et al. | Sep 1998 | A |
6453359 | Bender et al. | Sep 2002 | B1 |
7032023 | Barrett et al. | Apr 2006 | B1 |
7631044 | Yu | Dec 2009 | B2 |
7756933 | Reshef et al. | Jul 2010 | B2 |
7930413 | Peddemors et al. | Apr 2011 | B2 |
8464346 | Barai et al. | Jun 2013 | B2 |
8589304 | Patel et al. | Nov 2013 | B2 |
20020099780 | Scheussler et al. | Jul 2002 | A1 |
20020129264 | Rowland et al. | Sep 2002 | A1 |
20020138279 | Al-Kazily et al. | Sep 2002 | A1 |
20030026220 | Uhlik et al. | Feb 2003 | A1 |
20040014486 | Carlton et al. | Jan 2004 | A1 |
20040034794 | Mayer et al. | Feb 2004 | A1 |
20040143635 | Galea | Jul 2004 | A1 |
20040199592 | Gould et al. | Oct 2004 | A1 |
20050120090 | Kamiya | Jun 2005 | A1 |
20050132060 | Mo et al. | Jun 2005 | A1 |
20050182735 | Zager et al. | Aug 2005 | A1 |
20050229254 | Singh et al. | Oct 2005 | A1 |
20050246344 | Keller et al. | Nov 2005 | A1 |
20060031359 | Clegg et al. | Feb 2006 | A1 |
20060074896 | Thomas et al. | Apr 2006 | A1 |
20060075048 | Gruper et al. | Apr 2006 | A1 |
20060080444 | Peddemors et al. | Apr 2006 | A1 |
20060107318 | Jeffries et al. | May 2006 | A1 |
20060161989 | Reshef et al. | Jul 2006 | A1 |
20060168202 | Reshef et al. | Jul 2006 | A1 |
20060195531 | Braun et al. | Aug 2006 | A1 |
20060259551 | Caldwell, Jr. | Nov 2006 | A1 |
20060259561 | Takahashi et al. | Nov 2006 | A1 |
20070005782 | Zheng | Jan 2007 | A1 |
20070033650 | Grosse et al. | Feb 2007 | A1 |
20070061211 | Ramer et al. | Mar 2007 | A1 |
20070204341 | Rand et al. | Aug 2007 | A1 |
20070282770 | Choi | Dec 2007 | A1 |
20070282955 | Lin et al. | Dec 2007 | A1 |
20080005316 | Feaver et al. | Jan 2008 | A1 |
20080172468 | Almeida | Jul 2008 | A1 |
20090077664 | Hsu et al. | Mar 2009 | A1 |
20120239660 | Patel et al. | Sep 2012 | A1 |
Entry |
---|
PCT International Search Report corresponding to PCT Patent Application PCT/US2007/014293 filed Jun. 18, 2007 (3 pages). |
PCT Written Opinion of the International Searching Authority corresponding to PCT Patent Application PCT/US2007/014293 filed Jun. 18, 2007 (7 pages). |
Number | Date | Country | |
---|---|---|---|
20080005316 A1 | Jan 2008 | US |