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
Security
Malware Analysis
TrojanZipperPOC and ESET signatures Case Study
Message
<blockquote data-quote="MacDefender" data-source="post: 876972" data-attributes="member: 83059"><p>Yup that's exactly what I expect out of signature scanning. Whether it's ML or not, you can only tell so much from static inspection, which is why most enterprise and cloud products that claim to protect against APTs will use some sort of virtualization/sandbox-based detonation.</p><p></p><p>A behavior blocker can simply be thought as an extremely dangerous local version of that -- it's a local malware detonator that runs unprotected on your machine. If it identifies the suspicious behavior you're safe, if it doesn't, your host machine is compromised.</p><p></p><p>But at least when the malware detonates, there is very little you can do to hide the behavior. Like in your exploit, at some point you have to spawn 7z.exe with a -p and a -sdel argument. You can infinitely hide the code that spawns that, but by the time it turns into a Win32 API call you cannot hide it anymore. That's why I put so much value in a behavior blocker.</p></blockquote><p></p>
[QUOTE="MacDefender, post: 876972, member: 83059"] Yup that's exactly what I expect out of signature scanning. Whether it's ML or not, you can only tell so much from static inspection, which is why most enterprise and cloud products that claim to protect against APTs will use some sort of virtualization/sandbox-based detonation. A behavior blocker can simply be thought as an extremely dangerous local version of that -- it's a local malware detonator that runs unprotected on your machine. If it identifies the suspicious behavior you're safe, if it doesn't, your host machine is compromised. But at least when the malware detonates, there is very little you can do to hide the behavior. Like in your exploit, at some point you have to spawn 7z.exe with a -p and a -sdel argument. You can infinitely hide the code that spawns that, but by the time it turns into a Win32 API call you cannot hide it anymore. That's why I put so much value in a behavior blocker. [/QUOTE]
Insert quotes…
Verification
Post reply
Top