Dimnie: From Geeks on GitHub to Corporate Accountants
While the Russian information security community is closely watching the new attacks of the well-known criminal groups Carbanak, Buhtrap and RTM, a replenishment has quietly occurred in the camp of financial threats. And it was caused not by the appearance of a completely new banking trojan, but by the addition of a banking module to the previously known Dimnie spyware.
Dimnie is a trojan for collecting information (screenshots, keyboard taps, etc.) and gaining remote access to infected systems. Most recently, in January, we came across one of its new modules for substituting 1C payments, and then it became clear that the authors of Dimnie did not want to limit theft of information.
Dimnie gained fame at the beginning of 2017, when he attacked users of the GitHub service ( they wrote in more detail about this colleagues from Palo Alto Networks). But according to Virus Total, this trojan is far from new: attackers have been using it to the full extent since the middle of 2014, it was then that Dimnie executable files were first spotted.
GitHub attacked by the Trojan is used by many developers. Having stolen their credentials, attackers could compromise projects and carry out a so-called attack with the exploitation of trust in a third-party organization.
During such an attack, the criminal installs a backdoor in the source code of some popular program. As a result, when it reaches the customer, the attacker gains access to the systems of all end users, which are often large companies and government organizations. Thus, a cybercriminal kills a whole school of hares at once, compromising much more systems than if he attacked only one company. Well, then access to these systems can be sold for a pleasant amount to colleagues in the illegal workshop who specialize in certain sectors of the industry (for example, banks).
The Dimnie Trojan also stood out from the crowd in an unusual way of hiding requests to the management server - it masked them according to requests to the legitimate resources toolbarqueries.google.com and gmail.com and JPEG images. But the cybercriminals distributed it quite typically - using phishing emails with little social engineering:
Scheme of work
Dimnie is a sophisticated modular trojan. All its modules are divided into main and auxiliary. The main ones - Downloader, Autorunner, Core and Loader - are loaded at each infection and do not harm themselves. But the auxiliary modules - Keylogger, PCInfo, WebHistory, ProcInfo and Banker - are a “payload”, and it is with their help that information is extracted and replaced on an infected system. Each time Dimnie starts, the Loader module requests additional modules depending on what the criminal wants to do with the infected system. The general scheme of Dimnie is presented in the figure:
List of modules
Our team managed to download and explore the following Dimnie modules:
On January 29, we recorded a mailing list with these letters:
The letter was accompanied by a RAR archive with the file “Documents beginning of the year.exe” - the Windows executable file.
A typical letter to deceive accountants who are not particularly advanced in matters of cybersecurity surprised us with a rather hackneyed level of execution. It’s not in our rules to give advice to attackers, but you could at least remove “.exe” from the name of the archive ...
According to VirusTotal, the file “Documents beginning of the year.exe” was also distributed under other names:
- Documents 22.01.exe
- Documents by order 22.01.exe
- Reconciliation report 25.01.exe
- Document pack january.exe
- Excitation of enforcement proceedings January.exe
- Package of documents beginning of the year.exe
- Enforcement proceedings January 22 ,.exe
- Act 25.01.exe
- Enforcement proceedings 22.01.exe
For disguise, criminals used the PDF document icon. A user sitting under Windows with default settings is unlikely to distinguish this file from a real PDF document:
When our unsuspecting accountant opens the file, the payload starts up - in this case, the first Dimnie module, which we called Downloader. He downloads the main module and fixes it in the system.
The first thing Downloader gets is the Core core module and the module to dock on the Autorunner system. To do this, he makes a DNS query to obtain an entry with the name "justteordingto.xyz".
Interestingly, here, as in the instance examined by experts from Palo Alto Networks, the trojan disguises its requests as proxy requests to the resources toolbarqueries.google.com and gmail.com and as JPEG images:
After that, the received module is executed in a separate thread .
For the Autorunner module, the EntryPoint address is determined and the call parameters are formed: the memory address where the module is placed, the key for encrypting the data transmitted over the network, and the module identifier. Next, the Downloader module creates an Autorunner stream, waits for it to complete, and then self-deletes.
The Autorunner module contains the IP address 220.127.116.11, from which the Core module is loaded.
Depending on your rights, Autorunner uses one of three methods of binding:
As a result of the work of the Core module, a DNS query is made to obtain the domain name record “worldmed.bit”, which refers to the distributed blockchain infrastructure of Namecoin . The domain name is requested from the following DNS servers:
The “.bit” domain zone exists outside the general Internet domain name system and is not regulated by ICANN. This is not the first use of Namecoin DNS servers by malware developers - the RTM banking Trojan also used the “.bit” zone to resolve management server addresses. However, Dimnie was different from everyone here - it uses the “.bit” addresses only in the operation of the Core module, the rest of the modules we found contain the address of the management server in the form of an IP address wired into the module. Each time you start, Core loads the Loader module.
The Loader module downloads and runs all Dimnie function modules. The address from which Loader loads the modules of this trojan coincides with the address in the Autorunner module - 18.104.22.168.
At the same time, Loader uses its own implementation of the HTTP protocol. GET and POST requests are generated separately, and low-level winsock functions are used to send and receive responses.
According to our assessment, such a network interaction is not quite suitable for use in corporate networks: if you have your own proxy server, these functions simply will not work.
The communication protocol in this implementation does not differ from that described in the report of colleagues from Palo Alto Networks. The same domains are used to create GET and POST requests ( toolbarqueries.google.com and gmail.com ), and the modules and their reports are also disguised as JPEG images.
To encrypt data, Dimnie authors use AES 256 in ECB mode. This block encryption mode is considered the most unreliable - it preserves the statistical features of plaintext, and identical blocks of plaintext correspond to the same blocks of encrypted text. Considering that many formats use standard headers and blocks of identical characters, ECB cannot be called reliable, and this makes the choice of Dimnie authors especially strange.
Note that Dimnie loadable modules run differently:
- implementation of svchost.exe into the process. In this case, the process is created with the Suspended flag, and the module is introduced and the remote thread is launched using the CreateRemoteThread function;
- creating the file "% TEMP% \ msiexec2.exe", copying the payload into it and launching it;
- copying the module to the allocated virtual memory and starting the local stream.
The WebHistory module allows you to get the browsing history of the web browsers of the infected system. It goes through all the paths in the registry where the browser history files of Mozilla Firefox, Google Chrome and Internet Explorer can lie, after which it generates a message in the following format for each of them:
The Keylogger module is a keylogger that intercepts keystrokes using the WinAPI RegisterRawInputDevices function and supports the x86 and x64 architectures. At startup, it is embedded in explorer.exe and performs all subsequent actions from the context of this process. The keystroke log is saved to a temporary file in the% TEMP% directory along with the window headers and the clipboard. Then all this data is sent to the management server.
PCInfo system information gathering module
The PCInfo module collects information about the infected system: computer name and domain, user list, encoding used by default, information about network interfaces.
ProcInfo process list retrieval module
The ProcInfo module gets a list of running processes.
Stealer Account Data Theft Module
The Stealer module is the so-called Pony Stealer, software for stealing user account passwords from various installed programs. The list of programs from which Pony steals passwords includes more than a hundred popular names, including many FTP clients, email programs (Outlook, Thunderbird) and wallet files (wallet.dat and electrum.dat) for storing keys of various cryptocurrencies:
In this Pony Stealer’s case is compiled as a DLL, and it loads like the rest of the modules. The stolen data is sent to the address "http://22.214.171.124/g/g.php".
Banker payment order data substitution module
The most voluminous of the modules loaded by us, the Banker module replaces the details of the recipient in the text files of payment orders 1C (files 1c_to_kl.txt) when they are uploaded to remote banking systems (client banks).
Having received the appropriate command from the management server, the module implements its code in processes mainly belonging to web browsers and remote banking systems:
The implemented code allows you to intercept the CreateFile function called when opening files: for example, when a user wants to upload a payment order to the client bank and if the open file has the extension “.txt”, it starts with the line “1CClientBankExchange” and contains a section named “Payment order” ". In this case, the fields are replaced with the details of the recipient in accordance with the data from the management server.
Details are not changed in the following cases:
- If the name of the payer's bank contains the lines “SBERBANK”, “OPENING” or “VTB”;
- If the field “Recipient” or “Recipient1” contains the lines “UFNS” or “UFK”;
- If the fields "Payer" or "Payer1" contain the lines "SUE" or "MUP";
- If the amount does not meet the specified criteria.
It turns out that the authors of the Dimnie banking module are not going to steal money from customers of Sberbank, VTB, Otkritie Bank and government organizations, as well as funds allocated to the Federal Tax Service.
All this indicates that cybercriminals do not want to draw too much attention to their activities - and, apparently, until recently, they were completely successful.
It should be noted that the communication protocol of the Banker module differs from the communication protocol of the other modules - data is exchanged with the management server using the SOAP protocol, and specifically the open-source gSOAP library. In addition, requests to the management server are sent without any encryption or traffic obfuscation using false JFIF headers:
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="uri"><SOAP-ENV:Body SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><ns:get_Ar><uniq>1234567890</uniq></ns:get_Ar></SOAP-ENV:Body></SOAP-ENV:Envelope>
Using such methods (SOAP XML) is uncharacteristic for malware — it can often be found in enterprise application code. Together with the lack of traffic encryption, this suggests that the Banker module was developed by a third-party developer.
Dimnie made a rather mixed impression on us. On the one hand, it uses interesting technologies - masking a domain, mimicking a picture, a very complex modular architecture and a fault-tolerant Namecoin domain in the bottleneck of this architecture. All this seems to indicate that the authors of Dimnie carefully approached the work on their brainchild. But at the same time, the Trojan also has frankly disastrous moments: poor social engineering, using ECB mode for encryption, the inability to work through a proxy server, and a heavyweight SOAP protocol.
At the same time, protecting yourself from Dimnie is quite simple:
- Deny access to the Internet bypassing the corporate proxy
- Deny DNS queries to Namecoin servers
Such an uneven quality of the Trojan made us think that several cybercriminals with different qualifications are engaged in its development at once. But be that as it may, the transition from the theft of information to the theft of finance directly is alarming.
It is still impossible to even estimate approximately how much money Dimnie authors have already managed to steal: no one writes about him in financial cyber threat reports, and we have not yet encountered successful cases of embezzlement. The authors of the Trojan avoid attacking large banks and government organizations and, possibly, limit the maximum amount of thefts. Apparently, they are afraid to attract the attention of major players in the information security market. And so far they have been very successful in this.
Network Identifiers Related to Dimnie: