Win32/TrojanDownloader.Nymaim is a Trojan downloader that also exhibits ransomware features. It is associated with a long–running DarkLeech/Black Hole exploit kit (BHEK) campaign, dubbed the home campaign. Although reports of the recent arrest of Paunch, the BHEK author, might have put a momentary end to this group’s operations, it was active for several months and has infected numerous high profile websites. Recently, an independent researcher going by the name of Kafeine posted some statistics taken from the group’s BHEK panel and showed that there have been more than 2.8 million infections since the beginning of this campaign.
We have already discussed how a system gets infected with Win32/Nymaim and the numerous flow obfuscation techniques it uses in order to hinder analysis by researchers. In this blog post, we reveal a new infection vector, a study of the different international locker designs and ransom prices as well as a complete technical analysis of its communication protocol.
Win32/Nymaim compromises a computer in two steps, using two different executables. The first executable (referred to as“Win32/Nymaim first stage”) only downloads and run the second executable (referred to as“Win32/Nymaim second stage”). Win32/Nymaim second stage can download additional malware or lock the computer. ESET detects both stages as Win32/Nymaim because they contain a lot of common code, including the obfuscation techniques described in the first blog post.
When we first discovered Win32/Nymaim, we were aware of only one infection vector: drive-by downloads using BHEK. We now know that there is at least one other way this threat is delivered to unsuspecting internet users.
Starting towards the end of September and lasting for a couple of days, a large proportion of our Win32/Nymaim detections were files downloaded from the internet using a web browser. Looking through our logs, we found that Google is the referrer URL for most of these detections. It seems that users come in contact with these malicious files while searching for downloadable content on the web. Our analysis of some of the webpages that initiate these malicious downloads reveals that Black Hat SEO is used to make them appear as high as possible in the search results when people search for popular keywords.
The malicious websites that sometimes appear in the search results are only doorway pages. As such, they are constantly changing, most probably because their page rank diminishes as quickly as it initially increased. The doorway pages we have studied were trying to achieve higher rankings by highjacking popular pages. Once a user clicks on one of these search results, he can initiate the download of an archive whose name closely matches the search query, without any other interaction. The doorway page simply redirects the visitors to another site. This destination site has not changed during the time of our research. The following screenshot offers a visual explanation of this process.
As seen in the screenshot above, when the user clicks on a search result, his browser is first redirected to a second site, which redirects to the malicious archive. The user does not see any webpage loading; all he observes is an archive being downloaded and a blank page with a Google URL.
This archive contains an executable file. Once launched, it installs the malware on the computer. Since the user is already looking for downloadable content, he is more likely to execute the malicious file. As indicated earlier, the archive and the embedded executable file display a name that is closely related to the search query. Thus the same file can be downloaded with several different names. Sifting through our logs, the different names that a single file can have is quite revealing:
The multiple names listed above are all for the same file. When searching for downloadable content, especially illegal downloads, it is common to notice questionable websites in the search results. What is unusual in this case is to witness a malware downloaded right away when clicking on a Google result.
We have seen several malware families distributed through the same infrastructure. The payload changes frequently and delivers the same content for all users for a limited amount of time. Currently, it is delivering fakeAVs (detected by ESET as Win32/AdWare.SecurityProtection.A), but we have seen Win32/Sirefef (also known as ZeroAccess) as well as Win32/Nymaim.
Through the course of our research, we were able to collect several different lockscreen designs throughout the world. Win32/Nymaim has customized designs for countries in Europe and North America. The following list is not exhaustive , given we investigated cases in different countries throughout the world, but not all of them. That being said, we were able to obtain lockscreen designs from the following countries:
For countries where designs are not available, Win32/Nymaim second stage is downloaded and can be used at a later time by the malware author to download additional malware.
Interestingly, the ransom price is different from one country to another. The following graph shows the asking price per country, converted into USD, at the time of design collection in September.
For most of the countries examined, the ransom price is around 150 USD. That said, we have observed that United States residents are in for a much steeper price at 300 USD. Romania’s case is also quite interesting from a ransom perspective. The lockscreen states that the infected user can pay either 300 leu (Romanian currency) or 100 euros. Once both prices are converted to USD, it appears that the infected user gets a much better deal if the Romanian currency is chosen. This inconsistency in the Romanian ransom price is shown in the screenshot below. This specific discrepancy has been present in past designs of other police ransomware, such as Win32/Urausy (detected by ESET as variants of the Win32/Lockscreen family), and provides a good example of design reuse among different cybercriminal groups. ESET continues to advise that such ransom should never be paid by users.
When Win32/Nymaim first infects a computer, it reaches out to a set of predefined proxies using IP addresses hard-coded into its binary. These proxies are used to download the second stage for Win32/Nymaim as well as the locker HTML code and any additional malware. As indicated previously, these proxies change quite frequently and seem to be a layer of infected computers, which are used to hide the true C&C server. If none of the proxies are available, the binary also contains a hard-coded URL that will be used as a last resort.
All Nymaim network communications are encrypted using a salted RC4 key. The following image shows the structure of an encrypted TCP packet.
The salt’s length is obtained by masking the first byte of the encrypted message with 0x0F. The encrypted data is then decrypted by appending the salt to the following static RC4 key “*&^V8trcv67d[wf9798687RY”.
Once decrypted, the data has the following structure:
As stated earlier, Win32/Nymaim will either lock the computer screen or download additional malware and install it on the infected computer. A second layer of encryption is used in the latter case. This encryption consists of an RSA encrypted header and a custom encrypted body. The encryption scheme is described in the following figure.
RSA decryption is made on the first 0x80 bytes (RSA key was constant for all samples we have analyzed).
Header and encrypted body integrity validation is performed.
Two keys are obtained from the header data to decrypt the message body. The following figure illustrates the decrypting process :
Decrypted body integrity validation is performed.
Finally, the decrypted body is decompressed using the aPLib algorithm.
Now that the main infection vector, BHEK, is no longer operational due to its author’s reported arrest, the future of Win32/Nymaim and its distribution will no doubt be interesting. It appears inevitable that due to the complexity of this malware, we will encounter its variations again in the near future.
Special thanks to Mathieu Lavoie for his contribution to this analysis.
Sample distributed through Black Hat SEO: 81E6B189E944BF199D88C7DD006F01151FCC1ED8
Author Jean-Ian Boutin, We Live Security