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

Dec 6, 2014
61
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.


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.

true ! the first defense against malwares is user's behavior
 

SeriousHoax

Level 35
Verified
Mar 16, 2019
2,458
Hi @MacDefender, great thread.

Would you give me permission to share this on ESET's forums, see what they say and hopefully get an idea how to avoid similar (but real) scenarios? Of course I will give you credit for everything and link to this thread.
All they're gonna do is, this is not a real threat so we don't detect such threats, bla bla bla. I'm used to their excuses.
 

SeriousHoax

Level 35
Verified
Mar 16, 2019
2,458
Maybe he should send them a ‘fun’ e-mail. 😈
Kidding of course, I do not endorse any such behavior. But it would be nice to get their real take on a POC now and again.
I agree. But it has been like this always. They don't have a traditional behavior blocker so when someone share something like this they always tend to say similar things. This is what frustrates me. ESET is my preferred AV because of its lightness and having the best signature on the market but they fall short on the behavioral detection area and I'm yet to see any attempt from them to improve in this area.
 

The Ordynary

Level 2
Apr 26, 2020
96
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.
naively on your part, 99% of these activators are malicious, modify the registry, change the firewall, create services that connect, who knows where,
 

sepik

Level 11
Aug 21, 2018
521
Hello,
I used 10 random files (500 kb - 1mb in size).
Here's my quick test results:

GDATA AV:
Start.bat (files encrypted)
pyrate.exe (files encrypted)
idle.exe (files encrypted)

Sophos Home Premium:
Start.bat (4/10 files encrypted, then intercepted by Cryptoguard)
pyrate.exe (4/10 files encrypted, then intercepted by Cryptoguard)
idle.exe (4/10 files encrypted, then intercepted by Cryptoguard)

Mcafee IS:
Start.bat (files encrypted)
pyrate.exe (files encrypted)
idle.exe (files encrypted)

Kindest regards,
-sepik
 

MacDefender

Level 14
Verified
Oct 13, 2019
667
Hi @MacDefender, great thread.

Would you give me permission to share this on ESET's forums, see what they say and hopefully get an idea how to avoid similar (but real) scenarios? Of course I will give you credit for everything and link to this thread.
All they're gonna do is, this is not a real threat so we don't detect such threats, bla bla bla. I'm used to their excuses.


Thank you! You have my permission @Robbie and I would like them to know that I'm a paying ESET customer and think highly of their product, but at the same time, they basically have zero behavioral blocker style detections that have ever triggered in my tests or in any of the testing I've seen on MalwareHub ("dynamic" mostly means the network AV scanner caught something being downloaded via signatures, or a visit to a malicious URL)

I think we all know what they will say, but nonetheless, we should give them a chance to state their position.
 

MacDefender

Level 14
Verified
Oct 13, 2019
667
naively on your part, 99% of these activators are malicious, modify the registry, change the firewall, create services that connect, who knows where,
Yup that was a younger and dumber me!

I've made a number of posts here about it, but since then, my "specialty" has been analyzing greyware on P2P/Usenet. It is absolutely fascinating how it's a landmine of both "legitimate" pirated products and very very sneakily backdoored stuff.

I have a special Windows Server installer that I keep. It is almost legit but literally the backdoor is in the post-reboot environment where your AV would not be active, and they don't unpack it until then. Sneaky sneaky, would evade most AVs unless they were smart enough to fully scan a DVD-ROM.
 

RoboMan

Level 32
Verified
Content Creator
Jun 24, 2016
2,166
ESET's Marcos states the following:

1589009975129.png


After I read @MacDefender's aproval I sent him the download link over DM.

You can follow the thread on ESET's forums here: "pyrate", Behavior Blocker Bypass POC
 

fabiobr

Level 12
Verified
Mar 28, 2019
548
I've tested that looks at full execution trees and understands that Pyrate.exe started Python.exe and therefore Python.exe is not trustworthy.

@MacDefender you sure this is not Application Control? As I remember App Control has a setting that can opt to monitor the execution chain, default checked.

Edit:

Left: Do not inherit restrictions from the main process (application);
Right: Execution chain.
Kaspersky-Herdado.jpg
 
Last edited:

MacDefender

Level 14
Verified
Oct 13, 2019
667
@MacDefender you sure this is not Application Control? As I remember App Control has a setting that can opt to monitor the execution chain, default checked.

Edit:

Left: Do not inherit restrictions from the main process (application);
Right: Execution chain.
View attachment 239267
I am familiar with that setting but I do not believe it’s Application Control, as ultimately it was a PDM/Win32.Trojan.Gen detection which is typically KSW, and it flagged my source .exe as malicious and not Python. Unless Application Control trust groups somehow feed into KSW sensitivity?
 

MacDefender

Level 14
Verified
Oct 13, 2019
667
ESET's Marcos states the following:

View attachment 239257

After I read @MacDefender's aproval I sent him the download link over DM.

You can follow the thread on ESET's forums here: "pyrate", Behavior Blocker Bypass POC
I am curious what they will end up saying. As much as I am an ESET fan, I think they like to say “it’s not real malware” as a convenient excuse.

But if they add a static detection I am 99% confident that I could change my malicious script to avoid it — I was able to do that with my previous binary exploit and that is arguably harder:TrojanZipperPOC and ESET signatures Case Study
 

fabiobr

Level 12
Verified
Mar 28, 2019
548
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.
I did this a lot too, recently when downloading a program to recover data from HDD. That's one of the most reason I trust on a suite with good behavior blocker.
 

DDE_Server

Level 22
Verified
Sep 5, 2017
1,091
Thanks for your amazing efforts and analysis
Yup that was a younger and dumber me!

I've made a number of posts here about it, but since then, my "specialty" has been analyzing greyware on P2P/Usenet. It is absolutely fascinating how it's a landmine of both "legitimate" pirated products and very very sneakily backdoored stuff.

I have a special Windows Server installer that I keep. It is almost legit but literally the backdoor is in the post-reboot environment where your AV would not be active, and they don't unpack it until then. Sneaky sneaky, would evade most AVs unless they were smart enough to fully scan a DVD-ROM.
some antivirus has boot scanner which scan OS files during boot may one of then will be caught ??
 

MacDefender

Level 14
Verified
Oct 13, 2019
667
Thanks for your amazing efforts and analysis

some antivirus has boot scanner which scan OS files during boot may one of then will be caught ??

Yeah perhaps it would be caught, or enabling of Secure Boot would lead to the malware not executing. But the first reboot after running Windows Setup is into the WinPE installation environment. In there, no antivirus (Windows Defender or otherwise) is allowed to run. Maybe that environment refuses to run files not signed by Microsoft, but I don't think so (third party driver installers can be bundled into there). Either way, it's very risky and sneaky that the payload deployment was intentionally made to happen during a phase of Windows setup where AV isn't running.

It's just funny because I have always thought that scanning an external disk before execution is a waste of time since the realtime scanner is going to get around to it anyway. I guess this is one exception to that!
 

MacDefender

Level 14
Verified
Oct 13, 2019
667
ESET's Marcos states the following:

View attachment 239257

After I read @MacDefender's aproval I sent him the download link over DM.

You can follow the thread on ESET's forums here: "pyrate", Behavior Blocker Bypass POC

BTW regarding:
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.
Theoretically the "IDLE" exploit can be packaged as a ZIP file and that does not trigger smartscreen. Running IDLE.exe also does not trigger the default SmartScreen because IDLE is a digitally signed and safe reputation program.

I only packaged it as a 7z SFX EXE (which makes SmartScreen catch it) because it would be a 35MB zip file vs a 20MB 7z archive, and I didn't want to force all my testers here to get 7zip to unzip the exploit.

Python is actually often distributed as a self contained zip file, so unzipping and executing Python out of a downloaded archive is not necessarily far-fetched.

(but as Andy pointed out before, you can use the H_C config to force a SmartScreen popup to tell you about IDLE.exe regardless of it being signed. But that says nothing about the fact that I tainted a Python library buried deep within the archive....)
 
Top