The Brand Was Real. The Desktop App Wasn’t.

ScreenConnect is an RMM product, the kind of tool a help desk uses to take control of a machine with the user watching. This build was configured to surreptitiously do the same thing without the user being aware. We extracted the client configuration and the launch parameters. The access mode is set to unattended. The victim-facing indicators are turned off: no “your machine is being controlled” banner, no system-tray icon, no connection balloon. From the client’s app.config, verbatim:The banner that tells a user their machine is under someone else’s control does not turn itself off by default. The client installs as a Windows service, adds itself to Safe Mode with networking so it survives a safe-boot cleanup, and registers scheduled tasks. It also registers a credential provider, a component that loads on the Windows sign-in screen, so the operator’s session reaches the machine before anyone has logged in and stays with it through the lock screen. The result is a quiet, persistent, interactive foothold.

Every name branded copy of the payload ultimately pointed to the same place. The relay is a self-hosted ScreenConnect server at jyleatyg[.]com, resolving to 89.213.118[.]127 on port 8041, in Germany. The operator stood up their own server rather than using ConnectWise’s cloud, and left its web console exposed on the internet with the stock theme and no branding. The relay info is baked into the payload in two places and does not change when the wrapper is rebuilt, which makes it a durable indicator. This is the constraint in system.config that fixes every client to that one host and port, with the relay’s public key alongside it (key truncated):The config embeds two things: the domain name and the server’s key. A domain is easy to swap, so blocking it buys little; the operator can register a new one and redeploy. The key is different. It belongs to the server itself and stays the same even if the domain changes or the installer is rebuilt around it. Only standing up an entirely new server would change it. That is why the key’s fingerprint, not just the domain, is in the indicator list.

One word of caution before going further. The relay port 8041 and the file name ScreenConnect.ClientSetup.msi are ScreenConnect defaults, and both show up in unrelated campaigns run by other operators. They may be worth alerting on in specific cases, but on their own they identify the product, not this actor. That is why the indicators we lean on are the operator’s own: the relay, the client instance id, and the fingerprint of the server’s key.

Step back and nothing in this chain is malware in the usual sense. The page was generated by a legitimate AI builder and served by a legitimate host. The download came from a legitimate code platform. The one window the victim saw belonged to Microsoft. The thing that was installed is a legitimate RMM product, doing what it was designed to do, for someone who was never supposed to have it. Defenders have two names for this. Living off the Land (LotL) means using tools that are already trusted on the machine instead of writing custom malware, and here that is ScreenConnect and the Windows installer itself. Living off Trusted Services (LoTS) is its hosting counterpart: putting the infrastructure on platforms with good reputations so the domains and downloads look benign, which is what GitHub and Vercel did for this operator. This campaign does both, end to end. No typical malware, no exploit, no rogue infrastructure. Nothing to see, which was the point.