itman

Port 320 is used by the PTP protocol: https://wiki.wireshark.org/Protocols/ptp . As noted in the article, PTP is used for time synchronization between clients and servers on the internal LAN. As such, this port should not be open on the WAN side of the network perimeter appliance/router. I would check your network perimeter appliance/router for a possible breach/misconfiguartion.

Yes.

I don't have Chrome installed. However once you have added C:\Windows\System32\svchost.exe as the Application, search for the two referenced services, gpupdate and gpupdatem, per the below screen shot. The previous assumes your have installed Windows in the C:\ directory. Again two firewall rules are needed; one for each service. Also verify you haven't previously created firewall rules to allow these services and/or related .exes from running. Remember Eset firewall rules are run in top-to-bottom fashion. Your newly created block service rules would be added at the bottom of the existing rule set. Any prior existing firewall rules to allow Chrome updating would override these newly added block rules.

You have to create two firewall rules referencing Application as svchost.exe. The first rule will specify the gpupdate service and the second rule the gpupdatem service. For both rules specify the protocol as TCP & UDP. Action is Deny. Direction is Out. Name each rule appropriately. If you presently have existing Eset firewall rules, ensure they conform to the above. As far as how the Eset firewall blocks this activity, it is rather obvious. Chrome when it attempts to update will initiate an outbound connection to do so. The Eset firewall rules will prevent that activity.

Yes. Eset licenses are country specific. Assuming you purchased the license from an authorized retailer in Australia, contact them to determine if the license can be transferred to a device located in Costa Rica.

I will also add that the prior Javascript based variant of the malware made numerous Win registry changes. Of note were changes to Win internal network settings. It is for practical purposes impossible to determine what registry and possibly other system modification that were performed. Although removing the malware startup references from the %AppData% directory will prevent the Javascript malware from running, you have a possible likelihood to either becoming reinfected with the same malware or other malware because of these system changes. One mitigation would be to restore the registry from a registry backup as shown in this article: https://pureinfotech.com/restore-registry-backup-windows-10/ . The problem is this technique is beyond the average user. There is also a possibility it won't work. It appears later versions of Win 10 no longer backup the registry on a periodic basis as done in prior Win versions. If a registry backup exists, it may be very old. Reapplying that backup could very well bork Win system updates that were applied subsequent to the registry backup. Finally, restoring the registry might not be sufficient to mitigate all non-registry changes made by the malware. You should contact your local in-country Eset technical support on the best way to proceed on restoring your system back to pre-malware infection status.

I will also add that no security solution will give you a 100% guaranty against all ransomware attacks. Therefore, it is imperative that at least directories frequently targeted by ransomware; e.g. C:\Users\xxxxx\Documents, Pictures, etc., are regularly backed up to off-line media.

Confirmed. File extension is immaterial when script engine is specifically referenced via the /E parameter. Per the above linked TechNet article:

Another possibility is the .zip file is actually a "disguised " encrypted JavaScript file. Believe that is the case here. Note the use of; wscript.exe /E: https://stackoverflow.com/questions/5700431/how-to-use-the-windows-scripting-host-e-command-line-argument

FYI to all to what I believe is going on with this latest JavaScript incident. This; C:\WINDOWS\system32\wscript.exe /E:jscript "C:\Users\sande\AppData\Roaming\CC-Library-mul683-x64.zip" wscript.exe/e:key:BVfnB5qsixmIFscLj6DoRCZF Appears to be the running of an encrypted archive at boot time. Really something I have never seen before. Also since the archive is encrypted, Eset couldn't scan it when it was dropped on the disk.

I wouldn't worry about it at this point. I believe we are close to resolving at least the startup and running of the malicious script via wscript.exe. Delete that entry. Then reboot your PC. You should not see the previous wscript.exe error message any more. You should also no longer see any Eset HIPS log entries related to the wscript.exe created. Nor should you see anymore Eset alerts for api..... connection. However, there are still other possible issues. Do you use IE11 as your browser?

Yes, everything appears correct now. One of the problems is your Eset version is the Dutch language version and this is an English language forum.

This might be the malware. You are receiving the wscript.exe error message at system startup time because whatever is running the script, can't find it since it has been deleted. Again, verify that no files show in this folder, C:\Users\sande\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ . If files exist, take a screen shot of what is present in that folder.

You didn't post a screen shot for this setting. Verify it is set as previously specified; On the Source Applications screen, select "All Applications" from the drop down box. You didn't set this setting as specified: On the Application operation screen, enable the "Start new application"setting. Correct the above settings. Then on the last screen, mouse click on Finish. Click on the OK tab on any subsequent screen displayed to save your HIPS change. Hopefully therafter, HIPS log entries will start appearing in the Eset HIPS log.

You can do this without involving Eset use: https://www.wikihow.com/Completely-Disable-Google-Chrome-Update

I really don't know what the "uproar" is about. Microsoft just released the June Office updates yesterday: https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-outlook-crashes-in-june-office-2020-updates/ . On my device, it's not unusual for Microsoft updates to take a day or two to show up. For example, I didn't receive May updates till May 10. Now for what I have observed in regards to Office MS Store updates. It appears the update downloads and is still there in limbo. This manifests by a child appvnotify.exe or something like that running. Also when I check the parent OfficeClickToRun.exe process via Eset Reputation scanner, it shows in gray color - unknown. If I force a reboot of Win 10, the child process disappears and OfficeClickToRun.exe now shows in green with reputation rating. The above leads me to believe that the Store based Office updating process is possibly waiting on something that is "locked" and it can't access. Whether Eset is the reason for this lock remains to be determined.

My understand is as far as Kaspersky goes, most of the functionality of the paid version exists; including its highly rated System Watcher behavior monitoring feature. The difference between the free and paid is select options in a given feature are missing in the free versions. Additionally in Kaspersky free, many of the existing feature options can not be modified; e.g. disabled. Also both BitDefender and Kaspersky's free versions are anti-virus only solutions; i.e. the firewall, IDS, and possibly web filtering capability are missing.

I should have paid more attention to your Eset Filtered website log entries you posted previously: https://forum.eset.com/topic/23573-eset-is-agressively-blocking-url-cant-find-app/?do=findComment&comment=115004 . Previous various sandbox analysis of the malware does show it modifies network settings among other things. Something is running that is using wscript.exe to connect to the botnet. One possibility is the malware has created a backdoor on your device. It is then connecting to its remote C&C server via this backdoor. From this remote server, the attacker is running wscript.exe remotely to execute the malicious script. As such the created Eset HIPS rule is not detecting the startup of wscript.exe since it can only detect local device initiated startups. First, let's verify you created the HIPS rule correctly. Navigate to the HIPS rule you created. Mouse click on the rule to highlight it. Then mouse click on the Edit tab. This will display the first screen used in a multi-display sequence. For each screen displayed, do the following: 1. Take a screen shot of the display screen. Save the screen shot. 2. Click on the Next tab. Note: do not change anything on any displayed screen. When the screen is displayed with the Finish tab on it, take that screen shot. Then mouse click on the Cancel tab. This will cancel any changes made to the rule and return you to the HIPS screen showing all existing rules. You can now exit the Eset GUI at this point. Finally, post all saved HIPS rule screen shots in the order they were saved in your next reply.

First, note the following: In my Office Home and Student 2019, the setting was set to automatic updating and the above referenced setting was not hidden. I will say this. Prior to the May Win 10 updates, my Office apps were updating OK; although somewhat chaotically. Therefore, the issue might lie in a borked Win 10 update.

This should be stated in the AV-Test report details. Assume they are the paid versions since AV-Test lab tests are not free. They have however in the past performed a test comparative for free AV solutions but the report title clearly indicates this is the case.

Now you have to regularly monitor the Eset HIPS log for entries related to this rule. What you need to look for is what application is attempted to start wscript.exe. Copy those log entries and post a reply with those shown. Note that this HIPS rule could block legit wscript.exe use. This is most applicable if one has coded custom JavaScript, VB scripts, etc.. I doubt this applies to you.

Note that the above only; Office 365 - non-Pro. and current Office Home and Student versions are Win Store apps. As such, they are updated via Win Store update processing and do not show in the update status of the Win Updates section. On my Win 10 x(64) 1909 build, my Office Home and Student 2019 registry update settings exist in this reg. key; HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Updates

Something else "goofy" is going on. I have Home and Student 2019 installed. I opened up Word and forced an update. Sat there forever saying it was downloading updates. I then paused the Eset firewall and nothing changed. I then re-enabled the firewall and attempted to close Word. I then got an Office popup saying I had to close Word for updating to continue. Err - what? So I replied to that close request and status changed to "Applying Updates." That finished stating update was successful.

There is also something of a puzzle about this malware. As shown by the below Hybrid-Analysis screen shot, this malware first drops a script in the C:\ root directory. It then runs that script (method unknown) to run two PowerShell scripts to copy the script and corresponding .lnk version to Startup directory and %AppData directory: The problem here is you can't drop a .js file or any other file for that matter into the C:\ root directory in Win 10: So either the payload delivery is different in Win 10 or the malware is performing other activities such as privilege escalation prior to dropping the payload into the C:\ root directory. So it appears there is more to this malware than just JavaScript execution.

Per Hybrid-Analysis, appears one of the URLs shown is most likely the "culprit:"