Snowcone (Malware Challenge)

05 Feb 2021

Problem

This was a malware challenge where we were given just a simple pcap, “snowcone.pcapng” along with the following prompt:

“Another day, another intrusion here at IcyRetina. Can you help recover the encrypted files APT42 stole from this victim?”

.pcapng & Binary Analysis

Loading the pcap into wireshark we can quickly spot a windows executable snowcone.exe, which we can decompile using dnSpy, a now achieved but still usable tool which will allow us to more easily reverse engineer this program built in C#.

To summarize the program’s functionality, it operates like a command-line tool quickly encrypting the entire contents of any directory given to it (in that sense, it works a lot like any generic piece of ransom-ware). Although since this code could be repurposed for evil, I won’t post any screenshots of the decompiled code here.

Looking deeper into the decompiled C# source code we (me and my teammates working on the challenge) were able to determine the following steps the program takes to encrypt each file:

1. Generate a random 32 character string as a “key”
2. Use said randomly generated key to encrypt the file contents
3. Encrypt the key with a ‘one-time’ pad (it actually just XORs each byte of the key by 66)
4. Bitwise ORs each key byte by 128 and writes it out along with the rest of the encrypted data as a file with a .sn0w extension in the filename

Excellent, we know how the program works! From here we can write a quick python script to reverse the encryption by just taking the key from the first 32 bytes and using that to decrypt the rest of the file contents. But where are the files we are supposed to decrypt?

More .pcapng analysis and solution script

Looking back at pcap we can see an additional tcp scream which occurs prior to the executable being transmitted:

From this stream we can see that the user has encrypted a directory “super_sensitive_documents” with snowcone.exe, zipped the results, then used certutil to encode the zip file in base64, and ending TCP stream by printing out the encoded zip bytes.

By saving the entire “raw” TCP stream from wireshark we can then run certutil with the analogous -decode operation and get the target .zip file (the buffer text content seems to get discarded by certutil making it not an issue).

We can unzip the .sn0w files but now we need to reverse the encryption we figured out from the snowcone binary. With a little python (and a lot of pesky byte-to-int type conversions) we can decode the encrypted files and find our flag located in the “flag.txt.sn0w” file.

Below is my python script I wrote which decrypts the .sn0w files (and gives them a thematic .MELTED file extension):

# decode .sn0w files

from sys import argv

if (len(argv) < 2):
    print('bruh gimme the .sn0w pl0x')
    exit(2)
print("Decrypting ", argv[1])

with open(argv[1], 'rb') as sn0wfile:
    with open(argv[1]+".MELTED", 'wb+') as meltedFile:

        encrypted_data = sn0wfile.read()

        # get 32 byte key
        byte_key = list(map(lambda b: b^66^128, encrypted_data[:32]))
        # Write out decrypted file contents
        for index, next_byte in enumerate(encrypted_data[32:]):
            meltedFile.write(bytes([int(next_byte) ^ byte_key[index%32]]))

Conclusion & Lessons Learned:

Overall this was a fun challenge which refreshed some of my wireshark skills and again underscores the utility of decompilers in reverse engineering complicated binaries.