RegDefend vs. Rootkit

1.
Is RegDefend supposed to give the user control over cloaked registry entries or is it necessary that you disallow the rootkit's autostart entry prior to the installation of the rootkit?

A quick test seems to indicate that HackerDefender's autostart entries can only be monitored during the installation process (but not thereafter).

Shouldn't it be possible for a kernel-based solution to bypass a rootkit's "cloak of invisibility"? This would be good because a user may not know whether it is necessary to allow or disallow an autostart entry (or the start/installation of a service). If you are too careful and disallow each and everything the installation process may stop and potentially legitimate software will not be installed.

2.
Can I only block unwanted autostart entries or can I also remove them with the help of RegDefend? The latter would be good in conjunction with 1.

 

As you have observed, RegDefend still relies on the end user being able to make an informed decision. No matter where or how a driver loads it is always possible for another driver to be more aggressive and enforce its "cloak". After all the rootkit author probably won't be providing support for your PC if/when it becomes unstable and BSOD's due to the way the driver (mis)behaves

If you are blocking the CREATE of the autostart key then there is nothing to remove, this is after all the reason to have preventative security software

The other useful aspect of RD is that the process attempting to create the key is identified and you can use that to your advantage in knowing what to kill or what to investigate further.

 

Correct, when you install RegDefend it can only assume your system is clean and that the current state of your registry is clean. If you are already infected when you install RegDefend then of course RegDefend cannot know that and protect you from it.

 

Please let me explain why I believe that RegDefend should become a Rootkit Detector/Remover by referring to the history of Process Guard:

Initially, this tool was designed and promoted as an anti-termination tool although anti-termination is a pretty useless feature (i.e., termination attacks are not the really dangerous ones). Subsequently, DCS realized that Process Guard had the potential to stop almost any DLL trojans, prevent the installation of rootkit drivers, code-injections etc. The GUI was improved and gazillions of bugs removed. Now it's probably the best system firewall you can get.

I believe that a similar development is required in respect of RegDefend. RegDefend's current features are not terribly exciting: proactive registry protection (instead of registry monitoring in connection with a removal option) is nice but do we really need it? I can only imagine a few scenarios where proactive registry protection is really useful (e.g., malware bypasses your AV/AT scanner and tries to set an suspicious autostart entry for which there is no apparent reason (taking into consideration the type of application that the malware pretends to be)). Frequently, however, proactive registry protection does not help (e.g., a user allows the installation of a trojanized/spyware-infected application (including the creation of autostart entries) and subsequently realizes that s/he does not want this programm running on the computer).

In light of the above, I believe that something fancy is needed in addition to proactive registry protection. Something that fully uses the power of a kernel-based low-level solution. I could imagine that future versions of RegDefend are specifically targeted against the steadily spreading rootkit plague (also taking into account that (i) nowadays almost every type of malware can have rootkit functions and (ii) modern rootkits feature technologies to bypass simple rootkit detectors). Due to his experience in the area of malware and driver development Jason is probably in an excellent position to create an impressive low-level registry protection and malware removal tool.

I could imagine the following features (besides proactive registry protection):

- creation, removal, editing of registry entries (preferably w/o using the Windows API);

- rootkit detection by way of a raw-level registry comparison (i.e., reading the registry via the Windows API and comparing it with the raw registry hive);

- identificating/stopping/terminating malicious (cloaked) programmes and drivers using low-level technology, simultaneous termination of multiple malware processes/drivers which may interact, unloading of DLLs;

- identification and removal of API hooks (possibly: "Clean ALL hooks" function);

- file protection (against patching of important windows files etc.), identification of patched windows files (baseline comparison);

- if possible: defensive measures against a rootkit's anti-rootkit detector technology which try to benefit from RegDefend's timing advantage/prior installation (e.g., self-protection of memory space & file access to registry hive etc., "clean boot" option which only loads the RegDefend driver and certain white-listed drivers);

- polymorphic features that complicate RegDefend's identification, interchangeable object names, etc.

- name change: LowTec Ghost Defender ;-)

(Some of the above-mentioned retroactive features would perfectly compliment Process Guard which is proactive only.)

 

A number of good ideas there, it might be worth adding them to the wishlist thread to make sure that Jason sees the ideas...

[ and taking proper credit for them by registering your username ]

 

Yes, I believe Greatis Software's UnHackme is attempting to do something similar to what you suggest for RegDefend and it would certainly make RegDefend a more feature-rich product if it did have some automatic rootkit defenses included in it.

For now, it is more of a "second-line" defense, as you desribe. If, for example, I accidently gave permission to a trojan via ProcessGuard, I would still have a chance to stop it from making registry entries with RegDefend. Ditto, if the trojan/worm was not detected by KAV or PG, but was detected by RegDefend.

Rich

 

I was running the trial version (and purchased RegDefend yesterday). I am already running PG, Kaspersky and TrojanHunter. RegDefend is another layer in my protection.

 

Hi G1111,

Pretty much my configuration only I am using Ewido in real-time. I have Trojan Hunter on standby for on-demand scans. Have you looked at WormGuard (or something similar) to protect against scripts/worms? Something you might want to consider.

Rich

 

Rich - Thought about WormGuard, but relying on KAV for now. Just downloaded the lastest version of KAV (5.0.325). Thanks for the tip.

 

Some of this echoes the post I made in the Wishlist thread of being able to "spoof" changes (so only the program responsible saw the modifications - malware would then think changes had been done even though they had not) and also make it easier to reverse changes (making RegDefend a potent uninstaller).

However issues like file protection and process manipulation do go well beyond RegDefend's current remit. Let's see registry sandboxing and the ability to track (and reverse if needed) all changes made by specific processes first.

 

I've only read a bit on rootkits, but so far the ones that I've read about all access the registry to install...as people have mentioned above, I wonder if there's some generic way to use this against rootkits, or if a rootkit.ghst will be included in future versions.

 

A rootkit needs to run on Windows startup and setting appropriate Registry entries is one way of doing this (which RegDefend already covers I believe) - but it is not the only way, so RegDefend on its own cannot provide 100% protection in this area.

 

Hi all,

Without knowing the specifics, it would seem a rootkit would have to install specific services and registry entries in order to run in the kernal and be able to cloak itself. If this is so, it would seem that products like ProcessGuard would be in the best position to detect and prevent any rootkit installation. RegDefend could, theoretically, provide protection, but this type of protection would be after the Rootkit is already executing - and RegDefend is blocking the registry updates. This is good, but it would be better if ProcessGuard cuts them off at the pass, but first detecting the malicious program, and then detecting the malicious activitiy very early on.

No doubt, DiamondCS will have to stay on their toes to monitor new ways of entering the system. This is one of the reasons I would like DiamondCS to focus on ProcessGuard and WormGuard. If these two products are really covering the territory the RegDefend becomes more of a supporting line of defense.

Anyway, I am darn happy that these products exist.

Rich

 

Of course, however, seeing as you have to shut PG down to install many types of software....RD then becomes a very important line of defence.

And of course even if a rootkit installed, if it couldn't manipulate the registry to autostart it would be useless after reboot.

Hmmm...of course if the rootkit was a kernel level rootkit, then I'm presuming RD couldn't necessarily stop it changing the registry anyway (correct me if I'm wrong on that)

 

Not necessarily true - as I mentioned above, it is possible for programs to set themselves to run on Windows startup without touching the registry.

If the rootkit was able to install, then it would become a question of whether it was able to run on startup before RD or not. Prior to it installing though, RD would be able to intercept any registry changes.

 

Indeed, the most trival method would be to stick it into the startup folders. Others include altering the wini.ini, wininit.ini, config.sys, autoexec.bat etc. Some of these don't work on XP though.

I find it hilarous that someone installing Regdefend, and then goes on to research all sorts of obscure registry keys to block autostarts gets nailed because he forgot to monitor the most obvious ones of all !

 

I've heard about process injection, and err...piggyback execution (where starting one executable triggers another)....And then the ones mentioned above. Hell, I don't even know how process injection works, just that it happens. ,Not quite sure how the *.ini files work yet. Know a little about config.sys and autoexec.bat from the old dos days, although I thought they weren't used anymore.

Oh pollmaster...'I find it hilarious' ? ...no need to be rude about such things. I've never claimed to be an expert, and am always learning. Thank you to the people who correct me without resorting to such condescending remarks

 

I wasn't talking about you. I know you know such things. At worse, you merely forgot.

I was wondering about the hapless newbies who buy RD to monitor startups (that's the main selling point of monitoring registry)and ditch inferior products like Winpatrol and tea-timer. Given that a lot of programs register themselves to autostart via the startup folders , this would mean suddenly they lost control over such apps?

Granted such programs generally arent trying to hide, but I think making it clear would be helpful.

I wonder if Jason should list this Under common questions. The elite people who visit this board don't need to be told, but I think others might.

 

Then you are one up on me then.

I see people talk about dll/memory/process/thread/code
+ injection/hooking/modification

Some of them I think I understand, but it seems the terms are not that standardised.

 

Those, plus more subtle methods like altering key Windows startup files (e.g. winlogon, userinit) to include rootkit code.

 

That's what rootkits do!!