3CX Supply Chain Attack: Investigating a Multi-Stage Compromise

Investigations linked the incident to a multi-stage compromise involving a prior compromise of the software supply chain associated with Trading Technologies software. The 3CX incident demonstrated how an initial compromise can become a stepping stone to a second supply chain attack.

The campaign involved malicious application components, staged payload delivery, command-and-control communications, and selective follow-on activity. It highlighted the importance of examining software provenance, process behaviour, network activity, and the relationships between apparently separate incidents.

1. Introduction: When One Supply Chain Compromise Leads to Another

Organisations rely on trusted software to conduct daily business. Communication platforms, endpoint applications, and collaboration tools often have broad deployment across enterprise environments, making them attractive targets for attackers.

The 3CX incident demonstrated the risks associated with this trust.

In March 2023, malicious versions of the 3CX DesktopApp were identified. Users and organisations had obtained the application through legitimate distribution channels, but affected versions contained malicious components capable of initiating additional stages of an attack.

What made the incident particularly significant was the connection to an earlier compromise. Investigators linked the 3CX campaign to a previous software supply chain compromise involving Trading Technologies software.

Rather than attacking every victim individually, the adversaries exploited trusted software distribution to reach downstream organisations.

The incident is a useful case study for SOC analysts because it combines supply chain risk, endpoint investigation, multi-stage malware behaviour, and command-and-control detection.

2. Understanding the Attack Chain

A multi-stage compromise separates an intrusion into distinct phases. Each phase may perform a different function, from initial delivery to payload execution and subsequent access.

In the 3CX incident, the broad sequence can be understood as follows:

1. Earlier compromise: A prior compromise associated with Trading Technologies software was linked to the subsequent 3CX campaign.

2. Software distribution compromise: Malicious components were incorporated into affected 3CX DesktopApp versions.

3. Initial execution: Users launched the compromised application, allowing the malicious components to execute.

4. Payload staging: The malware used additional components and staged execution to progress beyond the initial infected application.

5. Command-and-control: Infected systems communicated with attacker-controlled infrastructure.

6. Selective follow-on activity: Additional malicious activity was observed in some environments, with the extent and impact varying between victims.

This sequence is a high-level model of the campaign. Not every affected installation necessarily experienced every stage, and investigators must validate each phase using evidence from the specific environment.

3. Stage One: The Earlier Software Compromise

The 3CX campaign attracted particular attention because threat researchers connected it to an earlier supply chain incident involving Trading Technologies software.

The relationship illustrated a difficult security problem: an organisation can become a victim of a supply chain attack and subsequently become a delivery mechanism for another attack.

In this scenario, the adversary's access to one part of the software ecosystem was linked to a later compromise affecting another vendor.

Why this matters

Traditional vendor-risk assessments often evaluate each supplier independently. However, modern software environments contain interconnected dependencies, including software libraries, development systems, update channels, and third-party applications.

An upstream compromise can therefore have consequences beyond the original vendor.

Investigation questions

SOC and incident-response teams should establish:

• Which software products and versions were installed?

• Were any affected versions obtained or executed?

• Is there evidence of malicious activity before the 3CX application was installed?

• Did other software from the same environment exhibit suspicious behaviour?

• Are there shared indicators or infrastructure connecting separate incidents?

A confirmed relationship between campaigns should be based on reliable threat-intelligence analysis, not simply the presence of similar malware behaviour.

4. Stage Two: Trojanised 3CX DesktopApp Distribution

The affected 3CX DesktopApp versions were distributed through channels that users and organisations normally trusted.

The malicious application components enabled the campaign to move beyond an ordinary software installation. The initial application acted as the entry point for additional malicious behaviour.

This was a critical distinction: the presence of a legitimate vendor name or a familiar installation process did not guarantee that the installed software was safe.

Why ordinary security checks may fail

Security tools that rely primarily on file reputation or known malware signatures may not immediately identify a newly compromised software package.

A legitimate application can also generate expected network traffic, making it harder to distinguish malicious communications from routine application activity.

For this reason, defenders should evaluate both software integrity and runtime behaviour.

SOC investigation focus

Review:

• Application version and installation source.

• File hashes and digital-signature information.

• Software deployment and update records.

• First execution time and associated user account.

• Process lineage and unusual child processes.

• Network activity originating from the application.

• Whether the installed binary matches a trusted vendor-provided reference.

A valid digital signature should be treated as one piece of evidence, not as proof that an application is benign.

5. Stage Three: Payload Staging and Execution

The 3CX campaign involved multiple stages rather than relying on a single executable to perform every action.

The compromised application used malicious components to progress through the attack chain. In affected Windows environments, investigators examined the use of a malicious DLL associated with the compromised application and subsequent payload execution. The macOS variant also involved a distinct set of malicious components and behaviours.

This distinction matters during investigation because the Windows and macOS attack paths should not be assumed to be identical.

Why staged execution is effective

Staged malware can separate its initial execution from later activities. An initial component may establish a foothold or retrieve additional content, while later components perform more specialised functions.

This approach can make detection more difficult when monitoring focuses only on the first executable or a single known file hash.

What analysts should examine

For Windows endpoints:

• Process creation and parent-child relationships.

• DLL loading and unexpected module activity.

• File creation and modification around application startup.

• Script interpreters or system utilities launched unexpectedly.

• Outbound connections associated with the affected application.

• Unusual activity under the account that launched the software.

For macOS endpoints:

• Application bundle contents and integrity.

• Unexpected child processes.

• Suspicious file writes and downloaded components.

• DNS queries and outbound connections.

• Execution events and security telemetry available through endpoint monitoring.

The objective is to reconstruct the sequence of execution and determine whether the application progressed beyond normal behaviour.

6. Stage Four: Command-and-Control Communications

Command-and-control (C2) infrastructure allows malware to communicate with attacker-controlled systems. Depending on the campaign, these communications may support payload delivery, tasking, or further malicious operations.

The 3CX investigation involved network indicators associated with the compromised applications and subsequent stages.

Why C2 detection is challenging

Business communication applications commonly connect to external infrastructure. As a result, an outbound connection alone does not establish malicious activity.

Analysts must correlate the destination with the originating process, domain resolution, timing, application version, and other indicators.

Network investigation checklist

Examine:

• DNS queries generated by affected endpoints.

• Connections to newly observed or suspicious domains.

• Unusual destinations contacted shortly after application startup.

• Repeated or periodic outbound communications.

• Unexpected changes in connection patterns after a software update.

• Connections associated with suspicious child processes.

• Similar communications from other endpoints running the same application version.

Where possible, compare the results against vendor advisories and campaign-specific indicators from trusted threat-intelligence sources.

Avoid blocking domains solely because they are unfamiliar. Validate their context, reputation, and relationship to the suspected incident.

7. Stage Five: Selective Follow-On Activity

The presence of a compromised application does not automatically prove that the attacker achieved broader access.

In some affected environments, the campaign progressed beyond the initial infection. Investigators reported follow-on activity consistent with attempts to conduct additional operations against selected targets.

This makes scoping a critical part of incident response.

Questions to answer

• Did the malicious application retrieve or execute additional payloads?

• Were credentials or sensitive files accessed?

• Did the endpoint communicate with other internal systems unexpectedly?

• Were new persistence mechanisms created?

• Were privileged accounts used from unusual locations?

• Is there evidence of lateral movement or access to sensitive resources?

Analysts should distinguish between confirmed activity, plausible hypotheses, and actions for which evidence is unavailable.

A system with a compromised application may require remediation even when no further activity is identified, but the incident's severity and scope should reflect the evidence.

8. SOC Investigation: A Step-by-Step Workflow

A structured investigation helps analysts move from an initial software alert to a defensible incident assessment.

Step 1 — Establish software exposure

Use software inventory, endpoint management records, and vendor advisories to identify potentially affected 3CX DesktopApp installations.

Record the operating system, application version, installation source, first-seen date, user, and device name.

Do not assume that all versions or all installations were affected.

Step 2 — Validate the binary

Collect relevant file hashes, signature information, timestamps, and application bundle details.

Compare the findings with trusted vendor or incident-response references. Preserve copies and metadata according to organisational forensic procedures.

A file hash can establish whether a binary matches a known sample, but it cannot independently prove whether the system experienced later stages of the attack.

Step 3 — Build the execution timeline

Correlate application launch events with file activity, module loading, process creation, and network connections.

On Windows, Security Event ID 4688 may provide process-creation evidence when the appropriate audit policy is enabled. EDR telemetry may supply richer process lineage and command-line details.

On macOS, use the available EDR and system telemetry to reconstruct application execution and associated activity.

Step 4 — Investigate network activity

Review DNS, proxy, firewall, and endpoint network logs for communications associated with the affected application.

Compare the observed activity with known campaign indicators and the organisation's normal application traffic.

Pay particular attention to connections that occur immediately after unexpected process or file activity.

Step 5 — Assess identity exposure

Review authentication activity associated with the affected endpoint and its user account.

Investigate suspicious logons, unusual privilege use, and unexpected access to sensitive applications or systems.

Potential Windows Security events include:

• 4624: Successful logon.

• 4625: Failed logon.

• 4648: Logon attempted using explicit credentials.

• 4672: Special privileges assigned to a new logon.

These events are contextual evidence. They do not independently establish that credentials were stolen or that lateral movement occurred.

Step 6 — Hunt across the environment

Search for other endpoints that share the same affected application version, file hashes, suspicious process patterns, or network indicators.

Use SIEM and EDR telemetry to determine whether the activity is isolated or widespread.

A practical hunt should consider both exact indicators and behavioural patterns. Exact hashes are useful for identifying known samples, while behavioural searches can identify related activity that uses different files or infrastructure.

Step 7 — Contain, eradicate, and recover

If compromise is confirmed or strongly suspected, follow the incident-response plan.

Potential actions include isolating affected endpoints, stopping malicious execution, removing compromised software, collecting forensic evidence, checking for persistence, and rotating credentials where evidence or exposure justifies it.

Install trusted versions of the application only after verifying the appropriate vendor guidance. If evidence indicates broader compromise, investigate and remediate that activity separately rather than assuming application replacement resolves everything.

9. Evidence and Indicators to Collect

No single indicator is sufficient to identify every stage of the 3CX attack. The investigation should combine software, endpoint, network, and identity evidence.

Evidence sourceWhat to collectPurposeSoftware inventoryProduct version, deployment source, installation timeIdentifies potentially exposed systemsFile metadataHashes, signatures, timestamps, bundle contentsValidates suspicious softwareEDR telemetryProcess trees, DLL loads, file writes, execution eventsReconstructs staged executionDNS logsQuery names, timestamps, resolved addressesIdentifies suspicious domain activityFirewall and proxy logsDestination, process attribution, connection timingInvestigates possible C2 communicationsWindows and macOS logsExecution and system activityEstablishes host-level contextIdentity logsAuthentication and privileged accessAssesses potential account exposureThreat intelligenceCampaign-specific domains, hashes, and infrastructureCorrelates local evidence with known activity

Use campaign-specific indicators from authoritative incident-response reports. Do not substitute generic suspicious domains or invented file hashes for validated indicators.

10. MITRE ATT&CK Mapping

The following mappings may be relevant to a 3CX-style supply chain compromise, depending on what the investigation confirms:

• T1195.002 — Compromise Software Supply Chain: Relevant to the malicious modification or compromise of a software supply chain.

• T1059 — Command and Scripting Interpreter: Applicable when observed activity uses a command or scripting interpreter.

• T1105 — Ingress Tool Transfer: Relevant when evidence shows that additional tools or payloads were transferred into the environment.

• T1071.001 — Web Protocols: Potentially applicable when command-and-control activity uses web protocols.

• T1078 — Valid Accounts: Relevant if attackers use legitimate accounts to access systems or resources.

These are conditional mappings, not a claim that each technique occurred on every infected endpoint. Select techniques according to the actual evidence and the appropriate ATT&CK sub-technique.

11. Defending Against Multi-Stage Supply Chain Attacks

Validate software integrity

Maintain software inventories, validate update sources, and verify signatures and hashes where appropriate. Use trusted vendor advisories to determine whether specific versions or releases are affected.

Monitor application behaviour

Baseline normal application execution, file access, and network activity. Alert on unexpected child processes, unusual module loading, suspicious downloads, and connections that do not match expected application behaviour.

Apply least privilege

Limit the permissions available to desktop applications and their associated service accounts. Prevent ordinary endpoints from having unnecessary access to privileged systems and sensitive data.

Use layered endpoint protection

Combine EDR, application control, threat intelligence, and behavioural analytics. No individual detection method is sufficient against every staged malware campaign.

Segment networks

Restrict unnecessary communication between user endpoints, servers, identity systems, and sensitive workloads. Segmentation can limit the opportunities available to an attacker after an endpoint is compromised.

Centralise security telemetry

Collect endpoint, network, identity, and cloud logs in a central monitoring platform. Preserve enough history to reconstruct activity that may have begun before the incident was detected.

Prepare for supplier incidents

Maintain a process for responding to vendor security advisories, identifying affected versions, finding deployed copies, and prioritising remediation.

Regularly test whether the organisation can rapidly identify all endpoints running a particular application and determine when it was installed or updated.

Conclusion

The 3CX supply chain attack demonstrated how an earlier compromise can be connected to a second compromise, allowing attackers to abuse trusted software distribution to reach downstream organisations.

The campaign's multi-stage nature makes it an important case study for SOC analysts. Effective investigation requires more than identifying a compromised application: analysts must validate software exposure, reconstruct execution, investigate command-and-control activity, assess identity exposure, and hunt for follow-on actions.

For defenders, the key lesson is to combine software integrity checks with behavioural monitoring and cross-layer investigation. A trusted update is a starting point for verification—not a guarantee that the software or the environment is safe.

Further Reading

• CISA — Cybersecurity Advisories

• MITRE ATT&CK — Compromise Software Supply Chain (T1195.002)

• Mandiant — 3CX Software Supply Chain Compromise

• SentinelOne — 3CX Supply Chain Attack Analysis