Here at Fortinet Labs we continually track phishing and spam campaigns around the world. Beside the usual global attack vectors, such as Office documents with executable files (e.g. exe, dll, MachO so on), we also track local markets and their respective attack vectors. For example, in the past we have conducted research and warned customer about attacks involving regional tools such as Hancom Office and JustSystems Ichitaro.
Recently, we came across some interesting samples in jtd format, which is the file format used by JustSystems Ichitaro. The following is a quick primer for readers who are unfamiliar with the Japanese market.
Ichitaro is one of the most popular word processors in Japan. There have been many attempts to exploit JustSystems Ichitaro in the past, but these most recent samples are interesting in their own ways. But before taking a deep dive into the nitty gritty details we feel compelled to give fair warning: all new details are actively unfolding (in fact, one of the malware domains just emerged on 11/1!), but due to the urgent nature of the malware campaign we feel it is necessary to provide early warning of this unknown threat vector. As a result, information from our report may be incomplete or may change quickly over time.
JustSystems Ichitaro uses jtd format, which in a nutshell is an OLE2 compound file format. A thorough discussion of this subject matter is out of the scope of this blog post, but we can summarize some of the key details. Jtd format is a Compound File Binary (CFB) format, which is also known as an Object Linking and Embedding (OLE) format. CFB files essentially contain a file system (closely related to FAT) within a file. The file system holds storages (akin to directories in a regular file system), which themselves contain other storages and streams (akin to files). Data is stored in chains of sectors (usually 512 bytes long), which are chained in the file allocation table (FAT). Figure 1 depicts a jtd file (which also happens to be the focus of our deep dive analysis.)
Figure 1 A Jtd File
As can be seen, the directory structure clearly shows the sizes of the streams. What is rather unusual about this sample is the fact that the total sum of the sizes is only 12229 bytes, but the actual file size is much bigger (613376 bytes), meaning something else is embedded inside the file.
This tipped us off, and we began the hunt for similar samples. As of this writing, we have found 10 (perhaps more will show up in the future.)
The first thing we wanted to learn was what would happen when we detonated the sample inside our test environment. Our hypothesis was that these samples exploit vulnerabilities (even zero day) in Ichitaro. After all, a similar attempt had been made in the past. But lo and behold, nothing happened. All we got was a blank frame.
Figure 3 Blank Frame
Deeper investigation found that this blank frame linked to a bmp image with a local path (I:\Documents and Settings\Administrator\ƒfƒXƒNƒgƒbƒv\PROBLEM\Prairie Wind.bmp) that is not in our machine.
All experiments so far seem to indicate that these vulnerabilities have been patched in the latest version of Ichitaro. We tried to obtain older versions of Ichitaro to verify our hypothesis, but to our dismay JustSystems only provides the latest version.
Figure 4 Latest Version Dated 2017/10/24
Not to be deterred, we decided to go the extra mile and dig deeper. Since we could not observe the entire kill chain and detonation, we decided to guess to brute-force the key and decrypt the payload. After all, our gut feeling told that the threat actor may have been lazy and used an easy encryption scheme like xor or similar variants, just as with many incidents in the past, which would make brute-forcing the payload in a realistic timeframe possible, unlike with an advanced encryption scheme such as AES or Blowfish.
We turned to a tried and true tool: Cryptam Document Scanner. Sure enough, the tool figured out the key length and from there, the value of the xor key itself, which is 0xD6, along with some encryption parameters:
Zero space not replaced: yes
Bitwise not: yes
Figure 5 Visualization of the key length (1 byte)
The results are rather interesting, and demonstrated nicely in figures 5 and 6. A thorough discussion of cryptanalysis is out of the scope of this work, but one quick hint of how to read the graph is to take note of how close each column of the chart is (1 byte) vs if the encryption key was longer (32 bytes). We can clearly see the cyclic nature of this clear encryption scheme in the graphs.
Figure 6 Visualization of the key length (32 bytes)
A summary of our cryptanalysis of the suspect documents is below:
Figure 7 Summary of Cryptanalysis
We managed to extract and decrypt all of the payloads, but due to various reasons most do not detonate. In the end, only 2 Jtd documents yielded valid executable payloads, which happen to be the same file. In the following sections we dedicate our analysis to that payload.
Figure 8 Decrypted Payload
Once we reverse-engineered the logic of the payload we found many indicators of maliciousness, including:
Figure 9 Overall Control Flow
Figure 10 Trying to Achieve Persistence
Figure 11 Persistence Achieved
The malware also tried to reach out to a hardcoded domain. The algorithm is shown below:
The way the code is organized strongly indicated that this was a handcrafted assembly.
It turns out, the domain (usjj.wwwcrazy.com) only became alive very recently (11 /1/2017!)
The next thing the malware does is try to retrieve and launch additional payloads from the Internet. The payload (if any) is encrypted. The decoder for the encrypted payload is inside the mtr_Launch() function. Once again, it is a custom encryption scheme.
Figure 15 Decoder
Based on a flag, one of the 3 decoders will be used. Each decoder is similar to the following xor-based algorithm using a lookup table.
Figure 17 Lookup Table
We have been monitoring the domain and communications, but nothing interesting has happened yet. Without an active payload, all the current malware does is attempt to remain persistent and try to connect outside again and again.
Currently, the samples we reviewed do no harm, but there is potential should a malicious payload be developed. When such a payload is available we plan to use code reuse techniques in order to have the malware decode the new payload for us. From there we can gain additional insights into this ongoing malware campaign.
As always, FortiGuard Labs will keep an eye on novel threats like this and keep everybody updated.
Great thanks to the Kadena team for additional support in preparing the manuscript.
-= FortiGuard Lion Team =-