WO2022002368A1

WO2022002368A1 - System and method for identifying data tampering in host device

Info

Publication number: WO2022002368A1
Application number: PCT/EP2020/068392
Authority: WO
Inventors: Shahar SALZMAN; Assaf Natanzon
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-06-30
Filing date: 2020-06-30
Publication date: 2022-01-06
Also published as: CN114556347A

Abstract

A system and method for identifying a data tampering in a host device is disclosed. The method comprises receiving at several sequential points in time a backup of a host device in a backup system, extracting a 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 stored data of the received backup for detecting an event of the data tampering in the host device and issuing an indication of the detected event.

Description

SYSTEM AND METHOD FOR IDENTIFYING DATA TAMPERING IN HOST DEVICE

TECHNICAL FIELD

The present disclosure relates generally to the field of computer security; and more specifically, to methods and systems for identifying data tampering in a host device.

BACKGROUND

With the developments in information technology, the dependence on computer devices is increasing day-by-day. At the same time, the computer devices are becoming vulnerable and need protection from malicious attacks such as viruses, Trojan horses, worms, spyware, and other types of malware. Typically, a perpetrator of the attack may try to change system files of an operating system (i.e. tamper data) in a host device. In the host device, during the attack the perpetrator may, generally, want to harden the changes made so that those changes will persist across reboot. In addition, the perpetrator may attempt to get rid of any logs related to the attack itself and the actions performed during the attack. For example, such actions may include the hardening of changes made in Windows® operating system in the registry.

Conventional techniques used to detect data tampering in a device rely on operating system of the device. For instance, blunt modification of event logs on some operating systems generate an event indication, for example clearing of the event logs, modification of system time, or elevation of privileges. These modifications are viewable by event log audits, which are built-in to most operating systems, or available by third party. In such case, typically, security researchers and system administrators can identify that event IDs are out of sequence, or contain invalid information, which is an indication of modification. But there are tools available like “DanderSpritz” which allow traceless modifications of event logs. Further, there are tools available to even recover an event in the case that it still exists on disk. However, it is to be noted that such audit tools are run on the host operating system which makes them vulnerable to the attacker, i.e. in addition to the actual changes, audit mechanism can be modified or “tricked” to not notice the changes. For example, Windows® operating system has built in audit tools for the event log and registry which can identify blunt events such as clearing of the event log, or modification of system times, but these can be bypassed by types of tools that can remove a single event.

On Linux® operating system, system logs can be protected using file attributes. A tool named “leap" can even make these attributes immutable if used within the startup scripts of a Linux system. The problem with this approach is that it is sensitive to tampering with the underlying storage, i.e. identifying the physical location of the system logs, and performing changes to the storage.

Some other tools are known, such as “Tiny Watcher”, and “MJ Registry Watcher” which allow monitoring and alerting when the registry is changed. However, these tools also have downside in that they rely on the operating system to invoke them upon registry changes, which means that they are prone to the attacker interfering with their operation, e.g. corrupting the third-party tool executables so that they do not function properly, or modifying Windows event log or event logger to hide the audit of the changes. Further, there is a tool provided by Fox-IT (www.fox-it.com) for recovering events using the fact that current tools only modify the metadata pointing to the event, but not the event itself. But this may not be not useful if the attack removes the event entirely from storage of the host device.

In general, all of the above-mentioned tools can be bypassed by the attacker since those tools reside on the system being attacked. Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with conventional technologies and methods for identification of data tampering.

SUMMARY

The present disclosure seeks to provide methods, devices, and a computer program product for identifying data tampering in a host device. The present disclosure seeks to provide a solution to the existing problem with tools, which rely on tools acting on the current storage of the system to recover or audit the system logs, event logs and Windows registry. An aim of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in prior art, and provides improved methods and systems that use a backup service to identify modification and recovery of modifications to operating system modifications and logging, which is not prone to bypass from within the system. The object of the present disclosure is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

In a first aspect, the present disclosure provides a method for identifying a data tampering in a host device, wherein the method comprises receiving at several sequential points in time a backup of a host device in a backup system; extracting a 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 stored data of the received backup for detecting an event of the data tampering in the host device; issuing an indication of the detected event.

The method of the first aspect provides that the backup system obtains backup from the host device at regular intervals of time so as to have a traceable view of the host device in order to detect any changes caused by a threat thereon. Once the threat is detected, the host device is notified and restored to the last healthy state by the backup system. This way the backup system is able to provide root-cause analysis of the threat to ensure the same threat does not reoccur in the host device.

In an implementation form of the first aspect, extraction of the data 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 execute scans for detecting the data tampering in the host device. The execution on the virtual machine is not prone to be affected by the tampered data on the host device. Hence, the virtual machine provides a secure environment which is not prone to bypass from within the system.

In an implementation form of the first aspect, extraction of the data comprises extracting a copy of an event log of the host device and a copy of a registry of the host device.

It is to be noted that the event logs and the registry of the host device act as record of changes made in the host system. Any unauthorized change in the event log and/or the registry is an indication of data tampering, and thus the copy of the event log of the host device and the copy of the registry of the host device can be used to identify data tampering.

In an implementation form of the first aspect, detection of the event is performed by comparing a backup differences between the scanning results of the stored data of the backup at one point in time of the several sequential points in time and the scanning results of the stored data of the backup at a point in time preceding the one point in time. By comparing the backup differences between scanning results of the stored data of the backup at one point in time with the stored data of the backup at the point in time preceding the one point in time, any unauthorized change in the event log and/or the registry of the host device is detected, which in turn can be used to identify data tampering in the host device. Further, comparison of the backup differences allows to determine last healthy state of the host device before data tampering event, and this information can be used to restore the host device to its state prior to the data tampering event.

In an implementation form of the first aspect, detection of the event is performed by comparing a first differences between the scanning results of the stored data of a first pair of the backups at first two sequential points in time and comparing a second differences between the scanning results of the stored data of a second pair of the backups at second two sequential points in time.

Comparing the first difference and the second difference of the backups allows to identify attack patterns and provides additional information related to changes made by attack on the host device at each point of time.

In an implementation form of the first aspect, the method further comprises using the first difference for detecting a hardening of an attack in a registry of the host device and using the second difference for detecting a hiding of the attack in the registry of the host device.

Typically, during a cyber-attack the perpetrator tries harden the changes made so that they will persist across reboot, and, in addition, may attempt to get rid of any logs supplying evidence of the attack itself, and the actions performed during the attack. By sequential comparison, it can be identified when such events took place in the host device by comparing changes in the registry and the event logs of the host device.

In an implementation form of the first aspect, detection of the event comprises at least one of detecting a change in an operating system registry of the host device; a change in an event log of the host device; a change in an event in the host device; a modification of system times of the host device; a modification of a metadata pointing to the event in the host device; a malware in the host device; a notorious activity in the host device; a hardening of an attack in the registry of the host device; a hardening of the change made in the system registry of the host device; a hiding of the attack in the host device; and an elevation of privileges. The listed elements of the host device are most vulnerable to be changed during an attack, and therefore detecting event related to an unauthorized change in any of these elements can be used as a reliable indicator of data tampering in the host device.

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

Periodic or continuous scanning of the stored data in the backup allows to detect any attack or data tampering in the host device in real-time or near real-time. Further, such periodic or continuous scanning enables to identify sequential point in time at which the data tampering event took place in the host device and allows to determine, and thereby restore, the state of the host device prior to the data tampering event.

In an implementation form of the first aspect, scanning the stored data periodically comprises scanning the stored data of the each received backup.

Scanning each received backup helps to identify data tampering in the host device in near real-time.

In an implementation form of the first aspect, scanning the data continuously comprises scanning the stored data of the received backups in a period of time.

Scanning the stored data of the received backups in a period of time ensures that the data tampering event is determined, while limiting the consumption of processing resources.

In an implementation form of the first aspect, the method further comprises building an attack profile.

By analysing the changes made by the attack on the host device, its attack profile can be built. The attack profile is built to perform post mortem analysis and profiling of the attack to obtain root cause analysis of the attack so that the host device (and other devices) can be made immune to similar types of attack in future.

In an implementation form of the first aspect, the method further comprises initiating a restore of the tampered data.

By restoring the tampered data using the backup system which would have original copy of the data before the attack, the host device can be restored to a state prior to the attack.

In a second aspect, the present disclosure provides a system for identifying a data tampering in a host device, wherein the system comprising one or more processors; a memory accessible by the one or more processors, wherein the memory comprises a database management system, a data extracting engine, a scanning engine; and wherein 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 an implementation form of the second aspect, the database management system comprises a backup database adapted to receive backups of a host device and a database for storing extracted data.

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

In an implementation form of the second aspect, the data extracting engine is configured to extract data from the received backups of the host device comprising a copy of an event log of the host device and a copy of a registry of the host device.

In an implementation form of the second aspect, the system further comprises a virtual machine engine stored in the memory.

In a third aspect, the present disclosure provides a computer program adapted to perform the aforementioned method of the first aspect when executed on a backup system.

The computer program product of the third aspect achieves all the advantages and effects of the method of the first aspect, or the system of second aspect. It has to be noted that all devices, elements, circuitry, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

Additional aspects, advantages, features and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The summary above, 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 present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

FIG. 1 is a block diagram of a system for identifying data tampering, in accordance with one or more embodiments of the present disclosure;

FIG. 2 is a flowchart of a method for identifying data tampering in a host device, in accordance with one or more embodiments of the present disclosure; FIG. 3 is an exemplary illustration of a timeline of backups to be used for detecting data tampering in a host device, in accordance with one or more embodiments of the present disclosure; and

FIG. 4 is a block diagram of the system being implemented for identifying the data tampering in a host device, in accordance with one or more embodiments of the present disclosure.

In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the non- underlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.

DETAILED DESCRIPTION OF EMBODIMENTS

The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.

FIG. 1 is a block diagram of a system 100 for identifying a data tampering in a host device, in accordance with an embodiment of the present disclosure, wherein the system comprises one or more processors 102A, 102B-102N; a memory 104 accessible by the one or more processors, wherein the memory comprises a database management system 106, a data extracting engine 108, a scanning engine 110; and wherein the system is configured to issue an indication of the detected event. The memory 104 is configured to store in a backup system the backups of a host device (such as, host device 402 of FIG. 4 as discussed later in the description) received at several sequential points in time. In the embodiment to issue an indication of the detected event the system is configured to receive in the backup system at several sequential points in time the backups of the host device, the event database of the database management system of the system is configured to store the extracted data of the received backups, the data extracting engine of the system is configured to extract the data from the received backups of the host device, the scanning engine is configured to detect an event of the data tampering in the host device. Herein, the one or more processors 102A, 102B to 102N relates to computational elements that are operable to respond to and process instructions that drive the system 100.

Examples of the one or more processors 102A, 102B to 102N may include, but is not limited to a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a central processing unit (CPU), a state machine, a data processing unit, and other processors or circuits. Moreover, the one or more processors 102A, 102B to 102N may refer to one or more individual processors, processing devices, a processing unit that is part of a machine.

Herein, the memory 104 may include suitable logic, circuitry, and/or interfaces that may be configured to store machine code and/or instructions with at least one code section executable by the one or more processors 102A, 102B to 102N. Examples of implementation of the 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, a Secure Digital (SD) card, Solid- State Drive (SSD), and/or CPU cache memory. The memory 104 may store an operating system and/or other program products to operate the system 100. The memory 104 may include a computer readable storage medium for providing a non-transient memory which may include, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Herein, the database management system 106 relates to an organized system of digital information regardless of the manner in which the data is represented. Optionally, the database management system 106 may be hardware, software, firmware and/or any combination thereof. The database management system 106 may store the related data of a host device in the form of a table, a map, a grid, a packet, a datagram, a file, a document, a list or in any other form. The database management system 106 includes any data storage software and systems, such as, for example, a relational database like IBM DB2 and Oracle 9. Optionally, the database management system 106 may be used interchangeably herein as database, as is common in the art. Optionally, the database management system 106 may be operable to supports relational operations, regardless of whether it enforces strict adherence to the relational model, as understood by those of ordinary skill in the art. The database management system 106 is populated by the backup of the host device. Furthermore, the data elements may include data records, bits of data, cells, are used interchangeably herein and all intended to mean information stored in cells of a database. In an embodiment, the database management system 106 comprises a backup database 112 adapted to receive backups of the host device and an event database 114 for storing extracted data.

The data extracting engine 108 is configured to extract data from the received backups of the host device including a copy of an event log of the host device and a copy of a registry of the host device. Optionally, the data extracting engine 108 may extract the data automatically at the several sequential points in time. Further, data extracting engine 108 may convert format of the data so that extraction of the data becomes easier. The data extracting engine 108 is configured to gather and retrieve data from the host device for further processing and analysis in real-time or near real-time. In the present disclosure, the data extracting engine 108 extract the data so that event of data tampering may be identified in the host device, as will be discussed in the proceeding paragraphs in detail.

The scanning engine 110 is configured to scan the stored data of the received backup for detecting an event of the data tampering in the host device. Herein, scanning the stored data of the backup received at several sequential points in time is performed periodically or continuously. Scanning the stored data periodically comprises scanning the stored data of the each received backup. Scanning the data continuously comprises scanning the stored data of the received backups after discrete periods of time. In one example, detecting the event is performed by comparing a backup differences between the scanning results of the stored data of the backup at one point in time of the several sequential points in time and the scanning results of the stored data of the backup at a point in time preceding the one point in time. In another example, detecting the event is performed by comparing a first differences between the scanning results of the stored data of a first pair of the backups at first two sequential points in time and comparing a second differences between the scanning results of the stored data of a second pair of the backups at second two sequential points in time.

The system 100 further comprises a virtual machine engine 116 stored in the memory 104 for enabling to run one or more virtual machines. Herein, the one or more virtual machine are sandboxed from the rest of the host device and creates a separate platform for scanning and detecting for the data tampering in the host device. Thus, the data in the virtual machine cannot be tampered by the attacker. Hence, the data is extracted from the virtual machine. For example, the data may be extracted from the virtual machine by attaching a VMDK to an Existing Virtual Machine, using a file archiver, Linux reader and/or a virtualization software package, e.g. the player of the workstation VMware®. The data extracted from the virtual machine comprises the copy of an event log of the host device and the copy of a registry of the host device. Such data is extracted by the virtual machine as any change in the event log and registry may provide complete details about the attack or event of data tampering.

FIG. 2 is a flowchart of a method 200 for identifying a data tampering in a host device, in accordance with an embodiment of the present disclosure. The method 200 may be executed on the system 100 of FIG. 1, as discussed in the proceeding paragraphs. Herein, the term “data tampering” refers to a security threat faced by the host device and involves changing or editing of files stored in the host device, to generally cause some form of harm to the host device. Data tampering is that act of deliberately modifying, manipulating or editing data through unauthorized channels. Herein, the host device suffers a security breach and an unauthorized perpetrator could deploy malicious code that corrupts the data or underlying programming code. As mentioned above, the method 200 of the present disclosure identifies such data tampering in the host device by performing the listed steps 202- 220 therein.

At step 202, the method 200 comprises receiving at several sequential points in time a backup of a host device in a backup system. As discussed, the backup database 112 of the database management system 106 is adapted to receive backups of the host device. In information technology, a backup, or data backup is a copy of computer data taken and stored elsewhere so that it may be used to restore the original after a data loss event.

Backup refers to the copying of physical or virtual files or databases to a secondary location for preservation in case of equipment 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, event log of the host device, registry of the host device, metadata related to various files; in addition to files (such as media files), folders, installed software on the host device, and the like. In the present examples, the backup may include a copy of a block device that stores the data of the host device, for example a copy of a VMware virtual disk file (VDMK), a virtual hard disk. Herein, VMDK is a file format that describes containers for virtual hard disk drives to be used in virtual machines like VMware Workstation or VirtualBox or ESX server. It may be understood that the block device represents a lower level on which the file system is mounted (sits on). The copy of the block device may be attached to the virtual machine. The backup system may be seen as a remote view of the history of the host device. The backup system may be seen as a remote view of history of the host device. That is, in a system which is backed up, the backup system can be seen as a remote view of the history of the system. It may be considered “remote,” since it does not reside on the primary storage (the VMDK data is a file stored on a VMFS which is stored on a logical unit LU of the primary storage). It is not accessible by the virtual machine and so not prone to changes by the attacker, and “historical,” since it contains information how the storage of the system looked like in several points in time. The sequential points in time for receiving the backup depends upon how pedantic or relevant is the information in the backup. For instance, the backup of the host device may be received every one hour, ten hours, one day or weekly.

At step 204, the method 200 comprises extracting a data from the received backup of the host device. As discussed, the data extracting engine 108 is configured to extract data from the received backups of the host device. In the present examples, the data may be extracted from the block device to avoid running a backup agent in the host device. It is done so since the backup agent, if executed in the host device, may already get the tampered data. It is the reason that the backup is made at a lower level, for example at the virtual machine disk level (as explained above). It may be understood that the backup is typically in the form of a compressed file. It is done so since the compressed file takes up less storage space, and thus can be transferred faster between locations e.g. on the Internet. Further, the backup provides that several files and folders are combined into one package that is easy to manage. The backup system may utilize one or more compression and corresponding extraction techniques for achieving the purpose. Further, for performing any form of processing of the data in the backup, it may be necessary to first extract the data from the backup. In some examples, only relevant data which may help to identify the data tampering in the host device is extracted from the received backup. This ensures reduced extraction time and less consumption of system resources.

In an embodiment, extracting the data is performed by activating the received backup of the host device as a virtual machine and extracting the data from the activated virtual machine. Herein, the virtual machine run by the virtual machine engine 116 of the system 100 of FIG.

1. As discussed, the virtual machine is in the form of an independent system sandboxed from the rest of the host device, which provides a separate platform for scanning of the extracted data for detecting the data tampering in the host device. With the virtual machine being an independent system, the extracted data from the backup is not affected by the attack on the host device, and thus, can be reliably used for identification of data tampering in the host device.

In an embodiment, extracting the data comprises 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 that is used by administrator of the host device to diagnose problems and predict future issues in the host device. For example, event log may comprise tracks of specific events in the host device such as log files, application installations, security management, system setup operations on initial start up, and problems or errors. Further, the event log comprises information about date and time at which the data occurred, username of a user logged onto the host machine when the event occurred, identification number that specifies the event log, source that caused that event log and the type of event log.

Further, extracting the data comprises extracting a copy of a registry of the host device. The registry is a type of database wherein all the information regarding the hardware and the software programmes installed on the operating system is stored. The data stored may be in the form of time, location, settings for software, options, user preferences and the like. For example, when a new program is installed on the host device, a subkey is generated that is stored in the registry. Along with the information of the program, the subkey also gives information of the time at which the program is installed on the computer, location where the program is stored, the version of the program and other details related to the installed program.

At step 206, the method 200 comprises storing the extracted data of the received backup in an event database of the backup system. In the present embodiments, the event database may be equivalent to the event database 114 of the system 100 of FIG. 1. The event database provides a storage space separated from primary storage of the host device. Therefore, the extracted event logs and registry stored in the event database cannot be modified or compromised by any attacker prevalent in the host device.

At step 208, the method 200 comprises scanning the stored data of the received backup for detecting an event of the data tampering in the host device. As discussed, such scan of the stored data may be executed by the scanning engine 110 of the system 100 of FIG. 1. The scan involves checking the backup for any inconsistencies in the data which may be indicative of any unauthorized change. For example, scanning is done to determine any unauthorised change in the copy of the registry as extracted (or in parts of the registry) of the host device. Further, scanning is done to determine any unauthorised change in the copy of the event log as extracted (or in parts of the event log) of the host device. Any determined unauthorised change in the registry and/or the event log is considered as detection of data tampering in the host device. By using such techniques, the data tampering can be detected in real-time or near real-time.

In an embodiment, scanning the stored data of the backup received at several sequential points in time is performed periodically or continuously. Periodic or continuous scanning of the stored data in the backup allows to detect any attack or data tampering in the host device in real-time or near real-time. Further, such periodic or continuous scanning enables to identify sequential points in time at which the data tampering event took place in the host device and allows to determine, and thereby restore, state of the host device prior to the data tampering event.

In one embodiment, scanning the stored data periodically comprises scanning the stored data of the each received backup. Scanning each received backup helps to identify data tampering in the host device as soon as there is a source (i.e. new backup) available for making the comparison to identify any threats.

In another embodiment, scanning the data continuously comprises scanning the stored data of the received backups in a period of time. This means that scanning of the storage can be performed continuously between any points in time, which enables continues data protection. Continuous scanning of the stored data may be done using a customer data platform (CDP) engine that provides a central location for the received backups. Continuous data protection allows to keep every change that occurs in the host device (i.e., in the storage disk of the host device, including changes in I/O) and allows to restore the backup (for example, the backup stored in the virtual hard disk or VMware virtual disk file) to any point in time. Thus, scanning of the continuous data protection stored data enables detecting every change that happened to the registry files, and further helps to identify data tampering in the host device in near real-time for that particular period of time and restore the host device to the state prior to the data tampering.

In an embodiment, detecting the event is performed by comparing a backup differences between the scanning results of the stored data of the backup at one point in time of the several sequential points in time and the scanning results of the stored data of the backup at a point in time preceding the one point in time. As discussed, such event detection may be executed in a virtual machine (such as, the virtual machine of the system 100 of FIG. 1). The event is detected by comparing scans of two immediate backups in the sequential points in time. For example, the event is detected by determining differences between a current state and a previous state of the registry and/or the event log. It will be contemplated by a person skilled in the art that by comparing the backup differences between the scanning results of immediate backups allows to detect active threats in real-time or near real-time. Further, it provides attack patterns such as singular removal of events in the event logs, known changes in the registry indicating malware or any other notorious activity in the host device.

Referring now to FIG. 3, shown is an exemplary illustration of a timeline 300 of backups and the event of the data tampering in the host device along a time axis T, in accordance with an embodiment of the present disclosure. The timeline 300 shows the start of receiving of the backup 302 of the host device in a backup system (such as, a backup system 400 of FIG. 4 as discussed later in the description). Herein, the backup 302 may be a master backup of the host device. Further, in the illustrated example, a total of seven number of backups 302A-302G are received by the backup system. 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 up to a seventh backup 302G which is received at a seventh sequential point in time, respectively. The timeline 300 further depicts starting of generation of event log 304 of the host device. The event log 304 may be a master event log of the host device. Further, events, such as events 304A-304C are added to the event log 304 over a period of time based on activities and changes in the host device. As shown, a first event 304A has occurred sometime between when the third backup 302C and the fourth backup 302D is received by the backup system, and corresponding change is recorded in the event log 304. Further, a second event 304B occurs sometime between when the fourth backup 302D and the fifth backup 302E is received by the backup system; and a third event 304C occurs sometime between when the fifth backup 302E and the sixth backup 302F is received by the backup system. In the present example, the second event 304B represents an event related to hardening of an attack and the third event 304C represents an event related to hiding of the same attack.

In an embodiment, detecting the event is performed by comparing a first differences between the scanning results of the stored data of a first pair of the backups at first two sequential points in time and comparing a second differences between the scanning results of the stored data of a second pair of the backups at second two sequential points in time. With reference to FIG. 3, the first differences refer to difference between the fourth backup 302D and the fifth backup 302E of the backup system. By comparing the first differences, i.e. differences between the scanning results of the fourth backup 302D and the fifth backup 302E of the backup system, the second event 304B is detected. Again, with reference with FIG. 3, the second differences refer to difference between the fifth backup 302E and the sixth backup 302F of the backup system. By comparing the second differences, i.e. differences between the scanning results of the fifth backup 302E and the sixth backup 302F of the backup system, the third event 304C is detected.

Referring back to FIG. 2, in accordance with an embodiment, the method 200 further comprises using the first difference for detecting a hardening of an attack in a registry of the host device and using the second difference for detecting a hiding of the attack in the registry of the host device. Typically, in case of any attack, the attack attempts to harden any changes made in the host device so that the made changes will persist across reboot, and then the attack may attempt to get rid of any logs supplying evidence of the attack itself, and the actions performed during the attack. Herein, the hardening of the attack in the registry of the host device increases vulnerability in applications, systems, infrastructure, firmware, and other areas in the host device. Further, the hiding of the attack in the registry of the host device makes it difficult to detect the attack. Since such attempts would be recorded as events in the event log, and there may exist sequential backups before and after for each of such attempts; by comparing such sequential backups it would be understood that such attempts could be detected.

Referring to FIG. 3, as discussed, the second event 304B represents an event related to hardening of the attack and the third event 304C represents an event related to hiding of the attack. Herein, the first differences, i.e. differences between the scanning results of the fourth backup 302D and the fifth backup 302E of the backup system, leads to detection of the second event 304B, and thereby detection of the hardening of the attack. Further, herein, the second differences, i.e. differences between the scanning results of the fifth backup 302E and the sixth backup 302F of the backup system, leads to detection of the third event 304C, and thereby detection of the hiding of the attack.

Referring to FIG. 2, in an embodiment, detecting the event comprises detecting a change in an operating system registry of the host device. For example, change in a computer-specific information, like hardware configuration as stored in the registry of the host device is detected. Detecting the event further comprises detecting a change in an event log of the host device. For example, change in account credentials stored in the event log of the host device is detected. Detecting the event further comprises a change in an event in the host device. For example, any change or modification in the event log is detected. Detecting the event further comprises a modification of system times of the host device. For example, modification in date and/or time associated with any event, which may or may not be related to the attack, such as database transactions, is detected. Detecting the event further comprises a modification of a metadata pointing to the event in the host device. For example, modification in details, like associated user information or the like, about a particular event is detected. Detecting the event further comprises a malware in the host device. For example, the malware including, but not limited to viruses, worms, Trojan Horses, rootkits, spyware and keyloggers, is detected. Detecting the event further comprises a notorious activity in the host device. For example, events like logging in the host device by an unauthorized person is detected. Detecting the event further comprises a hardening of an attack in the registry of the host device. For example, the hardening of the attack in the registry may include, but is not limited to adding superfluous programs, providing permissions and access that provides opportunities to attackers to gain a foothold within the host device, and such hardening of the attack in the registry is detected. Detecting the event further comprises a hardening of the change made in the system registry of the host device. For example, any unauthorized registry changes which are attempted to made permanent are detected. Detecting the event further comprises a hiding of the attack in the host device. For example, the event log of the host device is changed to hide the attack in the host device, and such changes are detected. Detecting the event further comprises an elevation of privileges. For example, changes related to allowing the access to the data of the host device to unauthorised person are detected.

At step 210, the method 200 comprises issuing an indication of the detected event. That is, once the event of the data tampering is detected by scanning of the stored data of the received backup, the indication of the detected event is issued to inform security researchers about threats on the host device. The indication of the detected event may be issued in the form of one or more of notification, email, text message, alarm and the like. The indication of the detected event may be issued in real-time or near real-time so that measures could be taken to quickly secure the host device against the detected event. The details of the detected event are also indicated. For example, the detected event issued may include information about removal of events A, B, and C from the event log. In some examples, information about the last healthy state of the host device is also notified with the indication.

In an embodiment, the method 200 further comprises building an attack profile. The attack profile includes information related to the detected activities and details about changes made in the host device during the attack. The attack profile may be built using the backups of the host device received at several sequential points in time in the backup system. The attack profile is built to perform post mortem analysis of the detected event to improve security of the host device. The attack profile may be stored in the backup system for better analysis in the future. Optionally, the post mortem analysis of the event detected may be performed in an isolated sandbox, such as a virtual machine, that provides an isolated environment to run and test the malicious event related to the host device in order to understand how the event works on the host device.

In accordance with an embodiment, the method 100 further comprises initiating a restore of the tampered data. Once the event is detected, the healthy state of the host device prior to the event is identified using the received backups at several sequential points in time of the host device in the backup system and the host device is restored to the healthy state. It may be appreciated that the healthy state of the host device is determined to the state corresponding to the backup before the data tampering event took place in the host device.

In some examples, rebooting the host device may be used to restore the host device to the healthy state.

The steps 202 to 210 are only illustrative and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

FIG. 4 is an exemplary block diagram of the system 100 being implemented for identifying the data tampering in a host device, in accordance with an embodiment of the present disclosure. As illustrated, the system 100 is associated with a host device 402. Herein, the host device 402 relates to an electronic device associated with (or used by) a user that is capable of enabling the user to perform specific tasks associated with the embodiments of the present disclosure. Furthermore, the host device 402 is intended to be broadly interpreted to include any electronic device that may be used for voice and/or data communication over a wireless communication network. Examples of the host device 402 include, but are not limited to, cellular phones, personal digital assistants (PDAs), handheld devices, wireless modems, laptop computers, personal computers, etc. Additionally, the host device 402 may include a casing, a memory, a processor, a network interface card, a microphone, a speaker, a keypad, and a display.

As illustrated, the host device 402 comprises a memory 404. Herein, the memory 404 relates to a computer readable storage medium that may store an operating system and/or other program products of the host device 402. That is, the memory 404 may be any computer readable storage medium, such as an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Examples of the 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, a Secure Digital (SD) card, Solid-State Drive (SSD), and/or CPU cache memory. The memory 404 of the host device 402 may temporarily store generated backups of the host device 402 before being transferred to and/or executed by the system 100 of the present disclosure.

As illustrated, the system 100 comprises a backup system 400. The backup system 400 is in communication with the memory 404 of the host device 402 to receive the backups of the host device 402 therefrom. Herein, the backup system 400 incorporates the backup database 112 and the event database 114 of the system 100. Herein, the backup database 112 stores the backups of the host device 402, including a first backup 408A, a second backup 408B, a third backup 408C up to an Nth backup 408N of the host device 402.

Herein, the backups 408A-408N are received at the several sequential points in time in the backup database 112.

As discussed, herein, the backup database 112 comprises the first backup 408A, the second backup 408B, the third backup 408C to the Nth backup 408N of the 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 one hour, one day, two weeks or one month according to how pedantic or relevant the backups are, e.g. according to the corresponding backup policy how frequently the backups need to be performed. In an example, the first backup 408A may be received by the backup database 112 on day one, the second backup 408B may be received by the backup database 112 on day two, the third backup 408C may be received by the backup database 112 on day three and so on.

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

In operation, the backup database 112 receives the first backup 408A, the second backup 408B, the third backup 408C up to the Nth backup 408N of the host device 402 at the several sequential points in time. The several sequential points in time may vary upon how pedantic or relevant the backup in the backup database 112 is. The backup database 112 internally mounts a copy of the backups 408A, 408B, 408C to 408N periodically and then transfers those to the virtual machine engine 116. The backup may comprise information related to the host device 402 such as operating system, installed software, folders, media, event log, registry and alike. As discussed, extracting the data is performed by activating the received backup of the host device 402 as the virtual machine engine 116 and extracting the 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 for the data tampering in the host device. Thus, the data in the virtual machine engine 116 cannot be tampered by the attacker. Hence, the data is extracted from the virtual machine engine 116. For example, the data may be extracted from the virtual machine engine 116 by attaching a VMDK to an Existing Virtual Machine, using a file archiver, Linux reader and/or a virtualization software package, e.g. the player of the workstation VMware®. The data extracted from the activated virtual machine engine 116 comprises the copy of an event log of the host device and the copy of a registry of the host device. Such data is extracted by the virtual machine engine 116 as any change in the event log and registry may provide complete details about the attack or event of data tampering.

The extracted data 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 for detecting the event of the data tampering in the host device 402. For detecting the event, the backup differences between the data of the two consecutive backups are compared. For example, the backup 408B is compared with the backup 408A to detect the event occurred in time between the backup 408B and the backup 408A are received. Similarly, the backup 408C is compared with the backup 408B to detect the event occurred in time between the backup 408B and the backup 408C are received.

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

In the system 100, first the host device 402 is periodically or continuously backed-up in the backup system 400. Periodically the backup system 400 will internally mount a copy of the host device 402 as a virtual machine. Herein, if the backup is periodical then every backup image will be scanned, and if the backup is continuous, every period of time will be checked. The backup system 400 will then run a tool that extracts the data from the running virtual machine engine 116. This includes extracting a copy of the event logs using an event log tool, and extracting the registry. The backup system 400 will then store the extracted data in the event database 114, and scan for differences between the current status of registry or event logs, and previous status. Further, the backup system 400 will alert the administrator in case of an issue. The system will provide root cause analysis and allow restoring of the parts (i.e. data) of the host device 402 which were tampered.

The present disclosure further provides a computer program adapted to perform the aforementioned method when executed on a backup system 400 (such as, the backup system 400 of FIG. 4). Such computer product for identifying data tampering in a host device (such as, the host device 402) may include, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

The systems and methods of the present disclosure provides a safe, and traceable view of the host device over time to allow system administrators, and security researchers to get notifications of active threats in almost real-time, and to perform post mortem analysis and profiling of threat progression. In the present implementation, sensitive components of the system are backed-up, such as the Windows registry, or the system log in short intervals, and following backup, these components are scanned inside the backup system (using the backup system resources, so the host is not affected by these scans). The results of these scans are then compared to previous results, and patterns are identified that are typical to an attack, such as singular removal of events in the event logs, or known changes in the registry indicating malware or notorious activity on the system. The sensitivity of the backup system to such events can actually be fine-tuned on how pedantic or relevant it should be in these scans, for example, notify any change whatsoever in the registry, or in parts of the registry for users who do not have permission to do any such changes. Once a threat is detected, the system administrator is notified by the backup system. Wthin the notification, can be information about the last healthy system state, and the details of the detected threat, for example removal of events A, B, and C from the event log.

Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as "including", "comprising", "incorporating",

"have", "is" used to describe and claim the present disclosure are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also 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" is used herein to mean "is provided in some embodiments and not provided in other embodiments". It is appreciated that certain features of the present disclosure, 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 suitable in any other described embodiment of the disclosure.

Claims

1. A method (200) for identifying a data tampering in a host device (402), wherein the method comprises receiving at several sequential points in time a backup (408A-408N) of a host device in a backup system (400); extracting a 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 stored data of the received backup for detecting an event of the data tampering in the host device; issuing an indication of the detected event.

2. The method (200) according to 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 the claims 1 to 3, wherein detecting the event is performed by comparing a backup differences between the scanning results of the stored data of the backup (408A-408N) at one point in time of the several sequential points in time and the scanning results of the stored data of the backup at a point in time preceding the one point in time.

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

6. The method (200) according to claim 5, wherein the method further comprises using the first difference for detecting a hardening of an attack in a registry of the host device (402) and using the second difference for detecting a hiding of the attack in the registry of the host device.

7. The method (200) according to any one of the preceding claims, wherein detecting the event comprises detecting a change in an operating system registry of the host device (402); a change in an event log of the host device; a change in an event in the host device; a modification of system times of the host device; a modification of a metadata pointing to the event in the host device; a malware in the host device; a notorious activity in the host device; a hardening of an attack in the registry of the host device; a hardening of the change made in the system registry of the host device; a hiding of the attack in the host device; or an elevation of privileges.

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

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

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

11. The method (200) according to any one of the preceding claims, wherein the method further comprises building an attack profile.

12. The method (200) according to any one of the preceding claims, wherein the method further comprises initiating a restore of the tampered data.

13. A system (100) for identifying a data tampering in a host device (402) 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 extracting engine (108), a scanning engine (110); and wherein the system is configured to issue an indication of the detected event.

14. The system (100) according to claim 13, wherein the database management system (106) comprises a backup database (112) adapted to receive backups (408A-408N) of a host device (402); an event database (114) for storing extracted data.

15. The system (100) according to claim 13, wherein the data extracting engine (108) is configured to extract data from the received backups (408A-408N) of the host device (402) comprising a copy of an event log of the host device; a copy of a registry of the host device.

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

17. A computer program adapted to perform the method (200) of claim 1 when executed on a backup system (400).