|Publication number||US7418729 B2|
|Application number||US 10/264,922|
|Publication date||Aug 26, 2008|
|Filing date||Oct 4, 2002|
|Priority date||Jul 19, 2002|
|Also published as||US20040015712|
|Publication number||10264922, 264922, US 7418729 B2, US 7418729B2, US-B2-7418729, US7418729 B2, US7418729B2|
|Original Assignee||Symantec Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (93), Non-Patent Citations (17), Referenced by (41), Classifications (6), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims the priority benefit under 35 U.S.C. § 119(e) of commonly owned U.S. Provisional Patent Application Ser. No. 60/397,159, filed Jul. 19, 2002, which patent application is hereby incorporated in its entirety by reference into the present patent application.
This invention pertains to the field of detecting malicious code in computer systems, and in particular to detecting malicious code using a dynamic heuristic based on tracking access to suspicious pages or portions of a memory.
In May of 2002, the number of known 32-bit Windows viruses and worms exceeded 2000. Computer viruses, worms, and Trojan horses are types of “malicious code,” which is herein defined as any computer program, module, set of modules, or code that enters a computer system without an authorized user's knowledge and/or without an authorized user's consent. In particular, a computer worm is malicious code that has the ability to replicate itself from one computer to another, e.g., over a computer network. Although the major problem for today's users is computer worms, simple file infector viruses persist and remain a challenge for anti-virus software. Distinguished from worms, computer viruses are characterized in that they typically attach to and/or modify a host program, which may be an executable, a dynamically linked library (DLL), or another kind of application. Examples of such viruses include the virus families W32. FunLove, W32. Bolzano, and W32. Coke.
To operate, malicious code usually has to call system APIs (application programming interfaces) from system libraries, such as KERNEL32. DLL in 32-bit WINDOWS systems. Normal computer programs access system APIs by static linking, which builds a proper import address table, or by calling the GetProcAddress( ) API to obtain dynamically the address of a particular API. An application that uses the GetProcAddress( ) API typically needs to have a static import to call that API. The static import for the GetProcAddress( ) API is located in the application's import address table, which thereby allows the application to call by name any APIs that are to be exported. Malicious code cannot typically call APIs like normal applications because malicious code typically does not have its own imports.
Accordingly, calling system APIs can be a challenge for writers of malicious code. For example, the Win95/Boza virus often failed to infect files as intended because it used hard-coded addresses to call particular system APIs more easily. Because API addresses often vary from one operating system (OS) to the next—and even among different releases of the same OS—malicious code that uses hard-coded API addresses does not spread well on different systems. To solve this problem, writers of malicious code have implemented functions for locating system APIs that are similar in their implementation to GetProcAddress( ). For example, the Win95/Marburg and Win32/Cabanas.A viruses both used a trick that has become a new standard in virus development. These viruses have a function that locates the address of each API they need to call under all Win32 systems. While a challenge for virus writers, this need to call system APIs can be exploited by writers of anti-virus tools.
The article, Ször, Péter, “Attacks on Win32,” Proceedings of the Virus Bulletin Conference, October 1998, England, explains how heuristic analysis is helpful for detecting infections by malicious code. Heuristics are usually based on certain characteristics that distinguish malicious code from normal code, such as the malicious code's need to call system APIs as described above. One heuristic suggested in the “Attacks on Win32” article is to search for code in a target file that uses the KERNEL32 address directly and looks for the text string “PE00”. This heuristic is premised on the idea that accessing the KERNEL32 library and searching for “PE00” is one way that malicious code can locate system APIs without having those addresses hard-coded, whereas normal applications do not need to perform this task because they have an import table. This technique is called a static heuristic because it is performed by scanning a particular file for certain structure characteristics common to particular types of malicious code. Static heuristic techniques have been extremely successful against early file viruses and other malicious code, and these heuristics continue to be useful against many species of malicious code today.
But programmers of malicious code are increasingly employing anti-heuristic techniques to hide the identifying features of malicious code infection in a file's structure. Many of these anti-heuristic techniques implement the same suspicious activity in different ways to obscure that activity from static heuristics techniques. For example, the static heuristic explained above could be defeated by encrypting the portion of the malicious code that looks for the text string “PE00”. Ször, Péter, “Attacks on Win32—Part II,” Proceedings of the Virus Bulletin Conference, September 2000, England, describes a variety of other anti-heuristic techniques used by malicious code to avoid detection by static heuristics. Accordingly, anti-virus software tools often employ emulation, in which a file is executed in an emulated environment. In this way, the anti-virus software can use heuristics that are based on actions that the executed file takes in the simulation, thus defeating the efforts of writers of malicious code to obscure the structure of their malicious code. Such techniques are referred to as dynamic heuristics. “Attacks on Win32 II” also describes various attacks by malicious code on computer systems, as well as static and dynamic heuristics and other techniques for detecting malicious code.
Apart from heuristics, the “Attacks on Win32 II” article additionally explains some of the incompatibility problems that caused older 32-bit viruses to fail to work on newer WINDOWS 2000 systems. For example, several 32-bit viruses call system APIs by searching for the loaded KERNEL32. DLL (and thus the APIs therein), and looking for the text “MZ” or “PE” within particular process address spaces. Because different versions and releases of WINDOWS use different base addresses for system libraries such as KERNEL32. DLL, viruses written for one release or type of OS will often fail to work on a different one. Viruses such as the WIN32/Cabana family do not pay attention to the moving DLL base address, and thus fail on some systems when attempting to locate the loaded system libraries. This paper, however, failed to recognize that incompatibility problems such as this one could themselves be used as a heuristic for detecting various types of malicious code.
As writers continue to develop malicious code, the need persists for additional reliable heuristics to detect computer viruses and other malicious code without generating a significant number of false positives.
The present invention comprises methods, apparati, and computer program products for detecting malicious code in a host file (100). In an embodiment of the invention, an emulating module (414) emulates the host file (100) in a virtual machine (422) having a virtual memory (426). While emulating the host file (100), the system (400) tracks the host file's access of the virtual memory (426). Responsive to an access in a non-normal address range of the virtual memory (426) by the host file (100), a flag recording module (522) sets a flag. A virus reporting module (526) declares a potential malicious code based on whether the flag is set. This technique can be used with additional heuristics for detecting a computer virus and other malicious code.
These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompany drawings, in which:
Malicious code typically infects a host file by attaching or altering code at or near an “entry point” of the file. An entry point is any instruction or set of instructions in the file, a pointer to an instruction or set of instructions, or other data in the file that malicious code can modify to gain control of the computer system at which the file is located. An entry point is typically identified by an offset from some arbitrary point in the file. Certain entry points are located at the beginning of a file or region and, therefore, are always invoked when the file or region is executed. For example, an entry point can be the first instruction executed when the host file is executed or when a function within the file is called. Other possible entry points are single instructions deep within the file that can be modified by malicious code. For example, the entry point can be a CALL or JMP instruction that is modified to invoke the malicious code. Once malicious code seizes control of the computer system through the entry point, the malicious code typically infects other files on the system and/or other systems networked with the host system.
Although the present invention can be applied to detect any type of malicious code, an embodiment of the invention is described in the context of detecting a computer virus. However, persons skilled in the art can appreciate that the invention can be used to detect any type of malicious code, such as computer worms, that is susceptible to the heuristic described herein.
The file 100 is divided into sections containing either code or data and aligned along four-kilobyte (kB) boundaries. The MS-DOS section 102 contains the MS-DOS header and is marked by the characters “MZ.” This section 102 contains a small executable program 103 designed to display an error message if the executable file is run in an unsupported OS (e.g., MS-DOS). This program 103 is an entry point for the file 100. The MS-DOS section 102 also contains a field 104 holding the relative offset to the start 108 of the PE header section 106. This field 104 is another entry point for the file 100.
The PE header section 106 is marked by the characters “PE” and holds a data structure 110 containing basic information about the file 100. The data structure 110 holds many data fields describing various aspects of the file 100.
Section 112 holds the section table 114, which contains information about each section in the file 100, including the section's type, size, and location in the file 100. For example, entries in the section table 114 indicate whether a section holds code or data, and whether the section is readable, writeable, and/or executable. Each entry in the section table 114 describes a section that may have a single entry point, multiple entry points, or no entry points.
The text section 116 holds executable code produced by the compiler or assembler. The data section 118 holds global and static variables that are initialized at compile time. There can be more than one text section 116 and/or more than one data 118 in the file 100.
The export section 120 contains an export table 122 that identifies functions exported by the file 100 for use by other programs. An EXE file might not export any functions, while DLL files typically export some functions. The export table 122 holds the function names, entry point addresses, and export ordinal values for the exported functions. The entry point addresses typically point to other sections in the file 100. Each exported function listed in the export table 122 is an entry point into the file 100.
The import section 124 has an import table 126 that identifies functions that are imported by the file 100. Each entry in the import table 126 identifies the external DLL and the imported function by name. When code in the text section 116 calls a function in another module, such as an external DLL file, the call instruction transfers control to a JMP instruction also in the text section 116. The JMP instruction, in turn, directs the call to a location within the import table 126. Both the JMP instruction and the entries in the import table 126 represent entry points into the file 100.
To operate, a computer virus typically needs to call certain system API functions, such as FileOpen( ) and FileDelete( ). Unlike the file 100 itself, a typical virus cannot use the import table 126 to call these API functions, because the virus infects the file 100 after the import table 126 is made. Accordingly, viruses often solve this problem by searching the headers of certain system DLLs—such as the KERNEL32. DLL in WINDOWS95—to obtain the addresses for the API functions that the virus needs to call. This action is suspicious because a normal file 100 does not need to access these non-normal locations in the memory because the file 100 has an import table 126. As used herein, a “non-normal” memory location is any part of the memory that a normal application does not typically access, such as headers and other sections that do not contain executable code. Accordingly, access to that memory location is suspicious as indicating the presence of malicious code. As used herein, “access” refers to any read or write operations to a memory. The present invention uses this concept to provide a heuristic for detecting file infector viruses and any other malicious code that accesses suspicious locations in the memory.
The processor 202 may be any general-purpose processor, such as an INTEL x86, a SUN MICROSYSTEMS SPARC, or a POWERPC-compatible CPU. As is known in the art, the processor 202 has multiple registers that are used to hold instructions, data, addresses, and other information. The storage device 208 may be any device capable of holding data, like a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. As is known in the art, the storage device 208 typically holds multiple files of different types, including potential virus host files like that described by
As is known in the art, the computer system 200 is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic and/or any hardware or circuitry utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, software, or any combination thereof. Preferably, program modules providing the functionality of the VDS 400 are stored on the storage device 208.
The virus identifies 312 a new host file 100 to infect. For example, the virus may search for files matching the string “*.EXE” to identify new host file candidates. The virus then filters the candidate files to identify 312 a particular new host file 100. The files may be filtered based for example on the files' sizes, names, types, and/or whether the files are already infected by the virus.
The virus inserts 314 its viral code into the new host file 100. For example, the virus can append the viral body to the slack space at the end of a section or put the viral body within an entirely new section. During this step 314, the virus uses one or more techniques to modify its current viral code to produce new viral code, which it then inserts into the file 100. The techniques the virus can use to modify its code include inserting and/or removing jump (“JMP”) and no-operation (“NOP”) instructions; substituting varying sets of equivalent instructions for performing certain tasks, such as register subtractions or zeroing; and substituting the registers used by certain instructions.
The virus typically modifies 316 the section table 114 in the host file 100 to account for the added viral code. For example, the virus may change the size entry in the section table 114 to account for the added viral code. Likewise, the virus may add entries for new sections added by the virus. If necessary, the virus may mark an infected section as executable and/or place a value in a little-used field to discreetly mark the file 100 as infected and prevent the virus from re-infecting the file 100.
In addition, the virus typically also alters 318 an entry point of the host file 100 to call the viral code. The virus may accomplish this step by, for example, overwriting the value in the field 104 holding the relative offset to the start 108 of the PE section 106, with the relative offset to virus code stored elsewhere in the file. Alternatively, the virus can modify entries in the export table 122 to point to sections of virus code instead of the exported functions. A virus can also modify the destination of an existing JMP or CALL instruction anywhere in the file 100 to point to the location of viral code elsewhere in the file 100, effectively turning the modified instruction into a new entry point for the virus.
A particularly sophisticated virus can use very complex techniques for infecting the host file 100 that differ in some respects from the ones described above. For example, one sophisticated virus includes a disassembly engine in its viral body and uses it to disassemble the host file 100 into its smallest elements. Then, the virus infects the dissembled host file 100 by moving code blocks to clear space for the viral code, inserting its modified viral body, regenerating code and data references, including relocation information, and then rebuilding the file 100. Another sophisticated virus detects whether a compiler is present on the host computer system 200. If a compiler is present, the virus uses it to recompile a slightly modified version of the virus's source code and thereby generate a completely new viral body. Then, the virus inserts the new viral body into the host file 100. Other viruses can use techniques in addition to, or instead of, the ones described herein to modify the viral bodies and insert the bodies into host files.
The VDS 400 includes a P-code data module 410, an engine module 412, an emulating module 414, and a virus database module 430. The P-code data module 410 preferably holds P-code instruction modules for controlling the operation of the VDS 400 to detect the presence of a virus. As used herein, “P-code” refers to program code for providing data-driven functionality to the VDS 400. Preferably, a virus researcher creates the P-code instructions in the data module 410 by writing instructions in any computer language and then compiling the instructions into P-code. In addition, the functionality of the P-code can be replaced by other data-driven techniques. For example, the program code can be stored in a representation other than P-code or a state machine can be utilized in combination with, or as an alternative to, the P-code to provide deterministic data-driven virus detection.
One embodiment of the present invention uses data-driven techniques to control the operation of the VDS 400 because such techniques allow the functionality of the VDS to be updated by updating the P-code and/or other data. For example, the VDS 400 can be updated to detect new viruses by updating the P-code instead of the other modules. Accordingly, the use of data-driven techniques simplifies the task of updating thousands or millions of VDSs 400 that are installed on computer systems “in the field.” However, alternate embodiments of the present invention implement the described functionality through non-data-driven techniques.
The engine module 412 preferably controls the operation of the VDS 400 in response to the P-code in the P-code data module 410. The engine 412 preferably contains a P-code interpreter 416 for interpreting the P-code, which in turn controls the operation of the engine 412. In alternative embodiments where the data module 410 holds instructions in a format other than P-code, the engine 414 is equipped with a module for interpreting or compiling the instructions in the relevant format.
The P-code interpreter 416 preferably includes special P-code function calls called “primitives” 418. The primitives 418 can be, for example, written in P-code or a native language, and/or integrated into the interpreter 416 itself. Primitives 418 are essentially functions useful for examining the host file 100 and virtual machine 422 that can be called by other P-code. For example, the primitives 418 perform functions such as opening files for reading, closing files, zeroing out memory locations, truncating memory locations, locating exports in the file, determining the type of the file, and finding the offset of the start of a function. The functions performed by the primitives 418 can vary depending upon the computer or operating system in which the VDS 400 is being used. For example, different primitives may be utilized in a computer system running the MACINTOSH operating system than in a computer system running a version of the WINDOWS operating system. In an alternative embodiment, some or all of the primitives can be stored in the P-code data module 410 instead of the interpreter 416.
The emulating module 414 is preferably adapted to execute computer program instructions in the host file 100 in a virtual machine 422 under the direction of the engine module 412. The emulating module 414 includes a control program (CP) module 420 for setting up a virtual machine 422 having a virtual processor 424, a virtual memory 426, and a set of virtual registers 428 (typically part of the virtual processor). The virtual machine 422 emulates a 32-bit MICROSOFT WINDOWS environment, an APPLE MACINTOSH environment, or any other hardware and/or software environment for which emulation is desired. The virtual machine 422 uses the virtual processor 424 to execute the instructions in the virtual memory 426 in isolation from the actual hardware and software on the computer system 200. Therefore, the malicious code executed by the emulating module 414 cannot contaminate the computer system 200.
A file selection module 510 preferably contains P-code for selecting a potential host file 100 on the computer system 200 to examine for the presence of a virus. In general, the file selection module 510 preferably filters the files on the computer system 200 to select only files that are susceptible to infection by a virus. In one embodiment, the file selection module 510 performs one or more tests on each file, and only those files that pass each test are designated “susceptible to infection by a virus.” The tests can include, for example, determining whether the file contains executable instructions (e.g., whether the file has a “.EXE” or “.DLL” extension), whether the file is a PE file, whether the file contains a marker that is consistent with infection by a known virus, whether the size of the file is suspicious, and whether the internal characteristics of the file indicate a possible viral infection.
In one embodiment, other modules in the VDS 400 are adapted to identify files on the computer system 200 and use the file selection module 510 to determine whether the file is susceptible to infection. For example, the other modules may be configured to detect when a file 100 on the storage device 208 is accessed and then activate the file selection module 510 to process the file 100. In another example, the other modules may be configured to search recursively for files on the storage device 208 and utilize the file selection module 510 to examine each encountered file 100. In another embodiment, the functionality described in these two examples is provided by the file selection module 510 itself.
The P-code data module 410 preferably includes an emulation control module 520. This module 520 preferably contains code for identifying and selecting potential virus entry points in the file 100 and emulating instructions in the file 100 at each selected point. Although one embodiment of the emulation control module 520 selects only certain locations in the file 100 as potential entry points, another embodiment of the module 520 treats every instruction in the file 100, or every instruction within certain regions of the file 100, as potential entry points. The emulation control module 520 accesses the virus database module 430 to determine the parameters for the emulations and interacts with the control program 420 in the emulating module 414 to perform the emulations according to the parameters. In one embodiment, the emulation control module 520 holds the emulation parameters instead of the virus database 430.
The P-code data module 410 also preferably includes a flag recorder module 522. This module 522 preferably contains code for setting one or more flags in response to the access of suspicious address ranges in the memory 426 by the emulated program. The address range or ranges to track are preferably stored in the virus database 430, although other embodiments of the present invention may use other techniques to specify the address ranges. The VDS 400 preferably stores the flags in the emulation module 414 or another location in the computer system 200 where the flags are accessible to the modules in the VDS 400. Depending on the desired heuristic, the flag recorder module 522 may be adapted to set a separate flag associated with different suspicious memory address ranges.
The P-code data module 410 also preferably includes a breakpoint condition module 524. This module 524 preferably specifies breakpoints and other stopping conditions for the emulation. Preferably, the emulation control module 520 uses the breakpoint condition module 524 to stop the emulation at certain points. In one embodiment, the breakpoint condition module 524 specifies a number of instructions that should be emulated before stopping. Preferably, the breakpoints are configured to stop emulation after relatively few instructions. For example, in one embodiment a breakpoint stops emulation after 50 to 500 instructions. In contrast, typical emulation-based virus detection software may emulate over one million instructions before reaching a breakpoint. In another embodiment, the breakpoint condition module 524 specifies a virtual machine state at which emulation should stop. In yet another embodiment, the module 524 specifies a combination of factors for determining whether to stop emulation. For example, the breakpoint condition module 524 can specify that emulation should stop if one or more flags have been set by the flag recorder module 522. In another example, the breakpoint condition module 524 can specify that a breakpoint should occur every 100 instructions, until the total number of emulated instructions exceeds a specified maximum. The breakpoint condition module 524 may also store separate breakpoint conditions for certain host files and/or viruses and also a default breakpoint condition.
The P-code data module 410 also preferably includes a virus reporting module 526 storing code for detecting the presence of a virus in the file 100. Preferably, the virus reporting module 526 whether one or more flags have been set by the flag recorder module 522. If the virus reporting module 526 determines that one or more flags were set, the module 526 preferably reports a probable virus detection to the VDS 400. In response, other modules in the VDS 400 preferably perform actions such as notifying the computer user of the virus, quarantining the file 100, attempting to repair the infected file 100 and/or computer system, and performing additional heuristics. If the virus reporting module 526 determines that no flags or an insufficient number of flags have been set, the module preferably reports this result to the VDS 400.
The VDS 400 examines the files on the computer system 200 to identify those files that are susceptible to infection by a virus. Preferably, the VDS 400 selects 610 a single file 100 for further examination. Alternatively, the VDS 400 receives a reference to a file from another module executing on the computer system 200 and subjects this file 100 to further examination.
The VDS 400 examines the selected file 100 to identify 612 potential entry points for a virus. As described above, there are many locations in the file 100 that viruses can exploit as entry points. The VDS 400 selects one of the entry points and emulates 614 the instructions at that entry point according to the specified emulation parameters. While emulating 614 the selected file 100, the VDS 400 tracks 616 access to suspicious address ranges in the virtual memory 426. The VDS 400 continues to emulate 614 the instructions and track 616 page access until the emulation reaches a breakpoint. The process of emulating the instructions in the file and tracking page access is referred to herein as “tracing” or “micro-tracing.”
If 618 the VDS 400 detects a virus, as indicated by one or more flags having been set by the flag recorder module 522, the VDS 400 preferably responds 620 to the virus by notifying the computer user, cleaning the file 100, or continuing to run additional heuristics. Depending upon the breakpoint, the VDS 400 may resume the micro-trace of the entry point if it does not detect a virus. For example, the VDS 400 may resume the micro-trace if it has emulated only 100 instructions and the breakpoint specifies that a break should occur every 100 instructions until a maximum of 1000 instructions are emulated.
If the VDS 400 finishes emulating 614 from entry point and it does not detect a virus, the VDS 400 determines 622 whether there are more potential entry points in the selected file 100 to micro-trace. If so, the VDS 400 begins 614 a new micro-trace at the next potential entry point. When the VDS 400 has micro-traced all of the potential entry points without detecting a virus, it determines 624 whether there are more files to check for viruses. If there are more files, the VDS 400 selects another file and repeats the virus detection process described above. If there are no more files, the VDS 400 completes 626 operation.
In sum, an infected program is likely to attempt to access suspicious, non-normal address ranges in the memory. The present invention uses this property as a dynamic heuristic to detect the presence of such viruses by micro-tracing portions of potential virus host files and tracking their access to certain pages in the virtual memory. As a result, the present invention can detect viruses that may be undetectable with other means, such as pattern matching and other static heuristic techniques.
The above description is included to illustrate the operation of various embodiments of the invention and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5278901||Apr 30, 1992||Jan 11, 1994||International Business Machines Corporation||Pattern-oriented intrusion-detection system and method|
|US5398196||Jul 29, 1993||Mar 14, 1995||Chambers; David A.||Method and apparatus for detection of computer viruses|
|US5440723||Jan 19, 1993||Aug 8, 1995||International Business Machines Corporation||Automatic immune system for computers and computer networks|
|US5452442||Apr 14, 1995||Sep 19, 1995||International Business Machines Corporation||Methods and apparatus for evaluating and extracting signatures of computer viruses and other undesirable software entities|
|US5473769||Aug 31, 1992||Dec 5, 1995||Cozza; Paul D.||Method and apparatus for increasing the speed of the detecting of computer viruses|
|US5572590||Apr 12, 1994||Nov 5, 1996||International Business Machines Corporation||Discrimination of malicious changes to digital information using multiple signatures|
|US5684875||Oct 21, 1994||Nov 4, 1997||Ellenberger; Hans||Method and apparatus for detecting a computer virus on a computer|
|US5696822||Sep 28, 1995||Dec 9, 1997||Symantec Corporation||Polymorphic virus detection module|
|US5715174||Nov 15, 1994||Feb 3, 1998||Absolute Software Corporation||Security apparatus and method|
|US5715464||Jun 7, 1995||Feb 3, 1998||International Business Machines Corporation||Computer system having suspend once resume many sessions|
|US5758359||Oct 24, 1996||May 26, 1998||Digital Equipment Corporation||Method and apparatus for performing retroactive backups in a computer system|
|US5812763||Jan 21, 1993||Sep 22, 1998||Digital Equipment Corporation||Expert system having a plurality of security inspectors for detecting security flaws in a computer system|
|US5889943||Mar 29, 1996||Mar 30, 1999||Trend Micro Incorporated||Apparatus and method for electronic mail virus detection and elimination|
|US5951698||Oct 2, 1996||Sep 14, 1999||Trend Micro, Incorporated||System, apparatus and method for the detection and removal of viruses in macros|
|US5956481||Feb 6, 1997||Sep 21, 1999||Microsoft Corporation||Method and apparatus for protecting data files on a computer from virus infection|
|US5960170||Mar 18, 1997||Sep 28, 1999||Trend Micro, Inc.||Event triggered iterative virus detection|
|US5978917||Aug 14, 1997||Nov 2, 1999||Symantec Corporation||Detection and elimination of macro viruses|
|US5987610||Feb 12, 1998||Nov 16, 1999||Ameritech Corporation||Computer virus screening methods and systems|
|US5991881||Nov 8, 1996||Nov 23, 1999||Harris Corporation||Network surveillance system|
|US6052709||Dec 23, 1997||Apr 18, 2000||Bright Light Technologies, Inc.||Apparatus and method for controlling delivery of unsolicited electronic mail|
|US6070244||Nov 10, 1997||May 30, 2000||The Chase Manhattan Bank||Computer network security management system|
|US6072830||Aug 9, 1996||Jun 6, 2000||U.S. Robotics Access Corp.||Method for generating a compressed video signal|
|US6088803||Dec 30, 1997||Jul 11, 2000||Intel Corporation||System for virus-checking network data during download to a client device|
|US6094731||Nov 9, 1998||Jul 25, 2000||Symantec Corporation||Antivirus accelerator for computer networks|
|US6104872||Jun 14, 1996||Aug 15, 2000||Fujitsu Limited||Macro program management system|
|US6108799||Mar 12, 1998||Aug 22, 2000||International Business Machines Corporation||Automated sample creation of polymorphic and non-polymorphic marcro viruses|
|US6167434||Jul 15, 1998||Dec 26, 2000||Pang; Stephen Y.||Computer code for removing junk e-mail messages|
|US6192379||Jun 26, 1998||Feb 20, 2001||British Telecommunications Public Limited Company||Data model compiler selectively using a reference store of labelled program components within a common class|
|US6192512 *||Sep 24, 1998||Feb 20, 2001||International Business Machines Corporation||Interpreter with virtualized interface|
|US6199181||Sep 9, 1998||Mar 6, 2001||Perfecto Technologies Ltd.||Method and system for maintaining restricted operating environments for application programs or operating systems|
|US6275938 *||Aug 28, 1997||Aug 14, 2001||Microsoft Corporation||Security enhancement for untrusted executable code|
|US6338141||Sep 30, 1998||Jan 8, 2002||Cybersoft, Inc.||Method and apparatus for computer virus detection, analysis, and removal in real time|
|US6357008||Sep 23, 1997||Mar 12, 2002||Symantec Corporation||Dynamic heuristic method for detecting computer viruses using decryption exploration and evaluation phases|
|US6370648||Dec 8, 1998||Apr 9, 2002||Visa International Service Association||Computer network intrusion detection|
|US6412071||Apr 28, 2000||Jun 25, 2002||Yona Hollander||Method for secure function execution by calling address validation|
|US6493007||Jul 15, 1998||Dec 10, 2002||Stephen Y. Pang||Method and device for removing junk e-mail messages|
|US6535891||Sep 26, 2000||Mar 18, 2003||Emc Corporation||Method and apparatus for indentifying accesses to a repository of logical objects stored on a storage system based upon information identifying accesses to physical storage locations|
|US6552814||Nov 4, 1998||Apr 22, 2003||Brother Kogyo Kabushiki Kaisha||Print system for executing printing operations based on macros selectively designated on document set basis|
|US6611925||Jun 13, 2000||Aug 26, 2003||Networks Associates Technology, Inc.||Single point of entry/origination item scanning within an enterprise or workgroup|
|US6622150||Dec 18, 2000||Sep 16, 2003||Networks Associates Technology, Inc.||System and method for efficiently managing computer virus definitions using a structured virus database|
|US6678734||Nov 13, 1999||Jan 13, 2004||Ssh Communications Security Ltd.||Method for intercepting network packets in a computing device|
|US6697950||Dec 22, 1999||Feb 24, 2004||Networks Associates Technology, Inc.||Method and apparatus for detecting a macro computer virus using static analysis|
|US6721721||Jun 15, 2000||Apr 13, 2004||International Business Machines Corporation||Virus checking and reporting for computer database search results|
|US6748534||Mar 31, 2000||Jun 8, 2004||Networks Associates, Inc.||System and method for partitioned distributed scanning of a large dataset for viruses and other malware|
|US6763462||Oct 5, 1999||Jul 13, 2004||Micron Technology, Inc.||E-mail virus detection utility|
|US6766458||Oct 3, 2000||Jul 20, 2004||Networks Associates Technology, Inc.||Testing a computer system|
|US6813712||Aug 17, 1999||Nov 2, 2004||International Business Machines Corporation||Viral replication detection using a counter virus|
|US6851057||Nov 30, 1999||Feb 1, 2005||Symantec Corporation||Data driven detection of viruses|
|US6910134||Aug 29, 2000||Jun 21, 2005||Netrake Corporation||Method and device for innoculating email infected with a virus|
|US6941473||Jan 30, 2001||Sep 6, 2005||International Business Machines Corporation||Memory device, stack protection system, computer system, compiler, stack protection method, storage medium and program transmission apparatus|
|US6973577 *||May 26, 2000||Dec 6, 2005||Mcafee, Inc.||System and method for dynamically detecting computer viruses through associative behavioral analysis of runtime state|
|US7134141||Jun 12, 2001||Nov 7, 2006||Hewlett-Packard Development Company, L.P.||System and method for host and network based intrusion detection and response|
|US7213260||Feb 24, 2003||May 1, 2007||Secure Computing Corporation||Systems and methods for upstream threat pushback|
|US7301899||Jan 31, 2001||Nov 27, 2007||Comverse Ltd.||Prevention of bandwidth congestion in a denial of service or other internet-based attack|
|US20020004908||Mar 20, 2001||Jan 10, 2002||Nicholas Paul Andrew Galea||Electronic mail message anti-virus system and method|
|US20020035696||Jun 7, 2001||Mar 21, 2002||Will Thacker||System and method for protecting a networked computer from viruses|
|US20020046275||Jun 12, 2001||Apr 18, 2002||Mark Crosbie||System and method for host and network based intrusion detection and response|
|US20020083175||Aug 14, 2001||Jun 27, 2002||Wanwall, Inc. (A Delaware Corporation)||Methods and apparatus for protecting against overload conditions on nodes of a distributed network|
|US20020091940||Jan 5, 2001||Jul 11, 2002||Welborn Christopher Michael||E-mail user behavior modification system and mechanism for computer virus avoidance|
|US20020157008||Apr 19, 2001||Oct 24, 2002||Cybersoft, Inc.||Software virus detection methods and apparatus|
|US20020162015||Sep 25, 2001||Oct 31, 2002||Zhaomiao Tang||Method and system for scanning and cleaning known and unknown computer viruses, recording medium and transmission medium therefor|
|US20020178374||May 25, 2001||Nov 28, 2002||International Business Machines Corporation||Method and apparatus for repairing damage to a computer system using a system rollback mechanism|
|US20020188870||Jun 11, 2001||Dec 12, 2002||Mcnc||Intrusion tolerant server system|
|US20030014667||Jul 16, 2001||Jan 16, 2003||Andrei Kolichtchak||Buffer overflow attack detection and suppression|
|US20030023865||Jul 26, 2001||Jan 30, 2003||Cowie Neil Andrew||Detecting computer programs within packed computer files|
|US20030051026||Jan 19, 2001||Mar 13, 2003||Carter Ernst B.||Network surveillance and security system|
|US20030065926||Jul 30, 2002||Apr 3, 2003||Schultz Matthew G.||System and methods for detection of new malicious executables|
|US20030115485||Sep 20, 2002||Jun 19, 2003||Milliken Walter Clark||Hash-based systems and methods for detecting, preventing, and tracing network worms and viruses|
|US20030120951||Dec 21, 2001||Jun 26, 2003||Gartside Paul Nicholas||Generating malware definition data for mobile computing devices|
|US20030126449||Dec 28, 2001||Jul 3, 2003||Kelly Nicholas Paul||Controlling access to suspicious files|
|US20030140049||Dec 21, 2001||Jul 24, 2003||Cybersoft, Inc.||Apparatus, methods and articles of manufacture for securing and maintaining computer systems and storage media|
|US20030145232||Jan 31, 2002||Jul 31, 2003||Poletto Massimiliano Antonio||Denial of service attacks characterization|
|US20030191966||Apr 9, 2002||Oct 9, 2003||Cisco Technology, Inc.||System and method for detecting an infective element in a network environment|
|US20030212902 *||May 13, 2002||Nov 13, 2003||Van Der Made Peter A.J.||Computer immune system and method for detecting unwanted code in a P-code or partially compiled native-code program executing within a virtual machine|
|US20030236995||Jun 21, 2002||Dec 25, 2003||Fretwell Lyman Jefferson||Method and apparatus for facilitating detection of network intrusion|
|US20040015712||Oct 4, 2002||Jan 22, 2004||Peter Szor||Heuristic detection of malicious computer code by page tracking|
|US20040015726||Sep 25, 2002||Jan 22, 2004||Peter Szor||Preventing e-mail propagation of malicious computer code|
|US20040030913||Aug 8, 2002||Feb 12, 2004||Trend Micro Incorporated||System and method for computer protection against malicious electronic mails by analyzing, profiling and trapping the same|
|US20040158730||Feb 11, 2003||Aug 12, 2004||International Business Machines Corporation||Running anti-virus software on a network attached storage device|
|US20040162808||Jan 7, 2004||Aug 19, 2004||Permabit, Inc., A Delaware Corporation||Data repository and method for promoting network storage of data|
|US20040181687||Mar 14, 2003||Sep 16, 2004||Nachenberg Carey S.||Stream scanning through network proxy servers|
|US20050021740||Feb 5, 2004||Jan 27, 2005||Bar Anat Bremler||Detecting and protecting against worm traffic on a network|
|US20050044406||Mar 28, 2003||Feb 24, 2005||Michael Stute||Adaptive behavioral intrusion detection systems and methods|
|US20050132205||Dec 12, 2003||Jun 16, 2005||International Business Machines Corporation||Apparatus, methods and computer programs for identifying matching resources within a data processing network|
|US20050177736||Jul 26, 2004||Aug 11, 2005||De Los Santos Aldous C.||System and method for securing computers against computer virus|
|US20050204150||Aug 21, 2004||Sep 15, 2005||Cyrus Peikari||Attenuated computer virus vaccine|
|US20060064755||Sep 21, 2004||Mar 23, 2006||Agere Systems Inc.||Methods and apparatus for interface adapter integrated virus protection|
|DE10021686A1||May 5, 2000||Nov 8, 2001||Thomson Brandt Gmbh||Computer virus distribution minimization method for email network, involves forwarding e-mails according to diagnosed commonality between incoming and outgoing mail of user|
|EP1280039A2||Apr 25, 2002||Jan 29, 2003||Networks Associates Technology Inc.||Detecting e-mail propagated malware|
|GB2364142A||Title not available|
|WO1997039399A2||Mar 28, 1997||Oct 23, 1997||Trend Micro Inc||Apparatus and method for electronic mail virus detection and elimination|
|WO2001091403A2||May 23, 2001||Nov 29, 2001||V N Hermes Inc||Secured electronic mail system and method|
|WO2002005072A2||Jul 6, 2001||Jan 17, 2002||Messagelabs Ltd||Method of and system for, processing email|
|1||"Description of Windows 2000 Windows File Protection Feature (Q222193)", [online], first published May 26, 1999, last modified Jan. 12, 2002, [retrieved on Apr. 9, 2002] Retrieved from the Internet <URL: http://support.microsoft.com/default.aspx?scid=kb:EN-US;q222193>.|
|2||"News Release-Symantec Delivers Cutting-Edge Anti-Virus Technology with Striker32", Oct. 1, 1999, 2 pages, [online]. Retrieved on Nov. 11, 2003. Retrieved from the Internet:<URL:http://www.symantec.com/press/1999/n991001.html>. Author unknown.|
|3||"Software: Windows ME; Windows ME and System File Protection", [online] last updated Mar. 11, 2002, [retrieved on Apr. 9, 2002] Retrieved from the Internet: <URL: http://www.wackyb.co.nz/mesfp.html>.|
|4||"System File Protection and Windows ME", [online], last updated Dec. 4, 2001, [retrieved on Apr. 9, 2002] Retrieved from the Internet: <URL: http://www.Microsoft.com/hwdev/archive/sfp/winME<SUB>-</SUB>sfpP.asp>.|
|5||Bakos et al., "Early Detection of Internet Work Activity by Metering ICMP Destination Unreachable Activity.", Proc. Of SPIE Conference on Sensors, and Command, Control, Communications and Intelligence, Orlando, Apr. 2002.|
|6||Delio, M., "Virus Throttle a Hopeful Defense", Wired News, Dec. 9, 2002, retrieved from the Internet Http://www.wired.com/news/print/0,1294,56753,00.html Jan. 7, 2003.|
|7||Kephart, Jeffrey et al., "An Immune System For Cyberspace" IBM Thomas J. Watson Research Center, IEEE 1997, pp. 879-884.|
|8||Parkhouse, Jayne, "Pelican SafeTNet 2.0", [online] Jun. 2000, SC Magazine Product Review, [retrieved Dec. 1, 2003] Retrieved from the Internet: <URL: http://www.scmagazine.com/standalone/pelican/sc<SUB>-</SUB>pelican.html>.|
|9||Symantec Corporation, "Norton AntiVirus Corporate Edition", 1999, Version 1, pp. 15,22.|
|10||Szor, P. and Ferrie, P., "Hunting for Metamorphic", Virus Bulletin Conference, Sep. 2001, Virus Bulletin Ltd., The Pentagon, Abingdon, Oxfordshire, England, pp. 123-144.|
|11||Szor, P.; Attacks on WIN32, Virus Bulletin Conference, Oct. 1998, pp. 57-84.|
|12||Szor, P.; Attacks on WIN32-Part II, Virus Bulletin Conference, Sep. 2000, pp. 47-68.|
|13||Szor, P.; Memory Scanning Under Windows NT, Virus Bulletin Conference, Sep. 1999, pp. 1-22.|
|14||Toth, et al "Connection-history based anomaly detection" Proceedings of the 2002 IEEE Workshop on Information Assurance and Security. West Point, NY, Jun. 17-19, 2002. pp. 30-35.|
|15||Von Babo, Michael, "Zehn Mythen um Computerviren: Dichtung und Wahrheit über den Schrecken des Informatikzeitalters," Technische Rundschau, Hallwag, Bern, Switzerland, vol. 84, No. 36, Sep. 4, 1992, pp. 44-47.|
|16||Von Babo, Michael, "Zehn Mythnum Computerviren: Dichtug Und Wahrheit Uber Den Schrecken Des Informatkzeitlers," Technische Kundschau, Hallwag, Bern CH vol. 84, No. 36. Sep. 4, 1992, pp. 44-47.|
|17||Wikipedia-"Thread (computer science)," Oct. 12, 2005, [online] [Retrieved on ] Retrieved from the Internet<URL:http://en.wikipedia.org/wiki/Thread<SUB>-</SUB>%28computer<SUB>-</SUB>science%29>.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7603715 *||Mar 30, 2005||Oct 13, 2009||Microsoft Corporation||Containment of worms|
|US7730532 *||Jun 13, 2005||Jun 1, 2010||Symantec Corporation||Automatic tracking cookie detection|
|US8006305||Jun 13, 2005||Aug 23, 2011||Fireeye, Inc.||Computer worm defense system and method|
|US8171553 *||Apr 20, 2006||May 1, 2012||Fireeye, Inc.||Heuristic based capture with replay to virtual machine|
|US8204984||Nov 30, 2007||Jun 19, 2012||Fireeye, Inc.||Systems and methods for detecting encrypted bot command and control communication channels|
|US8255992||Jan 18, 2006||Aug 28, 2012||Webroot Inc.||Method and system for detecting dependent pestware objects on a computer|
|US8291497||Mar 20, 2009||Oct 16, 2012||Symantec Corporation||Systems and methods for byte-level context diversity-based automatic malware signature generation|
|US8291499||Mar 16, 2012||Oct 16, 2012||Fireeye, Inc.||Policy based capture with replay to virtual machine|
|US8375444||Jul 28, 2006||Feb 12, 2013||Fireeye, Inc.||Dynamic signature creation and enforcement|
|US8418245 *||Jan 18, 2006||Apr 9, 2013||Webroot Inc.||Method and system for detecting obfuscatory pestware in a computer memory|
|US8528086||Mar 31, 2005||Sep 3, 2013||Fireeye, Inc.||System and method of detecting computer worms|
|US8539582||Mar 12, 2007||Sep 17, 2013||Fireeye, Inc.||Malware containment and security analysis on connection|
|US8549638||Jun 13, 2005||Oct 1, 2013||Fireeye, Inc.||System and method of containing computer worms|
|US8555392||Jun 19, 2012||Oct 8, 2013||Kaspersky Lab Zao||System and method for detecting unknown packers and cryptors|
|US8561177||Nov 30, 2007||Oct 15, 2013||Fireeye, Inc.||Systems and methods for detecting communication channels of bots|
|US8566946||Mar 12, 2007||Oct 22, 2013||Fireeye, Inc.||Malware containment on connection|
|US8584239||Jun 19, 2006||Nov 12, 2013||Fireeye, Inc.||Virtual machine with dynamic data flow analysis|
|US8635696||Jun 28, 2013||Jan 21, 2014||Fireeye, Inc.||System and method of detecting time-delayed malicious traffic|
|US8776229||Aug 28, 2013||Jul 8, 2014||Fireeye, Inc.||System and method of detecting malicious traffic while reducing false positives|
|US8793787||Jan 23, 2009||Jul 29, 2014||Fireeye, Inc.||Detecting malicious network content using virtual environment components|
|US8832829||Sep 30, 2009||Sep 9, 2014||Fireeye, Inc.||Network-based binary file extraction and analysis for malware detection|
|US8832835 *||Oct 28, 2010||Sep 9, 2014||Symantec Corporation||Detecting and remediating malware dropped by files|
|US8850571||Nov 3, 2008||Sep 30, 2014||Fireeye, Inc.||Systems and methods for detecting malicious network content|
|US8881282||Mar 12, 2007||Nov 4, 2014||Fireeye, Inc.||Systems and methods for malware attack detection and identification|
|US8898788||Mar 12, 2007||Nov 25, 2014||Fireeye, Inc.||Systems and methods for malware attack prevention|
|US8935779||Jan 13, 2012||Jan 13, 2015||Fireeye, Inc.||Network-based binary file extraction and analysis for malware detection|
|US8984638||Nov 12, 2013||Mar 17, 2015||Fireeye, Inc.||System and method for analyzing suspicious network data|
|US8990939||Jun 24, 2013||Mar 24, 2015||Fireeye, Inc.||Systems and methods for scheduling analysis of network content for malware|
|US8990944||Feb 23, 2013||Mar 24, 2015||Fireeye, Inc.||Systems and methods for automatically detecting backdoors|
|US8997219||Jan 21, 2011||Mar 31, 2015||Fireeye, Inc.||Systems and methods for detecting malicious PDF network content|
|US9009822||Feb 23, 2013||Apr 14, 2015||Fireeye, Inc.||Framework for multi-phase analysis of mobile applications|
|US9009823||Feb 23, 2013||Apr 14, 2015||Fireeye, Inc.||Framework for efficient security coverage of mobile software applications installed on mobile devices|
|US9027135||Feb 21, 2007||May 5, 2015||Fireeye, Inc.||Prospective client identification using malware attack detection|
|US9071638||Oct 21, 2013||Jun 30, 2015||Fireeye, Inc.||System and method for malware containment|
|US9104867||Mar 13, 2013||Aug 11, 2015||Fireeye, Inc.||Malicious content analysis using simulated user interaction without user involvement|
|US9106694||Apr 18, 2011||Aug 11, 2015||Fireeye, Inc.||Electronic message analysis for malware detection|
|US9118715||May 10, 2012||Aug 25, 2015||Fireeye, Inc.||Systems and methods for detecting malicious PDF network content|
|US9143518||Feb 22, 2013||Sep 22, 2015||The Trustees Of Columbia University In The City Of New York||Systems, methods, and media protecting a digital data processing device from attack|
|US20060021054 *||Mar 30, 2005||Jan 26, 2006||Microsoft Corporation||Containment of worms|
|US20070168982 *||Jan 18, 2006||Jul 19, 2007||Horne Jefferson D||Method and system for detecting obfuscatory pestware in a computer memory|
|WO2014094441A1 *||Aug 7, 2013||Jun 26, 2014||Huawei Technologies Co., Ltd.||Virus detection method and device|
|U.S. Classification||726/22, 726/24|
|International Classification||G06F12/16, G06F21/00|
|Oct 4, 2002||AS||Assignment|
Owner name: SYMANTEC CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SZOR, PETER;REEL/FRAME:013369/0410
Effective date: 20021001
|Feb 6, 2003||AS||Assignment|
Owner name: SYMANTEC CORPORATION, CALIFORNIA
Free format text: CORRECTIVE DOCUMENT TO CORRECT THE EXECUTION DATE.;ASSIGNOR:SZOR, PETER;REEL/FRAME:013739/0474
Effective date: 20021002
|Nov 11, 2008||CC||Certificate of correction|
|Feb 27, 2012||FPAY||Fee payment|
Year of fee payment: 4