3cx: lessons learned

The talk examines the 3CX incident, in which a VoIP software vendor shipped a trojanized desktop update to thousands of customers, some of whom then reported compromised internal systems. The speaker traces how the problem unfolded, from an endpoint security product flagging the software as suspicious, to community threads where the flag was dismissed as a false positive, to the vendor later confirming the malicious code. The incident is placed alongside earlier supply chain events such as SolarWinds and Codecov, and the speaker argues the pattern keeps repeating.

The middle section explains why common defenses fell short. Antivirus engines often rely on reputation and on partial scanning of large files, and sandboxes can stop at a fixed depth of nested archives or miss behavior that only appears later. The talk recommends reproducible builds so that artifacts can be compared bit for bit against an expected result, and diffing each release against the previous one to surface new network calls or unexpected behavior. It also covers typosquatted packages in public repositories and a Windows trust weakness, where a partially signed package can still validate.

For practitioners, the takeaways are to verify that build pipelines have not been tampered with, to test whether a release will trigger antivirus alerts before it ships, to keep a clear decision-maker ready during an incident, and to plan how customers will be told what happened. The speaker also suggests planting canary secrets to detect misuse of leaked credentials.