This invention relates generally to the field of networked communications, and more particularly to methods and systems for detecting malware.
Computer networks are often plagued by malware such as worms that use the resources of network processing devices without the knowledge and permission of the owner. Worms are computer programs that self-replicate by sending network packets to unguarded elements of the network. This type of malware is often used for identity theft and financial fraud, and thus poses a threat to users of the Internet and to businesses that have an online presence. Different approaches have been proposed and implemented for identifying and preventing further spread of such malware. These include signature-based methods, traffic anomaly methods, and so-called honey-spot techniques. The signature-based techniques are largely ineffective since it is very easy for worms to change signatures to avoid detection and remedial action, and these methods are ineffective against zero-day attacks. So-called stealth worms minimize the number of packets sent (e.g., only a few packets per week) in attempting to identify targets. These worms send scan packets at a very slow rate to hosts that show network activity, and sophisticated stealth worms often employ reconnaissance scans targeting hosts and servers with specific weaknesses that the worm can exploit. This type of malware is difficult to reliably identify using traffic anomaly methods because the rate of scanning packets is very low compared to normal traffic in a network. Consequently, the signal-to-noise ratio is very low in the case of stealth worms, as the signal rate of the worm's scanning packets is small compared to the noise level of the normal network traffic. Moreover, advanced stealth worms adjust the transmission rate of scanning packets based on actual network traffic, thereby reducing the chances of detection by traffic anomaly analysis. As a result, a stealth worm that maintains a SNR of less than 0.01% is virtually impossible to detect by traffic anomaly analysis without generating many false positives. The cost of false detections is high, particularly where the network takes automatic actions upon detecting possible infections. As a result, stealth worm detection has thusfar been difficult using conventional signature or traffic anomaly analysis methods. Accordingly, there remains a need for improved detection methods and systems to identify compromised hosts on a network for remedial steps to be taken to reduce the damaging effects of worms and other malware.
The following is a summary of one or more aspects of the invention to facilitate a basic understanding thereof, wherein this summary is not an extensive overview of the invention, and is intended neither to identify certain elements of the invention, nor to delineate the scope of the invention. Rather, the primary purpose of the summary is to present some concepts of the invention in a simplified form prior to the more detailed description that is presented hereinafter. The various aspects of the present disclosure relate to systems and methods for detecting worms and other malware in which a network switch entices the malware into sending scan packets by allocating a bait address, sending outgoing bait packets, and identifying compromised hosts that send unexpected incoming packets to the bait address. This technique allows reliable identification of stealth worms that send scan packets at a low rate, and therefore provides significant improvement over conventional traffic anomaly analysis techniques for stealth worm detection while minimizing the likelihood of false positives. In addition, the described systems and methods do not rely upon signature analysis, and are thus able to detect malware that adjust their signal signatures, and to identify infected hosts even for zero-day attacks.
One or more aspects of the present disclosure relate to a system for detecting malware infected computing devices in a network. The system is comprised of a network element, such as a layer 2 or layer 3 switch (router) or other network node in certain embodiments, which has one or more network addresses allocated as a bait address. In certain implementations, the bait address is a layer 2 address, such as a media access control (MAC) address that is shared by a first switch port configured for transmitting bait packets (TX) and a second port configured for receiving incoming packets from the network (RX). In other embodiments, all ports of the network element are allocated as bait addresses. The bait address in certain embodiments may also be an IP address. The network element also comprises a malware detection component that sends one or more outgoing bait packets from the bait address to the network and receives incoming packets from the network at the bait address. The detection component selectively identifies the source of the incoming packet as infected with malware if the incoming packet is unexpected or from an unauthorized source. In one embodiment, the detection component includes a policy table with a bait packet types list and a bait packet schedule, where the outgoing bait packet or packets are sent from the bait address to the network according to the bait packet types list and the bait packet schedule. In this manner, the detection component can conduct a “sting” operation according to a script of packet types at scheduled times in order to entice a worm or other malware into targeting the bait address for scanning probe packets. The bait packet or packets, moreover, may be sent as a broadcast from the bait address to the network or as a unicast to certain network addresses. The outgoing bait packets, moreover, preferably do not indicate any specific service, whereby worms cannot adapt their behavior to avoid targeting certain service types. In one example, the detection component sends out one or more bootp broadcast packets as bait to attract malware in the network. Moreover, the malware detection component may determine whether incoming packets are unexpected at least partially based on the type of outgoing bait packet sent from the bait address to the network.
Further aspects of the present disclosure provide a method of detecting malware infected computing devices in a network. The method includes allocating at least one network address in a network element as a bait address and sending at least one outgoing bait packet from the bait address to the network. In specific embodiments, all ports of the network element may be allocated as bait addresses. The method further includes receiving an incoming packet from the network at the bait address and selectively identifying a source of the incoming packet as infected with malware if the incoming packet is unexpected or from an unauthorized source. In accordance with further aspects of the disclosure, the network element may be a layer 2 switch or a layer 3 switch coupled to the communications network, and the bait address can be a layer 2 address, such as a MAC address shared by a first transmit port and a second receive port of the network element or an IP address. The outgoing bait packets may be sent according to a policy table stored in the network element according to other aspects, and may be sent according to a bait packet types list and a bait packet schedule stored in the network element in certain implementations. In addition, the outgoing bait packets may be sent as broadcast or unicast packets from the bait address.
The following description and drawings set forth in detail certain illustrative implementations of the invention, which are indicative of several exemplary ways in which the principles of the invention may be carried out. Various objects, advantages, and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings, in which:
Several embodiments or implementations of the various aspects of the present disclosure are hereinafter illustrated and described in conjunction with the drawings, wherein like reference numerals are used to refer to like elements.
Referring initially to
The illustrated network 2 includes a first subnet 10 that is operatively connected to the Internet 4 via a first router (e.g., layer 3 switch) 12, and a second subnet 20 connected to the first subnet 10 via a second router 14. A first network switch 16 (layer 2 switch) is connected to the first subnet 10 and a network switch 26 is connected to the second subnet 20 along with several computing devices 21-24, where computer 24 is assumed to be compromised or infected with a worm malware in the following discussion, and wherein each of the switches 12, 14, 16, 26, computers, servers 21-24, etc. are considered as being a network element. The disclosure may be implemented in any form, type, and topology of network, whether wired, wireless, or combinations thereof, in which various messages, packets, signals, data, etc., are sent and received according to any suitable messaging protocols, wherein the network may be operated according to any suitable multi-layer scheme (e.g., the OSI basic reference model or derivatives or variants thereof) in which messages to, from, or between the various networked components may be segmented or partitioned into packets, and in which one or more layers may add certain control information around a payload portion from another layer to form encapsulated packets or messages. In this regard, packets as used herein is intended to encompass all forms of frames, data packets, etc. sent over the network 2 within a given layer or multiple layers.
Referring also to
As best shown in
Various aspects of the disclosure are illustrated and described in terms of software, or algorithms, and/or symbolic representations of operations on data bits within a computer memory, by which ordinary skilled artisans convey the substance of their work. As such, algorithms, scripts, computations, and other operations of the described components 30, 32, 33, 34, etc. may be implemented as computer implemented steps via programmed software core or other programming or configuration to provide a desired result, where such steps involve manipulation or transformation of physical quantities such as stored memory states in a computer memory. In particular, certain embodiments may include software components operating according to programmed computer-executable instructions stored in an electronic memory, which operate on data and packets sent to or received from the network 2, which data may be likewise stored in an electronic memory at least for a time, wherein the packets and data described herein may be of any suitable form including without limitation optical, electrical, or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated, and wherein these may be referred to in various terms such as bits, values, elements, symbols, characters, terms, numbers, etc.
In this regard, unless specifically stated otherwise, or as is apparent from the discussion, terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. In addition, the various software implemented aspects of the present disclosure are typically encoded on some form of program storage medium or implemented over some type of transmission medium. The program storage medium may be magnetic (e.g., a floppy disk or a hard drive) or optical (e.g., a compact disk read only memory, or “CD ROM”), and may be read only or random access. Similarly, the transmission medium may be twisted wire pairs, coaxial cable, optical fiber, or some other suitable transmission medium known to the art. The invention is not limited by these aspects of any given implementation.
Referring also to
The method 100 begins at 102 in
At 104 in
The bait packet or packets are preferably such that they do not indicate any specific service. In general, the bait can be either broadcast or unicast or combinations thereof. For instance, the bait could be selected so as to appear to a worm like a Windows server just coming online, which begins advertising over NetBEUI. Another example is an IGMP bait packet. The bait could be a unicast transmission, for instance, such as a query for Windows networking to a particular host. The normal response(s) will follow protocol and be ignored by the malware detection component 30 in the network element 26. However, if the host is infected, the worm may harvest the bait address from the bait packet and later send probe packets which will be detected by the component 30. Other suitable bait packet types can include without limitation basic TCP/IP protocols like ARP (Address Resolution Protocol) and DHCP (Dynamic Host Configuration Protocol), such as a bootstrap protocol (bootp) packet 202 in the example of
The malware detection component 30 then waits at 106 (
The determination at 110 of whether the received packet is unexpected or from an unauthorized source includes determining at 112 whether the packet is expected or not, for example, based on the type of bait packet(s) previously sent at 104. If the received packet is a normal response to the transmitted bait packet, the reply is processed normally at 114, and the source is not identified as infected. If the received packet is not expected, a determination is made at 116 as to whether the packet is from an authorized source, and if so, it can be processed normally at 114. Otherwise (NO at 116), the source (the sender of the received packet) is identified as infected at 118, and further remedial action can be taken, such as by quarantining the source, etc.
As an illustrative example,
The malware detection component 30 thus operates to set up a “sting” operation in the network 2 to bait malicious worms and the like to attempt self replication at the bait address, without putting otherwise occupied network resources at risk. It is noted that the employment of the malware detection component 30 and the allocation of one or more network addresses and associated switch ports does occupy some resources in the network 2, and indeed adds to the total amount of network traffic. However, this expenditure of system resources and bandwidth (together with any ancillary malware detection components) benefits the network 2 as a whole by facilitating early identification and neutralization of corrupted systems such as the compromised computer 24 in the illustrated example. Once a worm or other malware responds to the bait packets sent by the detection component 30 and is identified as infected, the incoming received packets are logged and action can be taken against the source 24 of the scanning packet(s). Also, the malware detection component 30 can be deployed close to the network edge, such as on enterprise switches 14, 16, 26, and therefore is immune to source address spoofing. Moreover, the bait packet types and timing are preferably selected such that the network traffic generated from and to the bait address does not mimic any specific service and instead merely announces the existence of bait addresses, thereby preventing adaptive worms from avoiding the bait. The detection component 30 is also lightweight and easily deployable on any layer 2 or layer 3 switch or gateway, or on any other type of network node, and may be installed along with other forms of malware prevention components, such as honey spots, signature detection, and/or traffic anomaly analysis type system components.
Although the invention has been illustrated and described with respect to one or more exemplary implementations or embodiments, equivalent alterations and modifications will occur to others skilled in the art upon reading and understanding this specification and the annexed drawings. In particular regard to the various functions performed by the above described components (assemblies, devices, systems, circuits, and the like), the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the invention. In addition, although a particular feature of the invention may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Also, to the extent that the terms “including”, “includes”, “having”, “has”, “with”, or variants thereof are used in the detailed description and/or in the claims, such terms are intended to be inclusive in a manner similar to the term “comprising”.
This application is a continuation of, and claims priority to and the benefit of, U.S. patent application Ser. No. 12/039,817, filed on Feb. 29, 2008, entitled MALWARE DETECTION SYSTEM AND METHOD, the entirety of which application is hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
7089589 | Chefalas et al. | Aug 2006 | B2 |
7467405 | Cheng | Dec 2008 | B2 |
7516487 | Szeto et al. | Apr 2009 | B1 |
7870608 | Shraim et al. | Jan 2011 | B2 |
20050195753 | Chaskar et al. | Sep 2005 | A1 |
20060291469 | Omote et al. | Dec 2006 | A1 |
20070011741 | Robert et al. | Jan 2007 | A1 |
20070067845 | Wiemer et al. | Mar 2007 | A1 |
20070067847 | Wiemer et al. | Mar 2007 | A1 |
20070067848 | Gustave et al. | Mar 2007 | A1 |
20070101430 | Raikar | May 2007 | A1 |
20070208822 | Wang et al. | Sep 2007 | A1 |
20090241191 | Keromytis et al. | Sep 2009 | A1 |
Number | Date | Country |
---|---|---|
WO 2007143011 | Dec 2007 | WO |
Entry |
---|
International Search Report and Written Opinion, Apr. 2007, Alcatel Lucent. |
Written Opinion, Apr. 2005, Alcatel Lucent. |
Yi-Min Wang, Doug Beck, Xuxian Jiang, and Roussi Roussev, “Automated Web Patrol with Strider HoneyMonkeys”. |
Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern Paxson, and Brian Tierney; “A First Look at Modern Enterprise Traffic”, Princeton University, International Computer Science Institute, Lawrence Berkeley National Laboratory, Internet Measurement Conference 2005. |
Jaeyeon Jung, Vern Paxson, Arthur W. Berger, and Hari Balakrishnan, “Fast Portscan Detection Using Sequential Hypothesis Testing”, MIT Computer Science and Artificial Intelligence Laboratory , Cambridge MA. |
David Whyte, Evangelos Kranakis, and P.C. Van Odorschot, “DNS-based Detection of Scanning Worms in an Enterprise Network”, School of Computer and Science, Carlton University , Ottawa, Ontario, Canada, Proceedings of the 12th Annual Network and Distributed System Security Symposium, San Dieg0, USA. Feb. 3-4, 2005. |
Stuart E. Schechter, Jaeyeon Jung, and Arthur W. Berger, “Fast Detection of Scanning Worm Infections”, Harvard DEAS, Cambridge, MA, USA, MIT CSAIL, Cambridge, MA, USA. |
Shobha Venkataraman, Dawn Song, Phillip B. Gibbons, and Avrim Blum, “New Streaming Algorithms for Fast Detection of Superspreaders”, Carnegie Mellon University, Intel Research Pittsburgh. |
David Whyte, P.C. Van Oorschot, and Evangelos Kranakis, “ARP-based Detection of Scanning Worms Within an Enterprise Network”, School of Computer Science, Carlton University, Ottawa, Canada, Jan. 31, 2005. |
Paul C. Van Oorschot, Jean-Marc Robert, and Miguel Vargas Martin, “A Monitoring System for Detecting Repeated Packets with Applications to Computer Worms”, Mar. 8, 2006. |
Nicholas Weaver, Stuart Staniford, and Vern Paxson, “Very Fast Containment of Scanning Worms”. |
Number | Date | Country | |
---|---|---|---|
20120117653 A1 | May 2012 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 12039817 | Feb 2008 | US |
Child | 13352451 | US |