When Hackers Get Hacked: the Malware Servers of a Data-Stealing Campaign

By on May 29, 2015

Selling stolen data is an easy way for cybercriminals to make some quick money on cyber black markets.

The following flowchart shows a generic credential-stealing campaign in action. In the last step, the flow is bidirectional. The malware makes a two-way authentication-free connection between the victim and the attacker.

q1


This two way connection not only seamlessly delivers the stolen data to malware servers, but it also makes sure the malware can communicate with the infected system and remotely execute commands. However, one major flaw with this approach is that in addition to the malware author reaching the victim, an aware “victim”–such as a honeypot or a malware researcher–can make use of this connection to access and hack the malware author’s server.

Let’s look at a similar case: McAfee Labs found a bunch of malware samples connecting to a site hosted on third-party domain provider “z********.esy.es.” Some of the hashes had a fresh compilation timestamp, suggesting that the malware samples were created very recently. The following picture shows one of the recent compile dates:

q2

The malware author uses fancy encryption schemes to conceal the control server that holds the stolen data. Here is a section of the decryption loop module:

q3

After reversing the binary, we found that the malware uses the following function F(x) to conceal the domain:

F(x) = A(key1[i]) XOR B(A(key2[i])) > B(A(key2[i-1])) ? A(key1[i]) XOR B(A(key2[i])) – B(A(key2[i-1])) : (A(key1[i]) XOR B(A(key2[i])) + 0xff) – B(A(key2[i-1]))

In which A(x) is a function to remove zeroes from unicode, B(x) is a function to convert hex data to a string by clubbing two numbers to form a byte, Key1[] and Key2[] are two buffers of hardcoded keys, and “i” is a counter that starts from 1 and increments with each iteration.

To illustrate, let’s decrypt “3” of the address from the key values, assuming the loop has already run I times.

Key1[] = 42 00 56 00

 q4

 

A(Key1[]) = 42 56 ( Unicode removed )

So A[Key1[i]) = 42

A(Key2[]) = 44 30 34 36 ( Unicode removed )

B(A[Key2[]) = D046 i.e. D0 46 ( String conversion followed by hex)

B(A[Key2[i-1] = D0

B(A[Key2[i] = 46

 

(key1[i]) XOR B(A(key2[i])) = 42 xor 46 = 04

B(A(key2[i-1])) = D0

 04 > D0 is False, so output will be second condition.

So f(x) = (04 + ff )- d0 = 33 .

0x33 = “3” i.e., the 3 of “z********.esy.es”

The preceding calculations illustrate one iteration, by looping the functions over and over, we come across the whole decrypted url: z********.esy.es.

This looks a good effort from the malware author to conceal the attack from static analysis, but when we take the behavioral approach we can see that all hashes are continuously connecting to the malware-specific site. The connection shows the malware was hosted on the third-party domain Hostinger. Using a third-party site is convenient for malware authors, who can periodically change the domain names and remain concealed. The following is an overview of the domain, hosting, and ASN information:

q5-1024x645

 

When we connected to the control server, we were surprised to see a number of dumped logs, each representing a compromised user:

q6

Each log gives a list of credentials of various accounts. Most victims have opened sites related to Brazil and the malware author uses Portuguese on his server.

q7

Following is a snippet of leaked account data:

q8

 

Here is a YARA rule to identify this campaign:

 rule CredStealESY : For CredStealer

{

 meta:

description = “Generic Rule to detect the CredStealer Malware”

author = “IsecG – McAfee Labs”

date = “2015/05/08”

strings:

$my_hex_string = “CurrentControlSet\\Control\\Keyboard Layouts\\” wide //malware trying to get keyboard layout

$my_hex_string2 = {89 45 E8 3B 7D E8 7C 0F 8B 45 E8 05 FF 00 00 00 2B C7 89 45 E8} //specific decryption module

 condition:

$my_hex_string and $my_hex_string2

}

McAfee Labs has contacted the authorities to take action against this website and its author.

McAfee customers are already protected from this threat via DAT signature CredSteal-ESY!

McAfee website reputation software flags this site and raises a trigger to make sure customers do not land on this page.

q9

Special thanks to my colleague Christiaan Beek for his invaluable input.

About the Author

McAfee Labs

McAfee Labs is one of the leading sources for threat research, threat intelligence, and cybersecurity thought leadership. See our blog for more information.

Read more posts from McAfee Labs

  1. it came up as if it were a survey from Amazon.com. " You have been randomly selected to take this short 4 question survey". Thank you so very much to Christiaan Beek. I guess a consumer can't even trust the secured site logo's. That was SCARY. I am entirely too old and tired to go through this mess. Thanks to your team again for watching out for us all, when we aren't even aware that we should be.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to McAfee Securing Tomorrow Blogs