- Apr 1, 2017
- 1,782
what is it?
what about that PowerShell Dll? what about WMI? there more things that need to block:/
Shmu26 Config in 2018
- Thread starter shmu26
- Start date
- Jul 3, 2015
- 8,153
It puts memory restrictions on selected apps and processes, and it also prevents them from writing in system space. It also has an option for privacy protection, which is enabled by default for browsers. You manually define which files and folders are to be considered "private," and your browsers cannot read or write there.
- Apr 1, 2017
- 1,782
I see so it's a great feature! but I guess you can do the same with Sandboxie free
what about the registry?
I do have wmic in userspace = yes plus a bunch of other stuff.
In my older version I have *\reg.exe in userspace also
- Jul 3, 2015
- 8,153
Yes, sandboxing is stronger protection than guarded apps, but also more frustrating. Guarded apps does not really limit your productivity, and does not really break functionality.
About registry, there might be certain areas that it can write to. I think it will break a lot of apps if they have no access at all to registry. I can't say for sure, but I think that guarded apps blocks writing to critical registry areas but allows writing to certain other registry areas.
- Jul 3, 2015
- 8,153
Hardcore Appguard users have enough tweaks to block half of Windows. I am not one of them.
I am pretty happy with ReHIPS rules, I let them do most of the hard work for me.
You can block the powershell dlls either in Appguard or in Excubits products. I do it with Excubits MemProtect, so I can still have an allow rule for mscorsvw.exe.
- Apr 1, 2017
- 1,782
i guess I can block it with Eset hips as well but I'm not sure about it. i removed this dll btw
Lockdown can tell us.
Last edited:
- Jul 3, 2015
- 8,153
The basic idea of guarded apps is that malware cannot make system changes that will survive a reboot, and it restricts interaction with the memory of other running processes. This prevents both injecting into them and stealing data from them.i guess I can block it with Eset hips as well but I'm not sure about it. i removed this dll btw
Lockdown can tell us.
But the restrictions are not draconian, so the user usually doesn't feel them. It restricts the malware, not the user.
If you aren't downloading and installing unknown files then why even enable these settings in the first place ? You already know a PUA\PUP from a legit one and don't need some AV to tell you. Plus, these AVs are all over the place on what they classify a PUA\PUP and it doesn't help a lot of folks. And then there are those folks who are hell bent on installing the program no matter what the AV tells them.
The default AppGuard configuration provides high security. The product is software restriction policy - which means it can be made a whole lot more secure by someone willing to put forth some time and effort. A lot of people do not understand that software restriction policy is meant to be customized. It isn't a product that is pre-configured with a ton of policies. Note that I said policies and not rules. SRP uses policies whereas other security products use rules. The great advantage of SRP is that it is infinitely flexible, adaptable and can solve a huge range of security problems without the vast complexity of other products.
PowerShell, cscript, and wscript should be disabled. The vast majority of users do not need them and disabling them on a home system blocks a huge number of attacks.
That's about as overkill a security configuration as they come. I think it's bonkerz. I'll be surprised if you keep it for longer than a few weeks.
I keep telling you that PowerShell isn't needed - that it should be disabled. I wouldn't tell you that if it wasn't true. The PowerShell commands that Office, DropBox, etc runs during updates, repairs, etc are "empty" and do not break anything. You are needlessly exposing your system to risk by keeping PowerShell enabled - all for nothing.
Perhaps there is a program out there that really needs PowerShell to update, but I am unaware of it. Microsoft Office and DropBox definitely do not need PowerShell to update.
Browsers such as Chrome and Internet Explorer are added by default to the Guarded Apps list. Depending upon the version that you are using, Microsoft Edge might not be added by default.
Constrained Language Mode restricts powershell scripts, commands, and other code executed by either PowerShell and PowerShell_ISE whether from disk or in-memory and whether it is by the System32 or the SysWOW64 version.
i guess I can block it with Eset hips as well but I'm not sure about it. i removed this dll btw
Lockdown can tell us.
Block PowerShell.exe, PowerShell_ISE.exe and System.Management.Automation.dll.
If you can, use wildcard in your ESET rules:
*powershell*
*powershell_ise*
*system.management.automation*
Send me a PM and I will explain further.
Last edited by a moderator:
- Jul 3, 2015
- 8,153
I have a standard user account on my desktop that is used by a novice who has little patience for security. So I try to build my config in such a way that it will work both for noobs and for geeks. Right now, I am using KIS, but I might go back to Windows Defender.
Kaspersky has a strange way of dealing with PUAs\PUPs. Meaning, Kaspersky rates legit programs as PUAs\PUPs and a lets a lot of PUAs\PUPs to be installed.
Basically, this is the rule I see them following... Eugene Kaspersky does not want to be sued by the publisher, but if that publisher is running an open source project and isn't likely to sue, then you can bet the program will be blacklisted. Check it for yourself.
Last edited by a moderator:
- Jul 3, 2015
- 8,153
What I noticed is that Kaspersky, unlike some other AVs, does not care very much whether the program is legal or not.
But it consistently flags Process Hacker, which is a legal program, as potentially unwanted. It flags all Process Hacker processes, one after another.
Process Hacker can be abused that is why, but like I said earlier, what is the likelihood that the authors of Process Hacker will sue ? He's operating under Soviet, errr, ummm, Russian law.
- Jul 3, 2015
- 8,153
removed: Kaspersky
added: Windows Defender default settings
added: Windows Defender default settings
- Jul 3, 2015
- 8,153
The log in Excubits MemProtect recorded a blocked powershell event this morning, I am sure it was a Windows scheduled task, but I don't have a clue why:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe > C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\7f06bbe7908fb8d914459155ec6219e7\System.Management.Automation.ni.dll
That's just a PowerShell module and not a command or event. There's no context so I can't tell you anything.
- Jul 3, 2015
- 8,153
Thanks. Now I know what it was. I manually launched powershell_ise. and loaded a module. duh.
Last edited:
Lockdown is 100% right.
Process Hacker comes shipped with a vulnerable driver which can be operated by other third-party software, the source code is also open-source, making it easy for a malware author to understand what the correct IPC buffers it should pass to do XXXXXX (e.g. get the driver to terminate your AV's service from kernel-mode).
I don't use Process Hacker at all anymore because of this, not even with the driver disabled.
For the record, CPU-Z also has a vulnerable driver and their driver can be exploited to bypass your AV's self protection as well via NtDeviceIoControlFile.
VirtualBox also has a vulnerable driver which can be used to exploit PatchGuard's Driver Signature Enforcement (DSE) feature and load an unsigned device driver in a "driver-less" way (meaning the driver will not even show up on the ntoskrnl.exe imports list).
CPU-Z may have patched their driver years later but I doubt it.
Process Hacker comes shipped with a vulnerable driver which can be operated by other third-party software, the source code is also open-source, making it easy for a malware author to understand what the correct IPC buffers it should pass to do XXXXXX (e.g. get the driver to terminate your AV's service from kernel-mode).
I don't use Process Hacker at all anymore because of this, not even with the driver disabled.
For the record, CPU-Z also has a vulnerable driver and their driver can be exploited to bypass your AV's self protection as well via NtDeviceIoControlFile.
VirtualBox also has a vulnerable driver which can be used to exploit PatchGuard's Driver Signature Enforcement (DSE) feature and load an unsigned device driver in a "driver-less" way (meaning the driver will not even show up on the ntoskrnl.exe imports list).
CPU-Z may have patched their driver years later but I doubt it.
I would have thought Process Hacker authors would have patched that driver by now, but given that driver patching is a rigmarole with Microsoft it wouldn't surprise me that they don't do it.
I am using the Process Hacker nightly builds. Which driver is it so I can check ?
VirtualBox's driver not patched. And people call me a Microsoft-basher -- which I'm not -- as if Microsoft doesn't earn it all by itself.
Vendors using kernel-mode software should be taking precautions to keep their work safe against external usage.
For example, when handling IOCTL implementation, the device driver should always check what the caller process is by calling IoGetCurrentProcess routine and ensuring it's their own process via reliable authentication check techniques. For example, file-name, file-path, digital certificate and even custom byte pattern signatures embedded into the user-mode components which communicate with that kernel-mode component. For optimization purposes, the kernel-mode software can intercept process creation via PsSetCreateProcessNotifyRoutineEx and wait until a new process spawns with the process name of their user-mode image which will communicate with the kernel-mode software, and then perform checks and keep track of the right Process Identifiers for their own processes.
This would allow them to only allow requests to their kernel-mode software via techniques like IOCTL for processes with the right Process ID and would be strong against impersonation bypasses. They should also use IoCreateDeviceSecure instead of using the usually used IoCreateDevice routine and restrict IOCTL usage with their symbolic link to elevated processes only as another precaution.
Alternative methods would be secure named pipes implementation from kernel-mode (you can still create named pipes in a normal kernel-mode device driver via IoCreateFile which NtCreateNamedPipeFile calls) or secure ports IPC implementation. And enforce administrator rights to use the IPC method at-least as a minimum and still verify the requester....
All memory allocation should be done with the required and minimal memory protection. I see a lot of vendors setting NonPagedPool in kernel-mode for a unicode-encoded buffer, like what? You don't need executable rights for that for god sake, you only need RW minimum. I doubt Process Hacker does this one though, it's just something I noticed recently with some vendors products. Microsoft themselves even recommend to use NonPagedPoolNx now, they even flag warnings sometimes with WDK. For backwards compatibility when working on a driver for Windows 7 and below, just use a macro. Problem solved.
processhacker/processhacker
I don't see any verification of the caller making the IOCTL request in the above source code, unless this is outdated or I am blind and haven't realized where the authentication check is being performed (which is unlikely).
At-least if NtOpenProcess or NtTerminateProcess is hooked in user-mode you could do IOCTL to the device driver with KPH_OPENPROCESS and KPH_TERMINATEPROCESS IOCTL codes instead of bothering to do a direct system call yourself.
For example, when handling IOCTL implementation, the device driver should always check what the caller process is by calling IoGetCurrentProcess routine and ensuring it's their own process via reliable authentication check techniques. For example, file-name, file-path, digital certificate and even custom byte pattern signatures embedded into the user-mode components which communicate with that kernel-mode component. For optimization purposes, the kernel-mode software can intercept process creation via PsSetCreateProcessNotifyRoutineEx and wait until a new process spawns with the process name of their user-mode image which will communicate with the kernel-mode software, and then perform checks and keep track of the right Process Identifiers for their own processes.
This would allow them to only allow requests to their kernel-mode software via techniques like IOCTL for processes with the right Process ID and would be strong against impersonation bypasses. They should also use IoCreateDeviceSecure instead of using the usually used IoCreateDevice routine and restrict IOCTL usage with their symbolic link to elevated processes only as another precaution.
Alternative methods would be secure named pipes implementation from kernel-mode (you can still create named pipes in a normal kernel-mode device driver via IoCreateFile which NtCreateNamedPipeFile calls) or secure ports IPC implementation. And enforce administrator rights to use the IPC method at-least as a minimum and still verify the requester....
All memory allocation should be done with the required and minimal memory protection. I see a lot of vendors setting NonPagedPool in kernel-mode for a unicode-encoded buffer, like what? You don't need executable rights for that for god sake, you only need RW minimum. I doubt Process Hacker does this one though, it's just something I noticed recently with some vendors products. Microsoft themselves even recommend to use NonPagedPoolNx now, they even flag warnings sometimes with WDK. For backwards compatibility when working on a driver for Windows 7 and below, just use a macro. Problem solved.
kprocesshacker.sys
processhacker/processhacker
I don't see any verification of the caller making the IOCTL request in the above source code, unless this is outdated or I am blind and haven't realized where the authentication check is being performed (which is unlikely).
At-least if NtOpenProcess or NtTerminateProcess is hooked in user-mode you could do IOCTL to the device driver with KPH_OPENPROCESS and KPH_TERMINATEPROCESS IOCTL codes instead of bothering to do a direct system call yourself.
Similar threads
