During the analysis of some malicious artifacts collected from an incident, we have recently detected a sample that has caught our attention, the sample was deployed on a server exposed to the Internet and was packed with “VMProtect”. After analyzing this malware sample we could see that it was a recent version of a tool known as OwlProxy, which has been detected on targets hit by the APT group known as Chimera.
The use of “VMProtect” by the actors makes the analysis of their code more time-consuming (although it simplifies its detection since this is already an anomaly by itself). On the other hand, this packer has some weaknesses such as the fact that it does not always protect part of the binary metadata and that once in memory, it does not obfuscate most of the strings, which makes these elements of the executable relatively easy to analyze once in memory.
Especially for this sample it helps for its identification given the amount of quite unique strings it contains. An example of this is the fact that in static you can see how it still contains the string with the original name of the binary (iisdll.dll).
From some of these strings, it can be seen how new samples are being uploaded regularly, which after a more detailed analysis have been identified as different 32-bit and 64-bit versions of the same threat, some of them packaged and others not.
Some of them, dating from 2019, largely coincide with the samples analyzed in the following CyCraft
A summary of its capabilities can be found in this report, which explains that it acts as a proxy between the DMZ of the victim’s infrastructure and its internal network and also allows the execution of commands remotely.
The report shows the metadata of the binary where you can see how the PDB matches with most of the more recent samples that can be found in Virustotal.
It is also explained in the report that the sample puts its persistence as a Service and highlights the two endpoints it exposes while it is running.
In the case of the samples analyzed, instead of using port 80, they are exposing the port 443 using SSL and they have stopped using the string “servlet” and now they have different strings depending on the sample in question, they have kept the string “pp” for the endpoint that acts as proxy.
Two samples from 02/2019
|https://+:443/HelpTheme/||Remote CMD addr|
|https://+:443/topics/||Remote CMD addr|
Along with these two samples, there are 3 more recent ones (July 2020). Two of them are newer versions of this same 32-bit and 64-bit tool and the third one is an installer or dropper (9A9FFDB8FC20B6E6E6E5A1DE434F6B834E69755FD62157F91884E9A681F0073256) that when executed, depending on the operating system architecture, extracts from its resources a suitable OwlProxy sample for the architecture in question, installs it in system32 with the name “wmipd.dll”, gives it the same creation and modification date as “calc.exe” and creates a service named wmipd that runs it at every system startup.
The pdb of this dropper keeps the string “owl” in its path, so we have named it OwlInstaller. “f:\project\owl\isapi\win32\release\iisinstaller.pdb”.
The OwlProxy sample of its resources is split into reverse ordered blocks, so the MZ header, for example, is in the last 2634 bytes of the file.
Once extracted and installed, these more recent samples have many strings and use OutputDebugString in several occasions, which causes that in debugging or using DebugView a few of this strings can be seen as debug information:
Along with the fact that these also use “https” as protocol, and that they have again changed part of the path of their endpoints to use “exchangetopicservices” (probable evolution of the 2019 samples that use the string “topics”), they have added a new endpoint to the tool, as follows:
|https://+:443/exchangetopicservices/||Remote CMD addr|
The path ending in “exchangetopicservices” still works the same way as in previous samples, executing commands in a cmd process through unnamed pipes. The proxy endpoint has also remained the same in terms of capabilities. Finally, thanks to all the strings in the binary, it is easy to spot that they call this endpoint “Webshell_run”, whose URI ends in “/px/”, and consists of a function that adds the following list of commands:
This area has many more strings than the rest, and it is curious that several of them are misspelled. In fact the first error probably comes in the command “get_driver” since in its internal logic the only thing it does is to list the hard disks installed in the computer:
Which suggests that probably, this functionality should be called “get_drives” :_)
The next wrong command is “donwload_file”, although in this case it’s easy to guess what it means and it does exactly that, it allows the attacker to download a file from the compromised server.
The rest do match their names since “get_directory” can be used to list the contents of a directory and “upload_file” is used to drop a file on the remote server.
The last notable error we have detected is a translation error when a file does not exist in the “get_directory” command.
The older versions have much fewer strings, so it is likely that in future versions of the threat will remove many of those described in this post, but some of them are used to identify the command executed, so it is possible that they will remain, along with the pdb that they have been leaving since 2019. What is clear is that they are in constant development.
|DEE3A502AEDCBE109373AA200A690D4E2D1A10FA3CF69A7B6DB68A78C6ABFC2C||Old OwlProxy x64 version|
|75E616BF87AD0CBE738C4C48BC0ECD114871DEF145E21545FA11705D3A11D60E||Old OwlProxy x64 version|
|16CF6924ECA8208AD9D9B8470CF0A849995ED4D981D5BC706E62AE878EF261BB||Recent OwlProxy x86 version|
|C9B8CFACC859E494984AE9DDF864314AF651FD32E60F33C7F42BFC640620E8CA||Recent OwlProxy x64 version|
|95E7E09468F7DC62DA42E036B6E36CE27DC04C2CA0BB86A2FED39B3CC2BF4A97||VMProtect OwlProxy x64 version|