CFP- Poor Pop up alerts by compared with other HIPS?

[goodbrazer]

@wj32 post:38

you don’t need SeLoadDriverPrivilege in order to load drivers through the services controller (services.exe).

That explains. Thank you.
Strange thing: other application called Punto Switcher “tries to obtain LoadDriver priviledge”, too… but it never loaded and accessed any drivers.

@wj32 post:38

Did you read my previous explanation?

This one:

@wj32 post:32

OK, what I mean is: it’s just a test. I don’t want to actually load a driver, I just want to test the mechanism.

?
If so, yes i read it and understood.

[wj32]

@SS26 post:41

Strange thing: other application called Punto Switcher “tries to obtain LoadDriver priviledge”, too… but it never loaded and accessed any drivers.

You do know what privileges are, right? Just because a program enables a privilege for itself doesn’t mean its going to use it.

[goodbrazer]

@wj32 post:42

You do know what privileges are, right?

My level is “average”: I see word “driver” i know something serious is about to happen

[goodbrazer]

@wj32 post:40

Some of you might know about guard32.dll, which is a CIS component that is loaded into every process. The purpose of this component is to make alerts simpler for users. For example, if guard32.dll is disabled and a process attempts to create a service, the user will receive many prompts about services.exe trying to modify the registry.

Interesting. And full paths are displayed in this case…

I had no clue why alerts for installing driver (one technique) displayed correct paths (e.g. HKLM\System\ControlSet003\Services\driver_name), but other alerts for installing driver (another technique) displayed wildcarded path (HKLM\System\ControlSet???\Services\driver_name).

[wj32]

@SS26 post:44

wildcarded path (HKLM\System\ControlSet???\Services\driver_name).

Are those displayed by guard32? It’s possible that whoever coded guard32 put “ControlSet???” on purpose…

[goodbrazer]

@wj32 post:45

Are those displayed by guard32?

Access to “ControlSet???” alert is displayed for executable which attempt to install and load driver using services controller (attached pics).

update: these are displayed when guard32 is enabled.

[attachment deleted by admin]

[Citizen_K]

SS26. Would you be so kinds to post screenshots using the English interface? That makes things easier to understand.

[goodbrazer]

EricJH. Al right. Screenshots made in future will be in English. But those from my archieve remain as they are now (including those already attached).

[wj32]

@SS26 post:46

Access to “ControlSet???” alert is displayed for executable which attempt to install and load driver using services controller (attached pics).

update: these are displayed when guard32 is enabled.

Yes, that makes sense. Whoever coded guard32 decided to hook CreateService or a similar function in order to improve alerts (see my previous explanation), and put in the “ControlSet???” message. Why didn’t they use a better message such as “trying to create a service”? Who knows…

When TestDrivers.exe uses NtLoadDriver, it writes to the registry itself, guard32 doesn’t intervene, and the CIS driver catches it and displays an alert with “ControlSet003”.

[goodbrazer]

@wj32 post:49

Whoever coded guard32 decided to hook CreateService or a similar function in order to improve alerts (see my previous explanation), and put in the “ControlSet???” message.

@wj32 post:49

When TestDrivers.exe uses NtLoadDriver, it writes to the registry itself, guard32 doesn’t intervene, and the CIS driver catches it and displays an alert with “ControlSet003”.

Now when we know due to you how does Defense+ behave in these 2 cases,
would it be interesting to see Defense+ in action if neither services controller nor NtLoadDriver are used to load a driver?..

@wj32 post:10

There are two main ways a program can load a driver. One is by writing to the registry in HKLM\System\CurrentControlSet\Services and then calling NtLoadDriver. The other is by contacting the services controller (services.exe) and telling it to create a service to load the driver.

[bolded by me; does “main” imply there other, additional ways ?]

[wj32]

I used “main” because every sensible method of driver loading fits into one of those two categories. There are the methods I know of executing code in kernel-mode:

1. (XP only) NtSetSystemInformation with SystemLoadGdiDriverInformation. CIS already catches this.
2. (XP only) NtSystemDebugControl to write to kernel-mode memory. CIS hooks NtSystemDebugControl, so it should be detected.
3. (XP only) \Device\PhysicalMemory, same outcome as above. Should be detected.
4. NtLoadDriver. This can be used through the services controller or can be called directly.

[goodbrazer]

Many thanks for this information.

[sirio]

Thanks also from me wj32.