0xDEADBEEF

Appears Eset not alone here. At least one other AV is also flagging the driver: https://www.reddit.com/r/HonkaiImpact3rd/comments/f26zrh/vmprotect_suddenly_being_blocked_by_antivirus_is/
And it appears Eset is detecting Winnti's malware fingerprints here: https://github.com/eset/malware-ioc/tree/master/winnti_group#samples-1

The detection is correct. The purpose of the driver is questionable and having such driver running in the system is risky. You can exclude the file from detection, however.

It's all just about smart optimization, nothing else and nothing more. It's caused by obfuscation that the txt file was not detected.
1, Advanced heuristics doesn't scan scripts, there's a script scanner for that and the command-line (AMSI) scanner on Windows 10.
2, Scripts are not run sandboxed.
3, HIPS doesn't monitor file operations but real-time protection does.
We'll try to address it asap but if turns out to cause more harm then good then we'll probably leave it until it's addressed in a smarter way in the future utilizing HIPS.

Files were encrypted by Filecoder.LockedFile. According to the logs, there were about 170,000 failed attempts to log in via RDP as "administrator" and alike in approx. one day when the encryption occurred. Also an older version of EFSW 6.5 without Ransomware shield was installed.
The OP was informed and improvements in protection were suggested.

The only reason I was mentioning this is because web protection has more sensitive heuristics than on-demand scan or realtime scan, as Marcos has stated in this thread.
This means though the realtime scan or AMS will anyway catch the malware if the file is extracted to disk or memory, it might missed the more sensitive heuristic in the web protection layer, if my understanding is correct. As for how much more sensitive the web protection is compared to normal scanner, I've no idea

A quote from https://en.wikipedia.org/wiki/Firefox_Send:
All files are encrypted before being uploaded and decrypted on the client after downloading. The encryption key is never sent to the server.
That means ESET scans only encrypted files, ie. it's impossible to detect anything there.
 
From the technical documentation (https://github.com/mozilla/send/blob/master/docs/encryption.md :
The secret key is appended to the share url as a #fragment and presented to the UI
That means the key only leaves the machine when the user transmits it manually, so there's no reliable way for us to get to it.

Correct. Also web protection blocks known sites that distribute malware so even if there's a new unrecognized variant, the download would be blocked.

After updating to 12.1.31, the performance issue gets largely resolved. The sample that originally takes 15 sec to delete now only needs 3~4 sec in the latest version. 
Anyway I've messaged u the new log on 12.1.31

seems the performance issue is largely resolved in the latest version that is just released today. The deletion latency has dropped from 15 sec to 3~4 sec.