Eset failed to stop ransomware

[winstonsmith84 2]

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?

[Marcos 4,838]

First of all, please collect logs with ELC and drop me a message with the generated archive attached. The last Filecoder.NPA we've got is from January 2018. It could be that an attacker remoted in via RDP and disabled protection prior to running the ransomware. The logs should shed more light.

[winstonsmith84 2]

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.

[itman 1,594]

2 hours ago, winstonsmith84 said:

Since this attack happened we were hit again with something called Nestsha.A as well

It has worm like characteristics, hence the movement throughout the network. On the desktop that was attacked initially, did you verify that all Eset protections were enabled? That is, the firewall was not in a paused state, etc..?

Also if you have RDP enabled on the workstations, you need to read this: https://forum.eset.com/topic/14929-eset-server-users-you-need-to-patch-now/

Edited March 16, 2018 by itman

[novice 20]

17 hours ago, itman said:

did you verify that all Eset protections were enabled

This is not the first instance when users complained about "eset failed to stop ransomware" and the question was always the same: "all Eset protections were enabled?"

Once enabled (an most likely they were), eset protection should stay and remain enabled; is difficult if not imposible for user to constantly check if "all eset protections are enabled"

[itman 1,594]

1 minute ago, MSE said:

This is not the first instance when users complained about "eset failed to stop ransomware" and the question was always the same: "all Eset protections were enabled?"

No. Being explored presently but not yet confirmed in any of these instances is if Eset's protections could have been disabled by the attacker via the Eset GUI.

[Marcos 4,838]

According to the log, the ransomware was run from a remote share  (desktop) \\Masterserver\Users\kiek\desktop\f-new.exe and was accessed by explorer.exe. This had been happening between 5:35:26 and 5:36:27 on March 10. My understanding is that an attacker already copied the ransomware to the above mentioned desktop, then connected to this computer and attempted to start it via Windows Explorer. It had been blocked several times by ESET until the attacker disabled real-time protection to allow the ransomware to run.

[novice 20]

2 hours ago, Marcos said:

It had been blocked several times by ESET until the attacker disabled real-time protection

How do you know that " the attacker disabled real-time protection" and to the ransomware itself????

[itman 1,594]

2 hours ago, Marcos said:

It had been blocked several times by ESET until the attacker disabled real-time protection to allow the ransomware to run.

I am assuming in this attack the workstation's Eset GUI was not password protected?

[peteyt 373]

21 hours ago, MSE said:

This is not the first instance when users complained about "eset failed to stop ransomware" and the question was always the same: "all Eset protections were enabled?"

Once enabled (an most likely they were), eset protection should stay and remain enabled; is difficult if not imposible for user to constantly check if "all eset protections are enabled"

I dont know about esets side but it is important to remember that a security suite is only part of protection. Users are generally the weakest chain in security and having an unpatched computer can make a security product useless

[novice 20]

2 minutes ago, peteyt said:

I dont know about esets side but it is important to remember that a security suite is only part of protection. Users are generally the weakest chain in security and having an unpatched computer can make a security product useless

That I understand, but is important to clarify if the user disabled the protection (so, nothing can be done) or the malware itself disabled the protection (so, there is room for improvement)

[Marcos 4,838]

The OP should confirm that encryption occurred after 5:36:27 on March 10, 2018. The logs suggest so but since I didn't get examples of encrypted files, I cannot check their timestamp.

[itman 1,594]

What needs to be established first is if the attacker was able to disable ekrn.exe. Then move on to any equi.exe disabling method.

In Win 10 1709, ekrn.exe runs as a protected process - light. In theory, this would make it immune from being tampered with. However, I know of at least two POCs that demonstrated PPL being bypassed. On other OS vers., I don't believe ekrn.exe runs as a protected process.

[itman 1,594]

Eset Endpoint 6.5+ has an interesting feature called "Override" Mode. Per Eset doc., has to be set on the ERA console for selective workstations. Once set on the workstation, allows the user access to Eset GUI to change settings as he sees fit. Since the attacker was in the network "rooting around" pretty much at will, who knows what he could have accomplished?

[tmuster2k 22]

Override mode only has a 4 hour maximum plus you have to set a user defined password or know the domain admin password. 

[winstonsmith84 2]

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.

[winstonsmith84 2]

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.

[itman 1,594]

Was there any recent activity on this workstation,  \\Masterserver\Users\kiek\desktop\, or any other subjected to RDP attack where an admin recently logged into the Eset GUI with password?  

Edited March 19, 2018 by itman