Kaspersky Writeup - EKOPARTY CTF 2023

 I was given a ZIP file named kaspersky.zip, and the password ekoparty.

I extracted the ZIP file to find a file named attacker_traffic.pcapng, a PCAP file containing captured network traffic.

I analyzed the PCAP file with Wireshark, and by using the !tls && tcp.port != 443  filter I was able to narrow down the packets I had to analyze, filtering out all SSL traffic, as I didn't have a private key to decrypt it.

Then, I came across this:

This is a quite intriquing piece of data, so I decided to analyze it further.

I followed the TCP stream, and saw this:


I copied all the red data (client response) in hexadecimal (raw) format, and pasted it to CyberChef. Then I used From Hex and converted the data back to plain text. While looking at all this mess, I had the idea to use XOR, and that's because I saw all these 'A's, and when you XOR something with itself, it always becomes zero.

Null bytes are something very common in data, even though you never see them in text because they're literally used to mark the end of a text string.

I tried to XOR all this data with 'A', and this is what I got:


It didn't really make much sense, so I returned to the original, and noticed that there is another character that's getting repeated: the letter 'U'.

So this time, I XORed with 'U' and I got something a little bit more useful:


This green thing is the ELF Header (Executable and Linkable Format), and it actually means that there was a hidden Linux program inside this text. Also some library names can be seen further in the file.

I extracted the ELF with the Extract Files module.



Now all I had to do was find out what this program does. I use Ghidra as my main decompiler, but sometimes I may use IDA too. Let's load this thing to Ghidra now!

The first thing you have to do when analyzing an executable, is finding the entry point. The entry point is the address that gets called when the program runs.

When checking the functions you can usually see a function named main or entry, but sometimes there is no such function and you have to look deeper. For example, even the __libc_start_main function cannot be decompiled in this specific executable.

If you right-click on it though, you can go to the references, and find out which other functions call it.


And there it is, a call to the __libc_start_main, referencing the main function.


So that's our main function, FUN_00401704, which I will rename to main. Let's open it in the decompiler and see what is there for us to find...

I see some big numbers assigned to some variables, and that's usually how encrypted text shows up when decompiling. Then, one of them, local_58 gets referenced to FUN_00401489. Let's see what this function does.


All this function does is take a buffer (param_1), and its size (param_2) and XOR it byte-by-byte with 0x33. I'll rename it to XOR33 so I know what it does without having to check. Now when I go back, I can see this:


And now I see that everything from local_58 to local_30 has been XORed. Let's fix that.



That's an IP address, and a path to a file named core.db.

This IP is also the source of the captured packets.

Let's go deeper, and focus on this part of the code:



The first function called here, is FUN_004015b0, and it's pretty fun.


It gets the current date, then converts it to a string with "YY/MM/DD" format. After getting the date, it XORs an unknown data buffer named DAT_00404090. Let's take a look at it.

I'll copy the data as a byte string so I can XOR it on CyberChef



This data when XORed becomes 5P3R_S3CR3T_K3Y but I wouldn't really call it secret now. Continuing the code analysis, we reach line 14, that concatenates (joins) the "super secret key" with the date formatted as "YY/MM/DD" and saves it to buffer DAT_004040b0. This results to something like "5P3R_S3CR3T_K3Y23/11/03". I'll rename the buffer as Key_and_Date.



Going back to main we see that after this function returns, the function on the next line uses the Key_and_Date buffer.



I took a look at it, simplified its parameter names, and I'm left with this:


I still have to analyze FUN_00401226 that's being called on line 15.




Now this definitely looks like RC4 encryption. The RC4 key is the Key_and_Date buffer. What about the data? Well, back to the main function...

We can see that local_38 is being XORed, and that's the IP we found at CyberChef. It's being passed to the function below, so we just found our sender function.


The port is 0x1337, so we can look it up on Wireshark, and then decrypt the data with the RC4 key. We also need the date from when the packets were sent, because it is a part of the key.



We got the encrypted data, and the date (26/10/2023)
The new key will be: 5P3R_S3CR3T_K3Y23/10/26




EKO{W0ULD_Y0U_PL34S3_73LL_M3_WH1CH_D4T3_AR3_W3?}

Comments