Jump to content


  • Posts

  • Joined

  • Last visited

About winstonsmith84

  • Rank

Profile Information

  • Location

Recent Profile Visitors

1,169 profile views
  1. Nevermind. Event Viewer shows the update never started because permission to stop the Eset Management Service was denied.
  2. Web console says "Login failed: Connection has failed with state Not Connected". I'm assuming I just keep waiting until the web console finally works again but this seems like it's taking a very long time and I don't know how I would even know if it failed or not.
  3. The update has been running for over an hour. I can't log into the web console during this obviously and there is no status update of any kind so I can't tell if this is actually updating or if it failed and just hung. At what point do I give up and assume failure and restore the VM? The tomcat service is running on the server and the eset management service on the server says "stopping". It has said this for a long time now. Is the upgrade actually happening or did it fail?
  4. Unfortunately the error happens sporadically across the network. I never know when it's going to happen and I can't force it to happen.
  5. I get these error messages frequently. "During execution of Update on the computer the following event occurred: File does not exist." If I run the update modules task on the affected computer then it updates. Why does this keep happening and how do I make these computers update themselves without having this error?
  6. The struts exploit is for Apache but the server listed in the threat log doesn't have Apache installed on it. So why would this be listed as a threat alert on this server?
  7. We recently upgraded to Eset File Security 7.0.12016 and now have a few entries in the threat log that I'm uncertain what to do about. All say Firewall Security Vulnerability exploitation. One is SMB/Exploit.MS17-10.B and the other three are CVE-2017-5638.Struts2. Does this alert mean that these servers were actively attacked or just that a potential vulnerability exists with these servers?
  8. Service is running. Status is all green. No issues. Trace Log doesn't appear to have any errors but there is this entry occasionally: Warning: Kernel [Thread 648]: Module library +EVSAConnector was not loaded Warning: Kernel [Thread 648]: Module library +ESLCConnector was not loaded
  9. Nothing in Lost and Found with the same name and it's not cloned. It's a physical desktop that used to show up as managed.
  10. I have one PC in our environment that always shows as unmanaged in the remote admin console but Eset is installed on this PC. When you log into that machine and check Eset it says everything is OK. It appears to be working just fine but the ERA just shows the status wrong. How do I make this machine show up correctly in ERA as a managed PC? This PC has no info listed in ERA either. Everything for it just says N/A.
  11. Also, if it matters, desktop hit with filecoder was Windows 7 and desktop hit with neshta was Windows 10 although the desktops of both users are redirected and stored on a server. User with filecoder has desktop redirected to Server 2008 R2 and user with neshta has desktop redirected to Server 2016 if this is relevant.
  12. All eset endpoints are password protected so the employee shouldn't have been able to disable eset on the affected desktop. All eset protections should have been running unless the attacker found a way to disable them. I do still have this particular PC available offline to look over if anyone has ideas of what exactly I should be looking for on it. I don't have access to the servers that were hit as they were wiped and restored from a backup. After the attack on this desktop we received alerts that certain servers had massive CPU spikes so I believe the server encryption began after this desktop attack. Once this employee's password was changed the attack appeared to stop and was only able to get to 5 servers. We did receive an outbreak of the neshta.A virus a few days later. Whether or not this is related I don't know but Eset says it blocked this attack repeatedly except for 5 times. 5 times this neshta.A attack was not blocked on the same desktop that previously was blocking it. Eset was not disabled by the employee when this happened. The 5 times that failed Eset reported "error while performing action" and then the virus moved on to hit 3 servers. We haven't had any incidents since then but since we never have issues like this I'm inclined to believe the two were related.
  13. Logs are uploaded. Sent them in a personal message. Since this attack happened we were hit again with something called Nestsha.A as well. Eset caught this attempt except for 5 times when it said "error while performing action" and then this attack moved from that desktop to hit servers.
  14. We recently fell victim to a ransomware attack. The attack began on a user's PC that was protected with Eset 6. The remote admin console shows us that this machine was hit 20 times with something called Win32/Filecoder.NPA and that it was leaving an exe called f-new on the user's desktop. Eset claimed it was finding this infection and deleting it each time. The infection succeeded anyway as right after that server encryption began. Curious as to why Eset failed to stop this attack even though it noticed it. We have kept the infected desktop off the network after the attack and have not touched it since. What steps can we take to discover how the attack was successful and why Eset failed to stop it?
  15. Really hoping that there will eventually be a better way of informing users they need to restart the computer after an Eset update. Users consistently refuse to restart when they get the "Eset needs attention" message in the system tray. I'm forced to send the pop up window message task telling them to restart. This message scares them because they think any message that pops up on the screen is a virus and they refuse to reboot after seeing it. There has to be a better way to make people restart after an update. Ideally, not requiring a restart after an update would be wonderful. What exactly happens if people don't restart? Is Eset simply not working until they do? Or is it working but certain modules aren't? Or is it working fine but a restart is recommended?
  • Create New...