Flare-On 7 2020 Challenge #7: re_crowd

We received a capture network file named: re_crowd.pcapng.

Notice that there are number of records with PROPFIND:

I follow the TCP stream of this requests:

I didn’t understand what it is, I thought in the beginning that this is some base64 encoding but it doesn’t. I decided to search for “Not <locktoken:Write1>” and it seems that it is related to CVE-2017–7269:

According to MITRE this a vulnerability in WebDAV:

Buffer overflow in the ScStoragePathFromUrl function in the WebDAV service in Internet Information Services (IIS) 6.0 in Microsoft Windows Server 2003 R2 allows remote attackers to execute arbitrary code via a long header beginning with “If: <http://” in a PROPFIND request, as exploited in the wild in July or August 2016.

After searching for exploits for this vulnerability we see that this is almost exactly like the encoded string from the PCAP.

There are number of websites that analyze this shellcode but the best one was this website. It explained that the beginning of the shellcode is actually a decoder stub:

And provided a decoder function which I changed a bit:

I run it and received the decoded shellcode:

The only interesting thing we can see is some word killervulture123 but we still don’t have a clue what is the reason of it:

I used online disassembly to view the shellcode and in the beginning some part of it had some constants like:

After searching for specific constants (i.e. 0x726774c) I noticed that these are hashes of function names. For example, I notice that this shellcode was very similar to the block_reverse_tcp.asm shellcode from MetaSploit and it contained lots of notes which help me to analyze it.

At this point I knew what the shellcode do. It opens TCP socket on and port 4444and try to connect it.

I needed that my machine will have the and listen on 4444. One way to achieve it was to change my machine IP to this IP but there is another way — change the shellcode. All I need to do to change it to my local host is to change 0x1544a8c0 ; to 0x0100007F ; (to find the hex value of local host you can use this website).

I started IO Ninja TCP Listener Socket to listen on port 4444.

I used BlobRunner to run the shellcode through x32dbg:

After running it BlobRuner will show you the memory location of the shllecode:

Jump to this address, set breakpoint and press Enter and it will jump to the shellcode. We can see that it successfully connected to our localhost on port 4444:

Shellcode connect to our localhost on port 4444

But after that there were to ws2_32.dll!recv calls waiting for some input.

I went back to WireShark and searched for a place where there was a connection to 4444 and found something:

When I looked on the message sent from to, I saw block of data:

But if it sent it one time, why there are two calls of ws2_32.dll!recv?

It turns out that it split the message to two parts. The first is is 4 bytes (push 4) which is the 4 bytes from the beginning of the message 9c 5c 4f 52 and the second part is the rest of the message (push esi while it in size 0x4D7) :

I sent the first message with IO Ninja (notice it should be “Binary”):

And second message (size 0x4D7) after the first one received:

I also noticed that they did this decoded with the string we saw earlier: killervulture123

After I passed the two recv functions I continued to step over to see where it goes. The code started to unpack the large message we sent, to Windows libraries names and functions.

At some point it wants to open the file c:\accounts.txt:

I created the file that it will be able to continue and then it tried to read 0x100 (256) bytes from the file:

Notice the intrepidmango string, we will get to this later.

After that there was a call to ws2_32.WSAStartup:

I checked what is inside the call call 9B040E and I found that it leads to connect to TCP on and port 1337 which make sense because we saw that after the connection to port 4444 it connected to 1337:

Notice that to resolve the port, you can do it simply with Python:

So, this time I again needed to change the hostname to and open TCP listener on port 1337.

Because I needed to do number of tests, I also needed to get to this dynamically call to connect so I set breakpoint on the second call (after the call to the function 0x142- last function in the shellcode) to ws2_32.WSAStartup and set breakpoint on the first address on the stuck, the return address stuck.

I saw that the IP address (0x1544A8C0 = is in eax:

I changed eax to 0x010007F =

But after that it didn’t print anything.

What we know so far:

  1. The shellcode listen on port 4444 and waits for encoded second-stage shellcode.
  2. The second-stage shellcode is being sent with two parts: size and data.
  3. The second-stage shellcode is decoded using killervulture123 string.
  4. The second-shellcode is trying to open c:\accounts.txt and it tries to read 0x100 (256) bytes from there.
  5. After it reads the content from c:\accounts.txt, it calls to two functions that are doing some decoding with the string intrepidmango and listen to 1337. It then send it to the attacker.

In the last part of the communication on port 1337 the server send to the attacker the following data:

This is what should be sent after reading some unknown content from c:\accounts.txt and doing some decoding stuff on it. To reproduce it, I thought to do something similar we did in challenge 6.

I filled the c:\accounts.txt with NULL bytes in size of 0xCE, create Python script for automation and changed the computer name to

We received the following data:

I thought to XOR it with the data from WireShark:

After XORing I received the decoded data:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Eviatar Gerzi

Eviatar Gerzi

Security researcher interested in reversing, solving CTFs, malware analysis, penetration testing and DevOps security (docker and Kubernetes)