Malware Analysis "pyrate", Behavior Blocker Bypass POC #3

[MacDefender]

(heads up to @geminis3, @harlan4096, @SeriousHoax )
DISCLAIMER: This is a conceptual proof of concept, and is meant to test your behavior blocker's degree of whitelisting when a trusted binary is abused for evil purposes. This does not translate to whether or not your AV will detect real ransomware, which often has many other red flags. Do not place anything in My Documents\test\ that is valuable.

This is a follow-up to the "TrojanZipperPOC". Similar to @geminis3 's Ransominator, it abused the fact that 7Zip was trusted and whitelisted by many behavior blockers and therefore its actions were ignored.

But 7zip is kind of boring -- it can only manipulate files and is not a full blown programming language. That got me thinking: Can you get away with an entire Python runtime? It turns out that the official distribution of Python's "python.exe" is both digitally signed as well as marked as trusted by many cloud services -- Norton Insight, KSN, Emsisoft, etc.

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:

1. 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.
2. "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.
3. "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:

For my testing results, I will separate the results between starting the exploit as the EXE vs starting it via "start.bat". If you are a tester, feel free to PM me for the exploit POC to test on your own!

Software	Result for click on EXE	Result for Start.bat	Result for bonus "IDLE Python IDE backdoor"	Tested by	Comments
Kaspersky Total Security 2020 (default settings)	PROTECTED. KSW triggered after 3rd encrypted file, deleted the Pyrate.EXE file, correctly identified that as the cause. Rollback succeeded and restored encrypted files.	ENCRYPTED. No detection at all.	ENCRYPTED	@MacDefender	Kudos to KSW -- it is one of the only BB's I've tested that looks at full execution trees and understands that Pyrate.exe started Python.exe and therefore Python.exe is not trustworthy.
F-Secure FS Protection 17.8 Beta Default Ransomware Protection covering My Documents and other default locations.	ENCRYPTED	ENCRYPTED	ENCRYPTED	@MacDefender
Emsisoft AM Default Settings	ENCRYPTED	ENCRYPTED	ENCRYPTED	@MacDefender	In the "Application Rules" view, the exploit is labeled as "Python.exe" and shows up as trusted and Not Monitored
Norton 360 with Data Protector, default settings	PROTECTED. Data Protector blocked and identified the offending EXE correctly	ENCRYPTED	ENCRYPTED	@MacDefender
WD with ConfigureDefender, no CFA	PROTECTED (rule "Use advanced protection against ransomware" )	ENCRYPTED	ENCRYPTED	@SeriousHoax
WD with CFA	PROTECTED	PROTECTED	PROTECTED	@SeriousHoax	CFA alerted to Python attempting to access My Documents
ESET (without HIPS protected folder simulation)	ENCRYPTED	ENCRYPTED	ENCRYPTED	@SeriousHoax, @MacDefender confirmed the third column

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!

 

[Divine_Barakah]

Thank you very much for your efforts. I really like your tests. Could you please test more products like G Data for example?

 

[Andy Ful]

(heads up to @geminis3, @harlan4096, @SeriousHoax )
DISCLAIMER: This is a conceptual proof of concept, and is meant to test your behavior blocker's degree of whitelisting when a trusted binary is abused for evil purposes. This does not translate to whether or not your AV will detect real ransomware, which often has many other red flags. Do not place anything in My Documents\test\ that is valuable.

This is a follow-up to the "TrojanZipperPOC". Similar to @geminis3 's Ransominator, it abused the fact that 7Zip was trusted and whitelisted by many behavior blockers and therefore its actions were ignored.

But 7zip is kind of boring -- it can only manipulate files and is not a full blown programming language. That got me thinking: Can you get away with an entire Python runtime? It turns out that the official distribution of Python's "python.exe" is both digitally signed as well as marked as trusted by many cloud services -- Norton Insight, KSN, Emsisoft, etc.

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:

1. 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.
2. "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.
3. "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:

View attachment 238748


For my testing results, I will separate the results between starting the exploit as the EXE vs starting it via "start.bat". If you are a tester, feel free to PM me for the exploit POC to test on your own!

Software	Result for click on EXE	Result for Start.bat	Result for bonus "IDLE Python IDE backdoor"	Tested by	Comments
Kaspersky Total Security 2020 (default settings)	PROTECTED. KSW triggered after 3rd encrypted file, deleted the Pyrate.EXE file, correctly identified that as the cause. Rollback succeeded and restored encrypted files.	ENCRYPTED. No detection at all.	ENCRYPTED	@MacDefender	Kudos to KSW -- it is one of the only BB's I've tested that looks at full execution trees and understands that Pyrate.exe started Python.exe and therefore Python.exe is not trustworthy.
F-Secure FS Protection 17.8 Beta Default Ransomware Protection covering My Documents and other default locations.	ENCRYPTED	ENCRYPTED	ENCRYPTED	@MacDefender
Emsisoft AM Default Settings	ENCRYPTED	ENCRYPTED	ENCRYPTED	@MacDefender	In the "Application Rules" view, the exploit is labeled as "Python.exe" and shows up as trusted and Not Monitored
Norton 360 with Data Protector, default settings	PROTECTED. Data Protector blocked and identified the offending EXE correctly	ENCRYPTED	ENCRYPTED	@MacDefender

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!

I have seen this method in the wild one year ago a few times (PyLocky). The malware used the legal installer application (InnoSetup) to install the Python environment in a Temp folder and after the installation, it ran python application (lockyfud.exe) wrapped into EXE by legal PyInstaller tool. By using two wrappers and Python scripting, such malware is hard to detect by proactive AV features.

The similar techniques were successfully used in AVLab banking test:

Test of software for online banking protection

This is our next test from the series of comprehensive tests of various types of products for protection of computers and workstations. In February 2019, we tested dozens of solutions to protect the Windows 10 operating system, paying particular attention to the possibility of blocking malicious...

avlab.pl

 

[MacDefender]

I have seen this method in the wild one year ago a few times (PyLocky). The malware used the legal installer application (InnoSetup) to install Python environment in a Temp folder and after the installation it ran python application (lockyfud.exe) wrapped into EXE by legal PyInstaller tool. By using two wrappers and Python scripting, such malware is hard to detect by proactive AV features.

Very interesting, thank you for this info! Always interesting that these aren’t unique ideas. It’s a clunky delivery mechanism but sneaking your own scripting environment onto the target system is very powerful and leads to so many secondary attacks. Same reason why PowerShell was so popular initially but with AMSI, now PowerShell is much harder to pull off.

 

[marcopaone]

Test bitdefender and avast premium if you can.

 

[blackice]

Another interesting POC. Glad you're on our side.

 

[MacDefender]

Added a few more results by @SeriousHoax. Working through some technical difficulties with @harlan4096 -- the ransomware samples are having difficulty deleting the source documents (likely some sort of weird Python interpretation of Windows permissions), but we do not think it's because the AVs are protecting

Thanks for all the suggestions for additional AVs to test -- I will try to get a chance to spin up some more VMs this afternoon!

 

[Gandalf_The_Grey]

Would Hard_Configurator at recommended settings stop your POC?

 

[SeriousHoax]

Would Hard_Configurator at recommended settings stop your POC?

A question for our @Andy Ful
One more question from me, as you can see from the first column of the table, it was blocked by the ASR rule "Use advanced protection against ransomware". What does this rule check/look for actually?

 

[Andy Ful]

Would Hard_Configurator at recommended settings stop your POC?

Yes. The user cannot run the EXE unless via SmartScreen (or after whitelisting). The bat will be blocked, unless the user will whitelist it.
If one has Python already installed in the system then adding PY, PYC, PYD, etc. (Python script extensions) to Designated File Types is required. These extensions are also included in the H_C Paranoid Extensions. The H_C settings could be bypassed if the attacker would exploit something and used the command-line with Python Interpreter to run the python script (except if ASR would block it).

A question for our @Andy Ful
One more question from me, as you can see from the first column of the table, it was blocked by the ASR rule "Use advanced protection against ransomware". What does this rule check/look for actually?

Use advanced protection against ransomware
This rule provides an extra layer of protection against ransomware. It scans executable files entering the system to determine whether they're trustworthy. If the files closely resemble ransomware, this rule blocks them from running, unless they're in a trusted list or an exclusion list.

Use attack surface reduction rules to prevent malware infection - Microsoft Defender for Endpoint

Attack surface reduction rules can help prevent exploits from using apps and scripts to infect devices with malware.

docs.microsoft.com

 

[MacDefender]

Yes. The user cannot run the EXE unless via SmartScreen (or after whitelisting). The bat will be blocked, unless the user will whitelist it.
If one has Python already installed in the system then adding PY, PYC, PYD, etc. (Python script extensions) to Designated File Types is required. These extensions are also included in the H_C Paranoid Extensions. The H_C settings could be bypassed if the attacker would exploit something and used the command-line with Python Interpreter to run the python script (except if ASR would block it).

If Python's already installed, there is potentially an attack where a rogue installer can drop a script into Python's site packages, or a system-wide Python library that's commonly imported, which would be executed the next time a user legitimately starts the Python interpreter. I've seen such techniques used for ransomware on UNIX environments like Linux and macOS, especially in terms of dropping things into .bashrc or another automatically sourced script that is owned by the user and runs frequently.

Unfortunately, on Windows, a lot of applications (especially scientific ones like MATLAB, AutoCAD, etc) and video games love to bundle a copy of a scripting engine or some other runtime environment, so it's really challenging to define a whitelist.

This is also a trend seen on macOS, where the latest version builds in a prompting feature similar to CFA which is on by default:

From a phishing standpoint, the goal is now to just lure the user to grant these kinds of privileges to something like Terminal (or Python, haha), and then that paves the way for ransomware to abuse those agents.

Use advanced protection against ransomware
This rule provides an extra layer of protection against ransomware. It scans executable files entering the system to determine whether they're trustworthy. If the files closely resemble ransomware, this rule blocks them from running, unless they're in a trusted list or an exclusion list.

Use attack surface reduction rules to prevent malware infection - Microsoft Defender for Endpoint

Attack surface reduction rules can help prevent exploits from using apps and scripts to infect devices with malware.

docs.microsoft.com

This is kind of interesting. I wonder which executable it thought was not trustworthy -- whether that's the self extracting EXE or detecting that it's executing python.exe with an argument to a script.

 

[Adrian Ścibor]

(heads up to @geminis3, @harlan4096, @SeriousHoax )
DISCLAIMER: This is a conceptual proof of concept, and is meant to test your behavior blocker's degree of whitelisting when a trusted binary is abused for evil purposes. This does not translate to whether or not your AV will detect real ransomware, which often has many other red flags. Do not place anything in My Documents\test\ that is valuable.

Interesting theory. Basically its required Python on victim PC what limits the number of potential victims, right? But the primary question is what protocol do you use to provide malware to machine with installed security solutions? Do you used drag-and-drop from host to guest?

Do you tried infect PC by compile Python scripts to EXE file?

 

[MacDefender]

Interesting theory. Basically its required Python on victim PC what limits the number of potential victims, right? But the primary question is what protocol do you use to provide malware to machine with installed security solutions? Do you used drag-and-drop from host to guest?

Do you tried infect PC by compile Python scripts to EXE file?

well not exactly, this attack brings along a copy of Portable Python and executes it with a 7Zip SFX action. This can be a Trojan installer or even just disguised as a fake copy of Python. For example the “bonus” test just launches a Python IDE that simply encrypts your data in the background. My goal was actually to not make an EXE that’s malicious itself because most behavior blockers in my previous tests are very effective at stopping malicious EXE behavior.

I actually downloaded the exploit via Edge to the VM. I am aware that many behavior blockers like DeepGuard take into consideration how the file is introduced into the VM. So I host my exploits from a Public folder of my OneDrive. It’s meant to simulate being tricked by someone into downloading something deceptive. You might believe it’s a Python IDE with a bunch of difficult to install scientific computing packages built in.... but in reality it’s ransomware.

 

[Andy Ful]

If Python's already installed, there is potentially an attack where a rogue installer can drop a script into Python's site packages, or a system-wide Python library that's commonly imported, which would be executed the next time a user legitimately starts the Python interpreter.
...

Still, a rouge installer will be blocked by forced SmartScreen, so it cannot drop anything. Of course, nothing is bullet-proof. But, I would not bother about the malware which could bypass SmartScreen. For now, this is the best file reputation service.
You have to exploit something to know that the target has installed Python and next use the payload (downloader) to download/drop malicious Python script. So it would be possible in theory but in most cases, the payload would not be downloaded because of FirewallHardening rules.
Anyway, the H_C Recommended Settings can build an extended ASR protection - they are not intended to lock down the computer completely. So, one can find a way to bypass these settings in a targetted attack.

 

[MacDefender]

Still, a rouge installer will be blocked by forced SmartScreen, so it cannot drop anything. Of course, nothing is bullet-proof. But, I would not bother about the malware which could bypass SmartScreen. For now, this is the best file reputation service.
You have to exploit something to know that the target has installed Python and next use the payload (downloader) to download/drop malicious Python script. So it would be possible in theory but in most cases, the payload would not be downloaded because of FirewallHardening rules.
Anyway, the H_C Recommended Settings can build an extended ASR protection - they are not intended to lock down the computer completely. So, one can find a way to bypass these settings in a targetted attack.

I generally agree that it's hard to package into a 1-click exploit because EXEs are so well protected via SmartScreen, but if you distribute these as ZIP files (like a "portable" app), that more or less bypasses SmartScreen for the default config. For example I started with a OneDrive ZIP file link in MS Edge Chromium and got this far extracting it with no warnings from either the browser or SmartScreen:

Double clicking IDLE.exe also didn't trigger any additional dialogs. The annoying thing about this kind of exploit is that every executable is 100% authentic, common, and signed (IDLE.exe is a signed stub that launches pythonw.exe, which is signed as well). But it's interpreting .py script files that are not signed at all, but beyond the scope of Windows SmartScreen and other signature verification mechanisms.


And BTW, the 100% legitimate portable Python implementation I used as the basis of this exploit is packaged this exact same way -- downloaded as a ZIP file, extracts to this directory structure, doesn't trigger SmartScreen.


This would primarily be a social engineering attack. You'd basically make a fake GitHub landing page that looks almost exactly like the real one and trick users into downloading this trojan horse Python bundle instead of the legitimate one. Unfortunately, data scientists frequently trade Python setups this way so I can also see it working in the real world


And FWIW, my versions of the exploit come with a copy of Python. It makes the exploit a disgusting 20-30MB which is impractical, but I could've picked something like Lua or even just bringing along a copy of BusyBox+MinGW which is a lot smaller and almost equally powerful.

 

[MacDefender]

Thank you very much for your efforts. I really like your tests. Could you please test more products like G Data for example?

GDATA IS did not react to any of the 3 samples. The antiransomware feature seems enabled by default, but I didn't change any other settings.

EDIT: Disclaimer here is I don't have any past experience with GDATA or what settings may help. I have heard lots of good things about GDATA but all I did here was install a trial, update it, reboot, and download/execute the samples. More than happy to share samples with other testers here.

 

[Andy Ful]

...
For example I started with a OneDrive ZIP file link in MS Edge Chromium and got this far extracting it with no warnings from either the browser or SmartScreen:

View attachment 238889

Double clicking IDLE.exe also didn't trigger any additional dialogs.

This will not work with the H_C.
After unpacking, the MOTW is usually not transferred to the unpacked files, so they are ignored by SmartScreen. That is why H_C uses Forced SmartScreen. With the H_C Recommended Settings if you click on the EXE, then it will be blocked by SRP. So, you have to use the right-click Explorer context menu entry "Install By SmartScreen". This will add the MOTW to the file and trigger a SmartScreen check.

 

[MacDefender]

This will not work with the H_C.
After unpacking, the MOTW is usually not transferred to the unpacked files, so they are ignored by SmartScreen. That is why H_C uses Forced SmartScreen. With the H_C Recommended Settings if you click on the EXE, then it will be blocked by SRP. So, you have to use the right-click Explorer context menu entry "Install By SmartScreen". This will add the MOTW to the file and trigger a SmartScreen check.

Understood, thanks for pointing this out. I indirectly was implying that if you force SmartScreen, you can get a SmartScreen dialog that tells you about attempting to execute what looks like (and is validly signed as) the official Python IDE IDLE, from an official Python distribution.

At that point, it really becomes a social engineering exercise. The dirty secret hidden in there is that there's around 20,000 .py scripts that make up a Python installation, all unsigned, and just 1 of them has been replaced with ransomware. SmartScreen isn't designed to find that, and I would argue that it's pretty futile to use static scanning to detect script-based malware.

Basically, if I were an attacker using this technique, I don't really focus on defeating H_C or TAM or another lockdown mechanism. My goal would be to fool the user into believing they want to run this program because they believe it's legitimate or safe. At that point, I think the last line of defense has to be a behavior blocker that, regardless of whether or not the user has instructed the system to run the program, still keeps an eye out for blatantly harmful actions by supposedly "trustworthy" or good reputation binaries that the user asked to be run.

For example, "Your Python IDE is registering a startup item and deleting/modifying My Documents, this isn't typical behavior for the Python IDE."

In an ideal world, it would trigger something that looks like Kaspersky System Watcher's "do you want to roll back its actions?" dialog. Except the crux of the issue here is that the bulk of the behavior blockers tested turn a blind eye to good-reputation processes as long as the user has said to allow it to run.


(The big hammer here has been CFA, and CFA-like features do work to stop this attack. However, as we've talked about before, CFA is so false positive prone that I don't think it's practical for a lot of users in practice. They will end up whitelisting something that could be potentially dangerous because it can be scripted, and then that defeats CFA)

 

[Andy Ful]

...
Basically, if I were an attacker using this technique, I don't really focus on defeating H_C or TAM or another lockdown mechanism. My goal would be to fool the user into believing they want to run this program because they believe it's legitimate or safe. At that point, I think the last line of defense has to be a behavior blocker that, regardless of whether or not the user has instructed the system to run the program, still keeps an eye out for blatantly harmful actions by supposedly "trustworthy" or good reputation binaries that the user asked to be run.

This would not also work for novice users, when the advanced user will set the H_C (ConfigureDefender) on their computers to prevent by policies bypassing SmartScreen alerts.
But, this will work for "smart" users who think that they know better than SmartScreen, what is safe. Anyway, most of such attacks can be prevented by waiting one or two days, if SmartScreen blocks something and we are pretty sure that it is safe. Other methods like using VirusTotal or on-demand scanners are not especially useful for 0-day malware.

At that point, I think the last line of defense has to be a behavior blocker that, regardless of whether or not the user has instructed the system to run the program, still keeps an eye out for blatantly harmful actions by supposedly "trustworthy" or good reputation binaries that the user asked to be run.

Behavioral blocking and other proactive solutions do not help much in such a case. This could work for inexperienced users, when an advanced user made the AV setup and they do not know how to bypass the protection. If the non-novice user is convinced that the program is safe, then he/she will simply ignore the alerts or will add the malware to AV exclusions.

 

[MacDefender]

If the non-novice user is convinced that the program is safe, then he/she will simply ignore the alerts or will add the malware to AV exclusions.

Very true! I've been guilty of that myself! Was trying to activate a copy of Windows in a VM using one of those KMS based activators, and I went out of my way to disable Windows Defender because I was sure it was a false positive. Wasn't until my firewall blocked an outbound attempt to contact a known bad IP that I started realizing that this was actually a trojan downloading a secondary payload. Got super lucky there that I had one final line of defense, because I was so determined to disagree with the on-device antimalware about how safe this EXE was.