Recently, we have been receiving samples that use “decoys” to imitate what is to be expected from running a normal file. In this blog post, we will analyze one such sample that Fortinet detects as W32/Kryptik.CWXI!tr.
The sample uses an icon similar to Microsoft Word documents.
Figure 1. File icon used by the malware.
If our Windows Folder Options are set to “Hide extensions for known file types”, then we might not notice that the extension of this file is “scr”, which is associated with Windows screensavers but also indicates that the file is actually in an executable file format. This is most likely done to trick an unsuspecting user into thinking that the file is just a document.
Let's see what happens when we double-click it.
Figure 2. Opened RTF document.
A Rich Text Format document (RTF) opens. If the user thinks that the file is just a document, then this might not be considered strange, and the user might even dismiss this file as harmless.
Let's check if there's any network traffic...
Figure 3. Checking for network traffic.
But what happens if we wait...
Five minutes later...
Figure 4. Captured network traffic.
What if we wait even longer...
Figure 5. Ransom message from CTB-Locker.
We can see here that the malware just used an RTF file as a decoy, but has actually downloaded the CTB-Locker trojan into the user's system and executed it. At the time of analysis, this downloaded trojan can also be detected as W32/Kryptik.CWXI!tr.
As we have seen, the function of the malware is that of a typical downloader trojan (malware that downloads and runs another malware). In the next sections, we will take a look at its use of the decoy document and then its network traffic.
As we have mentioned earlier, the original malware file is in an executable file format – PE to be more exact. In the file's .rsrc section, we can see an unencrypted CAB file.
Figure 6. Unencrypted CAB file in the malware's resource section.
In the figure above, we can see the Microsoft Cabinet File (MSCF) header, as well as the original file name of the decoy document (uginv.rtf).
After copying this cabinet file to the user's Temporary folder, the malware extracts its contents then calls the ShellExecute API to open the extracted file.
Figure 7. Pseudocode to extract and open the decoy document.
One thing to note about the decoy document is that the Date Modified time is preserved inside the cabinet file, letting us estimate the time when it was packaged with the downloader.
Figure 8. A sample received on February 3rd, 2015 with a Date Modified time just 12 hours before.
For this sample, we can observe that it has been packaged very recently, having the decoy document's Date Modified time 12 to 24 hours before the time we received the sample for analysis.
What about the delays before the malicious activity begins?
In the code, we can see many calls to KERNEL32's Sleep API which pauses the current thread for a specified interval. Sleep can serve many purposes when used in malware code such as detecting if the malware is being run under a debugger, evading detection inside automated sandbox analysis tools, or simply just avoiding the user's suspicion. In this case, the downloader will sleep for 300000 milliseconds (five minutes) after opening the decoy document. To the unsuspecting user, they may think that the sample does nothing else but open an RTF document, but upon a more thorough analysis (or if you wait long enough), you can see that it does much more than that!
Figure 9. The five-minute sleep before starting any malicious activity.
After the initial five-minute sleep, the malicious activity begins as the downloader begins to query the hardcoded URLs to download the payload.
Figure 10. Hardcoded URLs inside the downloader.
The following table shows an example of the sequence of WinHttp API calls that are made:
Note that the malware chooses to use HTTPS for its internet queries. This makes it hard for intrusion prevention systems to monitor and analyze the encrypted traffic for malicious activity. With the option to ignore certificate errors (WINHTTP_OPTION_SECURITY_FLAGS = 0x3300), the HTTPS request will succeed even if it cannot verify or trust the host's CA certificate.
The compromised or malicious website does not always serve the payload requested by the downloader – most of the time, an HTTP 403 (Forbidden) response is received.
Figure 11. A Forbidden response returned from the malicious or compromised host.
To ensure the correct payload, the downloader does some validation on the data received. First, the size of the response must be at least 1024 bytes. Next, the second DWORD received must be equal to the number of bytes received in the response. If these two checks pass, the downloader begins to decrypt the data. Otherwise, the downloader will sleep before repeating the same steps on the next hardcoded URL. It is unknown how the host decides when to serve the malicious payload - it has been observed to serve the correct malicious payload sometimes immediately, but other times, forbidden responses are received for hours before the downloader is able to download what it wants.
When valid data is received, the data is decrypted using a stream cipher with a 128-bit key that is hardcoded in the downloader. Upon decryption, we can see a file with an MZ header in memory, which would indicate that the decrypted data is an executable file. The last validation is a CRC32 check to verify if the decrypted data is correct.
Figure 12. Decryption of the received data.
When all validation checks pass, the payload is written as an executable in the user's Temporary folder and then executed. After a Sleep of ten seconds, the downloader attempts to delete the downloaded file to remove any trace of the file being downloaded and ran.
Currently, the downloader is serving the ransomware CTB-Locker. However, this can change at any time as one of the benefits of employing a downloader in a malware campaign is the capability to switch the payload to another file such as a new undetected variant or a completely different malware.
This isn't the first time we have encountered this downloader. Variants with similar behavior have been detected since May 2014. Throughout its history, some of the observed differences include:
Use of a variety of different custom packers to obfuscate the code
Different values for the User-Agent in the HTTP request, e.g., Mozilla, Opera, and different Windows versions
Use of a variety of documents and images as decoy files
An executable (EXE) or a dynamic-link library (DLL) as the downloaded payload
The hardcoded URLs may be encrypted or in plain text
In this article we have analyzed malware that uses a decoy document to trick a user and to hide its malicious intent. However, a deeper analysis lets us see the true nature of the malware. We will continue to monitor for any changes to this downloader and provide the necessary detections to protect our customers.