Firewall paused with password protected settings?

[Lockbits 10]

Hi guys,

We've a customer that was infected by a variant of Crysis.P through RDP. According to them, all PCs and their respective AVs are password protected. Indeed we checked the logs and we can confirm that it's true.

The problem is that according to the customer the attacker paused firewall protection because when they saw the workstation they realized that ESET's firewall was paused and nobody disabled this. Looking at logs I can see that firewall is paused.

How is that possible if the product is password protected?

ELC is here: https://we.tl/Uz15qipeT5

Thank you.

[itman 1,659]

The attacker could have installed keylogger or screen capture software on one of the workstations. Do the workstation users have access to the Eset GUI password? Also the capture could have occurred if an Admin logged onto one of the workstations and entered the password. Don't know if Eset encrypts the keystrokes when they are entered into the password entry box.

Edited March 12, 2018 by itman

[Lockbits 10]

20 minutes ago, itman said:

The attacker could have installed keylogger or screen capture software on one of the workstations. Do the workstation users have access to the Eset GUI password? Also the capture could have occurred if an Admin logged onto one of the workstations and entered the password. Don't know if Eset encrypts the keystrokes when they are entered into the password entry box.

Hi itman,

Thanks for your reply. As far as I know only the TI stuff have access to ESET password. 

[itman 1,659]

Below screenshot is self-explanatory:

[Lockbits 10]

1 minute ago, itman said:

Below screenshot is self-explanatory:

itman,

Beside keylogger possibility, do you think that an attacker could pause firewall protection without knowing password or it's technically impossible or very difficult?

Thanks.

[itman 1,659]

2 minutes ago, Lockbits said:

itman,

Beside keylogger possibility, do you think that an attacker could pause firewall protection without knowing password or it's technically impossible or very difficult?

Thanks.

Not that I know off - paused that is. Now if he could somehow disable the ekrn.exe, he could do so.

One other thing for you to check. Verify Eset's self-protection wasn't disabled on the workstation.

[itman 1,659]

Since the attacker was in the network, possibility by ECMD usage: https://support.eset.com/kb6382/ ?

Individual security features can be enabled and temporarily disabled with the ERA Client Task Run command.

Personal firewall

ecmd /setfeature firewall pause

ecmd /setfeature firewall enable

Edited March 12, 2018 by itman

[Marcos 5,074]

6 hours ago, itman said:

Since the attacker was in the network, possibility by ECMD usage: https://support.eset.com/kb6382/ ?

Individual security features can be enabled and temporarily disabled with the ERA Client Task Run command.

Personal firewall

ecmd /setfeature firewall pause

ecmd /setfeature firewall enable

The attacker would have to run this command from the ERA console.

[Marcos 5,074]

First of all, if an attacker gains administrator access to a computer, he or she can do virtually anything, including killing the security programs you use. In this case it's not the firewall that would have prevented the ransomware from being executed by the attacker; they typically disable real-time protection which would have otherwise prevented the  ransomware from being executed.

Besides hardening or completely disabling RDP, if not really needed, you should consider:
- keeping the OS up to date, installing all critical security patches asap
- using a non-default port for RDP connections
- limiting users with RDP access
- using strong passwords
- limiting IP addresses / ranges for RDP connections
- set a password to protect ESET settings
- enable detection of potentially unsafe applications to detect legit tools that can be used to kill running applications.

[itman 1,659]

There is another possibility on how ECMD could have been used in this attack assuming the attacker had gained Admin privileges and the following condition existed. The attacker could have imported a configuration where the ESET password feature was not enabled:

Quote

When you have enabled ESET CMD, there are two authorization methods available:

• None - no authorization. We do not recommend you this method because it allows import of any unsigned configuration which is a potential risk.

Once ESET CMD is enabled, you can start using command line for exporting/importing ESET Endpoint Security configuration. You can do it manually or create a script for the purpose of automation.

http://help.eset.com/ees/6/en-US/index.html?idh_config_ecmd.htm

Edited March 13, 2018 by itman

[itman 1,659]

To get the disabled Eset password issue in to proper prospective, the question is did it have any impact on the ransomware attack? I say no.

The attacker performed most likely a brute force RDP attack against the server. Once in the server, he could then move laterally within the network via SMB. The client devices most likely were Eset IDS configured to allow incoming RPC communication over SMB.

[Marcos 5,074]

I have often seen Filecoders to be detected both in TS shares and on local disks which means they were detected and blocked, however, the attacker had to disable real-time or even other protection mechanisms in order to be able to run the ransomware. Did you have detection of potentially unsafe applications enabled? I'm asking because detection is disabled by default as it covers legitimate tools that can be misused in the wrong hands, however.

[itman 1,659]

I am going to "switch gears" and now assume this was a RDP attack against a specific endpoint device. Deployment of Crysis ransomware is well known for this as noted in this TrendMicro article from last year: https://blog.trendmicro.com/trendlabs-security-intelligence/brute-force-rdp-attacks-plant-crysis-ransomware/

Now it so happens there is a new strain of this malware being deployed via RDP brute force that is not only using Crysis to encrypt the device's files, but also dropping a coin miner for persistence if the files are later restored: https://opendatasecurity.io/crysis-a-dangerous-ransomware-that-is-infecting-companies-right-now/

Quote

The attacker usually downloads and installs monitoring programs like keyloggers to collect data from the system and also to gather data of the activities and data of the victim. This may be a private individual or a company. Through monitoring and credentials harvesting they can also extend the scope of the attack to other resources of the victim´s network. After enough data has been collected, the Crysis variant is executed on the victim machine and the ransomware encrypts almost every file of the affected machine including executable files. This is not common in other ransomware cases.

One plausible scenario is what I initially suspected. Initially a RDP brute force attack installed the keylogger. Keylogger captured Eset's password. Attacker disabled Eset's firewall via Eset's GUI. Also assumed other Eset's protections were disabled. With the endpoint's Eset firewall paused, attacker could download pretty much what he wanted. Question is why did not the endpoint user notice Eset's protections were disabled? Perhaps this occurred when the workstation was unattended?

My money currently is on this scenario using the "if it looks like a duck, walks like a duck, and talks like a duck, it's a duck!" rule.

-EDIT- One other thing to check out. Does ERA throw an alert if Eset workstation protections are not set to fully "protected status?"

Edited March 13, 2018 by itman

[Lockbits 10]

15 hours ago, Marcos said:

The attacker would have to run this command from the ERA console.

Thanks all for the replies. Detection of potentially unsafe app. was disabled so we urged the customer to enable this setting.

We also commented that a keylogger could get the ESET password.