July 5, 2017 at 12:48TeleBots backdoor analysis
On June 27, companies in Ukraine and other countries became victims of a large-scale cyber attack by the DiskCoder.C encryptor (aka ExPetr, PetrWrap, Petya or NotPetya). Malvar disguises itself as an ordinary ransomware - encrypts the data and requires a ransom for the decryption key. But, as the authors strive to inflict maximum damage, the chances of data recovery are minimized.
In the last report, we pointed out the connection of the DiskCoder.C epidemic with the TeleBots cybergroup and other attacks on Ukrainian companies. In this article, we will reveal details about the initial infection vector.
The cyber police department of the National Police of Ukraine confirmed the information of ESET and other anti-virus vendors that the legitimate MEDoc software was used by attackers to launch DiskCoder.C at the initial stage of the attack. However, so far there have been no details on how this operation is implemented.
In the course of our research, we discovered a complex hidden backdoor embedded in one of the legitimate MEDoc modules. It is unlikely that the attackers did this without having access to the MEDoc source code.
The backdoor module file name is
We studied all MEDoc updates released in 2017 and found that at least three updates contained a backdoor module:
Check dates. The attack with Win32 / Filecoder.AESNI.C (XData) began three days after the update 10.01.180-10.01.181; DiskCoder.C - five days after the update 10.01.188-10.01.189. Four updates from April 24 to May 10 and seven from May 17 to June 21 did not contain a malicious module.
An interesting point is related to the AESNI.C encoder. The MEDoc update of May 15 contained a backdoor, and the next, dated May 17, did not. Perhaps this is due to a relatively small number of infections - the attackers launched the encryptor on May 18, when most MEDoc users already installed a secure update.
The timestamps of the files studied suggest that they were compiled the same day or the day before.
Figure 1. The compilation time stamp of the updater with the backdoor released on May 15th.
Figure 2 shows the differences between the list of module version classes
Figure 2. List of module classes with a backdoor (left) and without (right).
The class containing the main backdoor is called
Figure 3. MeCom class with malicious code, as shown in ILSpy .NET Decompiler.
Methods of the MeCom class are called from a method
Each Ukrainian company is assigned a legal entity identifier - a code according to EDRPOU (Unified State Register of Enterprises and Organizations of Ukraine). This is useful for attackers - the code identifies the organization using the MEDoc version with a backdoor. Further, attackers can use various tactics to work with its network - it all depends on the goals.
Since MEDoc is used for accounting, it can be assumed that EDRPOU codes will be found on the machines on which this software is installed. Malicious code injected into the method
Figure 4. Code collecting codes EDRPOU.
In addition to EDRPOU codes, the backdoor collects information on proxy and mail service settings, including logins and passwords, from the MEDoc application.
Attention! ESET recommends that all MEDoc users change their proxy server and email account passwords.
Malicious code writes the information that is collected in the Windows registry under the key
And the most interesting part. The backdoor does not use external servers as C&C; their role is to execute MEDoc requests to its official server upd.me-doc.com [.] Uato check for updates. The only difference from a legitimate request is that the backdoor sends the collected information to the cookie.
Figure 5. HTTP request of the backdoor, which contains EDRPOU codes in cookies.
We did not conduct a retrospective analysis of the MEDoc server. However, as we reported in the previous report, there are signs that he was compromised. Therefore, we assume that the attackers involved server software, which made it possible to distinguish between requests from compromised and clean machines.
Figure 6. The backdoor code that adds cookies to the request.
Of course, the authors of the backdoor provided the ability to control the infected machine. The code receives a binary blob from the official MEDoc server, decrypts it using the Triple DES algorithm, and then decompresses it using GZip. The result is an XML file that can contain multiple commands at once. The ability to remotely control turns a backdoor into a fully functional cyber espionage and sabotage platform.
Figure 7. The backdoor code decrypts the received operator commands.
The following table shows the possible commands:
It is worth noting that command 5, called by the authors of the Malpvar AutoPayload, fully corresponds to how DiskCoder.C was launched on the “zero patients” - the machines from which the network infection began.
Figure 8. The AutoPayload function was used to execute DiskCoder.C.
As the study shows, the operation was carefully planned and implemented. We assume that the attackers had access to the source code of the MEDoc application. They had time to learn the code and embed a hidden complex backdoor into it. The MEDoc app is about 1.5 GB in size, and we haven’t had enough time to check if it has any other backdoors.
We still have a few questions to answer. How long has the backdoor been used? What commands and malware other than DiskCoder.C and AESNI.C were sent through this channel? What other infrastructures have been compromised, but have not yet been used by the cybergroup behind this attack?
Thanks to the help of colleagues Frédéric Vachon and Thomas Dupuy.
Detection by ESET products:
Legitimate server used by malware authors:
Registry key:
SHA-1 hashes:
In the last report, we pointed out the connection of the DiskCoder.C epidemic with the TeleBots cybergroup and other attacks on Ukrainian companies. In this article, we will reveal details about the initial infection vector.
Malware Update History
The cyber police department of the National Police of Ukraine confirmed the information of ESET and other anti-virus vendors that the legitimate MEDoc software was used by attackers to launch DiskCoder.C at the initial stage of the attack. However, so far there have been no details on how this operation is implemented.
In the course of our research, we discovered a complex hidden backdoor embedded in one of the legitimate MEDoc modules. It is unlikely that the attackers did this without having access to the MEDoc source code.
The backdoor module file name is
ZvitPublishedObjects.dll. It is written using the .NET Framework. This is a 5 MB file, it contains legitimate code that can be invoked by other components, including the main MEDoc executable ezvit.exe.We studied all MEDoc updates released in 2017 and found that at least three updates contained a backdoor module:
- 10.01.175-10.01.176 dated April 14
- 01.10.180-10.01.181 dated May 15
- 10.01.188-10.01.189 dated June 22
Check dates. The attack with Win32 / Filecoder.AESNI.C (XData) began three days after the update 10.01.180-10.01.181; DiskCoder.C - five days after the update 10.01.188-10.01.189. Four updates from April 24 to May 10 and seven from May 17 to June 21 did not contain a malicious module.
An interesting point is related to the AESNI.C encoder. The MEDoc update of May 15 contained a backdoor, and the next, dated May 17, did not. Perhaps this is due to a relatively small number of infections - the attackers launched the encryptor on May 18, when most MEDoc users already installed a secure update.
The timestamps of the files studied suggest that they were compiled the same day or the day before.
Figure 1. The compilation time stamp of the updater with the backdoor released on May 15th.
Figure 2 shows the differences between the list of module version classes
ZvitPublishedObjects.dllwith and without a backdoor, using ILSpy .NET Decompiler. Figure 2. List of module classes with a backdoor (left) and without (right).
The class containing the main backdoor is called
MeCom; it is located in the namespace ZvitPublishedObjects.Server. Figure 3. MeCom class with malicious code, as shown in ILSpy .NET Decompiler.
Methods of the MeCom class are called from a method
IsNewUpdatein the UpdaterUtilsand namespace ZvitPublishedObjects.Server. The method IsNewUpdateis called periodically to check if an update is available. The module with the backdoor of May 15 is implemented in a slightly different way and has fewer functions than the module of June 22.Each Ukrainian company is assigned a legal entity identifier - a code according to EDRPOU (Unified State Register of Enterprises and Organizations of Ukraine). This is useful for attackers - the code identifies the organization using the MEDoc version with a backdoor. Further, attackers can use various tactics to work with its network - it all depends on the goals.
Since MEDoc is used for accounting, it can be assumed that EDRPOU codes will be found on the machines on which this software is installed. Malicious code injected into the method
IsNewUpdatecollects codes from the application. One account in MEDoc can be used for accounting of several organizations, therefore the backdoor code collects all possible EDRPOU codes. Figure 4. Code collecting codes EDRPOU.
In addition to EDRPOU codes, the backdoor collects information on proxy and mail service settings, including logins and passwords, from the MEDoc application.
Attention! ESET recommends that all MEDoc users change their proxy server and email account passwords.
Malicious code writes the information that is collected in the Windows registry under the key
HKEY_CURRENT_USER\SOFTWARE\WCusing the value names Credand Prx. If these values exist on the computer, it is likely that a backdoor has visited it. And the most interesting part. The backdoor does not use external servers as C&C; their role is to execute MEDoc requests to its official server upd.me-doc.com [.] Uato check for updates. The only difference from a legitimate request is that the backdoor sends the collected information to the cookie.
Figure 5. HTTP request of the backdoor, which contains EDRPOU codes in cookies.
We did not conduct a retrospective analysis of the MEDoc server. However, as we reported in the previous report, there are signs that he was compromised. Therefore, we assume that the attackers involved server software, which made it possible to distinguish between requests from compromised and clean machines.
Figure 6. The backdoor code that adds cookies to the request.
Of course, the authors of the backdoor provided the ability to control the infected machine. The code receives a binary blob from the official MEDoc server, decrypts it using the Triple DES algorithm, and then decompresses it using GZip. The result is an XML file that can contain multiple commands at once. The ability to remotely control turns a backdoor into a fully functional cyber espionage and sabotage platform.
Figure 7. The backdoor code decrypts the received operator commands.
The following table shows the possible commands:
It is worth noting that command 5, called by the authors of the Malpvar AutoPayload, fully corresponds to how DiskCoder.C was launched on the “zero patients” - the machines from which the network infection began.
Figure 8. The AutoPayload function was used to execute DiskCoder.C.
conclusions
As the study shows, the operation was carefully planned and implemented. We assume that the attackers had access to the source code of the MEDoc application. They had time to learn the code and embed a hidden complex backdoor into it. The MEDoc app is about 1.5 GB in size, and we haven’t had enough time to check if it has any other backdoors.
We still have a few questions to answer. How long has the backdoor been used? What commands and malware other than DiskCoder.C and AESNI.C were sent through this channel? What other infrastructures have been compromised, but have not yet been used by the cybergroup behind this attack?
Thanks to the help of colleagues Frédéric Vachon and Thomas Dupuy.
Infection Indicators (IoC)
Detection by ESET products:
MSIL/TeleDoor.ALegitimate server used by malware authors:
upd.me-doc.com[.]uaRegistry key:
HKEY_CURRENT_USER\SOFTWARE\WCSHA-1 hashes:
7B051E7E7A82F07873FA360958ACC6492E4385DD
7F3B1C56C180369AE7891483675BEC61F3182F27
3567434E2E49358E8210674641A20B147E0BD23C