itman

Here's another clever phishing e-mail password attack currently circulating: https://www.bleepingcomputer.com/news/security/voicemail-phishing-campaign-tricks-you-into-verifying-password/

@Marcos since this activity appears to be COM based, check the logs for any WMI consumer or command event existence/activity.

That isn't necessary. However, you might want to create exceptions in both software's for the other to minimize the risk of any conflicts.

I got a bit "carried away" in my previous posting. Windows is such a "piece of garbage" security-wise, I can't control myself when thinking about the issue. The odds of a stand-alone keylogger being dropped on a device these days is about nill. Keyloggers these days are packaged in financial based malware along with a whole bunch of other nasty such credential stealing stuff and the like. Eset has always performed exceptionally well in AV lab tests against financial malware; in almost all tests over time scoring 100% detection. Emotet is a nasty bugger that Eset has one of the best detection rates against: https://www.us-cert.gov/ncas/alerts/TA18-201A Note above how passwords are stolen by Emotet. Not by a keylogger, but by misuse of legit password recovery tools. Also Emotet's primary deployment method is via phishing e-mail. Likewise, much less sophisticated phishing e-mails attacks are also very successful. Like the one from supposedly your e-mail provider that looks for all intent and purpose as legit. It usually states your password has been compromised and you need to change it with a link provided to supposedly your e-mail provider logon-on page. You click on it and arrive at a web page that appears to be your e-mail provider logon page. Well, it isn't and you enter your old password and new password. Attacker subsequently logs on to your e-mail account and does change the password to the value you previously entered. You've just been pwned and are completely clueless to how it happened. Oh, about that confirmation e-mail you should receive about the password change. Attacker will make sure its deleted upon arrival. Tip - almost all browsers have a setting that allows for storing of user names and passwords. Make sure that setting is disabled. Likewise, make sure your e-mail client is not configured to save your e-mail server connection password.

Issue also exists on the Eset retail products. Here's the thread on that: https://forum.eset.com/topic/17991-as-soon-as-possible-option-of-scheduler/?

It will help in regards to outbound firewall rules but won't cover all instances. Win 10 has system level apps that are like updated on a frequent basis. Eset has advanced memory scanning protection which is effective as long as the code signature is known. You can create HIPS rules for browser processes to prevent any process modification activities. Of course, you will need to create corresponding allow rules for legit processes that do like activities; e.g. explorer.exe, runtimebroker.exe, etc.. -EDIT- Also the previous method is not "bullet proof." Malware could inject the parent process and hook a thread into the child process. So now we need to protect the parent process, and its parent process, ad infinitum …… So view process protection as best guess effort. Yes.

It is also possible what Eset is detecting is the vulnerable Java version/s. Is Java fully patched and up to data?

Questionable. The attacker could inject the browser with a keylogger for example. @TomFace suggestion of using a password manager is a good one and should definitely be considered. You could also explore using a standalone e-mail client since these are less targeted by keyloggers. The main issue is if an attacker can install a global keylogger on your device. With this he can capture keystrokes from any app. Eset has improved its detection against these. It recently detected a .Net based one I created some time ago for testing purposes. It appears it is monitor for select API usage common to global keylogging and if detected, the process is uploaded via LiveGrid for inspection and eventual signature creation. So yes, interactive firewall monitoring of outbound traffic could detect a data upload. However, this is easier said than done. Also, the same issue with Win 10 store apps manifests in firewall rules since again, their process names are constantly changing. An "eye opener" is a review of the Win firewall log. What Win 10 does is dynamically delete old store app Win firewall rules and create new ones every time a Win 10 app is updated to a new name(version). Adobe Reader updater is also another app that performs like activity.

I did a bit of research yesterday in dllhost.exe usage. It is associated with COM processing. Malicious browser extensions will employ COM. So I would be suspect of any recent Chrome extensions installed or the like.

Your best protection against financial malware is to perform all like activity in Eset Banking and Payment Protection feature. As far as keyloggers go, you're covered since BP&P scrambles all your keystrokes. The HIPS per se has no dedicated keylogger protection. The HIPS option of global hook detection, i.e. global keylogging, only works in XP as discussed in a past forum posting. Don't know if that has been changed in regards to latter OS versions but doubt it. As far as the HIPS learning mode, you leave it enabled as long as it takes to create rules for your normal system activities. Then you switch the HIPS to interactive or policy mode. In policy mode, the HIPS blocks anything that does have an allow rule associated with it. You will also have to manually switch back to learning mode whenever you install anything or perform Win updates. Also Win 10 store apps could be problematic since they are constantly being updated with new program names being generated for most of them.

I am wondering if Eset is detecting an old unused Apache app on the server? https://arstechnica.com/information-technology/2017/03/in-the-wild-exploits-ramp-up-against-high-impact-sites-using-apache-struts/

As far as this one goes which is related to the NSA exploits; i.e. EternalBlue, etc., refer to this: https://support.microsoft.com/en-us/help/4023262/how-to-verify-that-ms17-010-is-installed

Again, the issue has nothing to do with how frequently Virusradar database signatures are created. The frequency on the weekends is the same as on week days as best as I can determine. The issue is how often those signature updates are distributed to Eset update servers worldwide. For some unknown reason, it appears the Eset update server assigned to North America is not receiving these updates promptly on the weekends. Or, the server is off-line for an excessive period of time on the weekends.

This is interesting. The IP address, 51.15.90.178, associated with the URL blacklisted is in Paris, France and appears to be associated with a gov. web site; UK Government Department for Work and Pensions. A UK gov. web site hosted in France? In any case, a web connection from C:\Windows\SysWOW64\dllhost.exe definitely is not normal. For the time being, you could create an firewall rule to block all TCP/UDP traffic inbound/outbound for IP address 51.15.90.178. Once it is determined what is causing the dllhost.exe traffic, you can delete the firewall rule.

As far as CVE-2017-5638 goes, this vulnerability was disclosed in 3/2017. Reference here: https://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html . You need to upgrade Apache to the latest version.

If you expand the "Application" column in the log, it will show you the full path name for the source app Eset is detecting. Eset also shows the source app in the desktop alert generated if you click on the "Details" section in the alert.

Well, this is my case since my average update time is 3 - 4 hours. On the other hand, new sig. updates are shown with like corresponding frequency on the Virusradar database web site. So I never was concerned about this interval. It is when I receive updates than are greater than 4 hours in frequency is when I get concerned. And this always occurs on the weekends for some reason.

I know the update checking is working properly since I see the time being updated in the Eset GUI. The connection to Eset update servers is being made since I see the Eset update server URLs showing in my network connection monitor. My last sig. update today was 12:54 PM EST. It is now 7:22 PM EST and the manually update check is now not pulling down the latest sig. update. And again, this is typical Eset weekend update behavior for me. -EDIT- I cleared the update cache and was able to manually download the latest sig. update.

That is not the issue. Using Eset's Virusradar web site as a reference: https://www.virusradar.com/en/update/info/ , the 18735 signature update was created at 1/19, 22:00 CET. That equates to 15:00 EST my time. I still had not received the update at 19:00 EST when I then forced the update manually. If Eset checks for updates on an hourly basis, why was it not pushed to my installation at 16:00, 17:00, or 18:00 EST? That is my question.

I just checked mine and it was 18734 with the last update 5 hours ago. I agree that is way to long for an update to be delivered. I just did a manually update to 18735. BTW - you don't have to do a system restart to do so. Eset checks for updates hourly. So I really don't know why these update cycles are so long on the weekends.

There is another work around for this problem. You can create a .bat script containing Eset's command line ECLS scanner as shown here: https://support.eset.com/kb3417/?locale=en_US&viewlocale=en_US . Then create a scheduled task using Windows Task Manager to run the script. Assumed is you need to set the scheduled task to run with highest privileges. -EDIT- Also in regards to using the coding shown in the KB article in a .bat file, I believe you need to add leading and trailing quotes to the entire string as shown below: ""c:\Program Files\ESET\ESET Smart Security\ecls.exe" /base-dir="c:\Program Files\ESET\ESET Smart Security" /auto /log-file=c:\ecls.txt /aind " Ref.: https://ss64.com/nt/syntax-esc.html

See the below screen shot. Uncheck the circled field and click on OK to save your changes. Make sure to reenable the field after you are done testing.

Correct. I stated so incorrectly. It shows seconds; not thousands of a second.

My above posting of using thousands of a sec. in scheduled time field also did not work in starting of the scan upon resume from sleep mode. Appears the only immediate solution to this issue is to set scheduled time to a time when PC is always powered on. Or, just initiate the scan manually.

To get to the bottom of this, I went to the Apower web site here: https://www.apowersoft.com/phone-manager and downloaded apower-manager.exe. I then performed an Eset context-menu scan on apower-manager.exe in my Downloads folder. Results shown below: I then performed an Eset context-menu scan on the Downloads folder. Results shown below: The bottom line is apower-manager.exe shows no malware by either context-menu scan method; individual file or folder. Therefore, I can't duplicate the activity you posted about.