Jump to content
RoboMan

"pyrate", Behavior Blocker Bypass POC

Recommended Posts

Hello everybody, evening to y'all. Well, basically this: https://malwaretips.com/threads/pyrate-behavior-blocker-bypass-poc-3.100636/

MacDefender has over time shared several files that bypass many antivirus behaviour blockers by using 3rd party signed executable files, like 7-zip. He just reciently shared a recreative malware test file using Python, which dodged any ESET protection. I believe this isn't as bad, since using a signed trusteable file for malicious activity is difficult to deal with (CCleaner case, for example). I'd like to know your opinion, why ESET fails to realize what's going on, and how to prevent this kind of attacks by happening. As it goes:

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\", so it is safe to execute on your host machine (but please don't take my word for it). There are two ways to run it:

  • 7zip SFX: The default package is a 7zip self extracting EXE that automatically executes pyrate.py after unzipping. This in theory should trigger more behavior blockers because it starts out as an untrusted, unsigned EXE.
  • "start.bat": You can use 7zip to extract the .exe and then directly launch "Start.bat". As we've seen many times, AVs currently are pretty bad at understanding that batch files started by the user are untrustable.
  • "bonus" backdoored IDE: There is a much more dangerous version of this exploit possible. When the Python interpreter starts, it actually executes many .py/.pyc scripts that are part of the Python built-in libraries. Even if you use a host hardening system that blocks batch files, you can still booby trap the fully signed Python.exe executable and cause it to run the ransomware on launch. This is the "bonus" test column:

 

1588633845824.png

Quote

Other Commentary: I think this is an especially dangerous exploit. This is a full blown Python runtime with wintypes. It has the complete ability to call arbitrary Win32 APIs, snoop around network shares, etc etc etc. It goes to show that a major weakness of AMSI for script defense is that it requires your scripting engine to be AMSI-aware. This Python binary is not compiled with AMSI.

The "bonus" attack of sticking a ransomware script into the startup file for the Python IDE is basically a new form of macro viruses. The behavior blocker logic of "User started Python IDE, Python IDE is trusted and sometimes saves to My Documents, therefore, ignore what the Python IDE is doing" is fundamentally flawed when an application is a full blown scripting environment. It doesn't matter if an executable is common, signed, and generally good reputation if that executable is a scripting language interpreter!

If you'd like the sample to have a closer look, I can share it over DM to avoid catastrophes.

Share this post


Link to post
Share on other sites
Posted (edited)

Actually, I have brought up this issue previously. That is python runtime can be bundled with malicious script into an .exe. My statement at the time was that python runtime bundled in such a way should be at least be flagged as suspicious activity. I didn't get any Eset response at that time and doubt you will get one now.

Edited by itman

Share this post


Link to post
Share on other sites
1 hour ago, itman said:

Actually, I have brought up this issue previously. That is python runtime can be bundled with malicious script into an .exe. My statement at the time was that python runtime bundled in such a way should be at least be flagged as suspicious activity. I didn't get any Eset response at that time and doubt you will get one now.

I play my secret card, level 100, which counters ignored threads by staff: tagging @Marcos

Share this post


Link to post
Share on other sites

I was unable to find a download link for the PoC. It's still PoC, not actual malware so AV vendors had no chance to analyze it and possibly adjust detection. One can't expect 100% proactive malware protection, that doesn't exist and there's no AV detecting 100% of new malware and PoCs. One should keep that in mind and not 100% rely on that AV will always detect 100% of malware.

Without analyzing the PoC it's impossible to comment on it.

Share this post


Link to post
Share on other sites
6 hours ago, itman said:

That is python runtime can be bundled with malicious script into an .exe.

I'm not an expert in this but I assume the Python runtime stays innocuous even if bundled in an exe. Files in exe archives are scanned separately so detecting the runtime would mean we would have to detect it regardless of its location, even in the installation folder or wherever the runtime is located.

Share this post


Link to post
Share on other sites
1 hour ago, Marcos said:

I was unable to find a download link for the PoC. 

Without analyzing the PoC it's impossible to comment on it.

Marcos, I just sent the download link, you can check your inbox. I'd like your insight in the matter please :)

 

Share this post


Link to post
Share on other sites
6 hours ago, Marcos said:

I'm not an expert in this but I assume the Python runtime stays innocuous even if bundled in an exe. Files in exe archives are scanned separately so detecting the runtime would mean we would have to detect it regardless of its location, even in the installation folder or wherever the runtime is located.

https://github.com/jabbalaci/PythonEXE

https://realpython.com/pyinstaller-python/

The bottom line here is the Python engine components are not malicious, the embedded script most certainly can be. And "bet your booties" that the script will be packed, encrypted, or obfuscated in such a way that it won't fully decode until executed. Win AMSI also is basically worthless against stand alone Python scripts since it doesn't by default analyze them.

Share this post


Link to post
Share on other sites
Posted (edited)

The prototype for this POC comes out of a posting on malwaretips .com: https://malwaretips.com/threads/macdefender-test-2-trojan-ransomware.98294/#post-857972 . Someone discovered that using 7-zip's main process, 7z.exe, can be used to perform nasty stuff. It also slips by a lot of AV's because it is a trusted process.

Edited by itman

Share this post


Link to post
Share on other sites

Also before anyone gets real excited about this, it was pointed out in the comments section of original linked malwaretips.com reference that Win 10 native SmartScreen will trigger on attempted execution since the process is unknown, unsigned, and definitely not a Win Store download.

Share this post


Link to post
Share on other sites

Here's a book, 'Creating a Ransomware With Python', in .pdf format for those wanting to get into the "nitty gritty":

Quote

There are many different ways that a ransomware can infect a device. The most common method is through email spam. The email might include attachments such as trapped PDFs or links to malicious websites. In this article, we will show you how to create your own ransomware with Python. You should know that attackers create ransomware by using techniques dedicated to data security such as AES and RSA algorithms, which we will be using in order to conceive our own ransomware.

https://hakin9.org/product/creating-a-ransomware-with-python/

 

Share this post


Link to post
Share on other sites
Posted (edited)

I guess it's also time to talk a bit why conventional AV products have problems detecting Python based malware other than by signature methods.

Python is an interpretive language. That is it uses an interpreter process to run its code. Windows facilitates this by loading the Python engine into a visualized container. The problem is that only the OS has access to this container. This also in effect nullifies AV sandbox heuristic analysis of Python based executable's since they in effect won't run in a conventional sandbox environment. Ditto for any other post execution methods such as memory scanning and the like.

Appears to me AV's have to come up with a way to extract the associated Python script from the executable while sandbox. Then come up with a way to unmask packed, encrypted, or obfuscated scripts outside of current AMSI script examination methods to detect suspicious/malicious code usage. Until this can be accomplished, the Python .exe should be de facto deemed suspicious, given an obfuscated code alert message, and quarantined. I for one have long held to the assumption that an unknown process containing like masked script code is in the majority of cases malicious.

Edited by itman

Share this post


Link to post
Share on other sites
1 hour ago, RoboMan said:

@Marcos Any feedback?

A detection was added on the same day. ESET is currently the only AV to detect the script at VT.

The task is pending for a deeper analysis by developers.

 

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, Marcos said:

A detection was added on the same day. ESET is currently the only AV to detect the script at VT.

The task is pending for a deeper analysis by developers.

Thank you. I hope devs find a way to fight back these kind of malware; OP realized it was being detected and counter-responded (still it's educational)

Quote

I made a very small change to the script, renaming two functions.

--- pyrate.py   2020-05-11 16:02:57.354937100 +0000
+++ "pyrate - Copy.py"  2020-05-04 20:34:50.040466800 +0000
@@ -11,7 +11,7 @@

     return buf.value

-def enc(src, dst):
+def encrypt(src, dst):
     print("Encrypting " + dst)
     srcfile = open(src, 'rb')
     dstfile = open(dst, 'wb')
@@ -19,10 +19,10 @@
     srcfile.close()
     dstfile.close()
     os.remove(src)
-def ran(dir):
+def ransom(dir):
     for filename in os.listdir(dir):
         if not filename.endswith(".enc"):
-            enc(dir+filename, dir+filename+".enc")
+            encrypt(dir+filename, dir+filename+".enc")


-ran(find_mydocs()+"\\test\\")
+ransom(find_mydocs()+"\\test\\")
Quote

No detection anymore. And this is the problem with trying to use signatures to respond to scriptors -- there are so many ways to mutate a script and this isn't even using any fancy form of obfuscation.

Hopefully devs find a way to cut it off from root :)

Edited by RoboMan

Share this post


Link to post
Share on other sites
Posted (edited)
Quote

BTW, the signature for this file is very specific. This change alone (from single quotes to 3 quotes) results in no detection:

-            encrypt(dir+filename, dir+filename+""".enc""")
+            encrypt(dir+filename, dir+filename+".enc")

 

Quote

In my opinion it's almost a waste of time for ESET to be adding signatures for this script. Signature detections are not the right approach here. Maybe a Python sandbox or better, runtime behavior detection.


EDIT: What I would really like is an explanation for why their Ransomware Shield isn't working against this sample. ESET says:

Ransomware Shield | ESET Glossary | ESET Online Help
Ransomware Shield is a behavior-based detection technique that monitors behavior of applications and processes that try to modify files in the way common for ransomware/filecoders. If an application´s behavior is considered malicious, or the reputation-based scanning shows an application to be suspicious, the application is blocked and process is stopped, or the user will be asked to block or allow it.


This sounds like a behavior blocker and similar to how WiseVector stops ALL variants of this attack, and how KSW and some other behavior blockers can stop the start.bat variant.

 

 

Edited by RoboMan

Share this post


Link to post
Share on other sites

One should look at the other AVs as well and also make a test with legitimate Python scripts that encrypt files to find out if the others can detect it and not detect legitimate stuff. It's not difficult to have 100% detection, what is difficult is to reliably distinguish between malicious and legitimate stuff.

Share this post


Link to post
Share on other sites
Posted (edited)
6 minutes ago, Marcos said:

One should look at the other AVs as well and also make a test with legitimate Python scripts that encrypt files to find out if the others can detect it and not detect legitimate stuff. It's not difficult to have 100% detection, what is difficult is to reliably distinguish between malicious and legitimate stuff.

Marcos, I agree and understand what your point is; nevertheless we can't compromise security in exchange for lower FPs. I deeply believe this is not a fact to discuss on signature or behaviour-detection, but actually in default-deny and software restriction. The only way to assure the user isn't getting infected by a random script is to block it by default. An advanced user can later unblock it/whitelist it if he was intentionally running it; but most novice/normal users will not even realise there was a python script running in the background, therefore a default deny action over it would be enough to avoid infection, don't you think?

Edited by RoboMan

Share this post


Link to post
Share on other sites

As I wrote, the Python script will be subject to deeper analysis. Also I must disagree with that FPs are not as important as malware detection. An FP can have much worse effects than a missed malware. Imagine that dozens of servers or thousands of endpoints would be rendered unusable in minutes because of a false positive.

Share this post


Link to post
Share on other sites
1 hour ago, Marcos said:

Also I must disagree with that FPs are not as important as malware detection. An FP can have much worse effects than a missed malware. Imagine that dozens of servers or thousands of endpoints would be rendered unusable in minutes because of a false positive.

Imagine they're unusable because their antivirus couldn't stop a ransomware script. Either way, aforementioned, the only solution would be default denying.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Marcos said:

An FP can have much worse effects than a missed malware. Imagine that dozens of servers or thousands of endpoints would be rendered unusable in minutes because of a false positive.

This is a valid statement for commercial installations. However, there are numerous retail users that would very much like to see optional detection mechanisms added to Eset to enhance malware detection regardless of the higher risk of false positives.

I also find it a bit odd that Microsoft has provided advanced surface reduction (ASR) rules for Windows Defender. Those rules have to be applied using specific PowerShell commands. In other words, it appears this feature is very much directed to commercial installations and is being deployed by them.

-EDIT- Forgot to list a few notable ASR mitigations:

  • Block execution of potentially obfuscated scripts.
  • Block JavaScript or VBScript from launching downloaded executable content.
  • Block Office applications from creating executable content.
  • Block process creations originating from PSExec and WMI commands.
  • Block executable files from running unless they meet a prevalence, age, or trusted list critera*

* Aah .............. a reputational scanner "with some meat to it."

Edited by itman

Share this post


Link to post
Share on other sites
Posted (edited)

Getting back to the specifics of the POC, note how Python was run:

RunProgram="python\\python.exe pyrate.py"

Quote

There are two ways to run a installation program: RunProgram and ExecuteFile. Use RunProgram, if you want to run a program from the .7z archive. Use ExecuteFile, if you want to open a document from the .7z archive, or if you want to execute a command from Windows.

If you use RunProgram, and if you specify empty directory prefix: Directory="", the system searches for the executable file in the following sequence:

  1. The directory from which the application (installer) loaded.
  2. The temporary folder, where files were extracted.
  3. The Windows system directory.

https://documentation.help/7-Zip/sfx.htm

To summarize the events:

  1. Unknown/unsigned .exe dropped on device.
  2. The .exe contains an embedded 7zip self-extracting archive.
  3. The archive in turn spawns the Python executable as a child process from Python runtime components also extracted from the archive.
  4. The self-extracting archive contains a read-me file.
  5. The Python executable runs a Python script that contains ransomware encryption code.

Ignoring no. 5 script execution details, are not the above activities enough to warranty a suspicious detection and resultant quarantine of the unknown .exe?

Finally ponder the detection outcome if this Python script was obfuscated along this line: https://liftoff.github.io/pyminifier/ . Note this section:

Quote

Special Sauce

So let’s pretend for a moment that your intentions are not pure; that you totally want to mess with the people that look at your minified code. What you need is Python 3 and the --nonlatin option...

 

Edited by itman

Share this post


Link to post
Share on other sites
1 hour ago, itman said:

This is a valid statement for commercial installations. However, there are numerous retail users that would very much like to see optional detection mechanisms added to Eset to enhance malware detection regardless of the higher risk of false positives.

I also find it a bit odd that Microsoft has provided advanced surface reduction (ASR) rules for Windows Defender. Those rules have to be applied using specific PowerShell commands. In other words, it appears this feature is very much directed to commercial installations and is being deployed by them.

-EDIT- Forgot to list a few notable ASR mitigations:

  • Block execution of potentially obfuscated scripts.
  • Block JavaScript or VBScript from launching downloaded executable content.
  • Block Office applications from creating executable content.
  • Block process creations originating from PSExec and WMI commands.
  • Block executable files from running unless they meet a prevalence, age, or trusted list critera*

* Aah .............. a reputational scanner "with some meat to it."

Sort of agree here. While there are advanced users that would like such functionality, such as those of us that are here, there are innumerable users out there that merely want to be protected. They couldn't care less how apps work or how antimalware works or how it protects them.

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.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...