-
Posts
12,200 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
This sounds like an Eset firewall issue to me.
Open the Eset GUI. Select Network Protection. Click on the Troubleshooting Wizard and see if the Chomecast dongle connection is shown as blocked. If so, click on the Allow tab and Eset will auto create firewall rules to allow the connection thereafter.
-
1 hour ago, MichWeb said:
For your information, the installer first installed version 11.2.63.0, I let the first scan of the computer and then restart the PC for the automatic installation of 12.2.23.0.
My own opinion is that upgrades from a prior xx version can be problematic. Upgrades within a xx version are OK. As a rule, you should always do a fresh install of the current Eset version when a full new release is issued; e.g. to ver. 12 when ver. 11.xx.xx is installed.
-
14 hours ago, novice said:
You just said " Sophos has a simple mitigation "
Next time I will be more specific in my replies to you. What I inferred was "Sophos has a simple mitigation recommendation." It appears you obviously have no Microsoft training in how to properly secure a business computer network. As such, it would be prudent to reflect a bit on your comments prior to posting them.
It is not Eset's or any other AV vendor's software responsibility to ensure that a business network is properly secured against not only external unauthorized access/breaches but also internal like activities. It is however the organization's IT/security administrator responsibility to ensure that Microsoft's "best practices" to do so are implemented and enforced.
-
There's a simply way to verify what directory epfwlwf.sys is loading from.
Refer to the above registry screen shot. Find the entry for epfwlwf. Refer to the "ImagePath" entry. If it shows C:\Program Files\ESET\Eset Security\Drivers, then that is where the driver will be loaded from.
Note that driver loading and use of it are two different things. I examined the Start Type setting value for my network adapter and it's "3', i.e. Load on Demand or manual. Obviously the network adapter has to be initialized prior to the assignment of Eset's NDIS mini-port filter to it. This is where ekrn.exe use might come into play.
So it might be that there is a bug/issue here where possibly some residual registry entry or the like that ekrn.exe refers to, and it is set to C:\Program Files\ESET\ESET Smart Security\Drivers versus C:\Program Files\ESET\ESET Security\Drivers?
-
Just now, novice said:
So why Sophos and not ESET?
The option has nothing to do with either. Both gpedit.msc or secpol.msc are Windows policy/security utilities only available on the Pro+ versions.
-
I will also add that Sophos has a simple mitigation recommendation that will eliminate most RDP brute force password guessing attacks while at the same time not permanently locking out a user's workstation:
Quote- Set a lockout policy to limit password guessing attacks. With three guesses at a time followed by a five-minute lockout, a crook can only try out 12 × 3 = 36 passwords an hour, which makes a brute force attack impractical.
https://nakedsecurity.sophos.com/2017/11/15/ransomware-spreading-hackers-sneak-in-through-rdp/
-
Here's how we can verify that EpfwLWF.sys is properly loaded. Had to "comb the deep recesses of my brain" for Win 7 memories which I rather not remember.😅
Refer to the below screen shot in regards to your network adapter. Under the "This connection uses the following items" should be something titled "NDIS Eset Mini-port Filter" or some wording similar to that. If it exists, assume the driver has been loaded and is functioning properly and just ignore the Event Log entry.
Additionally if the driver wasn't properly loaded, Eset's SSL/TLS protocol filtering processing wouldn't be functional.
-
There's also possibly another dimension to this problem.
@Marcos is not EpfwLWF.sys, Eset's network adapter mini-port filter driver that Eset stopped using releases ago in favor of Windows Filtering Platform use?
In other words, the question is if this driver should be installed in the first place?
-
6 hours ago, stackz said:
I may have spoken to soon. Even though Process Explorer shows epfwlwf.sys loaded under System, Windows event logs show the following error:
Service Control Manager
EventID 7026
The following boot-start or system-start driver(s) failed to load: EpfwLWFThis indicates to me that epfwlwf.sys is installed and not loading at boot time; but thereafter.
I suspect that the associated reg. key "Start" value might be improperly set. Eset on Win 10 doesn't use this driver. So I have shown a screen shot of a like Eset driver associated service reg. key location and Start value setting. If epfwlwf service reg. key Start value is not set to "1", you can do so and see if that resolves the Event 7026 creation.
Warning: Only do the above if the Type setting for the reg. key shows a value of "1".
-
1 hour ago, novice said:
So why the fantasist explanation about "an attacker who brute-forced the password, disabled ESET, encrypted everything, enabled ESET back and left"?????
As far as the first three reasons given, it's a fair assumption.
In prior endpoint attacks where logs or specific details were provided, RDP was always the attackers entry point into the network. Once in the network, he could easily access any device where Eset was installed. Even if password protected, it could be bypassed via keystroke capture using a keylogger or other credential capture means.
Further, there has been at least one forum poster who was been repeatedly attacked via RDP despite being initially warned and advised on how to properly secure it.
To set the record straight, the vast majority of ransomware incidents posted in the forum involved business networks. The individual user postings I have seen are from those seeking help or a decrypter and don't even have Eset installed. Or, they naively installed Eset after the ransomware incident in belief it could both remove the ransomware and decrypt their files.
-
2 hours ago, monbonita96 said:
X means OFF?
In the Eset GUI if an option selection is blank; i.e. uncheck-marked, it means that option is disabled.
-
59 minutes ago, Diane said:
I'm suddenly getting new spam in my inbox this is so frustrating I get hundreds a day and I can't stop them
https://www.howtogeek.com/180477/htg-explains-how-do-spammers-get-your-email-address/
-
Unless the OP replies back with specific details on the staging events of the attack, we will never know what they were. Unfortunately, most will never do so because disclosure of these events could very well cost them their employment.
-
14 minutes ago, URBAN0 said:
👌
Just curious, I'm fairly new to ESET so still learning. I just looked into installed cleaner modules and I'm still on 1195 and I'm on the latest 12.2.23.0 NOD32 I can only presume that the updates gets pushed to customers gradually😀
I assume any one who has posted to this effect is using the pre-released version.
-
Actually it wasn't mentioned what account/s are used by the password specified in the e-mail.
In regards to financial web sites as a rule, web sites of this nature don't use your e-mail address as logon id. They also usually require additional verification after logging on.
For web sites where the logon id is your e-mail address and the password indicated in the e-mail is your password, I would change the password on those web sites.
Also, I do hope the same password is not used on all the web sites you frequent.
-
Also to clarify, I expect to see Eset alert displayed, entry created in Detection log showing AMSI detection, and script quarantined.
Obviously since the script was never executed, PowerShell output display would not show what if given for the WD detection.
Also rather going the AMTSO committee route, Eset could just create like test AMSI PowerShell malware .php script? Since it would only be detected by Eset, the "obsessive" FP concern would be eliminated.
-
I just asked for a sig. to be added to verify Eset's AMSI detection functionality. No different in concept to existing AMTSO tests.
Forget I asked.
-
Here's what is displayed upon detection:
-
1 minute ago, Marcos said:
There's nothing to detect since the script merely prints "'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'". It doesn't do anything else.
Wrong. Refer to the Microsoft article for output displayed from Powershell when detected.
-
@Marcos, Eset AMSI doesn't detect this Powershell malware script; i.e. Win32/Mptest!amsi, that Microsoft developed to test AMSI functionality as noted below:
Ref.: https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps
I assume and hope this is because Eset doesn't have a like sig. detection for this. Please add a sig. for this. Let me know when this is done so I can retest.
Note: LiveGrid uploaded something when I was testing so the servers might already have code.
-
Appears this Symantec utility will remove all traces of Norton on a Mac: https://support.norton.com/sp/en/us/home/current/solutions/kb20080427024142EN
Likewise for whatever other AV traces you found, there should be a stand-alone uninstall/cleaner vendor utility for it.
Here's an Eset knowledge base article on how to uninstall and reinstall Eset on a Mac: https://support.eset.com/kb3239/?locale=en_US&viewlocale=en_US
-
You made a wise choice. Glad to have you on board.
-
1 hour ago, Marcos said:
Ok, there was a misunderstanding. As of v12.2, eamsi.dll is signed by Microsoft so that processes that utilize AMSI can load eamsi.dll without issues.
I checked the code signing specification on both the Microsoft ELAM and AMSI certificates used in both Eset corresponding entities and they are identical; i.e. 1.3.6.1.5.5.7.3.3. So at this point, I am at a loss as to why Win 10 1903 is blocking loading of the Eset AMSI .dll into PPL processes.
What I do know is these code integrity errors for PPL processes were not occurring on Win 10 1809. I "religiously" check that event log for errors. I suggest Eset developers get together with Microsoft as to cause and resolution.
-EDIT- One possibility is the Microsoft driver certificate Eset is using to sign its AMSI .dll must be EV status as the corresponding ELAM certificate is.
-
6 minutes ago, Marcos said:
I would say that developers and Microsoft know best so... I only quoted them and passed the information here to stop speculations.
Actually I misstated in use of Eset's ELAM cert. per se. Eset's needs to add the special PPL keys provided within the ELAM cert. to its existing driver authenticode cert..
Whats is the Password Manager Installer
in ESET Internet Security & ESET Smart Security Premium
Posted · Edited by itman
Actually, Eset Smart Security components are installed in Internet Security version but are not activated.
I actually have a Smart Security license but opted instead to install Internet Security since I have no need for the encryption of password manager features of Smart Security. So if anyone should be seeing the abnormal updating activity you posted, it should be me. Such is not the case.
I agree that it appears your current Internet Security installation is probably borked and an uninstall/reinstall should fix it. You could also try a repair install first and see if that resolves the updating issue.