Red Failure

Description

During a recent red team engagement one of our servers got compromised. Upon completion the red team should have deleted any malicious artifact or persistence mechanism used throughout the project. However, our engineers have found numerous of them left behind. It is therefore believed that there are more such mechanisms still active. Can you spot any, by investigating this network capture?

Solution

Red_Failure.png

There's quite a lot of traffic on HTTP, we can filter for it via http

Red_Failure-1.png

We have few files too -> File > Export Objects > HTTP

After some cleanup:

After downloading the malicious user32.dll it's loaded into memory and some method called Boom is invoked...

Because DLL is written in C# it's easy to decompile it, such as ILSpy or https://www.decompiler.com/jar/287f06e3716e4208967b58de9b12b5ce/user32.dllarrow-up-right

Red_Failure-2.png

This is the main line that's being processed. Boom method has a command line parser so all of the /arg's are passed as arguments to function.

/sc is the source from where the payload encoded in Base64 is downloaded from, but it's also AES encrypted. The password for decryption exists in program, after it's decoded it's passed to functions that are able to do Execute with decoded arguments.

But the AES decryption is somewhat ~custom

I verified the decrypted few times and it should be correct, but we are getting this weird blob of data

Red_Failure-3.png

DInjectorarrow-up-right: Collection of shellcode injection techniques packed in a D/Invoke weaponized DLL

rvrsh3ll/DInjector/DInjector/Modules/CurrentThreadarrow-up-right

Red_Failure-4.png

The Execute method is taking shellcode and that's why it's not plaintext commands.

I was trying to somehow debug the shellcode on Linux, but no luck.

In HTB Sherlocks chat BlobRunnerarrow-up-right or shcode2exearrow-up-right was recommended. shcode2exe is Python script and it was able convert the code to exe binary (on Linux), static analysis with Ghidra was hell tho... It was also recommended to use xdbgarrow-up-right if we converted code via shcode2exearrow-up-right.

I tried running shellcode with BlobRunner, attaching xdbg to process, going to thread and doing step manually, but shellcode wasn't working. Kept crashing and crashing 🥴

Then I tried SHAREMarrow-up-right, which is a shellcode analysis framework, capable of emulating more than 20,000 WinAPIs and virtually all Windows syscalls. (Use -m32 flag to run shellcode) But it was also crashing, well looping back to same point where crash was happening. Same with IDA 🥴

Something like ltrace or strace would be nice to have, where we can observe the calls that binary made.

scdbgarrow-up-right is a shellcode analysis application built around the libemu emulationarrow-up-right library. When run it will display to the user all of the Windows API the shellcode attempts to call.

circle-check

https://vincentandreas.medium.com/red-failure-forensic-hackthebox-writeup-cd1731eb7395arrow-up-righthttps://apchavan.medium.com/shellcode-challenges-from-malwaretech-24bab3f1ce22arrow-up-righthttps://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20presentations/Dr.%20Bramwell%20Brizendine%20Max%20Libra%20Kersten%20Jake%20Hince%20-%20Game-Changing%20Advances%20in%20Windows%20Shellcode%20Analysis.pdfarrow-up-righthttps://github.com/Bw3ll/sharemarrow-up-right

Last updated