Threat actors used a well-liked piece of corporate communication software from 3CX, according to security experts. In particular, reports state that a desktop client for the 3CX VoIP (Voice over Internet Protocol) service was used to specifically target 3CX’s clients.
It is believed that the attack is a multi-part process, with the first stage using a hacked version of the 3CX desktop application. Although the.exe file and the MSI package have the same name, preliminary research indicates that the MSI package is the one that may include DLLs that have been maliciously modified.
The beginning of the infection process occurs when 3CXDesktopApp.exe loads the ffmpeg.dll file. After that, ffmpeg.dll will read the encrypted code from d3dcompiler_47.dll and then decode it. It seems that the decrypted code is the backdoor payload that attempts to visit the IconStorage GiHub page in order to access an ICO file that contains the encrypted C&C server that the backdoor connects to in order to acquire the probable ultimate payload.
It is not a coincidence that the threat actors responsible for this attack chose these two DLLs (ffmpeg and d3dcompiler_47) as targets for their attack. The application in issue, known as 3CXDesktopApp, was developed using the open-source framework Electron. Both of the libraries in issue are often distributed along with the Electron runtime. As a result, it is very unlikely that they would arouse suspicion inside the surroundings of individual customers. In addition, the file that was tampered with, d3dcompiler 47, is signed with a certificate that was granted to Microsoft Corporation, and the digital signature details for Windows reflect that there are no problems associated to the signature. A signed binary that makes use of a valid certificate procured from a trustworthy company such as Microsoft is more likely to be given the “green light” when it comes to endpoint protection programs.
In this instance, the “smoking gun” was a combination of RC4 encrypted shellcode that was inserted into the signature appendix of d3dcompiler and a reference to the d3dcompiler library that was introduced to the ffmpeg library. Both of these things were added to the ffmpeg library.
Windows will show a notification saying the “digital signature of the item did not validate” whenever a signed executable is updated, but despite the fact that we are aware that the d3dcompiler_47.dll DLL was altered, Windows continued to present it as signed. This is despite the fact that we are aware of the fact that it was modified.
It seems the DLL is abusing the CVE-2013-3900 flaw, which is referred to as a “WinVerifyTrust Signature Validation Vulnerability.”
On December 10, 2013, Microsoft was the first company to publicly disclose this vulnerability. At the time, the company explained that it is possible to add content to the authenticode signature section of an EXE (the WIN CERTIFICATE structure) in a signed executable without rendering the signature invalid.
Microsoft made the final decision to make the fix optional, most likely because it would invalidate genuine, signed executables that contained data in the signature block of an executable. As a result, Microsoft made the decision to make the update optional.
According to the disclosure made by Microsoft for the CVE-2013-3900, the company changed the way signatures are verified for binaries signed with the Windows Authenticode signature format with the release of an update on December 10, 2013. This update was made available for all supported releases of Microsoft Windows.
This modification may be activated on a voluntary basis if desired.When the new behavior for Windows Authenticode signature verification is enabled, Windows will no longer regard non-compliant binaries as signed, and it will no longer allow unnecessary information to be stored in the WIN CERTIFICATE structure.
Even though it has been close to 10 years after the vulnerability was discovered, and even though it is known that several threat actors are exploiting it, the remedy is still an opt-in feature that can only be activated by manually modifying the Windows Registry. To make things worse, even if you add the Registry entries to apply the update, they will be deleted after you upgrade to Windows 11, putting your device susceptible once again.
Companies that are possibly impacted should immediately cease using the vulnerable version of the software, dlls if at all feasible and implement any patches or mitigating measures, if these are available. IT and security personnel should also search for proven compromised binaries and builds and watch for abnormal activity in 3CX processes, with a particular attention on C&C traffic.
In the meanwhile, activating behavioral monitoring in security solutions may assist in determining whether or not an attack is currently taking place inside the system.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.
