US20140181805A1 - System and method for establishing rules for filtering insignificant events for analysis of software program - Google Patents
System and method for establishing rules for filtering insignificant events for analysis of software program Download PDFInfo
- Publication number
- US20140181805A1 US20140181805A1 US13/722,619 US201213722619A US2014181805A1 US 20140181805 A1 US20140181805 A1 US 20140181805A1 US 201213722619 A US201213722619 A US 201213722619A US 2014181805 A1 US2014181805 A1 US 2014181805A1
- Authority
- US
- United States
- Prior art keywords
- events
- event
- insignificant
- rules
- programs
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
Definitions
- the invention relates generally to data processing systems and methods and, more particularly, to generating a set of event filtering rules for filtering events being produced in response to emulation of a program.
- the methods for proactive protection generally involve a code emulator.
- the emulator breaks the program's byte code down to commands and runs each command in a virtual copy of the computer. This allows the protection tool to monitor the program's behavior without endangering the PC's operating system and the user's data.
- emulators can also contain an analytical module, which collects information about the analyzed object, conducts research, uses such research to make conclusions on the potential malicious nature of an object, and puts together detection rules.
- an emulator with an analytical module performs deep analysis using rules for the detection of unknown threats. These rules were previously created by antivirus service providers.
- an emulator can use various ratings.
- a log of events having occurred is formed, which contains both usual events associated with programs known to be safe, as well as suspicious events associated with other, unknown, programs. Based on the analysis of such an event log, during which the detection rules of events and rules of calculating security ratings are used, a final verdict is issued on the examined application indicating its harmfulness.
- insignificant event is an event which is not important from the point of view of behavior during maliciousness risk analysis, because such events will happen during execution of either safe or malicious software. Consequently, insignificant events do not allow accurate determination of whether a particular item of software is dangerous.
- Typical examples of insignificant events are events which will be created during the execution of software written in the Delphi programming language. The execution of such applications can create many typical events found in any program created using Delphi. For example, these can include events that occur in connection with running code that was added during the compilation of the application, e.g., ⁇ startup code>>.
- One challenge in the development of systems for filtering events is the fact that the execution of training rules (whether newly-created, or adapted from previous detection rules for events having occurred) involves the risk of creating a rule that is typical for some legitimate program application, i.e. that will cause false activation of the rule.
- Examples of events from which rule may be falsely triggered are those that typically occur during the execution of an application that was compressed, or encrypted, using specialized security software.
- a typical example of program application is a protector from probing (for example, OSProtector), which can perform many various operations in order to protect the program application from hacking, but this is not an indication of legitimacy or maliciousness of the application, because any application secured by this kind of protector will have such behavior.
- One aspect of the invention is directed generally to a technique and system for preliminary filtration, i.e. by filtration as early as at the stage when the events happen and are entered in the emulation log.
- pre-formed rules for filtration of insignificant events are provided to be used for such preliminary filtration.
- a system for generating a set of event filtering rules for filtering events being produced in response to emulation of a program includes computing hardware, including a processor, a data store, and input/output facilities, and an operating system executable on the computing hardware.
- a sample program creation module is executable on the computing hardware and configured to automatically construct a plurality of sample programs based on a plurality of known program development tools (for example, different compilers and code libraries, or different packers).
- An emulator module is executable on the computing hardware and configured to perform emulated execution of the plurality of sample programs in an isolated virtual machine environment and record events occurring in the virtual machine environment as a result of the emulated execution of the plurality of sample programs in an event log.
- a rule generator module is executable on the computing hardware and configured to automatically formulate a set of rules for distinguishing events from among the event log that are determined to be insignificant with respect to malware detection processing to be performed.
- an event analyzer module is executable on the computing hardware and configured to analyze events in the event log to perform the determination as to whether any of the events are insignificant.
- whitelist and blacklist databases of events associated, respectively, with known non-malicious programs and known malicious programs are employed.
- the insignificant event filtering rules are defined based on previous analysis of events produced from emulation of a plurality known harmless programs and a plurality of known harmful programs, wherein the event filtering rules define insignificant events as those not strongly associated with known harmful activity.
- Another aspect of the invention is directed to a computer-implemented method for generating a set of event filtering rules for filtering events being produced in response to emulation of a program, the method being executed by a computer system having computing resources including a processor, a data store, input/output facilities, and an operating system executable on the processor.
- the method includes: constructing a plurality of sample programs based on a plurality of known program development tools; performing emulated execution of the plurality of sample programs in an isolated virtual machine environment and recording events occurring in the virtual machine environment as a result of the emulated execution of the plurality of sample programs in an event log; and formulating a set of rules for distinguishing events from among the event log that are determined to be insignificant with respect to malware detection processing to be performed.
- a security arrangement for detecting a presence of malware in an unknown program stored in a computer system.
- the security arrangement includes computing hardware, including a processor, a data store, and input/output facilities, and an operating system executable on the computing hardware.
- a performance assessment module is executable on the computing hardware and configured to perform assessment of the unknown program and record, in a local event log, events occurring as a result of the performance assessment of the unknown program.
- An event filtering module is executable on the computing hardware and configured to filter the local event log, based on event filtering rules, to produce a filtered event log that excludes events determined to be insignificant with respect to malware detection processing to be performed.
- An event filtering rules database is implemented in the data store that contains the event filtering rules usable by the event filtering module to identify the insignificant events to be excluded, the event filtering rules being defined based on previous analysis of events produced from emulation of a plurality of sample programs carried out by a remote service, wherein the remote service constructs a plurality of sample programs based on a plurality of known program development tools, performs automated assessment of the plurality of sample programs and records events occurring as a result of the assessment in a remote service event log, and formulates a set of rules for distinguishing events from among the event log that are determined to be insignificant with respect to malware detection processing to be performed.
- the preliminary filtration of a event log created during the emulation of an application reduces its size by finding and deleting insignificant events.
- One of technical outcomes of this invention relates to improving the quality of the analysis of a event log built during emulation of applications, which is achieved through preliminary filtration of insignificant events in the specified log using the created rules for filtration of insignificant events.
- FIGS. 1A , 1 B, and 1 C are block diagrams illustrating examples of a systems for generating rules for filtration of insignificant events according to various embodiments of the invention.
- FIG. 1D is a diagram that illustrates an example of a client-side PC that conducts analysis of an unknown program and performs malware assessment based on a filtered event log from the performance assessment according to an exemplary embodiment.
- FIG. 2 illustrates a sample diagram of the operation of an analyzer when building rules for filtration of insignificant events according to one embodiment.
- FIG. 3 illustrates a process for generating rules for filtration of insignificant events according to one embodiment.
- FIG. 4 illustrates an example process for generating rules for filtration of insignificant events utilizing whitelists and blacklists according to one embodiment.
- FIG. 5 illustrates exemplary limits for distinguishing between significant and insignificant events during analysis of events logs according to one embodiment.
- FIG. 6 is a block diagram of a a general-purpose computer system in which embodiments of this invention can be realized.
- aspects of the present invention can be implemented as part of a computer system.
- the computer system can be one physical machine, or can be distributed among multiple physical machines, such as by role or function, or by process thread in the case of a cloud computing distributed model.
- aspects of the invention can be configured to run in virtual machines that in turn are executed on one or more physical machines. It will be understood by persons of skill in the art that features of the invention may be realized by a variety of different suitable machine implementations.
- module means a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device.
- ASIC application specific integrated circuit
- FPGA field-programmable gate array
- a module can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software.
- at least a portion, and in some cases, all, of a module can be executed on the processor(s) of one or more general purpose computers (such as the one described in greater detail below) that execute an operating system, system programs, and application programs, while also implementing the module using multitasking, multithreading, distributed (e.g., cloud) processing, or other such techniques.
- each module can be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.
- FIG. 1A , FIG. 1B and FIG. 1C systems for building rules for filtration of insignificant events (IEs) are depicted in FIG. 1A , FIG. 1B and FIG. 1C .
- An application emulator is usually a part of an antivirus tool, which, when checking software, performs a search for unknown malicious objects on user PCs.
- An executable file can be considered as an object, for example, [name].exe. Before this file is it is run, it is checked (i.e., audited) with an application emulator.
- the application emulator breaks the application's byte code down to commands, and then it runs each command in a virtual computing environment, such as a virtual machine representing a copy of the actual computer system. This allows monitoring the behavior of the application.
- events are created, which, after preliminary analysis, will be entered in the event log for subsequent analysis (for detection of malicious application).
- rules for filtration of insignificant events are applied on the user PC's side.
- An insignificant event is an event which is not meaningful from the point of view of analysis of the maliciousness the behavior of a program because such event will happen during the execution of either safe or malicious program applications. Consequently, such events do not contribute meaningfully to the accurate determination of the benign/malicious nature of an application. Moreover, such events are not only useless for the analysis of emulation event logs, but also detrimental, because they increase the size of the emulation event log by tens or hundreds of times, which complicates detection of malicious actions and burdens the available computing resources, thus causing increased processing time, reduced system responsiveness, etc. It should be also noted that insignificant events affect the building of rules for analyzing event logs during emulation, because such rules can be created on the basis of an insignificant event, which can adversely affect the accuracy of the analysis based on such rules.
- examples of insignificant events include:
- systems for filtering events from event logs to be formed and analyzed in assessing software can be used with other tools for assessing performance of software.
- disassembler and tracer tools can be used in lieu of an emulator.
- a combination of such tools is contemplated.
- the embodiments detailed herein are presented in the context of use of an emulator as the software performance assessment tool.
- FIG. 1A is a block diagram illustrating a system for generating rules for filtration of insignificant events.
- the system for generating rules for filtration of IEs 100 interacts with an antivirus service 101 .
- An example of an antivirus service 101 can be the Kaspersky® Security Network service.
- Antivirus service 101 can be placed either on a server or on one of user PCs 180 a - 180 n .
- the antivirus service 101 contains various information on the software produced by developer companies, such as Microsoft®, and later operating on user PCs 180 a - 180 n . All information on various programs is stored in relevant knowledge bases, such as information databases 110 a - 110 n , for example.
- Information databases 110 a - 110 n can be located either separately (on the antivirus service 101 ) from other tools of the system 100 , or together.
- Information contained in the information databases 110 a - 110 n can consist in the application (file) itself, or in any information about them—for example, application metadata, parts of a program code, the application's hash sum, etc.
- the information databases 110 a - 110 n are built by application types; for example, a database of compilers 110 a , a database of packers 110 b (applications for compression of an executable file), a database of protectors/encryptors 110 c (applications for compression and encryption of an executable file), a database of archivers, etc.
- the system generating rules for filtration of IEs 100 requests data from databases 110 a , 110 b , 110 c , . . . , 110 n on the compilers, packers, protectors and other programs contained in them, which are sent to the sample program creation module 120 .
- the information that will be transferred can be the executable file of the compiler, packer, protector, etc., or the path to that executable file.
- the sample program creation module 120 processes the received information (for example, executable file of the compiler) and uses it to build a sample program 125 , which is sent to the emulator 130 .
- the created sample program 125 is a simplest application which does not carry out any particular functionality, but serves mainly for analyzing the behavior (e.g., defining events) of the application which was used to launch it.
- each compiler from the 110 a database has a standard list of events, which will be executed during the execution of the applications created (e.g., compiled) using relevant compiler.
- the following application is an example of a simplest application created using a compiler for the Delphi programming language:
- the sample program 125 will be an application created (i.e., written) in any programming language, and in this case it will be compressed by a relevant packer or protector, information on which was provided to the module 120 .
- the emulator 130 performs emulation of the obtained sample program 125 , during which it records all created events in the events log 135 .
- the emulation of the sample program 125 means breaking its program code down to instructions and imitating their execution. Then, the emulator 130 sends the built event log 135 to the analyzer 140 .
- a filtration rule is a Boolean characteristic and contains a name of an API function and masks for its arguments (a number of arguments from 1 to N). Each argument of the mask can adopt the following values:
- the analyzer 140 on the basis of created rules for filtration of insignificant events, builds a batch of rules 145 , which it then sends to the database of rules for filtration of IEs 160 .
- the database of rules for filtration of IEs 160 adds the received batch of rules 145 to the table of rules for filtration of insignificant events for subsequent storage. Once the batch of rules 145 is added to the database 160 , the version of the database is changed and sent to the update module 165 .
- Table 1 below is an example of a set of rules for filtration of insignificant events:
- API_FUNCT contains names of API functions
- ARG1, ARG2, . . . , ARGN contain arguments of functions
- the system for generating rules for filtration of IEs 100 will provide the rules for filtration of IEs from the database of rules for filtration of IEs 160 to the antivirus tools existing on user PCs 180 a , 180 b , . . . , 180 n , if a request is received from these antivirus tools.
- all interactions between the system for generating rules for filtration of IEs 100 and the user PCs 180 a , 180 b , . . . , 180 n pass through the Internet network 170 .
- the interaction between the database of rules for filtration of IEs 160 and the user PCs 180 a , 180 b , . . . , 180 n happens through an update module 165 .
- the update module 165 contains a current version of the database 160 .
- the update module 165 will compare the received version of the database with its own version of the database 160 . If the versions coincide, the antivirus tools on the user PCs 180 a , 180 b , . . .
- the batches will contain all filtration rules created after the provided version of the database of rules from the user PCs 180 a , 180 b , . . . , 180 n . Then, the batch 175 will be sent to the antivirus tools on user PCs 180 a , 180 b , . . . , 180 n.
- FIG. 1B shows another example embodiment of a system for generating rules for filtration of insignificant events.
- the system for generating rules for filtration of IEs 100 contains only an analyzer 140 , a database of rules for filtration of IEs 160 and an update module 165 , and interacts with an antivirus service 101 .
- the antivirus service 101 contains two databases, 150 a and 150 b .
- the 150 a database contains event logs BL 152 , which were built during emulation of only malicious applications.
- the 150 b database contains event logs WL 154 , which were built only during emulation of safe applications.
- the analyzer 140 requests from databases 150 a and 150 b all event logs BL 152 and WL 154 contained in the above databases at the time of the request. Then, the analyzer 140 analyzes all received event logs 152 and 154 , upon which it builds a list of insignificant events 270 (the structure of analyzer 140 is depicted in FIG. 2 ).
- the list of insignificant events 270 contains events encountered both in the event logs BL 152 and in the event logs WL 154 . All events entered in the above list 270 are insignificant events.
- the analyzer 140 on the basis of each event from the built list of insignificant events 270 , creates a rule for filtration of IEs. Then, all created rules for filtration of IEs are sent to the database of rules for filtration of IEs 160 in the form of a batch of rules 145 .
- the database of rules for filtration of IEs 160 adds the received batch of rules 145 to the table of rules for filtration of insignificant events for subsequent storage and transfer to user PCs 180 , if a request is received from them. All interactions between the system for generating rules for filtration of IEs 100 and the user PCs 180 take place through the update module 165 , which, in turn, interacts with the user PCs 180 through the Internet network 170 .
- FIG. 1C Another example of an embodiment of a system for generating rules for filtration of insignificant events is presented in FIG. 1C .
- the embodiment of a system for generating rules for filtration of IEs shown in FIG. 1C combines the approaches shown in FIG. 1A and FIG. 1B .
- the analyzer 140 performs verification of each event from the event log 135 received from the emulator 130 for their correspondence to the insignificant event. The verification will happen using the list of safe events 260 and the list of malicious events 250 ( FIG. 2 ).
- the above lists will be built by the analyzer 140 during the analysis of the event logs 152 and 154 from the 150 a and 150 b databases, together with the list of events 270 , as shown in FIG. 1B .
- the analyzer 140 will compare each event from the event log 135 with the built lists of events 250 and 260 .
- the analyzer 140 builds a filtration rule based on this event.
- One rules are built based on the events which have passed the verification, the analyzer 140 builds a batch of rules 145 , which is sent to the database of rules for filtration of IEs 160 .
- the system for generating rules for filtration of IEs 100 can be placed on one of the users' PCs 180 a - 180 n , which will form the new filtration rules for the IEs. Subsequently, the system 100 generates a set of rules 175 from among the new filtration rules and provide it to the appropriate anti-virus programs for users 180 a - 180 n via the Internet 170 .
- FIG. 1D illustrates an example of a client-side PC 180 that conducts analysis of an unknown program and performs malware assessment based on a filtered event log from the performance assessment according to an exemplary embodiment.
- PC 180 includes tracing module 182 , which in various embodiments can be an emulator, de-compiler, tracing tool, etc. Tracing module 182 executes or otherwise examines the unknown program, which can be performed in an isolated virtual execution environment, for example.
- the performance assessment produces event log 184 , which normally includes mostly insignificant events insofar as malware analysis is concerned.
- filter 186 removes insignificant events from the event log.
- Insignificant event filtering rules database 188 is updated via event filtering rules update module 190 , which is communicatively coupled to a remote service 195 .
- Remote service 195 can include an arrangement such as any of those depicted in FIGS. 1A-1C .
- Remote service 195 provides regular updates of rules for filtration of insignificant events, which can be provided in batches such as batch 175 .
- the rules are stored in database 188 , which is read by filter 186 to perform the filtering operation.
- Malware analyzer module 192 reads the filtered event log, and performs any one or more of a variety of actions to assess the risk of the unknown program (e.g., whether the unknown program is harmful or benign). These actions can include comparisons of events against patterns of known malicious patterns or benign patterns, heuristic analyses, analysis using artificial neural network technology, fuzzy logic analysis, etc. Any suitable malware detection technique now known, or later developed, is contemplated for use with aspects of the invention.
- FIG. 2 illustrates an example of a diagram of the operation of the analyzer 140 when building rules for filtration of IEs.
- the analyzer 140 includes a module for analysis of event logs 210 (hereinafter referred to as analysis module 210 ), a module for comparative analysis of event logs and for building lists of events 230 (hereinafter referred to as comparative analysis module 230 ) and a module for building rules for filtration of insignificant events 290 (hereinafter referred to as filtration rules module 290 ).
- Analysis module 210 is designed to analyze an event log 135 received from the emulator 130 and to provide all insignificant events to filtration rules module 290 in the form of a list of insignificant events 280 . Analysis module 210 also performs preliminary verification (as described in the description of FIG. 1 c ) of all events from the log 135 , using the list of malicious events 250 and the list of safe events 260 , received from comparative analysis module 230 .
- Comparative analysis module 230 is designed to analyze the event logs BL 152 and the event logs WL 154 , received from the databases 150 a and 150 b , stored on the antivirus service 101 . On the basis of the performed analysis, comparative analysis module 230 builds three lists of events: a list of malicious events 250 , a list of safe events 260 and a list of insignificant events 270 . Then, comparative analysis module 230 provides lists 250 and 260 to analysis module 210 and provides list 270 to filtration rules module 290 .
- Filtration rules module 290 is designed to:
- filtration rules module 290 checks the built rules for filtration of IEs for their presence in the database of rules of filtration of IEs 160 . In case if the built rules for filtration of IEs are found in the database 160 , the rules will not be added to the database 160 , but instead they will be deleted.
- FIG. 5 illustrates in more detail an example set of criteria (e.g., limits) for selection of insignificant events during the analysis of events from the 152 and 154 event logs.
- criteria e.g., limits
- the event detection ratio was 30%/70% or less for the event logs WL 152 , i.e. the event was detected from 0% to 30% in the event logs WL 152 , and from 70% to 100% in the event logs BL 154 .
- the event is a suspicious event and it will be added to the list of malicious events 250 .
- the event detection ratio was 30%/70% or more for the event logs WL 152 , but not more than 70%, i.e. the event was detected from 30% to 70% in the event logs WL 152 and from 70% to 30% in the event logs BL 154 .
- the event is an insignificant event and it will be added to the list of insignificant events 270 .
- the event detection ratio was 70%/30% or more for the event logs WL 152 , i.e. the event was detected from 70% to 100% in the event logs WL 152 and from 30% to 0% in the event logs BL 154 .
- the event is a potentially safe event and it will be added to the list of safe events 260 .
- FIG. 3 depicts a machine-implemented process which can be used to implement a system for generating rules for filtration of insignificant events.
- the system for generating rules for filtration of IEs 100 sends a request for presence of new data for the databases from the list of databases 110 a , 110 b , 110 c , . . . , 110 n .
- the request can be sent either to all databases 110 a , 110 b , 110 c , . . . , 110 n at once, or successively.
- the databases 110 a , 110 b , 110 c , . . . , 110 n send all data (or information) which they store on the objects (compilers, protectors, packers, etc.) to the system for generating rules for filtration of IEs 100 , and namely to the sample program creation module 120 .
- the data or information contained in the databases 110 a , 110 b , 110 c , . . . , 110 n may be the application itself (i.e., the file) and any data or information about it, for example, application metadata, one of more portions of the code, its hash, checksum, etc.
- the sample program creation module 120 checks the received data for up-to-dateness.
- the check of data for up-to-dateness can consist in the building of a hash sum for each set of data on each received object.
- the built hash sum is compared with the list of previously created hash sums, which is stored in the sample program creation module 120 . In case if the built hash sum is found in the list of hash sums, the built hash sum is not new, and the module 120 will delete all data which was used to build the hash sum. In case if the built hash sum is not found in the list of hash sums, the built hash sum is new and will be added to the specified list of hash sums, while the data used to build the hash sum will be sent to block 320 .
- a sample program 125 is built based on the data received with the help of the module 120 .
- the module 120 sends the sample program 125 to the emulator 130 for subsequent analysis.
- the emulator 130 is run, and at 330 , the sample program 125 is emulated.
- a event log 135 is built, where the emulator 130 records all performed actions (the events which took place) of the sample program 125 .
- the built event log 135 is sent to the analyzer 140 , which verifies it in order to detect insignificant events. The verification is performed by comparing the events from the event log with the events from the lists 250 and 260 .
- the analyzer 140 builds rules for filtration based on the events from the received list 280 .
- the building of rules for filtration of insignificant events happens as shown in FIG. 1 a .
- the built rules are added to the database of rules for filtration of IEs 160 for subsequent storage, pre-built in the form of a batch of rules 145 .
- FIG. 4 depicts a machine-implemented process for generation of rules for filtration of insignificant events.
- the analyzer 140 receives at least one event log BL 152 from database 150 a , and at least one event log WL 154 from database 150 b .
- the analyzer 140 compares all received event logs and detects the events encountered both in BL 152 and in WL 154 .
- the analyzer 140 builds a list of events from the events which were included in both types of lists. Based on this list of events, the analyzer 140 at 460 builds rules for filtration of IEs.
- the database 160 will add the rules for filtration of IEs from the received batch of rules 145 to the table of rules for filtration of insignificant events for subsequent storage.
- FIG. 6 is a diagram illustrating in greater detail a computer system 600 on which aspects of the invention as described herein may be implemented according to various embodiments.
- the computer system 600 may include a computing device such as a personal computer 602 .
- the personal computer 602 includes one or more processing units 604 , a system memory 606 , a video interface 608 , an output peripheral interface 610 , a network interface 612 , a user input interface 614 , removable 616 and non-removable 618 memory interfaces and a system bus or high-speed communications channel 620 coupling the various components.
- the processing units 604 may have multiple logical cores that are able to process information stored on computer readable media such as the system memory 606 or memory attached to the removable 616 and non-removable 618 memory interfaces 618 .
- the computer 602 system memory 606 may include non-volatile memory such as Read Only Memory (ROM) 622 or volatile memory such as Random Access Memory (RAM) 624 .
- the ROM 622 may include a basic input/output system (BIOS) 626 to help communicate with the other portion of the computer 602 .
- the RAM 624 may store portions of various software applications such as the operating system 628 , application programs 630 and other program modules 632 . Further, the RAM 624 may store other information such as program or application data 634 .
- the RAM 624 stores information that requires low-latencies and efficient access, such as programs and data being manipulated or operated on.
- RAM 624 comprises Double Data Rate (DDR) memory, Error Correcting memory (ECC) or other memory technologies with varying latencies and configurations such as RAMBUS or DDR2 and DDR3.
- DDR Double Data Rate
- ECC Error Correcting memory
- the system memory 606 may store the input data store, access credential data store, operating memory data store, instruction set data store, analysis result data store and the operating memory data store.
- the processing units 604 may be configured to execute instructions that limit access to the aforementioned data stores by requiring access credential before access to the information is granted.
- the removable 616 and non-removable 618 memory interfaces may couple the computer 602 to disk drives 636 such as SSD or rotational disk drives. These disk drives 636 may provide further storage for various software applications such as the operating system 638 , application programs 640 and other program modules 642 . Further, the disk drives 636 may store other information such as program or application data 644 . In various embodiments, the disk drives 636 store information that doesn't require the same low-latencies as in other storage mediums. Further, the operating system 638 , application program 640 data, program modules 642 and program or application data 644 may be the same information as that stored in the RAM 624 in various embodiments mentioned above or it may be different data potentially derivative of the RAM 624 stored data.
- disk drives 636 such as SSD or rotational disk drives.
- These disk drives 636 may provide further storage for various software applications such as the operating system 638 , application programs 640 and other program modules 642 . Further, the disk drives 636 may store other information such as program or application data 644 .
- the removable non-volatile memory interface 616 may couple the computer 602 to magnetic portable disk drives 646 that utilize magnetic media such as the floppy disk 648 , Iomega® Zip or jazz, or optical disk drives 650 that utilize optical media 652 for storage of computer readable media such as Blu-Ray®, DVD-R/RW, CD-R/RW and other similar formats. Still other embodiments utilize SSD or rotational disks housed in portable enclosures to increase the capacity of removable memory.
- the computer 602 may utilize the network interface 612 to communicate with one or more remote computers 656 over a local area network (LAN) 658 or a wide area network (WAN) 660 .
- the network interface 612 may utilize a Network Interface Card (NIC) or other interface such as a modem 662 to enable communication.
- the modem 662 may enable communication over telephone lines, coaxial, fiber optic, powerline, or wirelessly.
- the remote computer 656 may contain a similar hardware and software configuration or may have a memory 664 that contains remote application programs 666 that may provide additional computer readable instructions to the computer 602 .
- the remote computer memory 664 can be utilized to store information such as identified file information that may be later downloaded to local system memory 606 .
- the remote computer 656 may be an application server, an administrative server, client computers, or a network appliance.
- a user may enter information to the computer 602 using input devices connected to the user input interface 614 such as a mouse 668 and keyboard 670 .
- the input device may be a trackpad, fingerprint scanner, joystick, barcode scanner, media scanner or the like.
- the video interface 608 may provide visual information to a display such as a monitor 672 .
- the video interface 608 may be an embedded interface or it may be a discrete interface.
- the computer may utilize a plurality of video interfaces 608 , network interfaces 612 and removable 616 and non-removable 618 interfaces in order to increase the flexibility in operation of the computer 602 .
- various embodiments utilize several monitors 672 and several video interfaces 608 to vary the performance and capabilities of the computer 602 .
- Other computer interfaces may be included in computer 602 such as the output peripheral interface 610 . This interface may be coupled to a printer 674 or speakers 676 or other peripherals to provide additional functionality to the computer 602 .
- the processing unit 604 may include an embedded memory controller (not shown) to enable more efficient transfer of data from the system memory 606 than the system bus 620 may provide.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
- The invention relates generally to data processing systems and methods and, more particularly, to generating a set of event filtering rules for filtering events being produced in response to emulation of a program.
- Currently, the spread of malicious software is increasing every day, as does the damage caused by such software to users' personal computers. The existing methods for protecting personal computers and computers in a corporate network are designed to discover both known and unknown threats. The methods for protection from known threats (for example, viruses, worms, Trojans, and general vulnerabilities) are usually based on signature scanning, which uses code templates obtained from known malicious programs for subsequent verification of objects. In addition, related approaches for protection from known threats include: the “white lists” technology, which uses templates of known trusted programs; the “black lists” technology; systems for verification of check sums, of metadata, etc. However, the rate with which new malicious software appears is constantly rising, which leads to an ever-increasing role for proactive protection technologies that work to the benefit of users. The methods for proactive protection generally involve a code emulator. The emulator breaks the program's byte code down to commands and runs each command in a virtual copy of the computer. This allows the protection tool to monitor the program's behavior without endangering the PC's operating system and the user's data.
- Today, such emulators can also contain an analytical module, which collects information about the analyzed object, conducts research, uses such research to make conclusions on the potential malicious nature of an object, and puts together detection rules. Usually, an emulator with an analytical module performs deep analysis using rules for the detection of unknown threats. These rules were previously created by antivirus service providers. When examining applications, an emulator can use various ratings. During the emulation of applications for subsequent analysis/research, a log of events having occurred is formed, which contains both usual events associated with programs known to be safe, as well as suspicious events associated with other, unknown, programs. Based on the analysis of such an event log, during which the detection rules of events and rules of calculating security ratings are used, a final verdict is issued on the examined application indicating its harmfulness.
- Today, there are various methods for filtering event logs. Usually, filtration is used in order to obtain required data from the log, depending on required criteria. However, known technologies do not effectively solve one of the main log analysis problems, namely, the fact that the analysis is very time-consuming because the event log oftentimes has grown to a colossal size during emulation, which can amount to be on the order of a million lines. Another problem has to do with making a decision during analyzing of such logs—the events which are significant for issuing a verdict become diluted among the huge number of insignificant ones.
- An insignificant event is an event which is not important from the point of view of behavior during maliciousness risk analysis, because such events will happen during execution of either safe or malicious software. Consequently, insignificant events do not allow accurate determination of whether a particular item of software is dangerous. Typical examples of insignificant events are events which will be created during the execution of software written in the Delphi programming language. The execution of such applications can create many typical events found in any program created using Delphi. For example, these can include events that occur in connection with running code that was added during the compilation of the application, e.g., <<startup code>>.
- One challenge in the development of systems for filtering events is the fact that the execution of training rules (whether newly-created, or adapted from previous detection rules for events having occurred) involves the risk of creating a rule that is typical for some legitimate program application, i.e. that will cause false activation of the rule. Examples of events from which rule may be falsely triggered, are those that typically occur during the execution of an application that was compressed, or encrypted, using specialized security software. A typical example of program application is a protector from probing (for example, OSProtector), which can perform many various operations in order to protect the program application from hacking, but this is not an indication of legitimacy or maliciousness of the application, because any application secured by this kind of protector will have such behavior.
- In view of the above, a solution is needed to improve event log filtering specifically for malware analysis that can be performed locally on a distributed plurality of user computer systems.
- One aspect of the invention is directed generally to a technique and system for preliminary filtration, i.e. by filtration as early as at the stage when the events happen and are entered in the emulation log. According to one approach, pre-formed rules for filtration of insignificant events are provided to be used for such preliminary filtration.
- A system for generating a set of event filtering rules for filtering events being produced in response to emulation of a program according to one embodiment includes computing hardware, including a processor, a data store, and input/output facilities, and an operating system executable on the computing hardware. A sample program creation module is executable on the computing hardware and configured to automatically construct a plurality of sample programs based on a plurality of known program development tools (for example, different compilers and code libraries, or different packers). An emulator module is executable on the computing hardware and configured to perform emulated execution of the plurality of sample programs in an isolated virtual machine environment and record events occurring in the virtual machine environment as a result of the emulated execution of the plurality of sample programs in an event log. A rule generator module is executable on the computing hardware and configured to automatically formulate a set of rules for distinguishing events from among the event log that are determined to be insignificant with respect to malware detection processing to be performed.
- Optionally, an event analyzer module is executable on the computing hardware and configured to analyze events in the event log to perform the determination as to whether any of the events are insignificant. Optionally, in a related embodiment, whitelist and blacklist databases of events associated, respectively, with known non-malicious programs and known malicious programs, are employed. In a related embodiment, the insignificant event filtering rules are defined based on previous analysis of events produced from emulation of a plurality known harmless programs and a plurality of known harmful programs, wherein the event filtering rules define insignificant events as those not strongly associated with known harmful activity.
- Another aspect of the invention is directed to a computer-implemented method for generating a set of event filtering rules for filtering events being produced in response to emulation of a program, the method being executed by a computer system having computing resources including a processor, a data store, input/output facilities, and an operating system executable on the processor. The method includes: constructing a plurality of sample programs based on a plurality of known program development tools; performing emulated execution of the plurality of sample programs in an isolated virtual machine environment and recording events occurring in the virtual machine environment as a result of the emulated execution of the plurality of sample programs in an event log; and formulating a set of rules for distinguishing events from among the event log that are determined to be insignificant with respect to malware detection processing to be performed.
- In a related aspect of the invention, a security arrangement is provided for detecting a presence of malware in an unknown program stored in a computer system. The security arrangement includes computing hardware, including a processor, a data store, and input/output facilities, and an operating system executable on the computing hardware. A performance assessment module is executable on the computing hardware and configured to perform assessment of the unknown program and record, in a local event log, events occurring as a result of the performance assessment of the unknown program. An event filtering module is executable on the computing hardware and configured to filter the local event log, based on event filtering rules, to produce a filtered event log that excludes events determined to be insignificant with respect to malware detection processing to be performed. An event filtering rules database is implemented in the data store that contains the event filtering rules usable by the event filtering module to identify the insignificant events to be excluded, the event filtering rules being defined based on previous analysis of events produced from emulation of a plurality of sample programs carried out by a remote service, wherein the remote service constructs a plurality of sample programs based on a plurality of known program development tools, performs automated assessment of the plurality of sample programs and records events occurring as a result of the assessment in a remote service event log, and formulates a set of rules for distinguishing events from among the event log that are determined to be insignificant with respect to malware detection processing to be performed.
- Advantageously, the preliminary filtration of a event log created during the emulation of an application, reduces its size by finding and deleting insignificant events. One of technical outcomes of this invention relates to improving the quality of the analysis of a event log built during emulation of applications, which is achieved through preliminary filtration of insignificant events in the specified log using the created rules for filtration of insignificant events.
- The invention may be more completely understood in consideration of the following detailed description of various embodiments of the invention in connection with the accompanying drawings, in which:
-
FIGS. 1A , 1B, and 1C are block diagrams illustrating examples of a systems for generating rules for filtration of insignificant events according to various embodiments of the invention. -
FIG. 1D is a diagram that illustrates an example of a client-side PC that conducts analysis of an unknown program and performs malware assessment based on a filtered event log from the performance assessment according to an exemplary embodiment. -
FIG. 2 illustrates a sample diagram of the operation of an analyzer when building rules for filtration of insignificant events according to one embodiment. -
FIG. 3 illustrates a process for generating rules for filtration of insignificant events according to one embodiment. -
FIG. 4 illustrates an example process for generating rules for filtration of insignificant events utilizing whitelists and blacklists according to one embodiment. -
FIG. 5 illustrates exemplary limits for distinguishing between significant and insignificant events during analysis of events logs according to one embodiment. -
FIG. 6 is a block diagram of a a general-purpose computer system in which embodiments of this invention can be realized. - While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
- Aspects of the present invention can be implemented as part of a computer system. The computer system can be one physical machine, or can be distributed among multiple physical machines, such as by role or function, or by process thread in the case of a cloud computing distributed model. In various embodiments, aspects of the invention can be configured to run in virtual machines that in turn are executed on one or more physical machines. It will be understood by persons of skill in the art that features of the invention may be realized by a variety of different suitable machine implementations.
- In the system block diagrams, such as those depicted in
FIGS. 1A-1C , various modules are represented, such asanalyzer 140,emulator 130, sampleprogram creation module 120, andupdate module 165. The term “module” as used herein means a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module can be executed on the processor(s) of one or more general purpose computers (such as the one described in greater detail below) that execute an operating system, system programs, and application programs, while also implementing the module using multitasking, multithreading, distributed (e.g., cloud) processing, or other such techniques. Accordingly, each module can be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein. - As various the embodiments of the present invention, systems for building rules for filtration of insignificant events (IEs) are depicted in
FIG. 1A ,FIG. 1B andFIG. 1C . An application emulator is usually a part of an antivirus tool, which, when checking software, performs a search for unknown malicious objects on user PCs. An executable file can be considered as an object, for example, [name].exe. Before this file is it is run, it is checked (i.e., audited) with an application emulator. The application emulator breaks the application's byte code down to commands, and then it runs each command in a virtual computing environment, such as a virtual machine representing a copy of the actual computer system. This allows monitoring the behavior of the application. During the verification of application, at the time of execution of each command or set of commands, events are created, which, after preliminary analysis, will be entered in the event log for subsequent analysis (for detection of malicious application). During the preliminary analysis, rules for filtration of insignificant events are applied on the user PC's side. - If an event which happened during the emulation of an application was identified by any rule for filtration of insignificant events, that event will be deemed insignificant and will not be added to the event log. But if the event was not identified by any rule, such event will be entered in the event log for subsequent analysis by other antivirus tools, for example, using the system described in U.S. Pat. No. 7,530,106, the disclosure of which is incorporated by reference herein. After that, a final verdict will be issued as to maliciousness of the application under review.
- An insignificant event is an event which is not meaningful from the point of view of analysis of the maliciousness the behavior of a program because such event will happen during the execution of either safe or malicious program applications. Consequently, such events do not contribute meaningfully to the accurate determination of the benign/malicious nature of an application. Moreover, such events are not only useless for the analysis of emulation event logs, but also detrimental, because they increase the size of the emulation event log by tens or hundreds of times, which complicates detection of malicious actions and burdens the available computing resources, thus causing increased processing time, reduced system responsiveness, etc. It should be also noted that insignificant events affect the building of rules for analyzing event logs during emulation, because such rules can be created on the basis of an insignificant event, which can adversely affect the accuracy of the analysis based on such rules.
- For illustration purposes, examples of insignificant events include:
- 1) a call for <<GetVersion>>—a request for the operating system version. Any application written in the Delphi 7 programming language will make this request, but such request does not indicate whether an application is malicious or not;
- 2) a call for <<RegOpenKeyEx(0x80000001,“Software\Borland\Locales”, , , );>>—this action will also be performed in case of execution of any application written in Delphi 7, and does not allow to determine what kind of application it is, either;
- 3) a call for <<GetModuleHandle(“USER32.DLL”);>>—this action is proper to 80% of all executable files; consequently, this action will be performed in case of execution of both safe and malicious applications.
- It should be noted in other related embodiments, systems for filtering events from event logs to be formed and analyzed in assessing software (e.g., software applications) can be used with other tools for assessing performance of software. For example, disassembler and tracer tools can be used in lieu of an emulator. In a related embodiment, a combination of such tools is contemplated. However, for the sake of brevity, the embodiments detailed herein are presented in the context of use of an emulator as the software performance assessment tool.
-
FIG. 1A is a block diagram illustrating a system for generating rules for filtration of insignificant events. In one of the embodiments, the system for generating rules for filtration ofIEs 100 interacts with anantivirus service 101. An example of anantivirus service 101 can be the Kaspersky® Security Network service.Antivirus service 101 can be placed either on a server or on one ofuser PCs 180 a-180 n. Theantivirus service 101 contains various information on the software produced by developer companies, such as Microsoft®, and later operating onuser PCs 180 a-180 n. All information on various programs is stored in relevant knowledge bases, such as information databases 110 a-110 n, for example. Information databases 110 a-110 n can be located either separately (on the antivirus service 101) from other tools of thesystem 100, or together. Information contained in the information databases 110 a-110 n can consist in the application (file) itself, or in any information about them—for example, application metadata, parts of a program code, the application's hash sum, etc. The information databases 110 a-110 n are built by application types; for example, a database ofcompilers 110 a, a database ofpackers 110 b (applications for compression of an executable file), a database of protectors/encryptors 110 c (applications for compression and encryption of an executable file), a database of archivers, etc. - The system generating rules for filtration of
IEs 100 requests data fromdatabases program creation module 120. In various embodiments, the information that will be transferred can be the executable file of the compiler, packer, protector, etc., or the path to that executable file. The sampleprogram creation module 120 processes the received information (for example, executable file of the compiler) and uses it to build asample program 125, which is sent to theemulator 130. - It should be noted that the created
sample program 125 is a simplest application which does not carry out any particular functionality, but serves mainly for analyzing the behavior (e.g., defining events) of the application which was used to launch it. For example, each compiler from the 110 a database has a standard list of events, which will be executed during the execution of the applications created (e.g., compiled) using relevant compiler. The following application is an example of a simplest application created using a compiler for the Delphi programming language: -
Begin End. - In related embodiments, it is also possible to connect various standard libraries to this application, which will be called during the execution of the application. In this case, the
sample program 125 written in the Delphi programming language can look as follows: -
unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, OracleData, Oracle, StdCtrls, urlmon, ExtCtrls, Spin, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient, IdHTTP, IdMultipartFormData, AbUnZper, AbUtils, AbArcTyp, INIFiles, RxVerInf, IdUDPBase, IdUDPClient, IdDNSResolver, ComObj, Math; type TMain = class(TForm) end; var Main: TMain; implementation begin end. - If the data was received from
databases sample program 125 will be an application created (i.e., written) in any programming language, and in this case it will be compressed by a relevant packer or protector, information on which was provided to themodule 120. - The
emulator 130 performs emulation of the obtainedsample program 125, during which it records all created events in the events log 135. The emulation of thesample program 125 means breaking its program code down to instructions and imitating their execution. Then, theemulator 130 sends the built event log 135 to theanalyzer 140. - It should be noted that all events from the
event log 135 will be insignificant events, because the specified events will be proper to any application created with the help of the compiler being analyzed or packed with the help of the protector or packer being analyzed, regardless of whether the application is safe or malicious. - Based on each event from the received
event log 135, theanalyzer 140 creates a rule for filtration of insignificant events. A filtration rule is a Boolean characteristic and contains a name of an API function and masks for its arguments (a number of arguments from 1 to N). Each argument of the mask can adopt the following values: -
- -NULL-—indicates that the function's argument must be empty;
- *—any argument value;
- a specific argument value (in this case, the argument value and the set value will be compared until full coincidence).
- An example of such API function (rule for filtration of insignificant event) is the SysAllocString function with three arguments (*,-NULL-,-NULL-), where the first argument is any argument and the other ones are absent.
- The
analyzer 140, on the basis of created rules for filtration of insignificant events, builds a batch ofrules 145, which it then sends to the database of rules for filtration ofIEs 160. - The database of rules for filtration of
IEs 160 adds the received batch ofrules 145 to the table of rules for filtration of insignificant events for subsequent storage. Once the batch ofrules 145 is added to thedatabase 160, the version of the database is changed and sent to theupdate module 165. Table 1 below is an example of a set of rules for filtration of insignificant events: -
TABLE 1 API FUNCT ARG1 ARG2 . . . ARGN CoInitialize -NULL- -NULL- . . . -NULL- CoCreateIn- -NULL- -NULL- . . . * stance GetStringType -NULL- -NULL- . . . “”,, SysAllocString * -NULL- . . . -NULL- WideCharTo- -NULL- -NULL- . . . * MultiByte LCMapString -NULL- -NULL- . . . “”,,“”, GetModuleFile- -NULL- -NULL- . . . -NULL- Name GetFileType * -NULL- . . . -NULL- LoadLibrary shell32.dll -NULL- . . . -NULL- LoadLibrary kernel32.dll -NULL- . . . -NULL- LoadLibrary ole32.dll -NULL- . . . -NULL- RegSetValueEx \Registry\Machine\ -NULL- . . . ,,“regfile”, Software\Classes\.key RegOpenKeyEx 0x80000000 .key . . . ,, RegSetValue 0x80000000 .key . . . ,“”, CreateDirectory C:\DOCUME~1\ -NULL- . . . -NULL- ADMINI~1\LOCALS~1\ Temp\ . . . . . . . . . . . . . . . - In the above table, the first column (API_FUNCT) contains names of API functions, and the next columns (ARG1, ARG2, . . . , ARGN) contain arguments of functions.
- It should be also noted that the system for generating rules for filtration of
IEs 100 will provide the rules for filtration of IEs from the database of rules for filtration ofIEs 160 to the antivirus tools existing onuser PCs IEs 100 and theuser PCs Internet network 170. - In one example embodiment, the interaction between the database of rules for filtration of
IEs 160 and theuser PCs update module 165. In this case, theupdate module 165 contains a current version of thedatabase 160. Then, if a request is received from antivirus tools existing on theuser PCs update module 165 will compare the received version of the database with its own version of thedatabase 160. If the versions coincide, the antivirus tools on theuser PCs insignificant events 175 will be built. Thebatch 175 will contain all filtration rules created after the provided version of the database of rules from theuser PCs batch 175 will be sent to the antivirus tools onuser PCs -
FIG. 1B shows another example embodiment of a system for generating rules for filtration of insignificant events. In this embodiment, the system for generating rules for filtration ofIEs 100 contains only ananalyzer 140, a database of rules for filtration ofIEs 160 and anupdate module 165, and interacts with anantivirus service 101. In this embodiment, theantivirus service 101 contains two databases, 150 a and 150 b. The 150 a database containsevent logs BL 152, which were built during emulation of only malicious applications. The 150 b database containsevent logs WL 154, which were built only during emulation of safe applications. - The
analyzer 140 requests fromdatabases WL 154 contained in the above databases at the time of the request. Then, theanalyzer 140 analyzes all receivedevent logs analyzer 140 is depicted inFIG. 2 ). The list ofinsignificant events 270 contains events encountered both in the event logsBL 152 and in the event logsWL 154. All events entered in theabove list 270 are insignificant events. - Then, the
analyzer 140, on the basis of each event from the built list ofinsignificant events 270, creates a rule for filtration of IEs. Then, all created rules for filtration of IEs are sent to the database of rules for filtration ofIEs 160 in the form of a batch ofrules 145. The database of rules for filtration ofIEs 160 adds the received batch ofrules 145 to the table of rules for filtration of insignificant events for subsequent storage and transfer touser PCs 180, if a request is received from them. All interactions between the system for generating rules for filtration ofIEs 100 and theuser PCs 180 take place through theupdate module 165, which, in turn, interacts with theuser PCs 180 through theInternet network 170. - Another example of an embodiment of a system for generating rules for filtration of insignificant events is presented in
FIG. 1C . - The embodiment of a system for generating rules for filtration of IEs shown in
FIG. 1C combines the approaches shown inFIG. 1A andFIG. 1B . Also, in this embodiment, theanalyzer 140 performs verification of each event from the event log 135 received from theemulator 130 for their correspondence to the insignificant event. The verification will happen using the list ofsafe events 260 and the list of malicious events 250 (FIG. 2 ). The above lists will be built by theanalyzer 140 during the analysis of the event logs 152 and 154 from the 150 a and 150 b databases, together with the list ofevents 270, as shown inFIG. 1B . - Then, the
analyzer 140 will compare each event from the event log 135 with the built lists ofevents - In case if an event from the event log 135 received from the
emulator 130 was found in the lists ofevents - In case if an event from the event log 135 received from the
emulator 130 was not found in the lists ofevents analyzer 140 builds a filtration rule based on this event. One rules are built based on the events which have passed the verification, theanalyzer 140 builds a batch ofrules 145, which is sent to the database of rules for filtration ofIEs 160. - In one embodiment, the system for generating rules for filtration of
IEs 100 can be placed on one of the users'PCs 180 a-180 n, which will form the new filtration rules for the IEs. Subsequently, thesystem 100 generates a set ofrules 175 from among the new filtration rules and provide it to the appropriate anti-virus programs forusers 180 a-180 n via theInternet 170. -
FIG. 1D illustrates an example of a client-side PC 180 that conducts analysis of an unknown program and performs malware assessment based on a filtered event log from the performance assessment according to an exemplary embodiment.PC 180 includestracing module 182, which in various embodiments can be an emulator, de-compiler, tracing tool, etc.Tracing module 182 executes or otherwise examines the unknown program, which can be performed in an isolated virtual execution environment, for example. The performance assessment producesevent log 184, which normally includes mostly insignificant events insofar as malware analysis is concerned. Thus,filter 186 removes insignificant events from the event log. - Removal of the insignificant events is performed based on rules that are stored in insignificant event
filtering rules database 188. Insignificant eventfiltering rules database 188 is updated via event filtering rules updatemodule 190, which is communicatively coupled to aremote service 195.Remote service 195 can include an arrangement such as any of those depicted inFIGS. 1A-1C .Remote service 195 provides regular updates of rules for filtration of insignificant events, which can be provided in batches such asbatch 175. The rules are stored indatabase 188, which is read byfilter 186 to perform the filtering operation. - Once the
event log 184 is filtered, it is in condition to be analyzed for the presence of malware.Malware analyzer module 192 reads the filtered event log, and performs any one or more of a variety of actions to assess the risk of the unknown program (e.g., whether the unknown program is harmful or benign). These actions can include comparisons of events against patterns of known malicious patterns or benign patterns, heuristic analyses, analysis using artificial neural network technology, fuzzy logic analysis, etc. Any suitable malware detection technique now known, or later developed, is contemplated for use with aspects of the invention. -
FIG. 2 illustrates an example of a diagram of the operation of theanalyzer 140 when building rules for filtration of IEs. In one embodiment, theanalyzer 140 includes a module for analysis of event logs 210 (hereinafter referred to as analysis module 210), a module for comparative analysis of event logs and for building lists of events 230 (hereinafter referred to as comparative analysis module 230) and a module for building rules for filtration of insignificant events 290 (hereinafter referred to as filtration rules module 290). -
Analysis module 210 is designed to analyze anevent log 135 received from theemulator 130 and to provide all insignificant events tofiltration rules module 290 in the form of a list ofinsignificant events 280.Analysis module 210 also performs preliminary verification (as described in the description ofFIG. 1 c) of all events from thelog 135, using the list ofmalicious events 250 and the list ofsafe events 260, received fromcomparative analysis module 230. -
Comparative analysis module 230 is designed to analyze the event logsBL 152 and the event logsWL 154, received from thedatabases antivirus service 101. On the basis of the performed analysis,comparative analysis module 230 builds three lists of events: a list ofmalicious events 250, a list ofsafe events 260 and a list ofinsignificant events 270. Then,comparative analysis module 230 provideslists analysis module 210 and provideslist 270 tofiltration rules module 290. -
Filtration rules module 290 is designed to: -
- build rules for filtration of insignificant events (IEs) on the basis of the lists of
insignificant events modules 210 and 230 (as described in the description ofFIG. 1 a); - build a batch of
rules 145 from the built rules for filtration of IEs, and - subsequent transmission of the built batch of
rules 145 to the database of rules for filtration ofIEs 160.
- build rules for filtration of insignificant events (IEs) on the basis of the lists of
- In a specific embodiment,
filtration rules module 290 checks the built rules for filtration of IEs for their presence in the database of rules of filtration ofIEs 160. In case if the built rules for filtration of IEs are found in thedatabase 160, the rules will not be added to thedatabase 160, but instead they will be deleted. -
FIG. 5 illustrates in more detail an example set of criteria (e.g., limits) for selection of insignificant events during the analysis of events from the 152 and 154 event logs. First, all events from both types of event logs will be selected. Then, each event will be analyzed; in this case, the log where the analyzed event was discovered will constitute 100% of events, regardless of the event type. Then, three situations are possible: - 1. The event detection ratio was 30%/70% or less for the event logs
WL 152, i.e. the event was detected from 0% to 30% in the event logsWL 152, and from 70% to 100% in the event logsBL 154. In this case, the event is a suspicious event and it will be added to the list ofmalicious events 250. - 2. The event detection ratio was 30%/70% or more for the event logs
WL 152, but not more than 70%, i.e. the event was detected from 30% to 70% in the event logsWL 152 and from 70% to 30% in the event logsBL 154. In this case, the event is an insignificant event and it will be added to the list ofinsignificant events 270. - 3. The event detection ratio was 70%/30% or more for the event logs
WL 152, i.e. the event was detected from 70% to 100% in the event logsWL 152 and from 30% to 0% in the event logsBL 154. In this case, the event is a potentially safe event and it will be added to the list ofsafe events 260. - It also should be noted that the most accurate result during the building of the lists of
events -
FIG. 3 depicts a machine-implemented process which can be used to implement a system for generating rules for filtration of insignificant events. In order to create rules for filtration of IEs, at 310 the system for generating rules for filtration ofIEs 100 sends a request for presence of new data for the databases from the list ofdatabases databases databases IEs 100, and namely to the sampleprogram creation module 120. - The data or information contained in the
databases program creation module 120 checks the received data for up-to-dateness. - In one embodiment, the check of data for up-to-dateness can consist in the building of a hash sum for each set of data on each received object. The built hash sum is compared with the list of previously created hash sums, which is stored in the sample
program creation module 120. In case if the built hash sum is found in the list of hash sums, the built hash sum is not new, and themodule 120 will delete all data which was used to build the hash sum. In case if the built hash sum is not found in the list of hash sums, the built hash sum is new and will be added to the specified list of hash sums, while the data used to build the hash sum will be sent to block 320. - At 320, a
sample program 125 is built based on the data received with the help of themodule 120. At 325, themodule 120 sends thesample program 125 to theemulator 130 for subsequent analysis. After that, theemulator 130 is run, and at 330, thesample program 125 is emulated. During the emulation, aevent log 135 is built, where the emulator 130 records all performed actions (the events which took place) of thesample program 125. At 335, the builtevent log 135 is sent to theanalyzer 140, which verifies it in order to detect insignificant events. The verification is performed by comparing the events from the event log with the events from thelists lists list 280, which, after the completion of the verification, will be sent to block 345. In case if the events are found in the above mentionedlists - At 345, the
analyzer 140 builds rules for filtration based on the events from the receivedlist 280. The building of rules for filtration of insignificant events happens as shown inFIG. 1 a. At 350, the built rules are added to the database of rules for filtration ofIEs 160 for subsequent storage, pre-built in the form of a batch ofrules 145. At 355, it is decided whether to continue building rules for filtration of insignificant events or to end operation. In case if all data received frominformation databases databases system 100 will go back to 310. -
FIG. 4 depicts a machine-implemented process for generation of rules for filtration of insignificant events. At 415, theanalyzer 140 receives at least oneevent log BL 152 fromdatabase 150 a, and at least oneevent log WL 154 fromdatabase 150 b. At 430, theanalyzer 140 compares all received event logs and detects the events encountered both inBL 152 and inWL 154. At 445, theanalyzer 140 builds a list of events from the events which were included in both types of lists. Based on this list of events, theanalyzer 140 at 460 builds rules for filtration of IEs. After that, from the created rules for filtration of IEs, it builds a batch ofrules 145, which it then sends to the database of rules for filtration ofIEs 160. At 475, thedatabase 160 will add the rules for filtration of IEs from the received batch ofrules 145 to the table of rules for filtration of insignificant events for subsequent storage. -
FIG. 6 is a diagram illustrating in greater detail acomputer system 600 on which aspects of the invention as described herein may be implemented according to various embodiments. Thecomputer system 600 may include a computing device such as apersonal computer 602. Thepersonal computer 602 includes one ormore processing units 604, asystem memory 606, avideo interface 608, an outputperipheral interface 610, anetwork interface 612, auser input interface 614, removable 616 and non-removable 618 memory interfaces and a system bus or high-speed communications channel 620 coupling the various components. In various embodiments, theprocessing units 604 may have multiple logical cores that are able to process information stored on computer readable media such as thesystem memory 606 or memory attached to the removable 616 and non-removable 618 memory interfaces 618. Thecomputer 602system memory 606 may include non-volatile memory such as Read Only Memory (ROM) 622 or volatile memory such as Random Access Memory (RAM) 624. The ROM 622 may include a basic input/output system (BIOS) 626 to help communicate with the other portion of thecomputer 602. TheRAM 624 may store portions of various software applications such as theoperating system 628,application programs 630 andother program modules 632. Further, theRAM 624 may store other information such as program orapplication data 634. In various embodiments, theRAM 624 stores information that requires low-latencies and efficient access, such as programs and data being manipulated or operated on. In various embodiments RAM 624 comprises Double Data Rate (DDR) memory, Error Correcting memory (ECC) or other memory technologies with varying latencies and configurations such as RAMBUS or DDR2 and DDR3. In this way, in various embodiments, thesystem memory 606 may store the input data store, access credential data store, operating memory data store, instruction set data store, analysis result data store and the operating memory data store. Further, in various embodiments, theprocessing units 604 may be configured to execute instructions that limit access to the aforementioned data stores by requiring access credential before access to the information is granted. - The removable 616 and non-removable 618 memory interfaces may couple the
computer 602 todisk drives 636 such as SSD or rotational disk drives. These disk drives 636 may provide further storage for various software applications such as theoperating system 638,application programs 640 andother program modules 642. Further, the disk drives 636 may store other information such as program orapplication data 644. In various embodiments, the disk drives 636 store information that doesn't require the same low-latencies as in other storage mediums. Further, theoperating system 638,application program 640 data,program modules 642 and program orapplication data 644 may be the same information as that stored in theRAM 624 in various embodiments mentioned above or it may be different data potentially derivative of theRAM 624 stored data. - Further, the removable
non-volatile memory interface 616 may couple thecomputer 602 to magneticportable disk drives 646 that utilize magnetic media such as thefloppy disk 648, Iomega® Zip or Jazz, oroptical disk drives 650 that utilizeoptical media 652 for storage of computer readable media such as Blu-Ray®, DVD-R/RW, CD-R/RW and other similar formats. Still other embodiments utilize SSD or rotational disks housed in portable enclosures to increase the capacity of removable memory. - The
computer 602 may utilize thenetwork interface 612 to communicate with one or moreremote computers 656 over a local area network (LAN) 658 or a wide area network (WAN) 660. Thenetwork interface 612 may utilize a Network Interface Card (NIC) or other interface such as amodem 662 to enable communication. Themodem 662 may enable communication over telephone lines, coaxial, fiber optic, powerline, or wirelessly. Theremote computer 656 may contain a similar hardware and software configuration or may have amemory 664 that containsremote application programs 666 that may provide additional computer readable instructions to thecomputer 602. In various embodiments, theremote computer memory 664 can be utilized to store information such as identified file information that may be later downloaded tolocal system memory 606. Further, in various embodiments theremote computer 656 may be an application server, an administrative server, client computers, or a network appliance. - A user may enter information to the
computer 602 using input devices connected to theuser input interface 614 such as amouse 668 andkeyboard 670. Additionally, the input device may be a trackpad, fingerprint scanner, joystick, barcode scanner, media scanner or the like. Thevideo interface 608 may provide visual information to a display such as amonitor 672. Thevideo interface 608 may be an embedded interface or it may be a discrete interface. Further, the computer may utilize a plurality ofvideo interfaces 608, network interfaces 612 and removable 616 and non-removable 618 interfaces in order to increase the flexibility in operation of thecomputer 602. Further, various embodiments utilizeseveral monitors 672 andseveral video interfaces 608 to vary the performance and capabilities of thecomputer 602. Other computer interfaces may be included incomputer 602 such as the outputperipheral interface 610. This interface may be coupled to aprinter 674 orspeakers 676 or other peripherals to provide additional functionality to thecomputer 602. - Various alternative configurations and implementations of the
computer 602 are within the spirit of the invention. These variations may include, without limitation, additional interfaces coupled to thesystem bus 620 such as universal serial bus (USB), printer port, game port, PCI bus, PCI Express or integrations of the various components described above into chipset components such as the northbridge or southbridge. For example, in various embodiments, theprocessing unit 604 may include an embedded memory controller (not shown) to enable more efficient transfer of data from thesystem memory 606 than thesystem bus 620 may provide. - The embodiments above are intended to be illustrative and not limiting. Additional embodiments are within the claims. In addition, although aspects of the present invention have been described with reference to particular embodiments, those skilled in the art will recognize that changes can be made in form and detail without departing from the scope of the invention, as defined by the claims.
- Persons of ordinary skill in the relevant arts will recognize that the invention may comprise fewer features than illustrated in any individual embodiment described above. The embodiments described herein are not meant to be an exhaustive presentation of the ways in which the various features of the invention may be combined. Accordingly, the embodiments are not mutually exclusive combinations of features; rather, the invention may comprise a combination of different individual features selected from different individual embodiments, as will be understood by persons of ordinary skill in the art.
- Any incorporation by reference of documents above is limited such that no subject matter is incorporated that is contrary to the explicit disclosure herein. Any incorporation by reference of documents above is further limited such that no claims that are included in the documents are incorporated by reference into the claims of the present Application. The claims of any of the documents are, however, incorporated as part of the disclosure herein, unless specifically excluded. Any incorporation by reference of documents above is yet further limited such that any definitions provided in the documents are not incorporated by reference herein unless expressly included herein.
- For purposes of interpreting the claims for the present invention, it is expressly intended that the provisions of Section 112, sixth paragraph of 35 U.S.C. are not to be invoked unless the specific terms “means for” or “step for” are recited in a claim.
Claims (26)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/722,619 US8762948B1 (en) | 2012-12-20 | 2012-12-20 | System and method for establishing rules for filtering insignificant events for analysis of software program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/722,619 US8762948B1 (en) | 2012-12-20 | 2012-12-20 | System and method for establishing rules for filtering insignificant events for analysis of software program |
Publications (2)
Publication Number | Publication Date |
---|---|
US8762948B1 US8762948B1 (en) | 2014-06-24 |
US20140181805A1 true US20140181805A1 (en) | 2014-06-26 |
Family
ID=50944252
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/722,619 Expired - Fee Related US8762948B1 (en) | 2012-12-20 | 2012-12-20 | System and method for establishing rules for filtering insignificant events for analysis of software program |
Country Status (1)
Country | Link |
---|---|
US (1) | US8762948B1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105511941A (en) * | 2015-03-16 | 2016-04-20 | 卡巴斯基实验室股份公司 | System and method for facilitating joint operation of multiple hypervisors in computer system |
US10938839B2 (en) | 2018-08-31 | 2021-03-02 | Sophos Limited | Threat detection with business impact scoring |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
IL219499B (en) | 2012-04-30 | 2019-02-28 | Verint Systems Ltd | System and method for malware detection |
IL224482B (en) | 2013-01-29 | 2018-08-30 | Verint Systems Ltd | System and method for keyword spotting using representative dictionary |
IL226057A (en) * | 2013-04-28 | 2017-07-31 | Verint Systems Ltd | System and method for automated configuration of intrusion detection systems |
IL226747B (en) | 2013-06-04 | 2019-01-31 | Verint Systems Ltd | System and method for malware detection learning |
WO2015141630A1 (en) * | 2014-03-19 | 2015-09-24 | 日本電信電話株式会社 | Analysis rule adjustment device, analysis rule adjustment system, analysis rule adjustment method, and analysis rule adjustment program |
IL233776B (en) | 2014-07-24 | 2019-02-28 | Verint Systems Ltd | System and method for range matching |
US10560842B2 (en) | 2015-01-28 | 2020-02-11 | Verint Systems Ltd. | System and method for combined network-side and off-air monitoring of wireless networks |
IL238001B (en) | 2015-03-29 | 2020-05-31 | Verint Systems Ltd | System and method for identifying communication session participants based on traffic patterns |
US9766969B2 (en) | 2015-06-18 | 2017-09-19 | Xerox Corporation | Assessing and improving quality of event logs including prioritizing and classifying errors into error-perspective and error-type classifications |
US9852295B2 (en) | 2015-07-14 | 2017-12-26 | Bitdefender IPR Management Ltd. | Computer security systems and methods using asynchronous introspection exceptions |
IL242218B (en) | 2015-10-22 | 2020-11-30 | Verint Systems Ltd | System and method for maintaining a dynamic dictionary |
IL242219B (en) | 2015-10-22 | 2020-11-30 | Verint Systems Ltd | System and method for keyword searching using both static and dynamic dictionaries |
US9888022B2 (en) * | 2015-12-01 | 2018-02-06 | International Business Machines Corporation | Providing application-specific threat metrics |
US20170178026A1 (en) * | 2015-12-22 | 2017-06-22 | Sap Se | Log normalization in enterprise threat detection |
US10075462B2 (en) | 2015-12-22 | 2018-09-11 | Sap Se | System and user context in enterprise threat detection |
IL245299B (en) | 2016-04-25 | 2021-05-31 | Verint Systems Ltd | System and method for decrypting communication exchanged on a wireless local area network |
US10140448B2 (en) | 2016-07-01 | 2018-11-27 | Bitdefender IPR Management Ltd. | Systems and methods of asynchronous analysis of event notifications for computer security applications |
IL248306B (en) | 2016-10-10 | 2019-12-31 | Verint Systems Ltd | System and method for generating data sets for learning to identify user actions |
IL252041B (en) | 2017-04-30 | 2020-09-30 | Verint Systems Ltd | System and method for tracking users of computer applications |
IL252037B (en) | 2017-04-30 | 2021-12-01 | Verint Systems Ltd | System and method for identifying relationships between users of computer applications |
IL256690B (en) | 2018-01-01 | 2022-02-01 | Cognyte Tech Israel Ltd | System and method for identifying pairs of related application users |
CN110414021B (en) * | 2018-04-27 | 2023-09-08 | 西门子股份公司 | System, device and method for generating event rules of edge equipment of industrial Internet of things |
IL260986B (en) | 2018-08-05 | 2021-09-30 | Verint Systems Ltd | System and method for using a user-action log to learn to classify encrypted traffic |
WO2020188524A1 (en) | 2019-03-20 | 2020-09-24 | Verint Systems Ltd. | System and method for de-anonymizing actions and messages on networks |
US11314863B2 (en) * | 2019-03-27 | 2022-04-26 | Webroot, Inc. | Behavioral threat detection definition and compilation |
US11481486B2 (en) | 2019-03-27 | 2022-10-25 | Webroot Inc. | Behavioral threat detection engine |
US11080391B2 (en) | 2019-03-27 | 2021-08-03 | Webroot Inc. | Behavioral threat detection definition and compilation |
US11080394B2 (en) | 2019-03-27 | 2021-08-03 | Webroot Inc. | Behavioral threat detection virtual machine |
US11399016B2 (en) | 2019-11-03 | 2022-07-26 | Cognyte Technologies Israel Ltd. | System and method for identifying exchanges of encrypted communication traffic |
US20220311795A1 (en) * | 2021-03-23 | 2022-09-29 | Target Brands, Inc. | Validating network security alerting pipeline using synthetic network security events |
CN113434386B (en) * | 2021-05-26 | 2022-10-04 | 深圳开源互联网安全技术有限公司 | Method, system and storage medium for fuzz testing |
Family Cites Families (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6493868B1 (en) * | 1998-11-02 | 2002-12-10 | Texas Instruments Incorporated | Integrated development tool |
US7430670B1 (en) * | 1999-07-29 | 2008-09-30 | Intertrust Technologies Corp. | Software self-defense systems and methods |
WO2001022228A1 (en) * | 1999-09-17 | 2001-03-29 | Nortel Networks Limited | System and method for producing a verification system for verifying procedure interfaces |
US7024694B1 (en) | 2000-06-13 | 2006-04-04 | Mcafee, Inc. | Method and apparatus for content-based instrusion detection using an agile kernel-based auditor |
US7451216B2 (en) * | 2001-06-14 | 2008-11-11 | Invision Networks, Inc. | Content intelligent network recognition system and method |
US6947983B2 (en) * | 2001-06-22 | 2005-09-20 | International Business Machines Corporation | Method and system for exploiting likelihood in filter rule enforcement |
US7143394B1 (en) * | 2001-12-21 | 2006-11-28 | Emc Corporation | Analyzing software behavior |
US7340777B1 (en) | 2003-03-31 | 2008-03-04 | Symantec Corporation | In memory heuristic system and method for detecting viruses |
US7549164B2 (en) * | 2003-06-11 | 2009-06-16 | Symantec Corporation | Intrustion protection system utilizing layers and triggers |
US7512977B2 (en) * | 2003-06-11 | 2009-03-31 | Symantec Corporation | Intrustion protection system utilizing layers |
US6901581B1 (en) * | 2002-10-02 | 2005-05-31 | Eridon Corporation | Method for software debugging via simulated re-execution of a computer program |
US7194732B2 (en) * | 2003-06-26 | 2007-03-20 | Hewlett-Packard Development Company, L.P. | System and method for facilitating profiling an application |
US7490268B2 (en) | 2004-06-01 | 2009-02-10 | The Trustees Of Columbia University In The City Of New York | Methods and systems for repairing applications |
US7707189B2 (en) | 2004-10-05 | 2010-04-27 | Microsoft Corporation | Log management system and method |
US7797686B2 (en) * | 2005-05-13 | 2010-09-14 | Texas Instruments Incorporated | Behavior of trace in non-emulatable code |
US7720670B2 (en) * | 2005-05-16 | 2010-05-18 | Texas Instruments Incorporated | Saving resources by deducing the total prediction events |
US7950004B2 (en) * | 2005-10-21 | 2011-05-24 | Siemens Corporation | Devices systems and methods for testing software |
US7945898B1 (en) * | 2006-03-16 | 2011-05-17 | Avaya Inc. | Handling loops in programs and examining feasible software behavior for detecting malicious code |
US7685271B1 (en) * | 2006-03-30 | 2010-03-23 | Symantec Corporation | Distributed platform for testing filtering rules |
US8122436B2 (en) * | 2007-11-16 | 2012-02-21 | Microsoft Corporation | Privacy enhanced error reports |
US8166459B2 (en) * | 2008-02-27 | 2012-04-24 | Sap Ag | Apparatus and method of generating self-debugging computer software |
US8321842B2 (en) * | 2008-06-27 | 2012-11-27 | Vmware, Inc. | Replay time only functionalities in a virtual machine |
US7530106B1 (en) | 2008-07-02 | 2009-05-05 | Kaspersky Lab, Zao | System and method for security rating of computer processes |
US20110041179A1 (en) | 2009-08-11 | 2011-02-17 | F-Secure Oyj | Malware detection |
US8566943B2 (en) * | 2009-10-01 | 2013-10-22 | Kaspersky Lab, Zao | Asynchronous processing of events for malware detection |
US8499283B2 (en) * | 2010-02-09 | 2013-07-30 | Webroot Inc. | Detection of scripting-language-based exploits using parse tree transformation |
-
2012
- 2012-12-20 US US13/722,619 patent/US8762948B1/en not_active Expired - Fee Related
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105511941A (en) * | 2015-03-16 | 2016-04-20 | 卡巴斯基实验室股份公司 | System and method for facilitating joint operation of multiple hypervisors in computer system |
US10938839B2 (en) | 2018-08-31 | 2021-03-02 | Sophos Limited | Threat detection with business impact scoring |
US10938838B2 (en) | 2018-08-31 | 2021-03-02 | Sophos Limited | Computer augmented threat evaluation |
US10972485B2 (en) | 2018-08-31 | 2021-04-06 | Sophos Limited | Enterprise network threat detection |
US11297073B2 (en) | 2018-08-31 | 2022-04-05 | Sophos Limited | Forensic query of local event streams in an enterprise network |
US11552962B2 (en) | 2018-08-31 | 2023-01-10 | Sophos Limited | Computer assisted identification of intermediate level threats |
US11720844B2 (en) | 2018-08-31 | 2023-08-08 | Sophos Limited | Enterprise network threat detection |
US11727333B2 (en) | 2018-08-31 | 2023-08-15 | Sophos Limited | Endpoint with remotely programmable data recorder |
US11755974B2 (en) | 2018-08-31 | 2023-09-12 | Sophos Limited | Computer augmented threat evaluation |
US11836664B2 (en) | 2018-08-31 | 2023-12-05 | Sophos Limited | Enterprise network threat detection |
US11928631B2 (en) | 2018-08-31 | 2024-03-12 | Sophos Limited | Threat detection with business impact scoring |
US12079757B2 (en) | 2018-08-31 | 2024-09-03 | Sophos Limited | Endpoint with remotely programmable data recorder |
Also Published As
Publication number | Publication date |
---|---|
US8762948B1 (en) | 2014-06-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8762948B1 (en) | System and method for establishing rules for filtering insignificant events for analysis of software program | |
US8635694B2 (en) | Systems and methods for malware classification | |
US10382448B2 (en) | Methods, systems and computer readable media for detecting command injection attacks | |
US10664596B2 (en) | Method of malware detection and system thereof | |
Carmony et al. | Extract Me If You Can: Abusing PDF Parsers in Malware Detectors. | |
Aslan et al. | Investigation of possibilities to detect malware using existing tools | |
Comparetti et al. | Identifying dormant functionality in malware programs | |
US9348998B2 (en) | System and methods for detecting harmful files of different formats in virtual environments | |
Maggi et al. | Andrototal: A flexible, scalable toolbox and service for testing mobile malware detectors | |
RU2624552C2 (en) | Method of malicious files detecting, executed by means of the stack-based virtual machine | |
RU91213U1 (en) | SYSTEM OF AUTOMATIC COMPOSITION OF DESCRIPTION AND CLUSTERING OF VARIOUS, INCLUDING AND MALIMENTAL OBJECTS | |
CN106355092B (en) | System and method for optimizing anti-virus measurement | |
Yücel et al. | Imaging and evaluating the memory access for malware | |
Hahn et al. | Robust static analysis of portable executable malware | |
RU2708355C1 (en) | Method of detecting malicious files that counteract analysis in isolated environment | |
Akram et al. | The making of indicator of compromise using malware reverse engineering techniques | |
KR101383664B1 (en) | Analyzing system for behavior of each unit file | |
Guerra-Manzanares et al. | Cross-device behavioral consistency: benchmarking and implications for effective android malware detection | |
Webb | Evaluating tool based automated malware analysis through persistence mechanism detection | |
Guo et al. | Feature collection and selection in malware classification | |
Starink | Analysis and automated detection of host-based code injection techniques in malware | |
RU2514139C1 (en) | System and method of creating rules for filtering insignificant events for event log analysis | |
Kanchhal et al. | Android malware a oversight on malware detection using machine learning | |
Huang et al. | A Detection System of Android Malware Based on SVM Algorithm | |
Sokol et al. | Dynamic Heuristic Analysis Tool for Detection of Unknown Malware |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: KASPERSKY LAB ZAO, RUSSIAN FEDERATION Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZAITSEV, OLEG V.;REEL/FRAME:029536/0729 Effective date: 20121213 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: AO KASPERSKY LAB, RUSSIAN FEDERATION Free format text: CHANGE OF NAME;ASSIGNOR:KASPERSKY LAB ZAO;REEL/FRAME:036786/0655 Effective date: 20150625 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551) Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20220624 |