The first principle of analyzing compromised machines
The first principle of analyzing compromised machines is simple:
You can't trust anything running on a compromised machine.
If you are sufficiently paranoid, everything on a compromised machine might be compromised and lying to you: the programs, the shared libraries, the data files, even the kernel. You cannot trust any of it. This means that you cannot use a compromised machine to examine itself. Not even a little bit, however convenient it would be.
(The partial exception is that if a test on the compromised machine says that something is compromised, it probably is. But don't stop there.)
If you need to examine a thoroughly compromised machine you must do it completely from the outside, using some sort of environment that is known beforehand to be good. The traditional way is to connect the disks up to another system and use it to poke around; these days you can also use a live CD, if you are sure that the system is actually running it. Only then can you be confidant that you are not being lied to and your tools are actually reading what is really there and so aren't being fooled when they say that something isn't compromised.
(This sort of paranoia can run very deep. For example, are you sure that the BIOS hasn't been compromised to boot a hypervisor that then boots your live CD in a fake environment to hide bits of the disk from it? Really, it's simpler to add the disks to another system.)
The time and effort required for this sort of complete external verification is why the common advice for compromised machines is to just reinstall them from scratch.
(And you have to perform a complete verification, because an attacker might have hidden their compromise anywhere. For example, your kernel could be intact on the disk but the attacker has added a startup script that dynamically installs their rootkit through a kernel bug.)
|
|