In what is likely to be a short-lived cessation in Dridex campaigns while the criminal proponents behind that malware scramble to find a new delivery channel, it appears as though other malware purveyors may be positioning themselves to take additional market share of the lucrative crimeware arena. One recent development saw Vawtrak, previously a second-tier banking and information stealing trojan, emerge with new capabilities — most notably new methods for data encoding and changes to C2 communication that appear to be an attempt to improve on the malware’s detection evasion.
Part I : Attack Vectors and Infiltration
Before it can leverage its new capabilities, Vawtrak must be delivered to a target. While attachment-based phishing remains a leading delivery vector, Proofpoint also observed exploit kit-based attacks (aka “drive-by downloads”) delivering this updated variant starting in late September.
Attachment-Based Phishing :
Proofpoint observed several high volume email campaigns delivering the new Vawtrak variant.The emails claimed to have attachments that were faxes (Figure 1), subpoenas, price lists or financial reports in order to persuade the user to click on and open the attachment. The attachments contained macros from a service known as Xbagging or Bartalex1, which in turn downloaded the Pony malware dropper from a remote internet site. Pony then downloaded and executed the Vawtrak payload.
Proofpoint researchers have also observed this Vawtrak variant distributed through the Angler exploit kit. In the example shown in Figure 3, we observed a malicious TDS which led to an instance of Angler EK downloading Bedep. Bedep then performed its usual routines (e.g., created a hidden desktop that engaged in ad-fraud via browsing and other botnet attacks), but also downloaded Vawtrak.
Understanding communication to C2 and malware configuration files can play an important role in organizations’ detection of malware and remediation thereof, enabling better assessment of the damage malware might have inflicted. The latest observed variant of Vawtrak has incorporated definitive changes designed to further thwart such efforts by defenders.
Modified Encoding and Encryption :
As previous research has described2,3,4, Vawtrak has historically used an encoding method resembling a Vernam cipher to hide configuration files, suspicious strings and mask data exfiltrated to C2. In its latest incarnation, Vawtrak still uses a linear congruential generator (LCG) fed by a pseudorandom number generator (PRNG) to produce the key used to encrypt the data; however, the utilized PRNG function is now changed.
The code below is a simplified version of the new PRNG algorithm written in Python :
def prng(seed) :
return ((seed * 0x41C64E6D) + 0x3039 ) & 0xFFFFFFFF
String Encoding :
String encoding utilizes LCG fed by the new PRNG algorithm, while the generated keys are then subtracted from each ciphertext byte to generate the plaintext string. The first DWORD in the encoded string is used as the seed, while that same value is XOR’ed against the second DWORD to calculate the size of the encoded string. The encoded string begins at the position after the second DWORD. Most suspicious strings in the unpacked Vawtrak DLL are encoded using this method.
HTTP Beacons :
The HTTP traffic that is generated by Vawtrak to exfiltrate data to C2 is correspondingly changed, now drastically different in appearance as well as functionality. Figure 4 shows an example of the HTTP traffic generated by Vawtrak during the initial check-in with C2.
PHPSESSID is used to transport an encoded RC4 key and additional data. The first 4-bytes of the decoded Cookie are used to RC4 encrypt the data contained in the POST’s client body. This variant of Vawtrak utilizes a binary structure for most of the data transmitted to C2, as can be seen in the decrypted network traffic in Figure 5. This same encoding method is used during the exfiltration of credentials.
Depending on what is being exfiltrated, LZMAT is sometimes used to compress the exfiltrated data prior to encryption. Figure 6 shows the decrypted HTTP client body during an American Express attempted login, but the data is not yet in its plaintext format as it has been compressed with LZMAT. Figure 7 illustrates the observed plaintext data after it has been decompressed using LZMAT.
This variant of Vawtrak typically receives a raw (no encoding) binary blob of data immediately after the initial check-in. This blob contains a binary structure that may contain separate segments, including but not limited to an encoded configuration, URLs for retrieving additional modules, and a URL for retrieving an updated version of itself.
To decode the configuration file, Vawtrak first uses the exact same decoding method that is used to decode suspicious strings. Next, the configuration file is decompressed using LZMAT. After decompression, the configuration is contained in a binary data structure which contains several further encoded configuration segments. Figure 8 depicts the purpose of the first few bytes of this structure.
The next and last layer of encoding that Vawtrak uses to protect its configuration is a simple substitution cipher, where the S-box is created using the same PRNG algorithm. Each individual inject, target URL, etc., is contained in its own structure and decoded separately.
In addition to decoding the configuration immediately upon receiving it, Vawtrak also stores the encoded configuration in the registry after adding an additional layer of encoding. First, the seed (first DWORD) is XOR’ed against the VolumeSerialNumber of the drive which contains the result from the Windows API function GetTempPath. Next, the entire encoded configuration is encoded further using the addition LCG algorithm. This value is then stored in the registry using an encoded key.
We have observed this variant using the following registry keys denoting the configuration file:
However, these keys are first encoded in a similar fashion as older variants, but are first XOR’ed against the VolumeSerialNumber. Figure 9 contains a screenshot of stored Vawtrak information, while the highlighted key contains the encoded configuration.
As mentioned in the previous section, when Vawtrak receives its configuration from C2 it may also receive a list of URIs that are targets to additional modules. Vawtrak spawns a new thread for each module it should retrieve. The module is first received in an encoded state, which is decoded using the same subtraction LCG algorithm described in the previous sections. The decoded module contains a RSA signature at the beginning, which is used to verify the integrity of the compressed module. In each of decompressed “modules” we have analyzed, they have all contained a x86 and x64 version of the module. Each module may then be decompressed separately depending on the architecture of the infected machine.
So far we have only observed the following modules :
- hxxp://185.66.10[.]57/module/9f3359a7b12ceea791a4afc21a971152 -> injecter_32.dll / injecter_64.dll
- hxxp://185.66.10[.]57/module/4c06c7a4c2bc6fb51cd998e9bbcf5846 -> dg_32.dll / dg_64.dll
- hxxp://185.66.10[.]57/module/221680f17a95443c798c701eff36cbe6 -> pony_32.dll / pony_64.dll
As previously mentioned, in addition to retrieving modules Vawtrak may also receive a URL target pointing to an “update.” The update is contained in a binary data structure similar to the modules’ structure; however, the seed is contained in the second DWORD instead of the first. A RSA signature is then contained in the next 0x80 bytes, while the encoded update is contained in the remaining bytes following the signature. The update may be decoded using the same LCG subtraction algorithm. The URLs containing updated DLLs can be found in Appendix A.
Web Injects and Stolen Data
Vawtrak still functions similarly to previous versions regarding stealing data and web injects. In the sample’s configuration that we analyzed, several financial institutions and online services were targeted such as Amazon.com. For several of the organizations, a custom web inject was tailored to steal additional information beyond just login credentials. Victims attempting to login to Amazon were presented with the following credit card form (Figure 10) via Vawtrak’s web inject mechanism.
Should a victim fill out this form, the credit card data along with their Amazon login credentials will be sent to the botnet operators via the method described in the HTTP Beacons section. Figure 11 shows the decrypted output that is delivered to the malware’s C2.
At least one threat actor has moved away from distributing Dyreza to instead distributing a new variant of Vawtrak that has undergone several notable changes, seemingly designed to make Vawtrak’s data transmissions stealthier.
Those changes include:
- New PRNG algorithm for encryption key generation
- HTTP communication method to C2 and associated encryption for obfuscation
- Configuration encoding
- Downloaded modules encoding
- Update modules encoding
In the wake of Dridex’s disappearance, the authors of Vawtrak may be making a bid for market share. Whether they will succeed remains to be seen, but this latest offering is a sophisticated improvement and could better position them to fill the void left by Dridex and become the new leading tool in the banking trojan arena — and as such, bears further study and monitoring from a defense perspective.
- IDPS Detection
- ET Pro signatures: 2813059,2813060,2814111,2814112,2814150
Macro Office documents leading to Vawtrak :
Xbagging/Bartalex additional code downloads :
Pony downloads :
Pony hashes :
Pony Gates :
Vawtrak downloads :
Vawtrak hashes from email :
Vawtrak hashes from Angler EK chain :
Vawtrak c2 :
Vawtrak module downloads :
Vawtrak update downloads :
Vawtrak updates, decoded (respectively) :
Analyzed Vawtrak Dropper :
Analyzed unpacked Vawtrak x86 DLL :