[Tigzy]

Hello

Here's the beginning of my Group order list:

System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
Port
...

System reserved couldn't be taken as a valid group, right?

EDIT: This rootkit takes the tag 0x1 , How could we be before that?

EDIT2: Ok, understood. whatever the tag getted by the CreateService API, we could move the 0x1 at the end of the BYTE array in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GroupOrderList

[Tigzy]

Hello

I'm currently able to load my driver with tips EP talked before.

Processus malicieux: 1
[LOCKED] 57bcd85a2764d863.exe -- LOCKED -> KILLED [DrvNtTerm]

Entrees de registre: 4
[SUSP PATH] HKCU\[...]\Run : 57bcd85a2764d863.exe (C:\Documents and Settings\Administrateur\Local Settings\Application Data\57bcd85a2764d863.exe) -> ERROR [0x5]
[SUSP PATH] HKUS\S-1-5-21-823518204-842925246-839522115-500[...]\Run : 57bcd85a2764d863.exe (C:\Documents and Settings\Administrateur\Local Settings\Application Data\57bcd85a2764d863.exe) -> ERROR [0x5]
[HIDDEN] HKLM\[...]\services : d24eb7c11da0abb () -> ERROR [0x5]

Fichiers / Dossiers particuliers:

Driver: [LOADED]
SSDT[128] : NtOpenThread @ 0x805C1522 -> HOOKED (d24eb7c11da0abb.sys @ 0xF74F833C)
SSDT[122] : NtOpenProcess @ 0x805C1296 -> HOOKED (d24eb7c11da0abb.sys @ 0xF74F8213)

But due to the fs attachement / CmRegister callbacks I'm not able to break either the file or the registry key.
Only able to kill the rogue with direct NtOpenProcess / NtTerminateProcess within the kernel + restoring the SSDT.

Maybe the key could be the detachement of the fs + delete the driver file? (And praying for no BSOD at reboot :roll: )


EDIT: I tried to implement a direct deletion of registry key in the driver, but it seems that even with calls to NtOpenKey / NtDeleteKey the callback is called then... :|
(I hoped it was only called with the "right way", using ZwXxx or NtXxx from ntdll)

[EP_X0FF]

CM callbacks calls at object level inside CmpParseKey, your API by design can't bypass it. Forget about registry - it's unimportant.

And praying for no BSOD at reboot

There is nothing to BSOD, this protection driver "wipes out" without any problem.

In case of any kind of self-protection (and this is malware self-protection somehow equal to several AV SP, what irony maybe even better than someone who propose it as key part of product) all this game overs when attacker (in this case you) loads it driver.

[Tigzy]

There is nothing to BSOD, this protection driver "wipes out" without any problem.

If the driver's file is deleted, nothing happen when the system tries to load it?

all this game overs when attacker (in this case you) loads it driver.

That's done, but the following isn't as obvious... (for me)

[EP_X0FF]

Why it should BSOD?

1. Bypass NtSecureSys driver loading block (it's totally lame - there are 3+ different ways to bypass it including methods that even not require reboot)
2. Locate and remember all FakeAV stuff (it's simple, because of SP)
3. Remove or skip trash it attached, remove driver file, kill fakeav (ObOpenObjectByPointer, ZwTerminateProcess), remove fakeav files, no need to unhook anything because it's unsafe
4. Reboot, clean registry

In case if you use boot driver, boot driver and wait for user mode request for cleanup after Windows loading completion.

[Tigzy]

1. Bypass NtSecureSys driver loading block (it's totally lame - there are 4 different ways to bypass it including methods that even not require reboot)

OK

2. Locate and remember all FakeAV stuff (it's simple, because of SP)

OK

3. Remove or skip trash it attached, remove driver file, kill fakeav (ObOpenObjectByPointer, ZwTerminateProcess), remove fakeav files, no need to unhook anything because it's unsafe

You do this in the DriverEntry, before the RK has been loaded? If yes there's a problem: As the whole stack a drivers isn't loaded yet, you'll probably won't be able to remove any file or delete any registry key.
And at this point, you won't also be able to get the RK's name back from a file. But maybe I'm wrong?

[EP_X0FF]

You do this in the DriverEntry, before the RK has been loaded? If yes there's a problem: As the whole stack a drivers isn't loaded yet, you'll probably won't be able to remove any file or delete any registry key. And at this point, you won't also be able to get the RK's name back from a file. But maybe I'm wrong?

Why should I do this in DriverEntry? I will do this by user mode app request which will prepare for me anything else. The less code you have in driver than better.

[Tigzy]

I asked this cause in the driver entry (assuming we are loaded before the RK in the boot order) all the RK's self protections are off.
I agree this is better to control everything with atomic functions from usermode.
But now that this is clear, how can you bypass the NTFS filter to delete the driver without shutdown the RK?

[EP_X0FF]

The answer was given in a few posts and even image.

[Tigzy]

By detaching the RK device from the NTFS stack?

EDIT: It's also attached to TCP/IP stack

1.png (2.68 KiB) Viewed 566 times