Malware descriptions

Jumcar. Timeline, crypto, and specific functions. [Second part]

Jumcar stands out from other malicious code developed in Latin America because of its particularly aggressive features. At the moment three generations of this malware family exist, which basically use symmetric algorithms in the first and second generation, and an asymmetric algorithm in the third. In this manner the configuration parameters are hidden, progressively increasing the complexity of the variants.

In the first generation, data is encrypted with AES (Advanced Encryption Standard). We estimate that the first variant was released in March 2012, and that other pieces of malware with similar characteristics were being developed until August of the same year. That is to say over a six month period.

In this first stage, 75% of the phishing campaigns targeted Peruvian consumers that use home-banking services. The 25% remaining targeted users in Chile.

The following diagram shows multiple instances used by the second generation of Jumcar:

Some .NET instances used by a variant of the first generation of Jumcar

A month later, in September 2012, the second generation of Jumcar began to spread, exchanging the AES encryption algorithm for TripleDES. The propagation cycle of this generation lasted until March 2013, a period of time similar to the first generation: seven months.

Unlike the first stage, the second was aimed exclusively at users in Peru (100 %). The first two generations, encrypted with AES and TripleDES respectively, share a common factor – they both employ symmetric encryption algorithms.

In tandem with the second generation, in September 2012 the third generation began to circulate, using the RSA encryption algorithm (asymmetric). This could be because between the asymmetric algorithms RSA is more secure, and malware developers are looking to create more robust variants. This latest generation is “in the wild”.

Now, the phishing attacks haven’t forgotten users in Peru, with 86% of campaigns directly targeting users in this country. Chile was removed from the attacker’s plans and they subsequently modified their strategy to include users of a major bank in Costa Rica, which represents 14% of the campaign.

The following image shows the encrypted strings using AES, used to obfuscate some Jumcar configuration parameters in the first generation:

Strings encrypted with AES

By decrypting the code you can read something like this:

Decrypting AES encrypted strings

This behavior is replicated with similar features in all variants of the malware, showing four blocks that describe specific configuration actions for the Jumcar variants.

The first block describes the files that are copied, and where in the system they are copied to, following a successful infection. The second block configures the compromised websites from which to download the information to be recorded in the hosts file. The third relates to the handling of specific policies in the registry: disabling UAC (User Account Control) and trying to escalate privileges on the system. Finally, the malware adds a registry key to ensure that the malicious process will load each time you turn on or reboot the system.

Of these specific functionalities, we can highlight the two lines in the first block: Documento1.docx and calc1.xlsx.

In the first generation, the variants create a folder called “My Documents” on the root drive “C:” to which they copy a file called “Documento1.docx”. This contains a copy of the changed information in the hosts file. The following image shows this action:

DOCX file created by Jumcar to contain the hosts file configuration

This continued until mid-March 2013 (third generation) where, through a slight modification, the name of the folder created changed to “My Pictures”. The image below shows the functions for creating and manipulating the file and the folder:

Jumcar instructions for creating and manipulating files and folders

Jumcar shares other features in common with malware in general and Latin America malware in particular. However, the features we highlighted in the previous blog post, along with those described here, suggest that the distinguishing aspects of this malware family are likely to be replicated in other regional developments.

Remember that the entire family of malware is identified by Kaspersky Lab as Trojan.MSIL.Jumcar and Trojan.Win32.Jumcar. So we strongly recommend that you update your Kaspersky Lab products, especially customers in Latin America, as this part of the world is the direct target of those behind this development. However, as it also represents a potential threat to users in other regions because of possible collateral consequences, it’s always a good idea for everyone to keep their antivirus programs up to date.

Jumcar. Timeline, crypto, and specific functions. [Second part]

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



Lazarus targets defense industry with ThreatNeedle

In mid-2020, we realized that Lazarus was launching attacks on the defense industry using the ThreatNeedle cluster, an advanced malware cluster of Manuscrypt (a.k.a. NukeSped). While investigating this activity, we were able to observe the complete life cycle of an attack, uncovering more technical details and links to the group’s other campaigns.

Sunburst backdoor – code overlaps with Kazuar

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Our observations shows that Kazuar was used together with Turla tools during multiple breaches in past years.

Lazarus covets COVID-19-related intelligence

As the COVID-19 crisis grinds on, some threat actors are trying to speed up vaccine development by any means available. We have found evidence that the Lazarus group is going after intelligence that could help these efforts by attacking entities related to COVID-19 research.

Sunburst: connecting the dots in the DNS requests

We matched private and public DNS data for the SUNBURST-malware root C2 domain with the CNAME records, to identify who was targeted for further exploitation. In total, we analyzed 1722 DNS records, leading to 1026 unique target name parts and 964 unique UIDs.

Subscribe to our weekly e-mails

The hottest research right in your inbox