Closed GhostlyBox closed 1 year ago
Hey GhostlyBox, is it working correctly for the initial HTTP/HTTPS beacon? BokuLoader was designed for the original HTTP/S beacon. For injection or spawning I use BOFs. I have not tested all the other ways that CS uses the reflective loader aggressor hook and there's not much documentation on it for me to figure it out. Based on your response I will add info to the readme and look into seeing if there's a trivial way to integrate Bokuloader with pivot beacons or revert to the default CS loader. Thanks!
And the CS client bricking is the default behavior of CS if a Java exception happens in an aggressor script for any reason, unfortunately
Many thanks for your time and good to know. :-)
Yes, HTTP/S beacon works absolutely fine and as expected.
I also prefer BOF's in the real world, but the crash was puzzling me a little.
Hey so looking at it now at a computer I see the issue. So originally when I did PE modification with Aggressor scripting over a year ago I had it looping through all the imported DLLs to obfuscate the strings. Across different OS/platforms/CS versions this ended up being a coin flip stability wise. From there I hardcoded the obfuscation DLL's into the aggressor script for generating HTTP/S beacons. This is what's probably causing the crash. It looks like CS makes the SMB/TCP beacons on demand when doing inject or spawn commands. This was new info to me, but it makes allot of sense, but it throw me off a bit initially. I ended up just making payloads with SMB and TCP and its the same error. I haven't tried SMB or TCP beacon creations with BokuLoader since the new obfuscation/PE mod features.
So i think the issue is the HTTP/S beacons have 4 DLLs in the import table, but the SMB/TCP beacons only have 3 DLLs. So the aggressor script is trying to loop through a 4th DLL to obfuscate that does not exist, throwing the exception in CS.
Hey so I just tested and if obfuscate is set to false in the C2 profile then the SMB and TCP beacons work fine with BokuLoader
for TCP: ] ========== Running 'BEACON_RDLL_GENERATE' for DLL resources/pivot.x64.rl100k.dll with architecture x64 ========== at BokuLoader.cna:918 for SMB: [15:56:28] [!] ========== Running 'BEACON_RDLL_GENERATE' for DLL resources/pivot.x64.rl100k.dll with architecture x64 ========== at BokuLoader.cna:918 for HTTP/S: [15:57:14] [!] ========== Running 'BEACON_RDLL_GENERATE' for DLL resources/beacon.x64.rl100k.dll with architecture x64 ========== at BokuLoader.cna:918
So looks like i'll be able to tell if its SMB/TCP or HTTP/S by that first arg in BEACON_RDLL_GENERATE aggressor hook.
I'll look into checking that arg first before calling the obfuscate function in the aggressor script and see if I can trivially mod it to just do the 3 imports if its SMB/TCP.
Hey so I relabeled it "Support obfuscate "true" for SMB/TCP pivot beacons". It wasn't my original intention for the project, but I think I can make it happen pretty easy. I'll look into making the changes and testing it out when I get some time. Feel free to take a shot at getting obfuscation to work with the pivot beacons. If you get it to work submit a pull request. After testing it out with the different malleable C2 options i'll merge it :)
Ah, awesome. Many thanks for taking a look dude! I'll try and find some time to add that logic and send a pull request this week.
Just confirming that a few changes and yes, working absolutely fine with pivot beacons:
100% confession.. I've gone easy mode to start, duplicated functions and depending if $1
passed to generate_my_dll
matches resources/beacon.x64.rl100k.dll
, the original functions are used, else some alternative functions are called where any attempt to obfuscate WININET.dll
in the import table are striped... I'm gonna have a play to see if I can work out how to get aggressor dealing with imports that don't exist.
Awesome news, glad you got it working!
I pushed a change to the CNA script, it should fix it so it works with pivot beacons. I tested the DLL mod stomp and mapview allocators with smb + tcp + https beacons. There was some strange behavior when creating HTTPS beacons after creating pivot beacons where CS would only find 1 of the 4 DLLs randomly when trying to XOR.
I made sure to zero out variables, and I put an extra check in there to prevent the bad beacon creation. Seems to not be an issue anymore, but still needs some testing.
I also tested with spawn x64 and inject x64, both worked!
Also made sure to check for x86 and fail gracefully.
Thanks for the heads up, going to close this issue out for now. Let me know if you find any other issues, it's really helpful. Trying to test all the possible combinations of C2 malleable pe options is not trivial! haha
Not a problem. Thank you very much for the assistance! 😁
Not sure if it is just me... but when trying to
inject
orspawn
pivot beacon (SMB or TCP), the CS client crashes whenBokuLoader.cna
is loaded on Windows? Like full on freeze and have to killjavaw.exe
to continue...Has anyone else experienced this?