Sailing Into Danger: DONOT APT’s Attack on Maritime & Defense Manufacturing – Source:cyble.com

Key Takeaways

• Cyble Research and Intelligence Labs (CRIL) came across a campaign Linked to the known APT group DONOT, targeting the manufacturing industry that supports the country’s maritime and defense sectors.
• The campaign uses a malicious LNK file disguised as an RTF containing encrypted data. The file is decrypted via PowerShell to deliver a lure RTF and payload.
• A scheduled task is then created to ensure the malware runs every five minutes for persistence.
• Random domains are generated with hardcoded words and TLDs for backup C&C servers.
• The encryption method for C&C communication has changed compared to previous campaigns.
• The stager malware communicates with the C&C server using AES encryption and Base64 encoding to evade detection.
• The decryption key for the second-stage payload is now in the downloaded binary rather than hardcoded in the config file.
• The victim’s system information is collected before delivering the final payload to assess the target’s value.
• The stager malware uses environment variables to store critical configuration details, like C&C addresses and task information.

Overview

CRIL recently came across a campaign seemingly aimed at Pakistan’s manufacturing industry, which supports the country’s maritime and defense sectors. After analyzing the files involved in the campaign, it was determined that the attack was linked to the known APT group DONOT.

DoNot, also known as APT-C-35, is an Advanced Persistent Threat (APT) group operating since 2016. This group has a history of targeting government and military entities, as well as foreign affairs ministries and embassies across South Asia.

In this recent campaign, the Threat Actor (TA) uses the .LNK file as the initial infection vector, which could arrive within a RAR archive via spam email. The .LNK file is disguised as an RTF file, leading users to believe they are opening a legitimate file.

When the user clicks to execute, it triggers cmd.exe and powershell.exe to run additional malicious commands, loading the stager malware (a DLL file) and establishing persistence by creating a scheduled task to execute the DLL file through rundll32.exe. Also, it communicates with the primary C&C server by sending a unique device ID via a POST request and, in response, receives control commands from the TA to direct its next actions.

These actions include self-destruction, deployment of additional malicious payloads by downloading an encrypted payload from a specified URL, and subsequent execution. To evade detection and complicate analysis, the malware employs a different encryption method instead of the single-byte XOR key used in previous campaigns. The figure below shows the infection chain.

This “.LNK” file campaign was first identified by StrikeReady Labs, who reported it on the X platform. A similar campaign was also seen in July 2024, targeting Pakistan’s Government agencies and manufacturing industries using sector-specific lures. In the previous campaign, the TA employed malicious Office files with embedded macros and Rich Text Format (RTF) files that exploit vulnerabilities to load the stager DLL onto victim machines.

When comparing the previous campaigns, the initial infection vector has shifted from Microsoft Office files to .LNK files. Additionally, the stager DLL now employs an enhanced payload delivery method and improved C&C communication, incorporating encryption mechanisms at various stages.

Technical Analysis

The malicious “.LNK” file contains PowerShell commands, an encrypted lure RTF file, and the encrypted stager payload. Upon execution, the “.LNK” file initiates “cmd.exe,” which creates a directory in the “%temp%” path and copies “powershell.exe” to this location as “2SqSxDA2.exe.” The newly copied PowerShell process subsequently executes the PowerShell code embedded in the LNK file. The figure below shows the partial content of the LNK file.

PowerShell Code

The PowerShell command embedded within the “.LNK” file retrieves both a lure file and a DLL from the “.LNK” itself. It identifies the “.LNK” file based on its file size and directory path, then decrypts the lure RTF file and the DLL file using a single-byte XOR operation with “0xB2.” Decryption begins at offset “0x1774” for the lure file and “0x79AF” for the DLL.

These extracted files are stored in the “%temp%7GGVXwRn” directory. Once extraction is complete, the PowerShell command deletes the PowerShell copy “2SqSxDA2.exe,” opens the lure document, and calls “rundll32.exe” to execute the DLL, invoking the export function “HgCallClient.”

Lure Document

The lure document is related to Karachi Shipyard & Engineering Works (KS&EW), a prominent defense contractor and shipbuilding company in Pakistan. This suggests that the TA is targeting industries supporting the defense sector. The figure below shows the lure document.

DLL file analysis

Upon execution, the DLL begins extracting configuration details from an embedded JSON file. This configuration includes information such as the configuration filename, environment variable name, server domain, transit keys for secure communication, mutex, and user-agent string. The table below shows the configuration details.

Random domain generation

The BackupServerURL mentioned in the config file is generated by selecting six values from a hardcoded array of words and concatenating them to create a domain. A TLD is then selected from a separate array of TLD values. This randomly generated domain serves as a backup for Command and Control (C&C) communication. The figure below shows the list of available words used for generating random domains.

Persistence

After extracting the configuration details, the DLL checks for the presence of a specific scheduled task named “Schedule.” If the task is not found, it creates a new task to execute the DLL via “rundll32.exe” every 5 minutes for one day, as shown in the figure below.

After establishing persistence, the DLL sends a POST request to the primary server URL. This request includes headers such as an HMAC (Hash-based Message Authentication Code) generated from the HTTP method, contact URL, current DateTime, and an HMAC secret key, along with an “X-Timestamp.” The request body contains the unique DeviceID and configuration filename, encrypted using a hardcoded AES transit key and salt, then base64 encoded before being sent to the C&C primary URL. This encryption method marks a relatively new approach in this campaign compared to previous ones observed.

If the C&C server responds with a status code of 200, the response content contains JSON configuration data, which is decrypted using the same AES transit key and IV. The decrypted data includes the following details:

• DownloadURL
• FileDropEnvironment
• FileDropName
• ExportFunctionName
• TaskName
• Self_Destruction (boolean)
• Execution (boolean)

The decrypted JSON configuration data allows the TA to control key aspects of the malware’s behavior, such as downloading additional payloads, specifying file locations, and configuring execution options. This enables flexibility to adjust the attack as needed.

Next Stage payload Execution

If the TA intends to execute an additional payload, the encrypted payload is downloaded according to the C&C configuration. It is then decrypted using an XOR key found within the encrypted file, just after a sequence of magic bytes, and processed using the XOR round-robin method, as shown in Figure 10. This process differs from a previous campaign where the encrypted data was fetched from a URL, and the decryption key was provided directly in the C&C configuration, as shown in Figure 11.

Once decryption is successful, the data is verified as a valid binary by checking for the presence of the string “This program cannot be run in DOS mode”. The decrypted payload is then placed in the directory specified by the “FileDropEnvironment” variable.

After verifying the binary, the stager malware creates a scheduled task to execute the decrypted binary using “rundll32.exe”. The task name and execution interval are specified in the configuration details provided by the TA via the C&C.

In case of a decryption failure, the stager malware updates the configuration with the backup server URL and logs the error message “File corruption while decrypting” It also collects detailed system information, such as disk space and installed security products, to help identify the cause of the decryption failure. This information is then sent to the TA via POST request.

In case of successful payload deployment through the scheduled task, the stager malware logs the event in the same manner as it does for a failure, with the only difference being that the result is recorded as “Payload Deployment Successful.” This log also contains detailed system information, helping the TA identify potential targets in case of success and detect security solutions in case of failure. The TA collects and logs all relevant details, regardless of the outcome, and sends the information to the TA’s C&C via POST request.

The stager malware typically stores data, including the number of attempts to communicate with the C&C, the primary C&C domain name, the last connection date, the backup domain name, and details of the second-stage payload. These values are stored as encrypted entries in the environment variables, as shown in the table below.

During our testing, the C&C server was unavailable, preventing us from receiving a response. As a result, we were unable to observe or analyze the behavior of the next-stage DLL payload, which would have been triggered by communication with the C&C server. Without this crucial interaction, we could not fully understand how the payload executes or what further actions it might take.

Self-Deletion

If the TA activates the self-destruction command via C&C, the stager malware removes the scheduled task and initiates self-deletion by executing the “DEL” command through “cmd.exe”. The image below illustrates the self-deletion process.

Threat Actor Attribution

The malicious DLL connects to the C&C server “internalfileserver[.]online,” which resolves to the IP address “94[.]141.120[.]137.” This same IP address previously hosted the domain “office-updatecentral[.]com,” which was used by the DoNot APT group in a prior campaign. Also, the tactics, techniques, and procedures (TTPs) observed in this campaign exhibit similar behavior to those reported by the 360 Threat Intelligence Centre.

Conclusion

This DoNot APT campaign shows an evolution in tactics. It uses malicious LNK files, PowerShell for payload delivery, and scheduled tasks for persistence. The group also employs dynamic domain generation for backup C&C servers and has updated its encryption methods to avoid detection.

The shift in how decryption keys are handled and the collection of system information before payload delivery indicate a more sophisticated approach. These changes highlight the growing complexity of APT campaigns and the need for improved detection and defense strategies.

Threat hunting Packages

The threat hunting package, including YARA and Sigma rules capable of detecting this campaign, can be downloaded from the linked GitHub pages.

Recommendations 

• Deploy robust EDR solutions to monitor unusual PowerShell activity, scheduled task creation, and suspicious network connections to C&C servers. Ensure these tools are configured to flag and alert on anomalies.
• Limit the execution of PowerShell and other scripting tools to necessary users only and enforce least privilege policies to prevent malware from escalating privileges and performing malicious actions.
• Conduct frequent audits of scheduled tasks to identify any unusual or unauthorized tasks, particularly those involving rundll32.exe. Ensure only trusted applications are allowed to create or execute scheduled tasks.
• Implement behavior-based detection systems that can identify malicious actions, such as frequent attempts to contact C&C servers or unexpected encrypted data being transmitted.
• Implement a well-defined incident response plan with clear steps to handle potential APT intrusions. This plan should include rapid identification, containment, and recovery from any detected malicious activity.
• Conduct regular cybersecurity awareness training for employees, focusing on identifying phishing emails and handling suspicious attachments to reduce the risk of initial infection.

MITRE ATT&CK® Techniques 

Indicators of Compromise

References:

https://mp.weixin.qq.com/s/qCcuU0E6d84tdQ1r2dCsjA

https://twitter.com/StrikeReadyLabs/status/1852532673283268899

https://twitter.com/suyog41/status/1814230027560501248

Related