Overall I think this is why the balance between reputation / cloud intelligence, static heuristic scanning, and runtime behavior blocking is so important. Your best chance at preventing malware from doing something evil is stopping it in exactly that order above!
- Cloud lookup just involves computing a hash of the file. If you can't do that in year 2020 without being exploited, you've got major problems.
- Static scanning starts getting a little dangerous. Unpackers and complex parsers can have buffer overflows and other weaknesses, and this has been exploited in the past. Yet if you don't use an unpacker you have almost no chance at statically detecting obfuscated binaries or scripts.
- Runtime behavior blocking is where you are really getting into dangerous territory. You're basically allowing the malware to execute natively on your machine, hoping that your behavior blocker has hooked and has proper detection for every potentially malicious action.
At the end of the day I think it's a difficult balance to strike. You can make an AV suite less vulnerable by doing less complex scanning but that comes at the cost of protection and means more things result in the scanner saying it's clean but on execution bad things happen (e.g. everyone who pairs BitDefender sigs with an average behavior blocker)
But in SEP's case, I think it's a little disappointing that it's simply a log file. No matter how you slice it, it is a very bad practice to be creating and deleting log files in the user's AppData directory as a SYSTEM account with kernel level privileges. It should be either using an unprivileged helper, or even better, the scanner should simply not be using system level privileges at all.
At least we can be thankful it's "just" arbitrary file write and not arbitrary code execution as SYSTEM, which has also happened in the past with many AVs.