CN114556347A

CN114556347A - System and method for identifying data tampering in a host device

Info

Publication number: CN114556347A
Application number: CN202080068879.7A
Authority: CN
Inventors: 沙哈尔·萨尔兹曼; 阿萨夫·纳塔逊
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-06-30
Filing date: 2020-06-30
Publication date: 2022-05-27
Also published as: WO2022002368A1

Abstract

A system and method for identifying data tampering in a host device is disclosed. The method comprises the following steps: receiving backups of host devices in a backup system at several sequential points in time; extracting data from the received backup of the host device; storing the extracted data of the received backup in an event database of the backup system; scanning the received backup of the stored data to detect an event of tampering of the data in the host device; issuing an indication of the detected event.

Description

System and method for identifying data tampering in a host device

Technical Field

The present invention relates generally to the field of computer security; and more particularly to a method and system for identifying data tampering in a host device.

Background

With the development of information technology, the dependence on computer equipment is increasing day by day. At the same time, computer devices are becoming vulnerable and thus need to be protected from, for example, viruses, trojan horses, worms, spyware and other typesAnd malicious attacks such as malicious software. Often, an attacker may attempt to alter the system files of the operating system in the host device (i.e., tamper with the data). In a host device, during an attack, an attacker may often wish to reinforce the changes made so that they persist during a reboot. Furthermore, the attacker may attempt to delete any logs related to the attack itself and the operations performed during the attack. For example, such operations may include consolidating pairs in a registry

Changes made to the operating system.

Conventional techniques for detecting data tampering in a device rely on the operating system of the device. For example, on some operating systems, blunt (blunt) modification of an event log may generate an event indication, such as clearing the event log, modifying system time, or raising permissions. These modifications can be viewed through event log audits built into most operating systems, or obtained through third parties. In this case, typically, the security researcher and system administrator may recognize that the event ID is not within the sequence, or contains invalid information, indicating a modification. However, there are also tools available such as "DanderSpritz" that can make traceless modifications to the event log. Furthermore, even tools may recover an event while it is still present on disk. It should be noted, however, that such auditing tools run on the host operating system, which makes them vulnerable to attackers, i.e., in addition to the actual changes, the auditing mechanism may be modified or "spoofed" so that it does not notice the changes.

For example,

auditing tools for event logs and registries are built into the operating system, and can identify passivity events, such as clearing event logs or modifying system time, but can be bypassed by tools of various types that can delete a single event. In that

On the operating system, the system log may be protected using file attributes. These properties may even be made immutable if a tool named "lcap" is used within the startup script of the Linux system. A problem with this approach is that it is sensitive to tampering with the underlying storage, i.e. to identifying the physical location of the system log, and to performing changes to the storage.

Other tools are known, such as "Tiny watch" and "MJ Registry watch", which can monitor and alert when a Registry is changed. However, these tools also have disadvantages because they rely on the operating system to call them when the registry changes, which means they are susceptible to being disturbed by attackers, such as corrupting third party tool executables, disabling them, or modifying Windows event logs or event recorders to hide audits on changes. Com, moreover, the fact that Fox-IT (www.fox-it.com) only modifies metadata pointing to an event, with current tools, and does not modify the event itself provides a tool for recovering the event. However, if an attack completely removes the event from the storage of the host device, the tool may not be functional.

Typically, an attacker can bypass all of the tools described above, since they reside on the system being attacked. Thus, in light of the above discussion, there is a need to overcome the above-mentioned shortcomings associated with conventional techniques and methods for identifying data tampering.

Disclosure of Invention

The present invention seeks to provide a class of methods, devices and computer program products for identifying data tampering in a host device. The present invention seeks to provide a solution to the existing problem of providing tools that rely on acting on the tools currently stored by the system to recover or audit system logs, event logs and Windows registries. It is an object of the present invention to provide a solution that at least partially solves the problems encountered in the prior art, which improves the method and system of using a backup service to identify modifications to an operating system and log records and modification recovery, which is not easily bypassed within the system.

The object of the invention is achieved by the solution presented in the attached independent claims. Advantageous implementations of the invention are further defined in the dependent claims.

In a first aspect, the present invention provides a method for identifying data tampering in a host device, wherein the method comprises: receiving backups of host devices in a backup system at several sequential points in time; extracting data from the received backup of the host device; storing the extracted data of the received backup in an event database of the backup system; scanning the received backup of the stored data to detect an event of tampering of the data in the host device; issuing an indication of the detected event.

The method of the first aspect provides: the backup system obtains backups from the host device at regular intervals in order to have a traceable view of the host device in order to detect any changes caused by threats on the host device. Once a threat is detected, the backup system notifies the host device and restores it to its final health state. In this way, the backup system can perform root cause analysis of the threats to ensure that the same threats do not reoccur in the host device.

In one implementation manner of the first aspect, the data extraction is performed by: activating the received backup of the host device as a virtual machine and extracting the data from the activated virtual machine.

The virtual machine provides a separate system to independently perform scanning to detect data tampering in the host device. Execution on the virtual machine is not susceptible to tampered data on the host device. Thus, the virtual machine provides a secure environment that is not easily bypassed within the system.

In one implementation of the first aspect, extracting the data includes extracting a copy of an event log of the host device and a copy of a registry of the host device.

It should be noted that the event log and registry of the host device are used as a record of changes made in the host system. Any unauthorized changes to the event log and/or registry are indicative of data tampering, and thus, a copy of the event log of the host device and a copy of the registry of the host device can be used to identify data tampering.

In one implementation form of the first aspect, the detecting the event is performed by: comparing backup differences between the scan results of the backed up stored data at one of the several sequential points in time and the scan results of the backed up stored data at a point in time prior to the one point in time.

By comparing backup differences between the scan results of the stored data backed up at one point in time and the scan results of the stored data backed up at some point in time before said one point in time, any unauthorized changes of the event log and/or registry of the host device are detected, which in turn can be used to identify data tampering in the host device. Further, the comparison of backup differences may determine the last health status of the host device prior to the data tampering event, and this information may be used to restore the host device to the state prior to the data tampering event.

In one implementation form of the first aspect, the detecting the event is performed by: comparing a first difference between scan results of a first pair of the stored data of the backup at a first two sequential points in time and comparing a second difference between scan results of a second pair of the stored data of the backup at a second two sequential points in time.

Comparing the first and second differences of the backup may identify attack patterns and provide additional information about changes made to the host device by the attack at each point in time.

In one implementation form of the first aspect, the method further comprises: detecting a reinforcement of an attack in a registry of the host device using the first difference and detecting a concealment of the attack in the registry of the host device using the second difference.

Typically, during a network attack, an attacker will attempt to reinforce changes made so that they persist during a reboot, and may attempt to delete any logs that provide evidence of the attack itself and of the operations performed during the attack. By sequential comparison, the time at which such events occur in the host device can be identified by comparing the registry of the host device and the changes in the event log.

In one implementation of the first aspect, detecting the event comprises detecting at least one of: a change to an operating system registry of the host device; a change in an event log of the host device; a change of an event in the host device; a modification of a system time of the host device; a modification of metadata pointing to the event in the host device; malware in the host device; malicious activity in the host device; a reinforcement of an attack in the registry of the host device; a reinforcement of changes made in the system registry of the host device; a concealment of the attack in the host device; and rights elevation.

The listed elements of the host device are most susceptible to alteration during an attack, so detection events related to unauthorized alteration of any of these elements can be used as a reliable indicator of data tampering in the host device.

In one implementation of the first aspect, scanning the backup of the storage data received at several sequential points in time is performed periodically or continuously.

Periodic or continuous scanning of the stored data in the backup may detect any attacks or data tampering in the host device in real-time or near real-time. Further, such periodic or continuous scanning can identify sequential points in time at which a data tampering event occurred in the host device, and can determine to thereby restore the state of the host device prior to the data tampering event.

In one implementation of the first aspect, periodically scanning the storage data includes scanning the storage data of each received backup.

Scanning each received backup facilitates identifying data tampering in the host device in near real-time.

In one implementation of the first aspect, continuously scanning the data comprises scanning the stored data of the received backup over a period of time.

Scanning the received backed up stored data over a period of time may ensure that data tampering events are determined while limiting consumption of processing resources.

In one implementation of the first aspect, the method further comprises constructing an attack profile.

By analyzing the changes made to the host device by the attack, its attack profile can be constructed. The attack profile is constructed to perform post-hoc and performance analysis of attacks to obtain root cause analysis of the attacks so that the host device (and other devices) can be protected from similar types of attacks.

In one implementation of the first aspect, the method further comprises initiating recovery of the tampered data.

The backup system has an original copy of the data before the attack, and by restoring the tampered data using the backup system, the host device can be restored to the state before the attack.

In a second aspect, the present invention provides a system for identifying data tampering in a host device, wherein the system comprises one or more processors; a memory accessible by the one or more processors, wherein the memory includes a database management system, a data extraction engine, a scan engine; and the system is configured to issue an indication of the detected event.

The system of the second aspect achieves all the advantages and effects of the method of the first aspect.

In one implementation of the second aspect, the database management system includes a backup database for receiving a backup of the host device and a database for storing the extracted data.

The backup database and the database provide separate storage units for the received backup of the host device and the extracted data for processing the received backup, respectively, so that the backup can be processed without being affected by an attack on the host device.

In one implementation of the second aspect, the data extraction engine is configured to extract data from the received backup of the host device, the extracted data including a copy of an event log of the host device and a copy of a registry of the host device.

In one implementation of the second aspect, the system further includes a virtual machine engine stored in the memory.

In a third aspect, the present invention provides a computer program for performing the above method of the first aspect when executed on a backup system.

The computer program product of the third aspect achieves all the advantages and benefits of the method of the first aspect or the system of the second aspect.

It should be noted that all devices, elements, circuits, units and modules described in the present application may be implemented in software or hardware elements or any type of combination thereof. All steps performed by the various entities described in the present application and the functions described to be performed by the various entities are intended to indicate that the respective entities are adapted or arranged to perform the respective steps and functions. Even if, in the following description of specific embodiments, a specific function or step to be performed by an external entity is not reflected in the description of a specific detailed element of that entity performing that specific step or function, it should be clear to the skilled person that these methods and functions may be implemented in corresponding software or hardware elements, or any kind of combination thereof. It will be appreciated that features of the invention are susceptible to being combined in various combinations without departing from the scope of the invention as defined by the accompanying claims.

Additional aspects, advantages, features and objects of the present invention will become apparent from the drawings and from the detailed description of illustrative implementations, which is to be construed in conjunction with the appended claims.

Drawings

The foregoing summary, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention. However, the present invention is not limited to the specific methods and instrumentalities disclosed herein. Furthermore, those skilled in the art will appreciate that the drawings are not drawn to scale. Identical components are denoted by the same reference numerals, where possible.

Embodiments of the invention will now be described, by way of example only, with reference to the following figures, in which:

FIG. 1 is a block diagram of a system for identifying data tampering provided by one or more embodiments of the invention;

FIG. 2 is a flow diagram of a method for identifying data tampering in a host device provided by one or more embodiments of the invention;

FIG. 3 is an exemplary illustration of a timeline of a backup for detecting data tampering in a host device provided by one or more embodiments of the invention;

fig. 4 is a block diagram of a system for identifying data tampering in a host device provided by one or more embodiments of the invention.

In the drawings, underlined numbers are used to indicate items on which the underlined numbers are located or items adjacent to the underlined numbers. Non-underlined numbers refer to items identified by lines connecting non-underlined numbers with the items. When a number is not underlined and has an associated arrow, the non-underlined number is used to identify the general item to which the arrow points.

Detailed Description

The following detailed description illustrates embodiments of the invention and the manner in which the embodiments may be practiced. While several modes for carrying out the invention have been disclosed, those skilled in the art will recognize that other embodiments for carrying out or practicing the invention are possible.

FIG. 1 is a block diagram of a system 100 for identifying data tampering in a host device, wherein the system includes one or

more processors

102A, 102B-102N; a memory 104 accessible by the one or more processors, wherein the memory includes a database management system 106, a data extraction engine 108, a scanning engine 110; and the system is operable to issue an indication of the detected event. The memory 104 is used to store a backup of a host device (e.g., the host device 402 of fig. 4 discussed later in the description) received at several sequential points in time in a backup system. In embodiments where an indication of a detected event is issued, the system is operable to receive backups of the host device at several sequential points in time in a backup system; the event database of the database management system of the system is used for storing the received backup extraction data; a data extraction engine of the system is to extract data from the received backup of the host device; the scan engine is used to detect data tampering events in the host device.

Here, the one or

more processors

102A, 102B through 102N relate to computing elements operable to respond to and process instructions that drive the system 100. Examples of one or

more processors

102A, 102B, through 102N may include, but are not limited to, microprocessors, microcontrollers, Complex Instruction Set Computing (CISC) processors, application-specific integrated circuit (ASIC) processors, Reduced Instruction Set (RISC) processors, Very Long Instruction Word (VLIW) processors, Central Processing Units (CPUs), state machines, data processing units, and other processors or circuits. Further, one or more of

processors

102A, 102B, through 102N may refer to one or more individual processors, processing devices, processing units that are part of a machine.

Here, the memory 104 may comprise suitable logic, circuitry, and/or interfaces that may be operable to store machine code and/or instructions having at least one code segment that may be executed by one or more of the

processors

102A, 102B, through 102N. Examples of implementations of memory 104 may include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), flash memory, Secure Digital (SD) card, solid-state drive (SSD), and/or CPU cache. Memory 104 may store an operating system and/or other program products for operating system 100. Memory 104 may include a computer-readable storage medium to provide non-transitory memory that may include, but is not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing.

Database management system 106 is referred to herein as a system for organizing digital information, regardless of the manner in which the data is represented. Alternatively, database management system 106 may be hardware, software, firmware, and/or any combination thereof. Database management system 106 may store relevant data for a host device in the form of a table, map, grid, packet, datagram, file, document, list, or any other form. Database management system 106 includes any data storage software and systems, such as IBM DB2 and Oracle 9 relational databases. Here, as is common in the art, database management system 106 may be used interchangeably herein as a database. Alternatively, database management system 106 may operate to support relational operations regardless of whether it enforces strict adherence to the relational model, as will be appreciated by those of ordinary skill in the art. Database management system 106 is populated by a backup of the host device. Further, data elements may include data records, data bits, cells, used interchangeably herein, and all are intended to represent information stored in a cell of a database. In one embodiment, database management system 106 includes a backup database 112 for receiving a backup of a host device and an event database 114 for storing extracted data.

The data extraction engine 108 is used to extract data from the received backup of the host device, including a copy of the event log of the host device and a copy of the registry of the host device. Alternatively, the data extraction engine 108 may automatically extract data at several sequential points in time. In addition, the data extraction engine 108 may convert the format of the data, making data extraction easier. The data extraction engine 108 is used to collect and retrieve data from the host device for further processing and analysis in real-time or near real-time. In the present invention, the data extraction engine 108 extracts data so that data tampering events in the host device can be identified, as discussed in detail in the following paragraphs.

The scan engine 110 is used to scan the received backed up storage data to detect data tampering events in the host device. Here, the backed up stored data received at several sequential points in time is periodically or continuously scanned. Periodically scanning the storage data includes scanning each received backup of storage data. Continuously scanning the data includes scanning the received backed up stored data after a discrete period of time. In one example, detecting an event is performed by: the backup differences between the scan results of the storage data backed up at one time point of several sequential time points and the scan results of the storage data backed up at a time point before the one time point are compared. In another example, detecting the event is performed by: a first difference between the scan results of the first pair of backed up stored data at a first two sequential points in time is compared and a second difference between the scan results of the second pair of backed up stored data at a second two sequential points in time is compared.

The system 100 also includes a virtual machine engine 116 stored in the memory 104 for allowing one or more virtual machines to run. Here, one or more virtual machines are slave to the host deviceThe rest of the system is sandboxed and a separate platform is created for scanning and detecting data tampering in the host device. Thus, data in the virtual machine cannot be tampered with by an attacker. Thus, data is extracted from the virtual machine. For example, the file archive, Linux reader, and/or virtualization software package (e.g., workstation) may be used

The player) connects the VMDK to the existing virtual machine to extract data from the virtual machine. The data extracted from the virtual machine includes a copy of the event log of the host device and a copy of the registry of the host device. Such data is extracted by the virtual machine because any changes in the event log and registry may provide complete detailed information about the attack or data tampering event.

Fig. 2 is a flow chart of a method 200 for identifying data tampering in a host device provided by an embodiment of the present invention. The method 200 may be performed on the system 100 of fig. 1, as discussed in the following paragraphs. As used herein, the term "data tampering" refers to a security threat faced by a host device, involving altering or editing files stored in the host device, typically causing some form of damage to the host device. Data tampering refers to the act of intentionally modifying, manipulating, or editing data through an unauthorized channel. In view of this, the host device suffers from a security breach, and an unauthorized attacker may deploy malicious code that damages the data or the underlying program code. As described above, the method 200 of the present invention identifies such data tampering in the host device by performing the steps 202-220 listed therein.

In step 202, method 200 includes receiving a backup of a host device in a backup system at several sequential points in time. As discussed, backup database 112 of database management system 106 is used to receive a backup of a host device. In information technology, a backup or data backup is a copy of computer data that is acquired and stored elsewhere for use in restoring the original data following a data loss event. Backup refers to copying physical or virtual files or databases to a secondary location for saving in the event of a device failure or data corruption. The backup of the host device includes all or part of the data stored in the host device. In one example, the information in the backup may include, but is not limited to, an event log of the host device, a registry of the host device, metadata associated with various files, as well as files (e.g., media files), folders, software installed on the host device, and the like. In this example, the backup may include a copy of the block device storing the host device data, such as a copy of a VMware virtual disk file (VDMK), a type of virtual hard disk. A VMDK is a file format that describes a container of virtual hard drives to be used in a virtual machine such as a VMware workstation or a VirtualBox or ESX server. It will be appreciated that the block device represents a lower level of file system loading (where it is located). A copy of the block device may be connected to the virtual machine. The backup system may be viewed as a remote view of the history of the host device. The backup system may be viewed as a remote view of the history of the host device. That is, in a backed up system, the backup system may be viewed as a remote view of the system's history. The backup system may be considered "remote" because it does not reside on primary storage (VMDK data is a file stored on VMFS, which is stored on a Logical Unit (LU) of primary storage). The backup system is not accessible by the virtual machine and therefore is not easily altered by attackers, and is "historical" in that it contains information that the system stores what is presented at several points in time. The sequential point in time at which a backup is received depends on the fixity (nodal) or relevance of the information in the backup. For example, a backup of a host device may be received every hour, every ten hours, every day, or every week.

In step 204, the method 200 includes extracting data from the received backup of the host device. As discussed, the data extraction engine 108 is used to extract data from a received backup of a host device. In this example, data may be extracted from the block device to avoid running a backup agent in the host device. The reason for this is that the backup agent, if executed in the host device, may have obtained the tampered data. This is why the backup is done at a lower level, e.g. at the virtual machine disk level (as described above). It will be appreciated that backups are typically in the form of compressed files. The reason for this is that compressed files take up less storage space and can therefore be transferred between locations more quickly, for example on the internet. In addition, backup provides several files and folders combined into one easy-to-manage software package. The backup system may utilize one or more compression techniques and corresponding extraction techniques to achieve this. Furthermore, in order to perform any form of processing on the data in the backup, it may be necessary to first extract the data from the backup. In some examples, only relevant data that may be helpful in identifying data tampering in the host device is extracted from the received backup. This may ensure a reduction in extraction time and a reduction in system resource consumption.

In one embodiment, extracting the data is performed by activating a received backup of the host device as a virtual machine and extracting the data from the activated virtual machine. Here, a virtual machine is run by the virtual machine engine 116 of the system 100 of FIG. 1. As discussed, the virtual machine is in the form of a stand-alone system sandboxed from the rest of the host device, which provides a separate platform for scanning extracted data to detect data tampering in the host device. Since the virtual machine is an independent system, the data extracted from the backup is not affected by an attack on the host device, and therefore, can be reliably used to identify data tampering in the host device.

In one embodiment, extracting the data includes extracting a copy of an event log of the host device. The event log is a detailed record of system, security, and application notifications stored by the operating system of the host device for use by an administrator of the host device in diagnosing problems in the host device and predicting future problems. For example, the event log may include a trace of specific events in the host device, such as log files, application installation, security management, system setup operations at initial startup, and problems or errors. Further, the event log includes information about: the date and time the data occurred, the user name of the user logged into the host when the event occurred, the identification number specifying the event log, the source that caused the event log, and the type of event log.

Further, extracting the data includes extracting a copy of a registry of the host device. A registry is a database in which all information about hardware and software programs installed on an operating system is stored. The stored data may be in the form of time, location, software settings, options, user preferences, and the like. For example, when a new program is installed on the host device, the sub-entries stored in the registry will be generated. In addition to the information of the program, the sub-items also provide the following information: the time the program was installed on the computer, the location where the program was stored, the version of the program, and other detailed information related to the installed program.

In step 206, the method 200 includes storing the extracted data of the received backup in an event database of the backup system. In the present embodiment, the event database may be equivalent to the event database 114 of the system 100 of FIG. 1. The event database provides a separate storage space from the main storage of the host device. Thus, any attacker ubiquitous in the host device cannot modify or corrupt the extracted event logs and registries stored in the event database.

In step 208, the method 200 includes scanning the received backed up storage data to detect a data tampering event in the host device. As discussed, such scanning of stored data may be performed by the scan engine 110 of the system 100 of fig. 1. Scanning includes checking the backup for any inconsistencies in the data that may indicate any unauthorized changes. For example, a scan is made to determine any unauthorized changes in the extracted copy of the registry (or in portions of the registry) of the host device. In addition, a scan is performed to determine any unauthorized changes in the extracted copy of the event log (or in portions of the event log) of the host device. Any determined unauthorized change in the registry and/or event log is considered to detect data tampering in the host device. By using these techniques, data tampering can be detected in real time or near real time.

In one embodiment, the backed up stored data received at several sequential points in time is periodically or continuously scanned. Periodic or continuous scanning of the stored data in the backup may detect any attacks or data tampering in the host device in real-time or near real-time. Further, such periodic or continuous scanning can identify sequential points in time at which a data tampering event occurred in the host device, and can determine to thereby restore the state of the host device prior to the data tampering event.

In one embodiment, periodically scanning the storage data includes scanning each received backup of storage data. Scanning each received backup helps to immediately identify data tampering in the host device when the active (i.e., new backup) is available for comparison to identify any threats.

In another embodiment, continuously scanning data includes scanning the received backed up stored data over a period of time. This means that the memory scan can be performed continuously between any point in time, thereby achieving continuous data protection. The continuous scan of the stored data may be accomplished using a Client Data Platform (CDP) engine that provides a central location for the received backup. Continuous data protection may preserve every change that occurs in the host device (i.e., changes to I/O are included in the host device's storage disk) and may restore backups (e.g., backups stored in a virtual hard disk or VMware virtual disk file) to any point in time. Thus, scanning the continuous data protection stored data can detect each change that occurs to the registry file, and also facilitate identifying data tampering in the host device in near real-time during the particular time period, and restoring the host device to a state prior to the data tampering.

In one embodiment, detecting the event is performed by: the backup differences between the scan results of the storage data backed up at one time point of several sequential time points and the scan results of the storage data backed up at a time point before the one time point are compared. As discussed, such event detection may be performed in a virtual machine (e.g., a virtual machine of the system 100 of fig. 1). Events are detected by comparing scans of two instant backups in sequential time points. For example, an event is detected by determining a difference between a current state and a previous state of a registry and/or event log. One skilled in the art will appreciate that active threats may be detected in real-time or near real-time by comparing backup differences between scan results of instant backups. In addition, it also provides attack patterns such as a single deletion of an event in an event log, a known change in a registry indicating malware or any other malicious activity in the host device.

Referring now to FIG. 3, an exemplary illustration of a timeline 300 of a backup and data tampering events along a time axis T in a host device provided by an embodiment of the present invention is shown. The timeline 300 shows the beginning of receiving a backup 302 of a host device in a backup system (e.g., the backup system 400 of FIG. 4 discussed later in the description). Here, the backup 302 may be a primary backup of the host device. Further, in the example shown, the backup system receives a total of 7 backups 302A-302G. Respectively, a first backup 302A is received at a first sequential point in time, a second backup 302B is received at a second sequential point in time, and so on until a seventh backup 302G is received at a seventh sequential point in time. The timeline 300 also depicts the beginning of generating an event log 304 for the host device. Event log 304 may be the master event log of the host device. In addition, events such as events 304A-304C are added to the event log 304 over a period of time, depending on activities and changes in the host device. As shown, a first event 304A occurs at some time between the backup system receiving the third backup 302C and the fourth backup 302D, and corresponding changes are recorded in the event log 304. Further, a second event 304B occurs at some time between the backup system receiving the fourth backup 302D and the fifth backup 302E; the third event 304C occurs at some time between the backup system receiving the fifth backup 302E and the sixth backup 302F. In this example, the second event 304B represents an event related to the reinforcement of an attack and the third event 304C represents an event related to the concealment of the same attack.

In one embodiment, detecting the event is performed by: a first difference between the scan results of the first pair of backed up stored data at a first two sequential points in time is compared and a second difference between the scan results of the second pair of backed up stored data at a second two sequential points in time is compared. In conjunction with FIG. 3, the first difference is the difference between the fourth backup 302D and the fifth backup 302E of the backup system. The second event 304B is detected by comparing the first difference, i.e., the difference between the scan results of the fourth backup 302D and the fifth backup 302E of the backup system. Additionally, in conjunction with FIG. 3, the second difference refers to the difference between the fifth backup 302E and the sixth backup 302F of the backup system. A third event 304C is detected by comparing the second difference, i.e., the difference between the scan results of the fifth and

sixth backup

302E, 302F of the backup system.

Referring again to fig. 2, according to one embodiment, method 200 further includes: the first difference is used to detect a reinforcement of the attack in the registry of the host device and the second difference is used to detect a concealment of the attack in the registry of the host device. In general, in the event of any attack, the attack will attempt to harden any changes made in the host device so that the changes made persist during the reboot, and then the attack may attempt to remove any logs that provide evidence of the attack itself and the operations performed during the attack. Here, attack reinforcement in the registry of the host device may increase vulnerabilities of applications, systems, infrastructure, firmware, and other areas in the host device. Furthermore, attack hiding in the registry of the host device makes it difficult to detect attacks. Since such attempts will be logged as events in the event log, and there may be sequential backups before and after each such attempt; by comparing such sequential backups, it can be appreciated that such attempts can be detected.

Referring to FIG. 3, as discussed, the second event 304B represents an event related to the reinforcement of an attack and the third event 304C represents an event related to the concealment of an attack. Here, the first difference, i.e., the difference between the scan results of the fourth backup 302D and the fifth backup 302E of the backup system, results in the detection of the second event 304B, and thus the detection of the reinforcement of the attack. Further, here, the second difference, i.e., the difference between the scan results of the fifth and

sixth backups

302E and 302F of the backup system, results in the detection of the third event 304C, and thus the concealment of the attack.

Referring to FIG. 2, in one embodiment, detecting an event includes detecting a change in an operating system registry of a host device. For example, changes to computer specific information (such as hardware configurations stored in a registry of the host device) are detected. Detecting the event also includes detecting a change in an event log of the host device. For example, a change in an account credential stored in an event log of a host device is detected. Detecting the event also includes detecting a change in the event in the host device. For example, any changes or modifications in the event log are detected. The detection event also includes a system time modification of the host device. For example, modifications in date and/or time associated with any event, which may or may not be related to an attack, such as a database transaction, are detected. Detecting the event also includes modification of metadata directed to the event in the host device. For example, modifications to detailed information (e.g., associated user information, etc.) about a particular event are detected. The detection event also includes malware in the host device. For example, malware is detected, including but not limited to viruses, worms, trojan horses, rootkits, spyware, and keyloggers. The detection event also includes malicious activity in the host device. For example, an event such as an unauthorized person logging on to the host device is detected. Detecting the event also includes attack hardening in a registry of the host device. For example, the reinforcement of attacks in the registry may include, but is not limited to, adding superfluous programs, providing rights and access, giving an attacker the opportunity to gain entry into the host device, and detecting such reinforcement of attacks in the registry. Detecting the event also includes hardening of changes made in a system registry of the host device. For example, any unauthorized registry changes that attempt to be perpetuated are detected. The detection event also includes attack hiding in the host device. For example, an event log of a host device is altered to hide attacks in the host device and detect such alterations. Detecting an event also includes a rights lift. For example, changes associated with allowing unauthorized persons to access host device data are detected.

In step 210, the method 200 includes issuing an indication of the detected event. That is, upon detecting a data tampering event by scanning the received backed up stored data, an indication of the detected event is issued to notify security researchers of the threat to the host device. The indication of the detected event may be issued in the form of one or more of a notification, email, short message, alarm, etc. The indication of the detected event may be issued in real-time or near real-time so that measures may be taken to quickly protect the host device from the detected event. Details of the detected event are also indicated. For example, the issued detected event may include information regarding the deletion of events A, B and C from the event log. In some examples, information regarding the last health status of the host device may also be notified along with the indication.

In one embodiment, method 200 further comprises building an attack profile. The attack profile includes information related to the detection activity, as well as detailed information about changes made in the host device during the attack. The attack profile may be built using backups of the host device received at several consecutive points in time in the backup system. The attack profile is constructed to perform post-incident analysis on the detected event to improve the security of the host device. The attack profile may be stored in the backup system for better analysis in the future. Optionally, post-hoc analysis of detected events may be performed in an isolation sandbox (e.g., a virtual machine) that provides an isolation environment to run and test malicious events related to the host device in order to understand how the events work on the host device.

According to one embodiment, method 100 further comprises initiating recovery of the tampered data. Upon detecting the event, the health state of the host device prior to the event is identified using backups received at several sequential points in time of the host device in the backup system, and the host device is restored to the health state. It will be appreciated that the health of the host device is determined to be the state corresponding to the backup in the host device prior to the occurrence of the data tampering event. In some examples, rebooting the host device may be used to restore the host device to a healthy state.

Steps 202 through 210 are merely illustrative, and other alternatives may be provided in which one or more steps are added, one or more steps are deleted, or one or more steps are provided in a different order without departing from the scope of the claims herein.

Fig. 4 is an exemplary block diagram of a system 100 for identifying data tampering in a host device provided by an embodiment of the present invention. As shown, system 100 is associated with a host device 402. Herein, host device 402 refers to an electronic device associated with (or used by) a user that enables the user to perform certain tasks associated with embodiments of the present invention. Moreover, host device 402 is intended to be broadly construed to include any electronic device that is operable to communicate voice and/or data over a wireless communication network. Examples of host device 402 include, but are not limited to, cellular phones, Personal Digital Assistants (PDAs), handheld devices, wireless modems, notebook computers, personal computers, and the like. Further, host device 402 may include a housing, memory, a processor, a network interface card, a microphone, a speaker, a keyboard, and a display.

As shown, host device 402 includes memory 404. Herein, memory 404 refers to a computer-readable storage medium that may store an operating system and/or other program products of host device 402. That is, memory 404 may be any computer-readable storage medium, such as an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. Examples of memory 404 may include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), flash memory, Secure Digital (SD) card, solid-state drive (SSD), and/or CPU cache. The memory 404 of the host device 402 may temporarily store the backup generated by the host device 402 prior to being transferred to and/or executed by the inventive system 100.

As shown, the system 100 includes a backup system 400. The backup system 400 communicates with the memory 404 of the host device 402 to receive a backup of the host device 402 therefrom. Here, backup system 400 incorporates backup database 112 and event database 114 of system 100. Here, backup database 112 stores backups of host device 402, including a first backup 408A, a second backup 408B, a third backup 408C, through an nth backup 408N of host device 402. Here, the backups 408A-408N are received at several sequential points in time in the backup database 112.

As discussed herein, backup database 112 includes a first backup 408A, a second backup 408B, a third backup 408C through an nth backup 408N of host device 402 that may be received at several sequential points in time. The several sequential points in time may be any suitable time period, such as an hour, a day, two weeks, or a month, depending on the fixity or relevance of the backup, e.g., depending on the frequency with which the backup is required to be performed according to the corresponding backup strategy. In one example, a first backup 408A may be received by backup database 112 on a first day, a second backup 408B may be received by backup database 112 on a second day, a third backup 408C may be received by backup database 112 on a third day, and so on.

Here, for example, the virtual machine engine 116 may be a physical computer having an independent operating system that provides a separate platform from the host 402 in which the process for identifying data tampering can be independently run. Further, event database 114 provides a collection of records related to the operating system of host device 402 regardless of the manner in which the data is represented. In general, the event database 114 may be in the form of a table, map, grid, packet, datagram, file, document, list, or any other form. Alternatively, event database 114 may be hardware, software, firmware, and/or any combination thereof. The backup system 400 also incorporates a virtual machine engine 116. Here, for example, the virtual machine engine 116 is a physical computer having an independent operating system that provides a separate platform from the host 402 in which a process for identifying data tampering can be independently executed.

In operation, backup database 112 receives first backup 408A, second backup 408B, third backup 408C, through Nth backup 408N of host device 402 at several sequential points in time. The several sequential points in time may vary depending on the fixity or relevance of the backups in the backup database 112. Backup database 112 periodically internally loads copies of

backups

408A, 408B, 408C through 408N and then transfers these copies to virtual machine engine 116. The backup may include information related to the host device 402 such as an operating system, installed software, folders, media, event logs, registries, and the like.

As discussed, extracting data is performed by activating a received backup of host device 402 as virtual machine engine 116 and extracting data from the activated virtual machine engine 116. The virtual machine engine 116 is sandboxed from the rest of the host device and creates a separate platform for scanning and detecting data tampering in the host device. Thus, the data in the virtual machine engine 116 cannot be tampered with by an attacker. Thus, data is extracted from the virtual machine engine 116. For example, the file archive, Linux reader, and/or virtualization software package (e.g., workstation) may be used

The player) connects the VMDK to the existing virtual machine to extract data from the virtual machine engine 116. The data extracted from the active virtual machine engine 116 includes a copy of the host device's event log and a copy of the host device's registry. Such data is extracted by the virtual machine engine 116 because any changes in the event log and registry may provide complete detailed information about the attack or data tampering event.

The data extracted by the virtual machine engine 116 is then stored in the event database 114. The data stored in the event database 114 is then scanned to detect data tampering events in the host device 402. To detect an event, backup differences between two consecutive backed up data are compared. For example, backup 408B is compared to backup 408A to detect events that occur at the time between receiving backup 408B and backup 408A. Similarly, backup 408C is compared to backup 408B to detect events that occur at the time between receiving backup 408B and backup 408C.

In this embodiment, the backup system 400 alerts an administrator of the host device 402 if an event is detected at any sequential point in time. The backup system 400 also provides root cause analysis of detected events to protect the host device 402 from similar events in the future. In addition, the host device 402 is restored to the last health state detected by scanning the data stored in the event database 114. For example, if an event is detected in backup 408C, host device 402 is restored to a state prior to backup 408C, such as the state of host device 402 at backup 408B, which is the health state of host device 402.

In the system 100, the host device 402 is first periodically or continuously backed up in the backup system 400. Backup system 400 will periodically load a copy of host device 402 internally as a virtual machine. Here, each backup image will be scanned if the backup is periodic, and each time period will be checked if the backup is continuous. The backup system 400 will then run the tools that extract the data from the running virtual machine engine 116. This includes extracting a copy of the event log using an event log tool, and extracting a registry. The backup system 400 then stores the extracted data in the event database 114 and scans the registry or event log for differences between the current state and the previous state. In addition, the backup system 400 will alert the administrator in the event of a problem. The system will provide root cause analysis and recover the tampered parts (i.e., data) of the host device 402.

The present invention also provides a computer program for performing the above-described method when executed on a backup system 400 (e.g., the backup system 400 of fig. 4). Such computer products for identifying data tampering in a host device (e.g., host device 402) may include, but are not limited to, electronic memory devices, magnetic memory devices, optical memory devices, electromagnetic memory devices, semiconductor memory devices, or any suitable combination of the foregoing.

The system and method of the present invention provides a secure and traceable view of host devices over time to allow system administrators and security researchers to get notifications of active threats in near real-time and perform post hoc and performance analysis of threat progression. In this implementation, sensitive components of the system, such as the Windows registry or system log, are backed up for a short interval and, after backup, these components are scanned inside the backup system (using backup system resources so the host is not affected by these scans). The results of these scans are then compared to previous results and typical attack patterns are identified, such as a single deletion of an event in an event log, a known change in a registry indicating malicious activity in the malware or system. The sensitivity of the backup system to such events may in fact be fine-tuned according to the fixedness or relevance of the backup system in these scans, e.g., to notify any changes in the registry, or any changes in portions of the registry where the user is not entitled to perform any such changes. Upon detecting a threat, the backup system may notify a system administrator. The notification may include information about the last health system state, as well as details of the detected threat, such as removing events A, B and C from the event log.

Modifications may be made to the embodiments of the invention described above without departing from the scope of the invention as defined in the accompanying claims. Expressions such as "comprising," "combining," "having," "being/being," and the like, used to describe and claim the present invention are intended to be interpreted in a non-exclusive manner, i.e., in a manner that allows items, components, or elements not expressly described to be present. Reference to the singular is also to be construed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. The word "optionally" as used herein means "provided in some embodiments and not provided in other embodiments". It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as any other described embodiment of the invention.

Claims

1. A method (200) for identifying data tampering in a host device (402), the method comprising:

receiving backups (408A-408N) of host devices in a backup system (400) at several sequential points in time;

extracting data from the received backup of the host device;

storing the extracted data of the received backup in an event database (114) of the backup system;

scanning the received backup of the stored data to detect an event of tampering of the data in the host device;

issuing an indication of the detected event.

2. The method (200) of claim 1, wherein extracting the data is performed by:

activating the received backup (408A-408N) of the host device (402) as a virtual machine;

extracting the data from the activated virtual machine.

3. The method (200) according to claim 1 or 2, wherein extracting the data comprises extracting

A copy of an event log of the host device (402);

a copy of a registry of the host device.

4. The method (200) according to any one of claims 1 to 3, wherein detecting the event is performed by: comparing backup differences between the scan results of the stored data of the backup (408A-408N) at one of the several sequential points in time and the scan results of the stored data of the backup at a point in time prior to the one point in time.

5. The method (200) according to any one of claims 1 to 3, wherein detecting the event is performed by: comparing a first difference between scan results of the stored data of a first pair of the backups (408A-408N) at a first two sequential points in time, and comparing a second difference between scan results of the stored data of a second pair of the backups (408A-408N) at a second two sequential points in time.

6. The method (200) of claim 5, further comprising: detect a reinforcement of an attack in a registry of the host device (402) using the first difference and detect a concealment of the attack in the registry of the host device using the second difference.

7. The method (200) of any of the preceding claims, wherein detecting the event comprises detecting

A change to an operating system registry of the host device (402);

a change in an event log of the host device;

a change of an event in the host device;

a modification of a system time of the host device;

a modification of metadata pointing to the event in the host device;

malware in the host device;

Malicious activity in the host device;

a reinforcement of an attack in the registry of the host device;

a reinforcement of changes made in the system registry of the host device;

a concealment of the attack in the host device; or

And (5) authority is promoted.

8. The method (200) of any of the preceding claims, wherein scanning the stored data of the backups (408A-408N) received at several sequential points in time is performed periodically or continuously.

9. The method (200) of claim 8, wherein periodically scanning the stored data comprises scanning the stored data of each received backup (408A-408N).

10. The method (200) of claim 8, wherein continuously scanning the data comprises scanning the stored data of the received backup (408A-408N) over a period of time.

11. The method (200) of any of the preceding claims, further comprising constructing an attack profile.

12. The method (200) of any of the preceding claims, further comprising initiating recovery of the tampered data.

13. A system (100) for identifying data tampering in a host device (402), the system comprising:

one or more processors (102A-102N);

a memory (104) accessible by the one or more processors, wherein the memory comprises

A database management system (106);

a data extraction engine (108);

a scan engine (110);

wherein the system is configured to issue an indication of the detected event.

14. The system (100) of claim 13, wherein the database management system (106) comprises

A backup database (112) for receiving a backup (408A-408N) of a host device (402);

an event database (114) for storing the extracted data.

15. The system (100) of claim 13, wherein the data extraction engine (108) is configured to extract data from the received backup (408A-408N) of the host device (402), the data comprising

A copy of an event log of the host device;

a copy of a registry of the host device.

16. The system (100) of any of claims 13 to 15, further comprising a virtual machine engine (116) stored in the memory (104).

17. A computer program for performing the method (200) according to claim 1 when executed in a backup system (400).