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:
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.
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.
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...
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.
Comments
Post a Comment