This research was made possible by Lior Keshet, an IBM Trusteer Malware Researcher, and by Tomer Agayev, an IBM Trusteer Security Threat Engineer.

How many malware builds would you guess Dyre compiled and spammed out recently? IBM Security X-Force researchers have counted no less than nine different malware builds with actual code changes spread by this highly active crimeware project — and that’s in the past week alone.

Dyre Is in Constant Evolution

The Dyre Trojan is an ever-evolving advanced threat. While most of the time its modifications are minor, our recent research indicates the malware is doing some summer renovation in the code with the purpose of keeping it more elusive and stealthy.

At this time, there are two principal changes worth noting for Dyre: First, it has moved its run key from the Windows Registry, turning it into a scheduled task. The Registry still contains the instructions, but files run by the scheduler can be found in a preset Windows Tasks folder, where they are fetched as needed. By turning Dyre’s run into a scheduled task, it becomes more resilient to deletion by the user or security products. But it also gives its developer the flexibility to decide when to run and how often, or upon which type of OS event to rerun the malware file.

The second change is the randomization of Dyre’s configuration file name using a naming algorithm, most likely in order to trick antivirus engines that may be automatically finding and deleting it from infected PCs. The most likely reason for this change in approach is to keep the configuration away from automated security products that search for the file and then delete or quarantine it.

For this change, Dyre’s developer prepared a mathematical manipulation designed to create a different file name every time but a constant one for the same user. To do that, Dyre uses the machine’s name and the user’s name as its main parameters and concatenates them. It then takes that alphanumeric string and performs a hashing operation on it (SHA-256), then processes the result into a new string.

These changes show that advanced and active malware like Dyre is an ever-moving target that changes constantly to evade static security and maintain its foothold in infected endpoints. The next section of this post describes some of the technical details related to these changes.

Dyre’s Run Key in Non-Admin Installations

Until a few weeks ago, these non-admin installations had Dyre register a run key in the Windows Registry, designed to have it automatically run as soon as the computer is rebooted by the user:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

This element was changed in Dyre’s more recent builds. The malware’s developer modified this persistence mechanism and programmed Dyre as a scheduled task in the Registry.

The commands used for running Dyre’s schtasks are:

• /create: Create a task.
• /tn: Task Name specifies a name for the task.
• /tr: Task Run specifies the program or command that task runs.
• /sc: This specifies the schedule type. Valid values are MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, ONCE, ONSTART, ONLOGON, ONIDLE.
• /mo: A modifier that specifies how often the task shall run within its schedule type.

According to the task’s configuration, Dyre is currently defined to rerun every single minute!

The code below shows the parameters that define the run, where taskname stands for the executable’s file name and dropee_loc stands for its location.

Semirandom Config File Names

In the recent changes implemented by Dyre’s developers, the configuration name creation begins after the malware’s main thread is injected. That is the point where it calls on a function named createLocations.

At this point, Dyre attempts to locate the endpoint’s name and the active username on that machine. Since this operation does not succeed in 100 percent of the cases, Dyre has a fallback mechanism to just skip the process and use the letter C as the name of the endpoint.

Once Dyre has the initial string concatenated, it calculates its length, then calls on a create_hash function. Now, the string’s numeric value and the number of times it’s set to replicate the same manipulation can be set up. As of the time of writing this report, Dyre repeats the same mathematical manipulation three times.

The create_hash function calculates a standard SHA-256 hash function followed by a short mathematical manipulation, which is then followed by the next hashing.

Dyre adds one to the ASCII value of the byte — for example, C will become D. It concatenates it to the first 16 bytes of the string. It will call the SHA-256 hash function once more and repeat the process three times.

After the triple hashing, the malware takes four parts of the last hash, which is eight characters. Those serve as the configuration file’s name.

Let’s take an example where the endpoint name is Trusteer and the user name is Rocks. The process is case-sensitive.

The first SHA-256 hash of this combination would be:

7bae53921ee52afa71e0f9f32e51ac811be6f2dce6f7cf04b52b22f19b142326

Adding one to that:

7bae53921ee52afa71e0f9f32e51ac811be6f2dce6f7cf04b52b22f19b1423267caf54931fe62bfb72e1faf42f52ad82

The second SHA-256 hash:

a66509481502fd05e71980b623afd68cc066df301b0b777d082292ef0e1d8c8c

Adding one again:

a66509481502fd05e71980b623afd68cc066df301b0b777d082292ef0e1d8c8ca7660a491603fe06e81a81b724b0d78d

The third SHA-256 hash:

77ca550fa35a45867fad61e13c7b82953653d4523571428d3e8f3d957d91f3f9

Adding one for the last time:

77ca550fa35a45867fad61e13c7b82953653d4523571428d3e8f3d957d91f3f978cb5610a45b468780ae62e23d7c8396

Final SHA-256 hash:

4edd7c1294a01e429649d85aa92dadd0808d6573641f79b24310c06ff4594887

At this point, Dyre takes 4 bytes each time and changes that string’s — the sequencing of bytes of a word of digital data — a few times until it has a 16-byte string. The resulting semirandom alphanumeric string is the configuration file’s name:

471306993c57e3a436a2cb40c5be5e8f

Knowing the hashing process makes it possible to recalculate and know whether the machine has a Dyre configuration on it.

Dyre Keeping Tabs on Security

According to IBM Security X-Force research, Dyre’s developers are keeping close tabs on security. They constantly evolve the malware in both major changes and semantic modifications to ensure the Trojan is not detected by standard security products and static detection mechanisms.

Dyre is considered the most advanced banking malware in the wild. It is used for broad-stroke financial attacks on banking customers and in the targeted heists of corporate accounts measured in millions of dollars, which IBM Security previously reported as Dyre Wolf campaigns. Most recently, Dyre was seen adding a number of attacks targeting banks in Spain.

Dyre’s most targeted geographies in the past 60 days appear in the chart below. North America is the main focus, followed by Europe and Asia-Pacific.

Figure 1: Countries targeted by the Dyre malware. (Source: IBM Security)