Information-stealing ‘Vawtrak’ malware evolves, becomes more evasive

library
crime | hacking | security

Vawtrak, as we described in detail in our recent technical paper, is a dangerous banking Trojan that is actively being updated and improved on a regular basis.

As a demonstration of this, SophosLabs has recently observed a few interesting changes made by the Vawtrak authors.

The updates are mostly about disguising where the malware connects when it “calls home” to fetch its instructions on what to do next.

Additionally, the way that Vawtrak communicates with its so-called command-and-control (CC) servers has been adapted so that the malware’s traffic looks less suspicious.

We have also observed new configuration files being deployed, and an interesting trend in the commands sent back by the CC servers when an infected computer first checks in.

How Vawtrak stores its data

The first change is to how the list of CC server addresses is stored inside the Vawtrak program file.

As we explained in the technical paper, Vawtrak makes heavy use of pseudorandom numbers, produced by a Linear Congruential Generator (LCG) algorithm, to scramble the data it contains.

Vawtrak also waits for a browser process to be launched before making any outbound CC requests, so that it never generates traffic when you wouldn’t expect it.

→ In fact, Vawtrak uses what is known as process injection to add itself into the memory space of the the browser itself, so it doesn’t show up as a suspicious-looking process of its own.

In previous versions, the list of CC servers, the format string used to generate the call-home traffic (carried out using HTTP POST requests), and various other pieces of information would all be left unencrypted in memory once the malware was active.

In more recent versions, the data remains encrypted even after it has been injected into the browser process.

Additionally, the updated versions of Vawtrak encrypt each data component separately, so unscrambling it is not as simple as extracting a key and decrypting all the data in one go.

We must decrypt each item of data in the block separately using different keys.

For example, the chunk that contains the format string for the call-home POST request is 0x200 bytes long and starts at offset 0x10, with its key value just before it at offset 0xC.

The number of CC server domains is then stored at offset 0x210, with each address stored as a block of length 0x44 bytes with its own decryption key that needs to be fed into the LCG algorithm.

How Vawtrak calls home

The second significant change is to the format of the data that is sent back to the CC server from an infected computer.

Previous Vawtrak variants encrypted the data in a big chunk and sent it back as a single binary “blob” in a POST request.

The updated version sends several base64-encoded parameters in the request, for example:

When broken down, it contains the following parameters:

Bijt = 11853

Oupteb = Ve

EakqAwsu = /hUiFromAAf4NahsaH/iZpyiikWOIwZuUGocvyeltVr81aCpouYYnfcXgTVs//PUGDahKBXeSSicOHFKw+OUoq6jIlw7rGHBRuhMsvCuqQOgN214KFMOl/K4ZMUl4BzN1BQfhFTN0CbIHqNH+HQcanqzX+sGMGRuu+i4bt23u5yke21WKWyvvhgwevvGDDODjUJd6itC0HK4ykM4Ktzi6yI=

S = Aume

Tosduh = 24447

Qo = Bomn

The only parameter of any interest is the largest one, EakqAwsu. This is simply the same encrypted POST data that the previous version sent, but now base64 encoded.

All the other parameters are randomly generated and serve only to disguise the genuine data and make the whole request look less like CC data belonging to malware and more like legitimate traffic.

The Vawtrak authors’ attempts to disguise the network data can also be seen in the traffic generated when cookies and stored credentials are sent back.

This time the data is disguised inside a request of type multipart/form-data.

The request again contains several decoy items as well as the genuine data, which is labelled as if it were an image file:

Another change we have seen is the addition of URL patterns that look more like legitimate traffic.

Some examples of these include:

/stores/servlet/OrderItemDisplay?storeId={TYPE:Hb}langId={BOT_ID:Hd}catalogId={PROJECT_ID:Hd}

/collection/{PROJECT_ID:HD}/{TYPE:HB}/{BOT_ID:HD}

/mer/res/{TYPE:Hb}.php?pid={PROJECT_ID:Hd}bid={BOT_ID:Hd}a={BUILD:Hw}

/stats/{TYPE:HB}/counter/{PROJECT_ID:HD}/{BOT_ID:HD}

What Vawtrak does

The range of configuration files has also broadened, with the addition of several new targets.

In particular, we have seen one file targeting only banks in the Czech Republic; one file targeting only American Express; one targeting only Wells Fargo; and one targeting only Fifth Third Bank.

The final significant change we have seen is that some Vawtrak samples are being immediately instructed to distribute other malware.

One of the commands that the crooks can issue remotely is represented by the text string DL_EXEC. As the name suggests, this command tells an infected computer to DownLoad and EXECute a new program, typically some sort of additional malware.

This is perhaps a sign that the Vawtrak authors are looking to further monetise their botnet by using pay-per-install affiliate programs to generate revenue.

This was a tactic used with the Gameover malware: after milking an infected computer for what they could using Gameover, the crooks used it for a new money-making attack by deploying the CryptoLocker ransomware.

CryptoLocker infamously scrambled all your files and gave you 72 hours to pay a $300 ransom to get them back.

The bottom line

These updates show that Vawtrak is very active and constantly being improved by its authors, in particular to make it harder to spot.