Ransom simulation - Should be detected?

[rubencastello90 1]

Hello,

Some of my clients are being audited by third party pentesters and I noticed that they use powershell scripts in order to simulate RANSOMWARE encryptions and generate panic on them indicating that they were able to encrypt files on computers.

Some of those test, have compromised physical the machine, asking the user to leave them 5 min the computer in order to fix it. So, access gain to machine was easy. No point here to investigate.

I'm a little bit worried because I tried today on my own with a Windows Server with ESET last version and encryption ended successfully without any alert on ESET.

Anything I'm missing up?

Used script that found: https://github.com/lawndoc/RanSim

License used: Eset protect Entry. Should a superior license like XDR detect it?

 

 

 

 

Edited May 8, 2023 by rubencastello90
new title

[Marcos 5,070]

ESET is supposed to trigger detection if encryption of actual files unrelated to the application (simulator) occurs. Suspicious behavior may be reported by ESET Inspect, however.

Note that if an AV detects encryption simulation does not mean that it would detect also actual ransomware encryption and vice-versa.

[itman 1,659]

See my posting here: https://forum.eset.com/topic/10792-ransomware-simulators-a-detailed-analysis/ in regards to RanSim.

[itman 1,659]

As far as Eset protection against both real and simulated ransomware attacks, refer to the Ransomware test section of this report: https://www.mrg-effitas.com/wp-content/uploads/2023/02/MRG_Effitas_360_Q4_2022.pdf .

[itman 1,659]

Finally, refer to the following and linked article for additional ransomware mitigations;

Quote

• Configure additional settings to protect against ransomware in ESET business products manually or using ESET PROTECT/ESET PROTECT Cloud Policy

  • Configure HIPS rules for ESET business products

  • Configure Firewall rules for ESET Endpoint Security

  • Configure ESET Mail Security

 

https://support.eset.com/en/kb3433-best-practices-to-protect-against-filecoder-ransomware-malware

[rubencastello90 1]

Hi thank you all for the answers.

So, If I don't misunderstood, one of the biggest points, is that simulators usually creates that files and encrypts them so it's the same process acting with the same files and this can be obviously legit.

But in the case I was showing, I copied and pasted 1000 files from file server and then dropped in an updated server on C:\RanSim. So these files were not created by the main process of the simulation.

I'm missing something else?

[Marcos 5,070]

The question is if the script crawled the disk for actual files and encrypted. I guess no, otherwise it would not be a simulator but actual malware and this behavior would be likely detected.

[itman 1,659]

4 hours ago, rubencastello90 said:

But in the case I was showing, I copied and pasted 1000 files from file server and then dropped in an updated server on C:\RanSim. So these files were not created by the main process of the simulation.

I'm missing something else?

The problem is Eset doesn't detect Ransim as ransomware; or malware for that matter.

To actually test Eset ransomware dynamic; i.e. behavioral, protection, you need to find a 0-day ransomware sample not detected by Eset static detection methods; e.g. signature. Then run the ransomware on a test device totally isolated from the local network. The first thing that should happen once the ransomware binary is created on the test device is the submission of the file to Eset clould servers for analysis assuming LiveGuard Advanced is deployed. In most cases, the ransomware activities will be detected there and the sample deleted from the local device.

Edited May 9, 2023 by itman

[itman 1,659]

Hum .......... I didn't realize someone at Github wrote a PowerShell encryption script: https://github.com/lawndoc/RanSim/blob/main/RanSim.ps1

@Marcos Eset should be detecting this. It can be easily modified to be used against user directories.

[itman 1,659]

This GitHub PowerShell based ransomware script intrigued me, so I set about testing with it myself.

I first only downloaded the script itself. It was sent to LiveGrid which detected nothing. The reason for the non-detection will become obvious in the following.

Next, I modified the script to use a test sub-directory in My Documents as follows to make it a bit more realistic;

$TargetPath = "$Env:USERPROFILE\Documents\Test"

I then ran the script and received PowerShell alerts on every file it tried to encrypt although the last message from the script was that 6 files in the test sub-directory where encrypted. Upon inspection, the files were not encrypted. Something not right here .......

I then downloaded the entire zipped source from GitHub and saw what the issue was;

The author stored his encryption code in a PowerShell script module file. Clever .............

Again I ran the PowerShell script from the RanSim-main folder after establishing it as the active directory and it then successfully encrypted files in my folder;

Quote

C:\Users\xxxxxx\Downloads\RanSim-main\RanSim-main>powershell.exe -command C:\Users\xxxxxxx\Downloads\RanSim-main\RanSim-main\ransim.ps1 -mode encrypt

Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning message. Do you want to run C:\Users\xxxxxxx\Downloads\RanSim-main\RanSim-main\FileCryptography.psm1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"): R
Encrypting C:\Users\xxxxxx\Documents\Test\Bootsect on Windows.docx

    Directory: C:\Users\xxxxxxx\Documents\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----          5/9/2023   3:41 PM          13924 Bootsect on Windows.docx.encrypted
Encrypting C:\Users\xxxxxxx\Documents\Test\Eset_Trusted_Zone_Addresses.txt
-a----          5/9/2023   3:41 PM             84 Eset_Trusted_Zone_Addresses.txt.encrypted
Encrypting C:\Users\xxxxxxx\Documents\Test\MBRWizard.txt
-a----          5/9/2023   3:41 PM           4596 MBRWizard.txt.encrypted
Encrypting C:\Users\xxxxxxx\Documents\Test\Notes_4-17-2030.txt
-a----          5/9/2023   3:41 PM            980 Notes_4-17-2030.txt.encrypted
Encrypting C:\Users\xxxxxxx\Documents\Test\Win10_Bootsect_Utility.txt
-a----          5/9/2023   3:41 PM           1268 Win10_Bootsect_Utility.txt.encrypted
Encrypting C:\Users\xxxxxxx\Documents\Test\Winobj_Physical_Drive_Spec.txt
-a----          5/9/2023   3:41 PM            516 Winobj_Physical_Drive_Spec.txt.encrypted
Encrypted 6 files.

Refer to the above highlight text. That text doesn't originate from the Github PowerShell script or associated script module. At least, I couldn't find it there. The warning is coming from Win 10.

Is this a valid example of Eset ransomware protection being bypassed? Well, maybe if you're a complete security nob who ignores security warnings in regards to a .psm1 script wanting to execute "out of the blue."

-EDIT- As noted in the highlighted text if the script developer would have used;

Import-Module "$PSScriptRoot\FileCryptography.psm1" -cmdlet Unblock-File

or ran cmdlet Unblock-File prior to the Import instruction, this would have allowed the .psm1 script to run unimpeded since Unblock-File strips the "mark-of-the-web" from the file ADS.

Not good .................

Edited May 9, 2023 by itman

[rotaru 10]

On 5/8/2023 at 2:11 PM, itman said:

As far as Eset protection against both real and simulated ransomware attacks, refer to the Ransomware test section of this report: https://www.mrg-effitas.com/wp-content/uploads/2023/02/MRG_Effitas_360_Q4_2022.pdf .

From 8 entities tested, 6 passed the "ransomware test" with 100% (including Windows Defender)

I my opinion this test proves nothing...

[rotaru 10]

9 hours ago, itman said:

In most cases, the ransomware activities will be detected there and the sample deleted from the local device.

...after encrypting a bunch of files already...

[el el amiril 0]

14 hours ago, itman said:

This GitHub PowerShell based ransomware script intrigued me, so I set about testing with it myself.

I first only downloaded the script itself. It was sent to LiveGrid which detected nothing. The reason for the non-detection will become obvious in the following.

Next, I modified the script to use a test sub-directory in My Documents as follows to make it a bit more realistic;

$TargetPath = "$Env:USERPROFILE\Documents\Test"

I then ran the script and received PowerShell alerts on every file it tried to encrypt although the last message from the script was that 6 files in the test sub-directory where encrypted. Upon inspection, the files were not encrypted. Something not right here .......

I then downloaded the entire zipped source from GitHub and saw what the issue was;

The author stored his encryption code in a PowerShell script module file. Clever .............

Again I ran the PowerShell script from the RanSim-main folder after establishing it as the active directory and it then successfully encrypted files in my folder;

Refer to the above highlight text. That text doesn't originate from the Github PowerShell script or associated script module. At least, I couldn't find it there. The warning is coming from Win 10.

Is this a valid example of Eset ransomware protection being bypassed? Well, maybe if you're a complete security nob who ignores security warnings in regards to a .psm1 script wanting to execute "out of the blue."

-EDIT- As noted in the highlighted text if the script developer would have used;

Import-Module "$PSScriptRoot\FileCryptography.psm1" -cmdlet Unblock-File

or ran cmdlet Unblock-File prior to the Import instruction, this would have allowed the .psm1 script to run unimpeded since Unblock-File strips the "mark-of-the-web" from the file ADS.

Not good .................

wooah not good eset team should make a statement

[itman 1,659]

Eset improvements needed for ransomware detection in regards to LiveGuard.

Downloaded files that contain executable code and can be run from scripts such as .psm1 files need to be submitted to LiveGuard. Then scanned for code related to encryption activities. Whereas no determination as to actual malicious use of this code can be made at this time, the file should be classified as suspicious and quarantined. If later user analysis shows the file is associated with a verified legit app, it can then be manually released from quarantine.

Edited May 10, 2023 by itman

[itman 1,659]

Pondering a bit more in regards to this RanSim script, I see an issue with Eset local based script scanning methods.

Eset is supposed to scan PowerShell.exe, wscript.exe. and csript.exe scripts via the Win 10/11 AMSI interface prior to execution. When scanning the .ps1 script code, the Import Module code would have been encountered. One would assume at that point, Eset would fetch and load the .psm1 referenced file and scan its code. Since the encryption code is clearly visible there, is this not enough justification to determine the .ps1 script was potential ransomware? Or is the case here, Eset didn't recognize the encryption code at all?

-EDIT- Or .......... Here's what happened. The .ps1 script was submitted to LiveGuard;

Time;Hash;File;Size;Category;Reason;Sent to;User
5/9/2023 3:32:14 PM;7F7F234C8364AA255CBA3C070BFC77737E64B6D3;C:\Users\xxxxxx\Downloads\RanSim-main\RanSim-main\RanSim.ps1;2755;Script;Automatic;ESET LiveGuard;xxxxxx

No detection by LiveGuard and Eset whitelisted the script. When the .ps1 script ran, no AMSI scanning was done. Best analogy here is "A mouse trap that when set, immediately smacks you in the face."

Edited May 10, 2023 by itman

[itman 1,659]

It's a new day. Ranting completed, its time to unmask the RanSim PowerShell script for what it is.

For starters, it is not simulated ransomware. It lacks all the behavior characteristics of ransomware other than encryption. Some of those characteristics are;

1. Remote communication to attacker's C&C server to upload files for subsequent extortion activities and/or to download ransomware payload.

2. Deletion of shadow volume files to prevent file restoration from backups stored there.

3. System modification activities including disabling existing security software.

4. Creation of desktop ransomware note and display of same via locked screen at next system startup.

Actually, Github has a number of available ransomware simulators that do actually mimic real ransomware behavior.

So what is this RanSim PowerShell script? It's a filecrypter and not a very good one since the decryption key is displayed in clear text in the script. The problem here as far as AV detection goes is there are a number of legit software that can perform encryption including Win 10 Pro+ versions and Eset itself in the Smart Security Premium version. Of course, one could write their own encryption code as illustrated by this script.

Should Eset have detected this script? I say yes as a PUA filecrypter generic since the script was downloaded from the Internet with no/low reputation status. Script's like this one can still create havoc on the target installation by disrupting apps trying to access encrypted files and system downtime to restore encrypted files via shadow volume copies, etc..

Edited May 11, 2023 by itman

[itman 1,659]

Now this is very weird. Eset now detects the RanSim PowerShell script:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/11/2023 10:38:24 AM;Real-time file system protection;file;C:\Users\xxxxx\Downloads\RanSim-main\RanSim-main\RanSim.ps1;PowerShell/HackTool.Agent.AZ trojan;cleaned by deleting;xxxxxx;Event occurred during an attempt to access the file by the application: C:\Windows\System32\svchost.exe (1BC5066DDF693FC034D6514618854E26A84FD0D1).;02022B6654847445D6FC9892F944F8E808D52188;5/9/2023 2:42:42 PM

Problem is I didn't access the script in any way and the detection log entry shows the parent process was svchost.exe? I know of no way this script could have established persistence on my device.

-EDIT- Also there was a LiveGuard submission of the script just prior to the above detection. Again, I did not access the script manually in any way. I assume the Eset detection was a result of LiveGuard submission.

Time;Component;Event;User
5/11/2023 10:38:20 AM;ESET Kernel;File 'RanSim.ps1' was sent to ESET Virus Lab for analysis.;SYSTEM

Is Eset now performing some type of dynamic real-time scanning of User directories?

Edited May 11, 2023 by itman

[itman 1,659]

54 minutes ago, itman said:

Is Eset now performing some type of dynamic real-time scanning of User directories?

No, that's not the case. I still have a copy of RanSim.ps1 stored previously. Looks like Eset is using my device as a test platform which is scary stuff.

I will "play" with that copy to see if I can bypass LiveGuard to load the .psm1 file from other than source directory where RanSim.ps1 is stored.

In any case, it's encouraging to see Eset is working on the LiveGuard script scanning issue.

[Marcos 5,070]

53 minutes ago, itman said:

No, that's not the case. I still have a copy of RanSim.ps1 stored previously. Looks like Eset is using my device as a test platform which is scary stuff.

This is definitely not true. A detection was added yesterday. Without logs we can't tell why it was submitted unless you have modified the default script.

[itman 1,659]

3 hours ago, Marcos said:

This is definitely not true. A detection was added yesterday. Without logs we can't tell why it was submitted unless you have modified the default script.

I didn't touch the script in anyway prior to the LiveGuard submission. Also as my posted log indicates, it was svchost.exe which attempted to access the script resulting in Eset detection of the script by sig.. which occurred 4 secs. after the LiveGuard submission. Note at this time I was on the Eset forum in the related posting at the time. Also. an Eset staff member with the initials MK was connected to the same thread. See more details below.

Of note here is since the script was submitted by LiveGuard, it would have locked the file from access; or is supposed to to do. As such, anything including a Win service should not have been able to access the script. Finally, there is the question why the script was submitted to LiveGuard in the first place.

Of note here is I have seen weird Eset generated activity when connect to the Eset forum in regards to LiveGuard. An example is this morning I was on the forum reading the posting about the loader.vbs detection in the Malware section. I opened a new FireFox tab and did a Google search on loader.vbs resulting in this LiveGuard submission;

Time;Hash;File;Size;Category;Reason;Sent to;User
5/11/2023 8:44:41 AM;F1AC1B09247B83A27C1D96988550731A75F942DA;https://www.google.com/search?client=firefox-b-1-d&q=C:\ProgramData\Microsoft\IOBitUnlocker\loader.vbs;520909;Script;Automatic;ESET LiveGuard;xxxxxx

Note the LiveGuard submission occurred prior to any Google search results rendering.

[Marcos 5,070]

Hard to say what happened. Firstly, the script was already detected so it should not be sent. Secondly, F1AC1B09247B83A27C1D96988550731A75F942DA is the html code of the Google page below. It was not detected and nothing was submitted when I opened it:

[itman 1,659]

54 minutes ago, Marcos said:

It was not detected and nothing was submitted when I opened it:

Repeatable on my ESSP installation:

Edited May 11, 2023 by itman

[Marcos 5,070]

I was able to reproduce it as well. The file was sent because of ".vbs" at the end of the url which normally indicates a script and the extension is one of script identifiers. It doesn't hurt if the html code is submitted and even the web page is rendered properly.