Download Process Hacker
Kanisha Dezarn
This is a valid detection. We've decided to start detecting Process Hacker because it's abused by malware and especially by ransomware. If you added Process Hacker yourself and do not wish to see the detection, please add it to your allow list.
For the benefit of anyone else who runs in to this detection, you may want to update the blog article on Process Hacker, as it currently indicates that Malwarebytes does not detect it (the first note at the very end of the article). The link is -tos/2018/11/advanced-tools-process-hacker/.
It's a blog post from three years ago. I'm sorry but no one goes back and edits documents that are ancient. It becomes rather obvious to most users that something posted three years ago is highly unlikely to be relevant today, but thank you for your feedback
How is 'Process hacker' more dangerous then Sysinternals's Process Explorer, or Task Manager, or any of the other hundreds of other process management tools out there? When is it abused by ransomware? Just because something perfectly legit is being abused by malware doesn't mean it should be outright blocked (and deleted). I often use Malwarebytes on VMs, which are reset every time, so adding it to the allowlist doesn't really work.
ProcessHacker is used in targeted attacks to companies more lately, used manually, not packaged with mass-malware. It's true it's not malicious, but when abused by malware if becomes riskware. Based on shifts in the threat landscape we sometimes have to change our minds to protect our users against shifts in thread landscape. If attackers switch to using alternatives to ProcessHacker, we might have to evaluate adding some form of detection for those as well. Likewise, if they stop using it, we can also remove the detection in the future.
For those of you who use it, which I understand completely as I've used it extensively myself in the past, adding an exclusion for the path where ProcessHacker resides should be fairly straightforward.
Download the Portable version. Extract the files to a new folder of your choosing. In my example I created a C:\ProcessHacker folder.
Then right-click and select to have Malwarebytes scan the folder
The complaint that ProcessHacker is Riskware, in as much as malware can use it to do naughty things, strikes me as disingenuous boardering on a dissembling lie. By that simple definition almost anything on the computer that can shut down a program is RiskWare. Singling our ProcessHacker, as well as not working with the PH authors to mitigate trouble, suggests something more nefarious is afoot and directed specifically at ProcessHacker. Bad form leading to distrust.
Question to someone who works here: How/when can I start being able to edit my comments, because I just ending up having to create a new comment & spam that thread whenever I need to post a correction (which is often)
As you can see on the screenshot, KIS blocking access to process hacker program although I do have it on my list of excluded from scanning programs. With KIS turned off, I have no issue to access this program. What should I do?
I'm the lead developer/owner of these binaries so some clarification is required... These binaries are compiled automatically by Github and Appveyor (third party companies)... So if the binaries contain malware that implies the github repository is also infected with malware?
Malwarebytes is currently detecting our x86 executable, not the x64 executable and also not the driver... It's also not including detections for the last stable release v2.39 from 2016... So what you've said makes zero sense because otherwise you would blacklist the stable version and the driver, not the x86 nightly build.
At any time you could have contacted us and reported a problem but choose not to and instead attacked/blocked our project binaries which goes against everything that was written by Malwarebytes about our project: -tos/2018/11/advanced-tools-process-hacker/
Our security policy clearly states you can report issues privately and even includes our personal email addresses... You can't go around saying our project is malware, then saying the project has security issues, then saying no security issues but that it's abused by malware when its an actual human operator using RDP - then refusing to report issues to the development team... this is highly unethical to say the least.
If our project is being abused by malware then there's a security issue and you should be doing the right thing and reporting it to us... If it's simply being used over remote desktop then that's a human operator using the project, not actual malware which is a major difference between the two - misconstruing the issues does nothing to help anyone and just makes the issue worse.
I was referring to Dharma/Crysis... What good does mentioning it more than 3 years later achieve? You should have brought it up years ago, something could be done about the issue but instead you've kept quiet about it and prolonged the attack so it would cause more damage and justify targeting our project.... We could have done something if you bothered to reach out and let us know earlier!
What does that even mean exactly? You already stated "Malwarebytes does not detect Process Hacker as malicious or potentially unwanted."? I will gladly share the conversations with other vendors such as Avast who demanded a backdoor in our kernel driver - which we refused so we remain blocked by Avast- and Sophos who blame me for every Windows RDP attack - which we demanded evidence despite the company never responding....... I also have emails from Microsoft employees committing fraud which you're guaranteed to know about within the next few weeks.
There are currently 967 nightly builds - more than enough samples to train your ratio calculator or "machine learning"... There really isn't any excuses here for constantly declaring our binaries as malicious when no such thing exists. Stop with the deflections about ML and mentioning other vendors which have no bearing on issues with false positives by Malwarebytes... It should be a simple issue to resolve.
Whitelisting is being ignored and overridden... This is also breaking CTRL+ALT+DEL for users since the IFEO keys are being left behind but the executable deleted by Malwarebytes. The kernel driver, plugins and \x86\processhacker.exe are also being left behind but since the uninstaller is deleted users have to manually remove these files and/or reinstall then uninstall which is not optiminal and leaving users confused... I've already had users complain about this in GH #822 where they thought we hadn't provided an uninstaller but it was in fact deleted.
Labelling binaries "Malware" which contain no actual malware is misleading and "unconscionable conduct" per the ACL regulation... I'm going to file a complaint with the regulator if this continues. Breaking CTRL+ALT+DEL for users is another major issue that Malwarebytes needs to resolve as well.
Some tips to help us prevent this. Digitally Signing the files goes a long way. Also filling out the version info tab of files. I could do more predictive whitelisting for future versions if either was in place on the files.
Do you have an example of the ifeo keys? I am trying to investigate why we broke it but i cant seem to get the keys to be created here. I also whitelisted the main executables from malware.ai detections in a more broader way that should help prevent future fps.
Digital signing would be ideal but we're currently blocked/banned from the developer dashboard by Microsoft after they changed the attestation signing policy excluding individuals from code signing... I did setup a company but I still can't validate the certificates with Microsoft for code signing for some reason they refuse to explain:
The Microsoft support team just says "This issue surpasses our support" and immediately close the tickets so we haven't been able sign our code and I've wasted a fair amount of time and money on that already... I'm going to be filling some cases against Microsoft for this because we need to sign our code and their policy is anticompetitive.
The versioninfo is configured for the executables but was removed from the plugin DLLs after an anticheat product released a debug driver hard-coding the versioninfo strings and blocking PH from loading plugins... Malwarebytes hasn't deleted the plugins only the executables. The plugins should be ok for now without versioninfo? I will be adding updated versioninfo for the plugins later this year when it's more likely users have an updated anticheat driver.
Microsoft should honestly provide a mechanism for users to change the default. They've already been fined $1.3bn for preventing users from changing the default web browser and not having options to change the default task manager should have been included a long time ago.
Malwarebytes deleted the main executable (processhacker.exe) however it never removed the IFEO key for taskmgr.exe used to override the default task manager and launch processhacker.exe. If that key still exists when the executable is deleted you can't launch the task manager via CTRL+ALT+DEL or via right-clicking the taskbar or anything that attempts to launch taskmgr.exe while that key still exists.
575cccbfa5