Are they impossible to detect? Seeing as the attacker has admin rights and could modify anti virus software that might otherwise be used to detect or circumvent a root kit. Are there certain red flags that point to a root kit? Can they see everything you do?
A "rootkit" normally tries real hard not to be detected. However, it cannot, in theory, be completely undetectable, since the point of the rootkit is to maintain an entry path for the attacker, so at least the attacker can know whether the root kit is in place or not.
A lot of methods have been used in the past. For instance, some rootkits install themselves in the kernel memory and leave no trace on the hard disk -- thus they are very hard to detect, but will disappear upon next reboot. More commonly, rootkits modify some files or some parts of the disk in order to resist reboots, but they then have to alter the kernel so that their modifications are not visible from processes on the machine.
So, basically, if the rootkit does its job properly, then you will not be able to detect it from the machine itself. You might find out about it if you reboot your machine on a live CD or USB key, and from that OS (presumed clean), inspect the hard disk. If the same files do not look identical, when inspected from the outside (the OS booted on a live CD) and from the inside, then this is a rather definite sign of foul play.
All of this assumes that the rootkit is good at what it is meant to do. There are a number of inexpert rootkits (or inexpert attackers) who will leave traces. For instance, weird files in the home directory of root (or Administrator).
A rootkit makes sense in situations where the attacker gained total control of your machine; the job of the rootkit is to maintain this level of control. The attacker can then see everything you do on the machine, and as long as the rootkit is active, he will be able to keep on seeing everything you do on the machine.
(The term "rootkit" has also been applied to escalation tools, i.e. tools which exploit local vulnerabilities to transform a user-level access into a full adin-level access on the machine. Same result: the machine no longer is your machine.)
Thank you for your reply! That's very unnerving how powerful root kits can be. That they know your machine better than you do. So a root kit requires an expert attacker...it is no average attack. It seems to be extremely sophisticated. Oct 21, 2013 at 17:44
@Thomas Pornin: I guess rootkit would allow the attacker to open a
sshsession. Wouldn't a good firewall or public/private key authentication prevent it, if configured properly along with MD5 checksum? Oct 21, 2013 at 18:53
3@DBroncos1558 - Developing one, yes. Infecting you with an existing one doesn't require any more effort than infecting you with anything else that requires admin rights.– BobsonOct 21, 2013 at 19:23
Are there certain red flags that point to a root kit? Can they see everything you do? I am new to security so please be easy.
Certain for rootkits in general, no. However, as Thomas has already noted, rootkits must leave an entry trail for an attacker, that is, the attacker's usermode code must be able to talk to the rootkit somehow.
To give you some examples of how you might achieve this:
Implement a custom
/procdevice with an important looking name, let's say
/proc/gpuinfo. Okay, that's a little obvious, but you get the idea - at a communication endpoint via
/proc(procfs is one meta file system in Linux that lets you communicate with userland) or
/devthat wouldn't normally be there, but that a sysadmin would think is normal.
If you look through the rkhunter logs, you'll see it looking for these.
Modify the entry of one of the above items to respond to something it normally wouldn't. Most device entries respond to different codes telling them to do something - this is especially true in
/dev. Add an obscure code to this as your communication mechanism.
On Windows systems, you can achieve the same thing with filter drivers, or patching the driver object of the target, take your pick (but filter drivers are more stable).
A detection mechanism would be to try spurious device codes on devices that don't (normally) respond to these. If you get anything other than the relevant "Not implemented" error code on your system, something strange is going on.
Mounting your system drive on a different PC turns up a different filesystem size than you expect, or files you couldn't see before. Be aware the different file system size isn't in and of itself a symtom of a rootkit, since some Windows editions still use disk geometry and... yeah don't panic straight away, but one in the wild rootkit I can't remember the name of created an encrypted filesystem at the end of your NTFS volume, handily shrinking your disk for you. Similarly, a common rootkit behaviour is to remove file entries from appearing in the FS on the live system (to hide them).
Unfortunately, there aren't generic red flags for rootkits in general - the battle is more cat-and-mouse. As soon as rootkit authors realise scanners are able to detect one type of communication channel or hook, they will change strategy.
Can they see everything you do?
Rootkit in the term I tend to think of it as, i.e. a kernel-level attack whose purpose is to maintain the intrusion on your system generally will be able to, yes, as the kernel manages the entire system and the rootkit will have the same privilege. There are some defences; modern Windows and some Linux distributions enforce signed kernel drivers/modules and may enforce this. This moves the attack vector to the boot sequence (before the kernel has a chance to enforce anything), which UEFI secure boot is designed to address.
You didn't ask this, but I'm going to make the point anyway. Usually, unless your system policy is a little insane, inserting kernel modules/drivers requires administrator rights. Therefore, to install a rootkit, the attacker must conduct a privilege escalation attack in the first place. Doing your utmost to ensure this cannot happen is the way to defend against rootkits.
Aside 1: rootkits do not have to be in kernel land, nor do interception-like malware. It is possible to achieve this without kernel drivers. If the user in question is not an administrator, the damage is usually more limited.