DETERMINATION OF DATA ANOMALIES BASED ON OBJECT TYPE INFORMATION FOR BLOCK INLET AND OUTLET OPERATIONS

Abstract

In some examples, a system identifies an initial block input / output (I / O) operation that involves writing metadata to a data object, where the metadata of the initial block I / O operation includes initial object type information. Based on a header from a second block I / O operation that involves writing object contents to a target data object, the system generates secondary object type information relating to an object type of the target data object. The system compares the initial object type information in the metadata of the initial block I / O operation with the secondary object type information. Based on this comparison, the system determines whether a data anomaly has occurred.

Description

background

[0001] In a ransomware attack, data on a computer or on multiple computers connected via a network is encrypted. During a ransomware attack, the data is encrypted with a key, preventing users from accessing it unless a ransom is paid to obtain the key. A ransomware attack can be very disruptive for businesses, government agencies, educational institutions, individuals, and more. Brief description of the drawings

[0002] Some embodiments of the present disclosure are described with reference to the following figures. Fig. is a block diagram of an arrangement with a computer system that has a replication controller to replicate write input / output (I / O) operations to a recovery storage system, in accordance with some examples. Fig. This is a flowchart of a process for detecting an attack, in accordance with some examples. Fig. is a block diagram of a storage medium that stores machine-readable instructions according to some examples. Fig. This is a block diagram of a system, based on some examples. Fig. This is a flowchart of a process, based on some examples.

[0003] In the drawings, identical reference numbers denote similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated for better illustration of the example shown. Furthermore, the drawings contain examples and / or embodiments that correspond to the description; however, the description is not limited to the examples and / or embodiments shown in the drawings. Detailed description

[0004] A ransomware attack can be difficult to detect. By the time a user (e.g., an individual, an organization such as a company, government, educational institution, or other type of entity) becomes aware of the attack, most or all of their data may already be encrypted and therefore inaccessible. The inability to detect a ransomware attack in real time can impair a user's ability to recover from the attack.

[0005] In some cases, ransomware can encrypt an entire data object, where a "data object" can refer to any one or a combination of the following: a file on a file system, an image, a video, executable program code, or any other data container. In other cases, ransomware can perform intermittent encryption of a data object, in which the ransomware partially encrypts selected parts of the data object while leaving other parts unencrypted. Although ransomware protection systems may be able to detect ransomware that encrypts entire data objects, such systems may not be effective against ransomware that uses intermittent encryption. An intermittent encryption attack refers to an encryption attack in which less than the entirety of a data object is encrypted.As a result, a ransomware attack may go undetected, and all partially encrypted (intermittently encrypted) data objects are lost, as a user may not be able to recover original data from the partially encrypted data objects.

[0006] In accordance with some implementations of this disclosure, a encryption attack detector is able to determine whether an encryption attack is occurring based on monitoring block input / output (I / O) operations (including object block I / O operations and metadata block I / O operations) that access individual data blocks in a storage system, and to determine whether object type information in the metadata block I / O operations matches object type information in the object block I / O operations that target data objects. The detected encryption attack may be an intermittent encryption attack, which partially encrypts a portion of a data object, or a full encryption attack, which completely encrypts an entire data object. A "block I / O operation" is an I / O operation performed with respect to a data block in the storage system.A "data block" is stored in a memory block of the storage system, with each memory block having a specific size. The contents of a data object can be stored in multiple data blocks within the storage system. By detecting an encryption attack based on monitoring block I / O operations, intermittent encryption attacks can be detected, since the encryption attack detector does not rely on analyzing an entire data object to determine whether encryption has occurred.

[0007] In some examples in this disclosure, the encryption attack detector identifies in a stream of block I / O operations: (1) metadata block I / O operations, which involve writing metadata for data objects, and (2) object block I / O operations, which involve writing object contents to target data objects. Based on a header from an object block I / O operation, the encryption attack detector generates object type information representing the object type of a target data object. The encryption attack detector compares object type information in the metadata of a metadata block I / O operation with the generated object type information. Based on this comparison, the encryption attack detector determines whether unauthorized encryption of data has occurred.

[0008] In other examples, other anomalies relating to data can be detected using techniques or mechanisms as described in some examples in this disclosure. For instance, an anomaly relating to data may result from an error made by an entity (such as a person, a program, or a machine). The entity may, for example, have named a file with an incorrect extension.

[0009] The following sections refer to examples where data objects are files in a file system. Techniques or mechanisms as described in further examples can also be applied to other types of data objects, such as images, video objects, executable program code objects, or other data containers. Encryption attacks are also discussed. Techniques or mechanisms as described in some examples can be applied to detect other anomalies in data.

[0010] Fig. This is a block diagram of a sample arrangement comprising a Computer System 102 and a Recovery Storage System 104. The Computer System 102 can include one or more computers.

[0011] Computer system 102 contains a replication controller 106 that replicates write I / O operations to the recovery storage system 104. In some examples, the I / O writes are replicated to a journal stored in the recovery storage system 104. The journal contains entries to which the I / O writes are replicated by the replication controller 106. A "journal" can refer to a data structure that records I / O writes that modify data elements, such as data blocks. An I / O write operation to a data block is called a "block I / O write operation."

[0012] A write-block I / O operation can update data, add new data, or delete existing data in a data block. Replicating a write-block I / O operation to a journal entry can refer to adding information that represents the write-block I / O operation to the journal entry. In response to an event, journal entries can be applied to a backup data store (not shown) that stores copies of a primary data store 108 of computer system 102. An event that triggers the application of journal entries to the backup data store can be a time-based event (which, for example, can cause the application of journal entries on a periodic basis) or any other type of event.

[0013] As used here, a “control unit” can refer to one or more hardware processing circuits, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry. Alternatively, a “controller” can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) that can be executed on the one or more hardware processing circuits.

[0014] The primary data store 108 is a data store for storing data used in operations performed by a requester 110, for example, when the requester 110 executes workloads of application programs, an operating system (OS), or other programs. A "data store" can be implemented in a storage system.

[0015] Requestor 110 can make access requests 112 (read requests and write requests) to read data from or write data to primary datastore 108. An example of requestor 110 is a virtual processing unit, such as a virtual machine (VM) or a container. In other examples, requestor 110 can be a program or a hardware component. Although in Fig. While only one requester is shown, in other examples there may be multiple requesters that can access data from the primary data store 108.

[0016] The access requests 112 are received by a driver 114, which generates block I / O operations 116 based on the access requests 112. The block I / O operations 116 include read block I / O operations for reading data blocks from the primary data storage 108 and write block I / O operations 118 for writing data blocks to the primary data storage 108.

[0017] Driver 114 is a unit that manages access to primary datastore 108. In some examples, driver 114 might be part of a hypervisor that creates and manages virtual machines. In other examples, driver 114 might be part of the operating system of computer system 102.

[0018] The replication controller 106 detects the block I / O writes 118 provided by the driver 114. The replication controller 106 replicates the block I / O writes 118 to the recovery storage system 104.

[0019] According to some examples in this disclosure, the replication controller 106 includes an attack detector 120 capable of detecting when an attack involving data encryption is taking place. The attack detector 120 can be implemented using hardware processing circuitry of the replication controller 106 or by machine-readable instructions executed by the replication controller 106. In other examples, the attack detector 120 can be separate from the replication controller 106.

[0020] The attack detector 120 is capable of detecting partial file encryption, such as that occurring in an intermittent ransomware attack, or full file encryption. The attack detector 120 can perform real-time encryption attack detection while write-block I / O operations 118 are being processed by the replication controller 106 for replication to the recovery storage system 104. Real-time encryption attack detection refers to performing encryption attack detection while I / O operations are being transferred to a destination (in this case, the transfer of write-block I / O operations 118 to the recovery storage system 104 as part of the write-block I / O replication process).Real-time detection of an encryption attack differs from offline detection of an encryption attack, where previously stored data is analyzed to determine if the stored data has been encrypted.

[0021] The attack detector 120 comprises a write I / O analyzer 122 and a file type comparator 126. The write I / O analyzer 122 and the file type comparator 126 can be implemented using hardware processing circuits of the attack detector 120 or with machine-readable instructions executed by the replication controller 106.

[0022] Write-block I / O operations include metadata write-block I / O operations, which write metadata associated with files; file write-block I / O operations, which write the contents of data blocks from target files; and write-block I / O operations that are not recognized as either metadata or file write-block I / O operations. Write-I / O Analyzer 122 analyzes write-block I / O operations to identify the type of each operation.

[0023] In some examples, the metadata associated with a file includes a file set, such as a file set of Microsoft's New Technology File System (NTFS). In other examples, other types of file systems may be used to manage access to files, such as a Fourth Extended (EXT4) file system associated with a Linux operating system, an Apple file system, or another type of file system.

[0024] In general, a file system contains metadata that represents a file. The metadata includes attributes about the file, which can contain any or a combination of the following information: a file name, a timestamp indicating the time the file was created or modified, and storage location information that identifies a storage location (e.g., in primary data store 108) where the file's data resides. In some examples, the storage location information includes a data offset. A data offset can identify the location of data relative to a reference location in a storage system (e.g., the data offset can be added to the reference location to determine the actual location of the data in the storage system).

[0025] As in Fig.As shown, the primary data store 108 contains files 130 that are part of a file system. The primary data store 108 also contains metadata in a metadata repository 132. In examples using NTFS, the metadata repository 132 takes the form of a Master File Table (MFT). In other examples using a different type of file system, the metadata repository 132 can be implemented using other data structures.

[0026] In some examples, write I / O analyzer 122 adds 140 entries to a metadata I / O table for corresponding metadata write-block I / O operations, and write I / O analyzer 122 adds 142 entries to a file I / O table for corresponding file write-block I / O operations as well as unrecognized write-block I / O operations. An "unrecognized" write-block I / O operation is a write-block I / O operation that is not recognized as either a metadata write-block I / O operation or a file write-block I / O operation of a recognized file type.

[0027] The metadata I / O table 140 and the file I / O table 142 are stored in memory 144 of computer system 102. Although they are referred to as tables, the metadata I / O table 140 and the file I / O table 142 can also be implemented with other types of data structures, such as text files, trees, etc.

[0028] In one example, metadata I / O table 140 contains a "Filename" column and a "Data Offset" column. The "Filename" column contains the names of the respective files recognized in the metadata of metadata write-block I / O operations. As used here, "Metadata of a Metadata Write-Block I / O Operation" can refer to metadata included as part of the metadata write-block I / O operation. In the example shown, metadata I / O table 140 contains entries 146-1, 146-2, 146-3, and 146-4, with the following respective filenames: 1.DOCX, 2.PPTX, 3.PPTX, and 4.PDF. Each of the aforementioned filenames has an extension that indicates the file type. Thus, the .DOCX extension represents a Word file, the .PPTX extension represents a PowerPoint file, and the .PDF extension represents an Acrobat file. Further examples: The extension .JPG stands for a JPEG file, the extension .MPG for an MPEG file, and so on.

[0029] The Data Offset column of Metadata I / O Table 140 contains the data offsets at which the data of the respective files is located. The filename and data offset in each entry of Metadata I / O Table 140 are extracted from the metadata of a corresponding metadata write-block I / O operation. Entry 146-1 indicates that the file named 1.DOCX is stored at data offset 600, entry 146-2 indicates that the file named 2.PPTX is stored at data offset 800, entry 146-3 indicates that the file named 3.PPTX is stored at data offset 100, and entry 146-4 indicates that the file named 4.PDF is stored at data offset 200.

[0030] In the example shown, file I / O table 142 contains a "Data Offset" column and a "Header Type" column. The Data Offset column identifies data offsets associated with corresponding file write-block I / O operations. A file write-block I / O operation writes a data block of a file located at a corresponding data offset. The Header Type column contains information about the file type, taken from the header of a file write-block I / O operation. The header of the file write-block I / O operation can contain a signature that specifies a file type. Different signatures in the headers of file write-block I / O operations indicate different file types, such as DOCX, PPTX, PDF, JPG, MPG, etc.

[0031] In one example, entry 148-1 of file I / O table 142 indicates that a file at data offset 800 is of type PPTX, entry 148-2 indicates that a file at data offset 500 is of type JPG, entry 148-3 of file I / O table 142 indicates that a file at data offset 100 is of type "unrecognized," and entry 148-4 of file I / O table 142 indicates that a file at data offset 220 is of type "unrecognized." The "unrecognized" file type contained in the "Header Type" column of an entry in file I / O table 142 indicates that the write I / O analyzer 122 was unable to determine the file type from the header of a corresponding file write-block I / O operation.

[0032] Although the metadata I / O table 140 and the file I / O table 142 display the columns in a specific order, the columns may be arranged differently in other examples. Furthermore, the metadata I / O table 140 and the file I / O table 142 may contain alternative or additional columns in other examples. In still other examples, both the metadata I / O table 140 and the file I / O table 142 may contain a different number of entries.

[0033] File Type Comparator 126 compares entries in Metadata I / O Table 140 and File I / O Table 142. File Type Comparator 126 compares data offsets in the entries of Metadata I / O Table 140 with data offsets in the entries of File I / O Table 142 to determine if there are matching data offsets. For example, entry 146-2 in Metadata I / O Table 140 has a data offset of 800, which matches the data offset of 800 in entry 148-1 of File I / O Table 142. Based on the identification of matching data offsets, the file type comparator 126 compares a file type specified in the Filename column of entry 146-2 with the file type specified in the Header Type column of entry 148-1. The file type comparator 126 is able to determine that the PPTX file type specified by entry 146-2 matches the PPTX file type specified by entry 148-1.The matching file types of the compared entries 146-2 and 148-1 of the metadata I / O table 140 and the file I / O table 142 respectively indicate that the file was not encrypted at data offset 800.

[0034] File Type Comparator 126 also recognizes that entry 146-3 of metadata I / O table 140 has a data offset of 100, which matches the data offset of 100 in entry 148-3 of file I / O table 142. File Type Comparator 126 compares the file type specified in the File Name column of entry 146-3 with the file type specified in the Header Type column of entry 148-3 of file I / O table 142. File Type Comparator 126 detects a mismatch between the PPTX file type specified by entry 146-3 and the "unrecognized" file type specified by entry 148-3.

[0035] The mismatch may indicate an encryption attack. In response to the mismatch, the file type comparator 126 issues an attack alert 150 to a remediation engine 152. The attack alert 150 can take the form of a signal, a message, an information element, or another indicator. The attack alert 150 specifies which file was encrypted (e.g., the attack alert 150 may contain the data offset 100).

[0036] The remediation machine 152, which receives the attack alert 150, may be part of the computer system 102, or the remediation machine 152 may be located outside of the computer system 102. The remediation module 152 may perform one or more remedial actions in response to the attack alert 150.

[0037] In some examples, Remediation Engine 152 can track a number of mismatches associated with a specific data offset. For data offset 100, for example, Remediation Engine 152 can track (using a counter) how many mismatches have occurred for the file at data offset 100. If the number of mismatches displayed by the counter exceeds a threshold (e.g., 1 or greater), Remediation Engine 152 can determine that an encryption attack is likely taking place with respect to the file at data offset 100. In response, Remediation Engine 152 can initiate one or more remediation actions. Examples of remediation actions might include one or a combination of the following: sending a notification to a target entity (e.g.,a human administrator, a program, or a machine), disabling computer system 102 by shutting down computer system 102 or disabling programs on computer system 102), disabling a network connection of computer system 102, or any other type of remedial action. Thus, the attack detector 120 can detect not only unauthorized encryption attacks but also other types of malware attacks.

[0038] In other cases, the discrepancy may indicate another anomaly related to the data. For example, malware or another entity may have intentionally or inadvertently created a filename with an incorrect extension. Furthermore, instead of or in addition to Attack Detector 120, a Data Integrity and Validation Engine with a Write I / O Analyzer and a File Type Comparator (similar to Write I / O Analyzer 122 and File Type Comparator 126) can be used to detect other anomalies related to the data. The Data Integrity and Validation Engine can issue an anomaly alert if it detects a mismatch between file types in metadata and write-block I / O operations.

[0039] Fig.This is a message flow diagram of a process performed by the attack detector 120 in accordance with some examples in this disclosure. The attack detector 120 monitors a stream of write-block I / O operations. The write I / O analyzer 122 in the attack detector 120 analyzes each write-block I / O operation as it is received. This write-block I / O operation is referred to as the "current" write-block I / O operation. The process starts at 202 for each received write-block I / O operation.

[0040] The write I / O analyzer 122 determines (at 202) a type of current write block I / O operation, which may be a metadata write block I / O operation, a file write block I / O operation of a recognized file type, or an unrecognized write block I / O operation.

[0041] The detection of a metadata write-block I / O operation is based on a metadata write-block I / O header. In some examples, the metadata write-block I / O operation is indicated by a special metadata header (or "metadata prefix") of a write-block I / O operation. In NTFS, the metadata write-block I / O operation is indicated by the string "FILE," which is an example of a metadata prefix. In other examples, the block I / O operation with metadata is indicated by other metadata prefixes. A write-block I / O operation without the metadata prefix is ​​not a metadata write-block I / O operation.

[0042] The detection of a file write-block I / O operation of a recognized file type is based on a recognized signature present in the header of the write-block I / O operation. Note that the header of the file write-block I / O operation does not contain the metadata prefix that indicates a metadata write-block I / O operation. Rather, the header of the file write-block I / O operation may contain a signature to identify the file type of a file that is the subject of the file write-block I / O operation. For example, a file write-block I / O operation with the signature "PK..." in its header (where "..." indicates that more characters follow "PK") will write a DOCX file. Another example: A file write-block I / O operation containing the signature "%PDF..." in its header will write a PDF file.Other signatures in the headers of other file write-block I / O operations indicate write operations for other recognized file types.

[0043] It is also possible that a write-block I / O header contains neither the metadata prefix for a metadata write-block I / O operation nor a recognized signature of a file-block I / O operation. In this case, the write-block I / O operation is an unrecognized write-block I / O operation, i.e., a file-block I / O operation of an unrecognized file type. An example of an unrecognized write-block I / O operation is one that writes an encrypted data block.

[0044] Based on the detection that the current write-block I / O operation is a metadata write-block I / O operation, write I / O analyzer 122 extracts from the metadata of the metadata write-block I / O operation the filename of a file represented by the metadata and a data offset of the file (at 204). Write I / O analyzer 122 inserts (at 206) an entry into metadata I / O table 140, where the added entry correlates the filename with the data offset extracted from the metadata. The filename in the added entry includes an extension (e.g., DOCX extension, PPTX extension, PDF extension, etc.) that indicates the corresponding file type.

[0045] In some cases, the metadata of a metadata write-block I / O operation may not contain a filename with a recognized extension. In such cases, the write I / O analyzer 122 does not create an entry in the metadata I / O table 140. Therefore, no further analysis is performed on information in a metadata write-block I / O operation without a recognized file extension.

[0046] Based on the detection that the current write-block I / O operation is a file write-block I / O operation of a recognized file type, the write I / O analyzer 122 (at 208) determines the file type based on the signature in the header of the file write-block I / O operation. The write I / O analyzer 122 also receives (at 210) the data offset associated with the file write-block I / O operation. Each file write-block I / O operation targets a corresponding data offset.

[0047] The write I / O analyzer 122 inserts (at 212) an entry into the file I / O table 142, where the added entry correlates the determined file type (in the Header Type column of the added entry) with the data offset of the file that is the target of the file write block I / O operation.

[0048] Based on the detection that the current write-block I / O operation is an unrecognized file write-block I / O operation (e.g., the header of the current write-block I / O operation does not contain a recognized signature), write I / O analyzer 122 (at 214) retrieves the data offset associated with the unrecognized write-block I / O operation. Write I / O analyzer 122 inserts an entry (at 216) into file I / O table 142, where the added entry correlates the "unrecognized" file type (in the Header Type column of the added entry) with the data offset of the unrecognized write-block I / O operation.

[0049] File type comparator 126 starts at 220 for each detected update of metadata I / O table 140 or file I / O table 142. File type comparator 126 detects (at 220) an update of I / O table X, which is either metadata I / O table 140 or file I / O table 142. It should be noted that updates to metadata I / O table 140 and file I / O table 142 may not be synchronized. This can be caused by the writing of a data block of a file and the corresponding writing of the metadata for the file to primary data store 108 occurring at different times (e.g., separated by a few seconds or another time interval).For example, writing the metadata for the file might occur before writing the file's data block, or vice versa. This would result in the entries for these writes being added to metadata I / O table 140 and file I / O table 142 at different times. Consequently, when a new entry is added to either metadata I / O table 140 or file I / O table 142, file type comparator 126 might not find matching data offsets in the corresponding entries in metadata I / O table 140 and file I / O table 142. At a later time, after the corresponding new entry has been inserted into the other of the metadata I / O table 140 or the file I / O table 142, the file type comparer 126 can find matching data offsets in the corresponding entries of the metadata I / O table 140 and the file I / O table 142.

[0050] File Type Comparator 126 can detect an update to I / O Table X based on receiving an update notification, for example, from Write I / O Analyzer 122. In response to the update detection (which involves adding a new entry to I / O Table X), File Type Comparator 126 (at 222) compares the new entry added to I / O Table X with entries in I / O Table Y. I / O Table Y is the other of Metadata I / O Table 140 and File I / O Table 142. More precisely, if I / O Table X is Metadata I / O Table 140, File Type Comparator 126 compares the new entry added to Metadata I / O Table 140 with entries in File I / O Table 142.If, however, I / O table X is file I / O table 142, the file type comparator 126 compares the new entry in file I / O table 142 with the entries in metadata I / O table 140.

[0051] File Type Comparator 126 checks (at 224) whether there are entries from Metadata I / O Table 140 and File I / O Table 142 with matching data offsets. If not, File Type Comparator 126 returns to wait for another update (at 220). However, if entries from Metadata I / O Table 140 and File I / O Table 142 with matching data offsets exist, File Type Comparator 126 (at 226) compares the file types specified by the entries with the matching data offsets. If the file types match, File Type Comparator 126 returns to wait for another update. If the file types do not match, File Type Comparator 126 (at 228) issues an attack warning (e.g., 150). Fig. ) which are linked to a remedial program (e.g. 152 in Fig.) can be sent. More generally, the file type comparer 126 can issue an anomaly warning based on the detection of mismatched file types in the metadata I / O table 140 and the file I / O table 142.

[0052] In some examples, to reduce memory consumption, entries from metadata I / O table 140 and file I / O table 142 can be removed if one or more criteria are met. For example, an entry can be removed from metadata I / O table 140 or file I / O table 142 if it has been present in the table for longer than a certain period. Another example: To make room for a new entry in metadata I / O table 140 or file I / O table 142, an existing entry can be removed based on a Least Recently Used (LRU) criterion; that is, the entry that has been used the least in the respective I / O table is removed.

[0053] In some examples, the "Header Type" column of File I / O Table 142 contains only information about a specific file type (a recognized file type such as DOCX, PPTX, PDF, etc., or an unrecognized file type). In other examples, instead of determining the file type when processing write-block I / O operations, the first 256 bytes (or another segment) of a non-metadata write-block I / O operation can be stored in the Header Type column. If matching offsets are then found in the corresponding entries of Metadata I / O Table 140 and File I / O Table 142, the contents of the "Header Type" column can be parsed to determine the file type. The latter examples can reduce the processing effort, since a specific determination of the file type only needs to be carried out when matching data offsets are found between the metadata I / O table 140 and the file I / O table 142.However, the latter examples may require more storage space because more information is stored in the "Header Type" column.

[0054] Table 1 below lists eight examples of block I / O write operations. The "Data Offset" column in Table 1 indicates the data offset that is the target of the block I / O write operation. The "Parsed Information" column in Table 1 contains the information parsed for the block I / O write operation. The "Interpretation of Information" column in Table 1 indicates the meaning of the parsed information. TABLE 1 Data Shifted Verified information Evaluation of information 1 20 FILE...1.PDF ...500... Data record filename: 1.PDF Data offset: 500 2 24 FILE...2.DOCX ...1000... Record filename: 2.DOCX Data offset: 1000 3 600 PK... DOCX signature 4 1000 Press conference DOCX signature 5 500 %PDF... PDF signature 6 30 FILE...3.DOCX ...600... Record filename: 3.DOCX Data offset: 600 7 700 ???????????????????????????? Unknown header 8 700 FILE...4.PDF ...700... Data record filename: 4.PDF Data offset: 700

[0055] Entry 1 in Table 1 is a metadata write-block I / O operation for data offset 20 (this example data offset is part of the primary data store 108, which contains the metadata repository 132 of Fig.The header of the metadata write-block I / O operation represented by entry 1 has the metadata prefix "FILE", indicating the writing of a file record (an example of metadata). The metadata (file record) of the metadata write-block I / O operation represented by entry 1 contains the file name 1.PDF, and the metadata indicates that the data offset of this file (1.PDF) is 500.

[0056] Entry 2 in Table 1 is a metadata write-block I / O operation for data offset 24 (this example data offset is part of the primary data store 108, which contains the metadata repository 132 of Fig.The header of the metadata write-block I / O operation represented by entry 2 has the metadata prefix "FILE", indicating the writing of a file set. The metadata (file set) of the metadata write-block I / O operation represented by entry 2 contains the file name 2.DOCX, and the metadata indicates that the data offset of this file (2.DOCX) is 1000.

[0057] Entry 3 in Table 1 is a file write-block I / O operation with a data offset of 600. The header of the file write-block I / O operation represented by entry 3 has the signature "PK...", which indicates the DOCX file type.

[0058] Entry 4 in Table 1 is a file write-block I / O operation with a data offset of 1000. The header of the file write-block I / O operation represented by entry 4 has the signature "PK...", which indicates the DOCX file type.

[0059] Entry 5 in Table 1 is a file write-block I / O operation with a data offset of 500. The header of the file write-block I / O operation represented by entry 3 has the signature “%PDF...”, which indicates the PDF file type.

[0060] Entry 6 in Table 1 is a metadata write-block I / O operation for data offset 30 (this example data offset is part of the primary data store 108, which contains the metadata repository 132 of Fig. The header of the metadata write-block I / O operation represented by entry 6 has the metadata prefix "FILE", indicating the writing of a file set. The metadata (file record) of the metadata write-block I / O operation represented by entry 6 contains the file name 3.DOCX, and the metadata indicates that the data offset of this file (3.DOCX) is 600.

[0061] Entry 7 in Table 1 is an unrecognized write-block I / O operation with a data offset of 700. The header of the unrecognized write-block I / O operation contains neither the metadata prefix nor a recognized file type signature.

[0062] Entry 8 in Table 1 is a file write-block I / O operation with a data offset of 700. The header of the file write-block I / O operation represented by entry 8 has the signature “%PDF...”, which indicates the PDF file type.

[0063] In examples where metadata for files comprises NTFS file records, a file record has a size of 1 kilobyte (KB). Furthermore, in an NTFS system, file records are written to a MFT, which is an example of the metadata repository 132 of Fig.Furthermore, write / input operations to the MFT are 4 KB-aligned, meaning a write operation to the MFT is a write operation to a 4 KB segment. Since each file set is 1 KB in size, this means that a write operation to a 4 KB segment of the MFT can encompass up to four file sets. When the Write I / O Analyzer 122 detects the metadata prefix "FILE" of an initial file set at the beginning of the 4 KB segment, the Write I / O Analyzer 122 can analyze the metadata in the three other consecutive file sets within the 4 KB segment to extract attributes from each of the file sets in the 4 KB segment.

[0064] When the write-block I / O operations are received, the write I / O analyzer adds 122 ( Fig.) corresponding entries in the metadata I / O table 140 and the file I / O table 142. After the 8 write-block I / O operations have been processed by the write I / O analyzer 122, the entries of the metadata I / O table 140 are represented by Table 2 below and the entries of the file I / O table 142 by Table 3 below. TABLE 2 File name Data offset 1.PDF 500 2.DOCX 1000 3.DOCX 600 4.PDF 700 TABLE 3 Data offset Header type 600 DOCX header 1000 DOCX header 500 PDF header 700 Unrecognized

[0065] In the example above, the data offset (500) in the first entry of Table 2 matches the data offset (500) in the third entry of Table 3. Based on these entries, the file type comparer 126 can determine that the file type (PDF) specified in the "File Name" column of the first entry in Table 2 matches the file type (PDF) specified in the "Header Type" column of the third entry in Table 3.

[0066] Furthermore, the data offset (700) in the fourth entry of Table 2 matches the data offset (700) in the fourth entry of Table 3. Based on these entries, the file type comparer 126 can determine that the file type (PDF) specified in the Filename column of the fourth entry in Table 2 does not match the unrecognized file type specified in the Header Type column of the fourth entry in Table 3. In response to this file type mismatch, the file type comparer 126 can issue an attack warning.

[0067] Fig. is a block diagram of a non-transient machine-readable or computer-readable storage medium 300 that stores machine-readable instructions which, when executed, cause a system to perform various tasks. The system could, for example, be the computer system 102 of Fig.The machine-readable instructions may be part of Attack Detector 120 or any other data anomaly detector.

[0068] The machine-readable instructions contain metadata block I / O identification instructions 302 to identify a first block I / O operation related to writing metadata for a data object, where the metadata of the first block I / O operation contains initial object type information. For example, the metadata might contain an object name, where the object name includes a type extension that specifies the object's type. If the object is a file, then the object name is a file name with a file type extension.

[0069] The machine-readable instructions include commands for generating second object type information (304) to generate second object type information based on the header of a second block I / O operation that involves writing object contents to a target data object (e.g., file contents to a target file). This second object type information relates to an object type of the target data object. The header of the second block I / O operation might, for example, contain a signature that specifies the second object type. Different object types of data objects are associated with different signatures.

[0070] The machine-readable instructions include instruction 306 for comparing object type information, in order to compare the first object type information in the metadata of the first block I / O operation with the second object type information.

[0071] The machine-readable instructions contain instructions for anomaly detection (308) to determine, based on comparison, whether a data anomaly has occurred. If the information of the first object type and the information of the second object type do not match, the machine-readable instructions may indicate that a data anomaly has occurred. The data anomaly could include a data encryption attack, another type of malware attack, an unintentional error, or another type of anomaly.

[0072] In some examples, identifying the first block I / O operation related to writing the metadata involves detecting a metadata prefix in a header of the first block I / O operation.

[0073] In some examples, the generated second object type information indicates an unrecognized object type responding to the second block I / O operation, which does not contain a signature with respect to a recognized object type. A "recognized object type" (e.g., a recognized file type) is an object type specified by predefined information, such as a list of object types known to exist or permitted for use in a computer system or other computing environment.

[0074] In some examples, the machine-readable instructions can extract a first data offset from the metadata of the first block I / O operation. This offset relates to where the data object associated with the metadata is stored in a storage system. The machine-readable instructions can determine a second data offset, which relates to where the target data object is written to the storage system by the second block I / O operation. The comparison of the first object type information with the second object type information occurs in response to a match between the first and second data offsets.

[0075] In some examples, the machine-readable instructions can add the first data offset and the first object type information to an entry in a first data structure and add the second data offset and the second object type information to an entry in a second data structure. The comparison is based on identifying the entries in the first and second data structures with matching first and second data offsets.

[0076] In some examples, upon detecting an update to either the first or second data structure, the machine-readable instructions can compare the entries of the first and second data structures to identify any matching data offsets. Based on identifying a first entry of the first data structure and a second entry of the second data structure with matching data offsets, the machine-readable instructions can compare object type information in the first entry with object type information in the second entry.

[0077] In some examples, the machine-readable instructions can indicate the occurrence of the anomaly with respect to data that responds to the object type information in the first entry, which does not match the object type information in the second entry.

[0078] In some examples, the machine-readable instructions can remove (evoke) an entry from the first data structure or the second data structure based on the age of the entry.

[0079] In some examples, the machine-readable instructions can remove (evoke) an entry from the first data structure or the second data structure according to an LRU criterion.

[0080] In some examples, the first block I / O operation is a metadata block I / O operation, and the second block I / O operation is an object block I / O operation. The machine-readable instructions can track a counter of occurrences of object type mismatches in subsequent metadata and file block I / O operations, compare the counter to a threshold, and, based on the counter exceeding the threshold, indicate the occurrence of the anomaly with respect to the data.

[0081] Fig.This is a block diagram of a System 400 according to some examples in the present disclosure. One example of System 400 is Computer System 102 from Fig. .

[0082] The System 400 includes one Hardware Processor 402 (or multiple hardware processors). A hardware processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry.

[0083] The System 400 includes a storage medium 404 on which machine-readable instructions are stored that can be executed on the hardware processor 402 to perform various tasks. Machine-readable instructions executable on a hardware processor can refer to instructions that can be executed on a single hardware processor or on multiple hardware processors.

[0084] The machine-readable instructions in storage medium 404 contain metadata block I / O identification instructions 406 to identify a metadata block I / O operation related to writing metadata for a data object. The identification of the metadata block I / O operation can be based on a metadata prefix in a header of the metadata block I / O operation.

[0085] The machine-readable instructions in storage medium 404 contain instructions for extracting initial object type information 408 from the metadata of the metadata block I / O operation. The metadata may contain an object name that includes an extension specifying the initial object type.

[0086] The machine-readable instructions in storage medium 404 contain instructions for generating second object type information 410 to generate, based on a header of an object block I / O operation that relates to writing object contents to a target data object, second object type information relating to an object type of the target data object. The second object type information can indicate a recognized object type or an unrecognized object type.

[0087] The machine-readable instructions in storage medium 404 contain instructions for comparing object type information 412 to compare the first object type information in the metadata of the metadata block I / O operation with the second object type information.

[0088] The machine-readable instructions in the storage medium 404 contain instructions for anomaly detection 414 to determine, on the basis of comparison, whether an anomaly has occurred with respect to data.

[0089] Fig. This is a flowchart of a Process 500 according to some examples. Process 500 can be detected by the Attack Detector 120. Fig. or any other type of detector.

[0090] Process 500 involves receiving (at 502) a variety of write-block I / O operations that write data blocks to a storage system. For example, multiple write-block I / O operations are detected by the replication controller 106, which routes the multiple write-block I / O operations to the recovery storage system 104. Fig. replicated.

[0091] Process 500 involves identifying (at 504) a metadata write-block I / O operation among the multitude of write-block I / O operations, where the metadata write-block I / O operation refers to writing metadata for a data object.

[0092] Process 500 involves extracting (at 506) initial object type information from the metadata of the metadata write-block I / O operation. The initial object type information may include an object type extension in an object name contained in the metadata.

[0093] Process 500 involves identifying (at 508) an object write-block I / O operation from among the multitude of write-block I / O operations, where the object write-block I / O operation refers to writing object contents to a target data object. The object write-block I / O operation can be an object write-block I / O operation of a recognized object type or an object write-block I / O operation of an unrecognized object type.

[0094] Process 500 involves generating (at 510) secondary object type information based on a header from the object write-block I / O operation. This secondary object type information can indicate a recognized object type or a response (e.g., "unrecognized") that the object type is not recognized.

[0095] Process 500 involves comparing (at 512) the first object type information in the metadata of the metadata write-block I / O operation with the second object type information. Based on this comparison, process 500 determines (at 514) whether a data anomaly has occurred.

[0096] As used here, a “storage system” can be implemented with one or more storage devices, e.g., disk-based storage devices, solid-state drives, or other types of storage devices.

[0097] A storage medium (e.g., 300 in Fig. in Fig.The instruction set can include any or a combination of the following: a semiconductor storage device such as dynamic or static random-access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), or flash memory; a magnetic disk such as a hard disk, floppy disk, or removable disk; another magnetic medium, including tape; an optical medium such as a compact disc (CD) or digital video disc (DVD); or some other type of storage device. It should be noted that the above instructions can be provided on a single computer- or machine-readable storage medium or, alternatively, on multiple computer- or machine-readable storage media distributed throughout a large system, possibly with multiple nodes.Such a computer-readable or machine-readable storage medium or media are considered part of an article (or manufactured item). An article or manufactured item may refer to any single manufactured component or to multiple components. The storage medium or media may be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded for execution over a network.

[0098] In this disclosure, the use of the term "a," "an," or "the" includes the plural forms unless the context clearly indicates otherwise. Similarly, the terms "includes," "including," "comprises," "have," or "have," when used in this disclosure, specify the presence of the elements indicated but do not exclude the presence or addition of other elements.

[0099] The foregoing description includes numerous details to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and deviations from the details described above. It is intended that the accompanying claims cover such modifications and variations.

Images