{"uuid": "82671a57-2f48-4ac6-a216-1b868d65523a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2013-3900", "type": "seen", "source": "https://t.me/hacking_Attack/96834", "content": "Black Hat Ethical Hacking\n10-Year-Old Windows vulnerability still being exploited in the 3CX attacks\n\n10-Year-Old Windows vulnerability still being exploited in the 3CX attacksPost Views: 2 Premium Contenthttps://www.blackhatethicalhacking.com/wp-content/uploads/2022/12/Patreon.png Subscribe to Patreon to watch this episode.\nReading Time: 3 Minutes A 10-year-old Windows vulnerability is still being exploited in attacksA 10-year-old Windows vulnerability is still being exploited by cybercriminals to make it appear that executables are legitimately signed, with the fix from Microsoft still \u201copt-in\u201d after all these years. Even worse, the fix is removed after upgrading to Windows 11, leaving devices vulnerable to supply chain attacks.\n\nOn Wednesday night, VoIP communications company 3CX confirmed that it was compromised to distribute trojanized versions of its Windows desktop application in a large-scale supply chain attack. The company urged all users of the Windows desktop application to uninstall it immediately and perform a malware scan.\n\nAccording to 3CX, two DLLs used by the Windows desktop application were replaced with malicious versions that download additional malware to computers, such as an information-stealing trojan. One of the malicious DLLs used in the attack is usually a legitimate DLL signed by Microsoft named d3dcompiler_47.dll. However, the threat actors modified the DLL to include an encrypted malicious payload at the end of the file.\n\nhttps://www.bleepstatic.com/images/news/Microsoft/vulnerabilities/CVE-2013-3900/shows-as-signed.jpg Modified DLL seen as having a valid signature\nSource: BleepingComputer\nSee Also: So you want to be a hacker? Offensive Security, Bug Bounty Courses Signed Windows DLL Exploits CVE-2013-3900 Flaw, Allowing Modifications to Appear AuthenticAs first noted by security researcher Will Dormann, even though the file was modified, Windows still showed it as correctly signed by Microsoft. Code signing an executable, such as a DLL or EXE file, is meant to assure Windows users that the file is authentic and has not been modified to include malicious code. When a signed executable is modified, Windows will display a message stating that the \u201cdigital signature of the object did not verify.\u201d However, even though we know that the d3dcompiler_47.dll DLL was modified, it still showed as signed in Windows.\n\nAfter contacting Dormann about this behavior and sharing the DLL, BleepingComputer was told that the DLL is exploiting the CVE-2013-3900 flaw, a \u201cWinVerifyTrust Signature Validation Vulnerability.\u201d Microsoft first disclosed this vulnerability on December 10th, 2013, and explained that adding content to an EXE\u2019s authenticode signature section (WIN_CERTIFICATE structure) in a signed executable is possible without invalidating the signature.\n\nMicrosoft ultimately decided to make the fix optional, likely because it would invalidate legitimate, signed executables that stored data in the signature block of an executable. \u201cThis change can be enabled on an opt-in basis,\u201d explains Microsoft\u2019s disclosure for the CVE-2013-3900. \u201cWhen enabled, the new behavior for Windows Authenticode signature verification will no longer allow extraneous information in the WIN_CERTIFICATE structure, and Windows will no longer recognize non-compliant binaries as signed.\u201d\n\nIt is now close to ten years later, with the vulnerability known to be exploited by numerous threat actors. Yet, it remains an opt-in fix that can only be enabled by manually editing the Windows Registry. To enable the fix, Windows users on 64-bit systems can make the following Registry changes:\n\nWindows Registry Editor Version 5.00\n[HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Cryptography\\Wintrust\\Config]\u201cEn[...]", "creation_timestamp": "2026-09-01T20:01:00.644038Z"}