tzuzut

No data is currently stored (apart from the internal state/settings of the extension itself). No logging of browser history, no sending data to the server.

I'm afraid we can't do much about that, however, the maker of the software could contact ESET and try to find a solution together.

As far as what wmiprvse.exe child processes to monitor for;
https://redcanary.com/threat-detection-report/techniques/windows-management-instrumentation/
Also, the article gives multiple examples of why WMIC execution should be blocked.

Also, I believe WMIC invokes the main WMI process, wmiprvse.exe, to run the target process. So in reality, it is wmiprvse.exe that is creating the child process. I have a HIPS rule to monitor for that activity.
As far as stopping WMI via PowerShell use, the best mitigation is to set Powershell to Constrained Language mode which prevents all direct use of PowerShell subassembies via .Net invocation. Also, use of Windows Defender Application Control (WDAC) auto sets Powershell to Constrained Language mode.
-Correction- PowerShell Constained Language mode won't stop this;
Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList notepad.exe
but monitoring child process startup from wmiprvse.exe will;
Time;Application;Operation;Target;Action;Rule;Additional information
8/23/2023 3:04:21 PM;C:\Windows\System32\wbem\WmiPrvSE.exe;Start new application;C:\WINDOWS\system32\notepad.exe;Blocked;Deny child processes started from WmiPrvSE.exe;

You need to monitor WMIC startup; not child process creation. The HIPS alert Commandline will show if attempted child process creation is occurring;

Ditto for powershell startup.
WMIC HIPS rule is;

Note that MITRE's recommendation is to block WMIC execution;
https://attack.mitre.org/techniques/T1047/

Blueskying, what would be utterly fantastic is Eset ptogramming the HIPS to use MITRE detections as to LOL Windows binary abuse. Then one could specify in a HIPS rule to apply those detections against an abused process such as WMIC.