![]() It’s a very lazy way to do it, but it works and is very effective against very specific versions of malware. If you hard-coded a very specific encryption and decryption algorithm, it is highly likely that they would be able to obtain a very low false positive rate simply by flagging that specific encryption and decryption routine as your stub’s ‘signature’. I could be wrong, but this part is definitely more of an art than a science. By using standard API calls without doing anything custom, a rule against this crypter would have to rely on flagging ordinary API calls which may cause a problematic amount of false positives and is someting analysts seem to attempt to avoid based on my research. They pick out byte sequences or strings in a file and make rules that combined give a good indication that a file is a specific type of malware. I choose this approach over others because one of the primary ways antiviruses detect malware is through static rules. TransformFinalBlock ( $payload, 16, $payload. IV = $payload $memstream = New-Object System. NET functions, and it so happens AES can be very easily decrypted like so: It uses AES, but the reason I chose that is not because AES is better cryptographically than the alternatives, I use it because PowerShell provides a very simple way to call. Take for instance my PowerShell crypter Xencrypt. They’re both relatively simple questions, but the devil is in the details.
0 Comments
Leave a Reply. |