mythsthe wider record3CX2023business communications software / supply chain

everyone assumed:

a signed update from our vendor is safe to install

what was actually true:

A signature proves who built the software, not what happened to it before they built it.

how it happened

  1. whoattackerstampered X_TRADER package
  2. the gap3CX build environmentmalicious code before signing
  3. thensigned desktop updateauthentic to every machine
  4. the resultcustomers worldwidetrojanised app calling home
the gap that let it happen the result

what everyone assumed

A signed update from a trusted vendor is the safe path, so safe that most organizations set it to happen automatically. The whole point of code signing is to answer the question “is this really from them,” and when the answer is yes, the natural conclusion is that the update is fine to install. That trust is how the entire software supply chain is designed to work, and refusing every auto-update would break far more than it would protect.

what happened

The malicious code did not slip past the signature; it was inside the build before the signature was applied. 3CX’s desktop app for Windows and macOS, version 18.12.416 and earlier, shipped with injected libraries that were signed with the developer’s own certificate during the normal build process. To every machine that received it, the update was authentic. Mandiant, brought in to investigate, later traced the root cause to a second supply-chain compromise upstream: a 3CX employee had earlier installed a tampered version of an unrelated software package, X_TRADER, which is how the attackers reached the build environment in the first place. One legitimately signed update was quietly carrying the output of a breach that had started somewhere else entirely.

step by step

  1. an employee installs a tampered X_TRADER packageAn unrelated piece of software, itself compromised upstream, gives the attackers a way in.
  2. attackers reach the build environmentMalicious libraries are injected before the signing step.
  3. the app is signed with 3CX's own certificateVersion 18.12.416 and earlier ships to Windows and macOS looking fully authentic.the assumption breaks here
  4. late March 2023vendors spot the app calling attacker servers3CX pulls the builds. On 20 April Mandiant publishes the double supply-chain entry.

how it surfaced

The compromise surfaced in late March 2023, flagged by security vendors watching the trojanized app reach out to attacker infrastructure. 3CX confirmed the incident and pulled the affected builds; on April 20, Mandiant published the initial intrusion vector, the first time it had seen one software supply-chain attack lead to another. The product served a large base of business customers across many industries. The assumption retired itself the moment a valid signature turned out to certify who wrote the code, and nothing about whether it was safe.

A signature proves who built the software, not what happened to it before they built it.

Trust in a vendor’s identity is not the same as trust in a vendor’s build, and an attacker who reaches the build inherits the signature for free.

picture it at a company like yours

The company here is made up. The other two paths are not: they happened, and each links to the story.

your company
a normal dayYour phone system or accounting app updates itself overnight, and nobody thinks twice because the update is signed.
the gap nobody seesNobody checks what an update contains before it reaches every laptop at once.trusting what a supplier ships
  1. in this story
    the day it mattersThe vendor itself is breached and ships a poisoned update with its genuine signature.
    what it costs youEvery machine in the office installs it the same night, and your own IT team approved nothing.
  2. or it goes like this
    howA genuine, signed update from a certified vendor carries a backdoor.
    what leavesa quiet way into your networkwho ends up with ita state intelligence service
    it happenedSolarWinds / Sunburst, 2020
  3. or it goes like this
    howA build helper everyone uses is hijacked and its versions repointed.
    what leavessecret keys, printed into build logswho ends up with itanyone reading public logs
    it happenedtj-actions/changed-files, 2025

sources

  1. 3CX, "Security Update Thursday 20 April 2023, Initial Intrusion Vector Found" ,
  2. Krebs on Security, "3CX Breach Was a Double Supply Chain Compromise" ,
  3. Google Cloud / Mandiant, "3CX Software Supply Chain Compromise" ,
  4. The Register, "An earlier supply chain attack led to the 3CX compromise" ,

← all myths

your turn

what you can do about it

  1. this week

    List the critical applications that auto-update with no staging, no delay and no way to roll back.

    Your software updates itself because the updates are signed, which is the reason no one reviews them. The quiet-months question is what you would do if a signed update turned out to be the incident: this week, look at which of your critical applications auto-update with no staging, no delay, and no way to roll a bad version back. The 3CX customers who fared best were the ones who could answer that before the update asked to install.

  2. go deeper

  3. if you're not sure where to start

    Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.

    open the checklist →

the letter · every two weeks

one access gap in your inbox, with the fix.

Every issue takes one way access creeps in, shows a real incident where it went wrong, and ends with one thing to check that week. Written for the people who run the tools, without a security team behind them.

  • 1one mechanism, explained plainly
  • 2one real incident, taken apart
  • 3one step you can take on Monday

get the next issue

One email every two weeks. Your address stays here and is never passed to vendors. One click to unsubscribe. Privacy.