REW-sploit is a tool to Emulate And Dissect MSF And Other Attacks. Need help in analyzing Windows shellcode or attack coming from Metasploit Framework or Cobalt Strike (or may be also other malicious or obfuscated code)? Do you need to automate tasks with simple scripting? Do you want help to decrypt MSF generated traffic by extracting keys from payloads?
REW-sploit is here to help Blue Teams!
Install
Installation is very easy. I strongly suggest to create a specific Python Env for it:
#python -m venv /rew-sploit
#source /bin/activate
#git clone https://github.com/REW-sploit/REW-sploit.git
#cd REW-sploit
#pip install -r requirements.txt
#./apply_patch.py -f
#./rew-sploit
If you prefer, you can use the Dockerfile. To create the image:
docker build -t rew-sploit/rew-sploit .
and then start it (sharing the /tmp/ folder):
docker run –rm -it –name rew-sploit -v /tmp:/tmp rew-sploit/rew-sploit
You see an apply_patch.py script in the installation sequence. This is required to apply a small patch to the speakeasy-emulator (https://github.com/fireeye/speakeasy/) to make it compatible with REW-sploit. You can easily revert the patch with ./apply_patch.py -r if required.
Optionally, you can also install Cobalt-Strike Parser:
#cd REW-sploit/extras
#git clone https://github.com/Sentinel-One/CobaltStrikeParser.git
Standing on the shoulder of giants
REW-sploit is based on a couple of great frameworks, Unicorn and speakeasy-emulator (but also other libraries). Thanks to everyone and thanks to the OSS movement!
In general we can say that whilst Red Teams have a lot of tools helping them in “automating” attacks, Blue Teams are a bit “tool-less”. So, what I thought is to build something to help Blue Team Analysis.
REW-sploit can get a shellcode/DLL/EXE, emulate the execution, and give you a set of information to help you in understanding what is going on. Example of extracted information are:
- API calls
- Encryption keys used by MSF payloads
- decrypted 2nd stage coming from MSF
- Cobalt-Strike configurations (if CobaltStrike parser is installed)
You can find several examples on the current capabilities here below:
- RC4 Keys Extraction
- RC4 Keys Extraction + PCAP 2nd stage decryption
- ChaCha Keys Extraction
- Meterpreter session Decryption (no RSA)
- Cobalt-Strike beacon Emulation
- Cobalt-Strike config Extraction
- Debugging options
- Dumping Threads
You know for sure the Donut package, able to create PIC from EXE, DLL, VBScript and JScript.
Donut, in order to evade detection, uses a API exports enumeration based on hashes computed on every API name, as many PIC do. This is very CPU intensive (especially in an emulated environment like REW-sploit). So, knowing which are the API needed by Donut stub (you can get them in donut.c), I implemented a shortcut to avoid the hash computation if the API is not is the used list. This makes the emulation a lot faster (even if it takes some minutes).
Also, in order to be able to correctly complete the emulation, you need to give to Speakeasy the DLL to get the complete exports. To do it copy the following DLLs
kernel32.dll
mscoree.dll
ole32.dll
oleaut32.dll
wininet.dll
in the Speakeasy folder winenv/decoys/amd64 and/or winenv/decoys/x86 (see Speakeasy README for details). If you don’t need them, don’t leave the DLLs there, since they slow down the emulation.
In some cases emulation was simply breaking, for different reasons. In some cases obfuscation was using some techniques that was confusing the emulation engine. So I implemented some ad-hoc fixups (you can enable them by using -F option of the emulate_payload command). Fixups are implemented in modules/emulate_fixups.py. Currently we have
Unicorn issue #1092:
Fixup #1
Unicorn issue #1092 (XOR instruction executed twice)
https://github.com/unicorn-engine/unicorn/issues/1092
#820 (Incorrect memory view after running self-modifying code)
https://github.com/unicorn-engine/unicorn/issues/820
Issue: self modfying code in the same Translated Block (16 bytes?)
Yes, I know…this is a huge kludge… :-/
FPU emulation issue:
Fixup #2
The “fpu” related instructions (FPU/FNSTENV), used to recover EIP, sometimes
returns the wrong addresses.
In this case, I need to track the first FPU instruction and then place
its address in STACK when FNSTENV is called
Trap Flag evasion:
#Fixup #3
#Trap Flag evasion technique
#https://unit42.paloaltonetworks.com/single-bit-trap-flag-intel-cpu/
#The call of the RDTSC with the trap flag enabled, cause an unhandled
#interrupt. Example code:
#pushf
#or dword [esp], 0x100
#popf
#rdtsc
#Any call to RDTSC with Trap Flag set will be intercepted and TF will
#be cleared
Customize YARA rules
File modules/emulate_rules.py contains the YARA rules used to intercept the interesting part of the code, in order to implement instrumentation. I tried to comment as much as possible these sections in order to let you create your own rule (please share them with a pull request if you think they can help others). For example:
Payload Name: [MSF] windows/meterpreter/reverse_tcp_rc4
Search for : mov esi,dword ptr [esi]
xor esi,0x
Used for : this xor instruction contains the constant used to
encrypt the lenght of the payload that will be sent as 2nd
stage
Architecture: x32
yara_reverse_tcp_rc4_xor_32 = ‘rule reverse_tcp_rc4_xor { \
strings: \
$opcodes_1 = { 8b 36 \
81 f6 ?? ?? ?? ?? } \
condition: \
$opcodes_1 }’
