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
Inactive Support Threads
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
Software
Security Apps
ESET
Eset 13.0.22.0 Final
Message
<blockquote data-quote="MacDefender" data-source="post: 861445" data-attributes="member: 83059"><p>It is only meant as a test of one component of overall bad behavior. Fundamentally ransom behavior is difficult to distinguish from something that password protects user documents on their command. It is really hard to distinguish the difference of whether or not the user consented to this action from the perspective of AV software.</p><p></p><p>This test, as I explained in my original post, was inspired by a real piece of ransomware that defeated multiple AV software. The only difference between what it did and what mine does is just the lack of calling back to a control center for key escrow. It did not have any other attack vector other than it was a double extension file masquerading as a PDF, delivered via email phishing.</p><p></p><p>I do agree that most ransomware exhibits other behaviors which makes it easy to detect but at that point it's not at all clear what specific behavior is triggering detections.</p><p></p><p>And to your point about whether or not you expect homebrew ransomware to trigger detections, my first test on this forum did the exact same thing except it used a built in .NET API to encrypt files and every AV software except ESET detected and blocked it, and Kaspersky went as far as to capture a sample of it automatically and add it as malicious in its signatures.</p><p></p><p>The difference here, as several AV vendors have responded regarding this sample, is that the act of using 7zip to do the dirty work is harder to block without false positives and that makes it not worth attempting to detect, which I agree with. In fact, if I had 7zip encrypt the documents and instead of having it delete them, I deleted them through my exploit binary, more behavior blockers start flagging it as malware.</p><p></p><p>Bottom line is, I'm not saying that AV software not responding to these proof of concept exploits are not doing a good job. These tests are simply meant to look into specific ways software responds to attacks extremely similar to what I have seen in the wild.</p><p></p><p></p><p>P.S. By the way, Norton and Emsisoft and others have balked at a few other behaviors in under 50 lines of code. For example, I isolated a piece of code from Rufus that asks for UAC elevation and then uses group policy objects to disable AutoRun for removable drivws, which is just close enough to the same CLSID group as disabling Windows Defender. That triggers a lot of behavior blockers. Norton in particular will complain about 5 lines of code for a binary to copy itself and then register the copy as an AutoRun key if it's being done by a zero reputation binary. So actually there are many cases where a seemingly simple snippet of a larger complex of suspicious behaviors will trigger AV software. Whether that's correct or not, I totally agree is up for debate.</p></blockquote><p></p>
[QUOTE="MacDefender, post: 861445, member: 83059"] It is only meant as a test of one component of overall bad behavior. Fundamentally ransom behavior is difficult to distinguish from something that password protects user documents on their command. It is really hard to distinguish the difference of whether or not the user consented to this action from the perspective of AV software. This test, as I explained in my original post, was inspired by a real piece of ransomware that defeated multiple AV software. The only difference between what it did and what mine does is just the lack of calling back to a control center for key escrow. It did not have any other attack vector other than it was a double extension file masquerading as a PDF, delivered via email phishing. I do agree that most ransomware exhibits other behaviors which makes it easy to detect but at that point it's not at all clear what specific behavior is triggering detections. And to your point about whether or not you expect homebrew ransomware to trigger detections, my first test on this forum did the exact same thing except it used a built in .NET API to encrypt files and every AV software except ESET detected and blocked it, and Kaspersky went as far as to capture a sample of it automatically and add it as malicious in its signatures. The difference here, as several AV vendors have responded regarding this sample, is that the act of using 7zip to do the dirty work is harder to block without false positives and that makes it not worth attempting to detect, which I agree with. In fact, if I had 7zip encrypt the documents and instead of having it delete them, I deleted them through my exploit binary, more behavior blockers start flagging it as malware. Bottom line is, I'm not saying that AV software not responding to these proof of concept exploits are not doing a good job. These tests are simply meant to look into specific ways software responds to attacks extremely similar to what I have seen in the wild. P.S. By the way, Norton and Emsisoft and others have balked at a few other behaviors in under 50 lines of code. For example, I isolated a piece of code from Rufus that asks for UAC elevation and then uses group policy objects to disable AutoRun for removable drivws, which is just close enough to the same CLSID group as disabling Windows Defender. That triggers a lot of behavior blockers. Norton in particular will complain about 5 lines of code for a binary to copy itself and then register the copy as an AutoRun key if it's being done by a zero reputation binary. So actually there are many cases where a seemingly simple snippet of a larger complex of suspicious behaviors will trigger AV software. Whether that's correct or not, I totally agree is up for debate. [/QUOTE]
Insert quotes…
Verification
Post reply
Top
