Defending files against ransomware

Abstract

An electronic computing device for defending files against ransomware. The electronic computing device includes an electronic processor. The electronic processor is configured to receive a selection of a file and convert the file to a protected file having a protected file format including storing data in an alternate data stream in the protected file. The electronic processor is also configured to detect an attempt to access the protected file and block access to the protected file in response to determining that the attempt to access the protected file is unauthorized.

Description

Attorney Docket No. 093386-0045-WO01 DEFENDING FILES AGAINST RANSOMWARE SUMMARY

[0001] Ransomware has become a prevalent form of malware in the past few years due to the potential for great monetary gains. Ransomware typically operates by exploiting an attack vector, such as a fake software application update or a malicious email attachment, to deliver a payload to a user’s computer system. Once this payload is executed, the ransomware limits the user’s access to the computer system by either locking the system or removing access to files through file encryption. The user is then instructed to pay a ransom, usually in some form of cryptocurrency, to regain access to the computer systems or files.

[0002] The embodiments described herein relate to protecting against ransomware attacks that use encryption to block access to the user’s data files. A common approach to thwarting ransomware attacks is to maintain backups to recover encrypted data without paying a ransom. However, maintaining data backups requires dedicating a large amount of storage space to keeping extra copies of continuously growing data, which can be costly for both home or individual users and small businesses that lack sufficient IT resources and skilled staff. Another issue is that data acquired or generated after the most recently executed backup is lost. In some instances, some ransomware may also encrypt backup copies.

[0003] Since recovery approaches alone are not always effective against ransomware, efforts have been devoted to the development of ransomware detection techniques that aim to detect and stop ransomware attack software before it encrypts all files in a computer system. Detection and prevention techniques vary according to how a specific piece of ransomware is identified. These techniques include, for example, identifying ransomware function calls, network detection, input / output (I / O) monitoring, and decoy file monitoring. However, these approaches have several limitations. Specifically, detection and prevention techniques introduce overhead on the system performance, require large additional storage space, generate high numbers of false alarms, have false negatives (i.e., miss the ransomware), and the like. Moreover, detection and prevention techniques are unable to protect against novel forms of ransomware that have adapted to circumvent existing detection algorithms and / or exhibit new behavior. Many existing anti- virus software also provide an allow list to allow a specific set of applications to edit files. However, anti-virus software utilizing an allow list also has several limitations. There areAttorney Docket No. 093386-0045-WO01 estimated to be 35 million application titles and more than 175 million application versions. It is infeasible to maintain a large allowlist for all applications supported by an operating system such as Windows®. Additionally, if an application with backdoor code (ransomware software) has been incorrectly put into the allowlist, it is still possible to harm users’ computer systems.

[0004] To provide a more robust and effective defense against crypto-ransomware, embodiments herein describe a hybrid method referred to herein as FREEDOM (Fast REcovEry and DetectiOn Mechanism), which possesses both recovery and detection abilities. Embodiments described herein defend against existing crypto-ransomware that encrypts individual user files and can work in tandem with defense mechanisms that prevent full hard drive encryption but not individual file encryption to achieve complete protection against crypto-ransomware. Embodiments described herein provide an easy-to-use tool not only for companies but also for individual end-users and small organizations and businesses to protect their data.

[0005] The FREEDOM application serves as a convenient tool for ordinary users, offering a streamlined approach to data protection. Users may install the FREEDOM application that, when executed by an electronic processor, performs the FREEDOM method and subsequently select the files or file folders they wish to safeguard. Afterwards, users may open, edit, and save the protected files just like using normal files without noticing the existence of the FREEDOM application which runs as a background application. One feature of FREEDOM’s underlying technique is that it fights malware like malware. Specifically, the FREEDOM method leverages Alternate Data Streams (ADS), which are often used by malicious applications, to develop a data protection method that misleads ransomware into attacking only file ‘shells’ instead of the actual file content. With the FREEDOM application in place, users maintain ready access to their data without any perceived difference, while having their data in a secure, defensive, and recoverable posture. Without user-initiated action (for example, double-clicking a file), the protected user data will not be modified by any applications. Another advantage provided by the embodiments described herein is that no additional storage space is required for the protected files.

[0006] The FREEDOM method protects against ransomware that encrypts individual files. Unlike many existing recovery mechanisms, the FREEDOM method has negligible performance overhead and requires nearly no additional memory space. The FREEDOM method ensures that protected files can be easily opened, modified, and saved as normal files so that users do notAttorney Docket No. 093386-0045-WO01 experience operational differences when interacting with files protected by the FREEDOM method. The FREEDOM method not only considers current file-encrypting ransomware but also emerging ones. Embodiments described herein provide a kernel-level monitoring driver that can detect potentially malicious changes to the file structure described herein, and thereby prevent ransomware from bypassing the protections provided by the FREEDOM method.

[0007] Traditionally, the core defense methods against file-encrypting ransomware are user training and strong perimeter security to prevent ransomware from infecting the targeted system. However, as those methods are often not effective, defenses rely on various detection and recovery mechanisms to mitigate and recover from ransomware infections. Apart from user training, protection techniques against file-encrypting ransomware can be classified into three main categories: (i) data backups; (ii) code analysis; and (iii) dynamic monitoring.

[0008] Data backup is a commonly adopted strategy to recover user data from ransomware attacks and also from other malware. Existing data backup techniques utilize different strategies to create secure backups on a computer system and prevent the backups from being encrypted by ransomware. While data backups are an effective solution to ransomware attacks, they have heavy costs since a duplicate of user data needs to be maintained. Additionally, if backups are not executed on a regular basis, users will still lose valuable data after the ransomware attack. Unlike any of the existing backup methods, the FREEDOM method neither needs to store duplicates of user data nor requires users to perform any regular backup.

[0009] Another strategy to defend against the ransomware attack is code analysis. Code analysis relies upon static and dynamic analysis in the effort to draw conclusions about some executables based on the specific characteristics of ransomware. Such an approach is similar to anti-virus software that checks the hash of an executable against a known database of malware and determines whether the executable may be malware. These characteristics can also be used to train classifiers or set up entropy measurements. However, the detection accuracy of static analysis approaches is not guaranteed. This is evident when examining anti-virus’ poor detection rate regarding novel malware or malware variants.

[0010] A more advanced defense mechanism is dynamic monitoring. Since ransomware typically needs to access user files and modify them in a small timeframe, they generate large amounts of system noise that is uncommon during normal use. Based on these observations,Attorney Docket No. 093386-0045-WO01 various dynamic analysis algorithms have been proposed to detect potentially malicious behavior indicative of ransomware. Upon detection of abnormal activities, the suspected process is terminated to mitigate the impact on the system. For example, one dynamic monitoring approach operates by monitoring system I / O operations, analyzing the data, and terminating suspicious processes. Another dynamic monitoring approach is to monitor hardware sensor behavior to draw conclusions on what type of task the system is currently performing. As ransomware usually utilizes keys for encryption, some dynamic monitoring approaches leverage network and application programing interface (API) calls to identify ransomware and possibly obtain the keys used for encryption. Yet another dynamic monitoring approach analyzes the block I / O request headers on solid-state drives to detect malicious operations and utilizes the delayed deletion feature of solid-state drives to recover user data. Although dynamic monitoring approaches claim 100% accuracy in detecting behavior patterns of the existing ransomware, future ransomware that does not exhibit similar behavior patterns, such as conducting intermittent encryption on files instead of continuous encryption, may escape detection by dynamic monitoring approaches. In summary, existing ransomware detection mechanisms have the following common limitations. Their detection accuracy may drop for new ransomware which does not demonstrate behavior patterns similar to previous or existing ransomware. Simply relying on the knowledge of common behavior patterns of existing ransomware to conduct classification and detection may lead to false positives or false negatives. Also, for such a classifier to work, it takes time to collect and learn the user’s normal behavior.

[0011] Moreover, for most of the existing detectors to identify malicious processes, malicious behavior must be shown. That means that ransomware can execute unhindered until it passes a threshold that causes it to be identified as a malicious process. Therefore, many files can be encrypted or lost before the detector is able to stop the ransomware. These detection methods cannot terminate processes with suspected behavior too early since terminating these processes incorrectly could lead to system instability and / or create issues for end users. To recover the user files that end up encrypted before the ransomware is detected, one proposed solution is to couple the procedures of detection and recovery. Although such an approach could work, custom- written cryptographic libraries and other factors may lead to some defenses being unable to recover encrypted files. While such hybrid approaches may help protect user data to some extent while ransomware is being detected, these hybrid approaches still may not be able to detect newAttorney Docket No. 093386-0045-WO01 ransomware that does not have known features or patterns that have been learned by the detectors.

[0012] The FREEDOM method does not have any of the limitations mentioned above with regard to previous approaches. By using the protected user file (PUF) and advanced protected user file (APUF) file structures, embodiments described herein immediately detect any abnormal modifications to a user’s protected files. Embodiments described herein do not result in any loss of user-protected data during the detection process. More importantly, embodiments described herein provide protection against both previously known and unknown file-encrypting ransomware.

[0013] One example embodiment provides an electronic computing device for defending files against ransomware. The electronic computing device includes an electronic processor. The electronic processor is configured to receive a selection of a file and convert the file to a protected file having a protected file format including storing data in an alternate data stream in the protected file. The electronic processor is also configured to detect an attempt to access the protected file and block access to the protected file in response to determining that the attempt to access the protected file is unauthorized.

[0014] Another example embodiment provides a method for defending files against ransomware. The method includes receiving a selection of a file and converting the file to a protected file having a protected file format including storing data in an alternate data stream in the protected file. The method also includes detecting an attempt to access the protected file and blocking access to the protected file in response to determining that the attempt to access the protected file is unauthorized. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG.1 illustrates an example electronic computing device for defending files against ransomware in accordance with some embodiments.

[0016] FIG.2 illustrates a pictorial representation of the file structures of a normal user file, protected user file (PUF), and advanced protected user file (APUF) in accordance with some embodiments.Attorney Docket No. 093386-0045-WO01

[0017] FIG.3 is an example illustration of data stored in an APUF file, in accordance with some embodiments.

[0018] FIG.4 is an example pictorial illustration of a method for defending files against ransomware in accordance with some embodiments.

[0019] FIG.5 illustrates an example flowchart of a method for converting a normal file to a protected file in accordance with some embodiments.

[0020] FIG.6 illustrates an example flowchart of a method for allowing access to a protected file via a proxy application in accordance with some embodiments.

[0021] FIG.7 an illustrative example of kernel-level driver I / O redirection in accordance with some embodiments.

[0022] FIG.8 illustrates an example flowchart of a method for allowing access to a protected file for different types of access requests in accordance with some embodiments.

[0023] FIG.9 illustrates an example flowchart of a method for defending against ransomware in accordance with some embodiments. DETAILED DESCRIPTION

[0024] Before any embodiments are explained in detail, it is to be understood that the present disclosure is not limited in its application to the details of the configuration and arrangement of components set forth in the following description or illustrated in the accompanying drawings. The present disclosure is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings.

[0025] In addition, it should be understood that embodiments may include hardware, software, and electronic components or modules that, for purposes of discussion, may be illustrated andAttorney Docket No. 093386-0045-WO01 described as if the majority of the components were implemented solely in hardware. However, one of ordinary skill in the art, and based on a reading of this detailed description, would recognize that, in at least one embodiment, the electronic based aspects of the invention may be implemented in software (e.g., stored on non-transitory computer-readable medium) executable by one or more processing units, such as a microprocessor and / or application specific integrated circuits (“ASICs”). As such, it should be noted that a plurality of hardware and software based devices, as well as a plurality of different structural components may be utilized to implement the invention. For example, “servers” and “computing devices” described in the specification can include one or more processing units, one or more computer-readable medium modules, one or more input / output interfaces, and various connections (e.g., a system bus) connecting the components.

[0026] Embodiments are herein described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products. 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 by computer program instructions. These computer 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 special purpose and unique machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. The methods and processes set forth herein need not, in some aspects, be performed in the exact sequence as shown and likewise various blocks may be performed in parallel rather than in sequence. Accordingly, the elements of methods and processes are referred to herein as “blocks” rather than “steps.”

[0027] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.Attorney Docket No. 093386-0045-WO01

[0028] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus that may be on or off-premises, or may be accessed via the cloud in any of a software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS) architecture so as to cause a series of operational blocks to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide blocks for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. It is contemplated that any part of any example, feature, aspect, or embodiment discussed in this specification can be implemented or combined with any part of any other example, feature, aspect, or embodiment discussed in this specification.

[0029] Unless the context of their usage unambiguously indicates otherwise, the articles “a,” “an,” and “the” should not be interpreted as meaning “one” or “only one.” Rather these articles should be interpreted as meaning “at least one” or “one or more.” Likewise, when the terms “the” or “said” are used to refer to a noun previously introduced by the indefinite article “a” or “an,” “the” and “said” mean “at least one” or “one or more” unless the usage unambiguously indicates otherwise.

[0030] It should also be understood that although certain drawings illustrate hardware and software located within particular devices, these depictions are for illustrative purposes only. In some embodiments, the illustrated components may be combined or divided into separate software, firmware and / or hardware. For example, instead of being located within and performed by a single electronic processor, logic and processing may be distributed among multiple electronic processors. Regardless of how they are combined or divided, hardware and software components may be located on the same computing device or may be distributed among different computing devices connected by one or more networks or other suitable communication links.

[0031] Thus, in the claims, if an apparatus or system is claimed, for example, as including an electronic processor or other element configured in a certain manner, for example, to make multiple determinations, the claim or claim element should be interpreted as meaning one or more electronic processors (or other element) where any one of the one or more electronic processors (or other element) is configured as claimed, for example, to make some or all of theAttorney Docket No. 093386-0045-WO01 multiple determinations. To reiterate, those electronic processors and processing may be distributed.

[0032] FIG.1 illustrates an example electronic computing device 100 for defending files against ransomware in accordance with some embodiments. The electronic computing device 100 may be a cloud server, a laptop computer, a desktop computer, a tablet, a smartphone, or the like. The electronic computing device 100 may include an electronic processor 105 (for example, a microprocessor, application specific integrated circuit, or the like), a memory 110, a communication interface 115, and a user interface 120. The electronic processor 105, the memory 110, communication interface 115, and the user interface 120 may be electrically and communicatively coupled via a communication bus 125. FIG.1 illustrates only one example of the electronic computing device 100. The electronic computing device 100 may include more or fewer components and may perform functions other than those explicitly described herein.

[0033] In some examples, the electronic processor 105 is implemented as a microprocessor with separate memory, such as the memory 110. In other examples, the electronic processor 105 may be implemented as a microcontroller (with memory 110 on the same chip). In other examples, the electronic processor 105 may be implemented using multiple processors. In addition, the electronic processor 105 may be implemented partially or entirely as, for example, a field- programmable gate array (FPGA), an applications specific integrated circuit (ASIC), an x86 processor, and the like and the memory 110 may not be needed or be modified accordingly. In the example illustrated, the memory 110 includes non-transitory, computer-readable memory that stores instructions that are received and executed by the electronic processor 105 to carry out the functionality of the electronic computing device 100 described herein. The memory 110 may include, for example, a program storage area and a data storage area. The program storage area and the data storage area may include combinations of different types of memory, such as read- only memory and random-access memory. The memory 110 may include a file system (for example, the New Technology File System (NTFS)), an operating system (for example, a Windows® operating system), FREEDOM file protection application, existing anti-malware software that protects against ransomware designed to encrypt a hard drive of the electronic computing device 100 (for example, a master boot record (MBR) filter), and the like. In some embodiments, the electronic computing device 100 may include one electronic processor 105,Attorney Docket No. 093386-0045-WO01 and / or a plurality of electronic processors 105 in a cloud computer cluster arrangement, one or more of which may be executing none, all, or a portion of the applications or instructions of the electronic computing device 100 provided below, sequentially or in parallel across the one or more electronic processors 105. The one or more electronic processors 105 comprising the electronic computing device 100 may be geographically co-located or may be separated (for example, by miles), and interconnected via electronic and / or optical interconnects. One or more proxy servers or load balancing servers may control which one or more electronic processors 105 perform any part or all of the applications provided below.

[0034] The electronic processor 105 may be configured to send and receive information from one or more communication networks (for example, a Wi-Fi network, a Bluetooth™ network, and the like) via the communication interface 115. The communication interface 115 may include, for example, a transceiver or a transmitter and receiver. The user interface 120 may include one or more input and / or output devices (for example, a screen, a touch screen, a mouse pad, speakers, and the like).

[0035] Ransomware may exploit known vulnerabilities in legacy systems, be packaged as seemingly legitimate software, or use phishing schemes. Embodiments described herein target two common types of crypto-ransomware: (i) file encrypter which encrypts one or more of a user’s personal files; (ii) full hard-drive encrypter which encrypts the entire hard drive of a user’s computer (for example, the electronic computing device 100).

[0036] As there are many other types of malware, embodiments described herein work in tandem with existing anti-malware software so as to provide full protection for the user’s system. Specifically, the existing anti-malware can resist typical Trojan attacks that attempt to take over the administrator’s rights.

[0037] Embodiments described herein allow the electronic computing device 100 to quickly recover from existing file-encrypting ransomware attacks and inhibit file loss. Specifically, the user’s original files protected by the embodiments described herein can be restored. Second, embodiments described herein have negligible operational overhead and allow users to access protected files as if they were normal (unprotected) files. Third, embodiments described herein require a very low amount of additional storage space.Attorney Docket No. 093386-0045-WO01

[0038] Embodiments described herein obfuscate access to user files by utilizing Alternate Data Streams (ADS). The ADS are the file attributes that are found on the NTFS. Each file in the NTFS contains not only the main or default data stream, which is visible to the users, but also the ADS that are internal to the NTFS system and not visible to the user from normal file searches. Such obscure features make ADS an ideal vector for malware to insert their malicious code. While malware can hide the code in ADS, ADS’s obscure features can also be used to hide user data so that ransomware will not be able to locate and modify user data. However, unlike malware, which only needs to execute its own code in ADS, using ADS to protect against ransomware requires addressing some of the following new challenges. A first challenge is to ensure that the user experience remains consistent when interacting with the protected files. As ADS data is hidden from users and cannot be directly accessed using common or default applications like Acrobat®, it is not practical to require users to utilize special commands to access their files. A second challenge is to prevent attackers from directly encrypting the ADS or make the attack difficult enough so that encrypting the ADS is effort-prohibitive so that, even if attackers know the users’ files are hidden in ADS, the attackers cannot access the users’ files.

[0039] Embodiments described herein hide user data and also ensure that users can still operate these protected hidden files using the corresponding applications. In order to avoid encumbering users with additional steps, all the file protection activities executed by the electronic processor 105 when performing the embodiments described herein may be automatic and may not require extra steps or expertise by users.

[0040] To achieve the above objectives, example protected file structures are shown in FIG.2. An electronic processor (for example, the electronic processor 105), when executing an ADS file converter application, may automatically convert a normal or regular user file (represented by block 200 in FIG. 2) to a protected file structure. Specifically, the protected file structures include a Protected User File (PUF) (represented by block 205 in FIG. 2) and an Advanced Protected User File (APUF) (represented by block 210 in FIG.2). The PUF may consist of the following components: 1) protected data stored in the default data stream, 2) metadata that stores the regular user file’s original information, 3) a password that is used to generate a virtual entrance file, and 4) any other ADSs that are used by other applications. Except for the protected data, all the other components are stored in ADS with the protection of a kernel-level driverAttorney Docket No. 093386-0045-WO01 monitor. With the protection of the FREEDOM method, the protected data can only be modified when the user double-clicks the file (or other similar direct selection) in the file system graphical user interface. In a PUF, the malicious program can only read and cannot encrypt the file content. Converting regular user files to PUF files inhibits encryption of files by ransomware while maintaining very high usability. Common operations such as searching file content, uploading files through file transfer protocol (“FTP”), and previewing file content will not be affected.

[0041] The user can further increase the protection level of the important files by converting the files to APUF files. As presented in FIG.2, different from the PUF file, the APUF file stores protected user data in ADS and leaves the default data stream as dummy data. With the help of a kernel-level driver monitor, the malicious program can only read and write the dummy data, while the user can still edit the protected data in the APUF file by double-clicking the file and editing the file using associated applications (e.g., Microsoft Word®, Adobe Acrobat®, and the like) as usual. When the attacker tries to steal the important data in the APUF file by reading, copying, and uploading the file, the attempts will fail because the attacker can only obtain the dummy data. The protected data will be automatically erased in the new copy. Converting files to APUF files, protects the user data against ransomware encryption and data exfiltration.

[0042] PUF and APUF files are stored by taking advantage of the pre-allocated space within an NTFS entry to store the metadata and password so that the original user file size is unchanged. Specifically, each file entry in the managed file transfer (“MFT”) is created with the same size, usually 1024 bytes, which is used to store file attributes including the default data stream and the ADS. The user data will be directly stored in the default data stream if it is small enough (much less than 1KB). Otherwise, the file entry only records a pointer to the disk (memory) location where the user data is stored and labeled as a non-resident. FIG.3 gives a high-level view of what a APUF file entry would look like when a user file is a resident. Along with the other attributes and file header, this entry only uses 660 bytes leaving 360 bytes unused within the entry. This means only space that would otherwise be unused is being used. The need for additional storage space in this occurrence can be considered negligible. In some examples, the storage size may vary based on the implementation system.Attorney Docket No. 093386-0045-WO01

[0043] Embodiments described herein may be implemented using some of the following software components executed by the electronic processor 105. The software components may be included in the FREEDOM file protection application stored in the memory 110. The software components may include an ADS file converter for file conversion, a proxy application for verifying user operation and creating virtual entrance files, and a kernel-level driver monitor for blocking and redirecting I / O operations on the user data and detecting new types of ransomware. It should be understood that functionality described herein as being performed by one of the software components may, in fact, be performed by the electronic processor 105 when the electronic processor 105 executes the software component.

[0044] As presented in FIG. 4, once the user double-clicks the protected user file (PUF or APUF), the electronic processor 105 may execute a proxy application. The electronic processor 105, executing the proxy application, may check and verify the caller. If the proxy application is called by the file explorer through double-click, metadata and a password stored in the ADS of the protected user file may be read and a virtual entrance file created. Legitimate operations may be performed by a default application (e.g., a word processor, a portable document format reader, or the like) through the correct virtual entrance file to allow a user to read data from and write data to the protected file. All the read and write operations may be automatically redirected by the electronic processor 105, executing the kernel-level driver to monitor to protect data. The untrusted application can only read the protected data from the PUF file. Without knowing the correct path of the virtual entrance file, all the write operations will be blocked by the electronic processor 105, executing the kernel driver, to prevent the protected data from being encrypted by ransomware. To ensure protection against ransomware that encrypts the hard drive rather than individual files, existing anti-malware software (for example, MBRFilter) may be employed. The anti-malware software serves as the driver monitor that prevents malicious writes to the first sector on all drives.

[0045] FIG.5 illustrates an example method 500 performed by the electronic processor 105 to convert a normal file to a protected file, in accordance with some implementations. The functionality described in relation to FIG.5 may be performed when the electronic processor 105 executes an ADS file converter. The ADS file converter may be stored in the memory 110. At block 505, the method 500 includes determining, using the electronic processor 105, a file path.Attorney Docket No. 093386-0045-WO01 The file path is, for example, a file directory, a file name, and a file extension. The electronic processor 105 may determine the file path from, for example, a metadata of the file. At block 510, the method includes writing, using the electronic processor 105, metadata to the file. The metadata may include the protected metadata to convert the normal user file to a protected file (e.g., PUF, APUF, or the like). The electronic processor 105 may write the protected metadata to the ADS of the file, for example, “sample.puf:metadata.” At block 515, the method 500 includes generating, using the electronic processor 105, random password and writing, using the electronic processor 105, the generated random password to the file. The electronic processor 105 may generate the random password and write the random password to the ADS of the file, for example, “sample.puf:password.” The electronic processor 105 may save the generated password to or store the generated password in the ADS data stream.

[0046] At block 520, the method 500 includes determining, using the electronic processor 105, whether the normal file is being converted to a PUF or an APUF. For example, a user may select conversion to a PUF file or an APUF file in a user interface of the FREEDOM application. The electronic processor 105 receives the selection to determine the type of file the selected file is being converted to. When the normal file is being converted to a PUF, the method 500 ends. When the normal file is being converted to an APUF, the method 500 proceeds to block 525. At block 525, the method 500 reads, using the electronic processor 105, the user data stored in the file. The electronic processor 105 may retrieve the user data (e.g., protected or unprotected data) that is not in the ADS. At block 530, the method 500 includes copying, using the electronic processor 105, user data to ADS of the file. The electronic processor 105 may move the protected or unprotected data from the visible layer to the ADS, for example, “sample.apuf:protected data.” At block 535, the method 500 includes writing, using the electronic processor 105, random data to the default data stream. The electronic processor 105 may replace the protected or unprotected data in the visible layer (i.e., the default data stream) with dummy data (write dummy data to the default data stream). The conversion (the method 500) may be conducted automatically, whereby users only need to toggle files or file folders to be protected or initiate performance of the method 500 for a file or group of files.

[0047] To overcome the obstacle that most applications are not designed to work with ADS files, embodiments described herein utilize a workaround approach that creates a virtual entrance fileAttorney Docket No. 093386-0045-WO01 with the same file extension as the original file. The associated application will be able to open the virtual entrance file as usual. The cost of creating a virtual entrance file is equivalent to creating a pointer in memory (for example, the memory 110) which has negligible impact on system performance. The kernel-level driver will then redirect all the I / O operations performed by the associated application to the protected data either in the default data stream (PUF) or in the ADS (APUF). The kernel-level driver will also prevent the virtual entrance file from being accessed and encrypted by ransomware. The details about the kernel-level driver are elaborated below.

[0048] The proxy application, when executed by the electronic processor 105, acts as a proxy agent to capture the user’s double-click event on the protected user file and generate a valid entrance for the associated application to edit the file while preventing other applications from changing the protected data. FIG. 6 is an example method 600 for allowing access to a protected file via a proxy application in response to a user double clicking on a protected file. The functionality described in relation to blocks 605-625 of the method 600 may be performed by the electronic processor 105 when the electronic processor 105 executes the proxy application. The proxy application may be stored in the memory 110.

[0049] At block 605, the method 600 includes determining, using the electronic processor 105, that a user initialization of a protected file. For example, the electronic processor 105 may determine that a user has double clicked on a PUF or APUF file within a graphical user interface. In some implementations, at block 605, the electronic processor 105 checks whether a call to open a protected file is initialized by a user’s double clicking on the protected file by using the system application programming interface (API) “GetConsoleProcessList.” Because attackers are not able to simulate a user’s double-click event without gaining administrator privileges, when an attacker tries to trigger the proxy application to open the protected user files, the electronic processor 105 may block the protected file from opening. When the caller is verified, for example, when the call to open a protected file was issued due to the user double clicking on a file, the method 600 proceeds to block 610. At block 610, the method 600 includes obtaining, using the electronic processor 105, protected metadata of the file. The electronic processor 105 retrieves and reads the protected metadata from the ADS of the file. At block 615, the method 600 includes obtaining, using the electronic processor 105, an entrance password of the file. TheAttorney Docket No. 093386-0045-WO01 electronic processor 105 retrieves and reads the entrance password from the ADS in the protected user file. In some examples, the protected metadata and the entrance password are under the protection of the kernel-level driver monitor and may only be accessed by the proxy application.

[0050] At block 620, the method 600 includes creating, using the electronic processor 105, a virtual entrance file. For example, after obtaining the ADS layer information (e.g., the protected metadata and the entrance password), the electronic processor 105 creates a virtual entrance file either linked to the default data stream (PUF) or the protected data in the ADS (APUF). It is worth noting that the virtual entrance file is not physically stored on a disk (i.e., a permanent storage device) included in, for example, the electronic computing device 100. Rather, the virtual entrance file may be a virtual link that only exists in memory (for example, temporary storage or the RAM included in the electronic computing device 100) and points to the protected data. In some embodiments, the virtual entrance file may only be recognized by the kernel-level driver. In some embodiments, an attacker will not be able to locate the virtual entrance files by scanning all the folders because 1) the entrance file is virtual, meaning the entrance file does not actually exist in any of the folders and 2) only the proxy application, when executed by the electronic processor 105, can generate the virtual entrance file with the file path encrypted from the original normal file path read from protected metadata by the protected entrance password. The file extension of the virtual entrance file may be the same as the file extension of the original file. For example, given the original file “dissertation.docx,” the converted file will be “dissertation.puf” or “dissertation.apuf”, and the path of the virtual entrance file will be in the form of “{FileDir} / Hash(Encrypt({FilePath},EntrancePassword)) / {FileName}.{FileExt}.”

[0051] At block 625, the method 600 includes invoking, using the electronic processor 105, a default application to access the file. For example, the electronic processor 105 may use a “ShellExecute” command to invoke the default application to open the virtual entrance file (for example, a virtual entrance file named the following: “C: / / 1cfa352786ea0810bed334f92b76c3fb / dissertation.docx”). The default application may be an application associated with the file extension of the virtual entrance file (for example, a word processor). When the electronic processor 105 attempts to access the virtual entrance file executing the default application, instead of throwing a file not found exception, the electronicAttorney Docket No. 093386-0045-WO01 processor 105 executes the kernel-level driver monitor to access the virtual entrance file. The default application does not need to call the kernel-level driver monitor directly. The default application, when executed by the electronic processor 105, may access the virtual entrance file the same way as it would access a normal file. The kernel-level driver monitor will automatically redirect, to the ADS that stores the actual content of the protected file, read / write operations performed by the electronic processor 105, when executing the default application, and directed towards virtual entrance file. In some embodiments, the functionality described in relation to blocks 630-640 of the method 600 is performed by the electronic processor 105 when the electronic processor 105 executes the kernel-level driver monitor. The kernel level driver monitor may be stored in the memory 110.

[0052] At block 630, the method 600 includes determining, using the electronic processor, whether the protected file is a PUF or an APUF. When the electronic processor 105 determines that the protected file is a PUF, the method 600 proceeds to block 635. At block 635, the method 600 includes redirecting, using the electronic processor 105, read and / or write operations initiated by the default application on the protected file to protected data in the default stream. When the electronic processor 105 determines that the protected file is an APUF, the method 600 proceeds to block 640. At block 640, the method 600 includes redirecting, using the electronic processor 105, read and / or write operations initiated by the default application on the protected file to protected data in the ADS.

[0053] In some embodiments, at blocks 635 and 640, the electronic processor 105 obtains the file path of the protected file by removing the hash value from the file path of the virtual entrance file. The electronic processor 105, at blocks 635 and 640, may also read metadata and an entrance password from the ADS in the protected file and verify if the hash value is correct. More specifically, in some embodiments, the electronic processor 105 may verify the hash value is correct by removing the hash value from the file path of the virtual entrance file. After removing the hash value from the file path of the virtual entrance file, the file path will be the file path of the protected file. The electronic processor 105 may read the password from the metadata of the protected file, encrypt the file path of the protected file, and calculate the hash value of the encrypted file path of the protected file. The electronic processor 105 may verify that the hashAttorney Docket No. 093386-0045-WO01 value is correct when the calculated hash value is consistent with the hash value in file path of the virtual entrance file.

[0054] When the electronic processor 105 verifies the hash value is correct, the electronic processor 105 redirects the read and write operations the default application is attempting to perform on the protected file. The electronic processor 105 may redirect using the kernel level driver monitor. For example, the electronic processor 105 may redirect read and write operations on “dissertation.docx” to the protected data in “dissertation.puf” or “dissertation.apuf,” depending on whether the protected file is a PUF or an APUF. A compatibility issue between the default application and the file protected using the FREEDOM method described above may not arise because, from the perspective of the default application, the default application is editing a normal file as usual.

[0055] At block 645, the method 600 includes deleting, using the electronic processor 105, the virtual entrance file. When the user finishes editing and saving a protected file (e.g., when the electronic processor 105 receives a command or instruction to close the protected file), the electronic processor 105 may generate and store a new entrance password in the ADS to revoke or delete the corresponding virtual entrance file. Reading metadata and an entrance password and creating virtual entrance files may be performed by the proxy application seamlessly and automatically when a user double clicks a file. The default application will open the virtual entrance file which has the same name as the original file (for example, “dissertation.docx”). From a user’s point of view, editing a protected file does not appear different from editing a normal file.

[0056] In some embodiments, the kernel-level driver is a mini-filter driver developed using commands from Windows Driver Kit (WDK) that can intercept the I / O requests generated by both system and user applications as shown in FIG.8. The kernel-level driver consists of two main components: (i) the I / O redirection component, and (ii) the I / O monitor component.

[0057] The electronic processor 105, when executing the I / O redirection component, may redirect the read and write operations performed by the default application on the virtual entrance file to the protected user data. As presented in FIG.7, the electronic processor 105, when executing the kernel-level driver, may change the file path to the ADS file “ADSPath” in the pre- operation callback and set the “IoStatus” to “STATUS REPARSE.” Therefore, I / O operationsAttorney Docket No. 093386-0045-WO01 performed by the default application will be redirected to the protected data to allow users to load (read) and modify (write) the protected data as usual. I / O operations performed by the attacker will not be redirected to protect the user data from encryption.

[0058] In some embodiments, the electronic processor 105, when executing the I / O monitor component, monitors the I / O operations to detect and prevent malicious modifications to the PUF and APUF files. The file protection approach described above is very effective against various versions of existing file-encrypting ransomware. However, there exists the possibility that future (not yet developed) ransomware may know of file protection approach described above and attempt to target the protected user data, the metadata, the entrance password, the proxy application, or even attempt to encrypt the full hard drive. Described below are scenarios of possible bypasses or work arounds that future ransomware may attempt against the file protection system described above and solutions for addressing these work arounds.

[0059] First Scenario: Attacking the metadata in ADS: A ransomware may attempt to modify the metadata so that the user cannot edit the file as usual.

[0060] Second Scenario: Attacking the entrance password in ADS: A ransomware may access the entrance password in the ADS so as to create its own virtual entrance file to access the protected user data.

[0061] Third Scenario: Attacking the proxy application: A ransomware may infect or replace the proxy application to obtain access to the protected user data.

[0062] Fourth Scenario: Attacking the protected data: A ransomware may search all the data streams in the protected user file and encrypt the user data.

[0063] Fifth Scenario: Attacking the master file table (MFT): A ransomware may attempt to encrypt the MFT instead of user files to achieve full hard-drive encryption.

[0064] To address the first and second attack scenarios, the electronic processor 105, executing the driver monitor, may monitor the I / O operations on the metadata and entrance password. The metadata and entrance password should only be accessed by the proxy application and kernel- level driver. Any other processes that attempt to read from (for example, steal data in ADS to generate a virtual entrance link to access user-protected data) or write to (for example, modify orAttorney Docket No. 093386-0045-WO01 inject codes to disable the kernel-level driver) these fields will be detected as malicious and be terminated by the electronic processor 105, executing the driver monitor.

[0065] To address the third attack scenario, the electronic processor 105, executing the driver monitor, may block all the write operations to the proxy application and also deem the related program as malicious. The message-digest algorithm 5 (MD5) value of the proxy application may also be checked to ensure it is legitimate.

[0066] To address the fourth scenario, the electronic processor 105, executing the driver monitor and the proxy application, may ensure that only when the user double-clicks the protected file can the default application be invoked to edit the file. When the protected data is stored in the default data stream (in other words, when the protected file is a PUF), operations that change the protected user data, including write, override, replace, and delete operations, may be blocked by the electronic processor 105 when the attempt to access the protected file is not initialized by a user double clicking on the protected file. When the protected user data is stored in the ADS (in other words, when the protected file is an APUF), operations that change the protected user data and the read operation may be blocked to ensure that the protected user data is not be stolen by the ransomware.

[0067] To address the fifth scenario, the electronic processor 105 may utilize MBRFilter (existing anti-malware software) to detect and terminate malicious operations that intend to modify the MBR and encrypt the MFT.

[0068] The driver monitor described herein is substantially more accurate and effective than other driver-based monitoring techniques. Although existing driver-based monitoring approaches also look at file changes and monitor operations, they can only make educated guesses when determining if a process is malicious through analysis of a system’s historical behavior and do not always detect malicious processes. Moreover, for the drivers of existing driver-based monitoring approaches to identify malicious processes, malicious behavior must be shown. This allows ransomware to execute unhindered until it passes a threshold that causes existing drivers to identify the ransomware as a malicious process. Allowing ransomware to execute unhindered for even a brief amount of time may cause a number of files to be encrypted or lost before the existing drivers stop the ransomware. The solution provided by the embodiments described herein avoids these problems. In the embodiments described herein, the protected user data willAttorney Docket No. 093386-0045-WO01 be either read-only to the malicious applications (PUF) or hidden in the ADS files (APUF). The design consistency of the embodiments described herein ensures that illegal operations are detected by the driver monitor described herein and that zero files are lost.

[0069] In some embodiments, the software to perform the functionality described herein may be conveniently installed on an electronic computing device using a provided installer. When executed by an electronic processor (for example, the electronic processor 105), the installer takes less than a minute to complete the installation process. Once the software is installed, the electronic processor 105 may receive a user’s selection of one or more files or entire file folders to protect through an intuitive graphical user interface (GUI). Once the electronic processor 105 receives a user’s selection of one or more files or entire file folders, the user does not need to interact with the software that provides the functionality described herein, and the user can open, edit, and save the protected files as they would regular files. In addition, the electronic processor 105 may receive, from a user, a selection of one or more protected files or folders to revert back to regular files. In some embodiments, the systems and methods described herein use the ADS files in a way that does not trigger antivirus software.

[0070] FIG.8 is an example method 800 for allowing access to a protected file performed by the electronic processor 105. At block 805, the method includes determining, using the electronic processor 105, whether a proxy application is being executed. The electronic processor 105 may determine whether a proxy application (e.g., legitimate or ransomware) is being executed and attempting to open a protected file. In response to determining a proxy application is calling the protected file, the method 800 obtains protected metadata and entrance password (at block 810), generates a virtual entrance file (at block 815), and calls default application to open the virtual entrance file (at block 820) similar to that described in relation to blocks 615-625. In response to determining a proxy application is not calling the protected file, the method proceeds to block 825.

[0071] At block 825, the method 800 includes determining, using the electronic processor 105, whether a default application is calling or attempting to access the protected file. In response to determining that a default application is attempting to access a protected file, the method 800 proceeds to block 830. At block 830, the method 800 includes obtaining, using the electronic processor 105, the protected metadata and entrance password for the file. The electronicAttorney Docket No. 093386-0045-WO01 processor 105 reads the metadata and the entrance password from the ADS. At block 835, the method 800 includes determining, using the electronic processor 105, whether the entrance file name is valid. The electronic processor 105 may determine whether the file path from the default application and the virtual file path to determine whether the entrance file name is valid. In response to determining that the entrance file name is valid, the method 800 determines whether the file is a PUF or a APUF (at block 840), redirects read / write operations to the protected data in the default data stream (at block 845) when the file is a PUF, and redirects read / write operations to the protected data in the ADS (at block 850) when the file is a APUF similar to that described above in relation to blocks 630-640.

[0072] In response to determining, at block 830, the file path of the virtual entrance file is invalid, the method 800 proceeds to block 855. At block 855, the method 800 includes blocking, using the electronic processor 105, read / write operations on the protected file.

[0073] In response to determining, at block 825, a default application is not attempting to access the protected file, the method 800 proceeds to block 860. At block 860, the method 800 includes determining, using the electronic processor 105, whether a protected file is being access directly. For example, the electronic processor 105 may determine whether the protected file is being access by a different application or by the kernel. In response to determining the file is protected, the method proceeds to block 865. At block 865, the method 800 includes determining, using the electronic processor 105, whether the file is a PUF or an APUF. In response to determining the protected file is an APUF, the method 800 includes blocking, using the electronic processor 105, at block 855, read / write operations on the protected file (at block 855). In response to determining the protected file is a PUF, the method 800 includes allowing, using the electronic processor 105, read-only operations on the protected file (at block 870). In response to determining the file is not protected, the method 800 includes allowing, using the electronic processor 105, read / write operations on the file (at block 875).

[0074] FIG.9 is a flowchart of an example method 900 for defending files against ransomware. In the example illustrated, the method 900 includes receiving, via the user interface 120, a selection of a file (at block 910). As noted above, the user may select one or more files for protection. The user may perform a selection action, a drag and drop action, or the like to select the files for protection.Attorney Docket No. 093386-0045-WO01

[0075] The method 900 includes converting, using the electronic processor 105, the file to a protected file having a protected file format including storing data in the ADS of the protected file (at block 920). The electronic processor 105 may execute the ADS file converter as shown in FIG.5 to convert the file to a PUF file or an APUF file. In the APUF file, the protected user data is stored in the ADS. Dummy data may be stored in the visible layer of the APUF file.

[0076] The method 900 includes detecting, using the electronic processor 105, an attempt to access the protected file (at block 930). The attempt may be a legitimate attempt, for example, a user double clicking a file or may be an unauthorized attempt, for example, an access through a ransomware application. What types of attempts are authorized (or legitimate) and unauthorized may be preset. For example, only a double click attempt to access the file may be deemed authorized and every other type of attempt may be deemed unauthorized.

[0077] The method 900 includes blocking, using the electronic processor 105, access to the protected file in response to determining that the attempt to access the protected file is unauthorized (at block 940). As discussed above with respect to FIG. 8, the proxy application may block access to read and / or write operations of the protected file when the attempt is unauthorized.

[0078] The embodiments described herein mitigate the effects of existing file encrypter ransomware and future file encrypter ransomware. In embodiments described herein, the user data will be stored as a protected file and may be accessed only by the default application through the virtual entrance file. While under attack from existing file-encrypting ransomware, embodiments described herein will attempt to detect and terminate the attacks via the kernel- level driver monitor as early as possible. The embodiments described herein may inhibit file loss from existing file-encrypting ransomware.

[0079] As previously discussed, a challenging problem will be to successfully defend against ransomware developed in the future to target the new file structure described herein. Potential future ransomware attacks and how they may be addressed by the embodiments described herein are discussed below.

[0080] Attempt to encrypt the protected user file: Such an attack will not be successful since any process other than the proxy application that attempts to modify the protected files will beAttorney Docket No. 093386-0045-WO01 blocked. Any program that tries to modify the protected data in ADS will be suspended by the kernel-level driver monitor.

[0081] Attempt to modify or replace the proxy application: any attempt to modify or replace the proxy application will be blocked by the driver monitor since the proxy application is not expected to be modified after creation. When the attacker tries to infect the proxy application, the electronic processor 105 detects the malicious behavior and the terminates the program. If an attacker tries to build another proxy application, it will fail the validation performed by the electronic processor 105 because the hash value of the attacker’s proxy application will not match the hash value kept by the kernel-level driver monitor.

[0082] Attempt to read, modify, or replace the metadata and entrance password: the attempt to access the metadata and entrance password will fail because any program (e.g. the malicious programs that try to modify the data in ADS or inject codes into ADS) except the proxy application will be detected and stopped by the electronic processor 105, executing the kernel- level driver monitor in real time.

[0083] Attempt to change the file associations: By using the kernel-level driver monitor and proxy application as described herein, protected files securely hold the original file association from when they were created. Changing the file association will not change the application that a virtual entrance file opens with.

[0084] Attempt to encrypt the virtual entrance files during file editing: the electronic processor 105, executing the kernel-level driver, stops such an attempt since the virtual entrance file is only accessed by the default application when a user double-clicks the protected file. The electronic processor 105, executing the kernel-level driver, does not redirect the attacker’s writing operation to the protected data. When an attacker tries to call a default application using commands to modify the protected file, the electronic processor 105, executing the proxy application will block such an operation because access of the protected file is not initialized by a user double-clicking the protected file.

[0085] Attempt to create a new virtual entrance file to encrypt the protected data: an attacker may attempt to create its own virtual entrance file referring to the protected file and encrypt the data. However, such an attack will not be successful because the attacker cannot access theAttorney Docket No. 093386-0045-WO01 protected metadata and entrance password that are stored in the ADS. Such access will be blocked by the electronic processor 105 executing the kernel-level driver. Without the correct metadata and password, the electronic processor 105, executing the kernel-level driver, blocks the virtual entrance file and does not redirect write operations to the protected data.

[0086] Attempt to map files into memory: The attacker may attempt to map files into memory and then perform a memory I / O operation to encrypt the data instead of direct disk I / O and let the operating system write the updated data back to the disk to hide the malicious behaviors. However, such an attack will not be successful on the PUF because the electronic processor 105 blocks the write-back operation. The protected data is read-only and can only be edited by a default application when a user double-click is received. For the APUF file, only the dummy data will be mapped into the memory. The real user data in the ADS is still safe.

[0087] Attempt to simulate double-click events: The attacker’s efforts to mimic user’s double- click actions in an attempt to access files protected by the embodiments described herein are bound to fall short. This is because accessing these protected files requires administrative privileges, which are safeguarded by existing anti-malware software. The attacker will have to bypass both the anti-malware software and the system described herein to gain the access to the protected files.

[0088] Attempt to conduct full drive encryption: The attacker may attempt to infect the master boot record (MBR) to encrypt the master file table (MFT). Once MFT is encrypted, users will lose access to all the files. Such kind of attack is prevented by the MBRFilter (existing anti- malware software) which will detect and terminate malicious operations that intend to modify the MBR.

[0089] Attempt to uninstall the kernel-level driver: The attacker needs to gain administrator privileges to uninstall kernel-level drivers. Such attacks may be stopped by the electronic processor 105 utilizing existing anti-malware software.

[0090] The embodiments described herein provide systems and methods for implementing the FREEDOM method for defending user files against ransomware. Unlike many existing recovery mechanisms, the FREEDOM method neither requires extra storage space to backup user data nor introduces performance overhead. The FREEDOM method leverages the stealth ability ofAttorney Docket No. 093386-0045-WO01 Alternate Data Stream (ADS) to form a new structure of user data that will not be infected by existing ransomware. The FREEDOM method ensures that protected files can be easily opened, modified, and saved as normal files so that users do not experience operational differences after the adoption of the defense mechanism (utilizing the FREEDOM method). Along with a novel kernel-level driver monitor, the embodiments described herein have the potential to defeat future crypto-ransomware that is aware of the underlying defense mechanisms involved in implementing the FREEDOM method. The embodiments described herein allow for successful safeguarding of user data against various existing ransomware while maintaining very high efficiency.

Claims

Attorney Docket No. 093386-0045-WO01 CLAIMS What is claimed is:

1. An electronic computing device for defending files against ransomware, the electronic computing device comprising: an electronic processor configured to: receive a selection of a file; convert the file to a protected file having a protected file format including storing data in an alternate data stream in the protected file; detect an attempt to access the protected file; and block access to the protected file in response to determining that the attempt to access the protected file is unauthorized.

2. The electronic computing device according to claim 1, wherein the protected file is an advanced protected user file (APUF) and wherein to convert the file to the protected file, the electronic processor is configured to: generate a password; store the password in the alternate data stream of the protected file; store metadata of the file in the alternate data stream of the protected file; store user data of the file in the alternate data stream of the protected file; and write dummy data to a default data stream of the protected file.

3. The electronic computing device according to claim 1, wherein the protected file is a protected user file (PUF) and wherein to convert the file to the protected file, the electronic processor is configured to: generate a password; store the password in the alternate data stream of the protected file; and store metadata of the file in the alternate data stream of the protected file.Attorney Docket No. 093386-0045-WO01 4. The electronic computing device according to claim 1, wherein the protected file is an advanced protected user file (APUF) and the electronic processor is configured to block access to the protected file by: blocking read / write operations on the protected file.

5. The electronic computing device according to claim 1, wherein the protected file is a protected user file (PUF) and the electronic processor is configured to block access to the protected file by: blocking write operations on the protected file; and allowing read operations on the protected file.

6. The electronic computing device according to claim 1, wherein the electronic processor is further configured to: allow access to the protected file in response to determining that the attempt to access the protected file is authorized, the attempt is authorized when the attempt is in response to a user selecting the protected file using a double-click action.

7. The electronic computing device according to claim 6, wherein the protected file is a protected user file (PUF) and wherein to allow access to the protected file the electronic processor is configured to: obtain protected metadata stored in the alternate data stream of the protected file; obtain a password stored in the alternate data stream of the protected file; create a virtual entrance file linked to a default data stream of the protected file, wherein a file path of the virtual entrance file is created based on the protected metadata and the password; open the virtual entrance file using a default application, wherein the default application is an application associated with a file extension of the virtual entrance file; and in response to verifying the file path of the virtual entrance file using the protected metadata and the password, redirect read / write operations from the default application to the default data stream.Attorney Docket No. 093386-0045-WO01 8. The electronic computing device according to claim 6, wherein the protected file is an advanced protected user file (APUF) and to allow access to the protected file the electronic processor is configured to: obtain protected metadata stored in the alternate data stream of the protected file; obtain a password stored in the alternate data stream of the protected file; create a virtual entrance file linked to the alternate data stream in the protected file, wherein a file path of the virtual entrance file is created based on the protected metadata and the password; open the virtual entrance file using a default application, wherein the default application is an application associated with a file extension of the virtual entrance file; and in response to verifying the file path of the virtual entrance file using the protected metadata and the password, redirect read / write operations from the default application to the alternate data stream.

9. The electronic computing device according to claim 8, wherein the electronic processor is further configured to: receive a command to close the protected file; and in response to receiving the command to close the protected file, generate and store a new password in the alternate data stream to revoke the virtual entrance file.

10. The electronic computing device according to claim 1, wherein the alternate data stream is internal to a new technology file system (NTFS) and is not visible in normal file searches.

11. A method for defending files against ransomware, the method comprising: receiving a selection of a file; converting the file to a protected file having a protected file format including storing data in an alternate data stream in the protected file; detecting an attempt to access the protected file; and blocking access to the protected file in response to determining that the attempt to access the protected file is unauthorized.Attorney Docket No. 093386-0045-WO01 12. The method according to claim 11, wherein the protected file is an advanced protected user file (APUF) and converting the file to a protected file includes: generating a password; storing the password in the alternate data stream of the protected file; storing metadata of the file in the alternate data stream of the protected file; storing user data of the file in the alternate data stream of the protected file; and writing dummy data to a default data stream of the protected file.

13. The method according to claim 11, wherein the protected file is a protected user file (PUF) and converting the file to a protected file includes: generating a password; storing the password in an alternate data stream of the protected file; and storing metadata of the file in the alternate data stream of the protected file.

14. The method according to claim 11, wherein the protected file is an advanced protected user file (APUF) and blocking access to the protected file includes: blocking read / write operations on the protected file.

15. The method according to claim 11, wherein the protected file is a protected user file (PUF) and blocking access to the protected file includes: blocking write operations on the protected file; and allowing read operations on the protected file.

16. The method according to claim 11, the method further comprising: allowing access to the protected file in response to determining that the attempt to access the protected file is authorized, the attempt is authorized when the attempt is in response to a user selecting the protected file using double click.

17. The method according to claim 16, wherein the protected file is a protected user file (PUF) and allowing access to the protected file includes: obtaining protected metadata stored in the alternate data stream of the protected file;Attorney Docket No. 093386-0045-WO01 obtaining a password stored in the alternate data stream of the protected file; creating a virtual entrance file linked to a default data stream of the protected file, wherein a file path of the virtual entrance file is created based on the protected metadata and the password; opening the virtual entrance file using a default application, wherein the default application is an application associated with a file extension of the virtual entrance file; and in response to verifying the file path of the virtual entrance file using the protected metadata and the password, redirecting read / write operations from the default application to the default data stream.

18. The method according to claim 16, wherein the protected file is an advanced protected user file (APUF) and allowing access to the protected file includes: obtaining protected metadata stored in the alternate data stream of the protected file; obtaining a password stored in the alternate data stream of the protected file; creating a virtual entrance file linked to the alternate data stream of the protected file, wherein a file path of the virtual entrance file is created based on the protected metadata and the password; opening the virtual entrance file using a default application, wherein the default application is an application associated with a file extension of the virtual entrance file; and in response to verifying the file path of the virtual entrance file using the protected metadata and the password, redirecting read / write operations from the default application to the alternate data stream.

19. The method according to claim 18, the method further comprising: receiving a command to close the protected file; and in response to receiving the command to close the protected file, generating and storing a new password in the alternate data stream to revoke the virtual entrance file.

20. The method according to claim 11, wherein the alternate data stream is internal to a new technology file system (NTFS) and is not visible in normal file searches.

Images