1
`
`2
`
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`
`US9,674,206 10,027,693
`
`TECHNICAL FIELD OF THE INVENTION
`The present inventiondisclosure relates to network security technologies, and in particular, to a
`method, a device, and a system for alerting against unknown malicious codes.
`BACKGROUND OF THE INVENTION
`With popularization of the Internet, higher network security is required. Loopholes are frequently
`used for launching attacks. The time from discovery to use of a security loophole is now shortened
`from a few months to a few days. Once a loophole is discovered, it is used for launching attacks
`shortly. For such attacks, it usually takes a long time for the vendor to obtain a sample of malicious
`codes, and it is slower to release the corresponding patches. Therefore, such attacks tend to cause
`huge damages. MS Blast was used for launching attacks hardly in less than 25 days after it was
`discovered, and Nachi (a variant of MS Blast) was used for launching attacks in less than one week
`after it was discovered. If the malicious codes are discovered early, the attacks can be prevented in
`time, and the loss caused by malicious codes will be reduced.
`In the priorconventional art, network devices are unable to report suspicious codes. After the
`malicious code attack is launched, it takes a long time for the vendor to obtain the malicious code
`sample. Antivirus software analyzes files downloaded to the computer and reports the analysis result
`to the monitoring center. However, the computer may still be attacked by downloaded malicious
`codes if the downloaded data is not treated properly, which brings a heavy burden onto the
`computer. Antivirus software has to be installed on the computer, which is troublesome to the user.
`For such reasons, some users refuse to install antivirus software on network devices so that such
`devices are more vulnerable to propagation of malicious codes.
`SUMMARY OF THE INVENTION
`An embodiment of the present inventiondisclosure provides a method, a device, and a system for
`alerting against unknown malicious codes, so as to report source addressespath of numerous
`suspicious codes proactively at the earliest possible time, lay a foundation for shortening the time
`required for overcoming virus threats, and avoid the trouble of installing software on the
`clientterminal.
`An embodiment of the present inventiondisclosure provides a method for alerting against unknown
`malicious codes, including:
`
`detecting characteristics of a packet;
`receiving, by a network device, a request sent by a terminal for obtaining a file from a network
`entity and a data stream carrying the file;
`recording, by the network device, a source path carried in the request, wherein the network
`entity providing the file on the source path;
`judging, by the network device, whether any suspicious code exists in the packet according to
`a result of the detection;recording a source address of the suspicious code if the suspicious
`code exists in the packetthe file is an executable file according to the request or the data
`stream carried the file; and
`sending, by the network device, first alert information that carries the source addresspath to a
`monitoring device, if the network device judges the file is the executable file.
`An embodiment of the present inventiondisclosure provides a network device, including:
`
`0.0 01
`
`
`
`Juniper Ex. 1006-p.1
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`
`a first detectingreceiving module, configured to detect characteristics of a packetreceive a
`request sent by a terminal for obtaining a file from a network entity and receive a data stream
`carrying the file;
`
`a first judging module, configured to judge whether any suspicious code exists in the packet
`according to a result of the detection performed by the first detecting module;
`a first recording module, configured to record a source address of the suspicious code if the first
`judging module determines that the suspicious code exists in the packet; andpath carried in
`the request, wherein the network entity providing the file on the source path;
`a detecting module, configured to judge whether the file is an executable file according to the
`request or the data stream carried the file; and
`a first sending module, configured to send first alert information that carries the source
`addresspath to a monitoring device, if the network device judges the file is the executable file.
`An embodiment of the present inventiondisclosure provides a system for alerting against unknown
`malicious codes. The system includes a network device according to above and a monitoring
`device. The, where the monitoring device is configuredconfigure to: receive first alert information;
`resolve the alert information to obtain that carries a source address; download a suspicious
`code corresponding to the source address; and judge whether the suspicious code is
`malicious; and send alarm information when determining the suspicious code as
`maliciouspath sent from the network device; download an executable file according to the
`source path; detect the executable file to confirm maliciousness of the executable file; send
`second alarm information to the network device, wherein the second alarm information
`comprises maliciousness of the executable file, or comprises both the maliciousness of the
`executable and Botnet topology information.
`
`Therefore, the method, the device, and the system for alerting against unknown malicious codes in
`the embodiments of the present inventiondisclosure report source addressespath of numerous
`suspicious codes proactively at the earliest possible time, enable the vendor to obtain the source
`addressespath of malicious code samples shortly after the malicious codes occur, ensure
`comprehensiveness of the alert information source, lay a foundation for shortening the time required
`for overcoming virus threats, and avoid the trouble of installing software on the clientterminal.
`BRIEF DESCRIPTION OF THE DRAWINGS
`To make the technical solution under the present inventiondisclosure or in the
`priorconventional art clearer, the following outlines the accompanying drawings involved
`in the description of the embodiments of the present inventiondisclosure or the
`priorconventional art. Apparently, the accompanying drawings outlined below are
`illustrative rather than exhaustive, and persons of ordinary skill in the art can derive other
`drawings from them without any creative effort.
`FIG. 1 is a schematic diagram of a method for alerting against unknown malicious codes
`according to an embodiment of the present inventiondisclosure;
`FIG. 2 is a schematic diagram of a method for alerting against unknown malicious codes
`according to an embodiment of the present inventiondisclosure;
`FIG. 3 is a schematic diagram of a network device according to an embodiment of the
`present inventiondisclosure; and
`FIG. 4 is a schematic diagram of a monitoring device according to an embodiment of the
`present disclosure; and
`
`0.0 01
`
`
`
`- 2 -
`
`
`
`Juniper Ex. 1006-p.2
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`
`FIG. 5 is a schematic diagram of a system for alerting against unknown malicious codes
`according to an embodiment of the present inventiondisclosure.
`DETAILED DESCRIPTION OF THE EMBODIMENTS
`The following detailed description is given in conjunction with the accompanying drawings to provide
`a thorough understanding of the present inventiondisclosure. Evidently, the drawings and the
`detailed description are merely representative of particular embodiments of the present
`inventiondisclosure rather than all embodiments. All other embodiments, which can be derived by
`those skilled in the art from the embodiments given herein without any creative effort, shall fall within
`the protection scope of the present inventiondisclosure.
`The following describes the technical solution of the present inventiondisclosure in detail.
`
`FIG. 1 is a schematic diagram of a method for alerting against unknown malicious codes according
`to an embodiment of the present inventiondisclosure. The method in this embodiment includes the
`following steps:
`Step 105: Detect characteristics of a packet.101: receive, by a network device, a request sent
`by a terminal for obtaining a file from a network entity and a data stream carrying the file;
`Step 110: Judge whether any suspicious code exists in the packet according to a result of the
`detection.102: record, by the network device, a source path carried in the request, wherein
`the network entity providing the file on the source path;
`Step 128: Record a source address of the suspicious code if the suspicious code exists in the
`packet.
`Step 130: Send103: judge, by the network device, whether the file is an executable file
`according to the request or the data stream carried the file; and
`Step 104: send, by the network device, first alert information that carries the source addresspath
`to a monitoring device, if the network device judges the file is the executable file.
`The entity for performing the steps of this embodiment is a network device. The source address of
`the suspicious code in the packetpath is sent to the monitoring device so that the monitoring
`device is alerted for suspicious codescould download the file according to the source path,
`and detect the executable file to confirm maliciousness of the executable file in time.
`In this embodiment, the characteristics of the packet are detectedwhether the file is an
`executable file is detected. When the file is an executable file, then it is regards as suspicious
`codes. For example, the detection method is to detect whether a string which indicating the name
`of the suspicious code is included in the packet, whether theexecutable file exists in the
`request, and/or whether a file header of the suspicious code is includedexecutable file exists in
`the data stream, or bothreturned by the server.
`
`In this embodiment, the terminal sends the request for obtaining the file from the network
`entity, especially, the network entity is server providing the file on the source path, for
`example, the network entity is a Web server of a FTP (File Transfer Protocol) server.
`The request may be an HTTP get request or an FTP request, wherein the request contains the
`source path according to which the server providing the file.
`The network device may be a network gateway device between the terminal and the network
`entity. The network device will receive the request. After the network device receiving the
`request, the network device records a source path according to which the server providing
`the file. The source path generally appears in the URL after get.
`
`0.0 01
`
`
`
`- 3 -
`
`
`
`Juniper Ex. 1006-p.3
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`
`The network device, detects whether the file is an executable file. The detecting, by the
`network device, whether the file is the executable file comprises:
`detecting, by the network device, whether a string which indicating the name of the
`executable file exists in the request; and/or
`detecting, by the network device, whether a file header of the executable file exists in the data
`which transmitted by the data stream returned by the server.
`Specifically, at the time of detecting whether a string which indicating the name of the suspicious
`code is includedexecutable file exists in the packetrequest, if a string like get *.exe is detected in
`the packet, it indicates that an executable file is being transmitted, in which *.exe is a suspicious
`code, and * represents a string of a random length. The executable file may leak information of the
`terminal user, damage the terminal system, or even let the terminal be controlled by the attacker. Or,
`if a packet includes strings like get *.dll or get *.ocx, it indicates that an executable file or, that is a
`string of malicious codes is being transmitted, which may leak information of the terminal user,
`damage the terminal system, or even let the terminal be controlled by the attacker. Such codes need
`to be reported.
`At the time of detecting whether thea file header of the suspicious code is included in the data
`streamexecutable file exists in the file returned by the server, if a PE (portable executable) file
`header characteristic code “MZ” is detected (MZ is expressed by American Standard Code for
`Information Interchange (ASCII) codes), the PE file may leak information of the terminal user,
`damage the terminal system, or even let the terminal be controlled by the attacker when the PE file is
`executed. Therefore, the PE file is a string of suspicious codes.
`
`When the two detection methods above are combined, if get *.jpg is detected and a PE file header
`characteristic code “MZ” is detected (MZ is expressed by ASCII codes) in the corresponding data,
`the PE file is a string of suspicious codes, because the user attempts to download a picture but an
`executable file is returned. The spoofing indicates that the PE file is probably is a string of malicious
`codes.
`
`The source of the suspicious code needs to be located after the suspicious code is detected.
`Specifically, ifIf the suspicious code is detected by checking whether the name of the suspicious
`codeexecutable file is included in the data stream, the source addresspath generally appears in
`the URL after get. If the suspicious code is detected by checking whether the file header of the
`suspicious code is included in the data stream, the source address of the packet may be
`searched out according to the information in the packet. If both of the detection methods are
`applied in detecting the suspicious codeexecutable file, the source address generally appears in
`the URL after get.,
`
`After the source address of the suspicious code is recorded,If the network device judges the
`file is the executable file, the network device generates first alert information that carries the
`source address is sentpath and sends the first alert information to the monitoring device. After
`the first alert information is sent, the network device receives second alarm information returned by
`the monitoring device.
`
`The method for alerting against unknown malicious codes in this embodiment reports source
`addressespath of numerous suspicious codes proactively at the earliest possible time, enables the
`vendor to obtain the source addressespath of malicious code samples shortly after the malicious
`codes occur, ensures comprehensiveness of the alert information source, lays a foundation for
`shortening the time required for overcoming virus threats, and avoids the trouble of installing
`software on the clientterminal.
`
`FIG. 2 is a schematic diagram of a method for alerting against unknown malicious codes according
`to an embodiment of the present inventiondisclosure. The method in this embodiment includes the
`following steps:
`
`0.0 01
`
`
`
`- 4 -
`
`
`
`Juniper Ex. 1006-p.4
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`
`Step 105: Detect characteristics of a packet.receiving, by a network device, a request for
`obtaining a file from a sent by a terminal for obtaining a file from a network entity;
`receiving, by a network device, a data stream carrying the file;
`Step 110: Judge whether any suspicious code exists in the packet according to a result of the
`detection.recording, by the network device, a source path carried in the request, wherein the
`network entity providing the file on the source path;
`Step 128: Record a source address of the suspicious code if the suspicious code exists in the
`packet.judging, by the network device, whether the file is an executable file according to the
`request or the data stream carried the file;
`Step 130: Sendsending, by the network device, first alert information that carries the source
`addresspath to a monitoring device., if the network device judges the file is the executable file;
`Step 204: Receivereceiving, by the network device, second alarm information sent by the
`monitoring device. The second alarm information includes maliciousness of the suspicious code, or
`includes both the maliciousness of the suspicious code and the Botnet topology information.
`This embodiment differs from the previous embodiment in that: the network device receives second
`alarm information returned by the monitoring device after sending first alert information. The second
`alarm information includes maliciousness of the suspicious code against which the alert is raised, or
`includes both the maliciousness of the suspicious code and the Botnet topology information.
`
`The monitoring device may identify maliciousness of the suspicious code through characteristics
`detection, sandbox test, or both.
`
`If the monitoring device uses characteristics detection to calculate possibility of maliciousness, the
`monitoring device compares the suspicious code with a more detailed repository of malicious code
`characteristics. If the suspicious code matches any characteristics in the repository of malicious code
`characteristics, the monitoring device can calculate the probability of attacks launched by the
`malicious code according to the matching extent, and identify possibility of such attacks, namely,
`maliciousness possibility. For example, if the suspicious code matches a string of suspicious code
`characteristics regarded as having an 80% probability of launching attacks in the characteristics
`repository, the suspicious code is also regarded as having an 80% probability of launching attacks. If
`this probability exceeds the alarm threshold, the suspicious code is possibly malicious.
`
`If the monitoring device uses a sandbox to calculate the maliciousness possibility, the monitoring
`device runs the suspicious code in the sandbox automatically, records the execution result and the
`running status, and calculates the maliciousness possibility according to the record. The sandbox is
`a professional virtual environment. The program that runs in the sandbox is redirected into the
`sandbox when modifying a registry or a file. In this way, if the program is malicious, no impact is
`caused outside the sandbox. Even if an attack is launched in the sandbox, the attack impact is
`cancelled by restarting the sandbox. For example, the monitoring device detects that a malicious
`event is triggered in the process of running a suspicious code, and the probability of launching
`attacks from the event is 40%. Therefore, the maliciousness possibility of the suspicious code is
`40%. If this probability exceeds the alarm threshold, the suspicious code is possibly malicious.
`If the suspicious code that the monitoring device downloads according to the first alert
`information is determined as malicious, the monitoring device may retrieve the Botnet topology
`information in the malicious code, and generates and sends second alarm information that carries
`the Botnet topology information.
`
`The Botnet topology information in the foregoing malicious code includes Bot hosts as well as the
`IPInternet Protocol (IP) address, port, or Uniform Resource Locator (URL) that controls the hosts.
`After the monitoring device sends the second alarm information that carries the Botnet topology
`information, the network device receives the alarm information sent by the monitoring device. The
`
`0.0 01
`
`
`
`- 5 -
`
`
`
`Juniper Ex. 1006-p.5
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`
`second alarm information includes maliciousness of the suspicious code, or includes both the
`maliciousness of the suspicious code and the Botnet topology information.
`
`The method in this embodiment may further include the following steps:
`Step 216: Interceptintercepting, by the network device, suspicious codes that are malicious
`according to maliciousness of the suspicious codes; or
`Step 225: Interceptintercepting, by the network device, the suspicious codes that are malicious
`and the packets in the Botnet corresponding to the Botnet topology information according to
`maliciousness of the suspicious codes and the Botnet topology information.
`After receiving the second alarm information, the network device intercepts the corresponding
`suspicious codes and the packets in the Botnet.
`
`The method for alerting against unknown malicious codes in this embodiment reports source
`addressespath of numerous suspicious codes proactively at the earliest possible time, ensures
`comprehensiveness of the alert information sources, lays a foundation for shortening the time
`required for overcoming virus threats, and avoids the trouble of installing software on the
`clientterminal. Moreover, because the network device sends the source addresspath of the
`suspicious codes rather than the suspicious codes themselves, the occupancy of user bandwidth is
`reduced; the monitoring device analyzes the suspicious codes and sends alarms to the network
`device so that the network device can intercept malicious codes; the monitoring device retrieves the
`Botnet topology information and sends Botnet alarms to the network device, and therefore, the
`network device intercepts the packets in the Botnet, which reduces possibility of the host being
`attacked.
`
`FIG. 3 is a schematic diagram of a network device according to an embodiment of the present
`inventiondisclosure. The network device in this embodiment includes:
`a first detectingreceiving module 301, configured to detect characteristics of a packetreceive a
`request sent by a terminal for obtaining a file from a network entity and receive a data stream
`carrying the file;
`
`a first judging module 312, configured to judge whether any suspicious code exists in the
`packet according to a result of the detection performed by the first detecting module;
`a first recording module 325,302, configured to record a source address of the suspicious code if
`the first judging module determines that the suspicious code exists in the packet; andpath
`carried in the request, wherein the network entity providing the file on the source path;
`a detecting module 303, configured to judge whether the file is an executable file according to
`the request or the data stream carried the file; and
`a first sending module 336,304, configured to send first alert information that carries the source
`addresspath to a monitoring device, if the network device judges the file is the executable file.
`In this embodiment, the first detecting module detects characteristics of the packet to detect the
`suspicious code, for example, by detecting whether a string which indicating the name of the
`suspicious code is included in the packet, whether the file header of the suspicious code is
`included in the data stream, or both. The first judging module judges whether any suspicious
`code exists in the packet according to the result of the detection performed by the first
`detecting module. The firstexecutable file exists in the request; and/or detecting whether a
`file header of the executable file exists in the data returned by the server. The recording
`module records the source addresspath of the suspicious code if the first judging module
`determines that the suspicious code exists in the packet, and the first. The sending module
`sends first alert information to the monitoring device. After the alert information is sent, the
`network device receives alarm information returned by the monitoring device.
`
`0.0 01
`
`
`
`- 6 -
`
`
`
`Juniper Ex. 1006-p.6
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`
`The first detecting module in this embodiment may further include:
`a first detecting submodule 302, configured to detect whether the name of the suspicious
`code exists in the data stream; and/ora second detecting submodule 303, configured to
`detect whether the file header of the suspicious code exists in the data stream.
`
`This embodiment may further include:
`a firstthe receiving module 345,301 is further configured to receive second alarm information sent
`by the monitoring device after further detecting the file downloaded according to the source
`path by the monitoring device, where the second alarm information includes maliciousness of the
`suspicious code, or includes both the maliciousness of the suspicious code and the Botnet topology
`information.
`ThisAccordingly, this embodiment may further include:
`a first intercepting module 352,305, configured to intercept suspicious codes that are malicious
`according to maliciousness of the suspicious codes; or
`a second intercepting module 367,306, configured to intercept the suspicious codes that are
`malicious and the packets in the Botnet corresponding to the Botnet topology information according
`to maliciousness of the suspicious codes and the Botnet topology information.
`The network device provided in this embodiment reports source addressespath of numerous
`suspicious codes proactively at the earliest possible time, ensures comprehensiveness of the alert
`information sources, lays a foundation for shortening the time required for overcoming virus threats,
`and avoids the trouble of installing software on the clientterminal. Moreover, the first receiving
`module receives the alarm information from the monitoring device, and therefore, the network device
`interrupts malicious codes and the packets in the Botnet, which reduces the possibility of the host
`being attacked.
`FIG. 4 is a schematic diagram of the monitoring device, comprising:
`a receiving module 401, configured to receive first alert information that carries a source path
`sent from a network device;
`a downloading module 402, configured to download an executable file according to the
`source path;
`a detecting module 403, configured to detect the executable file to confirm maliciousness of
`the executable file; and
`a sending module 404, configured to send second alarm information to the network device,
`wherein the second alarm information comprises maliciousness of the executable file, or
`comprises both the maliciousness of the executable and Botnet topology information.
`FIG. 5 is a schematic diagram of system for alerting against unknown malicious codes according to
`an embodiment of the present inventiondisclosure. The system in this embodiment includes the
`network device 401501 and the monitoring device 412 shown in FIG. 4. The monitoring device is
`configured to: receive alert information; resolve the alert information to obtain a source
`address; download a suspicious code corresponding to the source address; and judge
`whether the suspicious code is malicious; and send alarm information when determining the
`suspicious code as malicious.512 shown in FIG. 5.
`An embodiment of the present inventiondisclosure provides a system for alerting against unknown
`malicious codes. The system collects source addressespath of numerous suspicious codes
`proactively at the earliest possible time, ensures comprehensiveness of the alert information
`sources, lays a foundation for shortening the time required for overcoming virus threats, and avoids
`the trouble of installing software on the clientterminal.
`
`0.0 01
`
`
`
`- 7 -
`
`
`
`Juniper Ex. 1006-p.7
`Juniper v Huawei
`
`

`

`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`
`After reading the foregoing embodiments, those skilled in the art are clearly aware that the
`embodiments of the present inventiondisclosure may be implemented through hardware, or,
`preferably in most circumstances, through software in addition to a necessary universal hardware
`platform. Therefore, all or part of the novelty of the present inventiondisclosure may be embodied
`in a software product. The software product may be stored in storage media such as ROM/a read-
`only memory (ROM) or random access memory (RAM), magnetic disk, or Compact Disc Read-
`Only Memory (CD-ROM), and incorporatesincorporate several instructions for instructing a
`computer device (such as personal computer, server, or network device) to execute the method
`specified in any embodiment of the present inventiondisclosure or a part of the embodiment.
`
`Finally, it should be noted that the above embodiments are merely provided for describing the
`technical solutions of the present inventiondisclosure, but not intended to limit the present
`inventiondisclosure. It is apparent that persons skilled in the art can make various modifications
`and variations to the inventiondisclosure without departing from the spirit and scope of the
`inventiondisclosure. The present inventiondisclosure is intended to cover the modifications and
`variations provided that they fall in the scope of protection defined by the following claims or their
`equivalents.
`
`0.0 01
`
`
`
`- 8 -
`
`
`
`Juniper Ex. 1006-p.8
`Juniper v Huawei
`
`