So i've discovered that there's a signature built in to endpoint defend that simply checks if a process is named "hashcat" and kills it as unwanted. While I get the spirit of this rule, it causes some issues.
First off, it's obviously trivial to break, as the default name of hashcat is no longer "hashcat" anyway. Also it doesn't signature on the binary itself, so in this case "hashcat" was actually a script, which got killed.
While validating the health of my passwords I ran into this issue. Of course I can rename the binary, but the primary issue is that there doesn't seem to be a way for me to turn off that rule. I can potentially create a whitelist for anything named "hashcat" or anything in a specific folder, but both of those are heavy handed and will create a larger attack surface. I.e.: anyone attacking me could use the name "hashcat" or the same folder and sneak by defend.
I'm unsure what the correct path forward is here, but it seems unlikely that an attacker would actually upload and run hashcat on a victim, given the obvious slowdown and side effects it would cause. Why is hashcat even considered harmful, and if it is why isn't there a stronger signature for it?
) using default hacking tools by process.name, for C2 frameworks like havoc, sliver and others that are more harmful and are likely to be run in victim network we do have extra coverage using yara and other behavior rules, but for hashcat its a dual use tool and also as you pointed out is likely to be executed on attacker infra. best course of action I would suggest is to create an endpoint exception using