Distributed ransomware protection

Abstract

Distributed ransomware techniques for protecting a distributed computer system are presented. The techniques include detection actions and diagnosis actions, performed by each node. The detection actions include: generating random files of a plurality of file types; storing the random files in randomized locations; computing baseline hash values for the random files; encrypting a configuration file containing the baseline hash values; storing the encrypted configuration file; computing updated hash values; comparing the baseline hash values with the baseline hash values; and storing a fault condition indication based on at least a result of the comparing. The diagnosis actions include: maintaining a diagnostic record indicative of fault conditions of at least some of the of nodes; sending a request for a neighboring node diagnostic record to a neighboring node; receiving the neighboring node diagnostic record from the neighboring node; and updating the diagnostic record based on the neighboring node diagnostic record.

Description

Attorney Docket No. P18368-02 / 0184.0327-PCTDISTRIBUTED RANSOMWARE PROTECTIONRelated Application

[0001] This application claims the benefit of U. S. Provisional Patent Application No. 63 / 711,815 entitled “DISTRIBUTED RANSOMWARE PROTECTION,” filed October 25, 2024.Field

[0002] This disclosure relates generally to cyberattacks, such as ransomware.Background

[0003] In the early days of ransomware in the 1990’s, crackers, or what the media used to call hackers, developed ransomware for fun and mischief. However, the landscape has changed dramatically, with a surge in nation-backed ransomware groups and groups driven by financial motives. Moreover, the development and distribution of ransomware have become a lucrative industry in the underground world. Nowadays, even non-technical individuals can obtain ransomware toolkits from the dark web and execute attacks. There has been a rise in attacks where certain groups develop ransomware toolkits and sell them to buyers who carry out the attacks. This partnership allows ransomware developers to create a network of enablers for their services. By focusing solely on the development aspect, they can reap the rewards of their work while their partners handle the execution.

[0004] Ransomware attackers may use various techniques to develop, propagate, and exploit victims. For example, a ransomware attack can begin as a phishing campaign. If the victim succumbs, they can be tricked into downloading theransomware binary. Depending on how the ransomware has been developed, it might utilize a zero-day exploit in the operating system, allowing it to escalate privileges and disable antivirus software. If it cannot escalate privileges, it may still run as a normal user. The actions it performs on the system may depend on the type of ransomware it is, e.g., locker ransomware or crypto ransomware.

[0005] Locker ransomware may completely lock the victim’s system resources, rendering the victim unable to use their device until they pay a ransom. The victim may receive a ransom note detailing how to pay. At that point, the victim might attempt to bypass the ransomware by forcefully powering off their device or opening the task manager to kill the ransomware process. However, if the locker ransomware has been developed by a skilled attacker, these attempts may be futile. Even powering off the device may not help, as the ransomware program may start running again once the device boots up again. Additionally, because locker ransomware may utilize OS API calls to control system resources, attempting to kill the program by opening anything on the device may be ineffective. Nonetheless, because locker ransomware may not encrypt the underlying files, one can power off the machine, copy the data to another device, and format the device in question. However, the data transfer might also infect the new device with the same locker ransomware.

[0006] Crypto ransomware may operate differently. Instead of rendering the underlying device unusable, it may encrypt the device’s data and demand a ransom for data retrieval. Before encrypting the data, the ransomware typically establishes a connection with its Command and Control Center (“C& C”), responsible for providing the encryption keys. There are three main ways encryption can be done: symmetric, asymmetric, and hybrid.

[0007] For symmetric encryption, the keys may be stored on the victim’s device and can therefore sometimes be easily retrieved. It is also possible for the keys to be stored in the ransomware binary, which can again be reverse-engineered, allowing the keys to be retrieved without having to pay the ransom.

[0008] For asymmetric encryption, the attacker may generate a public / private key pair. After the ransomware in the wild establishes a connection with the C& C, the attacker may encrypt the victim’s files with the public key. Once the victim pays the ransom, the attacker may share the private key with the victim, assuming that the attacker will keep their word. A drawback (for the attacker) of asymmetric encryption is that the encryption of large files is slow and can take up more space on the victim’s machine; thus, it may not be an efficient way of encrypting the data. Moreover, if the device in question is unable to establish a connection with the C& C, then the encryption process may not be able to start. In another scenario, asymmetric encryption can be done on the client side, i.e., on the victim’s machine; however, an issue with this approach is that if the victim powers off the device or removes it from the network, the private key will not be sent to the attacker. In either case, asymmetric encryption is generally not a viable approach to ransomware (from the attacker’s perspective).

[0009] In hybrid encryption, symmetric and asymmetric encryption methods may be combined. Symmetric encryption may be used to encrypt the victim’s device. After the device establishes a connection with the C& C, it may provide the attacker with the symmetric key and then delete the symmetric key from the victim’s device. The benefit (for the attacker) of the hybrid encryption approach is twofold. First, encryption may be faster, and the symmetric keys may not be stored on the victim’s device. Second, with the use of public key encryption, the private key can be sent tothe attacker even in the presence of an eavesdropper, allowing this hybrid approach to be an optimal technique.

[0010] With hybrid encryption, crypto ransomware has been seeing a surge in recently, being responsible for approximately 60% of total ransomware attacks in 2015. Further, recent ransomware has started to combine techniques from both locker and crypto ransomware. Thus, it may completely render the underlying system unusable with all data encrypted, forcing the victim to heed the ransomware demand.

[0011] Regarding defenses against ransomware, early detection techniques were largely signature-based. Signature based methods compare the byte code of unknown files against a set of known malicious executables to detect malware. Signature-based methods, although accurate against known executables, have been shown to generalize poorly and are inadequate against modern ransomware. Ransomware detection is now mostly behavior-based, a paradigm which analyzes processes, API calls, or disk usage as indicators of malicious activity. The application of machine learning makes behavioral analysis a generalizable technique, capable of high detection accuracy on previously unseen samples.Summary

[0012] According to various embodiments, a distributed ransomware protection system for a distributed computer system including a plurality of nodes is presented. A respective node of the plurality of nodes may include a respective subdomain non-transitory computer readable medium including a respective subdomain that is subject to a ransomware attack. The ransomware detection system may include, on the respective node of the plurality of nodes, a respective protection non-transitory computer readable medium including detection instructions and diagnosis instructions.The detection instructions, when executed by a respective electronic processer of the respective node of the plurality of nodes, configure the respective electronic processor to perform detection actions including: generating a plurality of respective random files of a plurality of file types; storing the plurality of respective random files in randomized locations within the respective subdomain; computing respective hash values for the plurality of respective random files, from which a plurality of respective baseline hash values are obtained; encrypting a respective configuration file including the plurality of respective baseline hash values, from which a respective encrypted configuration file is obtained; storing the respective encrypted configuration file in the respective subdomain; computing respective hash values for the plurality of respective random files, from which a plurality of respective updated hash values are obtained; comparing the plurality of respective baseline hash values with the plurality of respective baseline hash values; and storing, at the respective node, a respective fault condition indication, where the respective fault condition indication is based on at least a result of the comparing, where the respective fault condition indication is representative of a fault condition of the respective node. The diagnosis instructions, when executed by the respective electronic processer of the respective node of the plurality of nodes, configure the respective electronic processor to perform diagnosis actions including: maintaining a respective diagnostic record indicative of fault conditions of at least some of the plurality of nodes; sending a request for a neighboring node diagnostic record to a fault free neighboring node; receiving the neighboring node diagnostic record from the fault free neighboring node; and updating the respective diagnostic record based on the neighboring node diagnostic record.

[0013] According to various embodiments, a method for distributed ransomware protection of a distributed computer system is presented. The distributedcomputer system may include a plurality of nodes. A respective node of the plurality of nodes may include a respective subdomain non-transitory computer readable medium including a respective subdomain that is subject to a ransomware attack. The method includes: performing detection actions, by a respective electronic processer of a respective node of the plurality of nodes executing non-transitory detection instructions; and performing diagnosis actions, by the respective electronic processer of a respective node of the plurality of nodes executing non-transitory diagnosis instructions. The detection actions include: generating a plurality of respective random files of a plurality of file types; storing the plurality of respective random files in randomized locations within the respective subdomain; computing respective hash values for the plurality of respective random files, from which a plurality of respective baseline hash values are obtained; encrypting a respective configuration file including the plurality of respective baseline hash values, from which a respective encrypted configuration file is obtained; storing the respective encrypted configuration file in the respective subdomain; computing respective hash values for the plurality of respective random files, from which a plurality of respective updated hash values are obtained; comparing the plurality of respective baseline hash values with the plurality of respective baseline hash values; and storing, at the respective node, a respective fault condition indication, where the respective fault condition indication is based on at least a result of the comparing, where the respective fault condition indication is representative of a fault condition of the respective node. The diagnosis actions include: maintaining a respective diagnostic record indicative of fault conditions of at least some of the plurality of nodes; sending a request for a neighboring node diagnostic record to a fault free neighboring node; receiving the neighboring nodediagnostic record from the fault free neighboring node; and updating the respective diagnostic record based on the neighboring node diagnostic record.

[0014] Various optional features of the above system and method embodiments include the following. The respective fault condition indication may be based on a result of the comparing indicating a number of mismatches between the plurality of respective baseline hash values and the plurality of respective baseline hash values, where the number is greater than one. The respective configuration file may further include file paths for the plurality of random files. The respective node may have an associated respective asymmetric key pair including a respective public key and a respective private key; the respective node may be associated with a respective certificate authority that stores a copy of the respective public key; the respective certificate authority may sign an initial certificate including the respective public key; and the detection actions may further include sending the respective fault condition indication to the respective certificate authority, whereby the respective certificate authority does not provide an updated certificate if the respective node is not fault free. The request for the neighboring node diagnostic record may be encrypted using the initial certificate. The detection actions may further include determining whether file types of files on the respective node have changed; and the respective fault condition indication may be further based on results of the determining. The detection actions may further include determining entropy values of a randomly-selected plurality of respective files in the respective subdomain; and the respective fault condition indication may be further based on a number of the randomly-selected plurality of respective files that have entropy values that exceed a threshold. The detection actions may further include determining whether hash values of files including the detection instructions and the diagnosis instructions have changed; and the respectivefault condition indication may be further based on results of the determining. The detection actions may further include determining whether fuzzy hash values of files on the respective node have changed; and the respective fault condition indication may be further based on results of the determining. The respective fault condition indication may be further based on: detected changes to file types of files on the respective node, detected changes to entropy values for files on the respective node, detected changes of hash values for files including the detection instructions and the diagnosis instructions, and detected changes of fuzzy hash values for files on the respective node.

[0015] Combinations, (including multiple dependent combinations) of the above-described elements and those within the specification have been contemplated by the inventors and may be made, except where otherwise indicated or where contradictory.Brief Description of the Drawings

[0016] Various features of the examples can be more fully appreciated, as the same become better understood with reference to the following detailed description of the examples when considered in connection with the accompanying figures, in which:

[0017] Fig. 1 is a schematic diagram of a distributed ransomware protection system deployed on a distributed computer system, according to various embodiments;

[0018] Fig. 2 is a schematic diagram of system architecture of a node in a distributed ransomware protection system, according to various embodiments;

[0019] Fig. 3 is a schematic diagram of a source code integrity check detection mechanism, according to various embodiments;

[0020] Fig. 4 is a flow diagram of an example certificate authority process, according to various embodiments;

[0021] Fig. 5 is a flow chart of example detection actions for a method of ransomware protection, according to various embodiments; and

[0022] Fig. 6 is a flow chart of example diagnostic actions for a method of ransomware protection, according to various embodiments.Description of the Examples

[0023] Reference will now be made in detail to example implementations. Although described in reference to a distributed ransomware detection, diagnosis, and reporting system for space systems, the scope of the invention is not so limited. The following description is, therefore, merely exemplary.

[0024] Some embodiments provide a distributed ransomware attack detection and diagnostic system for a distributed computer system. The ransomware protection system may mitigate the impact of a ransomware attack by detecting it early in its life cycle and stifling the spread of ransomware across the protected distributed computer network. Approaches for both detection and diagnostics are presented. The distributed deployment of both detection and diagnosis modules throughout a distributed computer system according to various embodiments solves the computer-network-centric problem of detecting and ameliorating ransomware in the early stages, before the ransomware takes over the distributed system. Further, through the use of random files of a variety of file types in random locations deployed on each node of a distributed computer system, some embodiments solve the problem of prior art systems that only utilize detection techniques for attacks on specific files in specific ways. Thus, to effectively protect assets from ransomware, some embodiments maybe able to detect instances of ransomware locally, diagnose the health of the broader network, and integrate across assets to ensure ease-of-use for an operator.

[0025] These and other features and advantages are shown and described herein in reference to the accompanying figures.

[0026] Fig. 1 is a schematic diagram of a distributed ransomware protection system deployed on a distributed computer system 100, according to various embodiments. As shown in Fig. 1, the distributed computer system 100 includes a plurality of nodes 110, 120, and 130; by way of non-limiting example, three nodes are illustrated in Fig. 1. Each node 110, 120, and 130 includes a computational point of interest with a potentially vulnerable sub-domain 112, 122, 132 within the distributed computer network 100, for example, a disk. Non-limiting examples of nodes 110, 120, 130 may include any, or a combination, of desktop computers, laptop computers, internet-of-things appliances, and generally any device that: (1) includes an electronic processor, (2) includes persistent memory that can hold non-transitory computer-readable instructions that configure the electronic processor to perform one or more of the processes disclosed herein, (3) is communicatively coupled to additional nodes, e.g., by a network 150 such as the internet to perform some or all of the messaging disclosed herein, and (4) includes one or more files (generally present in the subdomain 112, 122, 132) that may be subject to a ransomware attack.

[0027] According to various non-limiting embodiments, each ransomware protection system 114, 124, 134 may include at least two modules: a detection subsystem 116, 126, 136 and a diagnosis subsystem 118, 128, 138. The detection modules may be responsible for detecting ransomware attacks on each node’s subdomain. The diagnosis modules may be responsible for determining, and subsequently quarantining, any nodes which have been compromised.

[0028] Various embodiments thus include at least two layers of monitoring: nodes monitor their sub-domain through detection, and nodes monitor other nodes through diagnosis. This may allow for the monitoring at a systematic level and thus quick diagnosis and action in the event of a ransomware attack.

[0029] Fig. 2 is a schematic diagram of system architecture 200 of a node in a distributed ransomware protection system, according to various embodiments. In general, each node may include a detection module, operating in a detection plane, and a diagnosis module, operating in a diagnosis plane.

[0030] The detection module operates by employing various detection mechanisms on each node within the network. As shown in Fig. 2, the detection mechanisms may include one or more of: a file similarity detection mechanism 201, a file type change detection mechanism 202, a source code integrity check detection mechanism 203, a file entropy detection mechanism 204, and / or a random indicator file detection mechanism 205. These mechanisms collaborate, with each being assigned a specific weightage in a weighted classification 210 for fault detection. Thus, a final detection decision regarding whether a particular node is subject to a ransomware attack may be made through a voting system that involves all these mechanisms. This collaborative approach significantly reduces false negatives, ensuring accurate and reliable results.

[0031] The diagnosis module is responsible for validating the network’s integrity. If any node is compromised, immediate alerts are sent to the other nodes using an adaptive distributed system-level diagnosis algorithm (“Adaptive DSD algorithm”) 220. Additionally, the diagnosis module utilizes a certificate authority 230 (“CA”) for all nodes in the network, preventing nodes from being spoofed. Theimplementation of the CA enhances the robustness of some embodiments against various attacks.

[0032] According to some embodiments, the diagnosis module propagates and validates the results of the detection modules at discrete testing rounds. Such rounds may be performed periodically, e.g., every 10 seconds, every minute, every 10 minutes, etc. Thus, the diagnosis module and detection module operate together to provide an overall detection result 240 for the nodes. For example, according to some embodiments, the overall detection result 240 may be in the form of a “FAULTY” flag if a node is under attack, and a “FAULT-FREE” flag otherwise. Embodiments may include a node or other computing resource for consolidating the diagnosis outputs of the various nodes and providing a visual representation of the health of the system.

[0033] According to some embodiments, a user can customize runtime execution by selecting specific detection mechanisms tailored to their requirements, thereby streamlining their workflow and saving valuable time. This user-friendly approach empowers users with greater control and flexibility.

[0034] Furthermore, some embodiments include comprehensive logging throughout the codebase, facilitating seamless debugging processes. This logging functionality provides value in coding environments, offering detailed insights into program execution, error identification, and troubleshooting. It enhances the overall robustness of various embodiments and contributes to a more efficient and effective development and maintenance process.

[0035] In sum, the architecture 200 illustrated in Fig. 2 allows for the timely alerting of other nodes in the network about an ongoing ransomware attack. By preventing the ransomware from spreading throughout the network, it can minimize the overall fallout and damage.

[0036] In the following, non-limiting example details of the various detection mechanisms 201, 202, 203, 204, 205, the weighted classification 210, the CA 230, and the Adaptive DSD Algorithm 220 are presented in detail.

[0037] Detection

[0038] While each detection mechanism functions independently, their collective synergy is pivotal in fortifying the overall detection capabilities. The determination of the weighting assigned to each mechanism may be determined empirically for a given implementation or set in advance, according to various embodiments. Nevertheless, the amalgamation of these sub-modules provides a comprehensive methodology for identifying potential attacks on a node. Their functionalities span file analysis, file entropy assessment, and integration of buffer overflow protection concepts, including the deployment of random indicator files, among other sophisticated techniques.

[0039] Entropy Detection Mechanism 204

[0040] Entropy, in the context of information theory, refers to the level of unpredictability or randomness present in a dataset. It provides a measure of the amount of information that is missing from our knowledge about the complete microstate of the system. High entropy suggests more randomness or less predictability, while low entropy indicates more uniformity or greater predictability. Shannon entropy, named after Claude Shannon, quantifies the expected value of the information contained in a message, usually in bits. Shannon entropy can be used to detect ransomware. Because ransomware often encrypts user files, resulting in a high degree of randomness in file contents, the entropy of a file will increase post-encryption. By monitoring the entropy of files, sudden increases can signal potential ransomware activity, prompting defensive measures or alerts.

[0041] According to various embodiments, the entropy detection mechanism may select one or more random files from specific or random directories. Specific files and / or directories may be defined in a configuration file. Example directories include folders such as Documents, Downloads, and Desktop, which are frequent targets for ransomware encryption. The entropy detection mechanism may randomly select a subset of eligible files, based on size criteria, e.g., excluding files exceeding 102,400 KB (by way of non-limiting example). The entropy detection mechanism computes their entropy and checks if it falls within a specified range. If so, it assesses whether more than 20% (by way of non-limiting example) of the examined files exhibit similar behavior, returning 1; otherwise, 0. The entropy calculation may utilize the following formula, by way of non-limiting example.In the above equation, X denotes a file, H(X) represents the file’s entropy, n is the number of unique bytes in the file, and p(xj) denotes the probability of the occurrence of byte xiin the file.

[0042] The maximum entropy value is Iog2(n), typically achieving a value of 8 for a file with 256 possible bytes. A file nearing an entropy value of 8 may be classified as highly random or encrypted. The entropy detection mechanism may additionally employ a range check, scrutinizing whether the calculated entropy falls within a specified range, by way of non-limiting example, between 7.99900 and 8.00000.

[0043] By way of non-limiting example, the entropy detection mechanism may report its results by returning a result code: 1 if more than 20% of the selected fileshave entropy within the specified range, or 0 otherwise. The entropy detection mechanism may log pertinent information about the selected files, including their entropy values.

[0044] Overall, the entropy detection mechanism may provide a thorough assessment of the randomness of files in specified directories, offering insights into the level of entropy exhibited by the files.

[0045] Random Indicator Files Detection Mechanism 205

[0046] The random indicator files detection mechanism strategically deploys assorted random files of different file types, such as.pdf and.docx, across diverse locations within the system directories, selected at random. These files, being unrelated to the user’s work and unlikely to be intentionally deleted or modified, mitigate the risk of false positives. The system continuously monitors these files for any alterations, deletions, or encryption attempts. Upon detecting such activities, the detection module is promptly alerted, signaling a TRUE value and indicating the potential occurrence of a ransomware attack.

[0047] A non-limiting example implementation of the random indicator files detection mechanism follows. According to the example, the system generates a series of random PDF and DOCX files, computes their SHA256 hashes, records the file paths and hashes in a configuration file, encrypts the configuration file, and subsequently verifies for tampering by comparing the calculated hashes with the anticipated values. The encryption keys may be stored in the node in plaintext, of they may be securely stored in a vault or Key Management System (KMS) for enhanced security. The following actions may be included for implementing the example.

[0048] 1. File Generation

[0049] • Generate random PDF and DOCX files with random content.

[0050] • E.g., 4 PDF files and 6 DOCX files.

[0051] 2. Storage

[0052] • The generated files may be stored in random locations within predefined directories, where the definitions are stored in configuration file(s).

[0053] 3. Hash Calculation

[0054] Calculate the SHA256 hash for each generated file.

[0055] 4. Configuration File

[0056] Write the generated file paths and hashes into a configuration file.

[0057] 5. Encryption:

[0058] Encrypt the configuration file, e.g., using AES-256 encryption to secure the file.

[0059] 6. Decryption and Validation

[0060] If the configuration file exists and the keys are available, decrypt the configuration file and validate the files by comparing the stored hashes with the recalculated hashes.

[0061] • If more than two files have been modified or tampered with, log that tampering has occurred and returns a value of 1. Otherwise, log that no tampering has occurred and returns a value of 0.

[0062] • If the configuration file does not exist or the keys are unavailable, log that tampering has been detected, as both files are required, and return a value of 1.

[0063] • If neither the configuration file exists nor the keys are available, proceed with the random indicator file generation process.

[0064] 7. Main Execution

[0065] • The script is called by the main monitor loop, which calls the random indicator files function and stores the result in the variable result.

[0066] File Type Change Detection Mechanism 202

[0067] Each file possesses distinctive magic numbers or magic bytes, acting as unique file signatures that convey essential information. In instances of ransomware attacks, such as with WannaCry, these magic numbers are often modified as the ransomware encrypts the files and changes their extensions (e.g., appending. WCRY). Typically, standard file modifications do not affect these magic numbers, so any deviations in these numbers are generally indicative of suspicious activities. Some embodiments specifically detect scenarios where multiple files are either modified or created with identical magic numbers, pointing to a potential file type alteration. In such cases, the file type change detection mechanism is programmed to issue alerts. However, to avoid false negatives, alerts are configured to trigger only when more than some threshold number of files (e.g., 10) are altered or created within a specified temporal window (e.g., 60-seconds). This threshold is helpful to differentiate between typical encryption activities by legitimate applications, such as GnuPG appending a.gpg extension during encryption processes, and potential ransomware attacks.

[0068] Some embodiments may include a global mechanism that monitors these types of changes across the distributed network. The occurrence of such widespread alterations in magic numbers network-wide may prompt an immediate alert from the diagnostic module, enhancing the system’s ability to preemptively identify and respond to ransomware threats.

[0069] Another example file type change detection mechanism is described presently. Ransomware often works by encrypting files and changing their types, which can be a clear indicator of such malicious activity. By keeping a vigilant eye onfile type alterations within a system, it’s possible to identify and respond to ransomware encryption activities before they spread extensively. Example implementation steps for this method are as noted below:

[0070] • Implementation of file type change detection may include tracking files within the file system and monitoring them periodically for change in type.

[0071] • Monitored files may exclude user-generated files because such files are commonly deleted in daily use.

[0072] • The monitored files may include the random indicator files described herein in reference to the random indicator files detection mechanism. Such files are not supposed to be edited and are placed in random locations only known to the ransomware protection system, the locations of which being stored in an encrypted manner.

[0073] • To detect changes in the files, magic numbers, which are the first few bits of the file to uniquely identify the type of file, may be used.

[0074] • Hashes of the magic numbers, or the magic numbers themselves, are then comparted to what they are expected to be, and the results of the comparison are indicative of whether the file types have changed.

[0075] File Similarity Detection Mechanism 201

[0076] Fuzzy hashing may be used to determine how similar two files are. This differs from cryptographic hashing, which provides a completely different hash value even for small changes. Fuzzy hashing provides a hash output that is the same even for slightly different files. Further, the fuzzy hash value depends on how similar the two files are. There are multiple fuzzy hash techniques, including Sdhash. Sdhash has a high recall rate, along with higher scalability and accuracy concerning target sizes, although other fuzzy hash functions may be used in the alternative.

[0077] Sdhash uses bloom filters to provide a similarity digest, which is then compared, and a score from 0 to 100 is provided. If the score is 0, the files are considered very different. If the score is 100, the files are identical. Because, after encryption, the resultant file will not be similar to the original file, the expected score should be very close to 0. Consequently, the fuzzy hash detection mechanism will alert the detection module of this similarity.

[0078] A non-limiting example implementation of the fuzzy hashing detection mechanism is explicated below.

[0079] 1. Invocation in the overall detection loop: The process commences by performing fuzzy hashing on specific files.

[0080] 2. The Fuzzy Hashing Module: The fuzzy hashing module acts as a bridge between the overall detection loop and the specific fuzzy hashing function implementation.

[0081] Invoke the fuzzy hashing function.

[0082] Extract the numeric result from the output, e.g., using a regular expression.

[0083] Return the result along with any potential error message.

[0084] The specific hashing function implementation includes the following components:

[0085] Function(s) that calculate fuzzy hash similarity between two files.

[0086] Comparison that checks similarity among files within a directory based on fuzzy hashing.

[0087] Decryption process for a configuration file containing file paths and other information.

[0088] Source Code Integrity Check Detection Mechanism 203

[0089] Code integrity is an important aspect of software security, ensuring that the protection code remains unaltered and trustworthy from its original state to execution. A code integrity check involves mechanisms to detect and prevent unauthorized modifications, which could compromise the security and functionality of the software system. At its core, code integrity ensures that the code executed on a system is the exact code that was originally written and intended for use, without any unauthorized alterations. This is important in maintaining the trustworthiness and security of software systems, especially in environments where malicious actors might attempt to inject harmful code or modify existing code for nefarious purposes.

[0090] To preserve code integrity, several methods may be employed, according to various embodiments:

[0091] • Hashing: Calculating and verifying cryptographic hashes of the codebase ensures that any alteration in the code changes the hash value, thereby detecting modifications.

[0092] • Digital Signatures: Signing code with digital signatures provides a way to verify the authenticity and source of the code, ensuring it has not been tampered with since signing.

[0093] • Secure Execution Environments: Using secure and trusted execution environments can protect the code at runtime.

[0094] • Regular Audits and Updates: Regularly auditing and updating software can help in maintaining code integrity by fixing vulnerabilities and preventing exploitation.

[0095] In distributed peer-to-peer systems, the decentralized nature significantly heightens the importance of code integrity for enhanced security.Unauthorized code execution in any node can risk the entire network, making it important to ensure that all code is authentic and unaltered. This is particularly important in environments with limited direct oversight. Compliance with code integrity standards not only meets regulatory requirements, but also ensures uniform security and reliability across all nodes. Consistent and predictable software behavior across nodes helps maintain the network’s stability and efficiency. Therefore, maintaining code integrity may serve as a cornerstone for trust, compliance, and reliability in the smooth operation of peer-to-peer networks.

[0096] The implementation of the code integrity detection mechanism in a distributed peer-to-peer network is designed to significantly bolster security and reliability. A feature of its implementation may include the precomputation and secure storage of the verified, correct version of the SHA-256 hash on each node. This hash, known for its strong security and resistance to collision attacks, may be stored in a secure location akin to a vault, ensuring its protection from unauthorized access or alterations.

[0097] During the execution of the code, an embodiment may dynamically compute the hash of the source code. Concurrently, it may request the signature of the pre-stored, verified hash from another node in the network. This process is important because it allows for the comparison between the dynamically generated hash and the pre-verified hash’s signature. The integrity of the code may then be ascertained by verifying the match between these two hashes. This technique ensures that any discrepancies due to unauthorized modifications or tampering are promptly detected.

[0098] By employing this strategy, an embodiment may ensure that the integrity of the code is continuously monitored and verified against a known, trusted standard.This approach not only enhances the security of each individual node but also fortifies the overall reliability and trustworthiness of the entire peer-to-peer network.

[0099] Fig. 3 is a schematic diagram of a source code integrity check detection mechanism 300, according to various embodiments. The source code integrity check detection mechanism is illustrated in reference to a first node 310 and a second node 320.

[0100] The following outlines a non-limiting example high-level workflow of a code integrity check mechanism implementation in a distributed peer-to-peer network:

[0101] 1. Initial Hash Calculation and Storage:

[0102] • The process may begin with the calculation of the hash of the source code using the SHA-256 algorithm, by way of non-limiting example, which is known for its strong security and resistance to collision attacks. These verified original hashes 312, 322 are then stored on each node.

[0103] • Hashes may be stored in environment variables on the nodes, or may be stored in a secure, unmodifiable location like a hardware security module or an encrypted database

[0104] 2. Dynamic Hash Computation and Verification:

[0105] • Upon startup, the first node 310, for example, may dynamically compute the hash 314 of the protection source code within its directory, again using the SHA-256 mechanism by way of non-limiting example.

[0106] • The first node 310, for example, may then request the correct hash value from another node, e.g., the second node 320. The second node 320 retrieves the hash value from its secure location (environment variables in the prototype), signs it using an asymmetric cryptography (e.g., RSA) private key, and sends the signed original hash 324 to the first node 310. The use of asymmetric1cryptographic signing ensures that the signatures are unique, enhancing security against replay attacks or spoofing.

[0107] 3. Verification and Node Status:

[0108] • Upon receiving the signed original hash, the requesting first node 310 may verify the hash and signature 330, and may compare the verified hash to t=its computed dynamic hash 314 to confirm the code integrity of the first node 310.

[0109] • If the verification is successful, the code is deemed authentic, and the first node 310 may proceed with the execution of other detection mechanisms. If the verification fails, the first node 310 is marked as faulty. This status is then broadcast to all other nodes in the network, including the second node 320, alerting them of a potential security risk.

[0110] Returning to Fig. 2, the weighted classification 210 is described in detail presently.

[0111] Weighted Classification 210

[0112] The weighted classification operates on the principle that each detection mechanism may not consistently yield accurate results and might generate false positives. However, in the context of detecting ransomware in diverse environments, it is important to have a robust approach. Given the utilization of multiple detection mechanisms, the inventors conducted tests to evaluate the accuracy and false positive / negatives rates of each detection technique. Subsequently, greater weight was assigned to detection mechanisms that demonstrated higher accuracy and fewer false positives when determining whether a node is infected with ransomware. This strategic weighting reduces false positives and enhances the overall accuracy of the detection process. In the event of a node becoming infected, this approach helps toensure that at least one detection module will successfully identify the infection, triggering alerts to notify other nodes within the network.

[0113] The weighted classification utilizes the various detection mechanisms ability to detect ransomware by examining different behavioral aspects, aiming to identify an ongoing ransomware attack on a system. By way of non-limiting illustrative example, a counter (cnt) is a weighted sum that reflects the severity of issues detected during these checks. A high-level explanation of a non-limiting example implementation is provided below:

[0114] 1. Initialization: The script initializes a counter (cnt) to zero, which will be used to track the weighted issues detected during the checks.

[0115] 2. Entropy Detection Mechanism:

[0116] • If the entropy detection mechanism is configured, the script executes the entropy detection mechanism to check for entropy-related issues.

[0117] • If the entropy detection mechanism returns TRUE, ent is incremented by 2.

[0118] 3. Random Indicator File Detection Mechanism:

[0119] • If the random indicator file detection mechanism is configured, the script executes the random indicator file detection mechanism to check for file file modifications.

[0120] • If the random indicator file detection mechanism returns TRUE, ent is incremented by 2.

[0121] 4. File Similarity Detection Mechanism:

[0122] • If the file similarity detection mechanism is configured, the script executes the file similarity detection mechanism using fuzzy hashing.

[0123] • If the file similarity detection mechanism returns TRUE, ent is incremented by 1.

[0124] 5. File Type Changes Detection Mechanism:

[0125] • If the file type changes detection mechanism is configured, the script executes the file type changes detection mechanism to check for file type changes.

[0126] • If the file type changes detection mechanism returns TRUE, ent is incremented by 1.

[0127] 6. Logging: The script logs the count value after each check, providing information on the number of detected issues for each type of check. After all checks, the script logs the final count value.

[0128] 7. Weighted Classification for Faulty Node Determination: If the final count (ent) is greater than 1, an error log is generated, indicating that the node is faulty. Note that the threshold of 1 is a non-limiting example. Other thresholds, e.g., 0, 2, 3, etc., may be implemented according to various embodiments. Note that the threshold may be set dependent on the number and type of detection mechanisms implemented in a particular embodiment, given that the system is modular and extensible. Depending on the value of ent in relation to the threshold, the function returns either 1 (indicating a faulty node) or 0 (indicating that all checks passed successfully).

[0129] Diagnosis

[0130] The diagnosis module identifies and flags malfunctioning (e.g., attacked) nodes within the network. This approach involves discrete testing rounds, which may utilize the Adaptive DSD algorithm, and which propagate and verify the findings of the detection module. Furthermore, some embodiments may include node networkdisconnection monitoring, which marks any unresponsive or downed nodes as faulty, consequently revoking their trusted status within the network.

[0131] Some embodiments use at least one certificate authority (“CA”) 230 to ensure the authenticity of nodes. Each node is assigned a specific CA, and during testing rounds, nodes transmit their CA information to verify their identity. A distinctive feature, this process enhances the security and integrity of the network and helps to ensure that nodes are not spoofed.

[0132] Adaptive DSD

[0133] The Adaptive DSD algorithm not only implements nodes testing their neighbors, but also employs an adaptive testing structure that dynamically responds to the network’s fault condition. This approach does not impose a limit on the number of faulty nodes, making it highly adaptable and suitable for complex network environments.

[0134] The Adaptive DSD algorithm functions by having each node in the network identify another node that is fault-free and then update the original node’s diagnostic information based on this interaction. This process may involve each node typically testing one other node, with the testing structure being flexible enough to adapt to the prevailing fault situation in the network. Such adaptability is not only practical but also efficiently handles the number of tests required, thereby simplifying the overall data structure and process compared to earlier methods.

[0135] A strength of the Adaptive DSD algorithm lies in its efficiency, particularly in terms of the total number of tests performed. The algorithm ensures that each node is tested by exactly one fault-free node. This aspect is especially beneficial for large-scale networks where resource optimization is a critical concern. By minimizing thenumber of tests, the algorithm reduces the network’s operational overhead, making it a resource-efficient solution for network diagnostics.

[0136] The Adaptive DSD algorithm plays an important role in the efficient propagation of fault statuses across the network. It effectively creates a chain of trust among nodes, systematically constructing a pathway that connects non-faulty nodes. Through each testing cycle, the algorithm accurately distinguishes between faulty and nonfaulty nodes, facilitating a seamless and reliable identification process. This reliability is further enhanced by the integration of fault status hashing with the Adaptive DSD algorithm, creating a robust defense mechanism against potential network compromises.

[0137] Note that the disconnection of a node can serve as an early warning sign of ransomware activity. Ransomware often leads to unusual network patterns and heavy resource consumption, which can result in the isolation or disconnection of the affected node. By monitoring these signs, some embodiments can potentially detect ransomware infections at an early stage. This early detection is highly beneficial, as it allows for prompt intervention to isolate the compromised node, thereby preventing the spread of the ransomware to other parts of the network.

[0138] Given its numerous advantages, including adaptability, efficiency, and robust fault detection, the Adaptive DSD algorithm may be implemented in any embodiments disclosed herein, its implementation is expected to enhance the capability of an embodiment to accurately diagnose and maintain the health of the network. The implementation of the Adaptive DSD algorithm may provide a more resilient, efficient, and secure network environment.

[0139] Thus, the Adaptive DSD algorithm coordinates network diagnostics, particularly focusing on the interactions and fault detection between nodes in thedistributed network. According to various embodiments, this algorithm establishes secure communications, assesses the operational status of network nodes, and updates diagnostic data based on these assessments. Non-limiting example features of the Adaptive DSD algorithm are presented in detail below.

[0140] 1. Establishing Node Communication: An aspect of the Adaptive DSD algorithm involves establishing secure and reliable communication between nodes. Each node in the network has the capability to initiate and respond to diagnostic tests from its neighbors. This process includes setting up secure SSL communication, which is used to protect the exchange of diagnostic information from unauthorized access and tampering

[0141] 2. Test Node Identification: Within the network, each node is responsible for identifying a fault-free neighboring node and then updating its diagnostic information based on this interaction. This identification is typically based on a numerical order of the nodes, following a circular pattern. For instance, in a network that includes three nodes numbered 0, 1, and 2, node 1 would test node 2, node 2 would test node 0, and node 0 would test node 1.

[0142] 3. Adaptive Testing Mechanism: The algorithm conducts a fault status check of the nodes. If a node and its connected node are both non-faulty, or both are faulty, the algorithm proceeds to retrieve a diagnostic data array from the connected node. Subsequently, it updates its local diagnostic data with the information obtained from the connected node

[0143] 4. Diagnosis: A component of the Adaptive DSD algorithm is the diagnosis process, where each node methodically assesses the operational status of its connected node. This involves efficiently navigating through the network and utilizing the diagnostic data obtained from the connected node, while keeping track ofthe nodes that have already been checked to prevent redundancy. A goal is to ascertain the health of each node, thereby providing a detailed overview of the network’s overall condition. This step is used for pinpointing any nodes that are malfunctioning or compromised, thus ensuring the network’s overall reliability and effectiveness.

[0144] Certificate Authority 230

[0145] According to some embodiments, a CA is used to enhance the security of network communications by issuing and managing digital certificates. By integrating a CA within the network framework, nodes can authenticate the identities of their peers before data exchange. In scenarios where nodes attempt to transmit data, the presence of a CA-issued digital certificate ensures that the data originates from a genuine and trusted source. This certification acts as a cryptographic proof of the node’s authenticity. Potential attackers or malicious entities aiming to spoof data between nodes may be thwarted by this rigorous identity verification mechanism. Hence, the introduction of a CA not only bolsters the trustworthiness of data exchanges but also significantly reduces the risk of spoofing attacks, reinforcing the network’s overall security infrastructure.

[0146] In ransomware detection, there are at least two problems that may be addressed by using a CA: Man-ln-The-Middle (“MITM”) attacks and spoofing. For an MITM attack, the adversary may get in the middle of the communication between nodes. To prevent MITM attacks, some embodiments use SSL on the top of the TCP connection.

[0147] Also, when a node is in faulty status due the ransomware, the attacker may try to spoof by communication with the other nodes, sending messages to tell the other nodes that it is fine. To prevent spoofing, flag mode may be used. Flag modemeans that after each round of detection, the node will send a flag value to a CA to report its faulty status. Once a node is flagged as faulty, the CA won’t respond to a certificate signing request (“CSR”) of the node. Also, once flagged as faulty, the status can only be modified by the CA, not the node.

[0148] Fig. 4 is a flow diagram of an example CA process 400, according to various embodiments. The CA may implement public key cryptography, utilizing an asymmetric encryption and signature scheme, such as, by way of non-limiting example, RSA. A brief description of RSA follows. Let n = pq, where p and q are large secret primes. The message space is represented as P = 1n, and the signature space is represented as A = 1n. The key space is denoted as IK = {(n,p, q, a, h) I n = pq,ab = 1 (mod c|)(n))}, where 1 < e < (p N) such that gcd(e, 0(A)) = 1. Compute d such that ed = 1 (mod (A)). Given a message x and a private key K = (p, q, a), the signature is computed as sigK(x = xamod ri). For a message x with signature y and a public key (n, b), determine verK(x,y = true if and only if x = yb (modri) for x,y G 20.

[0149] When the CA is started 402 at flag mode, flags for all the allowed IPs are initially set as “FALSE” at 404. At 406, the CA determines whether flag mode is set. If so, it CA continuously listens to two ports 412, 422 (e.g., 3001 and 3000) for updating flag values and signing certificates, respectively. If not, the CA only listens to the port for signing certificates.

[0150] The updating flag values branch of the process 400 may operate as follows. The CA may maintain a whitelist of allowed IP addresses, which may be preconfigured before starting the CA, and which may be updated during operation. When a node attempts to communicate, the CA verifies whether the node’s IP address is on the whitelist at 414. If it is not, the CA will not process the node’s certificate signingrequest. Otherwise, the CA proceeds to determine whether it receives a flag value of 1 (or “TRUE”), at 416. If so, at 418, it updates its flag dictionary by adding a TRUE indication in association with the node’s IP address.

[0151] For the certificate signing branch of the process 400, when receiving a CSR from a node, the CA checks whether the IP address is in its whitelist at 424 and whether the node is not in faulty status at 426. Only when both requirements are met, the CA will process the CSR and send a signed certificate for the node at 428.

[0152] SSL socket may be used for communication among nodes, using the signed certificates. Each node may play the role of both a server and a client, to send and receive messages from the other nodes. For the server role, the certificate is used for the SSL handshake. For the client role, the client first verifies whether the hostname of the server matches with the server’s certificate, then verifies whether the server’s certificate is valid, with the CA PEM. When a node is in faulty status, it will not be able to get a valid certificate signed by the CA, thus SSL error will be thrown, preventing the faulty node from spoofing.

[0153] Modularity

[0154] The design of some embodiments incorporates modularity, which facilitates the easy integration of additional modules with minimal configuration requirements. This modular approach contributes to adaptability and scalability. One advantage of this approach is the plug-and-play capability it offers. This feature is particularly beneficial as it allows for rapid adaptation to emerging cybersecurity threats by seamlessly incorporating new detection mechanisms as they are developed. Furthermore, the plug-and-play nature simplifies the process of system updates and maintenance. New modules can be added or updated without the need for a complete overhaul of the existing system, thereby enhancing the system’s overallreliability. This approach also significantly reduces downtime associated with system updates, ensuring that embodiments remain operational and effective in a constantly evolving digital threat landscape.

[0155] Logging

[0156] Some embodiments include comprehensive logging, which facilitates diagnosing issues and understanding the system’s operations. This feature provides the following advantages:

[0157] • For Developers: Developers can use detailed logging for effective debugging, gaining insights into the system’s internal processes and quickly identifying and resolving issues.

[0158] • For Maintainers: Maintenance personnel can use logs to understand and correct the system’s functionality, as logs serve as a record of system performance and behavior.

[0159] • Additional Importance of Logging: Comprehensive logging is helpful for security auditing and compliance, allowing for the tracking of system activities and potential security incidents, thereby contributing to the overall security posture of the system.

[0160] Summary of Example Implementation

[0161] Fig. 5 is a flow chart of example detection actions for a method 500 of ransomware protection, according to various embodiments. The method 500 may be implemented by a distributed ransomware protection system in a distributed computer system that includes a plurality of nodes, e.g., as shown and described herein in reference to Fig. 1. Each node may include a subdomain non-transitory computer readable medium that includes a respective subdomain that is subject to a ransomware attack. The ransomware detection system may include, on each node, aprotection non-transitory computer readable medium that includes detection instructions. (Note that the same protection non-transitory computer readable medium may also include diagnosis instructions, as shown and described herein in reference to Fig. 6.) When an electronic processor on a node executes the detection instructions, they configure the electronic processor to perform detection actions as described presently.

[0162] At 502, the method 500 includes generating a plurality of respective random files of a plurality of file types. The actions of 502 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0163] At 504, the method 500 includes storing the plurality of respective random files in randomized locations within the respective subdomain. The actions of 504 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0164] At 506, the method 500 includes computing respective hash values for the plurality of respective random files, from which a plurality of respective baseline hash values are obtained. The actions of 506 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0165] At 508, the method 500 includes encrypting a respective configuration file comprising the plurality of respective baseline hash values, from which a respective encrypted configuration file is obtained. The actions of 508 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0166] At 510, the method 500 includes storing the respective encrypted configuration file in the respective subdomain. The actions of 510 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0167] At 512, the method 500 includes computing respective hash values for the plurality of respective random files, from which a plurality of respective updatedhash values are obtained. The actions of 512 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0168] At 514, the method 500 includes comparing the plurality of respective baseline hash values with the plurality of respective baseline hash values. The actions of 514 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0169] At 516, the method 500 includes storing, at the respective node, a respective fault condition indication, wherein the respective fault condition indication is based on at least a result of the comparing, wherein the respective fault condition indication is representative of a fault condition of the respective node. The actions of 516 may be as shown and described in reference to Fig. 2, reference 205, for example.

[0170] Fig. 6 is a flow chart of example diagnostic actions for a method 600 of ransomware protection, according to various embodiments. The method 600 may be implemented by a distributed ransomware protection system in a distributed computer system that includes a plurality of nodes, e.g., as shown and described herein in reference to Fig. 1. Each node may include a subdomain non-transitory computer readable medium that includes a respective subdomain that is subject to a ransomware attack. The ransomware detection system may include, on each node, a protection non-transitory computer readable medium that includes diagnosis instructions. (Note that the same protection non-transitory computer readable medium may also include detection instructions, as shown and described herein in reference to Fig. 5.) When an electronic processor on a node executes the diagnosis instructions, they configure the electronic processor to perform detection actions as described presently.

[0171] At 602, the method 600 includes maintaining a respective diagnostic record indicative of fault conditions of at least some of the plurality of nodes. The actions of 602 may be as shown and described in reference to Fig. 2, reference 220, for example.

[0172] At 604, the method 600 includes sending a request for a neighboring node diagnostic record to a fault free neighboring node. The actions of 604 may be as shown and described in reference to Fig. 2, reference 220, for example.

[0173] At 606, the method 600 includes receiving the neighboring node diagnostic record from the fault free neighboring node. The actions of 606 may be as shown and described in reference to Fig. 2, reference 220, for example.

[0174] At 608, the method 600 includes updating the respective diagnostic record based on the neighboring node diagnostic record. The actions of 608 may be as shown and described in reference to Fig. 2, reference 220, for example.

[0175] Evaluation of Example Embodiments

[0176] To test an example embodiment, the following experimental setup was used. The setup included three Microsoft Windows 10 (64-bit) VMware ESXi hosts, each equipped with 16GB RAM and 80GB disk storage. These nodes were interconnected within the same intranet, which included a pfSense Router capable of blocking both outbound and inbound connections during the execution of ransomware samples. An Ubuntu-64 bit was used as the CA server. Each Windows node executed protection actions according to an example embodiment, establishing a chain of trust every one minute to identify faulty nodes. The experimental setup was implemented in C and operated using the Cygwin terminal. Windows Defender protections were disabled on all nodes to prevent interference with the detection. To avoid detection by ransomware families, data with various file extensions was generated, making theenvironment appear similar to a typical system in a network. This ensured that ransomware operated within the controlled environment, allowing one to observe its behavior and assess the robustness of the prototype. Finally, snapshots were taken before running the ransomware. After analyzing its behavior, the system was revered back to the snapshot and the testing process repeated.

[0177] During the evaluation of the experimental setup, each module underwent rigorous testing, involving exposure to three distinct ransomware samples: WannaCry, Cerber, and TeslaCrypt. The Adaptive DSD Algorithm was configured to update every 30 seconds during these evaluations. Following these individual assessments, a comprehensive evaluation of the embodiment was conducted, this time employing a weighted algorithm with an update rate of 1 minute and incorporating five ransomware samples.

[0178] Furthermore, the Adaptive DSD algorithm underwent testing with a single ransomware sample, specifically evaluating its functionality in ensuring node health reporting even when a node is unavailable. The subsequent observations provide insights into the individual robustness or drawbacks of specific sub-modules, along with an examination of their collective performance facilitated by the weighted algorithm. This thorough evaluation provided a comprehensive understanding of the embodiment’s effectiveness in detecting and mitigating ransomware threats in diverse scenarios.

[0179] File Entropy Evaluation

[0180] To evaluate the accuracy of file entropy, the inventors conducted testing using the WannaCry, Cerber, and TeslaCrypt ransomware samples. The testing procedure initiated by performing entropy analysis on Node 1, focusing on the ransomware under examination. Subsequently, the inventors documented whetherthe other two nodes, namely Node 0 and Node 2, were informed of this development. Following this initial test, we replicated the procedure on Node 2, assessing whether Node 0 could detect the infection on both Node 1 and Node 2.

[0181] The results include scenarios where a single node was infected, successful detection at the diagnostic level by both Nodes 2 and Node 0, and instances where both nodes were infected, with Node 0 detecting the infection for both nodes, for the specified ransomware samples. The detailed outcomes of each individual ransomware test observation, along with corresponding results, are discussed below.

[0182] WannaCry: The inventors initiated the execution of WannaCry on Node 1 at 13:06, and the same time, the encryption process of files commenced. At 13:09, the WannaCry ransomware note became visible. Interestingly, the file entropy module had already detected the encryption at 13:07, underscoring the efficacy of entropy as a reliable indicator for ransomware detection. Simultaneously, the system transmitted these results to other nodes, including Node 0 and Node 2, at the same timestamp. Consequently, Nodes 0 and 2 were informed about the ongoing encryption on Node 1 one minute prior to its completion, allowing ample time for remediation actions and potential removal of Node 1 from the network.

[0183] Subsequently, the inventors proceeded to execute WannaCry on Node 2 at 13:14. While the encryption process initiated promptly, files were not fully encrypted until 13:18 when the ransomware note appeared. Remarkably, the file entropy module identified Node 2 as faulty at 13:15, promptly notifying Node 0 at the same time. By 13:16, Node 0 confirmed the infection on Node 2, providing a two-minute lead in detection before the completion of the encryption process. Consequently, Node 0 now indicated infections on both Node 1 and Node 2. Theseobservations underscore the precision of the file entropy module as a detection mechanism, positioning it as a viable candidate for inclusion in a weighted algorithm.

[0184] Cerber: The inventors executed the Cerber ransomware on Node 1 at 13:49, and it promptly displayed the ransomware note at the same time, encrypting only documents and the desktop folder, demonstrating its swift operation. The File Entropy module detected this ransomware activity on Node 1 at 13:49, concurrently transmitting the alert to other nodes. By 13:50, both Node 0 and Node 2 indicated that Node 1 was infected. Notably, File Entropy consistently provided proactive results in this instance.

[0185] Consequently, the inventors conducted another Cerber ransomware run, this time on Node 2 with Node 1 already infected. The execution on Node 2 commenced at 13:52, completing the encryption of documents and the desktop folder almost instantly. The ransomware note appeared at 13:53. Node 2 successfully identified this development using the File Entropy module at 13:53, simultaneously alerting Node 0. By 13:54, Node 0 reflected that every connected node was faulty. In another ransomware execution scenario, File Entropy adeptly detected file encryption and seamlessly communicated this information to other nodes.

[0186] TeslaCrypt: Finally, the inventors executed the file entropy sub-module again, this time with the TeslaCrypt ransomware, as file entropy had previously consistently yielded positive results. The inventors initiated the execution of the TeslaCrypt ransomware on Node 1 at 14:09, and the encrypted files began to manifest at 14:10. The entropy module on Node 1 detected this ransomware activity at 14:11 and promptly alerted the other nodes simultaneously. Node 2 and Node 0 both indicated that Node 1 was infected by 14:12 during their next update cycle. Despitethis, the File Entropy module once again demonstrated its success in detecting ransomware activity.

[0187] Subsequently, the inventors introduced TeslaCrypt to Node 2, already having Node 1 infected. The execution on Node 2 commenced at 14:17, with file encryption starting around 14:18. Concurrently, the File Entropy module identified Node 2 as faulty at 14:18, alerting Node 0 of this development. By 14:19, Node 1 reflected both Node 2 and Node 1 as faulty. Once more, File Entropy exhibited success in detecting ransomware activity and effectively communicated this information to the other nodes.

[0188] To summarize, the embodiment triggered timely alerts on multiple nodes, signaling potential infections before complete encryption. This outcome positions the file entropy detection mechanism as a useful sub-module within the weighted algorithm. A substantial weight of 2 may be used to recognize its crucial role in the detection strategy, attributing its efficacy to the accurate identification of infections across interconnected nodes.

[0189] Random Indicator Files Evaluation

[0190] To assess the efficacy of ransomware random indicator files, the inventors conducted an analysis utilizing samples of the WannaCry, Cerber, and TeslaCrypt ransomware. The testing began with the ransomware random indicator files sub-module enabled on Node 1, focusing specifically on the ransomware under investigation. Subsequently, the inventors determined whether the other two nodes, namely Node 0 and Node 2, were notified of this development. Following this preliminary examination, the inventors replicated the procedure on Node 2, assessing whether Node 0 was also alerted to the potential network-wide faults across all nodes.

[0191] The detailed outcomes of each individual ransomware test observation, along with their corresponding results, are delineated below.

[0192] WannaCry: The inventors executed the WannaCry ransomware on Node 1, observing encryption initiation almost immediately. The process was initiated at 15:04, and Node 1 locally detected it promptly at the same time. Notably, the ransomware random indicator files demonstrated quicker detection compared to file entropy. Node 0 and Node 2 were alerted to this development at 15:05. These notifications occurred well in advance of the completion of the WannaCry ransomware encryption on all files, underscoring the efficacy of the detection sub-module. The ransomware note on Node 1 appeared at 15:08, allowing other nodes approximately 3 minutes to disconnect Node 1 from the network.

[0193] Subsequently, the inventors initiated the WannaCry ransomware on Node 2, with Node 1 already infected. The ransomware on Node 2 commenced at 15:09 and initiated file encryption, completing the entire process by 15:13. Concurrently, Node 2 locally detected ransomware activity using the ransomware random indicator files sub-module at 15:10 and promptly communicated this update to Node 0. Node 0 was informed simultaneously, resulting in both Node 1 and Node 2 being identified as faulty. Once again, these notifications occurred prior to the appearance of the ransomware note. The ransomware random indicator files consistently demonstrated swift detection compared to file entropy. Nevertheless, the results of the ransomware random indicator files position them as potential candidates for inclusion in the weighted algorithm, as inferred from these observations.

[0194] Cerber: Continuing the assessment, the inventors deployed the ransomware random indicator files sub-module again, this time with the Cerber ransomware. The execution occurred on Node 1 at 15:27. Remarkably, theransomware note was observed within a mere 45 seconds, given Cerber’s specific focus on encrypting documents and desktop files. Prior to the appearance of the ransomware note, the ransomware random indicator files efficiently detected the node’s faultiness and communicated this information to other nodes, namely Node 0 and Node 2. By 15:28, both Node 0 and Node 2 displayed awareness of Node 1’s faultiness. This aligns with our earlier observations with WannaCry, affirming the ransomware random indicator files’ rapid and effective detection capability.

[0195] To further validate the efficacy of random indicator files, the inventors repeated the Cerber ransomware test on Node 2, initiating it at 15:30. Once again, the ransomware note manifested in approximately 40 seconds. Concurrently, the ransomware random indicator files sub-module promptly detected this malicious activity and relayed the update to Node 0, notifying it of the ongoing development. Consequently, Node 0 swiftly acknowledged that every node in the network was compromised, highlighting the random indicator files sub-module’s exceptional speed. In both instances, the experimental setup successfully detected Cerber ransomware activity on both nodes, reinforcing the notion that ransomware random indicator files serve as potent indicators of ransomware activity, potentially emerging as the most reliable indicators.

[0196] TeslaCrypt: Finally, the inventors executed the ransomware random indicator files sub-module again, this time with TeslaCrypt ransomware, given the positive results observed thus far with the ransomware random indicator files. The TeslaCrypt ransomware was initiated on Node 1 at 15:48. The files began encrypting momentarily, and it took approximately 1 minute to observe the encrypted files. At 15:50:35, the ransomware note became visible. However, the ransomware random indicator files sub-module had already detected ransomware activity at 15:49,promptly conveying this information to other nodes, namely Node 0 and Node 2 simultaneously. Both nodes received and acknowledged this information concurrently, demonstrating that the ransomware random indicator files conveyed the alert before the ransomware note was displayed.

[0197] Once again, the inventors ran the TeslaCrypt ransomware on Node 2, with Node 1 already infected. The execution occurred at 15:54, and the encryption of files began after 2 minutes, at 15:56. As soon as the files were encrypted, the experimental setup detected the activity at 15:56 and promptly communicated this information to Node 0. Node 0 was informed simultaneously and, at that moment, displayed all nodes in the network as faulty. Although the ransomware note appeared at 15:59, Node 0 was already aware of the situation, providing ample time to isolate the affected node from the network. In either case, the ransomware random indicator files demonstrated remarkable speed, positioning them as strong candidates for inclusion in a weighted algorithm.

[0198] As demonstrated in the above analysis of ransomware random indicator files, they exhibit a high degree of speed in detecting various ransomware samples, namely WannaCry, Cerber, and TeslaCrypt, achieving a 100% accuracy rate with no false positives / negatives. Based on the observed results, the ransomware random indicator files should be considered a highly robust submodule capable of efficiently detecting ransomware activity. Consequently, and by way of non-limiting example, the inventors assigned it a weight of 2 in the weighted algorithm due to its speed and accuracy. This substantial weight acknowledges its critical role in the detection strategy, attributing its efficacy to the accurate identification of infections across interconnected nodes.

[0199] File Type Changes Evaluation

[0200] The testing for file type changes involved only two ransomware samples, namely, WannaCry and Cerber. The testing began with the file type changes detection mechanism enabled on Node 1. Subsequently, the inventors ascertained whether the other two nodes, namely Node 0 and Node 2, were notified of Node 1 being infected.

[0201] Following this preliminary examination, the inventors replicated the procedure on Node 2, assessing whether Node 0 was also alerted to potential network-wide faults across all nodes. The detailed outcomes of each individual ransomware test observation, along with their corresponding results, are provided below.

[0202] WannaCry: The inventors initiated testing of the file type changes detection mechanism using the WannaCry ransomware. First, the inventors infected Node 1 to assess whether the detection occurred at the system level. The execution of WannaCry began at 16:32, initiating file encryption simultaneously. Remarkably, the file type changes detection mechanism detected ransomware activity before the ransomware note was displayed, precisely at 16:32. The detection mechanism promptly transmitted this update to other nodes, namely Node 0 and Node 2, at 16:33, providing sufficient time for disconnecting the affected node from the network. The ransomware note was finally observed at 16:36, affording approximately 3 minutes for network disconnection. In either case, the file type changes detection mechanism demonstrated rapid and effective detection.

[0203] Subsequently, the inventors initiated WannaCry on Node 2 with Node 1 already infected at 16:37. The detection mechanism promptly detected node faultiness at 16:37 and communicated this information to Node 0 at 16:38. Node 0, in turn, identified a network-wide fault, signaling the necessity to remove both nodes from the network.

[0204] Interestingly, the WannaCry ransomware note was displayed at 16:41, underscoring the notably faster response of the file type changes detection mechanism in providing results on potential file modifications or tampering. In both instances, the results for the file type changes detection mechanism were positive for the WannaCry ransomware sample.

[0205] Cerber: To further assess the robustness of the file type changes detection mechanism, the inventors conducted tests with the Cerber ransomware. Node 1 was infected at 16:51, and the encryption process happened within a few seconds, displaying the ransomware note. However, the file type changes module failed to detect Cerber ransomware.

[0206] Despite the encryption of documents and the desktop folder, the file type changes were unable to identify this encryption process. Consequently, Cerber went undetected by Node 1, and Nodes 0 and 2 were not informed of this development, potentially allowing the ransomware to spread across the network if only the file type changes module were relied upon.

[0207] The inventors ran Cerber again on Node 2 to test whether the file type changes would work against Cerber, as it did not in the previous attempt. Cerber was initiated on Node 2 at 16:56, completing the file encryption process in 40-45 seconds and displaying the ransomware note. This time, Node 2 did not indicate its faultiness at 16:56, and it did not transmit this information to Node 0 at 16:57.

[0208] In summary, the effectiveness of the file type changes detection mechanism in detecting Cerber ransomware varied between Node 1 and Node 2, with successful detection on Node 2 but not on Node 1, resulting in a 75% detection rate overall. Despite these variations, the inventors still consider the file type changes detection mechanism as suitable for inclusion in the weighted algorithm, assigning it aweight of 1. Overall, the file type changes detection mechanism has demonstrated reliability as an indicator for ransomware in certain cases, with a 50% correct detection rate for Cerber and a 100% detection rate for WannaCry.

[0209] File Similarity Evaluation

[0210] The inventors conducted tests on the fourth detection mechanism, namely file similarity, using two ransomware samples, WannaCry and Cerber. The testing procedure commenced by infecting Node 1 and subsequently checking whether other nodes were alerted. Following this initial examination, the inventors replicated the procedure on Node 2, evaluating whether Node 0 was also alerted to potential network-wide faults across all nodes. The detailed results and observations of each individual ransomware test, along with their corresponding outcomes, are provided below. Additionally, a summarized table encapsulating the results is presented and discussed subsequently.

[0211] WannaCry: the inventors initiated the execution of the WannaCry ransomware on Node 1 at 17:57, and the file similarity detection mechanism promptly detected the activity at the same time, simultaneously alerting other nodes. This proactive detection occurred before the ransomware note was displayed, showcasing preemptive action before all files in the system were encrypted.

[0212] Following this success, the inventors proceeded to run WannaCry on Node 2 at 18:02. Remarkably, the file similarity detection mechanism efficiently detected this ransomware activity on Node 2 at 18:03, and the update was promptly transmitted to Node 0. As a result, Node 0 was swiftly made aware that both nodes were faulty, once again preceding the appearance of the ransomware note at 18:05. The consistent performance of the file similarity detection mechanism demonstrated its effectiveness in detecting WannaCry ransomware activity on the nodes.

[0213] Cerber: To further assess the robustness and detection rate of the file similarity detection mechanism, the inventors tested it with Cerber ransomware. The inventors infected Node 1 at 18:15, and although Cerber swiftly infected the node, the file similarity detection mechanism did not detect it. Consequently, it provided a false negative value, indicating that Node 1 was not faulty when, in reality, it was infected. Other nodes were not informed of this situation and continued to communicate with Node 1. To gain a comprehensive perspective on the efficacy of the file similarity detection mechanism, the inventors conducted a similar test on Node 2.

[0214] The inventors ran the Cerber ransomware on Node 2 at 18:17, once again, with the file similarity detection mechanism failing to detect ransomware activity on Node 2. This resulted in Node 0 being unaware that Node 2 was infected with Cerber. Currently, both nodes are infected, but Node 0 is oblivious to this development and continues to communicate with Node 2. One reason for this discrepancy is that file similarity examines files in a specific directory and checks if a file with the same filename, after trimming the extension, is present. Since Cerber renames files with random names along with the new extension, file similarity is unable to find a similar file with the same name, highlighting a limitation of using file similarity.

[0215] In summary, file similarity was only able to detect WannaCry ransomware, as WannaCry does not rename the base names of the files but only appends the extension. In contrast, Cerber renames filenames with random names and includes the new extension, rendering file similarity effective only with a success rate of 50%. Nevertheless, it is effective enough to warrant including in an ensemble detection technique, as disclosed herein. It is assigned a weightage of 1 for the weighted algorithm.

[0216] Weighted Classification Evaluation

[0217] After identifying limitations in the functionality of certain detection mechanisms, the inventors have opted for a weighted approach to enhance the robustness of ransomware detection at a behavioral level, rather than exclusively concentrating on the signature of the ransomware itself. This strategy aims to ensure that behavioral detection encompasses diverse avenues, avoiding an exclusive focus on a singular approach or vector. Moreover, the ensemble approach is expected to be more effective than any single approach in isolation.

[0218] The ensemble methodology integrates various approaches, prioritizing ransomware random indicator files and file entropy due to their lower occurrence of false negatives and higher accuracy. The inventors assert that these elements serve as reliable indicators for identifying the presence of ransomware in the wild. Ransomware random indicator files, when modified or tampered with, are easily detected, and file entropy, particularly in the context of encryption, can effectively highlight files exhibiting a high degree of ransomware-like characteristics.

[0219] In this context, the inventors present herein the results of the weighted algorithm, demonstrating its effectiveness in detecting four instances of ransomware. Following our established procedure, the inventors initially infect node 1 and subsequently assess whether node 0 and node 2 can detect the intrusion. The inventors then proceed to infect node 2, evaluating whether node 0 can detect the compromise on node 2. This approach allows for evaluating the efficacy of the tool in handling ransomware samples.

[0220] WannaCry: The inventors initiated the infection process on Node 1 with WannaCry at 8:19, coinciding with the commencement of the encryption process. Remarkably, detection occurred simultaneously at 8:19, registering a count of 5 at thesystem level. Detection mechanisms responsible for detection included file entropy, file type changes, and ransomware random indicator files. Notably, Node 0 received prompt notification of this occurrence at 8:20, while Node 2 detected it at 8:21. By 8:22, the encryption process on Node 1 concluded, yet Nodes 0 and 2 were already apprised of the infection. A socket error surfaced in Nodes 0 and 2, indicating WannaCry’s efficacy in encrypting files, rendering the node inaccessible, and severing communication with other nodes.

[0221] Subsequently, WannaCry ransomware was executed on Node 2 at 8:24. By 8:25, Node 2 detected ransomware activity locally and concurrently alerted Node 0. However, the intricacy count for Node 2 was 3, with random indicator files and file type detection mechanisms being effective, unlike file entropy. It is plausible that, during the execution of file entropy, either the files were not encrypted, or the randomly chosen files were not encrypted files. Socket errors were also observed in Node 2, indicating the failure to close the socket. The overall result indicated that the experimental setup, employing four modules, led to the detection of 3 instances on the first node and 2 on the second.

[0222] Despite WannaCry halting the program and disrupting communication through socket closure, the ransomware was still successfully detected by other nodes. In either case, the weighted algorithm facilitated the detection of WannaCry ransomware activity.

[0223] Cerber: The initiation of the Cerber ransomware on Node 1 at 8:57 resulted in an exceptionally rapid encryption process, concluding within a minute and surpassing the speed observed in other encountered ransomwares. This expeditious encryption can be attributed to Cerber’s specific target selection, focusing solely on documents and the desktop folder. Local detection on Node 1 occurred promptly at8:58, facilitated by the random indicator files detection mechanism, which carried a weight of 2 in the weighting count, while other detection mechanisms failed to detect the ransomware. Simultaneously, a faulty status was communicated by Node 1 at this juncture. Despite this, the experimental setup program continued to operate seamlessly, transmitting updates to Nodes 0 and 2 about Node 1 ’s compromised state. Node 2 detected the faulty status at 8:58, whereas Node 0 registered it slightly later at 8:59, thereby ensuring that the ransomware activity was promptly identified by both nodes.

[0224] Subsequently, Cerber ransomware was executed on Node 2 at 9:04. Notably, Node 2 autonomously detected Cerber ransomware activity at 9:05 and disseminated this information to other nodes concurrently at 9:05.

[0225] Interestingly, in Node 2, the detection mechanisms responsible for Cerber detection included file entropy, file type changes, and ransomware random indicator files, resulting in a total weight of 5. Node 0 received this information at 9:06, thereby gaining awareness of the faulty status of both Node 1 and Node 2. This expeditious and comprehensive detection of Cerber ransomware activity by the experimental setup highlights its effectiveness in swiftly identifying and communicating compromised states within the network.

[0226] Hive: The Hive ransomware was executed on Node 2 at 10:20, and its detection occurred locally on the same node at 10:23. Subsequently, Node 2 promptly disseminated this information to other nodes within the network. Hive, known for encrypting files across all folders and rendering the node unreachable, effectively halted all communication. The detection on Node 1 took place at 10:25:52 and at 10:26 on Node 0. The detection relied solely on the ransomware random indicator files count, with no positive feedback from other detection mechanisms.Consequently, the weighted count for detection was 2. Despite the challenges posed by Hive’s encryption and communication termination, both Nodes 1 and 0 successfully detected the ransomware on Node 2.

[0227] Continuing with the evaluation, Hive ransomware was executed on Node 1 at 10:28, initiating the process by inserting files titled “how to decrypt” across all folders. Notably, it encrypted the entire user directory, including the experimental setup code. At 10:30, two detection mechanisms, namely random indicator files and file type, demonstrated effectiveness on Node 1, yielding a total weight of 3. However, entropy and file similarity did not provide any positive feedback. Locally, Node 1 detected Hive ransomware at 10:31 and promptly communicated this information to Node 0 at the same time. Node 0 received the update during the next cycle at 10:32. While random indicator files and file type worked for Node 1, only random indicator files was effective for Node 2. The encryption process and termination of all connections resulted in socket errors, indicating the loss of files or the node being down. All files were transformed into Hive files, appended with strings of random values and “.hive.” For instance, “apple.txt” became “apple. txt. WSHJDKHSJKDHasdjashdjasdhjkasd. hive.” In summary, both nodes were successfully detected by Node 0, affirming the confidence in the weighted algorithm’s capability to identify Hive ransomware and highlighting the experimental setup as a robust security tool.

[0228] TeslaCrypt: Teslacrypt ransomware was executed on Node 1 at 11:45, swiftly encrypting the entire user directory, encompassing files such as pictures, downloads, music, and videos. The random indicator files detection mechanism proved effective, detecting the ransomware at 11:46 and promptly alerting other nodes, specifically Node 0 and Node 2, by 11:47. However, the encryption processwas expedient, leading to the encryption of the experimental setup files on Node 1, resulting in the failure of the program due to the unavailability of imported Python packages and the occurrence of socket errors. Despite the rapid encryption by Teslacrypt, the random indicator files detection mechanism played a crucial role in detection and subsequent notification to other nodes. Following this, Node 1 became unresponsive, ceasing communication entirely. File extensions were appended with “ecc,” transforming files like “apple.txt” into “apple. txt.ecc.” The weighted count in this instance was 2, as no other modules demonstrated functionality.

[0229] In a subsequent test on Node 2 at 11:51, Teslacrypt initiated the encryption process, requiring approximately 2 minutes to complete. Entropy provided a value of 2 and was communicated to Node 0 at 11:53. Notably, the random indicator files check could not be performed due to the encrypted files. Similar to the scenario in Node 1, Node 2 ceased all communication, becoming unresponsive and presenting socket errors. Node 0, however, successfully detected the faulty states of both Node 1 and Node 2. Intriguingly, in one case, random indicator files detection was successful, while in the other, entropy played a pivotal role. Regardless, the awareness and prompt communication of these developments to other nodes prevented the spread of the ransomware within the network. This highlights the significance of the weighted algorithm, as one detection mechanism might not work in one case, but the other one works on another node. But as a whole, the ensemble still get positive results.

[0230] Locky: Locky ransomware was executed on Node 1 at 12:20, initiating the encryption process that took approximately 3 minutes to commence at 12:23. Entropy proved effective in detection, resulting in a weighted count of 2, while none of the other modules demonstrated functionality. Local detection at the node leveloccurred promptly at 12:23, precisely when the encryption started, and this information was immediately communicated to Node 0 and Node 2. Both nodes were alerted at 12:23, signaling the rapid detection and transmission of the encrypted status. The file extension was altered to ‘ykcol,’ and filenames were changed to “TM2hqwkehwqjhekwq.ykcol.” Notably, despite encrypting the experimental setup code, the Python packages remained unaffected, allowing the code to continue running. This successful detection of Locky ransomware on Node 1 highlighted the system’s robustness.

[0231] Continuing with the evaluation, Locky ransomware was deployed on Node 2 at 12:29, aiming to determine if Node 0 could detect the faulty status of both nodes. The encryption process, completed within 2 minutes by 12:31, displayed a lock message. Entropy once again proved effective in detection, while random indicator files and other detection mechanisms did not detect the ransomware. Detection occurred promptly at 12:30, and Node 0 was promptly alerted. This rapid detection ensured that the network was secure, allowing for timely disconnection of the infected nodes with ransomware. In both instances, ensemble weighted algorithm emerged as a reliable mechanism for detecting Locky ransomware, emphasizing its effectiveness in identifying and mitigating such threats.

[0232] In summary, the evaluation of various ransomware samples using the weighted algorithm within the experimental setup system yielded insightful results. For WannaCry, the weighted count was 5, with file entropy, file type changes, and ransomware random indicator files contributing to its successful detection on Node 1 and a weight count of 3 for Node 2. Cerber demonstrated rapid detection on Node 1 through the random indicator files detection mechanism, giving it a weight of 2, and comprehensive detection on Node 2, involving file entropy, file type changes, andransomware random indicator files, giving it a weight of 5 in the second case. Despite its encryption speed, Hive was consistently detected by both nodes, emphasizing the weighted algorithm’s efficiency with a count of 2 in Node 1’s case and 3 in Node 2’s case.

[0233] Interestingly, in Teslacrypt, with a weighted count of 2, it was swiftly detected on Node 1 through the random indicator files detection mechanism, and on Node 2, entropy played a pivotal role in detection. Finally, Locky, with a weighted count of 2, was successfully detected on both Node 1 and Node 2, primarily through the entropy detection mechanism. In all, the weighted algorithm, leveraging the collective strength of different detection mechanisms, demonstrated its resilience in identifying and mitigating diverse ransomware threats, ensuring robust security within the network.

[0234] Adaptive DSD Algorithm Evaluation

[0235] When a single node out of the three nodes halted the experimental setup program, the other two nodes successfully detected this and alerted about the issue in their subsequent update cycle. Similarly, when the inventors stopped the experimental setup on the second node, the third node indicated that both nodes were faulty. This signaling mechanism demonstrates that if any nodes become disconnected or if communication is no longer established, the nodes are flagged as faulty. This functionality ensures that the experimental setup operates against attempts to stop the tool or modify the code. In the case of runtime code modifications, the code integrity check ensures the detection of any tampering. In either scenario, network disconnection is prevented, allowing the experimental setup to continuously and uninterruptedly keep all nodes in the network updated with each node’s health. This mechanism proves valuable for maintaining the overall integrity of the network.

[0236] One method for testing node unavailability is by examining the impact of ransomware that renders a node inaccessible. In the evaluation of the experimental setup, the inventors identified Petya as a ransomware with such characteristics. The results obtained when deploying the experimental setup against Petya are discussed below.

[0237] Petya: Petya ransomware was executed on Node 1 at 21:05, triggering an abrupt and critical event — the Windows system displayed the infamous blue screen of death, necessitating a system restart. Upon reboot, it became apparent that Petya had encrypted the Master Boot Record (MBR) and all disk space, rendering the Windows operating system unbootable. Simultaneously, Node 1 ceased responding to communication attempts from other nodes, prompting Nodes 0 and 2 to deduce the faulty status of Node 1. The Adaptive DSD algorithm played a crucial role in this detection process, regularly checking the health status of nodes every minute.

[0238] As Node 1 abruptly went offline, the detection module was unable to function; however, the Diagnose module, which examines the responsiveness of each node, successfully identified Node 1’s fault and relayed this information to Nodes 0 and 2.

[0239] Subsequently, Petya ransomware was initiated on Node 2 at 21:15, yielding similar results, where Node 0 efficiently identified both nodes as faulty. In this instance, the Diagnose module emerged as a crucial component, compensating for the non-operational Detection module and proving instrumental in detecting Petya and other ransomwares with similar disruptive behaviors.

[0240] In summary, due to the Adaptive DSD, Petya ransomware was identified on the node, leading to the notification of other nodes as the infected node ceased communication. Petya encrypted the MBR, causing a Windows system crash with ablue screen of death, rendering it inoperable upon the next bootup. This compensatory mechanism, using the diagnosis module alongside the detection module, distinguishes the experimental setup as a ransomware detection tool.

[0241] Certain examples can be performed using a computer program or set of programs. The computer programs can exist in a variety of forms both active and inactive. For example, the computer programs can exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats; firmware program(s), or hardware description language (HDL) files. Any of the above can be embodied on a transitory or non-transitory computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Exemplary computer readable storage devices include conventional computer system RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes.

[0242] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented using computer readable program instructions that are executed by a processor.

[0243] These computer readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0244] In embodiments, the computer readable program instructions may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, statesetting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the C programming language or similar programming languages. The computer readable program instructions may execute entirely on a user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.

[0245] As used herein, the terms “A or B” and “A and / or B” are intended to encompass A, B, or {A and B}. Further, the terms “A, B, or C” and “A, B, and / or C” are intended to encompass single items, pairs of items, or all items, that is, all of: A, B, C, {A and B}, {A and C}, {B and C}, and {A and B and C}. The term “or” as used herein means “and / or.

[0246] As used herein, language such as “at least one of X, Y, and Z,” “at least one of X, Y, or Z,” “at least one or more of X, Y, and Z,” “at least one or more of X, Y, or Z,” “at least one or more of X, Y, and / or Z,” or “at least one of X, Y, and / or Z,” is intended to be inclusive of both a single item (e.g., just X, or just Y, or just Z) and multiple items (e.g., {X and Y}, {X and Z}, {Y and Z}, or {X, Y, and Z}). The phrase “at least one of” and similar phrases are not intended to convey a requirement that each possible item must be present, although each possible item may be present.

[0247] The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function]...” or “step for [performing [a function]...”, it is intended that such elements are to be interpreted under 35 U. S. C. § 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U. S. C. § 112(f).

[0248] While the invention has been described with reference to the exemplary examples thereof, those skilled in the art will be able to make various modifications to the described examples without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method can be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.

Claims

What is claimed is:

1. A distributed ransomware protection system for a distributed computer system comprising a plurality of nodes, wherein a respective node of the plurality of nodes comprises a respective subdomain non-transitory computer readable medium comprising a respective subdomain that is subject to a ransomware attack, wherein the ransomware detection system comprises, on the respective node of the plurality of nodes, a respective protection non-transitory computer readable medium comprising detection instructions and diagnosis instructions;wherein the detection instructions, when executed by a respective electronic processer of the respective node of the plurality of nodes, configure the respective electronic processor to perform detection actions comprising:generating a plurality of respective random files of a plurality of file types;storing the plurality of respective random files in randomized locations within the respective subdomain;computing respective hash values for the plurality of respective random files, from which a plurality of respective baseline hash values are obtained;encrypting a respective configuration file comprising the plurality of respective baseline hash values, from which a respective encrypted configuration file is obtained;storing the respective encrypted configuration file in the respective subdomain;computing respective hash values for the plurality of respective random files, from which a plurality of respective updated hash values are obtained;comparing the plurality of respective baseline hash values with the plurality of respective baseline hash values; andstoring, at the respective node, a respective fault condition indication, wherein the respective fault condition indication is based on at least a result of the comparing, wherein the respective fault condition indication is representative of a fault condition of the respective node;wherein the diagnosis instructions, when executed by the respective electronic processer of the respective node of the plurality of nodes, configure the respective electronic processor to perform diagnosis actions comprising:maintaining a respective diagnostic record indicative of fault conditions of at least some of the plurality of nodes;sending a request for a neighboring node diagnostic record to a fault free neighboring node;receiving the neighboring node diagnostic record from the fault free neighboring node; andupdating the respective diagnostic record based on the neighboring node diagnostic record.

2. The system of claim 1, wherein the respective fault condition indication is based on a result of the comparing indicating a number of mismatches between the plurality of respective baseline hash values and the plurality of respective baseline hash values, wherein the number is greater than one.

3. The system of claim 1, wherein the respective configuration file further comprises file paths for the plurality of respective random files.

4. The system of claim 1,wherein the respective node has an associated respective asymmetric key pair comprising a respective public key and a respective private key;wherein the respective node is associated with a respective certificate authority that stores a copy of the respective public key;wherein the respective certificate authority signs an initial certificate comprising the respective public key; andwherein the detection actions further comprise sending the respective fault condition indication to the respective certificate authority, whereby the respective certificate authority does not provide an updated certificate if the respective node is not fault free.

5. The system of claim 4, wherein the request for the neighboring node diagnostic record is encrypted using the initial certificate.

6. The system of claim 1,wherein the detection actions further comprise determining whether file types of files on the respective node have changed; andwherein the respective fault condition indication is further based on results of the determining.

7. The system of claim 1,wherein the detection actions further comprise determining entropy values of a randomly-selected plurality of respective files in the respective subdomain; andwherein the respective fault condition indication is further based on a number of the randomly-selected plurality of respective files that have entropy values that exceed a threshold.

8. The system of claim 1,wherein the detection actions further comprise determining whether hash values of files comprising the detection instructions and the diagnosis instructions have changed; andwherein the respective fault condition indication is further based on results of the determining.

9. The system of claim 1,wherein the detection actions further comprise determining whether fuzzy hash values of files on the respective node have changed; andwherein the respective fault condition indication is further based on results of the determining.

10. The system of claim 1, wherein the respective fault condition indication is further based on: detected changes to file types of files on the respective node, detected changes to entropy values for files on the respective node, detected changes of hash values for files comprising the detection instructions and the diagnosis instructions, and detected changes of fuzzy hash values for files on the respective node.

11. A method for distributed ransomware protection of a distributed computer system, wherein the distributed computer system comprises a plurality of nodes, wherein a respective node of the plurality of nodes comprises a respective subdomain non-transitory computer readable medium comprising a respective subdomain that is subject to a ransomware attack, the method comprising:performing detection actions, by a respective electronic processer of a respective node of the plurality of nodes executing non-transitory detection instructions; andperforming diagnosis actions, by the respective electronic processer of a respective node of the plurality of nodes executing non-transitory diagnosis instructions;wherein the detection actions comprise:generating a plurality of respective random files of a plurality of file types;storing the plurality of respective random files in randomized locations within the respective subdomain;computing respective hash values for the plurality of respective random files, from which a plurality of respective baseline hash values are obtained;encrypting a respective configuration file comprising the plurality of respective baseline hash values, from which a respective encrypted configuration file is obtained;storing the respective encrypted configuration file in the respective subdomain;computing respective hash values for the plurality of respective random files, from which a plurality of respective updated hash values are obtained;comparing the plurality of respective baseline hash values with the plurality of respective baseline hash values; andstoring, at the respective node, a respective fault condition indication, wherein the respective fault condition indication is based on at least a result of the comparing, wherein the respective fault condition indication is representative of a fault condition of the respective node; andwherein the diagnosis actions comprise:maintaining a respective diagnostic record indicative of fault conditions of at least some of the plurality of nodes;sending a request for a neighboring node diagnostic record to a fault free neighboring node;receiving the neighboring node diagnostic record from the fault free neighboring node; andupdating the respective diagnostic record based on the neighboring node diagnostic record.

12. The method of claim 11, wherein the respective fault condition indication is based on a result of the comparing indicating a number of mismatches between the plurality of respective baseline hash values and the plurality of respective baseline hash values, wherein the number is greater than one.

13. The method of claim 11, wherein the respective configuration file further comprises file paths for the plurality of respective random files.

14. The method of claim 11,wherein the respective node has an associated respective asymmetric key pair comprising a respective public key and a respective private key;wherein the respective node is associated with a respective certificate authority that stores a copy of the respective public key;wherein the respective certificate authority signs an initial certificate comprising the respective public key; andwherein the detection actions further comprise sending the respective fault condition indication to the respective certificate authority, whereby the respective certificate authority does not provide an updated certificate if the respective node is not fault free.

15. The method of claim 14, wherein the request for the neighboring node diagnostic record is encrypted using the initial certificate.

16. The method of claim 11,wherein the detection actions further comprise determining whether file types of files on the respective node have changed; andwherein the respective fault condition indication is further based on results of the determining.

17. The method of claim 11,wherein the detection actions further comprise determining entropy values of a randomly-selected plurality of respective files in the respective subdomain; andwherein the respective fault condition indication is further based on a number of the randomly-selected plurality of respective files that have entropy values that exceed a threshold.

18. The method of claim 11,wherein the detection actions further comprise determining whether hash values of files comprising the detection instructions and the diagnosis instructions have changed; andwherein the respective fault condition indication is further based on results of the determining.

19. The method of claim 11,wherein the detection actions further comprise determining whether fuzzy hash values of files on the respective node have changed; andwherein the respective fault condition indication is further based on results of the determining.

20. The method of claim 11, wherein the respective fault condition indication is further based on: detected changes to file types of files on the respective node, detected changes to entropy values for files on the respective node, detected changes of hash values for files comprising the detection instructions and the diagnosis instructions, and detected changes of fuzzy hash values for files on the respective node.

Images