// Introduction

Lazarus (aka APT38 / Hidden Cobra / Stardust Chollima) is one of the more prolific threat actors in the APT panorama. Since 2009, the group leveraged its capability in order to target and compromise a wide range of targets; Over the time, the main victims have been government and defense institutions, organizations operating in the energy and petrochemical sector in addition to those operating in financial and banking one.

The group has also a wide range of tools at its disposal; among these, it’s possible to catalog [D] DoS botnets, first stage implanters, remote access tools (RATs), keyloggers and wipers. This list of malicious tools has over time supported a series of operations that have ranged from espionage to funding up to sabotage.

This specific blog post is related to a recent operation most likely carried out by this group and directed towards targets located in different parts of the world. However, our analysis started from a single malicious e-mail delivered against an important Italian institution operating in the banking and financial sector.

Starting from this email, we traced back the moves of the actor up to obtaining an excellent degree of visibility on what was going on.

However, in this intervention, we will describe only the first phase of the kill chain; Here, the threat actor provides two types of first stage payloads based on the architecture of the victim’s system. These payloads are used in order to carry out a first recognition phase. Afterward, some features of the remote script that is used for managing and controlling victims will be explored. Further information about this campaign are available for our threat intelligence portal customers by referring to the investigation ATR:78456.

// Vector

The threat actor, in this case, relied on a spoofed e-mail message (coming from e_banking@victim_name_domain_name) in order to deliver to the victims a message with a malicious Microsoft Office Word document attached. One of these retrieved documents refers to an alleged vacant job position for the Hindustan Aeronautics company.

The malicious document has two separate first-stage doubly base64 encoded payloads included within it (one for 32 and one for 64-bit systems) in addition to another doubly encoded base64 word document that is designed to be shown to the user.

An example of one of these payloads is shown as follows:

Once the macro is executed, the first infection process is started using the AutoOpen Sub. Variables dllPath and docPath are filled calling respectively the functions GetDllName() and GetDocName() in order to retrieve the paths from where they will be loaded later. For the first stage, it is as follows:

%USERPROFILE%”\AppData\Local\Microsoft\ThumbNail\thumnail.db

A subsequent LoadLibraryA loads dropped dll. A variable named “a” is then filled with the results of the so-called ShowState function within the content of an active opened document.

These instructions result in executing the dropped library.

// First run and persistence

The ShowState function has mainly the task of recovering the current execution path, starting the SetupWorkStation function in the same module context and ensuring persistence in the affected system.

It is interesting to note how the functions CoInitialize and CoCreateIstance are used respectively to initialize the COM library and to instantiate the COM object.

However, in order to understand which object is being instantiated, the first argument to the CoCreateInstance() function must be inspected to extract the unique identifier (CLSID) of the COM object. A look at variable as it would look in memory is shown as follows:

Opening the HKEY_CLASSES_ROOTCLSID key gives the corresponding readable format:

On function return, a new shortcut (lnk) is created under the local path resulting from GetTempPath function minus “\Local\Temp\” and plus “\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\thumbnail.lnk

The content of thumbnail.lnk is:

“C:\Windows\System32\rundll32.exe” “full path of module”, SetupWorkStation S-6-38-4412-76700627-315277-3247 0 0 9109 1

// Implant Initialization

SetupWorkStation function of the implant is aimed at a system reconnaissance and at performing beacon of the command and control center. If the malware does not find the exact number of expected arguments in its command line, it simply quits the execution without going any further.

Inside this frame of code, a new thread is created with the starting address 100075A0. sub_10007340 is designed to initialize external communication. It internally calls sub_100071F0 that is aimed to executing operations designed for system reconnaissance.

An example of these instructions from dynamically generated pseudo-code is shown below:

  • Retrieving Username and CumputerName
  • Retrieving LogicalDrives, DriveTypes
  • Retrieving FreeSpace for drives
  • Performing Processes Enumeration

The collected information is then compressed and encrypted. Subsequent HTTP request is prepared in order to send data to command and control. Communications make use of HTTP protocol and POST method. “ned“, “gl” and “hl” parameters will be used in order to interact with remote command and control script that are used to handle victims and to deliver the second stage payload. A code frame regarding the functions used for HTTP communication is reported as follows:

// Behind the first stone

We had the opportunity to analyze what the actor did in the backend in order to manage the victims of the first stage implanter that has been described. The remote script, at least as far as observed, is copied into legitimate compromised sites. It also includes the possibility to decide if and when the second level payload is to be released and works through blacklists and whitelists in order to protect the final backdoor from unwanted spread.

It looks like a heavily obfuscated VBScript artifact. Here an extract from the original retrieved code:

After retrieving the original instructions set, it has been possible to deeply understand the working logic behind; The remote script works mainly through Request.Form variables that are filled when receiving beacons from victims and by local variables named as following:

1. strworkdir: The working folder within the compromised wwwroot.

2. strlogpath: The path to the file used in order to log victims’ data. In this case a fake .mp3 file

3. strwhitefile: The path to the file used in order to store whitelisted victims IP address. In this case, a fake .mp3 file.

4. strblackfile: The path to the file used in order to store the blacklisted IP address. In this case, a fake .mp3 file.

Parameters “gl” and “hl” are used respectively to retrieve system info about victims and OS architecture. On the basis of what we have collected, the log file mapped by strlogpath variable is then updated with a new row comprising victim IP address, victim system info, request timestamp and adopted case in handling the victim.

The cases that have been designed by the threat actor can be four on the basis of interest for the victim:

  1. case_1_64/86: MD5 of IP address that made the request is on whitelist. The actor has selected the victim to be infected with a second-stage payload. TorisMa_x64/86 payload is then released to the victim.
  2. case_2_64/86: MD5 of IP address that made the request is on blacklist. The actor wants to prevent the spreading of the second stage payload to that IP address. Doris_x64/86 (non-sense chars) payload is then released to the victim.
  3. case_3: The victim results of particular interest for the threat actor on the basis of retrieved system info (identified with a value of 24 of “ned“). Second stage payload is not yet delivered.
  4. case_4: The victim results of no particular interest for the threat actor. no previous condition has been met. Second stage payload is not yet delivered.

Below, the primary construct used to manage what is received by the backend script:

// Victimology

According to the visibility obtained so far, we asses with a high degree of confidence that this campaign is mainly directed against research/defense sector and financial / payments institutions. Other types of sectors are obviously not to be excluded on the basis of actor interests. Most of the malicious activities associated with the examined malware set are limited to the Indian region. However, organizations of other countries as well are inside of Lazarus’ interests. Here there is an exhaustive geographical map where it is possible to observe actions attributable to this specific threat (note that these malicious actions may not have led to a current active infection but could be only limited to infection attempts):

// Conclusions

In this case, the Lazarus group targets research / defense and financial organizations mainly in the same region where the security community has recently attributed an attack from the same group against a nuclear power plant. However, it has also been noted that the actor has extended its interests to other regions of the world, including Italy. Furthermore, we have observed an info-gathering implanter used to quickly identify interesting targets and we have exposed the use of a backend script designed to handle the victims and limit the spread of second-stage payloads only to wanted ones.

// MITRE ATT&CK Techniques

[+] T1193 – Actor relies on spear-phishing as infection vector

[+] T1002 – Actor compresses and encrypts data

[+] T1132 – Actor encodes data

[+] T1023 – Actor relies on shortcuts to achieve persistence

[+] T1060 – Malware maintain persistence through Start menu folder

[+] T1071 – Actor relies on standard application layer protocol for C2 coms

[+] T1043 – Actor uses common ports to communicate

// Indicators of Compromise

SHA256: b018639e9a5f3b2b9c257b83ee51a3f77bbec1a984db13d1c00e0CC77704abb4

SHA256: adf86d77eb4064c52a3e4fb3f1c3218ee2b7de2b1780b81c612886d72aa9c923

SHA256: 1a172d92638e6fdb2858dcca7a78d4b03c424b7f14be75c2fd479f59049bc5f9

SHA256: ec254c40abff00b104a949f07b7b64235fc395ecb9311eb4020c1c4da0e6b5c4

SHA256: 26a2fa7b45a455c311fd57875d8231c853ea4399be7b9344f2136030b2edc4aa

Domain name (compromised): curiofirenze[.]com

IP Address: 193.70.64.163

File: %USERPROFILE%”\AppData\Local\Microsoft\ThumbNail\thumnail.db

File: %APPDATA% \Microsoft\Windows\Start Menu\Programs\Startup\thumbnail.lnk

// Artifacts detection rules

YARA detection rule for unpacked dll implant is available here

Third-party freely available rules for detecting executables that have been encoded with base64 twice are here