What I like about ESET is their user configurable HIPS rules. For me a product with no configurable rules is a no go - you rely on the vendor's detection. Some vendors think this and that does not merit separate detection due to their over-confidence in their own detection. If their detections are so good, we wouldn't have compromise after compromise of big corps. And red teams everywhere would be unemployed. And penetration test firms will be out of business. I prefer to play it safe and add persistence prevention to known registry keys and paths. That way I know a particular vector is covered. Otherwise it is one big black box. I am not saying that my rules offer better persistence detection than theirs, but extra rules that safeguards particular vectors are useful. For me blind trust in a vendor is suicidal.
For example, you can query for directories that are both writable and executable in \program files, \program files (x86), and \windows using SysInternals AccessChk. You will find that SetupMetrics under Edge, iirc, is one such directory (+ Chrome & derivatives) . When an attacker can write to a folder and also execute his wares you are in deep dodo. And I use SRP too, so user folders are covered for this scenario.
And as defenders we have to make use of AI. Ask for persistence registry keys and paths and you will get some. You will need to debug what AI's suggests because as we all know they hallucinate. But ESET offers logs of HIPS rules firing, so you can prune away or modify those that prevent normal operations. (for example I modified 4 out of 65 AI's registry offerings then the taskbar re-appeared. And most of them appeared reasonable)
As of my current very limited understanding, stopping the Persistence category of Mitre Attack SEEMS doable to a good extent. (in contrast to the Execution category) Not accounting for complex web based assets which we don't have.
