Successful Attacks: Covering Tracks

From Daelphinux
Jump to: navigation, search

After an attacker has gained access to your network, and maintained that access long enough to accomplish their objective, they will need to cover their tracks. Once this step has been reached, the attack is complete; defending against this step is a form of damage control. For these purposes, we are going to assume that the attacker is using basic methodologies; this is a short overview series after all.

In order to utilize the information gained, implement the backdoor opened, or activate the payload placed the attacker is relying on the defender not knowing what action was completed. A compromised list of passwords, for instance, is of now use to a buyer if the defending entity was able to determine the list and change the passwords. Malware is of no use when the defending administrator knows exactly what to clean. Backdoors are of no use if they are closed. Without covering tracks, the attack may have been accomplished, but the pay-off will be useless. Because of this, a complete attack may not include this step, but a successful one always will.

The best method for preventing an attacker from successfully covering their tracks is to utilize redundant logging. Essentially this means that logs should be stored in multiple places when generated, and there should be log systems that log each other’s access and uptimes. Given that many attackers try to maintain small footprints, this set up alone may deter an attacker from continuing on if they notice this during the third phase of the attack.

There are a couple of ways an attacker will cover their tracks. Initially (earlier in the attack, but very pertinent to this phase), the attacker will almost certainly obfuscate their IP and MAC addresses. If properly done, this makes it very difficult to determine where the attack is coming from. Ideally, from the attacker’s perspective, the attacker will have enough information to spoof an IP and MAC that exists on the local network. In these cases, it is often easiest to find a client that is initializing an inordinate number of unrelated connections; keep in mind, however, that easiest does not mean easy. This step alone can foil even experienced security teams if the right client is spoofed. While this makes the logs difficult to determine relevance, there are still logs there. To many attackers having any logs at all is an unacceptable risk.

This will lead some attackers to, once they connect to a system, disable logging. Although this is a little confusing to get one’s head around, usually, disabling a logging system generates a log message in itself. Although, a message saying logging is disabled is almost useless in determining what actions were taken while the logs were disabled, it is a very strong piece of information that can give data such as what client was making the attack, that an attack was made, and which specific system or subsystem the attack hit. This is a smart move on the part of the attacker, but as mentioned before, in some cases any logs at all are unacceptable.

Once the logs have been generated there is almost always a way to remove the log entry. Many of these methods are destructive to more than just the log files; not that this matters to most attackers, it is an important thing to consider. Often, in the cases that the operating system files themselves are corrupted to avoid administrators from seeing the logs, this can be a strong indicator of the system hit. In the event that the system is not corrupted in itself, an administrator will need to determine which system was hit in the attack. With this information, and various file system checking tools, an administrator can recover files from the destroyed system and compare them against the files in the attacked system’s backups.

In the event that the system is completely cleaned, as in all system and data files erased or destroyed, the defending entity’s security response team will need to make a list of things that could have been affected in the attack and make an educated guess as to which sub-system was most likely hit; the team will, however, need to inform potentially affected clients of all of the attacked system’s sub-systems. An attack that reaches this point is a public relations nightmare, regardless of how successful this step is. Even if all of the data loss, or any placed payload or vulnerabilities, is mitigated, a company will still need to inform potentially affected clients and customers. In some cases, that alone is a strong success for an attack, even if the target data or vulnerability were not successful.