Ransomware detection and mitigation

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority to U.S. Provisional Application No. 62/526,958, filed Jun. 29, 2017, the entire contents of which are incorporated by reference herein.

FIELD

Embodiments of the disclosure relate to the field of cybersecurity. More specifically, one embodiment of the disclosure relates to a ransomware detection and mitigation system.

GENERAL BACKGROUND

Cybersecurity attacks have become a pervasive problem for organizations as many electronic devices and other resources have been subjected to attack and compromised. An attack may involve the infiltration of malicious software onto an electronic device or concentration on an exploit residing within an electronic device to perpetrate the cybersecurity attack. Both of these types of attacks are the result of “malware.”

In particular, cyber-attacks (e.g., ransomware attacks) have become increasingly common and may lead to the loss of important data. Ransomware is a type of malware that attempts to installs itself covertly on a victim's network device, or is installed covertly, and carries out a cryptoviral extortion by holding data hostage until a ransom is paid. In one situation, ransomware may encrypt data and request a payment to unencrypt the data. Alternatively, ransomware may modify data such that the data is unreadable or otherwise inaccessible and request payment to return the data to its original form. As used herein, the term “unreadable” may be broadly interpreted as data that cannot be displayed by an application corresponding to the file type containing the data (e.g., data of a Portable Document Format (PDF) file that cannot be displayed by Adobe Reader is said to be “unreadable”).

Many current ransomware detection techniques cannot prevent attacks before they happen and thus cause data inaccessibility from “file-zero” (i.e., the first file affected by the ransomware) unless a ransom is paid. Current techniques of monitoring often cannot protect the first file because they rely on post modification detection techniques. Specifically, current ransomware detection techniques typically analyze the victimized system (e.g., a network device or a plurality of network devices) to determine at least the malware that caused the encryption of the data as well as the encryption method. For example, current ransomware detection techniques may analyze a victimized network device to determine a software application or program that was downloaded (e.g., a Trojan which contained the ransomware). A signature of the detected software application or program, or portion thereof containing the ransomware, may be added to a blacklist to be used for future malware scans in an attempt to detect the ransomware before it is executed and its attack is carried out.

However, current ransomware detection techniques fail to protect the initial victimized network device (or plurality of network devices) from ransomware attacks. Thus, the initial ransomware attack may succeed in locking one or more victims out of accessing data that is being held hostage. As a result, the victim or victims, may lose the data or may be forced to pay a ransom in hopes of having the data being held hostage returned. Such a situation may have very negative consequences, especially if accessing the data is time sensitive (e.g., patient data in hospitals). Therefore, enhancements to current ransomware detection systems are needed to prevent the loss of data from “file-zero.”

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the disclosure are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1A is an exemplary block diagram of a general, physical representation of logic components of a ransomware detection and mitigation system illustrated within a network device.

FIG. 1B is an exemplary block diagram of operations of a ransomware detection and mitigation system.

FIG. 2 is an exemplary embodiment of a flowchart illustrating operations of ransomware detection and mitigation system of FIG. 1B.

FIG. 3 is an exemplary embodiment of a flowchart illustrating the operations of determining whether a process being initiated in a computing environment monitored by the ransomware detection and mitigation system is suspicious.

FIG. 4 is an exemplary embodiment of a flowchart illustrating operations of the ransomware detection and mitigation system of FIG. 1 in detecting a ransomware attack and restoring any affected data to a version of the data stored prior to the occurrence of the attack.

FIG. 5 is an exemplary embodiment of a flowchart illustrating operations of copying at least a portion of a protected to a remote storage in response to intercepting an attempt to open the protected file.

FIGS. 6A-6B provide an exemplary embodiment of a flowchart illustrating the operations determining whether a suspicious operation is associated with a ransomware attack following interception of a request to close a protected file.

FIG. 7 is an exemplary embodiment of a logical representation of the ransomware detection and mitigation system 110 of FIGS. 1A-1B.

DETAILED DESCRIPTION

I. Overview Summary

Embodiments of a system and method for ransomware detection and mitigation are described. The ransomware detection and mitigation system provided is capable of detecting a ransomware attack and restoring any affected data to a version of the data stored prior to the occurrence of the attack.

For example, a ransomware detection and mitigation software application, e.g., a software module including monitoring agents and analysis agents, is installed on a network device (e.g., a laptop). The software module monitors software applications on the laptop, for example, Microsoft Outlook, Internet Explorer, etc. The monitoring may include detecting an attempt by a suspicious process, e.g., an instance of the executing software application, to open a file, especially, for example, when the suspicious process includes the ability to write to the file. The software module monitors any modifications made to the file initiated by the suspicious process and analyzes the file when the suspicious process closes the file. The software module determines whether the suspicious process is associated with a cyber-attack (e.g., a cryptoviral attack or a ransomware attack) based on an analysis of at least the entropy (e.g., randomness) of the modification of the file by the suspicious process, whether the file has been modified and is no longer a recognizable file type or able to be opened, and/or whether the file has been encrypted. When the software module determines the suspicious process is associated with a ransomware attack, the software module may generate an alert to the user of the network device, terminate the suspicious process, and quarantine the software application that caused the execution of the suspicious process. As used herein, the term “quarantine” may refer to the movement of a file or folder into a specified location in storage. In one embodiment, the specified location in storage may be isolated so that applications cannot access the data stored therein to prevent infection of an endpoint device, network device, etc.

In one embodiment, the ransomware detection and mitigation system is installed on an endpoint device (e.g., a host device) as a software module that monitors the creation of binaries by applications (often called a “dropped” or “child” process) commonly associated with known threat vectors (i.e., email clients, internet browsers, etc.). If a binary (e.g., an executable) is generated by a monitored application, it is considered “suspicious.” For example, the generation of an executable, or modification thereof, by a monitored application may result in the executable being deemed suspicious by the ransomware detection and mitigation system. Subsequently, the process initiated by the running of the suspicious executable may be deemed a suspicious process by the ransomware detection and mitigation system. The behaviors associated with suspicious processes are monitored by a kernel mode monitor and/or a user mode agent of the ransomware detection and mitigation system. Additionally, a process may be determined to be suspicious based on one or more of the following factors: (i) whether the executable run to initiate the process was obtained through data manipulation by a monitored process (e.g., download, creation or data modification, wherein one specific example may include a “drive by download” that includes the downloading of a binary without consent of a user, or via social engineering), (ii) whether the running of the executable that initiated the process is being monitored by the ransomware detection and mitigation system for the first time (e.g., on the endpoint device on which the ransomware detection and mitigation system is installed), (iii) whether the process is a non-system process (as used herein, a non-system process is a process that is not owned or initiated by the operating system, e.g., a process initiated by an application the execution of which was started by a user), (iv) whether the process and/or executable are on a white list (e.g., a list of executables and/or processes that known to be benign, or includes a trusted digital signature). The ransomware detection and mitigation system may take into account one or more of the factors in determining whether the process is suspicious.

In one ransomware detection and mitigation embodiment, a software module including a user mode agent and a kernel mode agent is installed on an endpoint device. The kernel mode agent may intercept an attempt to launch an application (e.g., the initiation of a process). Herein, the term “launch” (and other tenses) represents performance of one or more events that initiates activation of an object under analysis (that may include an executable the running of which initiates one or more processes). The kernel mode agent signals the interception to the user mode agent, which analyzes the process to determine whether the process should be deemed suspicious. The suspiciousness analysis performed by the user mode agent may include, inter alia, a determination as to whether the executable file of the newly initiated process was generated or modified by a monitored process (e.g., that appears on a predetermined list of processes to monitor), analysis of one or more predetermined static factors of the newly initiated process, a determination as to whether the newly initiated process is a non-system process being analyzed for the first time, etc. The suspiciousness analysis performed by the user mode agent may result in the user mode agent determining a score representing the level of suspiciousness of the newly initiated process (e.g., a probability score, expressed as a number or percentage). If the score is greater than or equal to a predefined threshold, the newly initiated process will be deemed suspicious.

A suspicious process is monitored by the user mode and kernel mode monitors, while the kernel mode agent intercepts any attempt to open a “protected file,” which may be broadly construed as one or more files, one or more folders, one or more file systems and/or any other collection of data in an organized structure, when the suspicious process has permissions to write to, or modify, the protected file. In response to intercepting the attempt to open a protected file with write permissions, the kernel mode agent copies at least a portion of the protected file to storage that is not accessible by the suspicious process. The kernel mode agent may inform the user mode agent of the intercepted attempt to open the protected file. Subsequent to copying at least a portion of the protected file to storage, the kernel mode agent permits the suspicious process to open the protected file and the user mode monitor monitors the behaviors of the suspicious process.

The kernel mode agent intercepts an operation by the suspicious process to close the protected file. Responsive to detecting the close of the protected file, the kernel mode agent may perform an entropy calculation on the protected file and provide the result of the entropy calculation to the user mode agent. The user mode agent may then determine if the protected file is no longer a recognizable file type or able to be opened (e.g., due to modification of at least a portion of the protected file), has been encrypted, and/or the result of the entropy calculation is above a predefined randomness threshold. In one embodiment, the user mode agent determines whether the protected file is no longer recognizable by parsing and analyzing at least a portion of the header of the protected file. For example, the user mode agent reads (e.g., parses) the file header and determines whether the parsed file header is no longer readable. In one embodiment, the determination as to whether the parsed file header is no longer readable may include the user mode agent analyzing the parsed file header for one or more known byte segments indicating that the file header corresponds to a known file header structure. For example, the user mode agent may analyze a predetermined number of bytes starting from the beginning of the protected file, e.g., a byte segment, to determine whether the byte segment includes known indicia of the file type such as, but not limited or restricted to, a file type, a file type specification or version, etc. When the user mode agent detects one or more known byte segments, the protected file header (e.g., following opening and closing of the protected file by the suspicious process) is deemed readable; thus, the suspicious process may be found to be benign (e.g., not associated with a ransomware attack). Alternatively, when the user mode agent does not detect one or more known byte segments, the protected file header is deemed unreadable; thus, the suspicious process may be found to be associated with a ransomware attack.

In a second embodiment, the determination as to whether the parsed file header is no longer readable may include comparing the parsed file header structure (or a portion thereof) against known file header structures for one or more file types. The result of the comparison (e.g., one or more similarity scores) may be used to determine whether the parsed filer header is readable. For example, the parsed file header may be deemed readable when a similarity score is greater than or equal to a predetermined threshold. As an example, when the protected file is a PDF file, the user mode agent may parse the file header and compare the parsed file header structure against the known file header structure for a PDF file to determine a similarity score. When the similarity score is greater than or equal to a predetermined threshold, the protected file header is deemed readable; thus, the suspicious process may be found to be benign (e.g., not associated with a ransomware attack). Alternatively, when the similarity score is less than the predetermined threshold, the protected file header is deemed unreadable; thus, the suspicious process may be found to be associated with a ransomware attack. The known byte segments and the known file header structures may be stored in the storage 104, as shown in FIG. 1.

In one embodiment, the user mode agent may assign scores to: (i) results of an analysis as to whether the protected file has been corrupted (which may refer to, but is not limited or restricted to, modification or alteration of any portion of the protected file such that the content of the protected file has been rendered unreadable and/or inaccessible), (ii) results of an analysis as to whether the protected file has been encrypted and/or the suspicious process used application programming interfaces (APIs) corresponding to encryption methods, or (iii) the result of the entropy calculation. Based on the assigned scores, the user mode agent determines whether a single score or a combination of two or more scores is above a predefined threshold. Based on the analysis, the user mode agent determines whether the suspicious process is associated with a ransomware attack. When the user mode agent determines the suspicious process is associated with a ransomware attack, an alert is generated and the kernel mode agent is instructed to restore the protected file to the version that was copied to storage by the kernel mode agent. In some embodiments, the generated alert may include information obtaining during analysis and monitoring of the suspicious process that identifies the suspicious process and the application responsible for initiating the suspicious process. The alert may also include information identifying one or more operations performed by or caused to be performed by the suspicious process. In some embodiments, the alert may provide information pertaining a source of the application responsible for initiating the suspicious process (e.g., an email, Uniform Resource Locator (URL) from which the application was downloaded, etc.) Furthermore, in some embodiment, the alert may include information pertaining to the origin of the suspicious (e.g., whether a child process and a corresponding parent process, if applicable) and/or whether any child processes were initiated. Thus, the alert may provide the user of the endpoint device, network administrators or the like to perform a targeted remediation process (e.g., terminate the suspicious process, remove the application responsible for initiating the suspicious process, prevent the spread of the application responsible for initiating the suspicious process, etc.) The suspicious process may be terminated and the corresponding application quarantined by the user mode agent.

Alternatively, or in addition to intercepting a request to close the protected file by the suspicious process, the kernel mode monitor may intercept requests by the suspicious process to write to the protected file. Upon intercepting a write request, the kernel mode agent determines whether the location within the protected file to be written to pertains to the header (e.g., based on byte offset set forth in the write request). For example, the kernel mode agent may determine whether the byte offset of the location to be written to is within a predetermined number of bytes from the beginning of the file. When the kernel mode agent determines the write request is attempting to modify the header, the kernel mode agent notifies the user mode agent (e.g., and provides the user mode agent with the bytes attempted to be written). When the user mode agent determines the bytes attempted to be written will corrupt the header, the suspicious process may be found to be associated with a ransomware attack. When the user mode agent determines the bytes attempted to be written will not corrupt the header, thus, the suspicious process may be found to be benign (e.g., not associated with a ransomware attack).

II. Terminology

In the following description, certain terminology is used to describe various features of the invention. For example, each of the terms “logic” and “component” may be representative of hardware, firmware or software that is configured to perform one or more functions. As hardware, the term logic (or component) may include circuitry having data processing and/or storage functionality. Examples of such circuitry may include, but are not limited or restricted to a hardware processor (e.g., microprocessor, one or more processor cores, a digital signal processor, a programmable gate array, a microcontroller, an application specific integrated circuit “ASIC”, etc.), a semiconductor memory, or combinatorial elements.

Additionally, or in the alternative, the logic (or component) may include software such as one or more processes, one or more instances, Application Programming Interface(s) (API), subroutine(s), function(s), applet(s), servlet(s), routine(s), source code, object code, shared library/dynamic link library (dll), or even one or more instructions. This software may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of a non-transitory storage medium may include, but are not limited or restricted to a programmable circuit; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); or persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device. As firmware, the logic (or component) may be stored in persistent storage.

Herein, a “communication” generally refers to related data that is received, transmitted, or exchanged within a communication session. The data may include a plurality of packets, where a “packet” broadly refers to a series of bits or bytes having a prescribed format. Alternatively, the data may include a collection of data that may take the form of an individual or a number of packets carrying related payloads, e.g., a single webpage received over a network.

The term “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware.

The term “agent” generally refers to a module of software installed on a target system (e.g., an endpoint device) that enables a user (e.g., a human such as an administrator or an external computer system) to monitor and interact with the target system. Agents allow users to gather information about multiple aspects of the target system. Agents also permit users to remotely retrieve the contents of the target system's memory or hard drive, and could potentially be configured to modify its contents. The agent may be configured to either communicate over a computer network, or to read and write all relevant configuration information and acquired data to a computer storage medium, such as a hard drive or removable read/write media (USB key, etc.). In one embodiment, the agent is built in a modular fashion. The ability to gather a particular piece of data from a target system (e.g. a list of running processes on the target system or a log file or timeline) is implemented as a discrete module of software and loaded by the agent. This allows for easy adaptation of the agent to different environments that have specific requirements for data collection.

According to one embodiment of the disclosure, the term “malware” may be broadly construed as any code, communication or activity that initiates or furthers a cyber-attack. Malware may prompt or cause unauthorized, anomalous, unintended and/or unwanted behaviors or operations constituting a security compromise of information infrastructure. For instance, malware may correspond to a type of malicious computer code that, as an illustrative example, executes an exploit to take advantage of a vulnerability in a network, network device or software, for example, to gain unauthorized access, harm or co-opt operation of a network device or misappropriate, modify or delete data. Alternatively, as another illustrative example, malware may correspond to information (e.g., executable code, script(s), data, command(s), etc.) that is designed to cause a network device to experience anomalous (unexpected or undesirable) behaviors. The anomalous behaviors may include a communication-based anomaly or an execution-based anomaly, which, for example, could (1) alter the functionality of a network device executing application software in an atypical manner; (2) alter the functionality of the network device executing that application software without any malicious intent; and/or (3) provide unwanted functionality which may be generally acceptable in another context.

A “characteristic” includes data associated with an object under analysis that may be collected without execution of the object such as metadata associated with the object (e.g., size, name, path, etc.) or content of the object (e.g., portions of code) without execution of the selected object. A “behavior” is an activity that is performed in response to execution of the object.

The term “network device” may be construed as any electronic computing system with the capability of processing data and connecting to a network. Such a network may be a public network such as the Internet or a private network such as a wireless data telecommunication network, wide area network, a type of local area network (LAN), or a combination of networks. Examples of a network device may include, but are not limited or restricted to, an endpoint device (e.g., a laptop, a mobile phone, a tablet, a computer, etc.), a standalone appliance, a server, a router or other intermediary communication device, a firewall, etc.

The term “transmission medium” may be construed as a physical or logical communication path between two or more network devices or between components within a network device. For instance, as a physical communication path, wired and/or wireless interconnects in the form of electrical wiring, optical fiber, cable, bus trace, or a wireless channel using radio frequency (RF) or infrared (IR), may be used. A logical communication path may simply represent a communication path between two or more network devices or between components within a network device.

Finally, the terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

III. General Architecture

Referring now to FIG. 1A, an exemplary block diagram of a general, physical representation of logic components of a ransomware detection and mitigation system illustrated within a network device is shown. Herein, the ransomware detection and mitigation system 110 is shown as being installed on an endpoint device 100 (e.g., a laptop computer), which includes one or more processors 102, a persistent storage 104 (e.g., a non-transitory computer-readable medium storage), a file system 106 and one or more software applications 108. The ransomware detection and mitigation system 110 is shown to include a user mode agent 112 (e.g., a user agent) and a kernel mode agent 114.

The endpoint device 100 includes one or more interfaces which include network interfaces and/or input/output (I/O) interfaces 116. According to this embodiment of the disclosure, these components are connected by a transmission medium, not shown, such as any type of interconnect (e.g., bus), are at least partially encased in a housing 118 made entirely or partially of a rigid material (e.g., hardened plastic, metal, glass, composite, or any combination thereof). The housing 118 protects these components from environmental conditions.

Referring to FIG. 1B, an exemplary block diagram of operations of a ransomware detection and mitigation system is shown. The ransomware detection and mitigation system 110 is shown located in both the user space (e.g., upper section) and the kernel space (e.g., lower section), e.g., includes components located in each space. The user mode agent 112 of the ransomware detection and mitigation system 110 is located in user space while the kernel mode agent 114 is located in kernel space. FIG. 1B illustrates exemplary interactions between the user mode agent 112, the kernel mode agent 114, storage 104, the file system 106 and a suspicious process 120. The interactions, referenced by circled numbers, correspond to operations of one or more of the components illustrated. Initially, in one embodiment, the ransomware detection and mitigation system begins a detection and mitigation process by intercepting, by the kernel mode agent 114, an attempt to launch an application and initiate a process. In response, the kernel mode agent 114 notifies the user mode agent 112 of the interception (operation 1). The user mode agent 112 analyzes the initiated process to determine whether the process is suspicious (operation 2). The determination of suspiciousness includes a determination as to one or more of the following factors: (i) whether the executable of the launched application was obtained via data manipulation (e.g., written, created, or downloaded) by a monitored process, (ii) whether the execution of the launched application is being monitored by the ransomware detection and mitigation system for the first time, (iii) whether the process is a non-system process, (iv) whether the process and/or executable are on a white list, (v) whether the process is signed by a whitelisted digital signature, and/or (iv) whether the process is a child process of a suspicious process. The ransomware detection and mitigation system may take into account one or more of the factors in determining whether the process is suspicious (hereinafter, the process will be referred to as the suspicious process 120).

Operations of the suspicious process 120 are monitored by the ransomware detection and mitigation system 110. During monitoring of the suspicious process 120, the kernel mode agent 114 may intercept an attempt by the suspicious process 120 to open a protected file (operation 3). The interception of an attempt to open a protected file may be done by the kernel mode agent 114 as access to the file system 106, located within the kernel space, will be requested. Further, in one embodiment, the kernel mode agent 114 may only intercept an attempt by the suspicious process 120 to access protected files when the attempted access is performed with the suspicious process 120 having at least “write” permissions (e.g., corresponding to the well-known file permissions of read, write and execute).

As a result of the attempted access of the protected file by the suspicious process 120, the kernel mode agent 114 accesses the file system (operation 4) and copies at least the portion of the protected file being accessed to storage 104 (operation 5). A purpose of copying at least the portion of the protected file being accessed to storage 104 is to save the state (e.g., contents, metadata, etc.) of the protected file prior to providing the suspicious process 120 access thereto. Thus, by saving a copy of at least a portion of the protected file prior to providing access to the suspicious process 120, the ransomware detection and mitigation system 110 is able to prevent and/or mitigate the effects of a ransomware attack. Specifically, as will be discussed below, when the suspicious process 120 is determined to be associated with a ransomware attack, the encrypted or corrupted protected file can be restored to a prior state with the copy stored in the storage 104.

After copying at least a portion of the protected file to the storage 104, the kernel mode agent 114 may provide the suspicious process 120 with access to the protected file. During processing, the suspicious process 120 may modify the protected file or encrypt the protected file (operation 6). In one embodiment, the kernel mode agent 114 may intercept the attempt to modify or encrypt the protected file to ensure the portion of the protected file being modified or encrypted has been copied to the storage 104 and/or copy the portion of the protected file being modified or encrypted to the storage 104. During further monitoring of the suspicious process 120, the kernel mode agent 114 may intercept a close request by the suspicious process 120 to close the protected file (operation 7). Subsequent to intercepting the close request, the kernel mode agent 114 may analyze the protected file. In one embodiment, the analysis of the protected file by the kernel mode agent 114 includes an entropy calculation to determine a level of the randomness of any modifications made by the suspicious process 120. The kernel mode agent 114 notifies the user mode agent 112 of the file close and provides the user mode agent 112 with results of the analysis (e.g., a result of the entropy calculation) (operation 8).

The user mode agent 112 also performs an analysis on the protected file (operation 9) to determine if the protected file has been modified in such a way that the protected file is no longer useable and/or readable by an associated application. For example, in one embodiment, the user mode agent 112 may analyze any modifications made to the header of the protected file to determine whether the header was modified to render the content of the protected file corrupted. Additionally, the analysis performed by the user mode agent 112 may include an analysis of the operations performed by or caused to be performed by the suspicious process 120. For example, the analysis may include a determination as to whether the suspicious process 120 used any cryptographic APIs (such a determination may be done with information provided by the kernel mode agent 114). The user mode agent 112 may assign a score to one or more of (i) the result of the entropy calculation, e.g., whether the resultant level of entropy is greater than or equal to a first threshold, or a score based on a sliding scale according to the resultant level of entropy, (ii) the result of the determination as to whether the protected file, particularly its header, was modified in such a way that the protected file is no longer useable and/or readable, and/or (iii) the result of the determination as to whether the suspicious process 120 used any cryptographic APIs. Based on any one score, or a combination of two or more of scores, the user mode agent 112 determines whether the suspicious process 120 is associated with ransomware or with a ransomware attack.

In response to determining the suspicious process 120 is associated with ransomware or with a ransomware attack, the user mode agent 112 notifies the kernel mode agent 114 and instructs the kernel mode agent 114 to restore the protected file to a prior state using the copy stored in the storage 104 (operation 10). Additionally, the user mode agent 112 may terminate and/or quarantine the suspicious process 120 (operation 11). Finally, user mode agent 112 may generate an alert 122 to notify a user of the endpoint on which the ransomware detection and mitigation system 110 is running of the presence of a ransomware attack (operation 12).

Referring to FIG. 2, an exemplary embodiment of a flowchart illustrating operations of ransomware detection and mitigation system of FIG. 1B is shown. Each block illustrated in FIG. 2 represents an operation performed in the method 200 of monitoring the processing of a suspicious process in order to determine whether the application that launched the suspicious process is associated with ransomware or a ransomware attack by the ransomware detection and mitigation system. Herein, the ransomware detection and mitigation system monitors the processing of one or more applications within a computing environment. In one embodiment, the ransomware detection and mitigation system may operate and monitor the one or more applications processing in real-time in the computing environment as the electronic device is operates. In a second embodiment, the ransomware detection and mitigation system may operate and monitor the one or more applications processing within a virtualized computing environment. Herein, the term “computing environment” may be used to refer to either a real-time computing environment and/or a virtualized computing environment. The method 200 begins when an application is launched within the computing environment initiating a process (block 202). Specifically, a kernel mode agent of the ransomware detection and mitigation system intercepts the launch of the application and the initiation of the process (block 204).

The user mode agent of the ransomware detection and mitigation system is notified of the interception and determines whether the process is suspicious (block 206). As discussed above, the determination as to whether of suspiciousness includes a determination as to one or more of the following factors: (i) whether the executable of the launched application was written, created, or downloaded by a monitored process, (ii) whether the executable of the launched application is being monitored by the ransomware detection and mitigation system for the first time, (iii) whether the process is a non-system process, (iv) whether the process and/or executable are on a white list, (v) whether the process is signed by a whitelisted digital signature. The ransomware detection and mitigation system may take into account one or more of the factors in determining whether the process is suspicious.

Responsive to determining the process is suspicious, the operations, directly or indirectly, caused by the suspicious process are monitored. In particular, the kernel mode agent may intercept an attempt, by the suspicious process, to open a protected file (block 208). Prior to providing the suspicious process with access to the protected file, the kernel mode agent copies at least a portion of the protected file to a secure storage location (block 210). As discussed above, in one embodiment, the kernel mode agent may copy the entire protected file to the secure storage location. As an alternative embodiment, the kernel mode agent may copy a portion of the protected file less than the entire file to the secure storage location.

After copying at least a portion of the protected file to the secure storage location, the kernel mode agent provides the suspicious process with access to the protected file (block 212). After providing the suspicious process with access to the protected file, the ransomware detection and mitigation system continues to monitor the operations, directly or indirectly, caused by the suspicious process. During the monitoring following the provision of access to the protected file, the kernel mode agent may intercept system calls by the suspicious process to close the protected file (block 214). For example, the kernel mode agent may intercept a close request from the suspicious process to close the protected file and/or a request by the suspicious process to rename a protected file.

Responsive to intercepting the close request by the suspicious process, the ransomware detection and mitigation system determines whether the suspicious process is part of a ransomware attack based on an analysis of one or more of: (i) an entropy calculation, e.g., whether the resultant level of entropy is greater than or equal to a first threshold, or a score based on a sliding scale according to the resultant level of entropy, (ii) whether the protected file, particularly its header, was modified in such a way that the protected file is no longer useable, accessible and/or readable, and/or (iii) whether the suspicious process used any cryptographic APIs (block 216). As will be discussed in more detail below with respect to FIG. 3, the determination as to whether the suspicious process is associated with a ransomware attack may take into account one or more factors and, in some embodiments, a combination of one or more factors.

Referring now to FIG. 3, an exemplary embodiment of a flowchart illustrating the operations of determining whether a process being initiated in a computing environment monitored by the ransomware detection and mitigation system is suspicious is shown. Each block illustrated in FIG. 3 represents an operation performed in the method 300 of performing a pre-processing determination as to whether the process being initiated is suspicious, e.g., associated with an application that is potentially ransomware or associated with a ransomware attack. Herein, the user mode agent of the ransomware detection and mitigation system performs a static analysis on the process (block 302). The method 300 continues with the user mode agent performing a correlation of one or more factors observed during a static analysis (block 304). At block 306, the user mode agent determines whether the correlation result is greater than or equal to a predefined threshold. The user mode agent assigns a first score to the result of the correlation (block 308).

The user mode agent also determines whether the executable file corresponding to the initiation of the process was written by a monitored process (block 310). The user mode agent then assigns a second score to the result of the determination as to whether the executable was written by a monitored process (block 312).

Furthermore, the user mode agent also determines whether the process is a non-system process being analyzed by the ransomware detection and mitigation system for the first time (block 314). The user mode agent then assigns a third score to the result of the determination as to whether the process is a non-system process being analyzed for the first time (block 316).

In one embodiment, following assignment of the first, second and third scores, the user mode agent determines whether one of the scores is greater than or equal to a corresponding predefined threshold (block 318). When the user mode agent determines at least one score is greater than or equal to a corresponding predefined threshold (yes at block 318), the user mode agent determines the process is suspicious (block 322). When the user mode agent determines each of the first, second and third scores are each less than the corresponding predefined thresholds (no at block 318), the user mode agent determines whether a combination of two or more of the first score, the second and/or the third score are greater than or equal to a predefined combined threshold. When the user mode agent determines the combination of two or more of first score, the second and/or the third score is greater than or equal to the predefined combined threshold (yes at block 320), the user mode agent determines the process is suspicious (block 322). When the user mode agent determines no combination of two or more of first score, the second and/or the third score is greater than or equal to the predefined combined threshold (no at block 318), the user mode agent determines the process is not suspicious (block 324).

The scoring process as described herein may refer to a plurality of separate scores. In an alternative embodiment, the assignment of a second score may be an adjustment or modification of the first assigned score. Similarly, the assignment of a third score may refer either to the assignment of a third score separate from the assignment of the first and/or second scores or a modification of the first and/or second scores.

Referring now to FIG. 4, an exemplary embodiment of a flowchart illustrating operations of the ransomware detection and mitigation system of FIG. 1 in detecting a ransomware attack and restoring any affected data to a version of the data stored prior to the occurrence of the attack is shown. Each block illustrated in FIG. 4 represents an operation performed in the method 400 of detecting a ransomware attack and restoring any affected data to a version of the data stored prior to the occurrence of the attack. Herein, the kernel mode agent (KMA) intercepts an attempt by a suspicious process to open a protected file with write permissions (block 402). In response to intercepting the attempt to open a protected file with write permissions, the KMA copies at least a portion of the protected file to storage, as will be discussed in detail with respect to FIG. 5 (block 404).

Subsequent to the KMA copying at least a portion of the protected file to storage, the KMA permits the suspicious process to open and access the protected file with write permissions (block 406). Additionally, the KMA intercepts a request by the suspicious process to close the protected file (block 406). In response to intercepting the request to close the protected file by the suspicious process, the user mode agent determines whether the content of the protected file is corrupted (e.g., modified in such a way the protected file is so longer accessible, encrypted, etc.) (block 408). When the user mode agent determines the protected file is corrupted (yes at block 408), the user mode agent instructs the KMA to restore the protected file to a previous version, e.g., the version saved in the storage prior to permitting the suspicious process to access the protected file (block 410). In addition to restoring the protected file to a prior version, the user mode agent may generate an alert that may be transmitted to one or more of a network administrator, security administrator, network security and forensics analyst, and the like (“administrator”) or a user of the endpoint device (block 412A) and terminate and/or quarantine the suspicious process (block 412B). In addition, the corrupted file may be one or more of: (i) deleted, (ii) quarantined for additional analyses by the ransomware detection and mitigation system, and/or (iii) provided to an administrator for additional analyses by a remote analysis system. When the user mode agent determines the protected file is not corrupted (e.g., not modified to be unreadable or otherwise inaccessible, not encrypted, etc.) (no at block 408), the user mode agent determines the suspicious process did not perform operations associated with a ransomware attack and discards the copy of the protected file (block 414).

Referring now to FIG. 5, an exemplary embodiment of a flowchart illustrating operations of copying at least a portion of a protected to a remote storage in response to intercepting an attempt to open the protected file is shown. Each block illustrated in FIG. 5 represents an operation performed in the method 500 of intercepting an attempt to open a protected file and copying at least a portion of the protected file to a remote storage as a result. Herein, during monitoring of a suspicious process, the kernel mode agent of the ransomware detection and mitigation system intercepts an attempt, by the suspicious process, to open a protected file with write permissions (block 502). In response to intercepting the attempt to open the protected file, the kernel mode agent notifies the user mode agent of the interception. The user mode agent subsequently determines whether the size of the protected file is greater than or equal to a predetermined file size threshold (block 504). However, in a second embodiment, the kernel mode agent may make the determination as to whether the protected file is greater than or equal to the predetermined file size threshold.

When the user mode agent determines the protected file is greater than or equal to the predetermined file size threshold (yes at block 504), the user mode agent instructs the kernel mode agent to copy a portion of the protected file, e.g., a subset of the entire protected file, to a secure, remote location (block 506). When the user mode agent determines the protected file is less than the predetermined file size threshold (no at block 504), the user mode agent instructs the kernel mode agent to copy the entire protected file to a secure, remote location (block 508). Following either blocks 506 or 508, the kernel mode agent permits the suspicious file to open the original protected file while prohibiting access to the copy (block 510).

Referring to FIGS. 6A-6B, an exemplary embodiment of a flowchart illustrating the operations determining whether a suspicious operation is associated with a ransomware attack following interception of a request to close a protected file is shown. Each block illustrated in FIGS. 6A-6B represents an operation performed in the method 600 of determining whether a suspicious operation is associated with a ransomware attack following interception of a request to close a protected file. Herein, during monitoring of a suspicious process by the ransomware detection and mitigation system, the kernel mode agent (KMA) of the ransomware detection and mitigation system intercepts a request by the suspicious process to close a protected file opened by the suspicious process with write permissions (block 602). Responsive to intercepting the request to close the protected file, the KMA performs an entropy calculation on the protected file (block 604). The KMA subsequently provides the result of the entropy calculation to the user mode agent (block 606).

The user mode agent analyzes the result of the entropy calculation and additional information collected by the user mode agent (block 608). The additional information may include, but is not limited or restricted to, information collected by the user mode agent during monitoring of the suspicious process such as operations performed by the suspicious process, the result of operations performed by the suspicious process, use of encryption APIs by the suspicious process, etc. The user mode agent then makes a determination as to whether the protected file has been modified by the suspicious process such that the content of protected file is corrupted (block 610).

When the user mode agent determines that the protected file has been modified by the suspicious process to be corrupted (yes at block 610), the user mode agent instructs the KMA to restore the protected file to a previous version, e.g., a version saved in the storage prior to permitting the suspicious process to access the protected file (block 614A of FIG. 6B). In addition to restoring the protected file to a prior version, the user mode agent may generate an alert notifying administrators or a user of the endpoint device (block 614B) and terminate and/or quarantine the suspicious process (block 614C). When the user mode agent determines that the protected file has not been modified by the suspicious process such that the content of the protected file is corrupted (no at block 610), the user mode agent makes a determination as to whether the result of the entropy calculation is greater than or equal to a first threshold (block 612).

When user mode agent determines the result of the entropy calculation is greater than or equal to a first threshold (yes at block 612), the user mode agent instructs the KMA to restore the protected file to a previous version (block 614A of FIG. 6B). In addition to restoring the protected file to a prior version, the user mode agent may generate an alert notifying administrators or a user of the endpoint device (block 614B) and terminate and/or quarantine the suspicious process (block 614C).

When user mode agent determines the result of the entropy calculation is not greater than or equal to a first threshold (no at block 612), the user mode agent makes a determination as to whether the protected file has been encrypted by the suspicious process (block 616).

When the user mode agent determines that the protected file has been encrypted by the suspicious process (yes at block 614), the user mode agent instructs the KMA to restore the protected file to a previous version (block 612A), generates an alert notifying administrators or a user of the endpoint device (block 612B), and terminates and/or quarantines the suspicious process (block 612C). When the user mode agent determines that the protected file has not been encrypted by the suspicious process (no at block 614), the user mode agent generates an identifier of the application that caused the suspicious process to launch for use in future analysis (block 616).

Now referring to FIG. 7, an exemplary embodiment of a logical representation of the ransomware detection and mitigation system 110 of FIGS. 1A-1B. The ransomware detection and mitigation system 110, in an embodiment may be stored on a non-transitory computer-readable storage medium of an endpoint device that includes a housing 700, which is made entirely or partially of a hardened material (e.g., hardened plastic, metal, glass, composite or any combination thereof) that protects the circuitry within the housing 700, namely one or more processors 702 that are coupled to a communication interface 705 via a first transmission medium 703. The communication interface 704, in combination with a communication logic 716, enables communications with external network devices and/or other network appliances to receive updates for the ransomware detection and mitigation system 110. According to one embodiment of the disclosure, the communication interface 704 may be implemented as a physical interface including one or more ports for wired connectors. Additionally, or in the alternative, the communication interface 704 may be implemented with one or more radio units for supporting wireless communications with other electronic devices. The communication interface logic 716 may include logic for performing operations of receiving and transmitting one or more objects via the communication interface 704 to enable communication between the generated ransomware detection and mitigation system 110 and network devices via the a network (e.g., the internet) and/or cloud computing services.

The processor(s) 702 is further coupled to a persistent storage 706 via a second transmission medium 705. According to one embodiment of the disclosure, the persistent storage 706 may include, (i) a user mode agent 112, one or more applications 710₁-710₁ and the communication interface logic 712 in a user space 708, and (ii) a kernel mode agent 114, an operating system 716 and a file system 718 in a kernel space 714. Of course, when implemented as hardware, one or more of these logic units could be implemented separately from each other.

In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims.