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.
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.
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.
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.
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.
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.
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.
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.
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:
- Extract and loads a net filter driver
- Exchanges data with drivers
- Install its SSL certificate into browsers as trusted root certificates without the victim’s permission
- 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.
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 1st, 1970. “m=” is the victim’s network MAC address.
From this point I’ll explain what the malware does once the driver “iTranslatorSvc” starts during the victim’s Windows startup.
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.
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.
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.
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 “hxxp://go.microsoft.com/?69157” to its command line. This is done so that when the browser opens, it accesses “hxxp://go.microsoft.com/?69157” first. Figure 10 is the screenshot of IE when IE starts, whose command line has been appended with the URL “hxxp://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 “hxxp://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.
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.
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.
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.
It also extracts the file “C:WindowsSSLSample CA 2.cer” from its memory.
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.
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.
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).
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 “hxxp://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 “hxxp://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: hxxps://www.google.com”, which is finally sent back to IE, where IE shows Google’s website to the victim. The request URL “hxxp://go.microsoft.com/?69157” could not really be sent out from the victim’s system.
Unfortunately, my test machine did not install the Microsoft Edge browser, but I think the malware does the same with Microsoft Edge.
When the “hxxps://cdn.immereeako.info/pa.min.js” is loaded in victim’s browser, it sends its C&C server a HTTP request as follows:
As you might have noticed, in the request, it contains MachineCode and the data collected from victim’s browser including current URL that the victim’s visiting. In this case it’s “hxxps://www.facebook.com”.
“pacb_jlcmurby4cp95” in the URL is a randomly-named callback function that was generated in “pa.min.js”. It would be used by the C&C server side to send it back in the response packet. Below it’s one response packet.
To better understand the whole infection process of the malware, I made a brief flow chart, as shown in Figure 19.
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:
- Delete the file “%WINDIR%iTranslator”.
- Delete the folders “%WINDIR%nss”, “%WINDIR%SSL”.
- Delete the file “%WINDIR%system32iTranslator.dll”.
- Delete the folder “%ProgramData%itranslator”.
- Delete the subkey “HKLMSYSTEMCurrentControlSetservicesiTranslatorSvc”.
- Delete the subkey “HKLMSYSTEMCurrentControlSetservicesNetfilterSvc”.
- Delete the “Sample CA 2” certificate from all browsers.
downloaded-itranslator.dll (ver 1.0.7)
downloaded-itranslator.dll (ver 1.0.8)
NetFilter SDK: http://netfiltersdk.com/index.html
Man in the Middle Attack: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
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.
*** This is a Security Bloggers Network syndicated blog from Fortinet All Blogs authored by Fortinet All Blogs. Read the original post at: http://feedproxy.google.com/~r/fortinet/blogs/~3/XFhAc_8AI98/deep-analysis-of-driver-based-mitm-malware-itranslator.html