Today I looked a bit closer at the response sent from chromeupdatecenter.com to the request of the malware. The malware connects to Port 8080, most likely because the “malware webservice” runs on another HTTP server instance (the headers state nginx, while the main page is supposedly running Apache on a Ubuntu server). I figured out that the first 22152 bytes contains a bitmap. This bitmap is later on saved to the users temporary path (on Windows 7 to C:\Users\$USERNAME\AppData\Local\Temp\32239.bmp).
Desktop wallpaper after infection
The image length also matches the header “ACC”, which states 22152. Although, the length of a bitmap is also available from its header, which would make the server code a bit easier, maybe something for their next version 😉
However, after the bitmap, there are still 493 bytes left. This should be either the encryption key or the message in the AlertEncryptor.txt files….
Pattern matching
Looking a bit longer at the remaining data in a hex editor, some patterns stand out: all bytes have higher values than 128 (text encoded in ASCII is below 128, so this might be something complementary of a ASCII text). Also, fairly often 0xdf appears. Comparing some of the text with the binary output, one can see that spaces (0x20) exactly match 0xdf. So this must be the text written to the AlertEncryptor.txt files. Of course, 0x20 is the complementary to 0xdf! Ok, no one can easily reclaim the ASCII data by using XOR with 0xff… Some C code decodes the data easily:
#include <stdio.h>
/*
* Get text from GoogleChromeUpdater.exe malware response
*/
main()
{
FILE *fd;
char c;
fd = fopen("extracted.bin", "r");
while (fread(&c, 1, 1, fd)) {
printf("%c", c ^ 0xff);
}
fflush(stdin);
close(fd);
return 0;
}
This gets the expected output:
Files on your hard disk are encrypted. Among them pictures, photos, documents, presentations, tables, databases, spreadsheets, archives, source codes etc... To names of the encoded files the line "_mail_yourID" is added. If you want to resore files: 1) Please, don't change encrypted files 2) Please, send message to mailbox specified at the beginning and the message end. (!!!)SURELY: In the subject of the message specify your ID. ID specified at the beginning and the message end.
The only missing part compared to the generated AlertEncryptor.txt files in this text is the E-Mail address and the ID. This seems to be generated by the malware itself when writing those text files, I found also a matching static text (“\nID: %d\nMAIL: %s\n\n”).
Well, it seems like the response content do not contain the encryption key. So the key must be in the header. There is still this EID which I do not understand yet. However, those hex numbers are 54 bytes (432 bit) of binary data, which do not look like a commonly used length for an encryption key… Also some of the numbers again look like they are some complementary of an ASCII character. Lets use our complementary “decrypter” again on this data, and see what happens:
$ ./a.out eid.bin ��~XI�W��iBl�i�U�sC� ϔ��alertencryptor@aol.com
Oh how nice, the E-Mail address! Of course, since this string is also not inside the malware itself, it must be part of the response. So another 22 bytes unveiled. So the first 32 bytes of the EID look like an encryption key. This also sounds a lot more like a common key length (256 bit).
That’s all so far. I think I have isolated the encryption key from the response now, which should allow to decrypt the data. However, the encryption algorithm remains unknown. Also, assuming the encryption key is not static, there is still little hope for a general decryption solution.
Note: Currently the server does not respond the way it used to some days ago. The EID are currently empty (in the form “EID=.”)… Either the malware author disabled the server or it is somehow broken.
0 Comments.