<\/p>\n
![](\"https:\/\/www.trendmicro.com\/content\/dam\/trendmicro\/global\/en\/research\/thumbnails\/24\/phemedrone-stealer-exploit.jpg\")
<\/div>\nDefense evasion by exploiting CVE-2023-36025<\/span><\/p>\n Once the malicious .url file exploiting CVE-2023-36025 is executed, it connects to an attacker-controlled server to download and execute a control panel item (.cpl) file. Microsoft Windows Defender SmartScreen should warn users with a security prompt before executing the .url file from an untrusted source. However, the attackers craft a Windows shortcut (.url) file to evade the SmartScreen protection prompt by employing a .cpl file as part of a malicious payload delivery mechanism. Threat actors leverage MITRE ATT&CK technique T1218.002<\/a>, which abuses the Windows Control Panel process binary (control.exe<\/i>) to execute .cpl files. Note that these files are DLL files. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n When the malicious .cpl file is executed through the Windows Control Panel process binary, it in turn calls rundll32.exe<\/i> to execute the DLL. This malicious DLL acts as a loader that then calls on Windows PowerShell to download and execute the next stage of the attack, hosted on GitHub. The next stage is another PowerShell loader named DATA3.txt<\/i>. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n The file DATA3.txt<\/i> is an additional obfuscated loader that uses PowerShell string and digit manipulation techniques to mask its contents and make deciphering its true purpose more difficult during static analysis. <\/a><\/p>\n Using a combination of static and dynamic analysis, we can deobfuscate the GitHub-hosted loader, which gives us a series of PowerShell commands that this script executes. This loader downloads a ZIP file hosted on the same GitHub repository to a hidden directory created using the Windows attribute utility binary (attrib.exe<\/i>). <\/p>\n The zip archive contains three files: <\/p>\n Persistence using scheduled tasks and DLL sideloading<\/span><\/p>\n The wer.dll<\/i> file is a crucial component of the loader’s functionality as it decrypts and runs the second stage loader and achieves persistence by creating scheduled tasks that we will detail here. The malware utilizes multiple techniques to evade detection and complicate reverse engineering, such as API hashing and string encryption. Additionally, this DLL is packed and protected by VMProtect. <\/p>\n The loader is executed using the DLL sideloading technique, where the attacker spoofs a malicious DLL file in the application’s directory. This tricks the operating system into loading the malicious file instead of the legitimate one. In the case we investigated, WerFaultSecure.exe<\/i> executes the WerpSetExitListeners<\/i> function from wer.dll<\/i>, which triggers the loader to run. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n The loader uses a technique called dynamic API resolving to hide its API imports and make it harder for static analysis. This technique involves storing the hashes of the necessary APIs instead of their names, and then importing them dynamically at runtime. In the case we investigated, the loader uses the Cyclic Redundancy Check 32 (CRC-32) hashing algorithm, contents of which are detailed in the following table.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n Table 1. The hashes in the loader\u2019s dynamic API resolving, and their corresponding API names<\/span><\/p>\n<\/p><\/div>\n<\/p><\/div>\n The loader uses an XOR-based algorithm with dynamic key generation for string decryption. For each byte, the algorithm generates a unique key based on its position in the buffer, using the formula (characterIndex % <num1> + <num2>).<\/i> This key is then XORed with the byte to reveal the original character. Each encrypted string has its own decryption function with unique <num1><\/i> and <num2><\/i> to make the string decryption automation harder. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n The following is a list of decrypted strings from the first stage loader: <\/p>\n The loader maintains persistence by creating a directory named C:\\Users\\Public\\Libraries\\Books<\/i> and copies wer.dll<\/i>, secure.pdf<\/i>, and WerFaultSecure.exe<\/i> from the current execution directory to this location. It then executes the schtasks.exe<\/i> command with the arguments “\/F \/CREATE \/TN \\”Licensing2\\” \/tr \\”C:\\\\Users\\\\Public\\\\Libraries\\\\Books\\\\WerFaultSecure.exe\\” \/sc minute \/MO 90″,<\/i> scheduling the WerFaultSecure.exe<\/i> to run at 90-minute intervals. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n The loader then advances to the second stage wherein the encrypted second-stage loader is in a file called secure.pdf<\/i>. To decrypt it, the malware utilizes an undocumented function, SystemFunction032<\/i> from advapi32.dll<\/i>, which performs RC4 decryption. It then uses the AllocADsMem<\/i> and ReallocADsMem<\/i> functions from Activeds.dll<\/i> to allocate memory and relocate the decrypted content. Finally, it calls VirtualProtect to modify the memory region of the decrypted buffer to Executable-Read-Write. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n The malware then uses API callback functions to redirect the flow of execution to the second stage. Callback functions are routines that are passed as a parameter to Windows API functions. Later, these routines are called by the API to perform specific functionalities. In the case we investigated, the malware uses the CryptCATCDFOpen<\/i> function, which is used for handling cryptographic catalog files in Windows. It requires two parameters: a file path (pwszFilePath<\/i>) and an optional callback function (PFN_CDF_PARSE_ERROR_CALLBACK<\/i>). The loader passes the second stage shellcode Entry Point (EP) to the second parameter, PFN_CDF_PARSE_ERROR_CALLBACK<\/i>. When the API function is called, the callback function is executed and the malicious code is run. <\/p>\n<\/p><\/div>\n<\/p><\/div>\n Second-stage defense evasion<\/span><\/p>\n The attacker used a second-stage loader known as Donut<\/a>, an open-source shellcode that allows the execution of VBScript, JScript, EXE files, DLL files, and .NET assemblies in memory. Donut can be embedded directly into the loader, or it can be staged from an HTTP server or a DNS server. In the case we investigated, the attacker chose to embed it directly into the loader. <\/p>\n\n\n\n\n\n
\n\n\n\n\n\n\n\n
\n 998B531E<\/i><\/td>\n KERNEL32.DLL <\/i><\/td>\n<\/tr>\n \n 46DED02D<\/i><\/td>\n GetModuleHandleExW <\/i><\/td>\n<\/tr>\n \n 0FC6B42F1<\/i><\/td>\n GetModuleFileNameW<\/i><\/td>\n<\/tr>\n \n 0C97C1FFF<\/i><\/td>\n GetProcAddress <\/i><\/td>\n<\/tr>\n \n 3FC1BD8D<\/i><\/td>\n LoadLibraryA <\/i><\/td>\n<\/tr>\n \n 0F29DDD0C<\/i><\/td>\n lstrcatW <\/i><\/td>\n<\/tr>\n \n 759903FC <\/i><\/td>\n CreateDirectoryW<\/i><\/td>\n<\/tr>\n \n 0A1EFE929<\/i><\/td>\n CreateFileW <\/i><\/td>\n<\/tr>\n \n 0A7FB4165<\/i><\/td>\n GetFileSize<\/i><\/td>\n<\/tr>\n \n 8B35A289<\/i><\/td>\n LocalAlloc <\/i><\/td>\n<\/tr>\n \n 95C03D0<\/i><\/td>\n ReadFile <\/i><\/td>\n<\/tr>\n \n 0B09315F4<\/i><\/td>\n CloseHandle<\/i><\/td>\n<\/tr>\n \n 0B1866570<\/i><\/td>\n GetModuleHandleA<\/i><\/td>\n<\/tr>\n \n 0F54D69C8<\/i><\/td>\n CopyFileW <\/i><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n\n\n\n\n
\n\n\n\n\n\n