"Behaviour Blocker" is a fancy name for dynamic protection capabilities... you can rely on a vendor who's services are complemented with behavioural-based protection aimed at protecting the client from new malicious software without having any component explicitly named as a "Behaviour Blocker" (UK) / "Behavior Blocker" (US).
Contrary to beliefs from many on the forums, ESET has behavioural-based protection against new malicious software, but they do not buy into the "Behaviour Blocker" marketing, which means misinformed hobbyists end up disrespecting them as a vendor online, making all sorts of claims from them being a signature-only solution to not being able to prevent any attacks based on dynamic-based monitoring. To elaborate further, ESET have in-product sandboxing, botnet protection, exploit protection and ransomware protection. I'd love to find out whether some of the other vendors which are heavily promoted on the forums because of marketing decisions have features like emulation support or exclusive botnet protection through network filtering.
References:
https://cdn1.esetstatic.com/ESET/INT/Docs/Others/Technology/ESET-Technology-2017.pdf
Exploit Blocker | ESET NOD32 Antivirus | ESET Online Help
Exploit Blocker | ESET NOD32 Antivirus | ESET Online Help
What is the Host-based Intrusion Prevention System (HIPS) in ESET Windows home products?
Bottom-line: any dynamic capabilities are vendor-dependent - vendor A and B may do the same or similar things to vendor C and D but vendor B might not be into the "Behavior Blocker" marketing, but this doesn't mean that vendor B has no behavioural-based protection.
None of the aforementioned activities are "malicious" behaviours on their own - it merely depends on
how X, Y or Z is being used. X, Y or Z might be used by 10,000 genuine and clean programs without any malicious intent, but it may also be used by 20,000 malicious programs to cause harm. You need to understand
what is going on to
determine whether usage of X, Y or Z is malicious or not.
Would a program automatically be automatically "malicious" or "suspicious" for encrypting logs on-disk and decrypting them in-memory when the program needs to use them, or for using a documented cryptography API to hash with SHA-1, SHA-256 or SHA-512? It depends on whether the end-result is damages to the user, and the important factor in all of this would be
whether malicious intent was present. Without being able to prove that malicious intent, and especially if you had signed any Terms and Conditions which complied with the law and explained your rights when it comes to things like responsibility/consequences and warranty, you can throw the whole case out the window because blaming someone for the damages and getting any compensation out of it will be tricky and will probably end up being a waste of time and money on your end.
Encrypting content in itself is not malicious and is quite common for companies who try and protect their Intellectual Property or anything sensitive such as user credentials. At the same time, encrypting content which if encrypted would harm the user (and let's not forget about the malicious intention being applied to this as well otherwise it would have been an accidental bug from a genuine and non-rogue author) would be malicious.
The use of networking features (e.g. using an active internet connection to download content from online to the local machine) are in themselves not malicious by default as well - and the same for registry modifications or general file system operations - although the use of networking features can be abused by someone who does have malicious intent. An example of what a threat actor could do if they have access to the local environment and are intending to do harm, would be using up the network bandwidth to perform DDoS attacks (e.g. botnet activity), or downloading other malicious software via the internet.
Bottom-line: the context is extremely important and blindly forgetting about it would be a mistake.