Reply to thread

Message

<blockquote data-quote="Hexspeak" data-source="post: 877323" data-attributes="member: 87292">From VT&#039;s statistics, this seems to be a fairly new signature. I am wondering if you could PM me the original sample and the one that avoids the detection?Sometimes I indeed found some signature are not strong, and even &quot;dumb&quot;. Seems to be heavily dependent on the malware prevalenceUpdate:alright I think I&#039;ve got the sample[ATTACH=full]238260[/ATTACH][ATTACH=full]238261[/ATTACH]After a glance through the PE, I assume the key string features of this sample are these four parts: encryption extension list, hardcoded encryption path, zip routine, and ransomnote. Changing the extension list may compromise the feature, changing the note may be better. Randomly changing things above will still trigger the detection. While changing a combo of those can avoid the detection, the sample is in a nasty situation already.Of course one can locate the key char that may significantly lower the scoring and avoid the detection upon deletion, or use basic method to concat the string or xor the string. But again, this requires some manual efforts. When manual efforts are involved, all bets are off (at least on the client side). The key here is when the mutated sample gets prevalent again, the detection signature will again be modified to be more robust. Thus I assume it is harder to avoid the detection using such evasion technique on more popular families. In addition, a production ransomware will have more features to be extracted including VSS deletion, key exchange, etc. Once there are more functionalities involved, simply changing a string or an API call won&#039;t do the trick.I remembered my past experiments with a more popular ransomware required me to change 4~5 key strings/functions combos to eventually avoid the client-side detection. I guess applying a packer is more cost-efficient in this case....</blockquote>

[QUOTE="Hexspeak, post: 877323, member: 87292"] From VT's statistics, this seems to be a fairly new signature. I am wondering if you could PM me the original sample and the one that avoids the detection? Sometimes I indeed found some signature are not strong, and even "dumb". Seems to be heavily dependent on the malware prevalence Update: alright I think I've got the sample [ATTACH type="full" alt="hex.jpg"]238260[/ATTACH] [ATTACH type="full" alt="hex2.jpg"]238261[/ATTACH] After a glance through the PE, I assume the key string features of this sample are these four parts: encryption extension list, hardcoded encryption path, zip routine, and ransomnote. Changing the extension list may compromise the feature, changing the note may be better. Randomly changing things above will still trigger the detection. While changing a combo of those can avoid the detection, the sample is in a nasty situation already. Of course one can locate the key char that may significantly lower the scoring and avoid the detection upon deletion, or use basic method to concat the string or xor the string. But again, this requires some manual efforts. When manual efforts are involved, all bets are off (at least on the client side). The key here is when the mutated sample gets prevalent again, the detection signature will again be modified to be more robust. Thus I assume it is harder to avoid the detection using such evasion technique on more popular families. In addition, a production ransomware will have more features to be extracted including VSS deletion, key exchange, etc. Once there are more functionalities involved, simply changing a string or an API call won't do the trick. I remembered my past experiments with a more popular ransomware required me to change 4~5 key strings/functions combos to eventually avoid the client-side detection. I guess applying a packer is more cost-efficient in this case.... [/QUOTE]

Verification