Anti-rootkit tactics

[Melf]

Caution: adjust paranoia level to DEFCON 5 for me for a minute please. Thanks.

Ok, so you've got some bullet-proof setup. You're running 64-bit Win 7 or Vista so have PatchGuard as well. You need to install some new drivers or what you think is a legitimate program and so you take down your "shields", give admin rights. But you've actually got some nasty sophisticated rootkit that has stolen certificates and is 0-day so scans clean etc.

What are the specific attack vectors that need to be protected to stop this thing from gaining the power to completely subvert the operating system and hence evade detection forever? I've been reading about TDSS a bit and it seems that there are two main tactics: writing to the MBR and partitioning the disk to create a new boot partition (with the rootkit on it of course - fricking genius you have to admit). I can also imagine that writing to the BIOS could be another avenue.

If each of these are covered, and you have PatchGuard to protect the kernel (from what I've read PatchGuard seems to have been 'avoided', e.g. by the above methods, rather than ever actually being broken i.e. a compromised kernel), is there anything left? If this stuff can be 100% protected against (barring of course the inevitable currently unknown exploit), all you have to worry about is some persistent infection that at least will eventually be detected by a periodic scan, as opposed to a sneaky little bugger that can control your hard drive and hide from scanners.

Second question - how much of this can be protected against using just the tools that come with the OS? Is it possible? Or do we need third-party software, and if so, which ones can pro-actively defend against these threats as outlined above? I'm aware that the MBR at least can be protected by MBR Guard from Blue Ridge, which is now no longer available and is part of AppGuard.

[Melf]

Nobody has any comment on modern rootkit attack vectors?

[Victek123]

Originally Posted by Melf

Nobody has any comment on modern rootkit attack vectors?

I don't believe that the attack vectors for rootkits are any different than for malware in general. I also don't believe the OS has the tools to deal with them. Currently the best protection against zero day threats are products that use cloud analysis, such as Webroot Secure Anywhere. The vendors have massive processing power compared to our individual PCs and they can close the window on new malware without needing to generate and push out signatures.

Looking at things through a paranoid lens it will always seem possible for there to be malware that is undetectable, secretly running and controlling the system, but in the real world even the sneakiest malware betrays its presence sooner or later to the astute user. After all malware has some purpose (identity theft, botnet, etc) and by pursuing that purpose it becomes detectable. Along with "best practices" we protect against that stuff by paying close attention and noticing if/when there are subtle changes to the way our systems are working. Anything which truly cannot be perceived by us or detected by the best available antimalware technology either doesn't actually exist or isn't worth worrying about (NSA, CIA, DHS, et al) IMHO...

[treehouse786]

nice question, nice answer.

What I have experienced with the latest modern rootkits for the Windows platform is that they do not elevate access, but rather are used to make some other software payload undetectable by adding stealth capabilities. Most rootkits are classified as malware because the payloads they are bundled with are malicious, for example to covertly steal user passwords, credit card information, computing resources or to conduct other authorized activities. A small number are legimate utility applications—an example of the latter is a rootkit that provides CD-ROM emulation capability allowing video game users to defeat anti-piracy features that require the original installation media.
Rootkits and their hidden agenda provide an attacker with full access via a back door so the attacker can for example, steal or falsify documents. One of the ways to carry this out is to subvert the login mechanism such as the /bin/login program on Unix-like systems or GINA on Windows The replacement appears to function as normal, but also accepts secret login combination that allows an attacker direct access with administrative privileges to a system, bypassing standard authentication and authorization mechanisms.
This way they can Conceal other software, notably password-stealing key loggers, computer viruses and other forms of malware.
Then they simply just apropriate the compromised machine as a zombie computer for attacks on other computers. The attack originates from the compromised system or network instead of the attacker's.

[EASTER]

Just like to add to what general_zerohour was pointing out of rootkits.

In my studies of these cloaking devices, the super hiders are of course designed to "go invisible" yet i found they almost always incorporate some type of driver file in order to tap into the system information flow or chain if you will to mask it's presence. So on a few of my XP machines in order to head this action off before some rootkit driver has a chance to load and disappear, i devised a simple experiment which i now keep in all my XP systems without issue. Simply took the main driver file from the old relic Samurai, and with a driver loader app register it and set it to either auto start or manual if you like me decide to energize it on-the-fly. This single driver on XP's for certain, locks out any driver installs whatsoever. When activated not a single ARK could load it's driver as expected, so then no malware rootkit could either if it tried. Just a little security tweak i'm glad i stumbled on, exclusive of course to XP systems, don't know about vista or 7, just xp for sure.

And to make matters even more secure against a forced rootkit install when tempting fate at sites that are geared to hijack systems in that manner, i took from another rootkit driver to hide samarai's (driver guard's) presence.

And for good measure, taking a page directly from those tweebs dirty deeds themselves, installed samarai's driver in an ADS in one of my system folders.

The beauty of all this is that it continues to work to absolute perfection on any XP system with the abandoned freeware app named ServiceView program developed by Native Computer Systems. It allows to stop & start drivers at-will and even change their startup characteristics to the users preference.

And to think just a single old fashioned driver, long abandoned can match up to any rootkit driver install could be so formidable as this is hilarious.

If you google it i think they both are still rusting on some active servers.

[Melf]

Thanks for discussion all. Sounds so far that we have:

Protecting the pre-OS level (MBR/Disk partitioning/BIOS): Does anyone know of third party tools that protect these?

Preventing driver loading: Easy enough to stop unsigned drivers using built-in Windows protection. For signed drivers, any third party tools other than the very rusty ones suggested by Easter?

Minimizing 0-day vulnerability through Cloud protection

Detecting behaviour of the payload after infection

[CGuard]

Originally Posted by Melf

Protecting the pre-OS level (MBR/Disk partitioning/BIOS): Does anyone know of third party tools that protect these?

I 'm also interested in that...

PS. Very informative thread.

[blacknight]

Originally Posted by CGuard

I 'm also interested in that...

PS. Very informative thread.

Agree. I think that MODs should put it in evidence.

[BoerenkoolMetWorst]

Originally Posted by Melf

Thanks for discussion all. Sounds so far that we have:

Protecting the pre-OS level (MBR/Disk partitioning/BIOS): Does anyone know of third party tools that protect these?

Preventing driver loading: Easy enough to stop unsigned drivers using built-in Windows protection. For signed drivers, any third party tools other than the very rusty ones suggested by Easter?

Not sure about BIOS, but I think you can protect from all this with a HIPS, for MBR and Disk partitioning I think the program will need direct disk access, almost all HIPS control this, same for driver installation. Most HIPS trust signed stuff by default to prevent pop-up galore, but you can disable this with most of them. Of course if you would be installing new drivers that are infact zero-day rootkits like in the scenario from your first post, then there's not much point in it as if it were legit you would have to allow driver loading as well for it to work, and depending on what kind of driver, direct disk access as well.

[3x0gR13N]

Originally Posted by Melf

Preventing driver loading: Easy enough to stop unsigned drivers using built-in Windows protection.

Unless it's bypassed with a built in Windows feature called TestSigning
http://www.securelist.com/en/blog/47...e_AV_for_MacOS

The 64-bit driver is signed with a so-called testing digital signature. If Windows – Vista and higher – was booted in ‘TESTSIGNING’ mode, the applications can launch the drivers signed with a testing signature. This is a special trap-door which Microsoft has left for driver developers so they can test their creations. Cybercriminals have also made use of this loophole: they execute the command ‘bcdedit.exe –set TESTSIGNING ON’ which allows them to launch their driver without a legitimate signature.

http://www.securelist.com/en/blog/11...also_to_64_bit

The file aaa.bat will run and execute the file bcdedit.exe, a legitimate tool developed by Microsoft aimed to edit the boot configuration of Windows Vista and later versions. Using this tool and some parameters like “DISABLE_INTEGRITY_CHECKS”, “TESTSIGNING ON” and “type= kernel start= boot error= normal” the files plusdriver.sys and plusdriver64.sys will be copied to the drivers folder and registered as active drivers during the next reboot. This technique allows them to launch their driver without a legitimate signature

[vojta]

Originally Posted by general_zerohour

A small number are legimate utility applications—an example of the latter is a rootkit that provides CD-ROM emulation capability allowing video game users to defeat anti-piracy features that require the original installation media.

Very legitimate.

[Melf]

Originally Posted by BoerenkoolMetWorst

Not sure about BIOS, but I think you can protect from all this with a HIPS, for MBR and Disk partitioning I think the program will need direct disk access, almost all HIPS control this, same for driver installation. Most HIPS trust signed stuff by default to prevent pop-up galore, but you can disable this with most of them. Of course if you would be installing new drivers that are infact zero-day rootkits like in the scenario from your first post, then there's not much point in it as if it were legit you would have to allow driver loading as well for it to work, and depending on what kind of driver, direct disk access as well.

After searching around I gather that most HIPS do this too. Though you can hardly ever tell from the product's website. One example was Spyshelter, I found forum posts showing screens of it blocking access to the MBR and to driver installation.

For me this makes HIPS a necessity because anything you choose to install could otherwise subvert the OS. It's not just malware you have to worry about - e.g. the oft-cited Sony rootkit fiasco. But I don't want to run a HIPS unless I can avoid (ideally want to minimize need for real-time security apps). So I was really hoping for either

a) A 'HIPS lite' that either hooks or better yet applies some policy to restrict modification of these areas
b) Some Applocker/SRP/registry/DACL etc hack to achieve the same thing through the OS.