A valid code signature proves who signed a file, not that the file is harmless. Mandiant's analysis of the 3CX incident found that the first step was a tampered X_TRADER installer, signed with a certificate issued to its publisher. Signatures are one input to trust, not a verdict.
What Mandiant reported
Mandiant's 20 April 2023 write-up says the initial intrusion into 3CX came from malicious software downloaded from the Trading Technologies website. The file was a tampered installer for X_TRADER. According to the page, X_TRADER was reportedly discontinued in 2020 but was still downloadable in 2022, and the installer carried a signature from a certificate issued to Trading Technologies International, Inc, due to expire in October 2022.
From there the page describes a chain: a backdoor called VEILEDSIGNAL, lateral movement inside 3CX, theft of credentials, and compromise of both the Windows and macOS build environments. The trojanized 3CX DesktopApp, version 18.12.416 and earlier, was then distributed from 3CX's own website.
Mandiant states this is the first software supply chain attack it had seen lead to another software supply chain attack.
What a signature does and does not tell you
A signature tells you that someone with access to a signing key vouched for these bytes, and that they have not changed since. It cannot tell you:
- that the build environment was clean when the file was signed
- that the signer's download site was not serving a swapped file
- that the software still deserves a place on a developer or build machine
Here the signature was real. The problem sat upstream of it.
Questions this suggests for your own estate
Retired software is a risk of its own. The report notes an application discontinued years earlier was still being distributed. Ask what old installers and tools your engineers still download, and from where.
Next, separate build machines from ordinary workstations. An attacker who lands on a build host can sign and ship what they like. Limit what runs there and what network paths it has.
Finally, treat vendor software on privileged machines like a dependency, with a reason to be there and an owner.
A practical routine
- List software installed on build and release hosts, including tools used once.
- Remove anything discontinued or unowned.
- Keep installers from a controlled internal source, with hashes recorded.
- Alert on new outbound destinations from build hosts.
- Re-check any vendor that signs and distributes tools you run with high privilege.
Where Safeguard fits
Safeguard's policies and gates can block builds that bring in components you have not approved, and asset discovery helps find what is running. Neither detects a trojanized installer by itself, so keep hash checks in the routine.
Quick check
Did Mandiant name affected customers?
No. The page describes the affected software and 3CX's compromised build environments but gives no customer list or count.
What was the affected 3CX version?
DesktopApp 18.12.416 and earlier, as distributed from 3CX's website, per Mandiant.
Sources
Last reviewed: 19 October 2026.
