Disable 3CX Unattended Upgrades (Windows)

What the 3CX client containment Worklet does

This Automox Worklet™ contains the compromised 3CX Desktop App on Windows endpoints by stopping the trojanized client and disabling its launch paths. The remediation script calls Get-Process -Name 3CXDesktopApp and, when a match is found, invokes Stop-Process -Name 3CXDesktopApp -Force to kill the running client before it can complete its second-stage download cycle.

After the process is terminated, the Worklet walks four installation paths: C:\Users\*\AppData\Local\Programs\3CXDesktopApp\3CXDesktopApp.exe, C:\Users\*\AppData\Local\Programs\3CXDesktopApp\Update.exe, C:\Program Files\3CXDesktopApp\3CXDesktopApp.exe, and C:\Program Files\3CXDesktopApp\Update.exe. For every match returned by Get-Item, the script appends _RENAMED to the filename using Rename-Item, so the auto-update loop cannot relaunch the trojanized binary on the next user logon.

The user-profile glob (C:\Users\*) is what makes this Worklet safe to run on shared workstations and Citrix or Windows Server multi-user hosts. A single execution disables the client in every profile that ever installed it, regardless of which account is logged in at run time. The script writes a status line to stdout for every match it renames, which lands in the Automox activity log so you can audit which endpoints needed cleanup.

Why contain the 3CX supply-chain compromise

On 29 March 2023, 3CX confirmed that the Windows Electron client (versions 18.12.407 and 18.12.416) shipped from its signed update channel had been trojanized with the SmoothOperator loader, tracked as CVE-2023-29059. The malicious build sideloaded ffmpeg.dll and d3dcompiler_47.dll, decrypted an embedded payload, and reached out to an attacker-controlled GitHub repository to pull ICO files containing the second-stage command-and-control configuration. Because the installer was Authenticode-signed by 3CX, EDR and application-allowlisting tools treated the binary as trusted.

Vendor patch guidance closes the door for new installs but leaves the existing 3CXDesktopApp.exe and its bundled Update.exe sitting on every workstation that already pulled an affected build. Until those binaries are removed or renamed, the local auto-updater can relaunch the trojanized client on the next user logon. This Worklet kills the process, renames the executables in place, and records each path it touched in the Automox activity log, giving the SOC an auditable per-endpoint record of containment coverage during the response window.

How 3CX client containment works

1. Evaluation phase: The evaluation script exits 1 unconditionally so the policy always advances to remediation. This is intentional for incident-response Worklets: idle endpoints with no install path will simply find no Get-Item matches and exit cleanly, while affected endpoints get the full containment in the same policy run. Pair this Worklet with a recurring policy if you want repeated sweeps of new endpoints onboarding into Automox.

2. Remediation phase: The remediation script calls Get-Process -Name 3CXDesktopApp -ErrorAction SilentlyContinue and pipes a match to Stop-Process -Force. It then iterates a list of four file paths covering per-user installs under %LOCALAPPDATA%\Programs\3CXDesktopApp and the machine-wide install under C:\Program Files\3CXDesktopApp. For each Get-Item hit, Rename-Item appends _RENAMED to the filename. Missing files raise no error because every Get-Item call uses -ErrorAction SilentlyContinue.

3CX client containment requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, or 2022 with PowerShell 5.1 or later

• Local administrator privileges (the Automox agent context already meets this) so the script can call Stop-Process and Rename-Item on per-user and Program Files paths

• FixNow execution recommended for the initial containment sweep so the trojanized client is killed without waiting for the next scheduled policy window

• Companion EDR or threat-hunting policy to follow up on indicators of compromise from the SmoothOperator second stage (ffmpeg.dll hash, d3dcompiler_47.dll modification, ICO callbacks to attacker GitHub repos)

• A change record or notification path so end users know the 3CX client has been intentionally disabled and that voice traffic should fail over to the web client or mobile app until a clean version is redeployed

Expected endpoint state after containment

On a previously affected endpoint, Get-Process -Name 3CXDesktopApp returns no result and the four target paths contain renamed files such as 3CXDesktopApp.exe_RENAMED and Update.exe_RENAMED. Double-clicking the original shortcut no longer launches the client because Windows cannot resolve the original target. The Automox activity log lists each Found 3CX Desktop App Files at '<path>', Renaming it... line emitted by the script, giving you a per-endpoint audit trail of which paths were active before remediation.

On endpoints that never had 3CX installed, the script exits cleanly with no output beyond the process check, and no files are touched. This makes the Worklet safe to run against the entire Windows fleet as a broad sweep rather than a curated target group. Re-running the Worklet later is idempotent: the renamed files no longer match Get-Item against the original paths, so a second execution produces no additional changes.

When you are ready to restore voice service, redeploy the 3CX Desktop App from a vendor-validated, post-incident build (3CX guidance pinned versions later than 18.12.416 once a clean release shipped). Push the new installer through your standard software-deployment policy so the install lands on a clean filesystem state and inventory shows a uniform version across the fleet. Treat the renamed files as forensic artifacts: archive them with your incident response evidence before sweeping them with a cleanup Worklet.