해외 악성파일

완전 재밌는 샘플 분석중 아래는 외국 분석 정보이며 이를 토대로 분석하고있어요~ㅎ

출처 : http://blog.9bplus.com/demystifying-zfkeymonitorexe

Demystifying zfkeymonitor.exe

Thanks to Binjo for the translation help and Nick Bloor for assisting with testing and analyzing zfkeymonitor.exe. 

A couple weeks back I did a write-up on one of the CVE-2011-2462 files that used AESV3 and dropped zfkeymonitor.exe (3765ea5a84df0240f550648a512205fd) along with svchost.exe (5d8d3373f1ded2ee3c0edf9e4dbf117a) and a couple DLLs. At the time it was unclear what role, if any, zfkeymonitor played in the exploit, but more importantly, it was unclear what this exe was or where it came from.

Below is a detailed technical analysis of the files dropped on the system, how they work together and a bit about the malware itself. In between the analysis will be some information on zfkeymonitor and a bit of background behind the file and its true use. 

After executing the PDF file, svchost.exe is dropped on the system and executed. If we disassemble and view the imports and strings a couple details stick out. Specifically the use of WinRar in the executable and the call made to ShellExecuteExW.

Debugging the EXE reveals that WinRar is packed within the binary and used to extract an archive to "C:\Program Files\Common Files\release". This archive contains data that will eventually be used by several other DLLs and processes. 

Within ShellExecute, a new thread is spawned and a malicious rundll32.exe is ran as a child process. Before diving into this malware, it is important to quickly go over the contents of the “release” folder. Located within this directory are several DAT, and DLL files with the addition of a single INI file. 

DAT files are typically application specific and if we open these up an any editor the contents reveal nothing to us. The INI file however uses base64 encoding to mask some of the parameters. Decoding these values reveals the command and control IP address observed when infecting the virtual machine. 

This INI file is later loaded from a hidden DLL, but even without knowing this, replacing the C2 IP address with our own testing server reveals that this file dictates the primary C2 node. 

Having the malware connect back to our lab machines also reveals what would have been sent to the attacker. This information includes the computer name, processor information, RAM and a few other details.

Keeping the DAT files in mind, but moving on, we can begin to debug rundll32.dll . Out of all the routines within the DLL, a few standout given their reading of the DAT files and mentioning of yet another EXE file to be executed (this time with WinExec). Identifying the use of the DAT files is important, but IDA doesn’t show which DAT file is being called upon in each of the routines.

If we load the DLL into Immunity Debugger and call the “Execute” function then we can traverse through the code until we get to the proper subroutine. From the stack it is easy to see that “zblock” files are being loaded first using CreateFileA with generic read access and read into a buffer using fopen. 

When stepping through the code in the debugger it is obvious that each loaded file is being ran through an XOR routine with the key of 0x05. Each zblock#.dat file is read into memory, XORed and then put all together. Once these files are put together, WriteFile is called and “zfkeymonitor.exe” is created before being executed.

To validate this, a simple script was used to manually XOR the DAT files using the 0x05 key. It is worth noting that zfkeymonitor.exe is a signed executable whos author appears to be Shandong Zhongfu Information Industry Inc.

zfkeymonitor.exe is called with no arguments and loads zfulib.dll (874416bb1e8327b59b58c790d7888f9c) into memory. Before stepping onto the next DLL, it is worth spending some time on zfkeymonitor as little search results turn up on the EXE itself. Within the digital certificate we can see who signed the executable, but it is unclear whether or not this file is malicious. 

Several Chinese websites turn up little documentation on the file, but do reveal some interesting details. A doc file downloaded from sjdw.gov.cn isn’t much of a help until we load it into Google Docs. Doing so accurately interprets the character set which we can then copy and paste into Google Translator to get a general idea of what’s going on.

This document identifies that zfkeymonitor is used to manage and handle digital certificates. In order to procure drug products in the Shandong Province, one must request a certificate in order to authenticate with the access portal. zfkeymonitor helps facilitate this process and appears to have a legitimate use. 

Further digging reveals a site in which you can actually download the program yourself and run it. Running the binary reveals an application that doesn't do much of anything, but does prove that the zfkeymonitor dropped by the malware may be something worth looking into more. After running several tests it was observed that the version downloaded from the Chinese websites appeared to be of build 1.x whereas our dropped file was up to version 3.x. 

Also, the file downloaded included CertReg.exe and was not signed like the one dropped by the malware. Loading both into IDA did not reveal anything suspicious, but our file also shipped with its own zfulib.dll. 

Upon further inspection, the dropped zfulib DLL performed the same XOR operation on the set of iblock#.dat files therefore mapping yet another DLL into memory. Running the XOR script against the iblock.dat files provides the same DLL that we could then load into IDA. This DLL was very small and appeared to function as a loader and persistence mechanism for the final malware to be executed. 

It should be noted that executing the zfkeymonitor.exe binaries in several scenarios eventually revealed that the dropped zfkeymonitor would run properly even with the older versions DLL. However, when using the older version of the DLL, DAT files were not read by the process and remained ignored.

It appears that zfkeymonitor was used in this attack not for its digital certificate functionality, but instead because of its signed status. Having a signed executable means you have more privileges and access to run on the system. The DLL pulled in by the signed process allowed the malware to bypass certain UAC controls put in place by later releases of Windows. The following link reveals more information about this abuse.

After understanding the order of execution, the last and final set of DAT files were decrypted by rundll32.dll using the same 0x05 key revealing the main malware. This file was another DLL that handled the outbound connections, command interface and cleanup of some of the dropped files that were written to the system. 

After walking through several of the subroutines that branch from the main switching cases, the following functionality appears to be present.

• spawn command shell
• restart the host
• shutdown the host
• uninstall all files from the host
• capture user screens
• record and transmit video
• record keyboard events

When transmitting back to the C2, it appears that the malware writes to HostID.dat as a temporary location to store the data and then deletes the file. 

At present, the only vendor to mention or even try to associate this dropper to a class of malware is Microsoft. Unfortunately, they classify this entire threat as "zfkeymonitor" which does not appear accurate.

Summary

Dropped files on the system:

• scvhost.exe (core dropper)
• DAT files (used to construct EXE and DLLs)
• zfulib.dll (deleted)
• zfulibblock.dll (failed to delete)
• ini.ini (main configuration)
• exit.log (never used)
• zfkeymonitor.exe (deleted)
• clean PDF document
• rundll32.dll

DAT files are XOR encoded using 0x05 as the key and decode to reveal the following:

• zblock - zfkeymonitor.exe
• iblock - install.dll (registry settings and loading)
• mblock - mydll.dll (malware functionality)

Command and Control

• 69.197.132.130
• Windows Server 2003 Enterprise Edition (Chinese language pack)