Next step is deciding how we’re going to execute. One way to get around this limitation is by dynamically generating encryption and decryption algorithms or at the very least changing it by hand frequently, but that’s out of the scope for this article.įor the sake of moving on let’s say you’ve decided to go with AES like my crypter does. 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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |