Detecting RegDefend

Jason,
Without asking for your anti-avoidance measures, which I am sure will gradually be revealed as you get the 100 question treatment from all of us....

What happens to a program with multiple threads when RegDefend blocks a thread from making a registry change ?

If the other threads continue running (ie: the whole process is not suspended) then a program could potentially detect that the registry modification has been blocking waiting on user input and try and take evasive action....

Thanks

NB: The same question applies for ProcessGuard when a program is attempting to perform a privileged action in one thread, but I'll ask that in the right place....

 

I suppose that other threads continue to run. But I don't see that as a bigger detection oportunity, as there are several ways to detect a running version of RegDefend (or Process Guard). Easiest is to enumerate the list of processes, and detect the GUI/usermode component. Or enumerate (read) the drivers, or autostarting entries in the registry and discover regdefend/pguard. Or attempt registry attack and detect being unsuccessfull because the re-read of the same location shows unchanged data. Etc, etc.
-hojtsy-

 

True, but from a malware point of view, why would it have to care about RegDefend unless it is configured to pop-up a prompt when a registry read/change is attempted, so simply detecting that it is there only narrows the attack vectors ....

Hopefully what is being monitored is something that cannot be determined by a process (without triggering alerts that is), the (current) somewhat sub-optimal GUI design actually works on the "obscurity" side of this security tool by making it much harder for an app to screen scrape the settings (assuming that RegDefender is vulnerable to a sendkeys style of attack)

I was wondering if a process (or thread) could suicide in an attempt to make the alert go away... and the nice thing is that the thread cannot be killed whilst the prompt is being displayed as it is waiting on a kernel call (in a Wait:Excecutive state)

To be fair I only tried with regedit and tried kiling the process and the single thread with process explorer, also used apt for belt and braces kill, nothing did anything immediately and the alert remained on the screen (as hoped for)

As soon as the alert had been responded to the process died... also not totally unexpected because the kill had been actioned in user-land and was just waiting for the kernel to return

 

Yep, it seems you investigated truly in this case.

When a thread performs a registry operation it ends up in the kernel where RegDefend kicks in. At this stage the thread is "halted" in a zero CPU using wait if it HAS to ask the user what to do, otherwise the thread isn't halted at all and the action is performed depending upon the settings. This is the most optimal way of handling it and is one reason why RegDefend isn't as slow as other registry protection programs. The other optimal thing RegDefend does is never go back to user-mode except for asking the user, a lot of other kernel mode programs perform things like Registry name expansion, process name finding, etc, in user-mode because they have access to those functions. In Kernel mode you have to write your own and use undocumented techniques, but it does mean you get the fastest possible protection available if you know these techniques.