Decrypthelp@qq.com Ransomware

[mayowa 1]

Hello All,

A customer just reported a malware attack on one of their critical servers that turned all files into an arrow file (decrypthelp@qq.com)

Please kindly advise on a way around this,wont mind if i can get decryptor for the encrypted files

kindly Note

ESET is installed and updated with recent update on the server 

Thank you 

[Marcos 5,074]

Files with the arrow extension were encrypted by Filecoder.Crysis. Unfortunately, decryption is not possible. It is common that Filecoder.Crysis is run by attackers after performing a bruteforce RDP attack on a system and getting in with administrator rights. Subsequently they either disable or remove the security product in order to be able to run ransomware and encrypt files. I will drop you a personal message with further instructions shortly. If you had important files which were encrypted, we suggest keeping them in case that decryption would be possible in the future.

[mayowa 1]

26 minutes ago, Marcos said:

Files with the arrow extension were encrypted by Filecoder.Crysis. Unfortunately, decryption is not possible. It is common that Filecoder.Crysis is run by attackers after performing a bruteforce RDP attack on a system and getting in with administrator rights. Subsequently they either disable or remove the security product in order to be able to run ransomware and encrypt files. I will drop you a personal message with further instructions shortly. If you had important files which were encrypted, we suggest keeping them in case that decryption would be possible in the future.

Thanks for your quick response, on my way to the client site to intervene and get the encrypted files,also await your personal message for further instruction 

[novice 20]

Hi Marcos,

You were saying "On behalf of ESET I can say that I hardly recall a malware-related ticket where the infection was caused by ESET letting malware in.."

Here is your example, with  " ESET is installed and updated with recent update on the server"

I am pretty sure you will provide a sophisticated explanation, yet the fact remains: ESET, wit a dedicated "antiransomware" module, failed to protect OP .

 

 

[Marcos 5,074]

2 hours ago, claudiu said:

Hi Marcos,

You were saying "On behalf of ESET I can say that I hardly recall a malware-related ticket where the infection was caused by ESET letting malware in.."

Here is your example, with  " ESET is installed and updated with recent update on the server"

I am pretty sure you will provide a sophisticated explanation, yet the fact remains: ESET, wit a dedicated "antiransomware" module, failed to protect OP .

 

 

I have replied to this in the topic you quoted. ESET had detected Filecoder.Crysis for months before the user got infected. That happened most likely because RDP was not properly secured and virtually anybody could get into the system with administrative rights and disable ESET easily prior to running the ransomware. However, the fact that RDP was not configured properly in no way means that ESET failed to protect the user.

General advice:
- disable RDP if not really needed, or limit its use to users who really need it
- make sure users with RDP access don't use weak passwords that are easy to guess or bruteforce
- use RDP only within VPN
- use 2FA
- restrict RDP to specific IP addresses or ranges on a firewall
- keep the OS and all applications updated, regularly install critical security updates
- use the latest version of the ESET Security product (preferably ESET Endpoint Security with the Network protection module to protect machines from exploits coming from unpatched computers and exploiting vulnerabilities in network protocols to proliferate over LAN)
- use default settings of your ESET Security product and customize settings only if you are aware of the impact on security (otherwise consult it with customer care first)
- enable detection of potentially unsafe applications to prevent ESET from being disabled
- protect ESET settings with a password

I kindly ask anybody to stay on topic. Any unrelated posts may be removed or moved elsewhere.

[itman 1,659]

4 hours ago, claudiu said:

I am pretty sure you will provide a sophisticated explanation, yet the fact remains: ESET, wit a dedicated "antiransomware" module, failed to protect OP .

"Mindless" criticism without thoroughly researching the facts "speaks volumes" in regards to the competency of the one performing such activity. If you want anyone to take your comments seriously, get your facts straight.

Emsisoft has a good layman article on RDP brute force attacks here: https://blog.emsisoft.com/en/28622/rdp-brute-force-attack/ . Since it appears you have difficulty in understanding articles like this, I will assist you. Once an attacker has been able to acquire a server's logon credentials, he can do anything a full administrator can do. No security method in any fashion will prevent an attacker from performing serious system and network damage when such access is acquired.  

[Arakasi 549]

7 hours ago, claudiu said:

Hi Marcos,

I am pretty sure you will provide a sophisticated explanation, yet the fact remains: ESET, wit a dedicated "antiransomware" module, failed to protect OP .

 

In addition, as described. ESET is not at fault here, but the best practices and methods of the infrastructures security settings and policies "might be".

An account with admin privileges able to remove or disable ESET's modules would be the main culprit. At that point they could run or launch whatever they wanted to. Followed by a restart or re-enable of the product.

Not insinuating at all that thats what happened but we will never know without forensically examining the history and logs if exists.

[JamesR 52]

@mayowa or others in similar situations.

Reasons files on a server get encrypted, regardless of security solution:

1. RDP Brute Force succeeded and security solution was removed, then encryption of files began.
   • If Admin rights are gained to a network and an attacker logs in just like an Admin would, then nothing can protect you against any actions they would like to take (Install/uninstall applications, creation of new user accounts, password scrambling of accounts, encryption, stolen data, crypto-currency mining, etc).
   • To mitigate this, either implement 2FA for RDP or only allow RDP to happen across a VPN (the VPN solution should use an authentication method that can not be brute forced.  Implementing 2FA on VPN Authentication will prevent a brute force).
   • Its good to know what ports are open on any public IPs for a network.  Close any ports that have vulnerabilities or are hosting services that are susceptible to Brute Force attacks.  NMAP command to identify open ports on a public IP: nmap -F %PublicIP%
2. Only Shared Files on the server are encrypted due to a workstation which did not have protections installed
   • If a workstation on a domain does not have protections installed and becomes infected, it can locate shares on a network and if the user on the workstation has proper rights to modify, delete, etc... then it will be able to encrypt the files on that share.  This can not be stopped by protections on the server due to no process going active on the server.  The server simply sees the user on the infected workstation requesting to modify the files and the server allows it.
     • If a workstation where a user is logged in as Domain Admin (or enterprise admin, etc...) then the infection could reach out to any C$ to encrypt.
   • Key problem here is that if you are not auditing systems to ensure security protection is deployed, then you might have an unprotected system that could lead to very serious damage.
3. Disabling or altering of ESET settings beyond their defaults.  Disabling items like "Cloud Based Detection" (ESET LiveGrid Reputation System) or other parts of protection will effectively remove layers of protection which are essential to preventing infections.
   • To see if your security is working properly on machines, you can follow the steps on AMTSO to test if your Desktop Security Solutions are working properly.  You need to ensure that you follow the instructions on the AMTSO site for each test.  Some of the tests are meant to show detection only while a file is being downloaded and not detection while the file is on disk.  You can find a list of tests here:
     • https://www.amtso.org/security-features-check/

While these reasons might not be the only reasons someone sees an infection occur on their network, they are the most reasons I have seen.

[mayowa 1]

Thank you all remediation communicated to client as suggested 

[jdashn 12]

Could it have been a keystroke logger not detected, and not an RDP brute force that was the cause of the breach? I know there have been discussions in the past about how certain processes that can be used to create a keylogger are not blocked?

 

 

 

[itman 1,659]

33 minutes ago, jdashn said:

Could it have been a keystroke logger not detected, and not an RDP brute force that was the cause of the breach?

Since it was a ransomware attack, I would say the probability is low. Keyloggers are installed on corp. systems for data pilfering purposes. They are designed to be as stealth as possible to avoid detection.

Edited June 27, 2018 by itman

[jdashn 12]

I'm not sure why it would not be that a simple undetected keylogger was run, credentials gained (thats the data they're looking to pilfer usually), and those creds used to disable eset and infect the computer with ransomware, instead of a brute force attempt on RDP.

I understand that most of the bad actors seen by ESET come in via RDP, but if the keylogger is never detected one might reasonably assume the PW was brute-forced. Especially if the common wisdom/training aligns to suggest that it was RDP Brute-force?

I would guess a bad actor who can get creds (either via rdp bruteforce, or keylogger or another exploit) will use them to whatever 'best effect' they can. If the company has CC#s to steal and the badguy can sell them they'll do that, if they can't find anything quickly i'd imagine they'd throw on some ransomware and move on to the next target. I would imagine most who are 'hacked' (keylogger, exploit, rdp bruteforce) aren't so much targeted for the data they have, as much as they are targeted for the low hanging fruit they are (they ran a keylogging script, they have rdp available over internet, other exploit).

Then again, it's totally just a guess, and i'd hate to (in a situation of a breach especially) suggest that I know what caused this particular issue, but i would also think it's important to have all of the possibilities laid out.

 

 

[itman 1,659]

Below are a few publications that should be read by corp. users in regards to ransomware protection:

1. Best practices: https://support.eset.com/kb3433/?locale=en_US&viewlocale=en_US

2. Applicable firewall and HIPS rules:

https://support.eset.com/kb6119/?locale=en_US&viewlocale=en_US

http://www.nod32.com.hr/Portals/66/PDF/anti-ransomware-techbrief_en.pdf

Although I am an end user and use Internet Security ver. 11, I still deploy the rules given in the .pdf as an extra measure of protection.