A ten-year-old Windows bug, which required an 'opt-in' fix, has been exploited in a 3CX attack.

Attackers continue to take advantage of a security flaw in Windows that is more than a decade old. This flaw deceives users into thinking that the authorized signatures on executables are legitimate. Microsoft has developed a solution for this issue, but it is not automatically applied and users must manually opt-in to activate it. Furthermore, after upgrading to Windows 11, the fix is removed.

On the night of Wednesday, it was reported that the company 3CX, which specializes in VoIP communication, was hacked in an attack to spread corrupted versions of its Windows desktop application. This attack targeted a wide range of supply chains.

As a component of the supply chain attack, malicious variations of two DLLs utilized by the Windows desktop application were inserted, resulting in the download of supplementary malware, including a trojan designed to extract valuable information from computers.

A component that was employed during the cyberattack was a harmful DLL. This DLL is typically a reliable Microsoft product known as d3dcompiler_47.dll. But, the attackers made some changes to the DLL by adding a hidden dangerous data at the end of the file that can't be read easily.

As mentioned earlier, despite alterations made to the file, Windows still displayed it as legitimately verified by Microsoft.

When you sign an executable, for instance, a DLL or EXE file, you are essentially providing assurance to Windows users that the file is legitimate and hasn't been tampered with in order to introduce harmful code.

If changes have been made to a signed executable, a notification appears on Windows, indicating that the "digital signature of the object did not verify." Despite the fact that there have been modifications to the d3dcompiler_47.dll DLL, it still registered as signed on Windows.

We reached out to Will Dormann, who holds a senior vulnerability analyst position at ANALYGENCE, regarding this conduct and shared the DLL with him. Dormann confirmed that the DLL is taking advantage of a security flaw, specifically CVE-2013-3900, which is a vulnerability in WinVerifyTrust Signature Validation.

On December 10th, 2013, Microsoft announced a weakness in their system. They noted that an attacker can add data to an authenticode signature section (WIN_CERTIFICATE structure) within a signed executable file without causing the signature to become invalid.

Dormann tweeted that the installation process of Google Chrome includes inserting information into the Authenticode structure to identify if you agreed to "share usage statistics and crash reports with Google." This data is later reviewed by Google Chrome during the installation process to determine whether or not diagnostic reports should be activated.

Microsoft made the decision to offer the solution as an option. This was probably because implementing the solution would make any genuine and authorized executable files invalid, which stored data in the signature area of an executable file.

Microsoft's statement regarding the CVE-2013-3900 details that on December 10, 2013, they rolled out an update for all versions of Microsoft Windows that alters the way in which signatures are authenticated for binaries that have been signed with the Windows Authenticode signature format.

You have the option to enable this change if you choose to.

If you activate it, the new feature for checking the Windows Authenticode signature will not accept any extra details in the WIN_CERTIFICATE formation. It will also disregard any binaries that do not comply with the signing rules.

After almost a decade, there are still many attackers using the vulnerability to their advantage. However, the solution to this problem is still not automatic and requires a manual adjustment of the Windows Registry.

If you're a Windows user who's running a 64-bit system and you want to implement the solution, you can modify the Registry using the steps below:

The code above is a configuration setting for the Windows Registry Editor Version 5.00. It specifies the path HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config and sets the value of "EnableCertPaddingCheck" to "1". This setting enables the padding check for certificates in the Windows operating system, which helps enhance security.

After activating these Registry keys, you'll be able to observe the distinct way in which Microsoft authenticates the signature of the harmful d3dcompiler_47.dll DLL that was involved in the 3CX supply chain breach.

Since the vulnerability has been utilized in recent assaults, like the 3CX distribution network and a Zloader malware spreading effort in January, it has become evident that repairing it is necessary, even if it causes disruption for the software creators.

Regrettably, many people are not aware of this weakness and often trust a harmful file without realizing it because Windows falsely labels it as trustworthy.

Dormann cautioned that if a solution is not mandatory, it will not safeguard the general public.

I turned on the extra solution, utilized my computer normally all day without encountering any problems that made me feel sorry for selecting it.

Although some installers (such as Google Chrome) may not appear as signed due to this, the increased protection is valuable enough to justify the inconvenience.

BleepingComputer attempted to contact Microsoft regarding the ongoing exploitation of this weakness and the fact that it is only available as an optional remedy. However, no response has been received yet.