WO2008017950A2

WO2008017950A2 - System and method for protecting a computer from malware (malicious software) in an executable file based on removal criteria

Info

Publication number: WO2008017950A2
Application number: PCT/IB2007/002320
Authority: WO
Inventors: Nadathur S. Baskar
Original assignee: Rudra Technologies Pte Ltd.
Priority date: 2006-08-10
Filing date: 2007-08-10
Publication date: 2008-02-14
Also published as: WO2008017950A3

Abstract

A system and accompanying method of identifying and removing malware on a computer system based on removal criteria. A detection module identifies an executable file that tampers critical files on the computer or comes through email and attempts to access an address book or send or receive data through the internet. If the attempted process meets removal criterion, then the executable file is removed.

Description

SYSTEM AND METHOD FOR PROTECTING A

COMPUTER FROM MALWARE IN AN EXECUTABLE

FILE BASED ON REMOVAL CRITERIA

CROSS REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application Serial Nos.

60/837,140 entitled SYSTEM AND METHOD FOR IDENTIFYING AND REMOVING MALWARE THAT PROPAGATES THROUGH EMAIL; 60/837,343 entitled SYSTEM AND METHOD OF PROTECTING THE LOCAL COMPUTER SYSTEM FROM MALICIOUS CODES BY CREATING A PROTECTIVE SHIELD OVER CRITICAL FILES, and 60/837,344 entitled SYSTEM AND METHOD OF IDENTIFYING AND REMOVING MALWARE THAT IS RECEIVED THROUGH EMAIL BUT DOES NOT PROPAGATE THROUGH EMAIL, the entirety of each of which are incorporated by reference herein.

BRIEF DESCRIPTION OF THE INVENTION

The present invention relates generally to computer security. More particularly, the present invention relates to protecting computer systems from malware, including computer viruses.

BACKGROUND

Malicious software ("malware") is software designed specifically to damage or disrupt a system, such as a virus or a Trojan. Existing technology used to detect and repair computer systems from malware currently comprise either a signature-based or a heuristic logic methodology. Signature-based technology is ineffective when dealing with new viruses since the signature of a new virus remains unknown until it is trapped by an antivirus software company, analyzed and its signature found and incorporated into a software patch. Heuristic logic methodology characterizes the execution pattern or behavior of files. Heuristic logic methods carry only a probability of success and do not provide trouble free identification and elimination of new viruses. A further drawback of heuristic logic methodology is a potential treatment of benign executable code and script as malware, resulting in probability of quarantining or removal of essential executable files.

With the Internet and other networking platforms enabling global and mass communication, the rate at which a new virus can infect computers is exceedingly high since most computers are connected to a network, such as the World Wide Web, leading to a very large number of computers across the world being damaged. What is needed is an anti-malware approach that does not rely on virus signatures or on heuristic logic and yet provides a certainty of 1) identifying new malware and 2) eliminating the responsible malware from the computer system.

SUMMARY OF THE INVENTION

In accordance with the aforementioned needs and shortcomings in the prior art, a system and method for identification and removal of malware is disclosed. As used herein, the indefinite article "a" or "an" and the phrase "at least one" shall be considered, where applicable, to include within its meaning the singular and the plural, that is, "one or more." The system monitors "On Access," i.e., by identifying all the user's action and logs in a source file, as well as by identifying any new file trying to: access to read an email client's address book or email database [e.g. inbox, sent items, outbox); tamper critical files; or send or receive data over the internet. The system applies any number of rules to determine whedier the file is malicious or not. If determined to be malicious, the file is removed, as is described herein. The system removes executable files subsequent to comparison to a source file and upon satisfaction of a removal criterion by those files.

A system for identifying and removing malicious software from a computer system including a processor and memory comprising: an executable file; a detection module; and a removal criterion; wherein said detection module: identifies die executable file; detects if the executable file attempts to access a file or program; determines if the attempted access by the executable file meets the removal criterion; and removes the executable file. The system can further comprise: a source file comprising a user's stored actions, identifying a malware-free state of said computer system.

An executable file can be operatively connected to a related component program; and a detection module can be configured to remove the executable file and the related

2

DOCSNY-262345v02 component program and restore the registry entries if the detection module determines that the executable file meets the removal criterion. The removal criterion may include method of entry software into the local computer system. The system can further comprise a quarantine folder, wherein the executable file is removed to the quarantine folder if the executable file meets the removal criterion. The computer system can further comprise: a handheld computer device, a laptop computer device, a cell-phone, a personal digital assistant; or a desktop computer.

A detection module can be configured to check if the executable file triggers removal criterion and send a pass signal if the executable file matches a pre-validation criterion. The detection module can continue to watch the user action in the local computer system.

The pre-validation criterion can comprise: a criterion where the executable file is effected as a function of user activity. The user activity can comprise a user function, the user function comprising any one or more of: a cut and paste function, a copy and paste function, a drag and drop function, a send to function, a save as function, a setup function, a rename file function, and a software update either by automatic update or manually by user action.

In an embodiment of the present invention, the detection module can be configured to scan the executable file that accesses the address book or reads the email database in the computer system and send a pass signal if the executable file does not access the address book or email database, provided the executable file came to the computer system through email or was created by the setup file which came through email. The removal criterion can comprise: removing the executable file when the executable file accesses the address book or reads the email database in the computer system in read mode. In this event, the detection module will get a notify message when the address book is accessed (in any mode), and will then identify the process (file) doing such access. If the file is created as a result of an incoming email, then the file will be removed. Another method of accessing the address book is not to access the address book file that is physically present in the hard disk, but to find out the location in the RAM where the address book is loaded, and to access that specific location in the RAM

DOCSNY-26234₅v02 and read its contents. In such event also, the detection module will be notified, for taking further action.

The pre-validation criterion can comprise: a criterion where the executable file is a file of the same software of which the address book is a part — for example, if die executable file of Oudook Express software accesses the address book of Oudook

Express software, it will comprise a pre-validated file and be allowed to continue its function unhindered.

In another embodiment, a method of identifying and removing malicious software from a computer system comprising: A) detecting a user action;

B) checking for an executable file accessing the address book or email database; and

C) removing die executable file from the system.

The method can further comprise excepting an executable file from removal if die execution file meets a pre-validation criterion. The method can furdier comprise removing an executable file to a quarantine folder.

In another embodiment of die present invention, the detection module can be configured to die executable file when it accesses a file(s) in the folder containing die operating system files in the computer system and sends a pass signal if die executable file is an auto-update file(s) or setup file(s) or the files created by the setup file in diat session. The setup file may also include un-installation file, which requires the removal of all die files of a particular software. The removal criterion can comprise: removing the executable file when the executable file accesses a files (s) in the operating system folder for deletion or overwriting or appending data of the existing file or renaming the name of die file and is not an auto-update file.

In anodier embodiment, a mediod of identifying and removing malicious software from a computer system comprises:

A) detecting any file accessing an operating system folder;

DOCSNY-262345v02 B) checking if the file accesses an executable file in the operating system folder to delete or overwrite or rename or append.

C) checking if the file is not an auto-update file or setup file

D) checking if the file is not an un-install file and E) removing the executable file from the system.

The method can further comprise excepting an executable file from removal if die execution file meets a pre-validation criterion. The method can further comprise removing an executable file to a quarantine folder.

In another embodiment of the present invention, the detection module can be configured to monitor if an executable file comes through email or if the executable file has been created by a setup file which comes dirough email and 1) attempts to eidier send or receive data through internet; or 2) attempts to tamper the system file(s); or 3) attempts to tamper the self executing file(s) in die computer system. A pass signal is sent if the executable file does not access attempt to send or receive data dirough die internet and does not attempt to tamper the system file(s) and does not attempt to tamper the self executing file(s). The removal criterion can comprise: removing the executable file when the executable file, which came through email, or the executable file that was created by a setup file, which came from email and attempts to send or receive data through the internet or attempts to tamper the system file(s) or attempts to tamper the self executing file(s) in the computer system.

In another embodiment, a method of identifying and removing malicious software from a computer system comprises:

A) detecting a user action;

B) checking for an executable file(s) that sends or receives data through internet;

C) checking for an executable file(s) attempting to tamper with system files;

D) checking for an executable file(s) attempting to tamper self-executing files; and

E) removing an executable file from the system.

DOCSNY-2₆2345v02 The method can further comprise excepting an executable file from removal if the execution file meets a pre-validation criterion. The method can further comprise removing an executable file to a quarantine folder.

A description of a source file as used in conjunction with a detection module is shown in PCT patent application no. PCT/US2005/37539 entitled SYSTEM AND

METHOD FOR IDENTIFYING AND REMOVING MALWARE ON A

COMPUTER SYSTEM, the entirety of this document being incorporated by reference herein.

BRIEF DESCRIPTION OF THE DRAWINGS 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 accompanying drawings, in which:

FIG. 1 is a block diagram illustrating a typical operating environment in which malware is detectable in accordance widi one aspect of the present invention.

FIG. 2 is a flow diagram illustrating a method of the present invention for identification and removal of malware files that attempt to access an address book.

FIG. 3 is a schematic diagram showing the operation in of the overall system in FIG. 2 in determining whether an executable or script file is a malware.

FIG. 4 is a flow diagram illustrating another method of the present invention for identification and removal of malware files that attempt to tamper critical files.

FIG. 5 is a schematic diagram showing the operation in of the overall system in FIG. 4 in determining whether an executable or script file is a malware.

FIG. 6 is a flow diagram illustrating another method of the present invention for identification and removal of malware files that attempt to send or receive data through the internet.

FIG. 7 is a schematic diagram showing the operation in of the overall system in FIG. 6 in determining whether an executable or script file is a malware.

DOCSNY-2₆2345v02 DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a typical operating environment of the present invention on a local computer system. The system 100 on a local computer system comprises a processor 102, memory 104, executable files 106 (e.g., operating system 108, system control files 112, application programs 110, and all other executable files n), source file 122, storage medium 118, user interface 120 and detection module 124. For purposes of illustrating a representative implementation of the system 100, it is to be understood that executable file 106 may include, but is not limited to, any file with a BAT, EXE, COM, or PE extension that is an application or command file. Similarly, executable file 106 may be any file upon which operating system 108 can take action, as for example, a script file such as a WSF, VBS, ASP or JSP file. Executable files 106, as used herein, includes executable files and their components, because, for example, a macro virus can create and infect a DOT, which is file a template for Word, while no new executable is created (e.g., as when the virus Redlof.A replaced a blank.htm with its own file). With regard to the operating system, the entire operating system is tracked for the presence or absence of changes irrespective of whether files are executable type files or not.

The system 100 recognizes that file types of any extension can be made to run as an executable file. The software product can be configured to identify executable files based on the file extensions, or, because a file with any extension can be made to run as an executable file, if the computer system is so modified, the system can be configured to identify executable files by a reading of the file, not merely the file extension so as to distinguish an executable file from a non- executable file. For example, an executable file can be identified by reading the file header. In this process the header (if it exists, since many other types of files may not necessarily have a header) of each file will be read by the system, and if the file header matches the requirements identifying it as an executable file, then the system will identify it as an executable file and begin its process to identify whether the said executable file satisfies removal criteria.

DOCSNY-26234₅v02 The following examples, as applicable fot Microsoft Windows Operating System, demonstrate methods that can be used to identify executable files: "Executable files typically contain a file header at or near the start of the file. This header contains 'magic numbers' that identify the file type. Beyond this header, executable files are typically divided into sections. Each section is characterized by name, permissions (RWX), size, file offset, and virtual address (VMA)." (Executable File Sections, Write Your Own

- Operating System, A Project of the altos. development Usenet Discussion Group, Jan. 7,

2003, available at http://my.execpc.coln/~geezer/osd/exec/). the entirety of which is incorporated by reference herein; "Any executable file must have information the loader expects for an executable file. An executable file must contain Microsoft Windows code and data, or Windows code, data, and resources. Only then will the Windows Operating system recognize it as an executable file." (Executable-File Header Format, Article ID: 65122, Rev. 3.1, Aug. 4 2004, available at http://support.microsoft.com/default.aspx?scid⁼kb;en-us:65122). the entirety of which is incorporated by reference herein. In a similar manner, the executable files can be identified in any operating system by reading the files, and validating whether the file has information contained in it that would make it to qualify as an executable file for any other operating system such as UNIX, Linux etc.

Executable file 106 may be included with an operating system 108, application program 110, and all other executable file types and their related relevant files. A computer user typically communicates with executable file 106 and/or local file via user interface 120, which may comprise a keyboard, monitor, mouse, and/or any peripheral computing device.

Executable file 106 is characterized by file properties 126 a-n and may be .exe, .com, or .bat or other file types. File properties 126 may include file information such as file name, file size, file location, path, file creation time (e.g., date and time), arid any and/or all other file properties that permit characterization and distinction of one executable file from other executable files. System 100 stores file properties 126 of executable file 106 and all odier executables in source file 122 as a fingerprint of the executable file 106. Source file 122 may therefore contain local computer system information like attributes and properties and/or copies of all files a storage medium 118

8

norsNY-2fi2Wvθ₂ including, but not limited to, operating system 108, application program 110, and system control file 112 and their related files. Cumulative fingerprints included in source file 122 therefore provide state information of a local computer system and all associated files, thereby serving as a reference copy for comparison to status of the computer system at some later point. It is assumed that status of the computer system contained in source file 122 is free of viruses, Trojans, and other malware devices.

A general survey of the mechanism of system 100 will now be portrayed. A more detailed review of various embodiments of the mechanism is found in Figures 2 through 7. After boot up, detection module 124 of system 100 reads executable file 106 and operating system 108 and their related files for associated file properties 126. If executable file 106 does not have a corresponding fingerprint in source file 122, then it is validated with reference to removal criterion to determine if it is malware, and if so removed. Various embodiments of removal criterion will be discussed below. If executable file 106 has a correspondingly identical fingerprint in source file 122, then detection module 124 returns a pass signal which is returned to the local computer system. Detection module 124 continues referencing further executable files from the storage medium 118 until all executable files are referenced against a fingerprint in the source file 122. The detection module 124 may perform a recursive scan of the hard disk, searching for executable files 106. As soon as it has reached the next executable file 106, the detection module compares the details of the executable file 106 with the source file 122.

The anti-malware system may be configured to move a file that qualifies for removal to a quarantine folder rather than physically removing the file from the storage, medium 116. The process of quarantining works as follows: a "Quarantine" folder is created in the storage device (which may be named "Quarantine"). The file that needs to be quarantined is moved into this folder (and removed from its original location). The file thus moved is now renamed taking care to ensure that the name of the extension is such that it is not recognized by the Operating System as an executable file (such as .dat). A quarantine folder refers to any data container that can quarantine the removed executable file.

DOCSNY-26234Sv02 As shown, the anti-malware system works by comparing executable files 106 on the hard disk with its relevant information stored in the source file 122. The source file 122 is on the hard disk and the executable file 106 being validated is also in the hard disk. Validation of the executable files 106 with reference to its "trigger points" for automatic execution or removal is also accomplished by reading relevant system files on the hard disk, which may include the registry as well as .ini and other configuration files. The system, for example its detection module 124 can move to the RAM to execute, and system files and other executable files 106 may be present in the RAM as well. Also, the source file 122 can move to the RAM in order for any read /write activity to take place.

The creation of a source file 122 in anti-malware system 100 will now be described. As discussed above, items in memory 104 may include operating system files 108, application programs 110, system control files 112, and other files including executable files 106. Each of said files has file properties; as for example, file properties 126 a-c. The local computer system on which system 100 operates, including files resident therein and their associated components is presumed to be free of malware. Source file 122 retains a database of all file properties of the above files and/or a copy of the files which are moved into storage medium 118. Storage medium 118 may contain, for example, a user's address book or email database. Source file 122 therefore contains local computer system information like attributes and properties and/or copies of all files in including, but not limited to, operating system 108, application program 110 and all other executable files, and a copy of the system control file 112 and their related files.

If an executable file is new (that is, if there is not an existing fingerprint entry in source file 122) and is capable of automatic execution without advertent initiation by a user, and has not been created intentionally by the user, detection module 124 identifies the executable file as malware. The user is notified and the detection module 124 removes the malware file. An executable file that has been installed on a local computer system without prior user intervention that is designed for automatic execution during subsequent booting or program launch is a malware.

Similarly, if any file 106 is capable of automatic execution without specific user initiation but detection module 124 matches the file 106 with a fingerprint in source file

10

DOCSNY-262345v02 122, detection module 124 determines whether there is any change in file 106 and its related files or its properties such as date, time, and other identifying file properties in comparison to the fingerprint in source file 122. If a change in file properties is detected, detection module 124 replaces file 106 with a copy from source file 122, if a copy of the file has been stored. In the event that a copy of die file has not been stored, it will remove the file and notify the user. Because detection module 124 compares file 106 and all associated files, this method can address macro viruses and also other viruses that launch automatically upon user launch of an executable file such as an internet browser or email software, such as script viruses.

In an embodiment of the system, if there is any change in existing executable files

106 or new executables found, and if prior to the detection module 124 discovering diis, the user has specifically indicated his proposed activity of installing new software in die computer system, then the anti-malware system will accept the new executables which are not configured to execute automatically as valid executables and store die information on these executables in source file 122, and confirm widi die user before removing die new executables which are configured to execute automatically upon booting.

In one embodiment, the system may also accept certain kinds of files as user created/pre-validated files, even if the user has not specifically indicated that he or she will be installing new software. These files include files created by the following exemplary activities:

(i) "Cut and Paste," "Copy and Paste," "Drag and Drop," "Send To,"

"Rename" for files which are already present in the source file, and/or of folders containing files which are already present in the source file. (ϋ) "Cut and Paste," "Copy and Paste," "Drag and Drop," "Send To," of files from an external media (for example, remote storage devices such as CD from die CD drive of the local computer system, USB and flash memory devices /drives, or floppy from the floppy drive of the local computer system etc.) whereby it is apparent that these have been created by the user due to the human action of inserting the CD or floppy in the drive, or by inserting the

USB/ flash device.

11

DOCSNY-262345v02 (iϋ) Using the "Save As" command, (it being understood that a User has used the Save As feature to create the new file in the computer system), (iv) Automatic online updates of software existing in the system which are present in the source file, so long as the process responsible for the automatic online updates and creating the new files is present in the source file, without any tampering or changes, and it is clearly identified that the new files created have been created out of the normal activity of this process only.

(v) Files arising out of a "Setup" file, so long as the Setup file is from an external media such as CD, floppy, USB/ flash device, or is already present in the source file, or has been downloaded from the internet and has been validated by the user as a valid file that he has downloaded, either by means of a positive confirmation to the anti-malware system or by using the "Save As" feature described above.

In an embodiment, the system may include a process filter designed to prevent malicious programs from executing, thereby preventing damage to the computer system from the malicious codes. Normally any request for launch by an executable file, such as happens when a user double clicks the file's icon on the desktop, is processed by the operating system and the file is launched to the RAM of the computer system for execution. The system may include a hook, or such other, program that will make the operating system forward all launch requests by any executable file/program to the system, which may approve the process launch request or terminate the request. The system will compare the details of the file creating the launch request with the details present in the source file. If the file's details and the details present in the source file of that file are the same, the process filter will return a pass signal, thus permitting the file to proceed to the RAM for execution. And if the file seeking to launch is not present in the source file, the process filter will terminate the request for launch, and may indicate the termination to the user.

As discussed above, if executable file 106 does not have a corresponding fingerprint in source file 122, then it is validated with reference to removal criterion to determine if it is malware. Alternatively, executable file 106 does not need to be

12

DOCSNY-262345v02 compared to source file 122 to be subject to removal criteria. Removal criterion will now be discussed with reference to FIGS. 2-7.

Referring now to FIG. 2, an embodiment of the present invention, wherein a method 200 for identification and removal of the malware files which attempt to access an address book, is described. In this embodiment, the storage medium 118 contains an address book. If a file received over email or a file created from a setup file received over email, accesses the email software's address book (named .WAB for Outlook Express, for example), such a file is deemed to be a malware or virus and is removed along with its various component files. Alternatively, if the user executes the executable file which is a malware and that executable file accesses an address book, the anti- malware system may be configured to move a file that qualifies for removal to a quarantine folder rather than physically removing the file from the storage medium 118. This is because usually the purpose of the emailed executable file that accesses the address book is to mail itself to all other computers through emails addressed to the addresses found in the address book. Thus, this is an effective method of identifying and removing all viruses that propagate through email.

Detection module monitors die system 202 continuously and stores the actions done by die user in a source file 122 in die local computer system 100. If the user gets an email from a known or unknown source without knowing that the file is malware, die user installs die file 204. Information mat a file originated from email is stored in die source file along widi die file's fingerprint. Here if that file accesses the address book or email database of die user and it is determined that that die file came dirough email, die detection module identifies the file as malware, stops die file from processing 206, deletes or quarantines die file 208 as well as any file diat is extracted by the executable file, and informs die user 210. In diis event, die detection module 202 will get a notify message when the address book is accessed (in any mode), and will then identify die process (file) doing such access 210. If the file is created as a result of an incoming email, dien the file will be removed. Another method of accessing the address book is not to access the address book file that is physically present in the hard disk, but to find out die location in die RAM where the address book is loaded, and to access that specific

13

DOCSNY-262345v02 location in the RAM and read its contents. In such event also, the detection module will be notified, for taking further action.

Turning attention to FIG. 3, a schematic diagram illustrates another aspect of this embodiment. In a local computer system 300 having address book 302 on hard disk 304, an anti-malware system with a detection module 312 is described. The detection module 312 continuously checks the computer system 300 and logs all the action done by the user in the source file 308. When a user stores a file that came by email as a valid file that attempts to access the address book 302, that file is identified as an malware and the detection module 312 quarantines the file and informs the user.

Referring now to FIG. 4, an embodiment of the present invention, wherein a method 400 for identification and removal of the malware files which attempt to tamper critical files on the local computer, is described. If an executable file attempts to tamper critical files, the executable file is deemed to be a malware and is removed along with its various component files. Critical files may include, for example, system files, setup files, self-executing files, auto-update files, and uninstall files. Tampering may include, e.g. deleting, updating, overwriting or inserting any file in a normal mode. The source file contains information on automatic update and uninstall processes of the system. Alternatively, the anti-malware system may be configured to move a file that qualifies for removal to a quarantine folder rather than physically removing the file from the storage medium 118. This is an effective method of identifying and removing viruses that tamper critical files.

Detection module monitors the system continuously and stores the actions done by the user 402 in a source file 122 in the local computer system 100. The detection module detects if a critical file is being opened. It can be notified whether the critical file is opened in a particular mode (e.g. read mode, write mode) with the name of path. Detection module can also detect that a new file is being created in folder containing critical files.

The detection module can detect if the executable file launches an automatic update process. In this case, full rights are given to the autoupdate file and its associated files, and the process is allowed to execute 404. The detection module can detect if the executable file launches a setup process and a new file is being created. If the setup

14

DOCSNY-262345v02 attempts to tamper the critical file, e.g. for overwriting or appending data into an executable file which is not created by that process, it will be considered malware and removed. The detection module can detect if the executable file launches and un- installation process. If the uninstall attempt to tamper the critical file, e.g. for overwriting or appending data into an executable file which is not created by that process, it will be considered malware and removed.

Changes that occur as a result of the executed file are recorded and stored in a database, which moves to the fingerprint database upon completion of the execution. The system removes executable files subsequent to comparison to a source file upon satisfaction of a removal criterion by those files. If any executable file attempts to tamper with a file folder, such as a windows folder, the detection module identifies this file as malware. If tampering that meets the removal criteria is detected, the then the system stops the execution file's access attempt 408, and removes or quarantines this file 410, and informs the user 412. Any changes done in the registry are removed. A separate registry monitor changes done in the registry along with the details of the process at issue.

If the detection module detects that the executable file exists in the source file {i.e., as a fingerprint) and is not an auto-update file, or when it creates a file in windows folder in normal mode or in install mode or modifies only the DIl files in install mode, then the executable file is allowed to process 404 and a pass signal is sent to 406. An executable file may also be allowed to be executed if it meets a pre-validation criteria, even if the executable does not match the fingerprint in the source file. In such event also, the detection module will be notified 412, for taking further action.

Turning to FIG. 5, a schematic diagram illustrates another aspect of the present invention. In a local computer system 500 having executable files 504, and the registry files 506 inside hard disk 508, an anti-malware system with a detection module 512 is described. The detection module 512 continuously checks the computer system 500 and logs all the action done by the user. When any executable file accesses a folder for the purpose of deleting, updating or inserting a file in a normal mode, it is identified as malware and the detection module 512 quarantines the file and informs the user.

15

DOCSNY-26234₅v02 Referring now to FIG. 6, an embodiment of the present invention, wherein a method 600 for identification and removal of the malware files which attempt to send or receive data through the internet, is described. If a file received over email or a file created from a setup file received over email, and accesses the internet, such a file is deemed to be malware or a virus and is removed along with its various component files. Alternatively, if a user executes an executable file which came by email and the executable file which is extracted accesses the internet, the anti-malware system may be configured to move a file that file as it qualifies for removal to a quarantine folder. This is because the purpose the emailed executable file that accesses the internet is to access other malware. Thus, this is an effective method of identifying and removing all viruses that propagate through email.

Detection module monitors the system continuously and stores the actions done by the user 602 in a source file 122 in the local computer system 100. If the user gets an email from the known or unknown source without knowing that the file is malware, the user installs the file 603. Information that a file originated from email is stored in the source file along with the file's fingerprint. Here if the emailed executable file, or its associated files, attempts to send or receive data through the internet, the detection module identifies the file as malware and deletes or quarantines the file 608, as well as any file that is extracted by the executable file, and informs the user 610. In this event, the detection module will get a notify message 610 when the internet is accessed (in any mode), and will then identify the process (file) doing such access. If the file is created as a result of an incoming email, then the file will be removed. If the detection module detects that the executable file did not attempt to send or receive data through the internet, then the executable file is allowed to process 604 and a pass signal is sent to 606. An executable file may also be allowed to be executed if it meets a pre-validation criterion. If the detection module determines that the file did not come by email, then the file is allowed to execute 612 and pass signal 614 is sent.

Turning to FIG. 7, a schematic diagram illustrates another aspect of the present invention. In a local computer system having executable files 704 and registry files 706 on hard disk 708, an anti-malware system 700 with a detection module 712 is described.

The detection module 712 continuously checks the computer system 700 and logs the

16

DOCSNY-262345v02 action done by the user in the user file 702. When a file comes by email and a user stores that file as a valid file, which in turn attempts send or receive data through the internet, the file is identified as malware and the detection module 712 quarantines or deletes the file and informs the user.

While certain embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention. Other embodiments that are apparent to those of ordinary skill in the art, including embodiments that do not provide all of the features and advantages set forth herein, are also within the scope of this invention. By way of example, whereas the aforementioned system is capable of eradicating malware executables, the system adequately addresses macro viruses which infect DOT files associated with templates for .doc files. Additionally, the system addresses any change to an operating system global environment of a local computer system irrespective of whether the changes in file properties are associated with executable files types or not. Because global changes are tracked by comparison of local computer system properties to a source file, the system is independent of the client and platform on which it runs. Therefore, die system is apposite for malware intervention on any platform including Windows OS, Sun UNIX, and the like.

This invention is not limited to the specific construction and arrangements shown and described as various modifications or changes may occur to those of ordinary skill in the art without departing from the spirit and scope of the invention. It should be understood that the above description is only representative of illustrative embodiments.

For the convenience of the reader, the above description has focused on a limited number of representative samples of all possible embodiments, samples that teach the principles of the invention. The description has not attempted to exhaustively enumerate all possible variations or even combinations of those variations described. That alternate embodiments may not have been presented for a specific portion of the invention, or that further undescribed alternate embodiments may be available for a portion, is not to be considered a disclaimer of those alternate embodiments. One of ordinary skill will appreciate that many of those undescribed embodiments, involve differences in technology rather than differences in the application of the principles of the invention. It

17

DOCSNY-262345v02 will be recognized that, based upon the description herein, most of the principles of the invention will be transferable to other specific technology for implementation purposes. This is particularly the case when the technology differences involve different specific hardware and/or software. Accordingly, the invention is not intended to be limited to less than the scope set forth in the following claims and equivalents.

18

DOCSNY-262345v02

Claims

1. A system for identifying malicious software in a computer system, the system comprising: a detection module; and a removal criterion,

wherein said detection module is operable to

identify an executable file,

detect if the executable file attempts to access a file in the computer system, and;

determine if the attempted access by the executable file meets the removal criterion.

2. The system of claim 1, wherein the removal criterion comprises an attempt to tamper said file.

3. The system of claim 2, wherein the attempt to tamper is at least one of an attempt to update, delete, overwrite, append, or rename a file.

4. The system of claim 1 , further comprising allowing the executable file to execute if the executable file is an auto-update file.

5. The system of claim 1, wherein the removal criterion comprises an attempt to overwrite a file in a mode, the mode including: an uninstall mode, a normal mode, or an install mode.

6. The system of claim 1, wherein the executable file comes through e-mail.

7. The system of claim 6, further comprising a user file for storing executable files saved by a user.

8. The system of claim 7, wherein the user file exists in a source file.

19

DOCSNY-262345v02

9. The system of claim 6, wherein the removal criterion comprises an attempt to access an address book in the computer system.

10. The system of claim 6 wherein the access attempt comprises an attempt to access a location in random access memory where the address book is loaded and read the address book's contents.

11. The system of claim 6, wherein the removal criterion comprises an attempt to read an e-mail database in the computer system.

12. The system of claim 6, wherein the removal criterion comprises an attempt to access the internet.

13. The system of claim 6, wherein the removal criterion comprises an attempt to tamper with the computer system's files.

14. The system of claim 6, wherein the removal criterion comprises an attempt to tamper with the computer system's self-executable files.

15. The system of claim 1, further comprising a related component program that is operatively connected to the executable file, wherein the component program is removed if the executable file meets the removal criterion.

16. The system of claim 1, further comprising a quarantine folder, wherein the executable file is removed to the quarantine folder if the executable file meets the removal criterion.

17. The system of claim 1, wherein the detection module generates a notification that the executable file has been removed.

18. The system of claim 1, further comprising a storage medium, wherein the detection module monitors user actions and executable files in the storage medium.

19. The system of claim 1 , wherein the executable file is stored by a user.

20

DOCSNY-262345v02

20. The system of claim 1, further comprising a source file that identifies a malware- free state of the computer system.

21. The system of claim 20, further comprising allowing the executable file to execute if the executable file exists in the source file.

22. The system of claim 1 , further comprising allowing the executable file to execute if the executable file meets a pre-validation criteria.

23. A method for identifying malicious software from a computer system comprising:

identifying an executable file in the computer system;

detecting if the executable file attempts to access a file; and

determining if the attempted access by the executable file meets a removal criterion.

24. The method of claim 23, wherein the removal criterion comprises an attempt to tamper with a file.

25. The method of claim 23, wherein the removal criterion comprises at least one of an attempt to update, delete, overwrite, append, or rename a file.

26. The method of claim 23, wherein the removal criterion comprises an attempt to overwrite a file in a mode, the mode including: an uninstall mode, a normal mode, or a install mode.

27. The method of claim 23, further comprising allowing the executable file to execute if the executable file is an auto-update file.

28. The method of claim 23, wherein the executable file comes through e-mail.

29. The method of claim 28, further comprising storing executable files saved by a user in a user file.

21

DOCSNY-262345v02

30. The method of claim 28, wherein the removal criterion comprises an attempt to access an address book in the computer system.

31. The method of claim 28 wherein the access attempt comprises an attempt to access a location in random access memory where the address book is loaded and read the address book's contents.

32. The method of claim 28, wherein the removal criterion comprises an attempt to read an email database in the computer system.

33. The method of claim 28, wherein the removal criterion comprises an attempt to access the internet.

34. The method of claim 28, wherein the removal criterion comprises an attempt to tamper with the computer system's files.

35. The method of claim 28, wherein the removal criterion comprises an attempt to tamper with die computer system's self-executable files.

36. The method of claim 23, further comprising removing a component program related to die executable file if the executable file meets the removal criterion.

37. The mediod of claim 23, further comprising quarantining die executable file to a quarantine folder if the executable file meets the removal criterion.

38. The method of claim 23, furdier comprising generating a notification that the executable file has been removed.

39. The mediod of claim 23, furdier comprising monitoring user actions and executable files in a storage medium.

40. The mediod of claim 23, wherein the executable file is stored by a user.

41. The method of claim 23, further comprising using a source file that identifies a malware-free state of die computer system.

22

DOCSNY-262345v02

42. The method of claim 41, further comprising allowing the executable file to execute if the executable file exists in the source file.

43. The method of claim 23, further comprising allowing the executable file to execute if the executable file meets a pre-validation criterion.

44. A method for identifying malicious software from a computer system comprising:

receiving an executable file via electronic mail;

storing the executable file in the computer system;

launching the executable file;

detecting if die executable file attempts to access a file; and

determining if die attempted access by the executable file meets a removal criterion, said removal criterion including at least one of accessing the internet, reading an address book, accessing an electronic mail database, or tampering with a file;

stopping said launch of the executable file; and

removing said executable file.

23

DOCSNY-262345v02