"Ant" <not@home.today> wrote in
news:yMednahPO6F7eSDRnZ2dnUVZ8r2dnZ2d@brightview.c o.uk:

> "~BD~" wrote:
>
>> It's scary, knowing Carberp can run without admin rights.
>
> Maybe it can but it'll have trouble hiding without them and it does
> attempt privilege escalation.
>
>> It also means
>> Carberp must reactivate itself after a system restart. It
>> accomplishes this by copying the required process to the startup
>> section of the currently logged-in user.
>>
>> Normally, that would make a file easy to find. But, Carberp's
>> executable chkntfs.exe is hidden. It can't be found with Windows
>> Explorer or by using the command line.
>
> That may depend on the OS. The sample I have contains exploits, one
> of which was patched in MS08-025 "...addresses several
> vulnerabilities in win32k.sys where you can execute arbitrary code
> in kernel mode". The sample actually contains code which will only
> run in the kernel and appears to manipulate the system service
> descriptor table (contains information about ntoskrnl.exe versions
> of Nt/Zw... routines).
>
>> Thankfully, the way Carberp hides is also its Achilles Heel (I'll
>> explain later).
>
> He didn't explain but low-level routines like NtQueryDirectoryFile
> are hooked. This is easy to do if the exploit worked and the malware
> does it from the kernel. However, I was under the impression that in
> newer versions of Windows (where this exploit won't work) hooking
> system routines from user-mode (in ntdll, rather than ntoskrnl) is
> not possible. Perhaps I'm wrong about that. In any case, logging in
> as admin and deleting the malware from the affected account's
> startup directory is the way to deal with it.
>
>
>

Thanks for your review Ant. I suspected as much.


--
Some people are like a Slinky. Not much good for anything, but you
can't help but smile when one tumbles down the stairs.