Abstract: Embodiments described herein are capable of preventing the installation of unwanted software bundled with a desired application at runtime, while allowing the installation of the desired application to continue as expected. For example, the embodiments described herein create a decoy in memory that preempts unwanted code. The decoy attracts any illegitimate code and diverts it into a dead end (e.g., the code is isolated, thereby preventing it from properly executing), while installation of the legitimate code (i.e., the desired application) flows as expected. The foregoing detects that a reflective loading process of DLL associated with the unwanted application has occurred, identifies the entity that attempted to perform the reflective loading process, and prevents the entity from completing the reflective loading process without terminating the main installer.

Abstract: Embodiments described herein enable the detection, analysis and signature determination of obfuscated malicious code. Such malicious code comprises a deobfuscation portion that deobfuscates the obfuscated portion during runtime to generate deobfuscated malicious code. The techniques described herein deterministically detect and suspend the deobfuscated malicious code when it attempts to access memory resources that have been morphed in accordance with embodiments described herein. This advantageously enables the deobfuscated malicious code to be suspended at its initial phase. By doing so, the malicious code is not given the opportunity to delete its traces in memory regions it accesses, thereby enabling the automated exploration of such memory regions to locate and extract runtime memory characteristics associated with the malicious code.

Abstract: Various automated techniques are described herein for the runtime detection/neutralization of malware executing on a computing device. The foregoing is achievable during a relatively early phase, for example, before the malware manages to encrypt any of the user's files. For instance, a malicious process detector may create decoy file(s) in a directory. The decoy file(s) may have attributes that cause such file(s) to reside at the beginning and/or end of a file list. By doing so, a malicious process targeting files in the directory will attempt to encrypt the decoy file(s) before any other file. The detector monitors operations to the decoy file(s) to determine whether a malicious process is active on the user's computing device. In response to determining that a malicious process is active, the malicious process detector takes protective measure(s) to neutralize the malicious process.

Abstract: Various automated techniques are described herein for protecting computing devices from malicious code injection and execution by providing a malicious process with incorrect information regarding the type and/or version and/or other characteristics of the operating system and/or the targeted program and/or the targeted computing device. The falsified information tricks the malicious process into injecting shellcode that is incompatible with the targeted operating system, program and/or computing device. When the incompatible, injected shellcode attempts to execute, it fails as a result of the incompatibility, thereby protecting the computing device.

Abstract: Embodiments described herein are capable of preventing the installation of unwanted software bundled with a desired application at runtime, while allowing the installation of the desired application to continue as expected. For example, the embodiments described herein create a decoy in memory that preempts unwanted code. The decoy attracts any illegitimate code and diverts it into a dead end (e.g., the code is isolated, thereby preventing it from properly executing), while installation of the legitimate code (i.e., the desired application) flows as expected. The foregoing detects that a reflective loading process of DLL associated with the unwanted application has occurred, identifies the entity that attempted to perform the reflective loading process, and prevents the entity from completing the reflective loading process without terminating the main installer.

Abstract: Embodiments described herein enable the detection, analysis and signature determination of obfuscated malicious code. Such malicious code comprises a deobfuscation portion that deobfuscates the obfuscated portion during runtime to generate deobfuscated malicious code. The techniques described herein deterministically detect and suspend the deobfuscated malicious code when it attempts to access memory resources that have been morphed in accordance with embodiments described herein. This advantageously enables the deobfuscated malicious code to be suspended at its initial phase. By doing so, the malicious code is not given the opportunity to delete its traces in memory regions it accesses, thereby enabling the automated exploration of such memory regions to locate and extract runtime memory characteristics associated with the malicious code.

Abstract: Various approaches are described herein for, among other things, detecting and/or neutralizing attacks by malicious code. For example, instance(s) of a protected process are modified upon loading by injecting a runtime protector that creates a copy of each of the process' imported libraries and maps the copy into a random address inside the process' address space to form a “randomized” shadow library. The libraries loaded at the original address are modified into a stub library. Shadow and stub libraries are also created for libraries that are loaded after the process creation is finalized. Consequently, when malicious code attempts to retrieve the address of a given procedure, it receives the address of the stub procedure, thereby neutralizing the malicious code. When the original program's code (e.g., the non-malicious code) attempts to retrieve the address of a procedure, it receives the correct address of the requested procedure (located in the shadow library).

Abstract: Various automated techniques are described herein for the runtime detection/neutralization of malware executing on a computing device. The foregoing is achievable during a relatively early phase, for example, before the malware manages to encrypt any of the user's files. For instance, a malicious process detector may create decoy file(s) in a directory. The decoy file(s) may have attributes that cause such file(s) to reside at the beginning and/or end of a file list. By doing so, a malicious process targeting files in the directory will attempt to encrypt the decoy file(s) before any other file. The detector monitors operations to the decoy file(s) to determine whether a malicious process is active on the user's computing device. In response to determining that a malicious process is active, the malicious process detector takes protective measure(s) to neutralize the malicious process.

Abstract: Various automated techniques are described herein for protecting computing devices from malicious code injection and execution by providing a malicious process with incorrect information regarding the type and/or version and/or other characteristics of the operating system and/or the targeted program and/or the targeted computing device. The falsified information tricks the malicious process into injecting shellcode that is incompatible with the targeted operating system, program and/or computing device. When the incompatible, injected shellcode attempts to execute, it fails as a result of the incompatibility, thereby protecting the computing device.

Abstract: Various approaches are described herein for the automated classification of exploit(s) based on snapshots of runtime environmental features of a computing process in which the exploit(s) are attempted. The foregoing is achieved with a server and local station(s). Each local station is configured to neutralize operation of malicious code being executed thereon, obtain snapshot(s) indicating the state thereof at the time of the exploitation attempt, and perform a classification process using the snapshot(s). The snapshot(s) are analyzed with respect to a local classification model maintained by the local station to find a classification of the exploit therein. If a classification is found, an informed decision is made as to how to handle the classified exploit. If a classification is not found, the snapshot(s) are provided to the server for classification thereby. The server provides an updated classification model containing a classification for the exploit to the local station(s).

Abstract: Various approaches are described herein for the automated classification of exploit(s) based on snapshots of runtime environmental features of a computing process in which the exploit(s) are attempted. The foregoing is achieved with a server and local station(s). Each local station is configured to neutralize operation of malicious code being executed thereon, obtain snapshot(s) indicating the state thereof at the time of the exploitation attempt, and perform a classification process using the snapshot(s). The snapshot(s) are analyzed with respect to a local classification model maintained by the local station to find a classification of the exploit therein. If a classification is found, an informed decision is made as to how to handle the classified exploit. If a classification is not found, the snapshot(s) are provided to the server for classification thereby. The server provides an updated classification model containing a classification for the exploit to the local station(s).

Abstract: Various approaches are described herein for, among other things, detecting and/or neutralizing attacks by malicious code. For example, instance(s) of a protected process are modified upon loading by injecting a runtime protector that creates a copy of each of the process' imported libraries and maps the copy into a random address inside the process' address space to form a “randomized” shadow library. The libraries loaded at the original address are modified into a stub library. Shadow and stub libraries are also created for libraries that are loaded after the process creation is finalized. Consequently, when malicious code attempts to retrieve the address of a given procedure, it receives the address of the stub procedure, thereby neutralizing the malicious code. When the original program's code (e.g., the non-malicious code) attempts to retrieve the address of a procedure, it receives the correct address of the requested procedure (located in the shadow library).