Disable 3CX Unattended Upgrades (Linux)

What the 3CX supply chain remediation Worklet does

This Automox Worklet™ contains the March 2023 3CX supply chain compromise on Linux PBX servers. The attack, tracked publicly as the 3CXDesktopApp incident (CVE-2023-29059) and attributed to a North Korean threat actor, trojanized the signed 3CX Electron desktop client. Endpoints that fetched the installer from a compromised PBX received a backdoor that established C2 channels and downloaded follow-on malware. The Worklet closes the staging side of that delivery chain on the Linux PBX itself.

The Worklet stops the unattended-upgrades service so the PBX cannot pull another tainted build, captures a file listing of the current 3CX Desktop artifacts to /root/3cx-desktop-versions.log for forensic review, then removes the installer files staged for client download. The targeted directory is /var/lib/3cxpbx/Instance1/Data/Http/electron/, which the 3CX PBX serves to macOS clients (.dmg and .zip) and Windows clients (.msi and .nupkg). Existing infected files are deleted; vetted versions can be re-staged after a clean rebuild.

The Worklet runs as a one-shot incident response action. The evaluation script always exits 1 to force remediation, which is the right behavior for an attack-containment runbook that should not skip endpoints based on a probe. Activity output, including the systemctl result and the removal passes, surfaces in the Automox console for audit and after-action review.

Why contain the 3CX supply chain attack now

The 3CX compromise weaponized a signed installer that thousands of Linux PBX deployments were configured to serve to their downstream Mac and Windows clients. Until the trojanized .dmg, .zip, .msi, and .nupkg files are removed from /var/lib/3cxpbx/Instance1/Data/Http/electron/, the PBX is still capable of handing the malware to any client that hits the auto-update URL. Stopping unattended-upgrades blocks a second wave of poisoned builds; removing the staged artifacts cuts the active delivery path on the server you control.

The CVE-2023-29059 advisory names specific 3CX client builds and publishes the indicator-of-compromise list, but acting on it across every PBX server in the estate is the slow step. The Worklet collapses that response interval by disabling the auto-update path on each Linux 3CX host in scope and emitting hostname-level evidence in the activity log. The SOC, the incident response lead, and the auditor each get a deterministic record showing which servers were brought into compensating-control coverage and when.

How the 3CX containment Worklet works

1. Evaluation phase: The evaluation script unconditionally exits 1, which marks every targeted endpoint as non-compliant and queues remediation. This is intentional. Supply chain incident response should not depend on a probe that could be evaded by a renamed file or a partially cleaned directory; the Worklet forces remediation on every run until the policy is removed.

2. Remediation phase: The remediation script runs systemctl stop unattended-upgrades to halt the auto-update path, changes into /var/lib/3cxpbx/Instance1/Data/Http/electron/, and writes ls -la ./* to /root/3cx-desktop-versions.log so responders have a record of what was on disk before deletion. It then iterates over /var/lib/3cxpbx/Instance1/Data/Http/electron/osx/*.dmg, /osx/*.zip, /windows/*.msi, and /windows/*.nupkg and removes any matching files with /bin/rm -f. The script exits 0 once the file sweep completes.

3CX containment requirements

• Linux endpoint running a 3CX PBX install with files at /var/lib/3cxpbx/Instance1/

• Root privileges for the Automox agent so systemctl stop unattended-upgrades and rm under /var/lib/3cxpbx/ succeed

• systemd-based init (systemctl available); the script targets unattended-upgrades.service by name

• Read access to /root for the operator who will review /root/3cx-desktop-versions.log post-execution

• Companion endpoint policies queued for any Mac or Windows endpoint that may have already pulled the trojanized 3CX Desktop client (host scan, IoC sweep, controlled reinstall from a clean build)

Expected state after 3CX containment

The unattended-upgrades service is stopped, so the PBX will not pull another vendor build without an operator initiating it. The file /root/3cx-desktop-versions.log holds a directory listing of the 3CX Desktop staging path as it existed before deletion, including timestamps and sizes that responders can correlate against the published indicators of compromise. The /var/lib/3cxpbx/Instance1/Data/Http/electron/osx/ and /windows/ directories no longer contain the .dmg, .zip, .msi, or .nupkg installer artifacts that were the active delivery channel for the trojanized client.

The 3CX call platform itself keeps running. SIP traffic, voicemail, conferencing, and the management interface are unaffected, because the Worklet only touches the auto-update service and the downstream client installer staging path. End users on Linux SIP phones and softphones continue to place and receive calls normally; the only thing they cannot do is auto-update the Mac or Windows Desktop client from this PBX, which is the desired state during containment.

Validate by running systemctl is-active unattended-upgrades, which should return inactive, and by listing /var/lib/3cxpbx/Instance1/Data/Http/electron/osx/ and /var/lib/3cxpbx/Instance1/Data/Http/electron/windows/ to confirm the installer files are gone. Note that systemctl stop does not persist across a reboot; pair this Worklet with systemctl disable unattended-upgrades or a follow-up runbook if the PBX is expected to reboot before the vendor publishes a verified clean build. Compare /root/3cx-desktop-versions.log against the 3CX vendor advisory and CISA guidance for the affected version strings so responders can scope which downstream Mac and Windows endpoints need an IoC sweep. When a clean build is available, re-stage the installer through a controlled deploy rather than re-enabling unattended-upgrades, so the next vendor incident does not auto-deliver itself to the fleet.