In March 2020 specialists from the PT Expert Security Center conducted an analysis on the activities of the APT group Higaisa. This group was first studied by security analysts at Tencent in November 2019. In that analysis, Tencent specialists reached the conclusion that Higaisa has its origins in South Korea. The group, which is still active today, can be tracked all the way back to 2009. According to the Tencent analysis, Higaisa's main targets have been government, public, and trade organizations in North Korea; however, they have also carried out attacks in China, Japan, Russia, Poland, and other nations.

Higaisa distributes messages containing real news and information on current events to initially spread their malware. They have also used messages containing seasonal greetings, which congratulate their recipients on holidays such as New Year, the Chinese Lantern Festival, and North Korean national holidays. In most cases the messages are written in English, implying that English-speaking countries could also be targets.

With the recent prevalence of the coronavirus (COVID-19) pandemic, many APT groups, including Gamaredon, SongXY, TA428, Lazarus, Konni, and Winnti, have been using the topic of COVID-19 in their email distributions. Higaisa is no exception.

This article is an investigation into one of the malicious files created by Higaisa. The file was discovered by security experts on March 11 while conducting another study on information security threats. The file is also compared with earlier files, and observed changes are noted and analyzed.

Object #1: File 20200308-sitrep-48-covid-19.pdf.lnk

Stage 1. Shortcut

The malware originates from a file called 20200308-sitrep-48-covid-19.pdf.lnk, which is concealed as a PDF file.

The file is a .lnk shortcut with the icon of a PDF document. When opened, the command cmd.exe /c is executed with the following command string (note: line breaks and spaces have been added for readability):

As a result, copies of the shortcut and a file called C:\Windows\System32\CertUtil.exe (under the name of msoia.exe) are placed into a temporary folder. Instead of directly using the name CertUtil.exe, the file mask *ertu*.exe and the for command are used to conduct search, bypassing filename signatures.

By launching findstr.exe, the Base64-encoded payload at the end of the LNK file is retrieved and then decoded using CertUtil.exe (msioa.exe).

Stage 2. Archive

The decoding results in a CAB archive, which is unpacked into the same %tmp% folder and contains the following files:

• 3UDBUTNY7YstRc.tmp (DLL, used for autorun)
• 9sOXN6Ltf0afe7.js (installation script)
• 486AULMsOPmf6W.tmp (a legitimate executable file used for autorun)
• 20200308-sitrep-48-covid-19.pdf (the original WHO report, used as bait)
• cSi1r0uywDNvDu.tmp (XSL; contains part of the installation code written in VBScript)
• MiZl5xsDRylf0W.tmp (installer payload)

After the files have been retrieved, the malware moves to the next stage in the process of achieving persistence in the system, launching the file 9sOXN6Ltf0afe7.js.

Stage 3. JS script. Part one.

The script is written as one line:

In effect, the script executes the following console commands:

A folder with the name cscript.exe is created in the temporary folder called %tmp%. The original script interpreter, cscript.exe, is then copied into this folder with the name msproof.exe. An XSL file by the name of WsmPty.xsl is copied in as well. This is what the XSL file looks like:

A legitimate script, %windir%\System32\winrm.vbs (a console tool for work with the Windows Remote Management API), is launched using the interpreter. It is then passed the command get wmicimv2/Win32_Process?Handle=4 and the output format: format:pretty.

When this format is specified, winrm.vbs is pulled from the directory where the interpreter cscript.exe and the file WsmPty.xsl are located. winrm.vbs is used to format the command output (regardless of whether it was successfully executed). This will then run the VBScript code embedded in the file.

This method, described by Matt Graeber in 2018, bypasses application whitelisting restrictions to run unauthorized code. There is one essential condition for winrm.vbs to work—the string cscript.exe must be present in the path to the interpreter. This is why the folder that it is copied into is created with this particular name.

Stage 4. XSL

The VBScript code that is launched contains a hex string and code that are responsible for decoding and executing the file. Here you can see the code with all hex strings converted into bytes and deobfuscated variable names:

Essentially, what the code does is create a file called OFFICE12 in the user profile, as well as a shortcut called Accessories.lnk in the startup directory. The shortcut does not directly launch the payload, instead using the function FileProtocolHandler from the url.dll library:

C:\Windows\System32\rundll32.exe C:\Windows\system32\url.dll,FileProtocolHandler %UserProfile%\OFFICE12\MSOStyle.exe

Additionally, a file called 2m7EBxdH3wHwBO.tmp is created in %tmp% via the function Write4D5A90. This file contains three bytes from the beginning of an EXE file: 0x4D, 0x5A, 0x90.

Stage 3. JS script. Continuation

Once the VBScript in XSL has been run, console commands launched by the JS code continue to be executed. Three files are copied into the folder OFFICE12 that was created in the user profile. Those files are:

• MSOSTYLE.EXE
• OINFO12.OCX
• Wordcnvpxy.exe

The last file, which is the payload, is built from the three-byte introductory string created by VBScript and from MiZl5xsDRylf0W.tmp, which was unpacked earlier. The result is a valid .exe file.

MSOSTYLE.EXE is a legitimate file from the Microsoft Office 2007 package. It is responsible for sideloading the dynamic link library OINFO12.OCX.

OINFO12.OCX contains the code for executing the final payload:

It also contains code in exported functions that is not actually run (we suspect that this is part of an attempt to avoid detection in sandbox environments):

The last step in the script is to open the PDF file that was used as bait.

Wordcnvpxy.exe downloader

The payload is an application that creates a hidden window (the name of the class and the window is SK_Parasite).

Essential functions are loaded dynamically. Base64 with the following non-standard alphabet is used to decode library names: z2bqw7k90rJYALIQUxZK%sO=hd5C4piVMFlaRucWy31GTNH-mED8fnXtPvSojeB6g. Instead of using function names, their hashes are used, using SuperFastHash algorithm.

The main code is run in a separate thread: every 10 minutes, the application contacts the C&C server motivation[.]neighboring[.]site and passes it the computer's identifier in the User-Agent string. The identifier is a SuperFastHash of the system volume serial number and the name of the computer.

The response from the server is saved into a temporary file. If the response contains at least 10 bytes, it is decoded from Base64 and divided into two segments separated by the symbol $. The first segment contains the RC4-encoded executable file, and the second contains its filename without an extension.

The method used to construct a key for decoding the RC4 encryption is interesting. It is generated via a recurrent sequence that begins with two numbers (28 and 39), and every subsequent number equals the sum of the previous two, mod 255. The key consists of 64 bytes and begins with the first sum in the sequence. The key is later expanded to 256 bytes (by looping) and is used in the standard RC4 algorithm.

The executable file received from the server is saved in %TEMP% with the specified name and is then launched.

Object #2: 邀请函.doc (Invitation card.doc)

This is an RTF file containing a congratulatory statement:

The document was created using the popular builder 'Royal Road RTF' (also known as 8.t), which exploits the CVE-2018-0798 vulnerability in Microsoft Equation Editor. This builder is not publicly accessible, but is widely used by Chinese APT groups, including TA428, Goblin Panda, IceFog, and SongXY. The name '8.t' originates from the fact that the malware creates a file called 8.t containing the encoded payload in a temporary folder.

Exploitation results in the creation of a file called %APPDATA%\microsoft\word\startup\intel.wll. This file is a DLL dropper, which is loaded the next time Microsoft Word is launched. Its payload consists of two files: %ALLUSERSPROFILE%\TotalSecurity\360ShellPro.exe and %ALLUSERSPROFILE \TotalSecurity\utils\FileSmasher.exe. The files are encoded using xor 0x1A.

The dropper achieves persistence in the system by creating a shortcut in the startup directory that launches %ALLUSERSPROFILE%\TotalSecurity\360ShellPro.exe with key /func=5. This file is a modified component of the antivirus tool 360 Total Security, and is used to transfer control to the downloader FileSmasher.exe via a method similar to DLL side-loading.

The legitimate 360ShellPro.exe file contains a number of relative paths to the executable file. The correct file is selected and launched depending on the value of the argument /func=.

FileSmasher.exe downloader

In many ways, FileSmasher.exe resembles Wordcnvpxy.exe. It is also a windowed application (class name: NIS_K). However, in this case, the relevant code is launched using a 10-minute timer, not a separate thread.

Dynamic DLL loading is not used (all imports are static) and the address of the C&C server is restored using a similar RC4 decoding function (instead of decoding from Base64 with a nonstandard alphabet). However, the initial elements in the series used to generate the key have different values (8 and 5), and the generative algorithm is fully repeated.

The CRC32 from the system volume serial number is used as an infected machine identifier. It is passed explicitly as a GET parameter. The following is the full address that the downloader uses to access the server: http://walker[.]shopbopstar[.]top/blog/index.php?ei={32 random chars}&ti={volume serial CRC32}

The loading algorithm is practically identical:

• The server response is saved in a temporary file and is processed only if it contains at least 10 bytes.
• In contrast to Wordcnvpxy.exe, there is no Base64 decoding.
• The response is divided into two parts using an ampersand (&) instead of a dollar sign ($).
• The first segment is also an executable file encrypted with RC4, and the second part is its name without an extension.
• The file is decoded using the same function that is responsible for decoding the address (the RC4 key parameters are 8 and 5).

The loaded file is launched using CreateProcess.

It is worth noting that the resource files for Wordcnvpxy.exe and FileSmasher.exe include a dialogue window, "About," containing the application's name and copyright information.

This window as well as other resources (Menu, Accelerators) are generated by Visual Studio when the project is created. In the case of Wordcnvpxy.exe, the application name indicated in the dialogue window matches the name of the window's class (SK_Parasite). However, this is not the case for FileSmasher.exe. Here, the application is called AttackBot, and in its case we see the abbreviation NIS, which we saw earlier in the name of the window class (NIS_K).

Experts at Tencent drew a connection between Higaisa and the Republic of Korea and identified its main targets as North Korean government and trade organizations. This suggests that NIS could stand for National Intelligence Service (The National Intelligence Service of the Republic of Korea). SK_Parasite could be a reference to the South Korean film Parasite (released in 2019). Alone, these data are insufficient to draw firm conclusions; however, they can be seen as circumstantial evidence for a connection with South Korea.

Related objects

The contents of the initial document (New Year greetings) and the date the file was created (22.12.2019) specify the period during which it was used. However, it is not the only object of its kind. Analysts at Tencent identified another distribution of malicious files during the same period. In that case the filenames were Happy-new-year-2020.scr and 2020-New-Year-Wishes-For-You.scr. These files are executable and use a congratulatory JPG file as bait. The image is dropped from an executable file and opened in the default viewer.

Other than the exploitation of the CVE-2018-0798 vulnerability, the structure of these threats is effectively identical to the RTF document. SCR files are droppers whose payload is decrypted using xor 0x1A and unpacked into the subdirectory of %ALLUSERSPROFILE%.

The payload consists of a legitimate executable file (rekeywiz.exe from Windows 7 is used) and the DLL downloader Duser.dll. The legitimate file is added to startup using a shortcut.

The downloader decrypts the URL using RC4 (the initial values are 8, 5 and 9, 5) and adds a random string and the CRC32 computer identifier into the GET parameter.

The downloader instance unpacked from 2020-New-Year-Wishes-For-You.scr to establish a connection with the C&C server uses a statically linked libcurl library. The other instance uses statically imported functions from the winhttp.dll library, just like FileSmasher.exe.

The server is accessed at the following addresses: http://adobeinfo[.]shopbopstar[.]top/notice/index.php and http://petuity[.]shopbopstar[.]top/research/index.php.

In both cases data is received from the server in the same format as in FileSmasher.exe.

Regardless of the fact that neither of the droppers that we have described actually create any windows, they do contain a standard set of window resources, including the "About" dialogue window. The strings "K_NIS" and "KISA" are used as application names.

C&C server responses

Two types of components were used as the payloads distributed by the C&C server:

• The system information collector (InfoStealer), which essentially provides the function of running the console command systeminfo & ipconfig -all & tasklist & net view & dir c:\ & dir c:\users\ & dir d:\ & dir e:\ and relays the response to the command server.
• Gh0st RAT in a variety of modified forms, particularly with all essential functionality implemented in DLL plug-ins loaded from the C&C server.

These instances of Gh0st RAT are interesting when compared with the publicly accessible source code, as they implement a non-standard encryption of incoming and outgoing data. In packets containing less than 10 payload bytes (not including the header), the first 10 bytes are processed with a 0x12 xor key. The bytes 0x0 and 0x12 are left unchanged. Data are compressed with LZO instead of zlib.

In addition, the m_bPacketFlag field (the signature of packets sent to the command sever) is initialized with a pseudorandom value calculated using the value returned from calling GetTickCount(). In the original code, the field is equal to Gh0st.

Conclusion

The results of our study demonstrate how the malicious objects used by the Higaisa group have evolved over time. Beginning with a simple distribution of executable files, they shifted towards utilizing exploits and complex multi-stage threats. However, the structure of their tools (such as droppers and downloaders) remained largely unchanged. To deter detection, the attackers modified details such as the control server URL, RC4 key parameters, the legitimate files used for DLL side-loading, and the libraries used for HTTP interaction.

Author: Alexey Zakharov, Positive Technologies

IOCs

motivation[.]neighboring[.]site

walker[.]shopbopstar[.]top