Honeypot-based attack detection
By creating honeypot files in the computer system and using a data replication manager to monitor I/O operations, the problems of delayed ransomware attack detection and false positives in existing technologies are solved, enabling early attack detection and data protection.
Patent Information
- Application Number
- CN202510102510.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-04-18
- Filing Date
- 2025-01-22
- Publication Date
- 2025-10-24
AI Technical Summary
Existing ransomware protection systems struggle to detect ransomware attacks quickly in the early stages of data encryption and are prone to false alarms, leading to the encryption and leakage of large amounts of data.
Using deception-based detection technology, honeypot files are created in the computer system and I/O operations are monitored using a data copy manager to identify and record honeypot patterns and detect access to honeypot files to indicate potential attacks.
It enables early detection of ransomware attacks, prevents data encryption and leakage, reduces detection delays, and lowers the false positive rate.
Smart Images

Figure CN120832669A_ABST
Abstract
Description
BACKGROUND
[0001] Ransomware attacks involve encrypting data on a computer or multiple computers connected through a network. In a ransomware attack, data can be encrypted using an encryption key, which makes the data inaccessible to a user unless a ransom is paid to obtain the encryption key. Ransomware attacks can cause great disruption to businesses, including commercial companies, government agencies, educational organizations, individuals, and the like. BRIEF DESCRIPTION OF DRAWINGS
[0002] Some implementations of the present disclosure are described with respect to the following drawings.
[0003] Figure 1 is a block diagram of a computer system including a honeypot agent and a data replication manager, according to some examples.
[0004] Figure 2 is a flow diagram of a data protection process, according to some examples.
[0005] Figure 3 is a block diagram of a storage medium storing machine-readable instructions, according to some examples.
[0006] Figure 4 is a block diagram of a system, according to some examples.
[0007] Figure 5 is a flow diagram of a process, according to some examples.
[0008] In all of the drawings, like reference numerals refer to like but not necessarily identical elements. The drawings are not necessarily to scale and the size of some parts can be exaggerated to more clearly illustrate the examples shown; thus, the drawings are provided to illustrate examples and / or implementations consistent with the description, not to limit the description. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION
[0009] Quick detection of ransomware attacks can reduce the likelihood of attackers stealing sensitive information and making the information inaccessible through encryption of the information. Any delay in detection can reduce the likelihood of victims being able to recover from a ransomware attack and avoid data theft.
[0010] Some ransomware protection systems can be able to detect a ransomware attack based on detecting that unauthorized data encryption is occurring. For example, a scan of input / output (I / O) operations can be performed to detect whether data is being encrypted. However, by the time a ransomware attack is detected based on detection of data encryption, a large amount of data can have already been encrypted, and further, the attacker can have already exfiltrated data that can be publicly exposed. Note that the attacker exfiltration of data can occur before the attacker encrypts the data. Moreover, some ransomware protection systems can be prone to false positives, i.e., indicating a ransomware attack when a legitimate data encryption operation is being performed.
[0011] According to some embodiments of the present disclosure, a data protection system uses a deception-based detection technique or mechanism that employs honeypot data to detect potential attacks (e.g., potential encryption attacks or any other attacks) against data of a computer system. An “attack” against data can refer to any unauthorized access (write or read) of the data. In some examples, the data protection system can include a honeypot agent and a data replication manager. The honeypot agent creates honeypot files containing data according to a honeypot pattern. The “honeypot pattern” refers to a predefined pattern of data to be contained in a honeypot file. The presence of the honeypot pattern in a given file indicates that the file is a honeypot file rather than a “regular” file. Generally, a “honeypot file” refers to a file that is used as a trap to attract unauthorized entities (users, programs, machines, or other entities) to access the file. The honeypot file is a false file, i.e., an authorized entity associated with the computer system would not normally access the honeypot file because the honeypot file does not contain any valid data that is meaningful to the authorized entity. In contrast, a “regular” file is a file that is accessed during operation of the computer system associated with the authorized entity, which is an entity (user, program, machine, or another entity) that is permitted to use or access the computer system. A “file” can refer to any identifiable container of data, which can be in the form of a file of a file system, an object, or any other type of data container.
[0012] The data replication manager copies data written by the data writer (which writes data to a data volume) to a replication storage system. The data replication manager can monitor I / O operations to identify data matching the honeypot pattern and determine storage location information associated with the data identified as matching the honeypot pattern. For example, the storage location information identifies a storage location of the honeypot file. The data replication manager detects access to data at the storage location indicated by the storage location information, and the data replication manager indicates a potential attack based on detecting the access to the data at the storage location indicated by the storage location information.
[0013] Figure 1is a block diagram of an example arrangement including computer system 102 and storage system 106. Examples of a computer system can include any one or some combination of the following: a computer (e.g., a server computer, a desktop computer, a notebook computer, a tablet computer, or other type of computer), a smart phone, an Internet of Things (IoT) device, a home appliance, a vehicle, a gaming device, or other type of electronic device.
[0014] Computer system 102 can store data in storage system 106 coupled to computer system 102. Storage system 106 can be part of computer system 102, or storage system 106 can be external to computer system 102. Storage system 106 can be implemented using a set of storage devices (one storage device or multiple storage devices). Examples of a storage device can include any one or some combination of the following: a disk-based storage device, a solid state drive, or other type of storage device.
[0015] In some examples, computer system 102 executes one or more programs (including machine-readable instructions) that can perform data transactions that read and write data in storage system 106. Examples of programs can include virtual computing entities such as virtual machines (VMs) 108, 109. Although two VMs are depicted in Figure 1 in other examples, a different number (1 or more than 1) of VMs can be executed in computer system 102.
[0016] A VM refers to a virtual computing entity that emulates a physical computer. A guest operating system (OS) and one or more application programs can be executed in a VM. For example, VM 108 includes guest OS 128 and one or more application programs 130. Similarly, VM 109 includes a guest OS and one or more application programs (not shown).
[0017] In other examples, other virtual computing entities that can be executed in computer system 102 can include containers, which are isolated computing environments in which application programs can be executed. In further examples, virtualized computing environments are not implemented in computer system 102; in such examples, programs can be executed in an environment provided by a host OS (not shown) of computer system 102.
[0018] In examples where a VM is executing in computer system 102, there is also a hypervisor 110 (implemented as machine-readable instructions) in computer system 102. A hypervisor is also referred to as a virtual machine monitor (VMM). Hypervisor 110 creates and controls the execution of VMs 108, 109. Hypervisor 110 is also responsible for presenting to each of VMs 108, 109 an emulated instance of the physical resources (e.g., processing resources, storage resources, communication resources, or other resources) of computer system 102.
[0019] More generally, hypervisor 110 is an example of a virtualization hypervisor running on computer system 102. Another example of a virtualization hypervisor is a container engine that can launch and manage containers in computer system 102.
[0020] The following discussion refers to some examples that employ VMs. It should be noted that techniques or mechanisms in accordance with some examples of the present disclosure can be applied to other types of virtual computing entities (like containers), or in computer systems that do not implement virtualized computing environments.
[0021] In examples where a VM is executing in computer system 102, there is also a hypervisor 110 (implemented as machine-readable instructions) in computer system 102. A hypervisor is also referred to as a virtual machine monitor (VMM). Hypervisor 110 creates and controls the execution of VMs 108, 109. Hypervisor 110 is also responsible for presenting to each of VMs 108, 109 an emulated instance of the physical resources (e.g., processing resources, storage resources, communication resources, or other resources) of computer system 102. Figure 1 Figure 1 In the example depicted in FIG. 1, VM 108 (or more specifically, a program executing in VM 108, like application 130 or guest OS 128) can read or write data in data volumes 120, 121. Although 2 data volumes are depicted in FIG. 1, different examples can involve a different number (1 or more than 1) of data volumes. A “data volume” refers to a logical container of data that is accessible by a VM. The data of data volumes 120, 121 is physically stored at storage system 106. When a program (application 130 or guest OS 128) accesses (reads or writes) data of data volume 120 or 121, VM 108 generates a data transaction 112 for reading or writing the data in storage system 106. Data transaction 112 is received by hypervisor 110.
[0022] Similarly, access to data volumes in VM 109 generates data transactions 113 that are received by hypervisor 110.
[0023] In some examples, hypervisor 110 includes a driver 114 that can split data transactions 112 or 113 into block I / O operations 116 that are provided to storage system 106. A “driver” can refer to a program that manages access to storage system 106. In other examples, the driver can be part of a container engine or host OS of computer system 102.
[0024] A block I / O operation refers to a data operation on a data block, where the data block has a specified size (e.g., 512 bytes (B), 4 kB, or any other size). Each block I / O operation can read a data block from or write a data block to the storage system 106. In response to data transactions 112, 113 from the VMs 108, 109, the driver 114 generates block I / O operations 116 for reading and / or writing data blocks of the storage system 106. In other examples, the driver 114 can be omitted, and the block I / O operations are generated by the hypervisor 110.
[0025] The computer system 102 includes a data replication manager 118 for protecting data volumes of the VMs 108, 109. The data replication manager 118 can be implemented as machine-readable instructions that execute in the computer system 102. For example, the data replication manager 118 can execute in a VM or container, or the data replication manager 118 can execute as an application or utility. Alternatively, the data replication manager 118 can be implemented using hardware processing circuitry of the computer system 102. In other examples, the data replication manager 118 can be external to the computer system 102.
[0026] The data replication manager 118 protects data volumes by writing data to a replication data store 132 stored in persistent storage 134. A“replication” of a data write can refer to providing a representation of a write I / O operation (or more specifically, a write block I / O operation) that writes data to a storage system (or more specifically, to a data block in the storage system), such as the storage system 106. The block I / O operations 116 can include read block I / O operations (reading data blocks in the storage system 106) and write block I / O operations (writing data blocks to the storage system 106).
[0027] The representation of a write I / O operation added to the replication data store 132 by the data replication manager 118 can include changed data (new data, or modified data, or deleted data) that was written to the storage system 106.
[0028] The replicated data repository 132 to which write I / O operations are added, representing writes to replicated data, can refer to any type of data structure. In some examples, the replicated data repository 132 can be stored in a persistent memory 134 in the computer system 102. Persistent memory refers to a memory that can maintain the data stored in the memory even when the memory is powered off. In some examples, the persistent memory 134 is implemented using a collection of persistent memory devices (such as flash memory devices, electrically erasable programmable read-only memory (EEPROM) devices, or other forms of non-volatile memory devices). In other examples, the replicated data repository 132 can be stored in a persistent memory external to the computer system 102, such as in a remote backup storage system.
[0029] Replicated data repository 132 includes a log of write I / O operations associated with protected data volumes. In some examples, replicated data repository 132 does not store information about read I / O operations. The representation of write I / O operations in replicated data repository 132 can be used to recover written data in the event that computer system 102 experiences a failure or data in storage system 106 is corrupted.
[0030] For each VM, an administrator or another entity can specify which data volume(s) of the VMs 108, 109 are selected for protection by the data replication manager 118. The selected data volumes are also referred to as protected data volumes. The data replication manager 118 protects the selected data volume(s) and does not protect the unselected data volume(s). The data replication manager 118 does not replicate write I / O operations associated with the unselected data volume(s) (also referred to as unprotected data volume(s)).
[0031] exist Figure 1 In the example of FIG, it is assumed that data volume 120 of VM 108 is a protected data volume and data volume 121 is an unprotected data volume. Data replication manager 118 replicates data written to protected data volume 120 but does not replicate data written to unprotected data volume 121.
[0032] The protected data volume 120 contains various files 122, which are regular files. The data volume 120 further includes honeypot files 124 that can have been created by a honeypot agent 126 in the VM 108. The honeypot agent 126 is a program that includes machine-readable instructions that execute in the VM 108. The honeypot agent 126 is capable of creating one or more honeypot files in a respective one or more data volumes. Each honeypot file created by the honeypot agent 126 can have a respective honeypot pattern. In some examples, the honeypot pattern is a random pattern that is generated as a random collection of data values (including data bits, alphanumeric characters, etc.). For example, the honeypot agent 126 can use a pseudo-random number generator to generate a random number, and use the random number to derive a random honeypot pattern. In other examples, the honeypot pattern can be a predefined data pattern that is produced by a user or another entity to represent a honeypot file. The honeypot agent 126 can receive the predefined data pattern from the user or other entity.
[0033] Different honeypot files created by the honeypot agent 126 can have the same honeypot pattern, or different honeypot patterns. For example, a first honeypot file in a first data volume can have a first honeypot pattern, while a second honeypot file in a second data volume can have a different honeypot pattern.
[0034] After the honeypot agent 126 creates the honeypot files 124 in the data volume 120, programs in the VM 108 would not normally access the honeypot files 124. However, if a program is compromised or if an unauthorized program is added to the VM 108, the compromised program or the unauthorized program can access the honeypot files 124. Access to the honeypot files 124 provides an indication that unauthorized activity, including attacks on data (e.g., ransomware attacks), can be occurring in the VM 108.
[0035] Similarly, other VMs (or other virtual computing entities) in the computer system 102 can include honeypot agents. Alternatively or additionally, honeypot agents can execute in non-virtualized computing environments in the computer system 102.
[0036] The following discussion relates to Figure 1 and Figure 2 both. Figure 2 is a flowchart of a data protection process that uses deception-based detection techniques according to some examples of the present disclosure. The data protection process is performed by a data protection system that includes the honeypot agent 126 and the data replication manager 118. Although Figure 2 a particular order of tasks is shown, in other examples, the tasks can be performed in a different order, some tasks can be omitted, or other tasks can be added.
[0037] Figure 2 The data protection process includes an initialization phase 202 and a tracking phase 204. In general, the initialization phase 202 identifies the data volume to be protected (e.g., protected data volume 120), notifies the data replication manager 118 of the honeypot mode, and sets the honeypot file (e.g., Figure 1 124) are added to the protected data volume 120. The tracking phase 204 monitors the block I / O operations (e.g., Figure 1 116) to detect access to the honeypot file 124, which may indicate that a potential attack is occurring.
[0038] Figure 2 The process involves a honeypot agent 126, a protected data volume 120, and a data replication manager 118. The honeypot agent 126 and the protected data volume 120 are part of a VM 108 (referred to as a "protected VM" 108).
[0039] The initialization phase 202 includes tasks 206 through 224, and the tracking phase 204 includes tasks 230 through 234. In the initialization phase 202, the data replication manager 118 identifies (at 206) one or more data volumes (including the protected data volume 120) to be protected for the protected VM 108. For example, an administrator or another entity may specify which data volume(s) to protect to the data replication manager 118. For each protected data volume identified, the data replication manager 118 intercepts block I / O operations that access data of the protected data volume.
[0040] The data replication manager 118 may provide (at 208) information of protected data volumes (e.g., 120) to the honeypot agent 126. The provided information allows the honeypot agent 126 to determine which data volumes of the protected VM 108 are protected and which are unprotected. Communication between the data replication manager 118 and the honeypot agent 126 (executed in the protected VM 108) may pass through the hypervisor 110.
[0041] The honeypot agent 126 creates (at 208) a honeypot pattern, such as by generating a random honeypot pattern or generating another specified data pattern to be included in the honeypot file. In other examples, the honeypot agent 126 may receive a honeypot pattern from another entity, such as a user, program, or machine.
[0042] The honeypot agent 126 sends (at 212) the honeypot pattern to the data replication manager 118. Figure 1In the example of FIG. 1, the data replication manager 118 includes a potential attack detector 150 that is responsible for detecting potential attacks based on detecting access to the honeypot file. The potential attack detector 150 can be implemented with a portion of machine-readable instructions of the data replication manager 118 or with a portion of hardware processing circuitry of the data replication manager 118.
[0043] The potential attack detector 150 can store (at 214) the honeypot pattern 142 from the honeypot agent 126 in a memory 140 (associated with the data replication manager 118). The potential attack detector 150 uses the stored honeypot pattern 142 to detect the location of the honeypot file. Figure 1
[0044] The honeypot agent 126 adds (at 216) the honeypot file containing the honeypot pattern to the protected data volume 120. It should be noted that it is possible that the honeypot agent 126 can create multiple honeypot patterns for different honeypot files, in which case the honeypot agent 126 would provide multiple honeypot patterns to the data replication manager 118. Further, in further examples, there can be multiple honeypot agents in multiple VMs that can send honeypot patterns to the data replication manager 118.
[0045] In the initialization phase 202, the data replication manager 118 intercepts (at 218) block I / O operations associated with data access to the protected data volume 120 of the protected VM 108. The potential attack detector 150 filters (at 220) the intercepted block I / O operations to determine whether the honeypot pattern 142 is present in the intercepted block I / O operations.
[0046] Depending on the size of the data block, the honeypot pattern 142 can be contained within one data block or a collection of multiple data blocks. For example, if the size of one data block is less than the total size of the honeypot pattern 142, the potential attack detector 150 checks for the presence of the honeypot pattern 142 in multiple data blocks. On the other hand, if the size of one data block is the same as or greater than the total size of the honeypot pattern 142, the potential attack detector 150 checks for the presence of the honeypot pattern 142 in a single data block.
[0047] Based on detecting the honeypot pattern 142 in one or more block I / O operations, the data replication manager 118 obtains (at 222) storage location information that specifies where the honeypot file is located. In some examples, the storage location information includes a storage address, which can be a logical address or a physical storage address. More specifically, the storage location information can include a range of storage addresses of the honeypot file.
[0048] The data replication manager 118 stores (at 224) the storage location information in the memory 140. In Figure 1 In the example, the storage location information is in the form of a honeypot file address 144 that specifies a storage address (or address range) of the honeypot file.
[0049] At this point, the initialization phase 202 has completed, and the data replication manager 118 can proceed to the tracking phase 204. It should be noted that the initialization phase 202 can be re-iterated at a later time, such as periodically or when the data volume to be protected is modified.
[0050] In the tracking phase 204, the potential attack detector 150 monitors (at 230) block I / O operations from the protected VM 108. The block I / O operations can include read block I / O operations or write block I / O operations. The data replication manager 118 determines (at 232) whether the block I / O operations access data of a file at an address that intersects (e.g., falls within an address range of) the honeypot file address 144. Data access of an address that intersects the honeypot file address 144 indicates that access to the honeypot file is occurring.
[0051] If the block I / O operations do not access data of the honeypot file at the honeypot file address 144, the data replication manager 118 returns to monitor (at 230) the next block I / O operation from the protected VM 108. On the other hand, if the block I / O operations access data of the honeypot file at the honeypot file address 144, the potential attack detector 150 generates (at 234) a potential attack notification 152 that indicates that a potential attack against the data can be occurring. The potential attack notification 152 can be in the form of a message, an information element, or any other indicator. If the block I / O operation that accesses data at the honeypot file address 144 is a write block I / O operation, the potential attack notification 152 can also include write data associated with the write block I / O operation.
[0052] In some examples, the potential attack notification 152 can also include information of a latest recovery point of the protected data volume 120. A "recovery point" can refer to a point in time to which data of the protected data volume 120 can be recovered. In the event of a system failure, data writes logged to the replicated data repository 132 are recoverable. The logged data writes have timestamp information that can provide an indication of a recovery point of the data of the protected data volume 120. Any data writes that have not been added to the replicated data repository 132 are not recoverable. The "latest" recovery point of the protected data volume 120 refers to the most recently modified data (by a data write modification) that can be recovered from the replicated data repository 132.
[0053] A remediation program 154 (which can be part of the management program 110 or separate from the management program 110) can perform one or more remediation actions in response to the potential attack notification 152. The remediation program 154 can send an alert to a remote entity, such as an administrator, program, or machine, to notify that a potential attack (e.g., a ransomware attack) can be occurring. This would allow the remote entity to take action to confirm whether an attack is occurring, and if so, to take further remediation actions.
[0054] Alternatively or additionally, the remediation program 154 can respond to the potential attack notification 152 by triggering protective actions in the computer system 102, such as by shutting down the protected VM 108, disabling further access to the protected volume 120, disabling network access to the computer system 102, stopping replication of data, saving a latest recovery point, or any other remediation action.
[0055] Although Figure 1 And Figure 2 An example is shown in which the data replication manager 118 is involved in protecting the data volume by writing data to a replication data repository 132, but in other examples, data replication need not be employed. In such other examples, a different program (more commonly referred to as a “data manager”) can be used instead of the data replication manager 118 to perform the tasks 206, 214, 218, 220, 222, 224, 230, 232, and 234 in Figure 2
[0056] In some cases, computer system operations (at the computer system 102) can cause the storage address of the honeypot file 124 to change. For example, a file system in the computer system 102 can perform a file defragmentation operation that consolidates different fragments of a file into more contiguous portions of the storage system 106 for more efficient storage and access. The file defragmentation operation can cause the storage address of the honeypot file 124 to change. Other operations can cause data of the honeypot file 124 to move, which can cause the storage address of the honeypot file 124 to change.
[0057] If the driver 114 detects a change in the storage address of the honeypot file 124, the driver 114 can send an indication of the changed storage address to the data replication manager 118, which can update the honeypot file address 144. Further tracking operations in the tracking phase 204 will be performed with respect to the updated honeypot file address 144.
[0058] By using a data protection system according to some embodiments of the present disclosure, early detection of potential attacks against data can be performed. In some cases, early detection of attacks against data can even occur before data encryption or data theft occurs. For example, any access to the honeypot file can disable the protected VM or computer system 102 to prevent any further action, which can prevent any further data encryption or data taking. Disabling the protected VM can refer to shutting down the VM or disconnecting the VM from the network. In examples where attack detection relies on using the data replication manager 118 to detect access to data at the honeypot file address 144, attack detection can be accomplished without investing significant additional resources to prevent attacks in systems where the data replication manager 118 is already implemented. In such systems, the data replication manager 118 can simply be configured to add the potential attack detector 150, and a honeypot agent (e.g., 126) can be added to support creation of the honeypot file. As described above, in other examples, instead of using the data replication manager 118, another program (a data manager that does not replicate data writes) that performs tasks 206, 214, 218, 220, 222, 224, 230, 232, and 234 in Figure 2
[0059] Figure 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 that stores machine-readable instructions that, when executed, cause a system to perform various tasks. The system can include one or more computers. An example of the system is Figure 1 the computer system 102 of
[0060] The machine-readable instructions include I / O monitoring instructions 302 for monitoring I / O operations to identify data that matches a honeypot pattern. The I / O operations that are monitored can include Figure 1 the block I / O operations 116 of
[0061] The machine-readable instructions include honeypot data storage location information determining instructions 304 for determining storage location information associated with data that is identified as matching the honeypot pattern. For example, the storage location information can include the honeypot file address 144.
[0062] The machine-readable instructions include honeypot storage location access detection instructions 306 to detect access to data at a storage location indicated by the storage location information. For example, the honeypot storage location access detection instructions 306 can determine whether an I / O operation accesses data at the honeypot file address 144. The detected access includes a read access or a write access.
[0063] The machine-readable instructions include potential attack indication instructions 308 to indicate a potential attack based on detecting access to data at a storage location indicated by the storage location information. For example, the potential attack indication instructions 308 can send the potential attack notification 152.
[0064] In some examples, the data replication manager 118 can receive the honeypot pattern from an agent such as the honeypot agent 126. The agent can create a honeypot file containing data having the honeypot pattern. Figure 1
[0065] In some examples, the data replication manager identifies one or more data volumes to be protected by the data replication manager by copying data of the one or more data volumes to a replication data repository. The honeypot file created by the agent is in a data volume of the one or more data volumes.
[0066] In some examples, the data write copied by the data replication manager includes a data write performed by a virtual computing entity (e.g., a VM or a container) protected by the data replication manager.
[0067] In some examples, the agent executes in the virtual computing entity.
[0068] In some examples, the honeypot pattern includes a random pattern or a specified data pattern.
[0069] In some examples, the indication of the potential attack includes providing information identifying a latest recovery point of the data. In further examples, the indication of the potential attack includes providing write data written to the storage location indicated by the storage location information.
[0070] In some examples, the machine-readable instructions can detect a change in a storage location of the data matching the honeypot pattern, determine whether an access to the data at the changed storage location matching the honeypot pattern has occurred based on detecting the change in the storage location, and indicate the potential attack based on detecting the access to the data at the changed storage location.
[0071] In some examples, the monitoring of the I / O operations and the determination of the storage location information are performed during an initialization phase of the data protection process, and the detecting of the access and the indication of the potential attack are performed during a tracking phase of the data protection process after the initialization phase.
[0072] Figure 4 is a block diagram of a system 400 that can be implemented using one or more computers. The system 400 includes a processor resource 402 that includes one or more hardware processors. The hardware processors can include microprocessors, cores of multi-core microprocessors, microcontrollers, programmable integrated circuits, programmable gate arrays, or another hardware processing circuit.
[0073] The system 400 includes a storage medium 404 that stores machine-readable instructions for an agent 406 (e.g., the honeypot agent 126 of Figure 1 and a data replication manager 408 (e.g., the 118 of Figure 1 ). The agent 406 is executable on the processor resource 402 to perform tasks 410 and 412, and the data replication manager 408 is executable on the processor resource 402 to perform tasks 414, 416, 418, and 420. In examples in which the processor resource 402 includes multiple hardware processors, the agent 406 and the data replication manager 408 can be executed on different hardware processors or on the same hardware processor.
[0074] The task 410 of the agent 406 is a honeypot file creation task to create a honeypot file. In some examples, the created honeypot file is added to a data volume to be protected by the data replication manager 408.
[0075] The task 412 of the agent 406 is a honeypot pattern sending task to send a honeypot pattern, such as the honeypot pattern 142 of Figure 1 , to the data replication manager 408.
[0076] The task 414 of the data replication manager 408 is an I / O operation monitoring task to monitor I / O operations to identify data that matches the honeypot pattern. The monitored I / O operations can include the block I / O operations 116 of Figure 1 .
[0077] The task 416 of the data replication manager 408 is a honeypot data storage location information determination task to determine storage location information associated with data that is identified as matching the honeypot pattern. The storage location information identifies a storage location of the honeypot file. For example, the storage location information includes the honeypot file address 144 of Figure 1 .
[0078] The task 418 of the data replication manager 408 includes a honeypot storage location access detection task to detect access to data at the storage location of the honeypot file. The task 420 of the data replication manager 408 is a potential attack indication task to indicate a potential attack based on detecting access to data at the storage location of the honeypot file.
[0079] In some examples, the agent 406 is part of a virtual computing entity, such as a VM or a container. The system 400 further includes a driver (e.g., the driver 114 of Figure 1 FIG. 1) for generating block I / O operations corresponding to data transactions of the virtual computing entity. The I / O operations monitored by the data replication manager include block I / O operations.
[0080] Figure 5 FIG. 5 is a flow diagram of a process 500 in accordance with some examples. For example, the process 500 can be performed in the computer system 102.
[0081] The process 500 includes obtaining (at 502), by an agent running in a computer system, a honeypot pattern of data to be stored in a honeypot file. For example, the agent can be the Figure 1 honeypot agent 126 of FIG. 1. The agent can obtain the honeypot pattern by creating the honeypot pattern or receiving the honeypot pattern from another entity.
[0082] The process 500 includes creating (at 504), by the agent, the honeypot file. The created honeypot file contains data according to the honeypot pattern and can be added to a data volume to be protected by a data replication manager.
[0083] The process 500 includes sending (506), by the agent, the honeypot pattern to a data manager. The data manager can store the honeypot pattern in memory. In some examples, the data manager is the data replication manager 118 of Figure 1 FIG. 1.
[0084] The process 500 includes monitoring (at 508), by the data manager, I / O operations to identify data matching the honeypot pattern. The data matching the honeypot pattern can be the object of a single I / O operation or the object of multiple I / O operations.
[0085] The process 500 includes determining (at 510), by the data manager, storage location information associated with the data identified as matching the honeypot pattern, wherein the storage location information identifies a storage location of the honeypot file. The storage location information can include a storage address of the honeypot file.
[0086] The process 500 includes detecting (at 512), by the data manager, access to the data at the storage location of the honeypot file. The access to the data at the storage location of the honeypot file can be performed through one or more I / O operations intercepted by the data manager.
[0087] The process 500 includes indicating (at 514), by the data manager, a potential attack based on detecting the access to the data at the storage location of the honeypot file.
[0088] The storage medium (e.g., the 300 or Figure 3 FIG. 1) for generating block I / O operations corresponding to data transactions of the virtual computing entity. The I / O operations monitored by the data replication manager include block I / O operations.
[0080] Figure 5 FIG. 5 is a flow diagram of a process 500 in accordance with some examples. For example, the process 500 can be performed in the computer system 102.
[0081] The process 500 includes obtaining (at 502), by an agent running in a computer system, a honeypot pattern of data to be stored in a honeypot file. For example, the agent can be the Figure 1 honeypot agent 126 of FIG. 1. The agent can obtain the honeypot pattern by creating the honeypot pattern or receiving the honeypot pattern from another entity.
[0082] The process 500 includes creating (at 504), by the agent, the honeypot file. The created honeypot file contains data according to the honeypot pattern and can be added to a data volume to be protected by a data replication manager.
[0083] The process 500 includes sending (506), by the agent, the honeypot pattern to a data manager. The data manager can store the honeypot pattern in memory. In some examples, the data manager is the data replication manager 118 of Figure 1 FIG. 1.
[0084] The process 500 includes monitoring (at 508), by the data manager, I / O operations to identify data matching the honeypot pattern. The data matching the honeypot pattern can be the object of a single I / O operation or the object of multiple I / O operations.
[0085] The process 500 includes determining (at 510), by the data manager, storage location information associated with the data identified as matching the honeypot pattern, wherein the storage location information identifies a storage location of the honeypot file. The storage location information can include a storage address of the honeypot file.
[0086] The process 500 includes detecting (at 512), by the data manager, access to the data at the storage location of the honeypot file. The access to the data at the storage location of the honeypot file can be performed through one or more I / O operations intercepted by the data manager.
[0087] The process 500 includes indicating (at 514), by the data manager, a potential attack based on detecting the access to the data at the storage location of the honeypot file.
[0088] The storage medium (e.g., the 300 or Figure 3 FIG. 1) for generating block I / O operations corresponding to data transactions of the virtual computing entity. The I / O operations monitored by the data replication manager include block I / O operations.
[0080] Figure 5 FIG. 5 is a flow diagram of a process 500 in accordance with some examples. For example, the process 500 can be performed in the computer system 102.
[0081] The process 500 includes obtaining (at 502), by an agent running in a computer system, a honeypot pattern of data to be stored in a honeypot file. For example, the agent can be the Figure 1 honeypot agent 126 of FIG. 1. The agent can obtain the honeypot pattern by creating the honeypot pattern or receiving the honeypot pattern from another entity.
[0082] The process 500 includes creating (at 504), by the agent, the honeypot file. The created honeypot file contains data according to the honeypot pattern and can be added to a data volume to be protected by a data replication manager.
[0083] The process 500 includes sending (506), by the agent, the honeypot pattern to a data manager. The data manager can store the honeypot pattern in memory. In some examples, the data manager is the data replication manager 118 of Figure 1 FIG. 1.
[0084] The process 500 includes monitoring (at 508), by the data manager, I / O operations to identify data matching the honeypot pattern. The data matching the honeypot pattern can be the object of a single I / O operation or the object of multiple I / O operations.
[0085] The process 500 includes determining (at 510), by the data manager, storage location information associated with the data identified as matching the honeypot pattern, wherein the storage location information identifies a storage location of the honeypot file. The storage location information can include a storage address of the honeypot file.
[0086] The process 500 includes detecting (at 512), by the data manager, access to the data at the storage location of the honeypot file. The access to the data at the storage location of the honeypot file can be performed through one or more I / O operations intercepted by the data manager.
[0087] The process 500 includes indicating (at 514), by the data manager, a potential attack based on detecting the access to the data at the storage location of the honeypot file.
[0088] The storage medium (e.g., the 300 or Figure 3 FIG. 1) for generating block I / O operations corresponding to data transactions of the virtual computing entity. The I / O operations monitored by the data replication manager include block I / O operations.
[0080] Figure 5 FIG. 5 is a flow diagram of a process 500 in accordance with some examples. For example, the process 500 can be performed in the computer system 102.
[0081] The process 500 includes obtaining (at 502), by an agent running in a computer system, a honeypot pattern of data to be stored in a honeypot file. For example, the agent can be the Figure 1 honeypot agent 126 of FIG. 1. The agent can obtain the honeypot pattern byFigure 4 The computer readable or machine-readable storage medium 404 (see also FIG. 4) can include any one or some combination of the following: a semiconductor memory device, such as a dynamic or static random access memory (DRAM or SRAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and flash memory; a magnetic disk; another magnetic medium, including tape; an optical medium, such as a compact disc (CD) or digital versatile disc (DVD); or another type of storage device. It should be noted that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) deemed to be part of an article (or article of manufacture). An article or article of manufacture can refer to one or more computer programs, one or more computer readable storage media, or one or more non-transitory computer readable storage media storing computer readable program instructions that when executed by a machine cause the machine to perform operations. The one or more computer readable storage media can be located either in the machine running the computer readable program instructions, or located at a remote site from which machine readable program instructions can be downloaded over a network for execution by the machine.
[0089] In this disclosure, the terms “a,” “an,” or “the” are intended to include plural, unless the context clearly indicates otherwise. Likewise, the terms “includes,” “including,” “comprises,” and “comprising,” when used in this disclosure, specify the presence of stated elements, but do not preclude the presence or addition of other elements.
[0090] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations can be practiced without some of these details. Other implementations can include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.
Claims
1. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a system to: monitor input / output (I / O) operations to identify data matching a honeypot pattern; determine storage location information associated with the data identified as matching the honeypot pattern; detect access to the data at a storage location indicated by the storage location information; and indicate a potential attack based on detecting access to the data at the storage location indicated by the storage location information.
2. The non-transitory machine-readable storage medium of claim 1, wherein, The monitoring of the I / O operations is performed by a data replication manager that replicates data writes to a replicated data repository.
3. The non-transitory machine-readable storage medium of claim 2, wherein, The instructions, when executed, cause the system to: receive, by the data replication manager, the honeypot pattern from an agent.
4. The non-transitory machine-readable storage medium of claim 3, wherein, The instructions, when executed, cause a system to: create, by the agent, a honeypot file containing data having the honeypot pattern.
5. The non-transitory machine-readable storage medium of claim 4, wherein, The instructions, when executed, cause the system to: identify, by the data replication manager, one or more data volumes to be protected by the data replication manager by replicating data writes to the replicated data repository, wherein the honeypot file created by the agent is in a data volume of the one or more data volumes.
6. The non-transitory machine-readable storage medium of claim 5, wherein, The data writes replicated by the data replication manager include data writes performed by a virtual computing entity protected by the data replication manager.
7. The non-transitory machine-readable storage medium of claim 6, wherein, The agent is executed in the virtual computing entity.
8. The non-transitory machine-readable storage medium of claim 1, wherein, The honeypot pattern includes a random pattern or a specified data pattern.
9. The non-transitory machine-readable storage medium of claim 1, wherein, The indication of the potential attack includes providing a notification of the potential attack and information identifying a latest recovery point of data.
10. The non-transitory machine-readable storage medium of claim 1, wherein, The indication of the potential attack includes providing a notification of the potential attack and write data written to the storage location indicated by the storage location information.
11. The non-transitory machine-readable storage medium of claim 1, wherein, The instructions, when executed, cause the system to: detect a change in a storage location of the data matching the honeypot pattern; based on detecting the change in the storage location, determine whether access to the data matching the honeypot pattern at the changed storage location has occurred; and indicate a potential attack based on detecting access to the data at the changed storage location.
12. The non-transitory machine-readable storage medium of claim 1, wherein, The detected access includes a read access or a write access.
13. The non-transitory machine-readable storage medium of claim 1, wherein, The monitoring of the I / O operations and the determination of the storage location information are performed during an initialization phase of a data protection process, and wherein the detection of the access and the indication of the potential attack are performed during a tracking phase of the data protection process after the initialization phase.
14. A system comprising: a processor resource; a non-transitory storage medium storing machine-readable instructions of an agent and a data replication manager, the agent is executable on the processor resource to: create a honeypot file, and send a honeypot pattern to the data replication manager, the data replication manager is executable on the processor resource to: monitor input / output (I / O) operations to identify data matching the honeypot pattern; determining storage location information associated with the data identified as matching the honeypot pattern, wherein the storage location information identifies a storage location of the honeypot file; detecting access to the data at the storage location of the honeypot file; and indicating a potential attack based on detecting access to the data at the storage location of the honeypot file.
15. The system of claim 14, wherein, The data replication manager is executable on the processor resource to: identify one or more data volumes to be protected by the data replication manager by replicating data writes of the one or more data volumes to a replication data repository, wherein the honeypot file created by the agent is added to a data volume of the one or more data volumes.
16. The system of claim 14, wherein, The storage location information includes a storage address of the honeypot file.
17. The system of claim 14, wherein, The honeypot pattern includes a random pattern created by the agent or a specified data pattern received by the agent.
18. The system of claim 14, wherein, The agent is part of a virtual computing entity, and the system further includes: a driver to generate block I / O operations corresponding to data transactions of the virtual computing entity, wherein the I / O operations monitored by the data replication manager include block I / O operations.
19. A method comprising: obtaining, by an agent running in a computer system, a honeypot pattern for data to be stored in a honeypot file; creating, by the agent, the honeypot file containing data according to the honeypot pattern; sending, by the agent, the honeypot pattern to a data manager; monitoring, by the data manager, input / output (I / O) operations to identify data matching the honeypot pattern; determining, by the data manager, storage location information associated with the data identified as matching the honeypot pattern, wherein the storage location information identifies a storage location of the honeypot file; detecting, by the data manager, access to the data at the storage location of the honeypot file; and indicating a potential attack based on detecting access to the data at the storage location of the honeypot file, wherein the data manager includes a data replication manager that replicates write I / O operations to a replication data repository.
20. The method of claim 19, further comprising: identifying, by the data replication manager, one or more data volumes to be protected by the data replication manager by replicating data writes of the one or more data volumes to the replication data repository, wherein the honeypot file created by the agent is in a data volume of the one or more data volumes, wherein the data writes replicated by the data replication manager include data writes performed by a virtual computing entity protected by the data replication manager, and wherein the agent executes in the virtual computing entity.
Citation Information
Cited By
Honeypot-based attack detection
US20250330493A1