new mailings of cyber spies PhantomCore to Russian companies using PhantomCore.KscDL_trim

On September 5, FACCT specialists recorded several mailings from the PhantomCore group, aimed at:

a Russian IT company that develops software and online cash registers;
a company that organizes business trips;
design bureau;
manufacturer of wireless communication systems and high-tech equipment.

FACCT's Leading Malware Analysis Specialist Analyzes New PhantomCore Mailings Artem Grishchenko and an analyst with the FACCT Advanced Threat Research Group Alena Shander.

Let us recall that PhantomCore, a cyber spy group operating against Russian organizations since early 2024, was first exposed and described in report by researchers at FACCT The group got its name from their unique remote access Trojan PhantomRAT. In the spring and summer of this year, cyber spies attacked Russian organizations in various industries, but most of the targets were found among industrial companies. A distinctive feature of the attackers is that they first compromise third-party organizations and use them to carry out attacks via phishing emails.

The content of the letters from the recent mailings was identical, an example of one of them is shown in Figure 1.

Fig. 1 – example of the contents of a letter from the PhantomCore mailing list dated 09/05/2024

The email with the attachment “Supply_agreement_form_00694723_from_04_09_2024.rar” was sent from a likely compromised address belonging to a company specializing in the construction and automation of electric power and transport facilities. The subject of the email matches the name of the attachment: “Supply agreement form No. 00694723 from 04.09.2024”. Attackers often use this format of attachments and themes in their activities, disguising the email as various important documents, such as contracts, applications, invoices, etc.

The attachment is a password-protected archive. Note that the attackers have complicated the password for the archive; in old attacks, the password was the year, mailing dates, easy digital combinations: “11112222”, “2024”, “1007”, and others, while the current mailing used the password: “He@k43M24v”. The archive includes an executable file and a legitimate PDF file, which is a decoy document with the same name. The contents of the archive are shown in Figure 2.

Fig. 2 - contents of the archive — Fig. 2 – contents of the archive “Supply_contract_form_00694723_from_04_09_2024.rar”

Attackers continue to exploit the vulnerability CVE-2023-38831, which means that if a user with a WinRAR version lower than 6.23 launches a PDF file, the executable file contained in the archive directory of the same name will be launched.

The contents of the bait document, supplied by the attackers in a blurred form, are shown in the figure below.

Fig. 3 – contents of the bait “Supply_Contract_No._00694723_from_04_09_2024.pdf”

The executable file “Agreement_for_delivery_obr_00694723_ot_04_09_2024.pdf .exe” is a malicious program classified by us as PhantomCore.KscDL_trim. As C2 it uses ip: 185[.]130[.]251[.]55:80.

PhantomCore.KscDL_trim is a stripped-down version of the PhantomCore.KscDL loader, written in the C++ programming language and packed with the UPX tool. The loader has the following capabilities: downloading and running files from a C2 address; executing arbitrary commands in the Windows command interpreter. PhantomCore.KscDL_trim uses the HTTP protocol to interact with the server and the Boost.Beast library.

After passing the check, the encoding 866 and locale “ru_RU.UTF-8” will be set. Next, the function for connecting to the server will be launched. The request will be executed on gateway /connect. In case of unsuccessful connection, the line will be added to the log: “[-] Retry in 5 seconds…”, and after a 5-second wait, a second attempt to connect will be made. If the connection is successful, the following line will be added to the log: “[+] Connected to server: {C2} successfully!”, and the execution process will proceed to the task of receiving and executing commands from C2. Also, during the connection to the server, the following line will be added to the log as a result of executing the request: “[+] Response from server: “.

In PhantomCore.KscDL_trim there is a task runRequester, which performs the following sequence of actions:

creating a JSON object with system data and sending it using a POST request to gateway /init;
execution of the /check request and transition to receiving and processing commands from the server (requesterThread task).

On first run, and if the initialization object has not been sent, the execution process will proceed to collecting the object and sending it. The object contains the following template:

{

    "BuildName": "5",

    "Domain": "{domain}",

    "Hostname": "{hostname}",

    "Interval": 15,

    "LocalIp": "{local_ip}",

    "Os": "{os_version}",

    "Username": "{computername}\{username}",

    "Uuid": "{uuid}"

}

Uuid – randomly generated value using the pattern %08x-%04x-%04x-%04x-%012llx;
BuildName – contained inside the file (in the file under study – “5”);
Domain – retrieved using the WQL query SELECT Domain FROM Win32_ComputerSystem to the WMI object Win32_ComputerSystem;
Hostname – retrieved using the WQL query SELECT DNSHostName FROM Win32_ComputerSystem to the WMI object Win32_ComputerSystem;
Username – retrieved using the WQL query SELECT RegisteredUser FROM Win32_OperatingSystem to the WMI object Win32_OperatingSystem;
LocalIp – local IP address, which will be obtained using the boost::asio::ip::host_name() function;
Os – the system version, which will be obtained as a result of concatenation of two WQL queries SELECT Version FROM Win32_OperatingSystem and SELECT Caption FROM Win32_OperatingSystem to the WMI object Win32_OperatingSystem;
Interval – is contained inside the file and is responsible for the time interval between iterations of the loop in the runRequester() function (in the file under study – 15).

This JSON object will be sent via POST request to gateway /init. It is important to note that this object and the response from the server will be added to the log.

If the data is successfully sent, the execution process will switch to a cyclic sending of the /check request and creation of the requesterThread task to receive and process the command from the server. To receive the command in the context of the task, a POST request is cyclically executed from gateway /command. In response to this request, a JSON object of the following type will be received:

{

    "Done": {done},

    "OperatorId": "{operator_id}",

    "Response": "{response}",

    "Command": "{command}",

    "AgentId": "{agent_id}",

    "Uuid": "{uuid}"

}

This object contains the “Command” field, which contains the command. After its execution, the command result will be added to the “Response” field, and the “Done” field will be set to true. We also believe that the “OperatorId” field contains a unique identifier of the attacker, which identifies the malware operator from whom the command was sent. The “AgentId” field contains a generated UUID, which denotes the unique identifier of the agent located on the infected system (this UUID will be sent to the C2 server in the context of the /init POST request). And the “Uuid” field in the context of the current request contains a unique identifier of a specific command.

Supported bootloader commands:

up {URL} – upload a file to the infected system. The command contains a URL to which a request will be made to download the file. The file will be saved to the current directory of the process.
ex {cmd} – change current directories, as well as arbitrary commands in the Windows command interpreter. There are three options for processing the command:
- if the command “cd ..” was received, the current directory will be set to the parent directory;
- if the string template is “cd {filepath}”, then a check will be performed to see if the file path {filepath} exists in the system. If the path exists, it will be set as the current directory;
- If the command does not match the patterns from points 1 and 2, the command “cmd.exe /C {cmd}” will be executed, the command result will be sent to the C2 server.
st {filepath} – run a file using the command “cmd.exe {filepath}”.

It is important to note that after each command is executed, a POST request will be made to the C2 server from gateway /out, which will contain the same JSON object template that was received from the server when the command was received. However, the “Response” field will be appended with the result of the command, and the “Done” field will be set to 1.

If the received command does not match the commands being processed, an error will be sent to the server: “ERROR: Input command incorrect!”.

During the analysis, we were able to obtain several commands from the command and control server, which allowed us to establish that the attackers pre-profile the victim and decide whether they are interesting for developing the attack: