3CX Supply Chain Attack — Full Technical Analysis

1. Sample Analysis — 3CX Supply Chain Attack Campaign

The 3CX Supply Chain Attack, publicly disclosed in March 2023, is regarded as one of the most sophisticated software supply chain compromises attributed to the Lazarus Group. Unlike traditional attacks that directly target victims, this operation focused on compromising a trusted software vendor and using its software distribution infrastructure to deliver malware to thousands of organizations worldwide.

Background

3CX is a software company that develops Voice over Internet Protocol (VoIP) communication solutions used by more than 600,000 organizations worldwide. Its desktop application is available for both Windows and macOS and is digitally signed to ensure authenticity and integrity. Because of its widespread adoption in enterprise environments, compromising the 3CX software supply chain provided the attackers with access to a large number of potential victims through a single trusted distribution channel.

Stage 1 — Initial Compromise

The attack did not begin at 3CX. According to the joint investigation conducted by Mandiant and 3CX, the attackers first compromised a 3CX employee's workstation through an earlier supply chain attack involving the X_TRADER financial trading software developed by Trading Technologies International, Inc.

Years before the 3CX incident, Lazarus had compromised the X_TRADER software distribution process, embedding malware within legitimate software updates. A 3CX employee installed the compromised application, unknowingly infecting their workstation. The malware established persistence, collected credentials, and allowed the attackers to maintain long-term access to the employee's system.

Stage 2 — Compromise of the Build Environment

After obtaining access to the employee's workstation, the attackers performed internal reconnaissance and harvested credentials that enabled them to move laterally within the corporate network. Eventually, they compromised the 3CX Continuous Integration and Continuous Delivery (CI/CD) build environment.

The CI/CD infrastructure is responsible for automatically compiling, testing, digitally signing, and publishing official software releases. By compromising this environment, the attackers gained the ability to modify legitimate application components before they were digitally signed and distributed to customers. Rather than stealing the company's code-signing certificate, the attackers inserted malicious components directly into the official build process, allowing the compromised software to retain its trusted digital signature.

Stage 3 — Trojanized Software Distribution

The attackers modified the Windows and macOS versions of the 3CX Desktop Application by replacing legitimate Dynamic Link Libraries (DLLs) with trojanized versions. When users installed or updated the software, the malicious DLLs were executed alongside legitimate application components without raising immediate suspicion. Because the software remained digitally signed by 3CX, endpoint security products and users generally trusted the application. Thousands of organizations unknowingly installed the compromised software during routine software updates.

Stage 4 — Multi-Stage Malware Execution

The trojanized application initiated a carefully designed multi-stage infection chain. During execution, malicious DLLs decrypted embedded shellcode that established communication with attacker-controlled infrastructure. The malware downloaded additional payloads only after performing victim profiling, reducing the likelihood of detection. Researchers identified several malware families associated with the operation, including:

• SIGFLIP — used to modify signed Portable Executable (PE) files while preserving their Authenticode signatures.
• DAVESHELL — a lightweight shellcode loader responsible for executing subsequent payloads in memory.
• VEILEDSIGNAL — a modular backdoor used to establish persistent command-and-control communications.
• ICONICSTEALER — an information-stealing malware deployed against selected victims.
• Gopuram — a sophisticated backdoor delivered only to high-value targets during later stages of the campaign.

This staged architecture allowed Lazarus to limit exposure by deploying advanced malware only to organizations considered strategically valuable.

Stage 5 — Target Selection

Unlike indiscriminate malware campaigns, the attackers carefully selected follow-on targets. The initial trojanized software acted as a filtering mechanism. Systems meeting predefined criteria received additional malware capable of credential theft, intelligence collection, and long-term remote access. Victims included organizations operating in sectors such as financial services, information technology, government, aerospace, and critical infrastructure.

Discovery

The attack was first identified in March 2023 after security researchers observed suspicious behavior associated with the signed 3CX Desktop Application. Subsequent investigations by multiple cybersecurity vendors, including Mandiant, SentinelOne, CrowdStrike, Sophos, Elastic Security, and Kaspersky, revealed that the application had been compromised during the software build process rather than after distribution.

The investigation also uncovered the connection between the 3CX compromise and the earlier X_TRADER supply chain attack, demonstrating how Lazarus leveraged one software supply chain compromise to facilitate another.

The campaign remains one of the most significant examples of a modern software supply chain attack and illustrates the growing importance of securing software development pipelines, code-signing processes, and CI/CD infrastructure against nation-state adversaries.

2. Technical Analysis

Phase 0 — Attack Execution Overview

Before analyzing the individual malware components, it is important to understand how they interact throughout the 3CX supply chain attack. Unlike conventional malware campaigns that rely on a single executable, the 3CX attack employed a multi-stage execution chain in which each component was responsible for loading or enabling the next stage.

The attack originated from a previously compromised X_TRADER installation, which provided the attackers with initial access to a 3CX employee's workstation. After compromising the company's CI/CD build environment, Lazarus inserted malicious components into the signed 3CX Desktop Application. When the application was executed, a sequence of malicious DLLs, shellcode, and payloads were loaded, ultimately leading to the deployment of advanced backdoors on selected victim systems.

The following sections analyze each component in the order it executes during the attack.

Phase 1 — X_TRADER Supply Chain

The first stage of the attack begins with the trojanized X_TRADER application, which served as the initial access vector into the 3CX environment. By compromising the software supply chain of X_TRADER, Lazarus Group was able to execute malicious code on a 3CX employee's workstation while the application appeared legitimate.

This initial compromise provided the attackers with a foothold inside the corporate network, allowing them to establish persistence, collect system information, and ultimately obtain access to the 3CX CI/CD build environment. The following analysis examines the malicious X_TRADER sample to identify its execution flow, capabilities, and role in the overall attack chain.

Starting the analysis of X_TRADER

The analyzed sample is a 32-bit Portable Executable (PE32) designed to run on Microsoft Windows. The executable targets the x86 architecture and uses the Windows GUI subsystem, indicating that it is intended to execute as a graphical application rather than a console program.

Compiled using Microsoft VS Code, it only imports four libraries: Kernel32.dll, SHELL32.dll, ole32.dll, OLEAUT32.dll. From these libraries, some of its functionalities can be inferred:

• Dynamic API loading (LoadLibraryExW, GetProcAddress)
• File operations (CreateFileW, ReadFile, WriteFile, CopyFileW, DeleteFileW)
• File discovery (FindFirstFileExW, FindNextFileW)
• Memory management (HeapAlloc, HeapReAlloc, HeapFree)
• Process information (GetCurrentProcess, GetCurrentProcessId, GetCurrentThreadId)
• Anti-analysis (IsDebuggerPresent, QueryPerformanceCounter)
• COM initialization (CoInitializeEx, CoCreateInstance)
• BSTR/VARIANT handling (SysAllocString, VariantClear, SysFreeString, VariantCopy)
• Shell execution (ShellExecuteExW)

It also has data stored in the resource section with a size of 001e1048.

Moving to IDA to confirm this functionality: uploading the sample to IDA and starting at the WinMain function, the function has only three calls. The program begins execution by calling a function that, based on its return value, decides whether to proceed to the next function or jump to the third.

Entering the first function, sub_401090, the malware begins by allocating and initializing several buffers used throughout the routine. It then retrieves the full path of the running executable and locates the last directory separator ('\') to isolate the installation directory. Using this path, it constructs the full path to X_TRADER-ja.mst.

Next, the malware opens X_TRADER-ja.mst, moves the file pointer to offset 0x167000, and reads the embedded encrypted payload. It then creates a new directory named TPM under C:\ProgramData. After creating the directory, the malware copies immersivetpmvscmgrsvr.exe into the newly created location and renames it to TpmVscMgrSvr.exe. Finally, it creates a new DLL named devobj.dll within the same directory, which is later populated with the decrypted payload extracted from X_TRADER-ja.mst.

The malware proceeds to decrypt an embedded payload from X_TRADER-ja.mst into a temporary memory buffer. Once the decryption process is complete, the recovered payload is written to devobj.dll, preparing it for execution in the next stage of the attack.

At this point, the first function completes its execution, and control is transferred to the second function, sub_4013C0. The function begins by constructing the full path C:\ProgramData\TPM\TpmVscMgrSvr.exe. It then initializes the COM library and creates an instance of the Task Scheduler COM object using the CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}, while requesting the ITaskService interface identified by the IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85} through CoCreateInstance().

Since COM methods are invoked through a virtual function table (vtable), the imported interface can be reconstructed using the ITaskService method offsets shown below. This mapping allows the indirect calls observed during reverse engineering to be resolved to their corresponding COM methods.

The malware initializes four empty VARIANT structures using VariantInit(). These VARIANTs are later passed as arguments to the first method retrieved from the ITaskService COM interface. Before the call, the compiler copies each VARIANT onto the stack, after which the malware invokes the function located at offset 0x28 in the ITaskService vtable, corresponding to ITaskService::Connect(). By passing empty VARIANTs, the malware connects to the local Task Scheduler service using the current user's security context without explicitly specifying a server, username, domain, or password.

The malware abuses the COM object to establish persistence by creating a scheduled task within the \Microsoft\Windows\TPM folder. It sets the task author to "Microsoft Corporation" to imitate a legitimate Microsoft task and configures an execution action that launches C:\ProgramData\TPM\TpmVscMgrSvr.exe. The task also uses the identifier Tpm-VscMgr, further reinforcing the appearance of a legitimate TPM-related scheduled task.

Task Scheduler

Name:        Tpm-VscMgr
Author:      Microsoft Corporation
Action:      C:\ProgramData\TPM\TpmVscMgrSvr.exe

Moving to the third function, the malware begins by searching the resource section for an embedded payload. After locating the appropriate resource, it loads the encrypted data into memory. The malware then retrieves the full path of X_TRADER.exe, opens the executable, and decrypts the embedded payload using the XOR key 0x0DA39F274. The decrypted code is written into the target executable, effectively patching it with the malicious payload extracted from the resource section. Once the modification is complete, the malware executes the newly patched X_TRADER.exe and finally deletes its original executable from disk to remove traces of the initial infection.

Phase 2 — 3CXDesktopApp.exe

Unlike the previously analyzed X_TRADER sample, 3CXDesktopApp.exe does not contain the primary malicious functionality. Static and dynamic analysis, along with multiple public threat intelligence reports, show that the executable remains a legitimate, digitally signed 3CX application. Its role in the attack is to act as a trusted loader for the malicious components deployed by the attackers.

During startup, the application follows its normal initialization process and loads its required dynamic-link libraries (DLLs). Due to the supply-chain compromise, the legitimate ffmpeg.dll included with the application was replaced with a trojanized version. As a result, when 3CXDesktopApp.exe starts, the Windows loader automatically loads the malicious ffmpeg.dll, transferring execution to the attacker's code while the application continues to function normally from the user's perspective.

Therefore, the analysis of 3CXDesktopApp.exe focuses primarily on its role in initiating the execution chain rather than implementing the malicious logic itself. The actual payload execution begins inside the trojanized ffmpeg.dll, which is analyzed in the next phase.

Phase 3 — Trojanized ffmpeg.dll

Starting the analysis of the trojanized ffmpeg.dll, the DLL was loaded into IDA for static analysis. The entry point contains only a single function call, which immediately transfers execution to the DLL's primary initialization routine. As a result, the remainder of the analysis focuses on this function, where the malicious behavior is implemented.

Going deeper into the primary initialization routine to determine the purpose of the trojanized ffmpeg.dll, the malware begins by creating a named event called AVMonitorRefreshEvent using CreateEventW(). Immediately afterward, it calls GetLastError() to determine whether the event already exists. If GetLastError() returns ERROR_ALREADY_EXISTS (0xB7), the malware concludes that another instance is already running and terminates its execution. This mechanism acts as a single-instance check, ensuring that only one instance of the DLL executes at a time.

Moreover, the malware retrieves the full path of the running module and locates the last directory separator ('\') to obtain the application's installation directory. It then appends the string d3dcompiler_47.dll to construct the full path to the target DLL. The file is opened using CreateFileW() with GENERIC_READ access, OPEN_EXISTING disposition, and FILE_ATTRIBUTE_NORMAL attributes. The malware then reads the DLL from disk into memory.

Afterward, the malware parses the contents of d3dcompiler_47.dll in search of the byte sequence FE ED FA CE, which serves as a marker indicating the beginning of the embedded shellcode. Once this signature is located, the malware extracts the encrypted payload and decrypts it using the RC4 stream cipher with the hardcoded key 3jB(2bsG#@c7. The decrypted shellcode is a downloader that retrieves icon files from a GitHub repository at https://raw.githubusercontent[.]com/IconStorages/images/main/, which are later used to download the final payload.

Phase 4 — GitHub Dead Drop Resolver

Each downloaded ICO file contains an embedded, encoded configuration rather than a standard icon resource. The malware parses the files, extracts the hidden data, and decodes it to recover the command-and-control (C2) configuration used by the final-stage payload. This technique enables the attackers to distribute updated C2 information through seemingly benign icon files hosted on remote servers.

Phase 5 — VEILEDSIGNAL

Moving to the final phase, VEILEDSIGNAL, the malware begins by retrieving workstation network information using the NetWkstaGetInfo() API, obtaining both the hostname and the domain name. It then loads ntdll.dll and resolves the RtlGetVersion API to retrieve the operating system version. Afterward, the malware obtains the path to the AppData\Roaming directory and appends \3CXDesktopApp\config.json to construct the full path to the configuration file. The malware then opens config.json, reads its contents into memory, and constructs a new JSON object by appending the previously collected system information, including the hostname, domain name, operating system version, and the data from the config.json file.

The malware targets the browsing history of several Chromium- and Gecko-based web browsers, including Google Chrome, Microsoft Edge, Brave, and Mozilla Firefox. It locates each browser's profile directory and accesses the corresponding history database (History for Chromium-based browsers and places.sqlite for Firefox). The malware then executes SQL queries to retrieve the 500 most recent visited URLs and their associated page titles, appending the extracted information to the in-memory JSON buffer for later use.

3. Campaign IOC Summary

All indicators extracted across every analyzed component of the 3CX supply chain attack.

In addition to the network and host-based indicators above, VEILEDSIGNAL targets the following browser profile paths and databases for history collection:

-- Chromium-based browsers
SELECT url, title FROM urls ORDER BY id DESC LIMIT 500

-- Firefox
SELECT url, title FROM moz_places ORDER BY id DESC LIMIT 500

4. MITRE ATT&CK Mapping — Full Campaign

Complete mapping of the 3CX supply chain campaign to MITRE ATT&CK techniques.

5. Conclusion & Recommendations

The 3CX supply chain attack illustrates how Lazarus Group leverages a chain of trust — compromising one vendor (X_TRADER) to reach another (3CX) — to gain scalable initial access without directly touching the end victim. Because the trojanized components were inserted during the signed build process rather than after distribution, traditional signature and reputation-based trust models failed to flag the malicious DLLs.

• Block and monitor the domains and IPs listed in the IOC summary at the DNS/firewall layer.
• Hunt for the file, registry, and scheduled task artifacts listed above across endpoints, particularly the Tpm-VscMgr scheduled task and the C:\ProgramData\TPM\ directory.
• Treat unexpected outbound connections to raw.githubusercontent.com or unusual ICO downloads from business applications as suspicious, since dead-drop resolvers abuse trusted platforms to blend in with normal traffic.
• Harden CI/CD build environments with code-signing integrity checks, build provenance attestation, and strict access controls, since this was the actual point of compromise rather than the distribution channel itself.
• Apply enhanced scrutiny to third-party software updates from vendors handling sensitive financial or communications infrastructure, and validate signed binaries against known-good hashes where possible.

References

• Mandiant / Google Cloud – 3CX Software Supply Chain Compromise Initiated by a Previous Software Supply Chain Compromise
• Google Cloud Threat Intelligence – 3CX Supply Chain Compromise: Follow-on Activity
• SentinelOne – 3CX Supply Chain Attack Analysis
• CrowdStrike – 3CX DesktopApp Supply Chain Compromise
• Elastic Security Labs – 3CX Supply Chain Attack Research
• Sophos X-Ops – 3CX Supply Chain Attack Analysis
• Kaspersky Securelist – Gopuram Backdoor Deployed Through the 3CX Supply Chain Attack
• MITRE ATT&CK – Lazarus Group (G0032)