Here is what I do. I place their folder in Programs (x86) and execute the driver install. Also you must place the ini file in c:\windows or nothing will happen. The other thing I do is create a shortcut to the tray.exe file. I place that short cut in windows startup folder so it will start with windows.
And if you wanted to white list it here is what you take and enter in the config file
C:\Users\Temp\Downloads\7z1700-x64.exe but I would do this
C:\Users\Temp\Downloads\7z*x64.exe instead
Note there are some rules regarding the ini file.
1. Must save it as unicode
2. Becareful of spaces. If they are there the rule will just be ignored.
3 Beware there most be a blank entry at the end of the file EOF or it won't run.
Also when you modify the config file and save then go to the tray app, select MZwritescanner and restart
And if you wanted to white list it here is what you take and enter in the config file
C:\Users\Temp\Downloads\7z1700-x64.exe but I would do this
C:\Users\Temp\Downloads\7z*x64.exe instead
Note there are some rules regarding the ini file.
1. Must save it as unicode
2. Becareful of spaces. If they are there the rule will just be ignored.
3 Beware there most be a blank entry at the end of the file EOF or it won't run.
Also when you modify the config file and save then go to the tray app, select MZwritescanner and restart
I'm seriously considering adding MZWriteScanner to my machine and buying a license.
The forensics option looks interesting, have you tried using this feature?
The one thing that concerns me though is that MZWriteScanner doesn't block a dropped file after a service restart or the machine is rebooted. So this means after a reboot that malicious exe that was dropped before the reboot could now run...
I'm seriously considering adding MZWriteScanner to my machine and buying a license.
The forensics option looks interesting, have you tried using this feature?
The one thing that concerns me though is that MZWriteScanner doesn't block a dropped file after a service restart or the machine is rebooted. So this means after a reboot that malicious exe that was dropped before the reboot could now run...
True, but solution is simple, If the tray icon is red look at it before rebooting. The other thing, is what else would have even told you something had been dropped
I restarted the service and cleared the log before testing. I then downloaded 7-Zip but the icon stayed green? But I did see an entry in the log when I opened it:
Edit: Seems to be working now. I'm not sure if something was cached but I cleared the log and restarted the service and I have copied some test exes into a folder and the icon goes red and I can see the details of what is going on in the log. I'm impressed so far!
So it looks like it creates an entry for the exe in the $FORENSICS folder but uses the hash for the filename? I was expecting the exe name for some reason.
For convenience I have created a junction to a the $FORENSICS folder:
I have a meeting with Florian (owner/developer of Excubits, company behind MemProtect) in December 11th in Amsredam. We will talk about preconfigured sandbox (combining MemProtect and Pumpernickel). Maybe with user supported help forum.
I will be very busy until December, so may be visiting MalwareTips less frequently, but will be checking this thread. so when uou have ideas or suggestions, feel free to post it here.
Could this point be explained a little?
Let's talk about a ransomware using process hollow. With MemProtect, the hollowed process will remain in the memory cage. But it can still perform any action that doesn't mess with the memory of another process. That means it can modify files. So how does this prevent it from encrypting files?
That isn't true. MemProtect will affect impact on performance because it'll be intercepting all handle creation/duplication requests and most likely for other operations such as thread creation - the action can't be completed until the callback consents to it (FltRegisterFilter & ObRegisterCallbacks).
I think what you meant is that it feels light (no noticeable impact).
That isn't true. MemProtect will affect impact on performance because it'll be intercepting all handle creation/duplication requests and most likely for other operations such as thread creation - the action can't be completed until the callback consents to it (FltRegisterFilter & ObRegisterCallbacks).
I think what you meant is that it feels light (no noticeable impact).
NO: Memprotect activates the Windows build-in Protected Process mechanism. Since the documentation of Protected Processes differs from INI-file command structure, I assume MemProtect has to monitor which processes are started, to activate the run as protected process.So YES MemProtect adds some overhead (but it does not monitor the usual stuff HIPS program all have to monitor when trying to achieve the same level of protection) and I should have said NO NOTICEABLE IMPACT on performance.
@Windows_Security MemProtect doesn't activate the Windows built-in Protected Process mechanism. This is enforced internally by non-exported NTOSKRNL routines and the checks are performed by Windows by checking the flags under the EPROCESS structure for the targeted process. There's an entry under this kernel-mode structure called ProtectedProcess (0 value means the process is not protected and the value of 1 means the process is protected). The sort of non-exported routines which perform such checks would be PsOpenProcess (which would call the PsIsProtectedProcess routine -> checks the EPROCESS structure).
Microsoft issue out special certificates which can be used for security vendors to have their processes spawned as protected under this mechanism; there's also a "light" variant of process protection on modern versions of Windows. The non-exported kernel-mode routines which handle these checks are eventually called down the line. For example, if you call OpenProcess (KERNEL32) in user-mode it will land at the NtOpenProcess stub within NTDLL which will perform a system call and then NtOpenProcess (NTOSKRNL) will be called -> eventually the non-exported routines are called before the handle is acquired. Not all vendors use this mechanism even when they have access to it, they tend to combine ObRegisterCallbacks among other mitigations.
You can patch the structure for a specific process but it would not work on each OS version the same/each patch update (necessarily) because offsets for the kernel-mode structures can be changed at any given time, and they are especially changed for structures like EPROCESS and KPROCESS regularly. Which would require checks for each OS version and specific build, and fast updates for new Windows updates. This counts as kernel-mode patching however PatchGuard does not intervene with this.
MemProtect doesn't monitor process execution; you can achieve this with PsSetCreateProcessNotifyRoutine, PsSetCreateProcessNotifyRoutineEx or PsSetCreateProcessNotifyRoutineEx. The MemProtect driver follows the File System Mini-Filter framework because it uses the FltRegisterFilter callback for the Pumpernickel functionality, and alongside this it registers the ObRegisterCallbacks callback so it can strip various access rights of "protected" processes for handle open/duplication requests for the targeted processes themselves but also their threads.
I'm not saying MemProtect is a bad product, I like it... I was just saying that it does use CPU usage because you said on a post that it uses like no CPU cycles.
It is all good mate and I am looking forward to your future projects
Using layman terms to an insider is asking for confusion because there is no such thing as an "Run As Protected" process. MemProtect does not need immediate updates after an major OS-updates, so (using your explanation) it does not seem to patch. With my limited knowledge I thought that the CreateProcessNotify routines were asynchronous. If that is true (again with my limited knowledge) a time gap would theoretically exists (time between actual start/creation of a new process and the setting of the protected process flags)? Would be interesting when you could try MemProtect and open the lid of the magic box of MemProtect a little (how does MemProtect applies protected processes (light) limitations?
@Windows_Security I did look at MemProtect which is how I know it uses ObRegisterCallbacks. If you're certain that it forces the Protected Process flags on a process and that I am incorrect then I respect this, but I found no evidence of this occurring. To my knowledge from when I tested it out it strips access rights for protected processes to prevent the following access rights being granted to a protected process (or its threads): - PROCESS_CREATE_PROCESS
- PROCESS_TERMINATE
- PROCESS_VM_OPERATION
- PROCESS_VM_READ
- PROCESS_CREATE_THREAD
- PROCESS_VM_WRITE
- PROCESS_SUSPEND_RESUME
- PROCESS_QUERY_INFORMATION
- PROCESS_ALL_ACCESS
- DELETE
- READ_CONTROL
- WRITE_DAC
- WRITE_OWNER
- SYNCHRONIZE
- PROCESS_DUP_HANDLE
- PROCESS_SET_QUOTA
ObRegisterCallbacks is registered using callback registration data which is contained within a kernel-mode structure known as OB_CALLBACK_REGISTRATION. The structure passed in contains an entry to another structure known as OB_OPERATION_REGISTRATION which holds data regarding the callback routines for the even notifications. The kernel-mode callback supports a Pre and Post callback notification for handle open/duplication requests; access rights stripping is performed on the Pre callback notification via bit-mask modification (e.g. a variable containing multiple flags for access rights -> you strip the ones you are interested in blocking only -> access denied is returned to the caller because the request failed).
The access rights data is stripped from a pointer structure passed to the Pre operation notification callback routine known as OB_PRE_OPERATION_INFORMATION (entries within that structure which is passed as a pointer contain data for the notification).
MemProtect will check if the process being targeted for handle creation/duplication has the same image file path as any programs set to be protected via the configuration file.
This isn't forcing Protected Process/Protected Process Light, and if an update isn't required to be issued after a Windows patch update/major OS version update then this already means that such isn't enforced because the structure entry offsets in kernel-mode structures like EPROCESS are regularly changed and targeting the wrong one would cause a BSOD -> it's neither officially supported nor documented to do this because Microsoft only want processes being protected this way which have the special signature they issue out. There's no supported mechanism for automatically resolving the correct offsets as far as I'm aware, it wouldn't make any sense if there was considering Microsoft cannot stand people patching in kernel-mode (hence why they introduced the callbacks which MemProtect uses!).
To make things as easily as possible to be understood, MemProtect basically protects processes using a technique that most traditional security software will use protect their own processes in conjunction with their other self-protection techniques. This is why you cannot terminate one of the MemProtect protected processes from the Details tab on software such as Task Manager, but can still attack the processes via other attack vectors such as their windows if they have one.
I think that this is all a good thing because this also means that MemProtect is stable to run on Windows Vista - 10 systems for both 32-bit and 64-bit.
Anyway to see the callback is being used at ease without knowing much about kernel-mode development you can use a tool that @Sunshine-boy likes to use called PC Hunter which appears to be some sort of scanner for rootkits. There's a tab for callback registration and you'll find the MemProtect driver listed under it.
I did look at MemProtect which is how I know it uses ObRegisterCallbacks. If you're certain that it forces the Protected Process flags on a process and that I am incorrect then I respect this, but I found no evidence of this occurring.
No I don't know, I was just wondering when the notify routines were used how would the time gap between notify and protected process flag setting be handled assuming MemProtect used these flags. I assumed that Memprotect used the flag mechanism because it does not seem to patch them. Thanks for further explaning the register callback mechanism which MemProtect uses.
MemProtect will check if the process being targeted for handle creation/duplication has the same image file path as any programs set to be protected via the configuration file.
Do I understand correctly that the "Pre and Post (register) callback notification" is triggered by the Operating system, when a "handle open/duplication request" is issued by another process (in layman terms when "The processes are targetted for creation/duplication")?
Is it correct to assume that Memprotecs then suspends the REQUESTING process when the image file path of the TARGETTED process matches any of the INI-files paths (or wildcard masks)?
Could this point be explained a little?
Let's talk about a ransomware using process hollow. With MemProtect, the hollowed process will remain in the memory cage. But it can still perform any action that doesn't mess with the memory of another process. That means it can modify files. So how does this prevent it from encrypting files?
Do I understand correctly that the "Pre and Post (register) callback notification" is triggered by the Operating system, when a "handle open/duplication request" is issued by another process (in layman terms when "The processes are targetted for creation/duplication")?
You understand correctly about how the callback works; the notifications registered by any driver for intercepting handle open/duplication requests is invoked the same way by the Windows Kernel (not just for the MemProtect software). I'll explain it in a bit more detail below but don't worry if you don't understand it properly.
There's a function called NtOpenProcess exported by NTOSKRNL. NTOSKRNL is the Windows Kernel (hence why it is a kernel-mode image) and all the kernel-mode device drivers are added as modules to NTOSKRNL, because they are running under the Windows Kernel (instead of having less privileges as user-mode code in ring 3). If you find the System process on a utility like Task Manager and check the Properties, you'll find all the loaded kernel-mode device drivers under the Modules tab for this reason. A module loaded in every single user-mode process named NTDLL exports various stubs named for Nt* routines (and also Zw* but they point to the same addresses as the Nt* stub copies). The reason for this is because the Win32 API usually internally calls Native API routines through the less documented/lower-level modules (such as NTDLL), and these will perform system calls... For example, an injection method through Extra Window Memory using a function called SetWindowLong (USER32) will internally call NtUserSetWindowLong (WIN32U) and the NtUser* variant will make a system-call to get win32k.sys to execute the NtUserSetWindowLong function (because the routine actually exists in kernel-mode memory but this mechanism is implemented because the kernel supports functionality so it all leads down back to that for these sorts of things). Now in regards to process/thread handles, there are functions such as OpenProcess, OpenThread, DuplicateHandle (all from KERNEL32). When those are invoked, NtOpenProcess, NtOpenThread, NtDuplicateObject are all invoked by those Win32 APIs (the correct one -> correct NT routine equivalent -> all those three are from NTDLL). Now what NTDLL does is perform a system call so the Windows Kernel receives the request... And the function ID of the function needing to be called is stored in a register EAX (so the routine invoked from the SYSCALL instruction for example -> relies on MSRs) will check the contents of EAX and then it'll redirect execution to the correct routine present under NTOSKRNL. However these routines even though they are kernel-mode, they'll rely on other routines which are kernel-mode only (some will be exported but then even those exported ones -> call non-exported ones).
If you understand the above then the following is the last elaboration to help you understand how the callbacks are invoked: functions within NTOSKRNL which were implemented by Microsoft when they invented the idea to stop kernel-mode patching (e.g. stop SSDT patching, inline NTOSKRNL hooks via byte-patching, etc.) will be invoked by these kernel-mode routines. So for example NtOpenProcess probably won't invoke it there, but it'll probably invoke another routine which is kernel-mode only and then THAT routine will invoke the APIs related to callbacks -> now the kernel checks which callbacks are registered once these APIs are used -> execution flow is granted to the Pre/Post routines of the callbacks with parameters sufficient for data (pointers so you can change the data such as status codes to block operations) -> waits until that is over and then continues. For callbacks that intercept and can do their business BEFORE the action is completed and has pointer structure for the data, it can be manipulated so once the callback has finished its job and the routine that invoked the callback APIs to do the check and redirection returns back, the original routine will continue as it left off. However if the data was modified then this means even if the call continues down the line, it will be blocked because of incorrect data (or for some callback routines like for process creation interception, you set an NTSTATUS error code so after your callback -> the status is checked and if it isn't STATUS_SUCCESS for example then it returns the code manually set by you -> now the execution is stopped and blocked).
So when it comes down to ObRegisterCallbacks like with MemProtect (or any AV that uses this technique as one for self-protection of their own processes), in the Pre operation callback you strip the access rights you don't want to grant if they are set for the access rights. It is to do with bit-masking so one variable can hold many different flags at once, e.g. PROCESS_VM_OPERATION being granted allows you to remotely allocate and write to the memory of the process you opened a handle too, PROCESS_TERMINATE allows you to terminate the process with the handle, etc... So you could do PROCESS_VM_OPERATION | PROCESS_TERMINATE = both of them are now the access rights. So in the callback you'd do a conditional statement check to check which ones are included which you are interested in and then strip them out. Since you removed access rights which were requested for the handle, the operation gets blocked because it fails... The caller wanted access rights X and didn't get it = STATUS_ACCESS_DENIED. Which explains why when you try to terminate a protected process being protected by a driver using the callback, you get that Access Denied error.
So all in all it does protect processes but in my opinion you need to do a lot more than just protect a handle to the process and threads. Windows is insecure so it isn't really a developers fault, there's so many ways to do things. Aside from abusing windows as a target for remote code execution (e.g. NtUserSetWindowLong technique for ROP chain exploitation, NtUserSetWindowsHookEx for window hooks RCE) you could even abuse a Windows process from standard rights to find a way to obtain a HANDLE without it being intercepted by a device driver using ObRegisterCallbacks. If you have admin rights and a process like csrss.exe (Windows 7) or lsass.exe (Windows 8+) is not protected then you could byte-patch that to detour NtOpenProcess and auto-gain handles with sufficient access rights to do RCE without being stopped by ObRegisterCallbacks as well (because system processes that obtain handles for newly started processes always bypass those documented and supported mechanisms). There's also ways to load modules into a process without PsSetLoadImageNotifyRoutine being able to stop it (there was a vulnerability exploited by researchers a few months back which supported loading modules and causing the registered callback to not receive correct info so it couldn't check if the module should be allowed or blocked properly).
Mash up of Windows Internals spam above, I know... If you understand it then great but if you don't then don't worry about it because I don't want to confuse you and if you get confused then it can just cause more hassle for you
Is it correct to assume that Memprotecs then suspends the REQUESTING process when the image file path of the TARGETTED process matches any of the INI-files paths (or wildcard masks)?
I don't think it would do this, I didn't see it do this at-least. You can test it by setting a config to not allow Task Manager to attack a protected process, then see if Task Manager gets suspended when attacking the protected process. It'd be a silly thing to do that anyway considering a process may try to open/duplicate a handle to a process and/or one of its threads for any given reason, and MemProtect blocks PROCESS_QUERY_INFORMATION and similar so if something tries to query info about a process using a handle it needs to obtain, it'd get suspended and stopped from working. And this would just cause so much hassle and drama on a daily-basis usage I'd imagine.
You can still suspend in kernel-mode of course as that is where that functionality is embedded into the kernel but it isn't officially supported by Microsoft for people to do this. I wrote a thread awhile back which had demo source code for doing this. NtSuspendProcess/NtSuspendThread isn't exported by NTOSKRNL and finding the SSDT with byte scanning isn't necessary when you can call the functions that those routines would call anyway which are exported by NTOSKRNL (KeSuspendProcess/KeSuspendThread). Process suspension routines like NtSuspendProcess -> KeSuspendProcess -> ends up enumerating the threads and suspending them anyway. Process suspension = thread suspension. A process doesn't execute the code technically, the threads within the process do. A process is nothing but a shell containing data about the image executing in memory, and the threads are responsible for executing the instructions -> Instruction Pointer from the CPU tracks the current address -> CPU executes instructions at the address of the Instruction Pointer (or Instruction Counter if you prefer).
On that note though, move the config stuff for MemProtect to an elevated folder if you can (and protect it with the config which Pumpernickel would handle) otherwise an attacker can exploit it by changing your config to unprotect processes (or add to the config to protect a rogue one abusing MemProtect haha) with standard rights. Another good idea would be to protect against driver unloads if it doesn't already because if not then an elevated process could just use the uninstallation cmd script that MemProtect uses itself for uninstallation to just rid the protection, and I assume you'd also want an elevated process not to bypass the process protection for handles
Sounds unrealistic but I'm a security researcher so it is sort of my mind-set to always think of possible ways something can be exploited or can't be, and since I don't know who the developer is but you do, you could probably ask about that if you were interested and thought it was a good idea
All in all I think that MemProtect using the documented kernel-mode callback for protecting processes is better than it doing things like patching kernel-mode structures because this makes MemProtect stable and compatible from Vista - Windows 10 for both x86 and x64 without constant updates or unexpected crashes after a Windows patch update.
You're also right about performance, MemProtect doesn't cause a noticeable one. I think it is quite lightweight
Pumpernickel supports preventing modifications to files so you can prevent documents being encrypted by ransomware if the malicious process wasn't configured to touch those protected documents. MemProtect uses FltRegisterFilter which is used by pretty much all large security vendors for intercepting file-system events in real-time and they get many different callbacks for Pre and Post operations. There's like a massive chain of callback routines which get passed through. There are also different levels assigned so some drivers can intercept quicker than others and it leads down until the last one of the chain has done its checks -> operation proceeds.
MemProtect is quite light so the file system operations don't hang up to cause a noticeable slowdown, the checks are done quickly in the callbacks for interception. It can pretty much control access/read and write, etc.
So it can be used to protect against ransomware encrypting protected documents/documented in a protected directory.
