Anti-ransomware using machine learning

Abstract

Data is received that includes or characterizes executable files and dynamic link libraries (DLLs). Features are then extracted from the executable files and DLLs. The extracted features are input to at least one machine learning model to generate a suspiciousness score. The machine learning model can be trained to determine whether the executable files contain ransomware. A confidence score for an execution chain of the executable files and DLLs can then be determined based on the extracted features and the suspiciousness score. The confidence score for the execution chain of the executable files and DLLs characterizes one or more associated parent processes. The suspiciousness score and the confidence score for the execution chain can be used to determine whether to initiate one or more ransomware countermeasures. Related apparatus, systems, techniques, and articles are also described.

Description

[Technical field]

[0001] (Related Applications) This application claims priority to U.S. patent application Ser. No. 63 / 311,684, filed February 18, 2022, which is a continuation of U.S. patent application Ser. No. 18 / 170,415 and 18 / 170,441, filed February 16, 2023, the contents of each of which are incorporated herein by reference in their entirety.

[0002] (Technical field) The subject matter described herein relates to the use of advanced techniques to prevent or circumvent ransomware from infiltrating and exploiting one or more computing systems. [Background technology]

[0003] (background) Ransomware is an increasingly prevalent type of malicious software (malware) that permanently blocks access to personal or corporate data until a ransom is paid. In particular, personal or corporate data is encrypted (often in-place) and the means to decrypt such data is provided only after receipt of payment (often in cryptocurrency). Summary of the Invention [Means for solving the problem]

[0004] (overview) In a first aspect, data including or characterizing executable files and dynamic link libraries (DLLs) is received. Features are then extracted from the executable files and DLLs. The extracted features are input to at least one machine learning model to generate a suspiciousness score. The machine learning model can be trained to determine whether the executable files contain ransomware. A confidence score for an execution chain of the executable files and DLLs can then be determined based on the extracted features and the suspiciousness score. The confidence score for the execution chain of the executable files and DLLs characterizes one or more associated parent processes. The suspiciousness score and the confidence score for the execution chain can be used to determine whether to initiate one or more ransomware countermeasures.

[0005] The one or more ransomware countermeasures may include restricting functionality of processes associated with executable files and DLLs if the execution chain trust score is within a first range, and blocking processes associated with executable files and DLLs if the suspiciousness score is within a second range different from the first range, the second range indicating a higher level of suspiciousness than the first range.

[0006] One or more ransomware countermeasures may include initiating a tripwire process in which processes associated with executable files and DLLs are subject to a higher level of monitoring.

[0007] One or more ransomware countermeasures may include initiating one or more processes to stimulate actions indicative of ransomware by executable files and DLLs.

[0008] If executables and DLLs have no associated parent process (i.e., the process is a root process), the suspiciousness score may be 0.

[0009] The executables and / or DLLs may be accessed or executed by an endpoint having an agent thereon. The agent may extract one or more features from the executables and / or DLLs and transmit the extracted one or more features to a remote server that runs at least one machine learning model. The remote server may take a variety of forms, including a bastion host and / or a server configured to host a single application or process to minimize vulnerability to ransomware attacks.

[0010] The features may be generated based on a variety of aspects including one or more of active processes using application programming interfaces (APIs) when executables and / or DLLs are accessed, reputation information about executables and / or DLLs or modules utilized by active processes, system-wide changes, or patch-level changes. These generated features may be further input into at least one machine learning model to generate a suspiciousness score.

[0011] One or more ransomware countermeasures may include creating a shadow copy of the file of interest. The shadow copy may be a Volume Snapshot Service (VSS) that creates a snapshot accessible through a key recovery mechanism.

[0012] One or more ransomware countermeasures can include delaying deletion of the file of interest, which can be accomplished by hooking a region of a file system or a kernel call such that the file of interest is temporarily moved whenever a deletion attempt occurs.

[0013] In a related aspect, access to executable files and / or dynamic link libraries (DLLs) across various nodes of a distributed computing environment is monitored. One or more features are extracted from each executable file and / or DLL accessed. The extracted features are input to at least one machine learning model to generate a suspiciousness score for each executable file and / or DLL accessed. The at least one machine learning model can be trained to determine whether an executable file contains ransomware. The extracted features and the suspiciousness score are then used to determine a confidence score for each executable file and / or DLL characterizing one or more associated parent processes. One or more ransomware countermeasures may be initiated if one or both of the suspiciousness score and the execution chain confidence score exceed a predetermined threshold.

[0014] The one or more ransomware countermeasures are activated only on a node that accesses the corresponding executable files and / or DLLs. The one or more ransomware countermeasures may be activated on multiple nodes, including the node that accesses the corresponding executable files and / or DLLs.

[0015] In another interrelated aspect, data is received that includes or characterizes an executable file and / or a DLL. One or more features are then extracted from the received data that indicate both (i) a confidence level of an execution chain that characterizes one or more events preceding a requested execution event specified in the executable file or DLL, and (ii) the presence of suspiciousness indicators. The extracted features are input to at least one machine learning model trained to determine whether the executable file and / or DLL contains ransomware. The executable file and / or DLL can be prevented from executing or continuing to execute based on a determination that the executable file and / or DLL contains ransomware. Additionally, the executable file and / or DLL can be allowed to execute or continue to execute based on a determination that the executable file and / or DLL does not contain ransomware.

[0016] In a further interrelated aspect, access to executable files is monitored across each of a number of nodes (e.g., endpoints, servers, etc.) forming part of the computing environment. Features are extracted for each executable file indicative of each of: (i) a trust level of an execution chain characterizing one or more events preceding a requested execution event; (ii) the presence of suspiciousness indicators; and (iii) an event associated with access of the executable file. The extracted features are input to at least one machine learning model trained to determine whether the executable file contains ransomware. The executable file is prevented from executing or continuing to execute based on a determination that the executable file contains ransomware. Otherwise, the executable file is permitted to execute or continue to execute based on a determination that the executable file does not contain ransomware.

[0017] In a further interrelated aspect, an executable file is initiated to execute in an operating environment. Thereafter, characteristics associated with the execution of the executable file are continualy monitored. The executable file is then determined to have one or more characteristics associated with ransomware. In response to such determination, at least one simulacrum is injected into the operating environment to attempt to trigger anti-detonation protection features by the executable file. One or more ransomware countermeasures can then be initiated based on the behavior of the executable file following injection of the at least one simulacrum.

[0018] At least one simulacrum may be or include a software executable or process that simulates characteristics of an operating environment to amplify the operation of the ransomware and / or trigger the self-destruction of the ransomware.

[0019] Information regarding the ransomware (e.g., information characterizing interactions with at least one simulacra byproduct) may be collected by the entrapment component.

[0020] The at least one simulacra is capable of obscuring at least one system component of the operating environment.

[0021] At least one simulacra is capable of changing an identification type of at least one system component of the operating environment.

[0022] At least one simulacra is capable of initiating a sandbox environment in which executables are executed and monitored by a virtual machine.

[0023] At least one simulacra is capable of spoofing or altering the location of endpoints that form part of the operating environment.

[0024] At least one of the simulacra is capable of deploying decoy files that appear to contain sensitive information accessed by the ransomware.

[0025] At least one simulacrum can generate fake servers that interact with the ransomware to verify malicious intent and / or neutralize the ransomware.

[0026] At least one simulacrum can generate fake servers that interact with the ransomware to verify malicious intent and / or neutralize the ransomware.

[0027] At least one simulacrum can cause the ransomware to conclude that the corresponding endpoint or server accessing the executable file is worthless.

[0028] At least one simulacra may indicate that the corresponding endpoint or server is a virtual machine.

[0029] At least one simulacrum is capable of hiding files of interest from ransomware.

[0030] At least one simulacrum can generate artifacts that ransomware would generate to prevent the ransomware from performing certain actions, such generated artifacts can include mutexes, flag files, or custom file extensions to prevent the ransomware from double encrypting data in the operating environment.

[0031] At least one simulacra may simulate the presence of multiple endpoint protection products on each endpoint and / or server forming part of the operating environment, and attempts to disable such multiple endpoint protection products are monitored.

[0032] At least one of the simulacra is able to simulate the presence of backup software, which the ransomware attempts to stop and delete previous backups.

[0033] At least one of the simulacra is able to simulate the presence of backup software, which the ransomware attempts to stop and delete previous backups.

[0034] Also described are non-transitory computer program products (i.e., physically embodied computer program products) that store instructions that, when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform the operations described herein. Similarly, computer systems including one or more data processors and a memory coupled to the one or more data processors are described. The memory can store, either temporarily or permanently, instructions that cause at least one processor to perform one or more operations described herein. Furthermore, one or more data processors can implement the methods within a single computing system or distributed across two or more computing systems. Such computing systems can be connected to exchange data and / or commands or other instructions, etc., via one or more connections, including, but not limited to, connections via a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.), connections via a direct connection between one or more of the computing systems, etc.

[0035] The subject matter described in this specification provides many technical advantages, including enhanced ransomware detection before the ransomware executes, and advanced techniques to combat ransomware after it begins to execute.

[0036] The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will become apparent from the detailed description and drawings, and from the claims. [Brief description of the drawings]

[0037] [Figure 1] Figure 1 is a first diagram showing an architecture for preventing ransomware using machine learning.

[0038] [Diagram 2] Figure 2 is a second diagram showing an architecture for preventing ransomware using machine learning.

[0039] [Diagram 3] FIG. 3 is a first process flow diagram for preventing ransomware using machine learning.

[0040] [Figure 4] FIG. 4 is a second process flow diagram for preventing ransomware using machine learning.

[0041] [Diagram 5] FIG. 5 illustrates an embodiment of a computing device for implementing aspects of the present subject matter. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] (Detailed Description) FIG. 1 is an exemplary architecture diagram directed to computing resources of an organization 110 monitored in part over a computer network 120 (e.g., the Internet, etc.) by an anti-ransomware monitoring system 130. The organization computing resources 110 may include multiple endpoints 112 (i.e., endpoint computing devices, etc.), multiple servers 114, and, as described below, multiple aggregators 116. The aggregators 116 may include dedicated computing devices and / or software running on one of the endpoints 112 or servers 114 within the organization. Agents operated and / or monitored by the monitoring system 130 may be deployed on the endpoints 112 and servers 114. The agents may collect data, monitor events, respond to events, and perform operations on the computing devices on which they are installed. These agents may identify and provide relevant information regarding potential ransomware attacks or other malicious activity.

[0043] The monitoring system 130 may include various computing devices separated by tenant systems 132 (i.e., data related to the organization may be maintained separately from data related to other entities / organizations). The tenant systems 132 may store organizational information, configuration information, and communicate with agents located on the organization's network. In the absence of the aggregator 116, the aforementioned agents may communicate directly with the corresponding tenant systems 132, which may result in some reduced functionality.

[0044] The monitoring system 130 may include various computing devices for analyzing or processing incoming data feeds 134 (received via the network 120) associated with the organization's computing resources 110 or from other external sources. Additionally, the monitoring system 130 may include an analysis server 136 that may analyze the data feeds 134 to assess whether software executed by the organization's computing resources 110 may contain ransomware or malware. This analysis may be performed at various granularities, from the event / process level to orchestration (i.e., data exchange, etc.) between different computing devices. In other words, the monitoring system 130 is responsible for storing, processing, and creating and distributing detection logic.

[0045] As mentioned above, the aggregators 116 may be located within the enterprise computing resources 110. The aggregators 116 may perform a variety of functions. As an example, the aggregators 116 may act as local distributors of information to reduce the bandwidth requirements of the product (i.e., they reduce the amount of network traffic to and from the monitoring system 130). The aggregators 116 may also act as bastion hosts that allow the monitoring system 130 to perform operations on the customer's network outside of the agents. A bastion host is a special purpose computer on an organization's network that is specifically defined and configured to withstand attacks. In such a scenario, the aggregators 116 may host a single application or process to minimize the threat of such a computer (as opposed to running multiple applications, which would increase the overall threat level of the aggregators 116).

[0046] FIG. 2 illustrates various components that may form part of the agent. The aggregator 210 is responsible for initiating all of the measurement components (described in more detail below), collecting data generated by such measurement components, and passing such data directly or indirectly to an aggregator outside the system (e.g., an aggregator forming part of the monitoring system 130). The executor 230 can refine the information through integration of the inputs, such as looking at statistics of individual inputs, combining disparate inputs, or using models to derive higher level meaning from the base inputs, and can execute decision logic that can cause certain software / processes to run / continue to run, etc. The executor 230 can also be used to launch optional components, such as sandboxes, file system virtualization and isolation, and components that affect the performance of a process but are desirable if the process meets a suspiciousness level.

[0047] 2, there may be a number of measurement components 240-290 that provide data to the aggregator 210 and / or may be invoked by the executor 230. These components fall into one of several categories.

[0048] The information producer components can generate information that identifies or characterizes when files are accessed, processes that use system APIs, information about the reputation of binaries or modules within a process (i.e., the code being analyzed), system-wide changes, and patch-level changes. This information can be created based on events occurring on the system to enable the executor 230 to make informed decisions. Examples of information producer components can include the engine 240, the performance monitoring component 250, and the resiliency component 280.

[0049] Engine 240 may perform various activities, including hashing data (e.g., executable files and other code, etc.) and running various models (e.g., machine learning models, statistical models, etc.) that may characterize various software reputations, behaviors, and / or data flows related to maliciousness, including the likelihood that such software is ransomware. These characterizations may then be used to determine whether any corrective action (e.g., anti-ransomware, isolating the software, restricting access to the software, preventing the software from running, etc.) needs to be taken to prevent the ransomware from launching and / or continuing to run. Machine learning models may take various forms (e.g., neural networks, regression models, support vector machines, random forests, etc.) and in some cases may be trained using historical data with known classifications or labels. In some cases, weak supervision may be utilized while the system is initially deployed to generate enough data to further train the model. Models may also be trained using unsupervised, semi-supervised, or reinforcement learning techniques.

[0050] The performance monitoring component 250 can monitor characteristics such as compatibility, endpoint role, and overall performance. For example, if new protection measures (such as ransomware protection) fundamentally change the way the system operates, this component can measure whether those changes to the operating system are relevant to adjacent programs of the system (such as allowing the protection measures to be deployed or activated so as not to impact system performance beyond a predefined threshold / metric). The role of an endpoint can be the category that a system or computing device represents, such as a web server, a database server, an accountant workstation, or a developer workstation. The role of an endpoint can then be used to customize the protection applied to optimize the parameters of that endpoint's protection based on its role (i.e., a role-based approach can be applied to each computing device that is being protected using the present subject matter). Finally, overall performance can be monitored to identify the impact of the endpoint on the system and the cause of the adverse performance, providing a closed loop for optimizing the system against the endpoint.

[0051] The resiliency component 280 can provide various operations that help maintain access to an organization's data even if ransomware detonates. For example, the resiliency component 280 can leverage shadow copies of files (e.g., snapshots generated by the Volume Snapshot Service (VSS)). The resiliency component 280 can provide mechanisms for key recovery. The resiliency component 280 can further be configured to delay the deletion of files on various endpoints 112 and servers 114. Such delays can be implemented, for example, by hooking file system regions or kernel calls such that files are temporarily moved whenever a deletion attempt occurs.

[0052] A simulacrum component is a software executable or process that can simulate characteristics on a system for the purpose of amplifying behaviors or triggering self-destruction in malware. The term simulacrum, as used herein, refers to a computer-implemented / software technique that simulates changes in characteristics of a monitored system without actually changing such characteristics. For example, a simulacrum can be deployed or executed to trigger an action by a potential ransomware to counter the potential ransomware or to confirm that an executable / DLL is indeed ransomware. In some examples, a simulacrum can make a particular system component appear to be present when it is not, obscure a particular system component, and / or change the identification type of a system component. This appearance consists of having a sign of a state without having the actual state. The simulacrum components can include an anti-detonation component 260 and an entrapment component 270.

[0053] The anti-detonation component 260 can perform various ransomware countermeasures to prevent ransomware from detonating (i.e., activating). These operations can include analysis tools deployed to identify or otherwise characterize a particular type of ransomware. The anti-detonation component 260 can also initiate a sandbox environment for the software in question. For example, the sandbox environment can cause one or more processors associated with the executable or DLL in question to be executed and monitored by a virtual machine (so as not to affect the operation of the receiving computing device, etc.). Additionally, in some cases, the anti-detonation component 260 can spoof or otherwise change the locale information of the endpoint. In this regard, as an example, some hostile software may have code that disables itself if the system appears to be in a country that is part of the Commonwealth of Independent States. Additionally, some hostile software may have code that detects whether it is being analyzed and attempts to hide the software's intent by disabling ransomware properties. The anti-detonation component 260 can utilize these operations as well as other operations that similarly disable hostile software.

[0054] The entrapment component 270 can be used to trigger or otherwise prompt an action from the executable / DLL, if present, that indicates that the executable / DLL contains ransomware. The entrapment component 270 can generate and deploy decoy files (i.e., files that appear to contain sensitive information but are otherwise of no use to the enterprise, such as fake human resources data). Additionally, the entrapment component 270 can generate fake servers and / or fake Extensible Provisioning Protocol (EPP) status codes, etc., to further interact with the ransomware, confirm its malicious intent, and / or disable such ransomware. Information about the entrapment component 270 can be used to neutralize the ransomware before and / or after it has been activated.

[0055] The mechanism modification components 280 and 290 can modify how organizational computing resources 110 operate and mitigate the impact of malware operations on those resources. These mechanism modification components 280, 290 can be selectively applied to suspicious processes / DLLs to avoid adverse system impacts (which would occur if the components were applied equally to all processes on the system). This arrangement allows these mechanism modification components 280, 290 to reduce the adverse impact of hostile code / processes while preserving desirable system parameters such as performance (i.e., can impact system performance up to a certain threshold). Examples of mechanism modification components can include a quarantine component 290 and a resiliency component 280.

[0056] The quarantine component 280 can take various measures to prevent access by software suspected of containing ransomware, including to local file systems on the endpoints 112 or servers 114. The quarantine component 290 can also prevent processes being executed by the endpoints 112 or servers from accessing or using other resources. Additionally, the quarantine component 290 can be used to prevent certain endpoints 112 or servers 114 from accessing the intranet and / or the Internet.

[0057] The action component can perform an action on the endpoint 112, such as installing a patch or stopping the execution of malware. The quarantine component 290 can be a type of action component.

[0058] When an action is performed by a user or program within the organizational computing resources 110 on which a malware sample may be executed, the executor 230 may include a mechanism by which a notification that such an event is about to occur may be generated before such an event occurs. At this point, the pre-execution engine may analyze the events surrounding the execution of the process or DLL, including aspects related to one or more of the trustworthiness of the execution chain, the origin of the corresponding executable, the category of the executable, suspiciousness indicators, etc. The pre-execution engine may extract or otherwise generate features of any of these categories and later feed such features (e.g., in the form of vectors, etc.) into one or more machine learning models.

[0059] The execution chain trust allows us to analyze the trust of the execution chain following all parent execution events. For example, when a user double-clicks an executable file using a MICROSOFT WINDOWS system, explorer.exe is responsible for making the execution request. However, if an attacker exploits the GOOGLE CHROME browser to launch malware, GOOGLE CHROME is responsible for making the request. These two different execution lineages result in different trust values ​​for the execution. This can be achieved by the executor 230 observing the creation of processes and the processes responsible for their creation. When an attacker hits GOOGLE CHROME to launch a process, the executor 230 can see the request originating from GOOGLE CHROME. Similarly, the executor 230 can see requests made with explorer.exe as the request origin and mark the newly requested process as having explorer.exe as the parent. These parent processes may have different levels of trust / suspiciousness due to their manufacturer, binary properties, and associated attack history, and the resulting child processes may inherit these trust / suspiciousness levels and / or have a suspiciousness score based on the parent's suspiciousness score.

[0060] The origin of an executable file can be determined or characterized by analyzing various characteristics of the executable file, including one or more of the correctness of the code signature, the providing company, the source of the executable file (e.g., USB or other solid state drive, downloaded over the internet, etc.), the compiler used to generate the binary, the date and time the binary was generated, the amount of machine time spent safely executing the program locally and across organizational computing resources 110, etc.

[0061] The category of the executable may be determined by analyzing various attributes including the presence of an executable obfuscator, the manufacturer, model, and configuration of the executable obfuscator, the language and compiler used to generate the executable, the imports and exports of the executable, strings present in the executable, the resources of the executable, the size of the executable, etc. Examples of software categories include platform and management, education and reference, home and entertainment, productivity suites, multimedia players, file viewers, web browsers, collaboration tools, enterprise resource management, customer relationship management, supply chain and manufacturing tasks, application development, information management and access, product manufacturing and delivery, etc. These software categories are important to allow the model to associate the characteristics of the executable as being related to a particular product category with a particular set of manufacturers. For example, ransomware may have properties related to the management category or productivity suite. These characteristics may be observed by engine 240, for example, by using the information integration of executor 230. As these two categories are distinct but are observed to overlap, they may be used to make a negative determination by executor 230.

[0062] It can be analyzed for suspicious indicators (i.e., attributes or characteristics indicative of ransomware / malware, etc.). Example indicators may include modified rich headers, section entropy, presence of URLs, section names, presence of appended data, checksum mismatches. As with all information collected, features can be extracted or otherwise generated for use in downstream applications or processes (e.g., one or more machine learning models, etc.).

[0063] These categories of events / attributes can be considered together (or utilized by a machine learning model) as a score or dimension of the executable. Some or all of these dimensions can be fed into each other to determine if there is a match. As an example, it is unlikely that a supposedly managed tool would use an executable obfuscator, have many suspicious elements, or be signed by the company that created the program. If these measured elements do not match with a high enough degree of certainty, the monitoring system 130 can block the executable from running (either directly or via one of the deployed agents). If the measured elements do not provide enough certainty, the monitoring system 130 can allow the executable to run. The monitoring system 130 can log the values ​​of these different dimensions so that they can be viewed as suspicious values ​​that track throughout the execution of the program. These suspicious values ​​are generated using an algorithm that takes the output of the engine 240, the anti-detonation component 260, and the entrapment component 270 and optimally combines them. In some variations, the scores can be weighted and added together. In other variations, these scores and other extracted features can be input into a machine learning model such as a convolutional neural network whose weights are trained to produce optimal output values.

[0064] If the monitoring system 130 determines that the program should be allowed to run, it then determines whether the program is a good candidate for adding an artificial simulacrum. For programs that are not suspicious (which is the vast majority of programs), no artificial simulacrum is added. This determination allows the monitoring system 130 to improve compatibility and performance, since all software that an organization would want to run without interference falls into the "not suspicious" category.

[0065] For programs that have become suspicious enough that simulacra are needed, monitoring system 130 can inject various simulacrums into the program's view of the environment. Such injections can be accomplished through a variety of means, including kernel hooks, file system filters, and network drivers, all under the control of executor 230.

[0066] There are two main purposes behind simulacra. The first is to trigger anti-detonation protection mechanisms built into the malware. The operating environment on the endpoint 112 and / or server 114 can be modified to determine that the executable (i.e., the suspected malware) is operating within a restricted geographical area. For example, Russian malware producers may prevent their software from performing malicious actions on Russian computer systems, and may utilize such features to effectively disable the malware. Simulacra can also be used to generate properties that lead to the conclusion that the executable has been analyzed. Such an arrangement can identify indicators that indicate the presence of analysis tools on the corresponding endpoint 112 or server 114 (which causes the executable to run some anti-detonation processes to prevent it from being disabled) and / or that the software is being debugged.

[0067] Simulacra can also be used to simulate properties that would lead an executable to conclude that a corresponding endpoint 112 or server 114 (or collection of computing devices within organizational computing resources 110) is worthless. For example, the simulacra can indicate that the system is a virtual machine and / or can obscure or otherwise hide the user's personal files (i.e., their absence indicates that the system is not useful for ransomware purposes).

[0068] Simulacra can be used to simulate properties of an executable that make it appear as if it has already been run. For example, some malware creates mutexes, flags files, or checks for custom file extensions to prevent double encryption of the machine; such artifacts can be simulated by a simulacra.

[0069] A second purpose of injecting simulacra into the malware's system view (i.e., operating environment) is to increase the amount of malicious behavior that the executable will result in. The performance monitoring component 250 can measure behavior of the executable that increases the amount of signals that the monitoring system 130 can judge the executable from (i.e., more data becomes available that the model can consume in characterizing the executable, etc.). Additionally, any behavior-oriented endpoint protection running simultaneously on the endpoint 112 can also observe the bad behavior and make a more appropriate judgment against the executable. Examples of this type of simulacra include the following, which simulates the presence of multiple endpoint protection products (on each endpoint 112 or server 114): The performance monitoring component 250 can monitor the executable's attempts to disable such endpoint protection products. Some types of ransomware can simulate the presence of database software, as they attempt to take down or otherwise interface with database servers so that the malware can encrypt the database. The simulacra can simulate the presence of artificial user files that some types of ransomware attempt to access (where the executable has no rational reason to access such artificial user files). Simulacra can simulate the presence of backup software that attempts to stop and move previous backups so that some types of ransomware make the backups unavailable to users.

[0070] For executables for which the anti-detonation feature has been triggered, execution is stopped. Additionally, the performance monitoring component 250 can measure that the anti-detonation feature has been triggered and update other resources forming part of the organizational computing resources 110 so that executables can be more expediently stopped on other endpoints 112 and / or servers 114. For executables for which the anti-detonation feature has not been triggered, execution can continue in this expanded view of the system (so that the performance monitoring component 250 can obtain additional information about the executable).

[0071] FIG. 3 is a process flow diagram 300 in which data including or characterizing executable files and dynamic link libraries (DLLs) are received at 310. Features are then extracted from the executable files and DLLs at 320. The extracted features are input to at least one machine learning model at 330 to generate a suspiciousness score. The machine learning model can be trained to determine whether the executable files contain ransomware. A confidence score for the execution chain of the executable files and DLLs can then be determined at 340 based on the extracted features and the suspiciousness score. The confidence score for the execution chain of the executable files and DLLs characterizes one or more associated parent processes. The suspiciousness score and the confidence score for the execution chain can be used to determine whether to initiate one or more ransomware countermeasures at 350.

[0072] 4 is a process flow diagram 400 in which an executable file is initiated to execute in an operating environment at 410. Thereafter, characteristics associated with the execution of the executable file are frequently monitored at 420. Thereafter, it is determined that the executable file has one or more characteristics associated with ransomware at 430. In response to such determination, at 440, at least one simulacrum is injected into the operating environment to attempt to trigger anti-detonation protection features by the executable file. Thereafter, at 450, one or more ransomware countermeasures can be initiated based on the behavior of the executable file after injection of the at least one simulacrum.

[0073] FIG. 5 is a diagram 500 illustrating an example of a computing device architecture for implementing various aspects described herein. A bus 504 can function as an information highway interconnecting the other illustrated components of hardware. A processing system 508 (e.g., one or more computer processors / data processors in a given computer or computers), labeled as a central processing unit (CPU), can perform the calculations and logical operations necessary to execute a program. Additionally, a processing system 510 (e.g., one or more computer processors / data processors in a given computer or computers), labeled as a graphics processing unit (GPU), can perform the calculations and logical operations necessary to execute a program. A non-transitory processor-readable storage medium, such as a read-only memory (ROM) 512 and a random access memory (RAM) 516, can be in communication with the processing system 508 and can include one or more programming instructions for operations specified herein. Optionally, the program instructions can be stored on a non-transitory computer-readable storage medium, such as a magnetic disk, an optical disk, a recordable memory device, a flash memory, or other physical storage medium.

[0074] In one example, the disk controller 548 can interface one or more optional disk drives to the system bus 504. These disk drives can be external or internal floppy disk drives such as 560, external or internal drives including solid state drives such as 552, or external or internal hard drives 556. As previously indicated, these various disk drives 552, 556, 560 and disk controllers are optional devices. The system bus 504 can also include at least one communication port 520 to enable communication with external devices either physically connected to the computing system or externally available through a wired or wireless network. In some cases, the at least one communication port 520 includes or is otherwise configured with a network interface.

[0075] To provide for interaction with a user, the subject matter described herein can be implemented on a computing device having a display device 540 (e.g., a monitor such as an LED, LCD, etc.) for displaying information obtained from the bus 504 via the display interface 514 to the user, and an input device 532, such as a keyboard and / or a pointing device (e.g., a mouse or trackball) and / or a touch screen, by which the user can provide input to the computer. Other types of input devices 532 can be used to provide interaction with the user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback via a microphone 536, or haptic feedback, etc.); and input from the user can be received in any form, including acoustic input, voice input, or haptic input. The input device 532 and microphone 536 can be connected to the bus 504 via an input device interface 528 and communicate information over the bus 504. In other computing devices, such as dedicated servers, one or more of the display 540 and display interface 514, the input device 532, the microphone 536, and the input device interface 528 may be omitted.

[0076] One or more aspects or features of the subject matter described herein may be implemented in digital electronic circuitry, integrated circuits, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) computer hardware, firmware, software, and / or combinations thereof. These various aspects or features may include implementation in one or more computer programs executable and / or interpretable on a programmable system including at least one programmable processor, which may be special purpose or general purpose, coupled to receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. Clients and servers are typically remote from each other and typically interact through a communications network. The relationship of client and server arises by virtue of computer programs running on the respective computers having a client-server relationship to each other.

[0077] These computer programs, which may also be referred to as programs, software, software applications, applications, components, or codes, include machine instructions for a programmable processor and may be implemented in high-level procedural languages, object-oriented programming languages, functional programming languages, logic programming languages, and / or assembly / machine languages. As used herein, the term "machine-readable medium" refers to any computer program product, apparatus, and / or device used to provide machine instructions and / or data to a programmable processor, such as, for example, magnetic disks, optical disks, memories, and programmable logic devices (PLDs), including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor. The machine-readable medium may be, for example, a non-transitory solid-state memory, or a magnetic hard drive, or any equivalent storage medium, capable of non-transitory storage of such machine instructions. The machine-readable medium may alternatively or additionally store such machine instructions in a transitory manner, such as, for example, a processor cache or other random access memory associated with one or more physical processor cores.

[0078] In the above description and in the claims, phrases such as "at least one" or "one or more" may be followed by a connectable list of elements or features. The term "and / or" may also be used in a list of two or more elements or features. Such phrases are intended to mean any of the listed elements or features individually, or any of the listed elements or features in combination with any of the other listed elements or features, unless otherwise implicitly or explicitly contradicted by the context in which it is used. For example, the phrases "at least one of A and B," "one or more of A and B," and "A and / or B" are intended to mean "A alone, B alone, or both A and B," respectively. A similar interpretation is intended for lists containing more than two items. For example, the phrases "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, and / or C" are intended to mean "A alone, B alone, C alone, both A and B, both A and C, both B and C, or all of A, B, and C," respectively. Additionally, use of the term "based on" above and in the claims means "based at least in part on" and is intended to allow for unrecited features or elements.

[0079] The subject matter described herein may be embodied in systems, devices, methods, and / or articles, depending on the desired configuration. The implementations described in the foregoing description do not represent all implementations consistent with the subject matter described herein. Rather, they are merely some examples consistent with aspects related to the subject matter described. Although some variations have been described in detail above, other modifications or additions are possible. In particular, further features and / or variations may be provided in addition to those set forth herein. For example, the implementations described above may be directed to various combinations and subcombinations of the disclosed features, and / or combinations and subcombinations of some further features disclosed above. Furthermore, the logic flow depicted in the accompanying figures and / or described herein need not necessarily be in the particular order depicted, or in the exact order, but rather in any order necessary to achieve the desired results. Other implementations may be within the scope of the following claims.

Claims

1. receiving data including or characterizing executable files and / or dynamic link libraries (DLLs); extracting one or more features from the executable file and / or DLL; inputting the extracted features into at least one machine learning model to generate a suspiciousness score, the at least one machine learning model being trained to determine whether the executable file contains ransomware; determining an execution chain score of trustworthiness for the executable file and / or DLL using the extracted features and the suspiciousness score, characterizing one or more associated parent processes; and activating one or more ransomware countermeasures based on the suspiciousness score and the trust execution chain score.

2. 2. The method of claim 1, wherein activating one or more anti-ransomware measures comprises restricting functionality of resources required by processes associated with the executable file and / or DLL if the suspiciousness score is within a first range.

3. 3. The method of claim 2, further comprising: blocking execution of the process associated with the executable file and / or DLL if the suspiciousness score is within a second range that is different from the first range and indicates a higher level of suspiciousness than the first range.

4. activating the one or more ransomware countermeasures, restricting functionality of a process associated with the executable file and / or DLL if the execution chain score of trustworthiness is within a first range; and 2. The method of claim 1, further comprising: blocking a process associated with the executable file and / or DLL if the suspiciousness score is within a second range that is different from the first range and indicates a higher level of suspiciousness than the first range.

5. 10. The method of claim 1, wherein the step of initiating one or more ransomware countermeasures includes initiating a tripwire process in which processes associated with the executable files and / or DLLs are subject to a higher level of monitoring.

6. 2. The method of claim 1, wherein invoking one or more anti-ransomware measures comprises initiating one or more processes to induce behavior by the executable file and / or DLL indicative of ransomware.

7. The method of claim 1 , wherein the suspiciousness score is 0 if there is no parent process associated with the executable file and / or DLL.

8. 10. The method of claim 1, wherein the executable and / or DLL is accessed or executed by an endpoint having an agent thereon, the agent extracting the one or more features from the executable and / or DLL and transmitting the extracted one or more features to a remote server that executes the at least one machine learning model.

9. The method of claim 8 , wherein the remote server is a bastion host.

10. 9. The method of claim 8, wherein the remote server is configured to host a single application or process to minimize vulnerability to ransomware attacks.

11. 10. The method of claim 1, further comprising generating features based on one or more of an active process using an application programming interface (API) when the executable and / or DLL is accessed, reputation information about the executable and / or DLL or module utilized by the active process, system-wide changes, or patch-level changes, and the generated features are further input into the at least one machine learning model to generate the suspicious score.

12. The method of claim 1 , wherein the one or more ransomware countermeasures include generating a shadow copy of a file of interest.

13. 13. The method of claim 12, wherein the shadow copy comprises a Volume Snapshot Service (VSS) that creates a snapshot accessible through a key recovery mechanism.

14. The method of claim 1 , wherein the one or more ransomware countermeasures include delaying deletion of files of interest.

15. 15. The method of claim 14, wherein delaying the deletion of the file of interest is performed by hooking a file system region or kernel call such that the file of interest is temporarily moved whenever a deletion attempt occurs.

16. monitoring access to executable files and / or dynamic link libraries (DLLs) across various nodes of the distributed computing environment; extracting one or more features from each executable file and / or DLL accessed; inputting the extracted features into at least one machine learning model to generate a suspiciousness score for each accessed executable file and / or DLL, the at least one machine learning model being trained to determine whether the executable file contains ransomware; Using the extracted features and the suspiciousness score to determine an execution chain score of trustworthiness for each executable file and / or DLL, characterizing one or more associated parent processes; and activating one or more ransomware countermeasures if one or both of the suspiciousness score and the trust execution chain score exceed a predetermined threshold.

17. 17. The method of claim 16, wherein the one or more anti-ransomware measures are activated only on nodes that access the corresponding executable files and / or DLLs.

18. 17. The method of claim 16, wherein the one or more ransomware countermeasures are launched on multiple nodes, including a node that accesses the corresponding executable file and / or DLL.

19. receiving data containing or characterizing an executable file; extracting from the received data one or more features indicative of each of an execution chain of trustworthiness characterizing one or more events preceding the requested execution event and the presence of a suspiciousness indicator; inputting the extracted features into at least one machine learning model trained to determine whether the executable file contains ransomware; Preventing the executable file from executing or continuing to execute based on a determination that the executable file contains ransomware; and allowing the executable file to execute or continue to execute based on a determination that the executable file does not contain ransomware.

20. monitoring access to the executable file for each of a plurality of nodes that form part of the computing environment; extracting, for each executable file, one or more features indicative of each of an execution chain of trust characterizing one or more events preceding a requested execution event, the presence of suspiciousness indicators, and events associated with said access of said executable file; For each executable file, inputting the extracted features into at least one machine learning model trained to determine whether the executable file contains ransomware; For each executable file, preventing the executable file from executing or continuing to execute based on a determination that the executable file contains ransomware; and 1. A method comprising: for each executable file, allowing the executable file to execute or continue to execute based on a determination that the executable file does not contain ransomware.

21. commencing execution of the executable file in the operating environment; continuously monitoring characteristics associated with said execution of said executable file; determining that the executable file has one or more characteristics associated with ransomware; based on the determining step, to attempt to entrap the ransomware and / or trigger anti-detonation protection by the ransomware; injecting at least one simulacra into the operating environment; and and activating one or more ransomware countermeasures based on the ongoing monitoring after injection of the at least one simulacra.

22. 22. The method of claim 21, wherein the at least one simulacra comprises a software executable or process that simulates characteristics of an operating environment to amplify ransomware behavior and / or trigger ransomware self-destruction.

23. The method of claim 21 , wherein the at least one simulacra obscures at least one system component of the operating environment.

24. The method of claim 21 , wherein the at least one simulacra changes an identification type of at least one system component of the operating environment.

25. 22. The method of claim 21, wherein the at least one simulacra launches a sandbox environment in which the executable runs and is monitored by a virtual machine.

26. The method of claim 21 , wherein the at least one simulacra disguises or changes the location of an endpoint that forms part of the operating environment.

27. 22. The method of claim 21, wherein the at least one simulacrum deploys a decoy file that appears to contain sensitive information for access by the ransomware.

28. 22. The method of claim 21, wherein the at least one simulacra generates a fake server that interacts with the ransomware to confirm malicious intent and / or to neutralize the ransomware.

29. 22. The method of claim 21, further comprising collecting information about the ransomware by an entrapment component.

30. 22. The method of claim 21, wherein the at least one simulacra causes the ransomware to conclude that a corresponding endpoint or server accessing the executable file is worthless.

31. 31. The method of claim 30, wherein the at least one simulacra indicates that the corresponding endpoint or server is a virtual machine.

32. 31. The method of claim 30, wherein the at least one simulacra hides a file of interest from the ransomware.

33. 22. The method of claim 21, wherein the at least one simulacra generates artifacts that ransomware would generate to prevent the ransomware from performing a particular action.

34. 34. The method of claim 33, wherein the generated artifacts include a mutex, a flag file, or a custom file extension to prevent the ransomware from double-encrypting data in the operating environment.

35. 22. The method of claim 21, wherein the at least one simulacra simulates the presence of multiple endpoint protection products on each endpoint and / or server forming part of the operating environment, and attempts to disable such multiple endpoint protection products are monitored.

36. 22. The method of claim 21, wherein the at least one simulacra simulates the presence of backup software that the ransomware attempts to stop and delete previous backups.

37. at least one data processor; and 37. A system comprising: a memory storing instructions which, when executed by said at least one data processor, perform the method of any one of claims 1 to 36.

38. A non-transitory computer program product storing instructions that, when executed by at least one computing device, result in the method of any one of claims 1 to 36.

Images