execute-assembly should allow unlimited timeout / backgrounding

[realalexandergeorgiev]

Is your feature request related to a problem? Please describe. The current SOCKS implementation isnt great, so I switched to use another one. I run it using execute-assembly, but since it is a background task it runs all the time. I need to set ridiculous high timeouts and have a 2nd beacon running for that.

Describe the solution you'd like Would be nice to be able to disable timeout on execute-assembly and keep the new process running in the background without affecting the UI of the beacon.

Describe alternatives you've considered Running a second beacon in multiplayer mode.

[rkervella]

I've introduced --keep-alive for this kind of things in sideload and spawndll a while back (prevents the implant to kill the subprocess we inject into), we could probably do the same for execute assembly. This won't solve the UX issue were you get a "Error: timeout expired" message in the client console, but at least you'll have a long running process.

As a workaround, if all you need is a more stable proxy, you can also sideload chisel.

[realalexandergeorgiev]

thank you! i didnt know that one can sideload chisel. i had issues converting its EXE to shellcode (using donut) and stopped trying. (and btw i stopped trying to run shellcode from sliver - it crashes my implants too often)

my current stable workaround is a c# based reflective PE loader, which once run keeps running in the background, even if the UX hangs/rans into timeout

[rkervella]

Chisel needs to be built with -buildmode=pie for it to work with Donut. I believe it's the default on modern Go versions, but I'm not sure.

[realalexandergeorgiev]

i read that in the donut issues, yes (link) and i think it even complains if no reloc information is found ("This file has no relocation information required for in-memory execution").

its getting a bit OT, but maybe for the sake of helping the community: so, i tried building a DLL using go without the pie flag and using it and received two different files (same size, different hash). i then tried building a DLL using garble and received the exact same file (size and hash).

finally i tried running the chisel-x64.dll compiled with go using pie using sideload and my implant crashed :disappointed:
edit: got curious and tried it in my lab with Win10 and same command and DLL worked fine. hm.

[rkervella]

You don't need to use a DLL. sideload supports PE executable out of the box. I should update the help string.

finally i tried running the chisel-x64.dll compiled with go using pie using sideload and my implant crashed 😞

The implant should not crash, as it's running the PE in another process (notepad by default). A crash might indicate it got killed by a security product. I know the default builds of Chisel are flagged as malware nowadays so that might be why.

[realalexandergeorgiev]

is the cryptic stack trace of use?

[rkervella]

Not without more details about:

• how you generated the implant
• how you ran the implant
• what command you ran on the client that resulted to this

Also, a stack trace from an implant built with --debug would be more helpful, as we don't obfuscate function names in debug mode.

[realalexandergeorgiev]

• generate -f shellcode -e -b https://...
• custom .NET stager that fetches the shellcode and runs it in memory
• sideload /tmp/chisel-x64_fud.exe

i need to try if AV/EDR will trigger on --debug. may take until next week..