itman

It also appears that there is a fundamental misunderstanding among the amateur malware testers over at malwaretips.com. All AV's perform hueristic; i.e. sandbox, analysis on a process. If during this analysis which is relatively short in duration the malware makes system modifications, those changes can be reversed. If for whatever reason the system modifications cannot be directly associated with malware payload execution detection, it is not possible to reverse those changes when the payload executes. Now there is a unique feature of WD which is its cloud scanning of unknown execut

I received the new Eset Internet protection module, 1416, today and have no issue with either of my two e-mail providers in Thunderbird. One is using IMAPS - SSL/TLS and the other POPS - SSL/TLS. Are the people having issues using IMAP - STARTTLS or STARTSSL ?

I will also add that unlike Firefox which has set preference to Win root CA certificate use by enabling this option: security.enterprise_roots.enable true Thunderbird has not done so. If the AV certificate used by Thunderbird gets corrupted or whatever, the result is what @Marcosdescribed. Disabling SSL/TLS protocol scanning and re-enabling it, repopulates the Eset certificate in Thunderbird's Authorities certificate store.

Let's again review your test procedure: It appears that WD is "monitoring' Autoruns results. This makes sense since both are Microsoft base products. You then repeated the same procedure and expected Eset to trigger on Autoruns findings. Namely, the found Autoruns entries flagged and associated with this malware. The main point to emphasis here is WD's real-time behavior was identical to Eset's in regards to the original detection and removal of the malware sample. It was only after Autoruns was executed did WD become aware of the malware related registry and scheduled task

Here's my take on what is going on with this malware based on the posted WD screen shot of what was cleaned. The malware is actually starting from a HKCU run key. This in effect is a UAC bypass since the bugger will run even under a standard user account. It appears the next step is it sets up the scheduled tasks and then dynamically invokes task manager to run those tasks. I believe the only reason a scheduled task related to this bugger shows in the posted Autoruns screen shot is Eset detected and deleted the app that eventually would have removed the scheduled task shown.

As I recollect, older versions of WD were also quite effective at removing residual malware traces. Reason? WD's signatures used to suck big time until they finally farmed that out to a third party a while back. As such, once a sig. was created, appears Microsoft created in essence "metadata" associated with the malware to find system modifications once the malware was discovered on a device. Kaspersky deploys system snapshot capability that will rollback system modifications. However, there is a performance degradation associated with that processing. As a rule, most current AVs suc

Yes. Here's a Microsoft article detailing Windows versions vulnerable to EternalBlue: https://support.microsoft.com/en-us/help/4023262/how-to-verify-that-ms17-010-is-installed Also I realized why srv.sys no longer exists on my device. Windows will auto remove SMBv1 10 days after installation if it is not used. Additionally if srv.sys exists on later Win 10 installations, you are not vulnerable since this driver has been patched against this exploit.

It should also be noted that Node js can arrive on a device via legit software. Visual Studio is one example: http://jameschambers.com/2015/09/upgrading-npm-in-visual-studio-2015/ . However, it is not activated by default and some additional setup work is needed. -EDIT- Another source notorious for installing server side Node js crud is Adobe products: https://community.adobe.com/t5/photoshop/can-i-turn-off-node-js-server-side-javascript/td-p/8731592?page=1

@Marcos already posted how to do this:

@Marcos has anyone from the Eset side explored whether using "/?/" in a firewall rule path specification would work? I mention this because I noticed some Win 10 registry entries using this path specification. Appears to be something Windows natively supports; at least for Win 10.

We can also assume this Node js based crud was created prior to the Eset trial version installation. Do yourself a favor and purchase an Eset license. -EDIT- Also heed @Marcos advice about getting rid of Node Js. Its presence opens you up to ransomware attacks that deploy components of it. Ref.: https://soanvig.github.io/node-ransomware/

1. Upload in your next posting the logs @Marcos requested. 2. You can also use Win Task Manager to review task startup history related to Win startup times for suspicious task startup entries. Or, you can use SysInternals Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns to do the same which will scan all Win startup tasks. This tool can also be configured to use VirusTotal to scan all startup entries. Warning! Do not remove anything anywhere unless you know what you are doing and you have provided a recovery method to restore whatever you removed in case you

The legit installation path for Node js is C:\Program Files\nodejs. However on your device, Node js is installed in C:\Program Files (x86)\nodejs. This is highly suspicious. Also it is not easy to dump a file into C:\WINDOWS\TEMP\ directory in Win 10. You don't even have read access to that directory if running under default limited admin account. As such, I believe a scheduled task was created to run with highest privileges that is running at system startup time. This task is creating the .exe in the C:\WINDOWS\TEMP\ directory that Eset is detecting. One possibility is the scheduled task

I have asked in the past if an Eset export file created on a prior version or within version release would cause issues when imported to a later Eset version/release. I was told by @Marcos that this would not be an issue. Additionally, I have done this multiple times in the past w/o any apparent issues from upgraded version/release. However, I don't use the firewall in Interactive mode. As such, I never created any rules in this mode.

The first question is did you purposely install Node js. Or, does any software you have installed use Node js? Ref.: https://www.geeksforgeeks.org/installation-of-node-js-on-windows/ Per the linked reference, node js is installed on your device as evidenced by the creation on this directory, C:\Program Files (x86)\nodejs. However, a malware based install of Node js can be evidenced by creation of this Windows environment variable: Also Eset's detection appears to be for this file, C:\WINDOWS\TEMP\ec4b3ab6-14a3-3a24-522c-23f67832b6d1\e4afb5cd-2616-2ade-b688-275bb99d02