Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
Malware Analysis
"pyrate", Behavior Blocker Bypass POC #3
Message
<blockquote data-quote="MacDefender" data-source="post: 879979" data-attributes="member: 83059"><p>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.</p><p></p><p>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. </p><p></p><p>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 <strong>want</strong> 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.</p><p></p><p>For example, "Your Python IDE is registering a startup item and deleting/modifying My Documents, this isn't typical behavior for the Python IDE."</p><p></p><p>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.</p><p></p><p></p><p>(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)</p></blockquote><p></p>
[QUOTE="MacDefender, post: 879979, member: 83059"] 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 [B]want[/B][I] [/I]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) [/QUOTE]
Insert quotes…
Verification
Post reply
Top