"pyrate", Behavior Blocker Bypass POC

[SeriousHoax 83]

11 minutes ago, NewbyUser said:

As for MS ASR, I believe it's part of Windows Defender ATP, which is oriented towards commercial/enterprise users, not the typical home user.

All the ASR are available for Windows Defender too.

[NewbyUser 72]

6 minutes ago, SeriousHoax said:

All the ASR are available for Windows Defender too.

Thanks,wasn't sure. That;s why I used I "believe" lol

[itman 1,659]

I think its also time Eset start offering an optional Home product version of their Commercial EDTD product. This is Eset's equivalent offering to Windows Defender ATP cloud protection. Price it to compete with WD ATP which as I recollect costs less than $10 per month on Win 10 Pro versions; cost would be per each license seat.

Edited May 15, 2020 by itman

[NewbyUser 72]

1 hour ago, itman said:

I think its also time Eset start offering an optional Home product version of their Commercial EDTD product. This is Eset's equivalent offering to Windows Defender ATP cloud protection. Price it to compete with WD ATP which as I recollect costs less than $10 per month on Win 10 Pro versions; cost would be per each license seat.

I think home users already benefit somewhat from this as it feeds info into LiveGrid.

[itman 1,659]

It's been a slow forum posting weekend and it appears this thread has run its course. We have all had the opportunity to "rant and rave" about Eset Home version protection features we all wished we had and in reality, probably never will have. So it is time to expose this Python POC for what it is - fake ransonware. Err ..... what, you say? The POC encrypted files. Well so does a lot of legit encryption and other apps including user created ones. So lets get into this.

A few years back, the NextGen security software vendors were trying "to get traction" against the established AV vendors with their supposed superior behavior detection methods. Corresponding to this was the appearance a proliferation of ransomware "simulators" where one was encouraged to test their existing AV solution with. The most infamous of these was RanSim produced by KnowBe4: https://www.knowbe4.com/ransomware-simulator . I wrote a thread about the methodology used by this product and similar ones here: https://forum.eset.com/topic/10792-ransomware-simulators-a-detailed-analysis/ . Eset subsequently commented upon Ransim tactics in their own publish article on Eset ransomware protection:

Quote

RanSim

This software might be a simulator, but certainly does NOT simulate the behavior of crypto-ransomware. Since it modifies only the files it has created itself, it in fact simulates only “ransomware” that demands payment for decrypting its own files. Were all of the hundreds of ransomware families in the wild to share such an ingenious design, there would be no actual ransomware at all.

ESET products do not – nor will they ever – detect this behavior as malicious, and so repeatedly “fail” in such tests. Actually, if they were to detect it they would also have to detect digital rights management techniques used by digital distribution platforms, such as Steam. These behave similarly, by downloading their own encrypted files – games in the case of Steam – and decrypting them at the right moment. But let us get back to the topic of this section and discuss why we do not approach crypto-ransomware differently.

https://cdn1.esetstatic.com/ESET/INT/Docs/Others/eset-vs-crypto-ransomware.PDF

So let's get into some details on the POC. First, note this from the POC's author posting about it at malwaretips.com:

Quote

This new exploit, "pyrate" as I call it, bundles a copy of Python 3.8 (official Windows zip distribution), a "pyrate.py" ransom core, and an "aes.py" pure Python implementation of AES. It, like my other samples, ONLY encrypts "My Documents\test\"

Next is why no vendor on Virus Total detected the POC initially and I believe presently. That one is pretty straightforward. The ransomware portion of the POC never ran. The POC pauses program execution waiting for user input to continue. VT's automated sandbox analysis timed out waiting for input it does not respond to.

In summary, I am not 100% ruling out that techniques used in the POC could bypass existing Eset ransomware detection methods. However, a POC must be developed deploying real world ransomware deployment and execution methods with the most important being the program runs uninterrupted and encryption activities performed against all existing files in C:\Users\xxxx\Documents\*, etc. directories.

 

Edited May 19, 2020 by itman

[SeriousHoax 83]

POC author's response,

Quote

I haven’t found any behavior blocker that cares whether only one sub directory of My Documents gets encrypted or all of them, they all seem to react to the number of files.

Also the sandbox “it has a prompt” theory is interesting but doesn’t make sense. No scanning engine is going to take the time to execute this whole sample, which involves spending 30+ seconds to decompress 5000 files. That would be a virus scanner that takes 30+ seconds to scan a single EXE. If having a dialog box or doing a bunch of extra work, that’s also going to be an easy way to bypass.

Also, there is no dialog box for the “start.bat” version or the IDLE.exe version. Both of those immediately start encrypting.

The reason that no scanner on VT detects it is because none of the scanning engines tested on VT execute Python scripts or EXEs in a sandbox.

Their analysis of RanSim isn’t correct either — RanSim has a separate process that creates bait documents versus all of the test documents. The real reason why ESET doesn’t detect RanSim is because each test binary is randomly generated and obfuscated and can not be signature detected, and it does not monitor runtime behavior for encryption of files.

AVs with a behavior blocker at least detect some forms of RanSim’s tests. Some of the RanSim tests are really hard to detect because the behavior isn’t suspicious enough or they use complex techniques like splitting the encrypting vs deleting across multiple binaries working together.

It might be worth mentioning that though it is true almost zero AV engines on VT detect my POCs, many AVs are consistently detecting them as ransomware or generic trojans at runtime because of behavior blocking.

If ESET is seriously saying that their BB is smart enough that encrypting My Documents\test is different from encrypting My Documents, I'm more than happy to attempt to disprove that theory. I think we know how that's going to go though.

 

 

[itman 1,659]

2 hours ago, SeriousHoax said:

If ESET is seriously saying that their BB is smart enough that encrypting My Documents\test is different from encrypting My Documents, I'm more than happy to attempt to disprove that theory. I think we know how that's going to go though.

Assumed here is the POC .exe at startup or upon user consent of the displayed prompt creates the My Documents\test directory. The program then copies all or part of existing My Documents files into the My Documents\test directory. The program code then proceeds to encrypt whatever files exist in the My Documents\test directory. Again, Eset will not detect this as ransomware.

Tell the POC author to first manually create the My Documents\test directory and copy whatever files he wants to it. Remove the corresponding program code that does this. Now run the POC directly executing the encryption commands against all files in the My Documents\test directory.

Edited May 18, 2020 by itman

[itman 1,659]

2 hours ago, SeriousHoax said:

The reason that no scanner on VT detects it is because none of the scanning engines tested on VT execute Python scripts or EXEs in a sandbox.

This is a ludicrous statement. Yes, python.exe is a trusted .exe. So no alerting will be done on the .exe. But its scripts certainly are not trusted. I find it a far stretch that no one is scanning Python scripts; especially un-obfuscated ones.

[SeriousHoax 83]

3 hours ago, itman said:

Assumed here is the POC .exe at startup or upon user consent of the displayed prompt creates the My Documents\test directory. The program then copies all or part of existing My Documents files into the My Documents\test directory. The program code then proceeds to encrypt whatever files exist in the My Documents\test directory. Again, Eset will not detect this as ransomware.

Tell the POC author to first manually create the My Documents\test directory and copy whatever files he wants to it. Remove the corresponding program code that does this. Now run the POC directly executing the encryption commands against all files in the My Documents\test directory.

The POC doesn't create this "My Documents\test" directory. The author and other testers including me already created this "test" directory and put files like images, doc, pdf there and only after that the POC was ran. So, ESET failed anyway. You know ESET is mainly a signature based AV without a behavior blocker and the included ransomware shield is worthless.

Edited May 18, 2020 by SeriousHoax

[itman 1,659]

57 minutes ago, SeriousHoax said:

The POC doesn't create this "My Documents\test" directory. The author and other testers including me already created this "test" directory and put files like images, doc, pdf there and only after that the POC was ran. So, ESET failed anyway. You know ESET is mainly a signature based AV without a behavior blocker and the included ransomware shield is a total .

Would have been nice if this was clearly explained originally.

[SeriousHoax 83]

52 minutes ago, itman said:

Would have been nice if this was clearly explained originally.

Right. It didn't come to mind because this is how he created 2 other POCs before as well so didn't thought about fully explaining it this time. He also didn't write anything about the POC creating the folder but I can understand the reason of confusion here.

[itman 1,659]

Upon further research, I am in agreement with @SeriousHoax that Eset malicious Python script detection is 100% signature based. Personally that is unacceptable to me and I have taken measures outside of Eset to "trap" all Python script execution and allow me to examine the scripts prior to execution. In summary, the POC was beneficial to alerting me to this issue so I could implement an alternative mitigation.

[Nightowl 202]

18 minutes ago, itman said:

Upon further research, I am in agreement with @SeriousHoax that Eset malicious Python script detection is 100% signature based. Personally that is unacceptable to me and I have taken measures outside of Eset to "trap" all Python script execution and allow me to examine the scripts prior to execution. In summary, the POC was beneficial to alerting me to this issue so I could implement an alternative mitigation.

I once tried python elevation exploit , it worked so fine , no alerts from Windows / Windows Defender / ESET

An elevation exploit can do much damage , but how so can these AVs detect them if they are not doing anything malicious yet.

And it seems that AVs have problems with Python scripts and Archieve softwares most probably as you said before because AVs designate them as SAFE

Edited May 20, 2020 by Nightowl

[NewbyUser 72]

3 hours ago, itman said:

Upon further research, I am in agreement with @SeriousHoax that Eset malicious Python script detection is 100% signature based. Personally that is unacceptable to me and I have taken measures outside of Eset to "trap" all Python script execution and allow me to examine the scripts prior to execution. In summary, the POC was beneficial to alerting me to this issue so I could implement an alternative mitigation.

What would you suggest for those of us not quite as skilled or knowledgeable as you are?

[itman 1,659]

1 hour ago, NewbyUser said:

What would you suggest for those of us not quite as skilled or knowledgeable as you are?

Nothing.

To begin, most Python ransomware attacks are targeted ones. So unless your a corp., your chances of being targeted are about zip. Bundled Python runtime component attacks are very "noisy" and usually leave a lot of residual artifacts on the device. As such, they aren't suitable for RaaS concerns that are selling their ransomware to the hacker masses.

I don't have Python installed and have no intention to doing so. I am not a gamer that might be using software containing bundled Python runtime comments. Neither am I part of the scientific or research community that might be sharing Python software so bundled. What I am doing will unconditional block any python script from running legit or malicious.

[itman 1,659]

I guess I should mention that I did run the Python POC as a way of testing out my script trap program. Procedure was as follows.

1. Create My Documents\Test directory and copy some existing files into into; e.g. .docx, etc. files.

2. Exclude Python POC .exe, pyrate.exe. from Eset detection by file hash.

3. Start pyrate.exe. When consent prompt appeared, answered "Y" to that. Program displayed "files extracting" graphic display.

4. Python.exe attempted to start and run the pyrate.py script. My trap program prevented python.exe from starting and instead started itself and displayed a window to where script contents would be copied to. Prior to any actual file writing occurring, Eset detected the pyrate.py script as ransomware and prevented the script from being created in my trap file:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/19/2020 3:56:05 PM;Real-time file system protection;file;C:\Users\xxxxxx\AppData\Local\Temp\7zS49990B73\pyrate.py;Python/Filecoder.EA trojan;cleaned by deleting;xxx\xxx;Event occurred on a new file created by the application: C:\Users\xxxxxx\Downloads\pyrate.exe (A224A40F4BB45ED5284DF0653B0BD20351C144B8).;90C618BCCB96C258BE36954FA31D53DC690F2482;5/19/2020 3:56:04 PM

5. Pyrate.exe terminated execution. No files encrypted in My Documents\Test directory.

Observations:

1. Eset has a signature for the Python script itself; not just the pyrate.exe which bundled it in a 7Zip SFX archive.

2. Hopefully this a a generic or Smart signature script detection that will ignore the cosmetic script changes the POC author subsequently made to it and Eset context re-scanning  afterwards didn't detect.

Questions:

1. Puzzled that Eset didn't detect the pyrate.py script after the 7zip archive extraction completed and prior to python.exe attempting to run it. Perhaps Eset needs the script to be actually loaded to memory before it can scan it?  At this point, don't have a "warm and fuzzy Eset feeling" here.

 

Edited May 20, 2020 by itman