Attackers turn unpatched TrueConf servers into backdoor delivery, pushing trojanized client installers

A self-hosted conferencing server that also ships its own client is two products wearing one hostname. One of them answers meeting requests. The other quietly hands executables to everyone in the building. Compromise the box once and the second job becomes a malware dispenser, because every future client update flows through infrastructure the attacker now owns. That is the mechanism behind the latest attacks on TrueConf, and it is why the same product keeps getting hit.

Kaspersky researchers, who disclosed the campaign in early August, tie this wave to the Head Mare group and place discovery in July 2026. The intrusion path needs no credentials. The server listens on TCP port 4307, and that port ships open and accepts unauthenticated connections, so nothing stands between a reachable box and the exploit. The operators then chained two flaws Kaspersky tracks as KLCERT-26-057 (run a malicious script inside the server's isolated environment) and KLCERT-26-058 (break out of that sandbox and run commands on the host).

The rest reads like a standard host takeover. Privileges are raised to NT AUTHORITY\SYSTEM, and a web shell is dropped in place of a legitimate server file (\public\js\locale.php) so the operator keeps a way back in. Then comes the part that matters to everyone downstream: the client installers the server offers as updates are swapped for trojanized builds carrying two backdoors Kaspersky names PhantomCore and PhantomGraph. PhantomGraph ships as two DLLs and takes its commands through attacker-controlled Microsoft OneDrive accounts, which lets its traffic blend into normal cloud usage.

Which builds are exposed, and the fix

The flaws sit in the 5.5, 5.4, and 5.3 branches, in every build older than the fixes listed in the table below, and in 5.2 and earlier. TrueConf shipped the patched builds on June 18, 2026. Discovery of active exploitation came in July, so the patch predates the public campaign by roughly a month. That gap is the window operators who deferred the update were exposed in, and it is exactly the window where a server could have become a distribution node before anyone was looking.

The real tell is an unsigned installer

Here is the detail worth pinning to the wall: the trojanized installers are not digitally signed. TrueConf's own builds are. So the boundary that failed was not a missing patch on the endpoint, it was trust. Users, and the client software, accepted whatever the local server offered because it came from the local server. An organization that verified the publisher signature on the update path, or ran an allowlist that only lets signed TrueConf binaries execute, would have rejected these builds no matter how thoroughly the server was owned. This is the same lesson as a hijacked trusted script served to thousands of browsers or a WordPress CDN backdoor that only fired for logged-in admins: the delivery channel was trusted, so nobody inspected the payload.

It also reframes the exposure. Even shops that do not run a TrueConf server are not automatically clear. Employees who join a meeting hosted on a partner's or supplier's compromised server can be offered the same poisoned installer. Your patch status does not govern a counterparty's, which is the uncomfortable arithmetic of any attack that rides trusted infrastructure you do not control.

Patch is step one. Hunt is step two.

Upgrading the server to 5.5.5, 5.4.9, or 5.3.9 stops new poisoned installers from being served. It says nothing about clients that already took one. Because the malicious build ran with a user's own hands, treat the client fleet as the investigation, not the server. Concretely:

• Inventory installed TrueConf clients and flag any binary that is not signed by TrueConf. An unsigned client is the highest-confidence indicator you have.
• Watch TrueConf.exe and its child processes for outbound connections that do not fit a conferencing app, in particular traffic to OneDrive that a normal client would never generate, and unexpected DLLs loading into the client process.
• On hosts Kaspersky examined, the operators pulled credentials straight from memory with an LSASS dump, ran quick whoami and hostname checks, and opened a reverse SSH tunnel outbound. On the server itself, look for the planted web shell at \public\js\locale.php and any admin or service account added since your last known-good baseline.
• Restrict the server's management and update surface. Port 4307 reachable from the internet is a pre-auth path with no login in front of it, so it belongs behind a VPN or a tight allowlist, not on a public interface. The same reflex applies to any internal server that answers before it authenticates.

If you find an unsigned client, assume credential theft happened on that host and rotate accordingly, because LSASS dumping means the passwords cached on that machine are the attacker's now, and patching does not evict them.

This keeps happening to TrueConf, and that is the signal

Treat this as one data point in a trend, not a one-off. Head Mare ran an earlier TrueConf campaign that Kaspersky traced to late 2025, delivering a different backdoor, PhantomPxPigeon, through the same installer-swap idea. Separately, in April 2026, Check Point attributed a distinct TrueConf operation it called Operation True Chaos (CVE-2026-3502) to a China-linked actor running the Havoc framework. Three campaigns, at least two unrelated actors, one product, all inside a year, and all converging on the same trick.

That convergence is the point. Adversaries independently reached the same conclusion: a self-hosted app that pushes its own client is a high-value pre-auth target, because one server compromise buys a signed-looking distribution channel into every machine that trusts it. TrueConf is the current example. The category, on-prem servers that double as software update sources, is the actual exposure. If you run one, the question is not only whether it is patched. It is whether you would notice the day it started handing out something that was not yours. Kaspersky's telemetry places these victims in Russian industry, but the design flaw the attackers keep exploiting is not regional.