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="Hexspeak" data-source="post: 877312" data-attributes="member: 87292"><p>ESET's detection is likely to be based on the combination of API calls and their arguments. Also it will account for other features (strings and other metadata), as stated in its tech whitepaper. This seems to be a standard method most relatively robust detection engines will implement (but the underlying feature representation and pattern match algorithm will vary). My past experience is that it rarely use strings as the unique identifier and in some cases changing strings does not help at all, which makes sense since strings are "weak" features.</p><p></p><p>To avoid detection, one can change meta features (strings, compiler features, etc.), and can also further replace existing syscalls with their equivalents & obfuscate the parameters, or even rewrite some key routines. My past experiment on this yields somewhat interesting results: by replacing different APIs with their equivalents in a detected ransomware, the detection name will also change accordingly (e.g. from Filecoder.A to Filecoder.AB, and then to Filecoder.CD...). This is a strong indicator that what I have tried have been explored by other people and a good heuristic algorithm caught my "zero-day" sample as long as it is in its known realm.</p><p></p><p>Of course eventually I managed to produce a sample to avoid the client-side detection. However my personal view on this is that the real malware industry won't do this. For people who sell malware as a service, changing the source code is too expensive and can hardly be automated. Imagine that you spend hours in changing the code to avoid detection, and the cloud blacklist and generate signatures within minutes (note that the client side may flag a sample as benign, but the cloud counterpart may not, because it has better emulation engine, better sandbox, and better AI models, this is a common practice among AV vendors to avoid/delay adversarial trial-and-errors). Thus what the malware authors are likely to do is to obfuscate the existing code with different techniques as much as possible, and will only change the source code every several weeks for example, when existing techniques have been exhaustively "handled" by the majority of vendors. That's why some past reports shows periodic detection rate dip for a certain malware family.</p><p></p><p>As a side note, it seems that ESET's BB is mainly targeting big families. Thus a hoax program definitely won't catch its attention. This has the advantage of extremely low false positive, and in the realworld case, this is also effective from a probability's standpoint. Many other "strong" BB more or less suffer from FPs in my past testings. Some vendors rely on whitelisting, but it won't help in a corporate environment or more complex situations. For example, many remote desktop apps provides package customization to enterprise users, and AVs may produce FPs. This cannot be effectively whitelisted because it is company specific. Perhaps that's why in AV-C's most recent FP tests, some even flag popular packages such as Teamviewer as malicious.</p></blockquote><p></p>
[QUOTE="Hexspeak, post: 877312, member: 87292"] ESET's detection is likely to be based on the combination of API calls and their arguments. Also it will account for other features (strings and other metadata), as stated in its tech whitepaper. This seems to be a standard method most relatively robust detection engines will implement (but the underlying feature representation and pattern match algorithm will vary). My past experience is that it rarely use strings as the unique identifier and in some cases changing strings does not help at all, which makes sense since strings are "weak" features. To avoid detection, one can change meta features (strings, compiler features, etc.), and can also further replace existing syscalls with their equivalents & obfuscate the parameters, or even rewrite some key routines. My past experiment on this yields somewhat interesting results: by replacing different APIs with their equivalents in a detected ransomware, the detection name will also change accordingly (e.g. from Filecoder.A to Filecoder.AB, and then to Filecoder.CD...). This is a strong indicator that what I have tried have been explored by other people and a good heuristic algorithm caught my "zero-day" sample as long as it is in its known realm. Of course eventually I managed to produce a sample to avoid the client-side detection. However my personal view on this is that the real malware industry won't do this. For people who sell malware as a service, changing the source code is too expensive and can hardly be automated. Imagine that you spend hours in changing the code to avoid detection, and the cloud blacklist and generate signatures within minutes (note that the client side may flag a sample as benign, but the cloud counterpart may not, because it has better emulation engine, better sandbox, and better AI models, this is a common practice among AV vendors to avoid/delay adversarial trial-and-errors). Thus what the malware authors are likely to do is to obfuscate the existing code with different techniques as much as possible, and will only change the source code every several weeks for example, when existing techniques have been exhaustively "handled" by the majority of vendors. That's why some past reports shows periodic detection rate dip for a certain malware family. As a side note, it seems that ESET's BB is mainly targeting big families. Thus a hoax program definitely won't catch its attention. This has the advantage of extremely low false positive, and in the realworld case, this is also effective from a probability's standpoint. Many other "strong" BB more or less suffer from FPs in my past testings. Some vendors rely on whitelisting, but it won't help in a corporate environment or more complex situations. For example, many remote desktop apps provides package customization to enterprise users, and AVs may produce FPs. This cannot be effectively whitelisted because it is company specific. Perhaps that's why in AV-C's most recent FP tests, some even flag popular packages such as Teamviewer as malicious. [/QUOTE]
Insert quotes…
Verification
Post reply
Top
