# COVID-19 and New Year greetings: an investigation into the tools and methods used by the Higaisa group

**[ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/covid-19-and-new-year-greetings-the-higaisa-group/](https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/covid-19-and-new-year-greetings-the-higaisa-group/)**

Positive Technologies

Published on 4 June 2020

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](https://s.tencent.com/research/report/836.html)
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


-----

Figure 1. PDF document containing a World Health Organization (WHO) report

### Stage 1. Shortcut

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

Figure 2. Contents of the LNK

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):


-----

Figure 3. The command string executed

by the shortcut
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)](https://www.who.int/docs/default-source/coronaviruse/situation-reports/20200308-sitrep-48-covid-19.pdf)
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:

Figure 4. A fragment of the code from

9sOXN6Ltf0afe7.js
In effect, the script executes the following console commands:

Figure 5. Console commands in 9sOXN6Ltf0afe7.js
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:

Figure 6. A fragment

of the code in WsmPty.xsl
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.


-----

e t s o at s spec ed, _bs s pu ed_ o t e d ecto y e e t e te p ete csc pt e e a d t e e _s_ _ty s a e ocated_
_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](https://posts.specterops.io/application-whitelisting-bypass-and-arbitrary-unsigned-code-execution-technique-in-winrm-vbs-c8c24fb40404)
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:

Figure 7. Deobfuscated VBScript

code
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:


-----

Figure 8. Launching Wordcnvpxy.exe in DllMain

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):

Figure 9. The code of GetOfficeData() Figure 10. The code of

DeleteOfficeData()
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).

Figure 11.

Window creation and event processing loop in Wordcnvpxy.exe
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.](http://www.azillionmonkeys.com/qed/hash.html)


-----

Figure 12. Dynamically loaded libraries

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.

Figure 13. Main downloader cycle
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.

Figure 14. Processing the server response

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.


-----

Figure 15. Generation of the RC4 key in Wordcnvpxy.exe

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:

Figure

16. Document with holiday greetings
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,](https://malpedia.caad.fkie.fraunhofer.de/details/win.8t_dropper)
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](https://www.ptsecurity.com/ww-en/analytics/cybersecurity-threatscape-q4-2017/)
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._


-----

Figure 17. The main

function in the intel.wll dropper (fragment)
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=.

Figure 18. File selection based on the func parameter

### 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.


-----

Figure 19. Window creation,

timer set-up, and event processing loop in FileSmasher.exe
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.

Figure 20. RC4 key generation in FileSmasher.exe

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}_

Figure 21. Construction of a URL to

access the monitoring server, from FileSmasher.exe
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.


-----

Figure 22. The

"About" dialogue window from the resources included in FileSmasher.exe
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](https://en.wikipedia.org/wiki/Parasite_(2019_film))
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.](https://s.tencent.com/research/report/895.html)
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.


-----

Figure 23. The image contained in Happy-new-year-2020.scr

Figure 24. The image contained in 2020
New-Year-Wishes-For-You.scr
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%.


-----

Figure 25. The main function in 2020-New-Year
Wishes-For-You.scr dropper (fragment)
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.

Figure 26. Construction of a URL to access the

control server, from Duser.dll (2020-New-Year-Wishes-For-You.scr dropper)
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:


-----

e syste o at o co ecto ( oStea e ), c esse t a y p o des t e u ct o o u g t e co so e co a d syste _o &_
_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.

Figure 27. Decompiled code of the function

CClientSocket::OnRead
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.

Figure 28. Initialization of the field CClientSocket::m_bPacketFlag

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

**Filename** **MD5** **SHA-1** **SHA-256**


20200308-sitrep-48covid-19.pdf.lnk


21a51a834372ab11fba72fb865d6830e 9ceb6e0e4ad0a2c03751d0563a82a79ebb94ec95 95489af84596a21b6fcc


oGhPGUDC03tURV.tmp 37f78b1ad43959a788162f560bdc9c79 992d530d4bb35fb8dbdfb690740ead6e0fa974ec f74199f59533fbbe57f0b

OINFO12.OCX 83d04f21515c7e6316f9cd0bb393a118 e00b982a14835dae781bbbe06055d7d18acc6eb0 a49133ed68bebb66412

9sOXN6Ltf0afe7.js 4f8ff5e70647dbc5d91326346c393729 2fd4eb78e53af6a5b210943ca8f0e521bb567afb 70b8397f87e4a0d235d

MSOSTYLE.EXE 371e896d818784934bd1456296b99cbe 88f23b0913ef5f94cd888605504e1e54c3a6e48f 604679789c46a01aa32


20200308-sitrep-48covid-19.pdf


faf5ef01f4a9bf2aba7ede67dcc5a2d4 4e0c1a05360c6bebf903a708acf6792b13f43870 2dd886cc041ea6e5e80


cSi1r0uywDNvDu.tmp eefeb76d26338e09958aae5d81479178 c400e10a8f2b5b62f919033e2db0a1f99b1a3c38 9d52d8f10673518cb9f1

MiZl5xsDRylf0W.tmp c1d8966fa1bd7aee41b2c4ad731407d3 6e7e3277801669f3053bf364ae6be89f00017c89 b578a237587054f351f7


-----

**Filename** **MD5** **SHA-1** **SHA-256**

Wordcnvpxy.exe fd648c3b7495abbe86b850587e2e5431 d0e0d641f3a063fb02c7f862ea8586312af5fa2e 002c9e0578a8b76f626e

**Filename** **MD5** **SHA-1** **SHA-256**

邀请函.doc 2123bf482c9c80cb1896ff9288ad7d60 ea02db9b92cbf1d243b502d130aa2dd6c98637d2 500b6037ddb5efff0dd91f75b22c

intel.wll 59a55c7bbc0ee488ec9e2cf50b792a56 a29ce0331015f2a3e87fd7fe1ce9dae228808b59 1b978324df504451c2a3430e32d

360ShellPro.exe d5e42cc18906f09d5bab62df45b5fcf6 46833928f75db90220451e026997d039730906fa 1acd3cbc83dd4153f07b869b314

FileSmasher.exe ea628fef3b547a1476d915963415e64c 07dbfaa430a201ce81f5079dd1e48379fac27177 f2c60274e625bcb051909797b35

motivation[.]neighboring[.]site

walker[.]shopbopstar[.]top


-----