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

.sys files being written to protected folder directories is very different from .sys files achieving privileged access. For those following the discussion, I made one final post that sums up this point and more; all of the discussion relating to poor pop up alerts, with explanations and details for those who are interested. Once again, it’s at this thread:


Thanks for sharing info about driver loading techniques. Due to this info i have set up D+ reasonably: warning when services.exe is calling NtLoadDriver (second technique you mentioned) is now available on my system - see attached screenshot (alert is not in english, it tells “services.exe tries to load a driver” etc like “services.exe is trusted, but dpclat_driver.sys could not be recognized”). Second screenshot captured when running your test program.
Is that missing alert you reffered to?

[attachment deleted by admin]

D+ config was changed in following way:

  • set D+ to Paranoid mode;
  • located %windir%\system32\services.exe under Computer security policy and changed everything to ask instead of default values (not sure these were default though).

Or you can just set services.exe to ask for Device Driver Installations :slight_smile:

What’s the most secure yet flexible access rights configuration for explorer.exe, rundll32.exe and services.exe?

I’m just curious, I want to know what access rights:

  1. are safe to allow
  2. should be set to ask / block.

If only this could be done in clean PC mode.


It can be done in any mode, excluding training mode :slight_smile:

In clean PC mode device driver installation automatically gets set to allow. You cannot have it on ask.


Before I posted my comment, I did some testing.
I suggest you do some testing as well.


Is it necessary condition that driver should be file (.sys) on hard disk in order for it to be loaded? Or driver “body” can be saved to memory (RAM), from which it can be loaded (without .sys file on hard disk)?

Why these questions appeared:

Every app that installs driver(s) i launched so far creates 2 things: appropriate registry entries and .sys file. Only after that there is an attempt to load driver.
However, your test program creates only registry entries, then there is an attemp to load driver (in both cases for both techniques of loading a driver).

To load a driver using the standard OS mechanism, you must have a driver file. That doesn’t mean it has to be on the hard disk, though. You could have a ramdisk (though I doubt anyone would use one to store and load a driver).

However, your test program creates only registry entries, then there is an attemp to load driver (in both cases for both techniques of loading a driver).

That’s because it doesn’t attempt to load a driver (that exists). Partly due to my laziness.

That's because it doesn't attempt to load a driver (that exists).
I see...

Thank you for this info :-TU

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.

I don’t know if I have well understands ;D, however I have made this test:

CIS 3.12 in Proactive Security at default

Instead adding these items
we will have:

Regards :slight_smile:


How did you know exact entries to add to the list (\RPC Control\ntsvcs and LocalSecurityAuthority.LoadDriver)? I dont see them in the list of all COM components available…

KProcessHacker driver can be stopped from loading in the first case by alert of D+ (after red one) “services.exe tries to load driver KProcessHacker.sys” (attached screenshot). If so… seems like those additional 2 alerts (due to added COM entries) are not critical to miss.

[attachment deleted by admin]

It is true :), adding these 2 entries we don’t increase the security, we only have some popups in more to understand better the dangerous activity, that then, if I have well understands, it is the matter of the thread.

For \RPC Control\ntsvcs, it did part of My Protected COM in the previous versions to the 3.8 of CIS, this was due to the different structure of the Computers Security Policy…
Instead, for LocalSecurityAuthority.LoadDriver, looking at the previous entries in Pseudo COM Interfaces - Privileges and based to the list of the super privileges for LSA:

  • Debug programs A user with this privilege can open any process on the system without regard to the security descriptor present on the process. The user could implement a program that opens the LSASS process, for example, copy executable code into its address space, and then inject a thread with the CreateRemoteThread Windows API to execute the injected code in a more-privileged security context. The code could grant the user additional privileges and group memberships.

  • Take ownership This privilege allows a holder to take ownership of any securable object by writing his own SID into the owner field of the object’s security descriptor. Recall that an owner is always granted permission to read and modify the DACL of the security descriptor, so a process with this privilege could modify the DACL to grant itself full access to the object and then close and reopen the object with full access. This would allow the owner to see sensitive data and to even replace system files that execute as part of normal system operation, such as LSASS, with his own programs that grant a user elevated privileges.

  • Restore files and directories A user assigned this privilege can replace any file on the system with her own. She could exploit this power by replacing system files as described in the preceding paragraph.

  • Load and unload device drivers A malicious user could use this privilege to load a device driver into the system. Device drivers are considered trusted parts of the operating system that can execute within it with System account credentials, so a driver could launch privileged programs that assign the user other rights.

  • Create a token object This privilege can be used in the obvious way to generate tokens that represent arbitrary user accounts with arbitrary group membership and privilege assignment.

  • Act as part of operating system LsaRegisterLogonProcess, the function a process calls to establish a trusted connection to Lsass, checks for this privilege. A malicious user with this privilege can establish a trusted-Lsass connection and then execute LsaLogonUser, a function used to create new logon sessions. LsaLogonUser requires a valid user name and password and accepts an optional list of SIDs that it adds to the initial token created for a new logon session. The user could therefore use her own user name and password to create a new logon session that includes the SIDs of more privileged groups or users in the resulting token.

Sorry for my English, thanks.


Thanks :-TU

Currently D+ in safe mode triggers alert when services.exe is about to load driver when .sys file is not in the whitelist. When autolearning was removed? I’m sure exactly same alerts were autolearnt by D+ in safe mode previously ??? update: problem with autolearning is still present.

…Some applications do not trigger alert similar to the one mentioned previously, despite ‘LocalSecurityAuthority.LoadDriver’ is in the list of Protected COM Interfaces. For example, DPC Latency Checker. It uses services.exe to load driver, too.

  1. There’s going to be some confusion when using Process Hacker for testing, since it enables SeLoadDriverPrivilege not in order to load KProcessHacker, but to be able to unload drivers. Hence that was a bit of a red herring - you don’t need SeLoadDriverPrivilege in order to load drivers through the services controller (services.exe).
  2. Did you read my previous explanation? You need SeLoadDriverPrivilege to manually load drivers, but you don’t need it if you’re using the services controller. That’s why the DPC latency checker isn’t triggering the alert.

Have been testing out online armor on my spare PC and I must say… I really like the way alerts are displayed.

I’ve just discovered an interesting fact…

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. If guard32.dll is enabled and a process attempts to create a service, guard32 will let CIS know about this, a different prompt will be displayed, and the registry alerts from services.exe will be suppressed.

The “different prompt” is in fact the “trying to modify the protected registry key” prompt. So, it should be very easy to change it to “trying to load a driver” or something similar.