Abstract: Systems and methods are provided in example embodiments for mitigating malicious calls. The system can be configured to receive a function call, determine the location of a memory page that initiated the function call, determine if the memory page is associated with a trusted module, and block the function call if the memory page is not associated with the trusted module. In addition, the system can determine the return address for the function call and block the function call if the return address does not belong to the trusted module. Further, the system can determine a parameter for the function call, determine if the parameter is a known parameter used by the process that called the function, and block the function call if the parameter is not the known parameter used by the process that called the function.

Abstract: Systems and methods are provided in example embodiments for mitigating malicious calls. The system can be configured to receive a function call, determine the location of a memory page that initiated the function call, determine if the memory page is associated with a trusted module, and block the function call if the memory page is not associated with the trusted module. In addition, the system can determine the return address for the function call and block the function call if the return address does not belong to the trusted module. Further, the system can determine a parameter for the function call, determine if the parameter is a known parameter used by the process that called the function, and block the function call if the parameter is not the known parameter used by the process that called the function.

Abstract: Systems and methods are provided in example embodiments for mitigating malicious calls. The system can be configured to receive a function call, determine the location of a memory page that initiated the function call, determine if the memory page is associated with a trusted module, and block the function call if the memory page is not associated with the trusted module. In addition, the system can determine the return address for the function call and block the function call if the return address does not belong to the trusted module. Further, the system can determine a parameter for the function call, determine if the parameter is a known parameter used by the process that called the function, and block the function call if the parameter is not the known parameter used by the process that called the function.

Abstract: Systems and methods are provided in example embodiments for mitigating malicious calls. The system can be configured to receive a function call, determine the location of a memory page that initiated the function call, determine if the memory page is associated with a trusted module, and block the function call if the memory page is not associated with the trusted module. In addition, the system can determine the return address for the function call and block the function call if the return address does not belong to the trusted module. Further, the system can determine a parameter for the function call, determine if the parameter is a known parameter used by the process that called the function, and block the function call if the parameter is not the known parameter used by the process that called the function.

Abstract: A suspicious entity is identified. An intelligent hash for the suspicious entity is generated, wherein the intelligent hash includes a set of metadata that is specific to the suspicious entity and at least some of the metadata is invariant over changes to the suspicious entity. The intelligent hash is transmitted to a server for evaluation of whether the suspicious entity corresponds to the malware entity. The server is adapted to determine whether the suspicious entity corresponds to the malware entity based on the intelligent hash. A result is received from the server specifying whether the suspicious entity corresponds to the malware entity.

Abstract: A system and method detects malware on client devices based on partially distributed malware definitions from a central server. A server stores malware definitions for known malware. The server generates one or more filters based on the malware definitions and distributes the filter(s) to client devices. The server also distributes full definitions to the clients for a subset of the most commonly detected malware. The client device scans files for malware by first applying the filter to a file. If the filter outputs a positive detection, the client scans the file using the full definition to determine if the file comprises malware. If the full definition is not stored locally by the client, the client queries the server for the definition and then continues the scanning process.

Abstract: The executions of computer viruses are analyzed to develop register signatures for the viruses. The register signatures specify the sets of outputs the viruses produce when executed with a given set of inputs. A virus detection system (VDS) (400) holds a database (430) of the register signatures. The VDS (400) selects (710) a file that might contain a computer virus and identifies potential entry points in the file. The VDS (400) uses a virtual machine (422) having an initial state to emulate (714) a relatively small number of instructions at each entry point. While emulating each potential entry point, the VDS builds (716) a register table that tracks the state of a subset of the virtual registers (428). Once the VDS (400) reaches an emulation breakpoint, it analyzes the register table in view of the register signatures to determine whether the file contains a virus.

Abstract: A blocking-scanning manager (101) detects (200) attempted malicious behavior of running code (120). In response to detection, the blocking-scanning manager (101) blocks (206) the attempted malicious behavior. The blocking-scanning manager (101) generates (208) a signature to identify the code that attempted the malicious behavior. The blocking-scanning manager (101) detects (506) code identified by the signature. Responsive to detection, the blocking-scanning manager (101) blocks (508) execution of the identified code (122).

Abstract: Methods, apparatuses, and computer-readable media for detecting malicious computer code in a host computer (1). A method embodiment of the present invention comprises the steps of determining (32) whether data leaving the host computer (1) is addressed to exit a port (15) of the host computer (1) where outbound executable content normally does not appear; when the data is addressed to exit such a port (15), determining (33) whether a string (24) from a pre-established runtime database (9) of executable threads is present in said data; and when a string (24) from said runtime database (9) is present in said data, declaring (34) a suspicion of presence of malicious computer code in said data.

Abstract: Accesses to critical tokens are monitored and malicious changes to the security privileges of those critical tokens are detected and prevented.

Abstract: Methods and apparatuses for detecting hidden network channels of rootkit tools are described. In one embodiment, critical endpoint events detected at an endpoint computer system are selectively logged to an endpoint database. Also, critical network events associated with the endpoint computer system and detected on a network are selectively logged to a gateway database. Periodically some or all of the entries in the endpoint database are compared to entries in the gateway database. Entries detected at the network but not detected at the endpoint computer system are presumed indicative of hidden network channels of rootkit tools.

Abstract: In one embodiment an IO request packet (IRP) attempting to access a computer disk is evaluated to determine if the request identifies an area of a computer disk to be accessed that is marked as bad in a file system. When the request identifies an area of the computer disk to be accessed that is marked as bad in a file system, the request is assumed to be indicative of a rootkit. In another embodiment an IO request packet is evaluated to determine if the request identifies an area of the computer disk to be accessed that was not identified in requests detected in the file system level of the kernel. When the stalled request identifies an area of the computer disk to be accessed not detected in requests detected in the file system level of the kernel, the request is assumed to be indicative of a rootkit.

Abstract: Parameters of DNS transactions associated with DNS MX record queries, which may be performed by mass-mailing worms from a host computer system, are detected at a DNS proxy and collected. An outbound SMTP transaction, such as an e-mail message, received at an SMTP proxy is stalled at the SMTP proxy and a determination is made whether malicious code activity is detected on the host computer system by correlating the parameters associated with the DNS MX record queries and the e-mail message. In one embodiment, above a specified threshold rate of DNS MX record queries to resolve SMTP server IP addresses, followed by the use of a resolved SMTP server IP address to send the e-mail message, an assumption is made that the e-mail message is generated by a worm, such as a mass-mailing worm, and protective action is taken thus preventing propagation of the worm, or other malicious code, via the outbound e-mail message.

Abstract: A suspicious entity is identified. An intelligent hash for the suspicious entity is generated, wherein the intelligent hash includes a set of metadata that is specific to the suspicious entity and at least some of the metadata is invariant over changes to the suspicious entity. The intelligent hash is transmitted to a server for evaluation of whether the suspicious entity corresponds to the malware entity. The server is adapted to determine whether the suspicious entity corresponds to the malware entity based on the intelligent hash. A result is received from the server specifying whether the suspicious entity corresponds to the malware entity.

Abstract: A system and method detects malware on client devices based on partially distributed malware definitions from a central server. A server stores malware definitions for known malware. The server generates one or more filters based on the malware definitions and distributes the filter(s) to client devices. The server also distributes full definitions to the clients for a subset of the most commonly detected malware. The client device scans files for malware by first applying the filter to a file. If the filter outputs a positive detection, the client scans the file using the full definition to determine if the file comprises malware. If the full definition is not stored locally by the client, the client queries the server for the definition and then continues the scanning process.

Abstract: Techniques are disclosed for detecting manipulations of user-kernel transition registers (such as the SYSENTER/SYSCALL critical registers of Intel/AMD processors, respectively), and other such registers. In one embodiment, a register monitor agent is deployed at system boot-up, and continues monitoring target registers for manipulation during system use. If a manipulation is detected, then exclusions are checked to see if that manipulation is legitimate (e.g., caused by a trusted source). If not a legitimate manipulation, then reporting and/or corrective action can be taken. The techniques can be used in real-time and in any number of behavior blocking, antivirus, and/or intrusion prevention applications.

Abstract: Call to driver load functions, including associated driver objects to be loaded, are stalled and evaluated for indications of a rootkit. When a rootkit is indicated, protective action is taken, and optionally a user or system administrator are notified. Calls not indicative of a rootkit are released and allowed to load. In one embodiment, calls to currently loaded drivers and calls related to installation of new hardware, are excluded from the evaluation for indications of a rootkit. In additional embodiments, sensitive structures and calls to sensitive structures of a computer system are also evaluated for indications of a rootkit.

Abstract: A method includes stalling a cache flush instruction to flush a cache; determining that the cache comprises a file that has been infected with malicious code, and terminating the cache flush instruction to prevent the cache from being flushed to disk. By preventing copying of the infected file from the cache to disk, the malicious code is prevented from being propagated to disk. Accordingly, the malicious code is detected and defeated without having the malicious code be present on disk. Thus, detection of an infected file on disk and the repair of the infected file on disk are unnecessary and obviated.

Abstract: An executable file containing malicious software can be packed using a packer to make the software difficult to detect. The executable file is loaded into the computer's memory and executed as a process. A memory dump module analyzes the address space for the process and identifies an executable file image within it. The memory dump module creates a memory dump file on the computer's storage device containing the file image and modifies the file to make it resemble a normal executable file. A signature scanning module scans the memory dump file for signatures of malicious software. If a signature is found in the file, a reporting module sends the host file for the process and the memory dump file to a security server for analysis.

Abstract: A method includes generating new update name lists and providing malicious code protection update information including the new update name lists to host computer systems. In one embodiment, the new update name lists are generated by registering domain names, and only a subset of the registered domain names are used to create an update name list provided to any one of the host computer systems.