PuterCare

You can copy wscript.exe to a location that is not in the path variable and run the script with a full path to that wscript.exe.

Apparently an "update of Proxy-settings" solved this issue. I would have appreciated an communication about this solution since after all the trouble last week I was reluctant to allow any changes of anything. But glad the issue seems to be solved now. Thanks
 

Correct.
Also, the Eset firewall is "picky" about which CIDR is valid. For example, it will accept 2620:1ec:d::10/64 but not 2620:1ec:d::10/96.

To begin, dismhost.exe running from the user temp folder is OK.
I monitor dism.exe execution via Eset HIPS and the only thing that starts it on my Win 10 20H2 installation is cleanmgr.exe running from a Microsoft set up scheduled task.
The above said, PowerShell usage is "baked into" Windows and is used internally for many OS functions. As such, it is entirely possible Windows internally is initiating the above activity you posted. As I posted previously, I monitor all Powershell.exe startup via Eset HIPS. I also monitor my Windows Powershell event logs and I have multiple daily event log entries showing PowerShell running to perform required system maintenance activities. Also, I have never once received an alert from my Eset HIPS Powershell start up rule in regards to this activity. So however Windows is running Powershell in the background, the Eset HIPS doesn't detect this activity.
Bottom line is I have seen enough to state that the recommended Eset HIPS rule to monitor child process startup from Powershell wasn't thoroughly tested and should not be used.

I erred in my original posting in this thread.
I didn't implement Eset's recommended anti-ransomware HIPS rules per se. Rather, I made them more secure which suits me personally. One of the revisions for example is I monitor all Windows script executable's startup via a HIPS ask rule. This includes PowerShell.exe startup. As such, there was no need to use the recommended rule of monitoring all child process startup from PowerShell.exe.
To use PowerShell legitimately, it must be allowed to start conhost.exe since it is the graphical interface element for PowerShell.

You could create a permissive rule based on the rule "Deny child processes for powershell.exe" and add the path to conhost when specifying the path to target applications which would be safer than disabling the rule completely.

First, what is conhost.exe:
https://softwarekeep.com/what-is-conhost-exe
I have had this Eset Powershell HIPS rule in place for ages and never received "a peep" from it.
One example of conhost.exe starting from PowerShell.exe is when it is deployed by PowerShell Empire used maliciously:
https://www.trustedsec.com/blog/who-left-the-backdoor-open-using-startupinfo-for-the-win/

Based on this .docx sample: https://www.joesandbox.com/analysis/476188/1/html , Eset and most other AVs are detecting the dropper file now.

It's custom HIPS rules: https://support.eset.com/en/kb6119
They are not there by default since they may generate false positives especially in networks where scripting is used. After creating the rules we recommend monitoring the network for potential script-related issues and disable or adjust the appropriate rule(s), if necessary.

I'll add that I've added these rules, and Teams seems to be functioning properly now.

 

Thanks @Peter Randziak @TomasP, I have PM'd you the link to logs.

This is my Dynamic Group rule.

Using "not regex (7.3).*"  could work.

Hello, 
we use dynamic group with following template configuration to show us all V6 Agents. I am sure you can adjust that to ver 7.

Of course the group is populated on next connection of the client (agent).

They added a new app pathway in the latest update and it also needs allowed on the firewall, it is (Renderer)
/Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper (Renderer).app/Contents/MacOS/Microsoft Teams Helper (Renderer)  

Finally got this working, it looks like the issue was Microsoft blocking the SMTP AUTH as it was deemed "Risky". I had to log into Azure portal and manually mark it as safe, then after about an hour it started to work with Automatic authentication selected. 

This is now resolved, in case it helps anyone I logged into the VA and enabled Webmin, I then accessed Webmin using a web browser, Servers section, ESMC then there was an option to repair ESMC Agent Connection. I entered "localhost" for the Hostname and the ESMC port then clicked the repair button and it fixed it and updated to 7.1 as I had this task queued from last year.