Restoring data from backups after a security breach

Dealing with the aftermath of a security breach is never easy. Those tasked with the cleanup must determine not only how the attacker managed to penetrate the network's defenses, but also what they did after gaining access.

Once these two questions have been answered, then the real work of restoring data begins. When a system has been compromised, the operating system volume must be reformatted and the OS reinstalled. Similarly, any applications running on compromised systems also need to be reinstalled. It is nearly impossible to guarantee the integrity of the system after an attack, hence the need for reinstallation of the OS and any executable code (such as applications).

Of course, manually rebuilding the systems that have been impacted can be disruptive to the business. That being the case, it is common for IT pros to try to minimize the disruption by restoring a backup rather than redeploying the systems from scratch. While this approach might expedite the recovery effort, one has to consider whether the backups can be trusted.

To answer this question, consider how the security team determines the scope of the attack. Typically, the forensic analysis is based around a comprehensive review of various audit logs. Although tedious, audit logs can be used to retrace an attacker's actions thereby allowing the organization to figure out which systems were impacted.

For the purposes of this discussion, let's assume that an attacker managed to access several servers at the operating system level, but never managed to access the data. Given the scope of the attack, the server operating systems clearly cannot be trusted. But is it safe to restore the operating systems from a backup that was made prior to the attack? Maybe not.

The problem with assuming that it is safe to restore a backup that was created prior to an attack is that the assumption treats the attack as a one-off event. It's dangerous and naive to assume that the attacker broke in and then immediately launched an attack against the system. It is actually very common for an attacker to penetrate a network's defenses and spend time looking around and planning before actually launching the attack.

Attackers sometimes plant a Trojan on server operating systems. The reason for this is that it is relatively difficult to penetrate a network that uses defense in depth. However, resources residing within the network perimeter are almost always trusted. Hence, there may be nothing stopping a Trojan from contacting the outside world. As such, some attackers will plant Trojans to gain backdoor access. This is easier to do than it might seem. Some Trojans, for instance, will overwrite operating system files as a way of camouflaging their existence and may be able to exploit elevated privileges.

So, the problem with restoring an operating system from backup as a way of cleaning up after an attack is that a Trojan could have been planted weeks before the attack happened. If you restore data from a recent backup then you may be leaving the attacker's backdoor wide open.

The safest option is to reload the OS from scratch. If business operating requirements make that impossible, then the next best option is to use a combination of tools to try to validate the system's integrity. Obviously this means running an antimalware scan, but there is another tool that can be helpful.

Windows has a built-in tool called the System File Checker. You can run this tool from an elevated command prompt by entering the following command:

SFC /SCANNOW

This will scan all of the Windows system files and a number of registry keys in an effort to verify their integrity. If any files or registry keys are found to be suspicious, you can use the /Revert switch to return them to their default settings.

It is important to keep in mind that the System File Checker only examines operating system components. You must use additional security tools to make sure that no malicious code exists outside of the OS files.

Restoring data from a backup after an attack can lead to a false sense of security. It is better to rebuild or repair impacted systems and then make a fresh backup only when you know for sure that the system is clean.