3CX Double SSC Attack Analysis

• 3CX Double SSC Attack is a multi-stage compromise that disrupts both upstream distributions and downstream build systems to inject malicious artifacts.
• The attack exploits vulnerabilities from distribution servers to employee hosts and build environments, demonstrating advanced propagation techniques.
• Extended MulVal frameworks now integrate SSC predicates with network rules to enhance detection of combined supply chain and software artifact vulnerabilities.

The 3CX Double Software Supply Chain (SSC) Attack denotes a multi-stage, chained compromise leveraging vulnerabilities in both upstream and downstream elements of a software supply chain, culminating in the malicious modification and widespread distribution of a critical software artifact. This attack is characterized by transit across distinct organizational boundaries and trust domains, integrating both traditional network-based exploits and advanced supply-chain propagation, resulting in a doubly-nested SSC attack path. Its modeling, analysis, and detection have motivated substantial extensions to existing attack-graph frameworks, notably the integration of SSC predicates and propagation semantics within logical attack graph generation systems such as MulVal (Soeiro et al., 14 Nov 2025).

1. Attack Stages and Logical Structure

The 3CX double SSC attack proceeds through four canonical stages:

1. Upstream Compromise of X_Trader Distribution: The attacker exploits a remote vulnerability in the Trading Technologies (TT) distribution server (host $h_{tt}$), resulting in root access and tampering of the X_Trader software artifact ($sa_{XT}$).
2. Downstream Pivot into 3CX Enterprise: An employee of 3CX (host $h_{emp}$) downloads and executes the compromised $sa_{XT}$, permitting the attacker to leverage cached VPN credentials and pivot into 3CX’s internal infrastructure.
3. Compromise of 3CX Build System: Escalation continues to the 3CX build server ($h_{build}$), with isolation escape from the build environment ($BE_{3CX}$) and subsequent compromise of the build pipeline transformer ($T_{build}$). This allows malicious code injection into the 3CXDesktopApp artifact ($sa_{3CXApp}$), which is then signed using the formerly legitimate, now compromised, code-signing key.
4. Customer Impact via Malicious Artifact Distribution: The compromised $sa_{3CXApp}$ is published to customer environments, enabling attacker code execution across the customer base.

Supply-chain graphically, the attack forms two tightly coupled subgraphs:

• TT → $sa_{XT}$ → employee host → 3CX network
• 3CX build host → build environment → transformer → $sa_{3CXApp}$ → customers

2. Formal Modeling: Predicates and Inference Rules

To represent and analyze such attacks, the MulVal logical attack graph framework is extended with new predicate classes and interaction rules, specifically to encode SSC semantics:

Predicate	Meaning	Example Usage
wasPresent(SA, H)	SA observed/executing on host H	wasPresent($sa_{XT}$, $h_{emp}$)
hosted(H, BE)	Build environment BE runs on host H	hosted($h_{build}$, $BE_{3CX}$)
executed(BE, T)	Transformer T ran inside build environment BE	executed($BE_{3CX}$, $T_{build}$)
transferred(src, SA)	SA downloaded/transferred from src	transferred($h_{tt}$, $sa_{XT}$)
maliciousSA(SA)	SA is marked malicious	maliciousSA($sa_{XT}$)

Rule-based propagation ties compromise and vulnerability across chain elements. For example, maliciousSA is inferred via the compromised build transformer, and vulnerability propagation across artifacts adheres to:

$$vulnerableSA(SA,\,v)\;\leftarrow\;vulnerableSA(SA_{in},\,v)\;\wedge\;wasInputTo(SA_{in},T)\;\wedge\;generated(T,SA)$$

The extension unifies SSC semantic inference (malicious artifact propagation, build-pipeline-derived compromise, code-signing chain breaks) with conventional MulVal network predicates, ensuring full relational tracking from supply-chain events to exploitability on individual hosts.

3. Integrated Network and SSC Attack Graph Reasoning

Bidirectional integration of SSC and network attack graphs is a central feature:

• SSC → Network: When a vulnerable software artifact is inferred in the supply-chain graph, corresponding networkServiceInfo and/or vulExists predicates are generated. This allows artifacts produced or delivered via supply-chain mechanisms to be treated as network-exploitable services, thus enabling downstream lateral movement analyses.
• Network → SSC: When network-side rules (e.g., execCode or execBatchCode) establish host compromise, these facts inject into the SSC graph, firing compromise propagation rules. Specifically, compromisedH(H) triggers compromisedBE, compromisedT, and maliciousSA, enabling further downward SSC propagation and trust chain breakage.

A real MulVal-generated attack graph consequently features interleaved (purple for SSC, orange for network) edges representing both semantic domains, with flows such as:

internet | [N] hacl/internet→h_tt & vulExists → execCode v h_tt (compromised) | [S] wasPresent → maliciousSA(sa_XT) v h_emp (victim) | [S] execBatchCode → compromisedH(h_emp) v h_build (3CX build host) | [S] isolationEscapeBE(BE_3CX) v BE_3CX (compromised) | [S] compromisedT(T_build) → maliciousSA(sa_3CXApp) v customers (h_cust1, h_cust2)

4. Sequence of Attack Events and Inference Example

The logical analysis proceeds through distinct steps, each with associated MulVal facts and derived rules:

1. Exploitation of Distribution Server:
   • Facts: $attackerLocated(internet)$, $hacl(internet, h_{tt}, tcp, 443)$, $vulExists(h_{tt}, "CVE-TT-HTTP", httpd)$
   • Inference: $$networkServiceInfo(h_{tt}, httpd, tcp, 443, apache)$$; $execCode(h_{tt}, root)$; $compromisedH(h_{tt})$
2. Artifact Tampering:
   • Facts: $transferred(h_{tt}, sa_{XT})$, $wasPresent(sa_{XT}, h_{tt})$, $wasPresent(sa_{XT}, h_{emp})$
   • Inference: $maliciousSA(sa_{XT})$
3. Pivot via Employee Host:
   • Inference: $execBatchCode(h_{emp}, sa_{XT}, empUser)$; $compromisedH(h_{emp})$
4. Build Environment Isolation Escape:
   • Facts: $hosted(h_{build}, BE_{3CX})$, $wasPresent(sa_{XT}, h_{build})$, $vulExists(BE_{3CX}, "CVE-escape", container)$
   • Inference: $isolationEscapeBE(BE_{3CX})$
5. Build Pipeline Transformer Compromise:
   • Facts: $executed(BE_{3CX}, T_{build})$, $wasBuildToolTo(sa_{tool}, T_{build})$
   • Inference: $compromisedBE(BE_{3CX})$; $compromisedT(T_{build}, BE_{3CX})$; $maliciousSA(sa_{3CXApp})$
6. Code Signing Key and Chain Subversion:
   • Facts: $wasPresent(key_{3CX}, h_{build})$, $signedSA(key_{3CX}, sa_{3CXApp})$, $validateSA(cert_{3CX}, sa_{3CXApp})$
   • Inference: $compromisedK(key_{3CX})$; $compromisedC(cert_{3CX})$; $maliciousSA(sa_{3CXApp})$
7. Distribution to Customers:
   • Facts: $wasPublishedTo(sa_{3CXApp}, h_{cust1})$, $wasPublishedTo(sa_{3CXApp}, h_{cust2})$
   • Inference: $compromisedH(h_{cust1})$, $compromisedH(h_{cust2})$

5. Implications for Automated SSC Attack Path Discovery

By encoding system host and software topology—including build environments, artifact provenance, transformers, signing keys, and certificates—within the extended MulVal model, practitioners can automatically discover both classic network attack paths and deeply intertwined SSC paths representative of sophisticated campaigns like the 3CX double SSC attack. Standard network-only or SSC-only analyses systematically miss multi-domain, chained compromise paths of this type.

This integration demonstrates operational feasibility and analytical advantages for modeling and detecting attacks that exploit the dual nature of software supply chain and network propagation, substantiating the necessity of unified frameworks for modern cyber defense against advanced, supply-chain-oriented threats (Soeiro et al., 14 Nov 2025).

6. Formal Vulnerability and Compromise Propagation

Key inference rules governing SSC propagation include:

• Vulnerability propagation (via build pipeline):

$$vulnerableSA(SA,\;v)\;\leftarrow\;vulnerableSA(SA_{in},\,v)\;\wedge\;wasInputTo(SA_{in},T)\;\wedge\;generated(T,SA)$$

Meaning that a vulnerability $v$ present in an SSC input artifact propagates through a transformer $T$ to its outputs.

• Malicious software and compromise propagation:

$$compromisedT(T,\;BE) \leftarrow compromisedBE(BE),\,executed(BE, T)$$

$$maliciousSA(SA) \leftarrow compromisedT(T, BE),\,generated(T, SA)$$

These rules capture the essential dynamics of attacker control transfer within the complex build and software delivery chain.

• Code-signing chain subversion:

$$compromisedC(Cert) \leftarrow compromisedK(Key),\,signedC(Key, Cert)$$

$$maliciousSA(SA) \leftarrow compromisedC(Cert),\,validateSA(Cert, SA)$$

This enables inference of malicious artifact status for code-signing trust chain breaks.

A plausible implication is that advanced supply-chain attacks exploiting both software artifact lineage and build infrastructure compromise require hybrid, relationally expressive security analysis frameworks, as traditional models lack sufficient representational capacity for such propagation.

---

For comprehensive technical detail and the full Datalog specification of predicates, interaction rules, and the complete illustrated attack graph for the 3CX double SSC attack, see (Soeiro et al., 14 Nov 2025).