Introduction

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.

Ichitaro 101

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.

Figure 2

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 SettingsAdministratorƒfƒXƒNƒgƒbƒvPROBLEMPrairie 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

Cryptanalysis to the Rescue

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

Deep Dive into the Payload

Once we reverse-engineered the logic of the payload we found many indicators of maliciousness, including:

• Trying to Achieve Persistence
• Retrieving and Launching Additional Payloads from the Internet

Figure 9 Overall Control Flow

Figure 10 Trying to Achieve Persistence

Figure 11 Persistence Achieved

Phoning Home

The malware also tried to reach out to a hardcoded domain. The algorithm is shown below:

Figure 12

The way the code is organized strongly indicated that this was a handcrafted assembly.

Figure 13

It turns out, the domain (usjj.wwwcrazy.com) only became alive very recently (11 /1/2017!)

Figure 14

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 16

Figure 17 Lookup Table

Figure 18

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.

Solution

1. FortiGuard Antivirus service detects samples as the following:
   • 1363623174d369a06314a9e21358a23d W32/Small.CNK!tr.bdr
   • 0e244d9b3b06a60dce6f986e56a766a4 W32/Ichitaro_Tarodrop.I!tr
   • 4df28492ee6cfd3d24fc74f1a025e0d3 W32/Ichitaro_Tarodrop.I!tr
2. FortiGuard Webfilter service blocks and tags all downloaded URLs as malicious.
3. JustSystems Ichitaro users are urged to patch to the latest version to block exploitation in the first place.

Conclusion

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 =-

IOC

Samples:

1363623174d369a06314a9e21358a23d W32/Small.CNK!tr.bdr

0e244d9b3b06a60dce6f986e56a766a4 W32/Ichitaro_Tarodrop.I!tr

4df28492ee6cfd3d24fc74f1a025e0d3 W32/Ichitaro_Tarodrop.I!tr

URL:

usjj.wwwcrazy.com

Sign up for our weekly FortiGuard intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.