Deep Analysis of a Driver-Based MITM Malware: iTranslator

The FortiGuard Labs research team recently captured a malware sample, an EXE file, which was signed by an invalid certificate. Once a victim opens the exe file, it installs two drivers to control the victim's Windows system as well as monitors the Internet activities of the victim's Web browser.

In this blog, I will elaborate how the malware installs the drivers onto the victim's system, how the drivers work, and what the malware does.

Executing the Malware Sample

The file name of this captured sample is 'itranslator_02.exe'. In the wild, the malware has several different names, including 'itransppa.exe', 'itranslator20041_se.exe', 'Setup.exe', and 'itransVes.exe'. The file was signed by a digital certificate that had expired on May 16, 2015. The certificate was issued to 'Beijing ******** Technology Ltd.' (I hid the company name with '*'.) by 'VeriSign Class 3 Code Signing 2010 CA', and its serial number is '0A 00 5D 2E 2B CD 41 37 16 82 17 D8 C7 27 74 7C'. Figure 1 shows the screenshot of the sample's digital certificate information.

Figure 1. The expired certificate used by the malware

When 'itranslator_02.exe' is run, it creates a new folder named 'itranslator' in the program-data folder (in my test environment, it's 'C:ProgramData'). It then extracts a new file named 'wintrans.exe' into this folder. After starting 'wintrans.exe' with the command parameter 'P002', 'itranslator_02.exe''s task is finished. The command line string is 'C:ProgramDataitranslatorwintrans.exe P002'. This malware refers to 'P002' as 'GUID', and uses it to communicate with the C&C server throughout the malware campaign.

Installing a Driver Component

The 'wintrans.exe' executable takes over the work of the 'itranslator_02.exe' by downloading and installing additional malicious components into the victim's Windows system. It starts by installing a driver in the victim's system. Let's look at how it does that.

Figure 2. Creating the driver service 'iTranslatorSvc'

It creates a thread to do the following work: it calls two Windows system APIs to create a driver service, which are 'OpenSCManagerA', 'CreateServiceA'. The driver name is 'iTranslatorSvc', which is a parameter to the API call 'CreateServiceA'.

By the way, calling the 'CreateServiceA' API creates a new registry key for this new driver service. For this case, the following subkey was created: 'HKLMSYSTEMCurrentControlSetservicesiTranslatorSvc'.

The Start type of the newly created driver is first set to 2, which translates to 'AUTO_START', and later is modified to 1, which means 'SYSTEM_START'. These enable it to load when the system starts up. Figure 2 shows the assembly code snippet in IDA pro that enables you to see how the driver is created.

Next, 'wintrans.exe' extracts a file named 'iTranslator' into the Windows Directory ('C:Windows' in my test environment). The extracted file was embedded in the Resource section of 'wintrans.exe' named 'BIN'. Figure 3 is the pseudo code showing how the file is extracted.

Figure 3. Extracting the file iTranslator from resource

As you may have guessed, the file 'iTranslator' is also a Windows driver file, whose full path has been provided to the API 'CreateServiceA' when being called to create 'iTranslatorSvc'.

The 'iTranslator' file is protected with a VMProtect packer. The file was also signed by an invalid certificate (It already expired on May 12, 2015). The signer is 'Nanjing ********* Technology Co.,Ltd.' and the Serial number is '73 dc b1 a0 35 15 bb 63 9b f3 1e cd 5f 98 ff 24'. In Figure 4 you can see the file property of 'iTranslator', along with its packer information in a PE tool.

Figure 4. iTranslator property and its packer information

The malware then creates the value 'GUID' with the value 'P002', and the value 'MachineCode' with a hexadecimal value generated from the victim's hardware information, which are both saved under the registry subkey 'HKLMSYSTEMCurrentControlSetservicesiTranslatorSvc'. Figure 5 is the screenshot of what this looks like in the Registry Editor.

Figure 5. iTranslatorSvc items in registry

After that, it continues to call the API 'StartServiceA' to have the malicious driver run immediately. To clearly explain how the driver works on the victim machine, I'll next analyze it from the time it starts during the OS startup, which is the normal way to load a driver.

Downloading Other Components

Once installed, it tries to download a DLL module in the thread function. The HTTP requests and responses are shown in Figure 6:

Figure 6. Downloading a dll file

In the URI, 'uid=' is the machine code; 'v=' is the malware current version (here, it is '1.0.0'), 'x=' is the victim Windows platform (32 bit or 64 bit). In the header, 'UID: P002' is the malware GUID. In the response packet, it replies with the latest version and its download link. In this sample, the latest version is 1.0.7, and the download link is 'hxxp://gl.immereeako.info/files/upgrade/32/iTranslator.dll'. (During my analysis of this malware, however, the latest version was updated to 1.0.8 and its download link was changed to 'hxxp://dl.shalleeatt.info/ufiles/32x/iTranslator.dll'.)

It then downloads the dll file and saves it into the same folder as 'wintrans.exe' located at 'C:ProgramDataitranslator'. Based on my analysis, this downloaded file 'iTranslator.dll' may be the main module of this malware. Here is a partial list of the tasks it performs:

1. Extract and loads a net filter driver
2. Exchanges data with drivers
3. Install its SSL certificate into browsers as trusted root certificates without the victim's permission
4. Monitors the Internet access packets from victim's browsers

Interestingly, this download is not only a DLL file, but also a file container because its resource section contains many other files that are later extracted into the victim's local folders. The downloaded 'iTranslator.dll' could be loaded and executed in 'wintrans.exe' when it's first installed, or it could be loaded and executed in 'winlogon.exe' when it is loaded by the driver 'iTranslatorSvc' during the Windows system startup. I'll fully explain how it works in the driver start section below.

It also records the latest version in the system registry under 'HKLMSOFTWAREMicrosoftWindows NTCurrentVersion', where the value 'iVersion' is the latest version. As of this writing, it is 1.0.8.

Notifying the Attacker of the Malware Installation

The last job of 'wintrans.exe' is to send the victim's system information to the attacker's server. The packet it sends out looks like this:

'ch=' in the URL and 'UID' in the header are the GUID 'P002'. 'mc=' in the URL and 'MC' in the header are the machine code of the victim's system. 'os=' is the victim's OS version. 't=' is the current Windows installation date, which is taken from the system registry. It uses Unix time, which is the number of seconds since Jan 1^st, 1970. 'm=' is the victim's network MAC address.

I hid the sensitive data contained in the original packet with '*'. This packet is used to report back to the attacker that the malware installation has finished on a Windows system.

Malicious Driver is Loaded During Windows Startup

From this point I'll explain what the malware does once the driver 'iTranslatorSvc' starts during the victim's Windows startup.

The malicious driver file is located in 'C:WindowsiTranslator'. It's protected by VMProtect v.2.07 packer and has several export functions, as you can see in Figure 7.

Figure 7. Export functions of the driver iTranslatorSvc

The driver is loaded by 'nt!IopLoadDriver'. After the VMProtect packer's code has been executed, we can enter the driver's real DriverEntry function that was restored by the packer's code.

It first reads the 'GUID' and 'MachineCode' from the system registry, saves them into the global variables, and sets the key value 'Start' to 1, which means 'SYSTEM_START'. Next, it creates a device object '\Device\iTranslatorCtrl' for this driver and a symbolic link '\DosDevices\iTranlatorCtrl' so the software running on ring 3 can access the driver through '\\.\iTranslatorCtrl'. It then sets some dispatch functions, just as other drivers do. In the IRP_MJ_DEVICE_CONTROL dispatch function, it only returns the values of 'GUID' and 'MachineCode' from the global variables.

Setting the Callback Functions in the System Thread

Finally, it creates a system thread by calling the API 'nt!PsCreateSystemThread'. The thread function is still protected by VMProtect packer. Figure 8, below. displays the code snippet of the System Thread function protected by VMProtect packer. By the way, all API calls in this driver are also protected by the packer, just like the code shown in Figure 8.

Figure 8. VMProtect packer-protected code snippet

When the system thread starts, it extracts a file from its memory. The file's full path is 'C:WindowsSystem32iTranslator.dll'. It then calls the API 'nt!PsSetLoadImageNotifyRoutine' to set an image-loading callback function. From MSDN it describes this API as: 'The PsSetLoadImageNotifyRoutine routine registers a driver-supplied callback that is subsequently notified whenever an image is loaded (or mapped into memory).' This means that whenever an image (e.g. an exe file) starts to load, the image will be suspended and the callback function in the driver will be called by another API, namely 'nt!PsCallImageNotifyRoutines'. At this time, the driver 'iTranslatorSvc' can then read the image's entire process information and modify that process information to affect the process's workflow.

Let's step back on this callback function in the driver to see what its tasks are. When it is called, it checks to see if the process name is 'winlogon.exe'. If so, the driver finds out the mapping memory of this process. It then rebuilds the Import Directory Table data in memory, where it adds the malicious DLL 'C:WindowsSystem32iTranslator.dll' to the end of the Import Directory Table. The Import Directory Table also contains some modules data that the process' running needs (e.g. Kernel32.dll, User32.dll.). The data for every module in the Import Directory Table occupies 14H in bytes.

Figure 9 is the screenshot of the rebuilt Import Directory Table. It needs to modify the Import Table item offset in the PE Data Directory Table to enable the rebuilt Import Directory Table. After that, once the 'winlogon.exe' resumes running, it loads this malicious DLL in the same way as loading other normal DLLs.

Figure 9. Rebuilt Import Directory Table

Why is it using the 'winlogon.exe'? This is a process belonging to the Windows login manager that handles the login and logout procedures on a Windows system. If it is killed, you will be logged out from the system. In other words, this process will always work until the Windows system is shutdown.

The malware also continues to set another image-loading callback function. From my analysis, this one is used to check if the image is a particular browser, such as 'iexplore.exe', 'firefox.exe' or 'chrome.exe'. If matched, the driver finds the related process information block and adds 'http://go.microsoft.com/?69157' to its command line. This is done so that when the browser opens, it accesses 'http://go.microsoft.com/?69157' first. Figure 10 is the screenshot of IE when IE starts, whose command line has been appended with the URL 'http://go.microsoft.com/?69157'.

Figure 10. IE opens with the URL 'http://go.microsoft.com/?69157'

Actually, the URL is not really being accessed from the victim's browser, but it instead works like a switch flag. Later, the malware will extract and load another driver to monitor the victim's network activity. It then breaks the request to 'http://go.microsoft.com/?69157', and performs different work. I'll talk about this later in this blog.

It also sets a RegistryCallback function in the System Thread function by calling the API 'nt! CmRegisterCallback ', which is used to filter the registry calls in the driver level. Based on my analysis, this callback function is interested in the Microsoft Edge browser.

The driver 'iTranslatorSvc' also protects its subkey in the system registry from being accessed, i.e. 'HKLMSYSTEMCurrentControlSetservicesiTranslatorSvc'. When we access this subkey using the Registry Editor, it pops up an Error Messagebox, as shown in Figure 11.

Figure11. iTranslatorSvc subkey is protected by the driver

When 'winlogon.exe' Resumes Running

As I described above, when 'winlogon.exe' resumes running it loads the library 'C:WindowsSystem32iTranslator.dll', which was extracted from the driver 'iTranslatorSvc'. It's same process as previously described. This 'iTranslator.dll' in System32 folder is also protected by VMProtect v.2.07 packer.

Through my analysis, its main purpose is to load the module 'itranslator.dll' from the 'C:ProgramDataitranslator' folder, which is downloaded by the 'wintrans.exe' that I mentioned before. Later, it will try to upgrade the itranslator.dll from the C&C server if a new version is available, just as what 'wintrans.exe' does. So far, the latest version of this DLL file is 1.0.8.

The file naming system here can be confusing. There are two files with similar file names. One is extracted by the driver 'iTranslatorSvc' that is located at 'C:WindowsSystem32iTranslator.dll', and the other one is downloaded from the C&C server that is located at 'C:ProgramDataitranslatoritranslator.dll'. To classify them, I'll refer to the 'C:WindowsSystem32iTranslator.dll' as the 'extracted-iTranslator.dll', and the 'C:ProgramDataitranslatoritranslator.dll' as the 'downloaded-itranslator.dll' in rest of this blog.

The 'downloaded-itranslator.dll' is the main module of this malware, which could be loaded and can work in both 'wintrans.exe' and 'winlogon.exe'. In the 'winlogon.exe' process, the downloaded-itranslator.dll is loaded manually at memory address 0x10000000. According to the data defined in its PE structure, it corrects data to get it ready to execute. Finally, it calls the entry function of the downloaded-itranslator.dll. After doing this, the extracted-iTranslator.dll's work is done.

Starting the downloaded-itranslator.dll

It first obtains 'GUID' and 'MachineCode' through the driver 'iTranslatorSvc', and saves them into its global variables. In next step, it creates a thread performing the update of the C&C server URLs from a C&C server. By the way, this malware has multiple C&C servers used for different purposes. On 'hxxp://ask.excedese.xyz/', it holds two C&C server URLs. Figure 12 shows the packet content.

Figure12. Update C&C server URLs

The response packet contains two new URLs in JSON format. They are 'immereeako.info' and 'search.bulletiz.info', which are saved as two global variables for future communication with the C&C server.

As I said before, the downloaded-itranslator.dll file is a container whose Resource section contains many files. They are released into different local folders. The following table shows the files extracted from its Resource section.

Resource name	Extract to
'DRV'	'C:WindowsiNetfilterSvc'
'NSS'	'C:Windowsnsscertutil.exe' 'C:Windowsnssfreebl3.dll' 'C:Windowsnsslibnspr4.dll' 'C:Windowsnsslibplc4.dll' 'C:Windowsnsslibplds4.dll' 'C:Windowsnssnss3.dll' 'C:Windowsnssnssckbi.dll' 'C:Windowsnssnssdbm3.dll' 'C:Windowsnssnssutil3.dll' 'C:Windowsnsssmime3.dll' 'C:Windowsnsssoftokn3.dll' 'C:Windowsnsssqlite3.dll'

It also extracts the file 'C:WindowsSSLSample CA 2.cer' from its memory.

Man-in-the-Middle Attack

From my analysis, all of the extracted files serve as a Man-in-the-Middle Attack on the victim's system.

The file 'iNetfilterSvc' is another driver, whose name is 'NetfilterSvc'. It's actually an instance of a commercial project called NetFilter SDK. It is a framework for transparently filtering the data packets transmitted via the network on Windows. The extracted 'Sample CA 2.cer' is the root certificate that will be installed into Firefox and into Windows system for both IE and Chrome as their trusted Root Certification Authorities. This is necessary to perform Man-in-the-Middle attack secretly. This way, all certificates for SSL protected communication from victim's browsers are instead certificates signed by 'Sample CA 2.cer'. In this way, the browser won't warn the user since 'Sample CA 2.cer' is in the trusted Root Certificate Authorities list.

All files in 'C:Windowsnss' are used to control the Firefox browser. The file 'C:Windowsnsscertutil.exe' is used to install 'Sample CA 2.cer' into Firefox. Figure 13 shows what it looks when 'certutil.exe' starts in a debugger.

Figure13. 'certutil.exe' installs Sample CA 2.cer

And in Figure 14, you can see that 'Sample CA 2.cer' was installed into the trusted Root Authorities list of Mozilla Firefox and Microsoft IE.

Figure14. Sample CA 2.cer was installed in Mozilla Firefox and Microsoft IE.

The main purpose of the downloaded-itranslator.dll module is to extract the driver 'iNetfilterSvc', run it (BTW, the file 'C:WindowsiNetfilterSvc' is deleted immediately after it's loaded), then install 'Sample CA 2.cer', and communicate with the two drivers 'iTranslatorSvc' and 'NetfilterSvc'. This way, the malware is able to monitor the victim's activities on all major browsers.

It continues to create a device handle (using '\.CtrlSMNetfilterSvc') of the driver 'NetfilterSvc' to exchange data with it. It then registers related protocols to 'NetfilterSvc' so the driver can callback functions when data over registered protocols is captured. For more information about how the Netfilter SDK works, visit its official website. From Figure 15, you can see the code snippet that it registers on HTTP (port 80) and HTTPS (port 443).

Figure15. Registers filtered protocols to NetfilterSvc

Figure16. Code snippet in the protocol callback function

Do you remember that? When the victim starts IE, for example, the image loading callback function is called in the driver 'iTranslatorSvc'. It then appends 'http://go.microsoft.com/?69157' to IE's command line. IE sends an HTTP request packet, which is captured by the driver 'NetfilterSvc'. Meanwhile, the protocol callback function in the downloaded-itranslator.dll gets called. Figure 16 shows the code snippet in one callback function. It checks if the requested URL is the URL 'http://go.microsoft.com/?69157'. If so, it sends a notice packet to its C&C server and tells one browser to open.

Figure 17 is the captured notice packet in Fiddler. The request URL contains 'P002' and 'MachineCode'. The C&C server replies with 'Location: https://www.google.com', which is finally sent back to IE, where IE shows Google's website to the victim. The request URL 'http://go.microsoft.com/?69157' could not really be sent out from the victim's system.

Figure17. Notify the C&C server that one browser opens

For other requests from the browsers, including HTTP and HTTPS, through Man-in-the-Middle attack the malware can modify the packet content. It inserts a small piece of Javascript code at the end of every response packet. This Javascript code was generated early in the process and contains the C&C server URL and MachineCode. When the response is received by browsers, the inserted Javascript code will be executed in the browsers to do more malicious things. For now, the Javascript code only downloads other JS file from its C&C server. Figure 18 is the modified page source of 'https://www.google.com', which contains the inserted Javascript code at the end.

Figure18. Javascript code that was inserted into the google.com response

As you may have noticed, when the Javascript code runs it downloads 'hxxps://cdn.immereeako.info/pa.min.js' to run in the victim's browser.

I'm still working on analyzing the 'pa.min.js' file. I may post another blog if I can collect additional useful findings.

Unfortunately, my test machine did not install the Microsoft Edge browser, but I think the malware does the same with Microsoft Edge.

Infection Flow Chart

To better understand the whole infection process of the malware, I made a brief flow chart, as shown in Figure 19.

Figure19. Brief Infection Flow Chart

Solution

The FortiGuard Antivirus service has published the signature 'W32/Itranslator.FE45!tr' to detect the sample file. The URLs have also been detected as 'Malicious Websites' by FortiGuard Webfilter service.

How to remove this malware:

Restart and enter in safe mode, then take following steps:

1. Delete the file '%WINDIR%iTranslator'.
2. Delete the folders '%WINDIR%nss', '%WINDIR%SSL'.
3. Delete the file '%WINDIR%system32iTranslator.dll'.
4. Delete the folder '%ProgramData%itranslator'.
5. Delete the subkey 'HKLMSYSTEMCurrentControlSetservicesiTranslatorSvc'.
6. Delete the subkey 'HKLMSYSTEMCurrentControlSetservicesNetfilterSvc'.
7. Delete the 'Sample CA 2' certificate from all browsers.

IOC

URLs:

hxxp://s3.amazonaws.com/dl.itranslator.info/

hxxps://cdn.immereeako.info/pa.min.js

hxxp://tk.immereeako.info/in.php

hxxp://ask.excedese.xyz/i.php

hxxp://gl.immereeako.info/files/upgrade/32/iTranslator.dll

hxxp://dl.shalleeatt.info/ufiles/32x/iTranslator.dll

Sample SHA-256:

itranslator_02.exe

B73D436D7741F50D29764367CBECC4EE67412230FF0D66B7D1D0E4D26983824D

wintrans.exe

67B45AE63C4E995D3B26FE7E61554AD1A1537EEEE09AAB9409D5894C74C87D03

iTranslator (driver)

E2BD952812DB5A6BBC330CC5C9438FC57637760066B9012FC06A8E591A1667F3

downloaded-itranslator.dll (ver 1.0.7)

C4EDE5E84043AB1432319D74D7A0713225D276600220D0ED5AAEB0B4B7CE36CD

downloaded-itranslator.dll (ver 1.0.8)

873825400FFF2B398ABF397F5A913A45FBD181654F20FBBE7665C239B7A2E8F5

References:

Download our latest Fortinet Global Threat Landscape Report to find out more detail about recent threat landscape trends.

Sign up for our weekly FortiGuard Threat Brief.