Rome 2 Virtualalloc

[Kassim Bisaillon]

TheCybereason Global Security Operations Center (GSOC) Team issues Threat Analysis Reports to inform on impacting threats. The Threat Analysis Reports investigate these threats and provide practical recommendations for protecting against them.

This may have been due to the fact that the PlugX malware authors were tied to China and the operators of this malware at the time were located within Asian countries. Since then, the malware has been active and utilized by many threat actors for over the past decade. The malware had many updates over the years and it does not appear to be going away anytime soon.

From its original version, the PlugX malware has been primarily used against public-sector organizations such as governments and various political organizations. In addition, advanced threat actors utilize the malware heavily to target high profile private organizations.

This may be the indicator that the malware operators for PlugX were expanding their markets and targets. Most recently, the malware was utilized to target European government agencies which aided Ukrainian refugees from the recent Russia-Ukraine War.

PlugX loader is commonly delivered via phishing emails and it is also seen delivered by exploiting a vulnerability such as ProxyLogon according to Unit 42 from Palo Alto Networks. The malware is often delivered as an archived formatted file such as .zip, .rar or self-extracting RAR (SFX) archive.

The malware utilizes DLL Side-Loading as a main method to load a malicious DLL from a legitimate executable, like Acrobat Reader or a legacy Microsoft binary, for instance. The benefits of using DLL Side-Loading is that the malware can hijack and masquerade the legitimate executable by loading malicious modules. DLL Side-loading not only allows for evasion of security tools, but also allows malware developers to have a variety of options into which legitimate executable to side-load the PlugX payload:

The malware utilizes DLL Side-Loading technique by leveraging the legitimate executable (Nv.exe) to load a malicious module (NvSmartMax.dll), which loads an additional malicious payload (Nv.mp3) to prepare for an actual PlugX payload.

When the legitimate executable Nv.exe first executes and side-loads the PlugX loader module NvSmartMax.dll, the module first checks the OS date and time with the GetSystemTime method, which then calculates the output with the following formula.

The result of the equation is expected to be a hex value, which is then compared with the value 0x1330225, which is equivalent to the date 2012-01-01. The execution of this method enables the NvSmartMax.dll to check if the OS date and time is later than 2012-01-01.

The NvSmartMax.dll module proceeds to patch the EntryPoint to jump into a function at offset 0x1020 in NvSmartMax.dll. The malware appears to be utilizing control flow manipulation as an obfuscation method against static analysis:

Once the control flow enters the EntryPoint of the Nv.exe, execution jumps to the patched address in NvSmartMax.dll. In the target function, the malware prepares to load the Nv.mp3 by attempting the following steps:

PEB is a data structure, which contains process information which is utilized internally by the operating system (OS). PEB is often utilized for anti-analysis techniques such as NtGlobalFlag check, but it can also be used to fetch necessary module information.

At offset 0x0C within PEB, PEB_LDR_DATA structure is located which stores loaded module information. This structure has three members: InLoadOrderModuleList, InMemoryOrderModuleList, and InInitializationOrderModuleList:

The code located in Nv.mp3 fetches InInitializationOrderModuleList, which includes all the loaded modules in order of initialization. This list does not include the executable itself, and it only lists the modules:

Once the base address of kernel32.dll is retrieved, Nv.mp3 fetches the function GetProcAddress address in order to load the functions LoadLibraryA, VirtualAlloc, VirtualFree, and ExitThread, which appears to be loaded via StackString method:

Once all the function addresses are loaded from kernel32.dll, Nv.mp3 loads the module ntdll.dll by using the LoadLibraryA function which was retrieved earlier by the GetProcAddress function. From ntdll.dll, Nv.mp3 loads functions RtlDecompressBuffer and memcpy.

The code located at Nv.mp3 level proceeds to decrypt the RC4-encrypted strings which are stored within the payload at offset 0x1529 with size 117KB. The decrypted strings are a compressed version of a PE file, which performs the RtlDecompressBuffer function with LZ decompression format:

Lastly, it loads necessary libraries and functions dynamically by using LoadLibraryA and GetProcAddress from the import table listed in the decompressed PE file. Once this preparation is done, it proceeds to enter the PlugX payload:

This comparative analysis analyzes the following six samples listed in the table below. The samples are observed in the past from various analyses from different reports. As a reference, the samples (executable, module, payload) are identified with codename with prefix px_ followed by the relevant year that the samples were observed according to the external sources:

However, in sample px_2019, it only conducts the date and time check for the year 2018. The versioning of this malware also seems to exist, which is evident from the date and time check of the date of px_2019 being 2018.

Samples px_2014 and px_2021 did not patch instructions to manipulate the control flow. It utilized legitimate exported function names of the legitimate DLL which gets called by the legitimate executable.

Aside from InitializationOrderModuleList, sample px_2021 utilized InMemoryOrderModuleList. InMemoryOrderModuleList lists loaded modules according to the memory placement. The difference from InInitializationOrderModuleList is that InMemoryOrderModuleList includes the executable within the list.

The usage of StackString on the functions which need to be loaded dynamically appears to be consistent throughout the samples. However, a slight update is placed in px_2019, px_2021 and px_2022, which is placing one character at a time onto a Stack:

Samples px_2014 and px_2015 also have additional code obfuscation, which is an encryption on the function that prepares the PlugX payload. This function is the main component of this deployment payload and this is an additional layer of anti-analysis:

This update only removed portions of the PE header. However, it contained necessary information for the code to function. This update prevents analysts from simply dumping the decompressed payload and conducting further analysis, since it is not in proper PE format.

Although there were no major updates, the malware loader appears to have version management. This is evident from OS date and time check as well as the differences in payload headers while deploying the actual PlugX.

The lack of a major deployment method is also believed to be due to the use of the DLL Side-Loading technique. The DLL Side-Loading technique itself gives the threat actors various options on which legitimate executables to side-load the PlugX with. This evasion technique already creates various combinations and an update on deployment methods deemed unnecessary

The Cybereason Defense Platform is able to detect and prevent infections with the PlugX loader using multi-layer protection that detects and blocks malware with threat intelligence, machine learning, anti-ransomware and Next-Gen Antivirus (NGAV) capabilities:

Cybereason is dedicated to teaming with defenders to end cyber attacks from endpoints to the enterprise to everywhere. Schedule a demo today to learn how your organization can benefit from an operation-centric approach to security.

Kotaro Ogino is a Senior Security Analyst with the Cybereason Global SOC team. He is involved in threat hunting, administration of Security Orchestration, Automation, and Response (SOAR) systems, and Extended Detection and Response (XDR). Kotaro has a bachelor of science degree in information and computer science.

Yuki Shibuya is a Senior Security Analyst with the Cybereason Global SOC team. He is tasked with triaging critical incidents, threat hunting and malware research. He has a master degree of information systems security and is interested in malware research and penetration testing.

The Cybereason Global SOC Team delivers 24/7 Managed Detection and Response services to customers on every continent. Led by cybersecurity experts with experience working for government, the military and multiple industry verticals, the Cybereason Global SOC Team continuously hunts for the most sophisticated and pervasive threats to support our mission to end cyberattacks on the endpoint, across the enterprise, and everywhere the battle moves.

First observed in June 2022 in the wild, HavanaCrypt Ransomware masquerades as a legitimate Google Chrome update with sophisticated anti-analysis techniques and other functionality that may be used for data exfiltration and privilege escalation...

3a8082e126